#foswiki 2011-09-08,Thu

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***MartinCleaver has joined #foswiki [00:15]
............... (idle for 1h12mn)
pharvey has joined #foswiki [01:27]
.... (idle for 15mn)
MartinCleaver has quit IRC (Quit: MartinCleaver) [01:42]
...... (idle for 27mn)
tsnfoo has quit IRC (Quit: tsnfoo)
tsnfoo has joined #foswiki
[02:09]
gac410Baar, That "possible attempt to separate words with commas" is bogus. I have list that contains some ,v files - which of course are valid names and not an attempt for two file names blah.txt and "v"
er. Babar, not Baar
And on my system it was a warning - the test still ran. No "failed to use" here.
[02:16]
.............. (idle for 1h8mn)
***Lynnwood has quit IRC (Quit: Lynnwood) [03:26]
......... (idle for 44mn)
pharveygac410, ArthurClemens - do you have any opinion on the proposed Web.Topic@123 notation for revision-specific topic addresses?
long-winded discussion at Foswiki:Development.LoadDifferentTopicVersions
[04:10]
FoswikiBothttp://foswiki.org/Development.LoadDifferentTopicVersions [ LoadDifferentTopicVersions ] [04:10]
gac410I think the only concern I raised would be how it interacts with auto recognition of email address.
Could you write "Refer to InstallationGuide@10 for ... " for example.
[04:11]
pharveyI hope so
but autolinking might be too tedious
[04:11]
gac410The current email regex would pick it up as an email address I suspect. The new regex I checked into trunk would probably be safe. [04:12]
pharveyI guess I'm not hunting for implemention thoughts (though I do appreciate them), but rather the overall proposal [04:13]
gac410overall I believe an easy nomenclature to reference past revisions of topics is a good addition. [04:14]
pharveyDid you think any other ideas in the proposal deserve more consideration? Michael preferred a speaking-word variation, such as Web.Topic!revision=3
crawford proposed Web.Topic(revision=3)
[04:16]
gac410I'm reading the topic now. I guess references to old versions don't happen all that often, so are we wasting a simple @xxx shorthand for something that is not used often. [04:18]
pharveySvenDowideit is the only user apart from me (of Foswiki::Address :-) and he hasn't complained about Foo@123, but that's probably because he doesn't have time to have any strong opinion :) [04:18]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Address [ (Foswiki login) PerlDoc ] [04:18]
pharveyah, this isn't just a TML syntax change. This is indirectly a proposal to accept Foswiki::Address's current implementation
Foswiki::Address provides a way to parse into atoms, then build back out into a string, an address to any Foswiki 'thing'
Web, Topic, Attachment... of a particular revision
it actually also does addresses to parts of a topic: meta type, meta datum, key on a meta datum
without a decision here, Foswiki::Address's $address->stringify() is useless to everybody except itself
[04:19]
gac410For the F:::A implementation I don't think the @ matters at all. It's really the TML syntax change that is the public face of the proposal that's concerning. [04:22]
pharveyright. So that's why I didn't pollute this proposal with any F::A business
because I'm prepared to change F::A to whatever we agree on, but if we don't like @, I need to know that, and get some alternatives which are better
[04:23]
gac410So today we use ?rev=n as a url param, in a [[]] bracketed link. Is there a reason that staying with that format is bad?
possibly changing the tml syntax to accept Web.Topic?rev= (or Web.Topic?version= )
[04:26]
pharveyThat was the first idea I had
But imagine you have the address string 'Web.Topic?rev=123'
and in your wiki app you want to append some URL params to it
Web.Topic?rev=123?foo=bar doesn't work
also, I thought it would be confusing to have a "Foswiki address" which took one thing that looks like a URL param, would users expect to be able to use others?
Where does an "address" obviously start and end in a given URL?
http://foo.org/Web.Topic@123?foo=bar - you can still easily parse out the "address" part
?rev=123 could work, but only by convention... and I just think it could be confusing to users
I guess I'm a little perplexed why everybody thinks the '@' is controversial
[04:27]
gac410So you want the rev part of the address in a fixed location. The ?rev= implies that as a url param it could be anywhere in the parameters. And we don't permit ?urlparam=blah in tml without the [[ ]] [04:29]
pharveyI think ?urlparam without [[ ]] isn't a big issue
because we could possibly "fix" the autolinking code to cater for that
[04:30]
gac410I wouldn't call it controversial. I think that TML changes though are very deep and long-lived, so some due consideration is important. But don't want paralysis. [04:31]
pharveyYeah, I understand. I think I've just exhausted myself trying to think through all the problems. I need external feedback to finally make a decision and just code it up. [04:32]
gac410The ?rev= implies urlparam. So even if you fix autolinking, there is implication you could use Web.Topic?blah=asdf;d=a;rev=32 as position of url params is not necessarily significant.
whereas Web.Topic@32 is very specific - fixed location. Either there or not without any complex url parsing.
[04:32]
pharveyFor example, 'classical' usage of Foswiki::Func::normalizeWebTopicName() will need to either truncate off the @rev part, or return it as a third element ($web, $topic, $rev) [04:33]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Func [ (Foswiki login) PerlDoc ] [04:33]
pharveygac410: exactly. Easier for me to code :P [04:34]
gac410I think that CDot's (version=123) has the advantage of being fixed position - avoids urlparam confusion, and has future extension possibilities of (at=timestamp) [04:39]
pharveyrev@time is fraught with timezone offset complexities, but I understand
though rev@2001-04-03 could be detected as a timedate rather than an integer rev
but we are guilty of making too much magic in Foswiki
[04:40]
gac410is there a disadvantage to the (instance-selector) syntax (rev= (version= (at= ... [04:42]
pharveyI don't think so [04:43]
gac410(...) seems to be more extensible than @some-magic [04:43]
pharveyexcept ( and ) are allowed in topic names :/ [04:43]
gac410Aw ^&*() [04:44]
pharvey[ ] aren't
< > aren't
ooh. That would make it consistent-ish with existing querysyntax
Web.Topic[version=123]
[04:44]
gac410What does that do to [[Web.Topic][some string] Does it become [[Web.Topic[version=123]][some string]] bleh [04:46]
pharveyd'oh :)
I like the idea of an instance selector, though.
[[Web.Topic[version=123]][some string]] doesn't render at all on existing code.
Forgetting the parse problem. Is that ugly to write?
too ugly, I mean
Because as we say, we're not doing this very often (rev-specific linking)
[04:46]
gac410That's what I was just typing back...
Hm. Though for a bracket link, maybe we need specific syntax [[Web.Topic][Title][version=]] Which is probably easier to write than the extra nesting.
[04:49]
pharveyI'd really love to keep it consistent.
if only { } weren't valid in wiki names :)
[04:55]
***HughBlair has joined #foswiki [04:57]
gac410I wonder how many sites would actually run into an issue with {}. I know () would be an issue.
Syntax also has to work for attachments, right?
[04:57]
pharveyYes [04:58]
gac410Although that gets reallly complex - how to flip to viewfile from direct pub access. [04:59]
pharveyCurrently Foswiki::Address parses and stringifies them as Web/SubWeb.Topic/Attachment.pdf@123 [04:59]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Address [ (Foswiki login) PerlDoc ] [04:59]
pharveythe @ syntax was going to fail for direct pub access, too. [05:00]
gac410yeah. [05:00]
pharveyFoswiki would render these to viewfile though.
which would understand it
[05:00]
gac410right
glad you are making the decision on this one.
[05:00]
***gac410 has left [05:02]
HughBlairhello all, I'm having a spot of bother with Foswiki::Plugins::ImageGalleryPlugin, the titles argument doesn't want to play nice for me. If I say %IMAGEGALLERY{titles="on"}% then I don't get any titles underneath the thumbnails. Nothing relevant in apache error.log or foswiki error.log... Any hints? [05:11]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Plugins::ImageGalleryPlugin [ (Foswiki login) PerlDoc ] [05:11]
HughBlairFYI: I've got the Apache rewrite rules set to push attachments through bin/viewfile (which I know causes an incompatibility) but I set an exception for pub/images (i.e. RewriteRule ^/+pub/+images/+.*$ - [L,PT]).
Everything renders fine, but I just can't get the thumb titles to show in the thumbnail gallery (the $comments show just fine when I view the full size image)
[05:14]
pharveyHughBlair: I see it too. Raise a task at http://foswiki.org/Tasks/ImageGalleryPlugin [05:21]
HughBlairpharvey: thanks for confirming this, I thought I was going insane ;) I have raised Item11117 but didn't fill in many of the formfields in the Item. If you have any suggestions please let me know... [05:33]
FoswikiBothttp://foswiki.org/Tasks/Item11117 [ Item11117: thumbtitles don't show ImageGalleryPlugin (even with titles=on) ] [05:33]
.... (idle for 19mn)
pharveyHughBlair: looks fine. Sadly I don't use this feature, and a quick read of the code doesn't seem obviously wrong, I'm too busy to look further :(
I wonder if it's a JS problem.
[05:52]
HughBlairpharvey: Thanks for your assistance on this... [05:58]
.... (idle for 18mn)
***CDot has joined #foswiki
ArthurClemens has quit IRC (Quit: ArthurClemens)
[06:16]
Sam687 has joined #foswiki [06:26]
Colas has quit IRC (Remote host closed the connection)
Colas has joined #foswiki
[06:33]
pharveyCDot: I wrote to foswiki-svn rambling about Web.Topic@123 notation. I noted that people seem to prefer a 'selector' notation as you and Micha discussed, so I proposed Web.Topic[version=123] :-)
only because () are valid topic chars, whereas [] aren't
(! is a valid topic char too :(
[06:38]
***MichaelDaum has joined #foswiki
MichaelDaum has quit IRC (Changing host)
MichaelDaum has joined #foswiki
ChanServ sets mode: +o MichaelDaum
[06:42]
pharveyhowdy MichaelDaum
I sent a mail to foswiki-svn with some rambling about Web.Topic@123 notation. I noted that Web.Topic(rev=123) and Web.Topic!version=123 are both depending on chars which are allowed in topic names (!, (, ) - so I'm wondering about Web.Topic[version=123]
[06:42]
MichaelDaumheya paul [06:43]
pharvey[] are not allowed in topic names [06:44]
***HughBlair has quit IRC () [06:49]
CDotpharvey: but that's the syntax for a query selector.....
CDot is concerned about risk of confusion, as "version" is not a valid selector in query expressions
CDot really isn't happy about using squabs that way
[06:54]
pharveykool
just trying to kick things along :)
I guess we could use a variation of MichaelDaum's ! idea, just using a char that's not valid in a topic name.
or give up and stick with @123
the only magic chars remaining that seem vaguely plausible are *, ~, ^, $ and @
Web.Topic$version=123 ?
Web.Topic~version=123
Web.Topic*version=123
[06:56]
CDotCDot has always been happy with @123, and doesn't understand the arguments against (or hasn't read them)
requiring the parser to reserve @ as an atom is overkill, as really it's /\@\d+\b/ that needs to be recognised
[06:59]
pharveyCDot: I'm pretty happy with @123 too, but I guess there's a concern about whether it's future-proof enough for @datetime and @namedversion [07:00]
***mark_doe has quit IRC (Ping timeout: 252 seconds) [07:01]
CDothmmm. well, @2011-09-11 is pretty recognisable too, as is @BertholdtBrecht
the only reasonable 'con' is if the @ symbol can be mistaken for an email addrsss.
[07:01]
pharveyI thought so too, but I was having trouble getting gac410 to like it :)
Which according to my testing and reading of RFCs implies it isn't
at least, nobody has given me a case where it's a problem
we also have a tomcat app at work which uses @ in its paths
[07:03]
***ModAcOst has joined #foswiki
terceiro has quit IRC (Remote host closed the connection)
[07:07]
CDotthey only case I can think of is where a extension developer has been sloppy. In that case, turning off the @ syntax may be a requisite. [07:09]
***mark_doe has joined #foswiki
foswiki_irc4 has joined #foswiki
foswiki_irc4 is now known as FlorianP
[07:10]
pharveyHopefully, as long as people are using normalizeWebTopicName, the problem won't be too overwhelming [07:11]
CDothum, given that we provide a regex for recognising email addresses, does that regex also match @123, @2011-09-11 or @mineallmine style address expressions? [07:12]
pharveynot on trunk, after george's recent fixes [07:13]
Babarpharvey: did you see all my swearing against you in the logs? :) [07:13]
CDotIsaac.Newton@1727.co.uk [07:13]
***Babar sets mode: +oooo Colas ColasHome CDot leik
Babar sets mode: +o pharvey
[07:13]
MichaelDaumpharvey, I like [] ... very xpathish/jquerish [07:14]
CDotIsaac.Newton@1654-1727.co.uk is a valid email address [07:14]
MichaelDaumthe point to separate address from query is well made too [07:14]
pharveyCDot: I think george's new regex looks for a dot in the hostname part
but I could be wrong about that
Item11059
[07:15]
FoswikiBothttp://foswiki.org/Tasks/Item11059 [ Item11059: Email address followed by a dot generates email link with dot included ] [07:15]
CDota smarter regex might do it. [07:15]
MichaelDaumso how about doing both: @revision-tag and [some query] [07:16]
pharveyI'd rather just one way todoit [07:16]
CDotstill unhappy about [] being confused with query syntax. Maybe I'm just being paranoid. [07:16]
MichaelDaumMichaelDaum not sure to see the problem [07:17]
BabarTWikiFuncTests::test_TWiki_web that's the only unit test not passing???
should be easy to fix :)
[07:17]
CDotCDot has gone to play golf in the rain. Back l8r. [07:17]
pharveyBabar: I see now that AddressTests are failing like mad... but not on my machine? :( [07:17]
MichaelDaumBabar, lol [07:17]
CDotBabar: I'm getting loads of failures locally. Trying to understand them, but it's blocking me from checking in ATM.
they don't seem related to my changes in any way :-(
[07:17]
Babarpharvey: they're unexpected passes, not failures for me :) [07:18]
***CDot has quit IRC (Quit: Leaving.) [07:18]
pharveyunexpected pass = fail
I don't get them
oh, I lied.
mega-fail 5000
but they pass when run stand-alone...
... I guess re-using the same Foswiki session across all those tests might be making it sad somewhere
[07:18]
***leik has quit IRC (Read error: Operation timed out) [07:24]
pharveyhah! I thought calling $this->expect_failure() should only affect the test where it was called?! [07:26]
BabarBabar wonders who coded that feature :) [07:37]
.... (idle for 15mn)
***MartinRowe has joined #foswiki [07:52]
pharveyit was working fine... some time ago
if I remove the expect_fail, then test_simple_noparams is the only thing that fails
[07:57]
***pharvey has quit IRC (Quit: ChatZilla 0.9.87 [Firefox 3.6.22/20110905191701]) [07:58]
Babarthen somebody broke it :) [08:01]
***leik has joined #foswiki
leik has quit IRC (Read error: Connection reset by peer)
[08:03]
ArthurClemens has joined #foswiki [08:19]
Alexander__ has joined #foswiki [08:26]
leik has joined #foswiki
McAldo__ has joined #foswiki
McAldo_ has quit IRC (Read error: Connection reset by peer)
McAldo__ has quit IRC (Ping timeout: 264 seconds)
[08:36]
denisr has joined #foswiki
McAldo__ has joined #foswiki
[08:54]
Colas has quit IRC (Quit: Ex-Chat) [08:59]
Alexander__Hi there! I would like to use an ajaxForm to save topics. I´m thinking about a cover and spinning wheel during the save process with a wysiwyg editor, for example. I could set the cover once i´m clicking save and i would like to remove the cover when i get a sucess response. What i need is the success function, but the overall behaviour should be the same like with a normal submit()...
...(redirecting to the bin/view for example)
Is there an aproach to use the sucess function, but to have still the same behaviour like without ajaxForm?
[09:02]
***McAldo_ has joined #foswiki
McAldo__ has quit IRC (Ping timeout: 240 seconds)
verboEse is now known as VerboEse|Off
McAldo_ has quit IRC (Ping timeout: 260 seconds)
[09:07]
McAldo_ has joined #foswiki
Colas has joined #foswiki
McAldo__ has joined #foswiki
pharvey has joined #foswiki
McAldo_ has quit IRC (Read error: Connection reset by peer)
[09:22]
McAldo__ has quit IRC (Ping timeout: 260 seconds) [09:33]
McAldo__ has joined #foswiki [09:45]
McAldo_ has joined #foswiki
McAldo__ has quit IRC (Read error: Connection reset by peer)
VerboEse|Off is now known as verboEse
McAldo_ has quit IRC (Ping timeout: 240 seconds)
pharvey has quit IRC (Read error: No route to host)
pharvey has joined #foswiki
McAldo_ has joined #foswiki
[09:58]
denisr has quit IRC (Quit: Parti) [10:21]
.......... (idle for 47mn)
pharvey has quit IRC (Changing host)
pharvey has joined #foswiki
[11:08]
GithubBot has joined #foswiki [11:16]
GithubBot[foswiki] foswiki pushed 1 new commit to master: https://github.com/foswiki/foswiki/commit/5c557c125863f68fc5607e95469f8eef2b06b244
[foswiki/master] Item11119:Item11005:Item10886:Item10880:Item10302:Item10744: - MichaelDaum
[11:16]
***GithubBot has left [11:16]
FoswikiBothttp://foswiki.org/Tasks/Item11119 [ Item11119: create a new foswiki jquery-ui theme ] http://foswiki.org/Tasks/Item11005 [ Item11005: Surplus "; in JQueryPlugin/UI.pm ] http://foswiki.org/Tasks/Item10886 [ Item10886: make theming of jquery-ui pluggable ] http://foswiki.org/Tasks/Item10880 [
..Item10880: move to jquery.ui.autocomplete ] http://foswiki.org/Tasks/Item10302 [ Item10302: JQuery 1.6.1 update ] http://foswiki.org/Tasks/Item10744 [ Item10744: create an ajax progress bar UI element for 'initialise or update' restHandlers to all use ]
[11:16]
***Alexander__ has quit IRC (Ping timeout: 258 seconds) [11:20]
Alexander__ has joined #foswiki [11:27]
.... (idle for 15mn)
SvenDowideitpharvey: I _do_ have a strong opinion about Topic@143 and topic@2011-11-12
i think its a good syntax
but note that topic@2001.12.23 is a valid date :p
and don't forget that in some time cases, a user would need to specify even the seconds, and possibly parts of seconds
and a TZ
at which point, i still _like_ the idea of @, but start squirming
SvenDowideit goes to read some of the backlog
[11:42]
pharveySvenDowideit: I think it's a good syntax. Just trying to figure out if there something better. [11:46]
SvenDowideitbetter? than a symbol that is on most keyboards that means 'at' not bloody likely [11:48]
pharvey: nothing fun detail
specify a particular rev of an attachment... that might only exist up to a particular rev of a topic
and yes, i recon using ? would be bad
as we don't really want to need to goto urlparam style.
[11:54]
pharveyagreed [11:57]
***CDot has joined #foswiki [11:57]
SvenDowideitf**k they're exhausted and refusing to sleep
gone
[11:57]
CDotSvenDowideit: Nitrous Oxide. For you, not for the girls. [11:58]
***Lynnwood has joined #foswiki [12:01]
CDotCDot is getting a failure in the CacheTests "failed to remove SERVERTIME" - but this SERVERTIME isn't being added anywhere in the code that I can find. What am I missing? [12:14]
pharveyCDot: does it happen when you run cachetests by themselves? [12:15]
CDoty
foswiki.SERVERTIME appears to be a <meta> tag that's expected by the tests, but never added by the cache code AFAICT
[12:15]
nope, as far as I can tell that is never being added by the core or standard plugins. So why is that test apparently passing? [12:27]
***MartinCleaver has joined #foswiki
MartinCleaver has quit IRC (Changing host)
MartinCleaver has joined #foswiki
[12:29]
CDot*** Failed to use ConfigureTests: Possible attempt to separate words with commas at /home/foswiki/trunk/core/test/unit/ConfigureTests.pm line 1401. now. WTF? [12:30]
***GithubBot has joined #foswiki [12:30]
GithubBot[foswiki] foswiki pushed 1 new commit to master: https://github.com/foswiki/foswiki/commit/2b47ded60882470fe9f2ba892a37ec5bd3d5eae5
[foswiki/master] Item10188: Fix pseudo-install mkdir bug - PaulHarvey
[12:30]
***GithubBot has left [12:30]
FoswikiBothttp://foswiki.org/Tasks/Item10188 [ Item10188: Make pseudo-install aware of git ] [12:30]
CDotthis is clearly an error in the test code. So why doesn't it fail in the central test runs? [12:32]
pharveydifferent perls ? [12:37]
CDotCDot has found another error in ConfigureTests, traceable back to management of _indices in the meta object
appears to have been introduced recently, probably by SD judging from the comments, though PH is also implicated
note that these are genuine errors in the tests and code. I don't know what the nightly test run is running, but it isn't what's in SVN :-(
[12:40]
pharveyCDot: which tests are you looking at. I'm about to start writing a _index related test.. [12:43]
CDotConfigureTests
CDot has already fixed CacheTests, and one error in ConfigureTests
[12:43]
pharvey.. on a perhaps related bug (in that MongoDBPlugin is still producing bogus TOPICINFO{_authorWikiName....
(but only sometimes)
[12:43]
CDotCDot is not using Mongo. Vanilla, out of the box, SVN [12:43]
pharveyyeah, I understand. Just explaining reason to write a _index related test.
pharvey peeks at ConfigureTests
CDot: which ConfigureTest is wrong?
[12:44]
CDotConfigureTests::test_Package_sub_install
Assertion failed!
at /home/foswiki/trunk/core/lib/Assert.pm line 80
Assert::ASSERT('') called at /home/foswiki/trunk/core/lib/Foswiki/Meta.pm line 1247
[12:45]
pharveythat's not failing here [12:46]
CDothmph. What rev of ConfigureTests.pm, and what rev of Meta.pm?
Meta.pm: 12444
[12:46]
pharveyMeta.pm is Foswikirev:12480 [12:47]
FoswikiBothttp://trac.foswiki.org/changeset/12480 [ Changeset 12480 ? Foswiki ] [12:47]
CDotCDot has just svn upped several times. [12:48]
pharveyConfigureTests.pm is Foswikirev:12463 [12:48]
FoswikiBothttp://trac.foswiki.org/changeset/12463 [ Changeset 12463 ? Foswiki ] [12:48]
CDotthis is trunk, right? [12:48]
pharveyyes [12:48]
CDothmmm. http://svn.nextwiki.org/trunk? [12:49]
pharveyit's possible I'm misunderstanding the output of git svn info
ah, ConfigureTests.pm is actually Foswikirev:12201 according to git log
[12:49]
FoswikiBothttp://trac.foswiki.org/changeset/12201 [ Changeset 12201 ? Foswiki ] [12:49]
CDotthe nightly tests are run in an svn repo, aren't they? So git shouldn't matter?
y, 12201 is what I have
[12:49]
pharveyWhich makes Meta.pm ....Foswikirev:12444 [12:50]
FoswikiBothttp://trac.foswiki.org/changeset/12444 [ Changeset 12444 ? Foswiki ] [12:50]
CDotand the syntax error is in that rev (though may be related to perl version)
what about Meta.pm?
[12:50]
pharvey12444 [12:50]
CDotwtf. same as me. So why is this failing for me, but not for you? Guess I have to look harder.
CDot checks in the syntax error fixes.
[12:51]
pharveyI've done a clean, pseudo-install.pl -A developer
are you using -A? or manual config?
[12:52]
CDotmanual config; basically stripped down to minimum diffs from Foswiki.spec
argh; aborted a svn checkin but too late it seems
[12:54]
***GithubBot has joined #foswiki [13:01]
GithubBot[foswiki] foswiki pushed 3 new commits to master: https://github.com/foswiki/foswiki/compare/2b47ded...26d0ec7
[foswiki/master] Item11091: CacheTests and ConfigureTests were failing; these are genuine failures that are blocking my progress, so I have fixed them. - CrawfordCurrie
[foswiki/master] Item10880: docu'ed jquery.ui.autocomplete - MichaelDaum
[foswiki/master] Item11091: reverted unintentional checkin - CrawfordCurrie
[13:01]
***GithubBot has left [13:01]
FoswikiBothttp://foswiki.org/Tasks/Item11091 [ Item11091: RCS VC needs to handle mauled .txt better ]
http://foswiki.org/Tasks/Item10880 [ Item10880: move to jquery.ui.autocomplete ]
[13:01]
leikHow can I turn on debug info so that I see what happens with and without using $formfield(Name) in a SEARCH? [13:04]
CDotleik: what sort of debug info? There are many switches for enabling debug in different parts of the code.
normally there is a "use constant TRACE => 0" which, when switched to 1, generates tracing info
but it varies from module to module.
[13:06]
leikI have now disabled MongoDBPlugin and change store back to default (Item11088) Still I see the issue so I need deeper info [13:07]
FoswikiBothttp://foswiki.org/Tasks/Item11088 [ Item11088: MongoDB much slower when SEARCH outputs 'formfield()' ] [13:07]
leikTRACE in any particular file? [13:08]
***MartinRowe has quit IRC (*.net *.split)
Bamieater_ has quit IRC (*.net *.split)
WikiRingBot has quit IRC (*.net *.split)
ArthurClemens has quit IRC (*.net *.split)
verboEse has quit IRC (*.net *.split)
uebera|| has quit IRC (*.net *.split)
henk has quit IRC (*.net *.split)
SvenDowideit has quit IRC (*.net *.split)
WikiRingBot has joined #foswiki
ArthurClemens has joined #foswiki
henk has joined #foswiki
verboEse has joined #foswiki
henk is now known as Guest21167
SvenDowideit has joined #foswiki
MartinCleaver has quit IRC (Quit: MartinCleaver)
MartinRowe has joined #foswiki
FlorianP has quit IRC (Ping timeout: 252 seconds)
[13:08]
CDotleik: I doubt there's any single debug approach that will help you track that down. If I was you, I'd instrument the code with print statements myself. Starting in Foswiki/Search.pm, where the $formfield token gets expanded (it may have moved, but that's where it used to be expanded) [13:14]
SvenDowideitleik: so you can't send me the data? [13:14]
CDotare you calling $formfield on a large number of results? [13:14]
SvenDowideitthe most effective thing would be to run using nytprof - especially if your issue is in trunk without mongodb
and then to compare runs
[13:14]
CDotif so, $formfield will force each topic found to be loaded, whcih could be expensive [13:14]
SvenDowideitif its speed related, then finding where the slowness is will help more [13:15]
***GithubBot has joined #foswiki [13:15]
GithubBot[foswiki] foswiki pushed 1 new commit to master: https://github.com/foswiki/foswiki/commit/a050f1fdec575d73817f823fac9a998f1d01ab69
[foswiki/master] Item11091: CacheTests and ConfigureTests were failing; these are genuine failures that are blocking my progress, so I have fixed them. - CrawfordCurrie
[13:15]
***GithubBot has left
Bamieater has joined #foswiki
[13:15]
CDotSvenDowideit: explain why $meta->{_indices} is asserted in Meta::get, but is never defined in a Meta::new? [13:15]
SvenDowideitok, but only if you explain to me why it exists in the first place
as _indicies is a really dumb way to make sure meta accesses are as slow as possible :p
[13:15]
CDotwhat, {_indices}? Didn;t you add it? [13:16]
SvenDowideitno
if i had touched that pos code, i would have removed the moronic array stuff
[13:16]
CDotand replaced it with what? A tie? [13:17]
SvenDowideitand (unsurprisingly) thats what i'm likely to do in store2.0
no, a simple name based hash
as we've had almost 10 years of 'well allow arrarys because one day someone will maybe have more than one element with the same name, and have not dont it
(cos its a stupid idea)
[13:17]
CDotoh, right. Yeah, that aspect of it is pretty dumb.
there *are* array elements - FILEATTACHMENT, of course, but also several in plugins
[13:18]
pharveyis it a stupid idea? [13:18]
SvenDowideitFILEATTACHMENT, is not an array [13:19]
CDotit shouldn't be, no [13:19]
SvenDowideitits a hash implemented as an array to make lookup slower
but internally, we treat things as an arrya, but then serialise using name as a uniquifier
[13:19]
CDotwhatever; this isn't helping me with my immediate problem, which is fighting with a bunch of test failures that I didn't cause, AFAICT [13:19]
pharveyFWIW META:SLVALUE{name="..." - I can't think of anything to put in the name, except perhaps an array index :) [13:19]
SvenDowideitand that only happen on your system [13:20]
CDotso far, yes [13:20]
SvenDowideitwhich suggests that you need to use a different computer to make sure you're not foot shoting [13:20]
CDotI am using the same config I have always used for running the unit tests; which suggests the sys reqs have changed [13:20]
pharveyCDot: there might be something odd going on with expect_failure() - because ~257 AddressTests 'unexpected pass' from a single test that calls that method [13:21]
SvenDowideitthe nightly build box was created 2 or 3 weeks ago
and uses the same script (and only that script) as is in svn
[13:21]
CDotSvenDowideit: what perl version? [13:21]
SvenDowideitso its much morelikely that your system is hosed
debian - something
[13:21]
CDotcos the CacheTests error I fixed I can imgine being in older perls only [13:21]
leikSvenDowideit, where do you want me to send the data? [13:22]
SvenDowideitwhat data? [13:22]
CDotsorry, the Configure tests [13:22]
pharveyso I am convinced that UnitTestContrib is borked [13:22]
CDotbut the CacheTests error, I can't explain why it doesn't fail for you, because AFAICT it is most definitely a genuine failure (prior to my fix) [13:22]
pharveybecause calling $this->expect_fail() inside a test, should NOT cause all subsequent tests to also expect fail [13:23]
SvenDowideitThis is perl, v5.10.1 (*) built for i486-linux-gnu-thread-multi [13:23]
pharveybut then, maybe I'm mis-abusing the tear_down () stuff [13:23]
CDotSvenDowideit: snap (on the perl version) [13:24]
SvenDowideiti'm convinced of nothing, but then, i'm not able to think much atm [13:24]
leikSvenDowideit, the dataset. You asked if I could send it to you :) [13:24]
CDotSvenDowideit: I told you, get gas. [13:24]
SvenDowideitjust pointing out that 'its broken on my system, but no-one elses' is extremely unlikely to be the tests faiult
oh, leik sorry, your nic is in the same colour as CDot
email to Sven@fosiki.com ?
[13:24]
CDotwell, perhaps, but the code I'm running definitely has an error in it
which is why I'm surprised it works for you; pharvey and I compared revs, and we are 1:1
[13:24]
SvenDowideity, but if your failing, and no-one else is, its a clear sign something s wrong on your system
and you should seriously consider nuking it and getting a working system first
else you could trivially have lots of false results
[13:25]
CDotI did nuke foswiki, before I started this process. It is SVN clean, apart from my changes. [13:26]
pharveyCDot: what perl are you on? that @list = qw()... deprecated fails on 5.12 right? [13:26]
CDotpharvey: 5.10.1 [13:26]
SvenDowideity, and so either you have a broken system, or ... [13:26]
CDotor? [13:26]
SvenDowideityour foswiki is now nothing like reality [13:26]
pharveyweird. @list = qw() should have cause problems [13:26]
SvenDowideitSvenDowideit giggles at the idea that 'It is SVN clean, apart from my changes' [13:27]
CDotpharvey: should have, or should not have? [13:27]
pharveyshould
I agree with your analysis
[13:27]
CDotI agree, and it did on my system.
But not, apparently, on yours or SD's
[13:27]
pharveyhow very odd [13:27]
CDotzactly. [13:28]
pharveywhat OS are you on? [13:28]
CDotdebian [13:28]
pharveyme too
albeit testing
SANITY FAIL, ? REDO FROM START
[13:28]
CDotpharvey: can you check the CacheTests too? cos AFAICT that is also a genuine error
and I can't understand why you were not seeing it
[13:29]
leikSvenDowideit, mail is sent. It's not big [13:29]
pharveyAll tests passed (20)
1..423
[13:29]
CDotpharvey: since svn up? [13:30]
pharveybut I'm missing BDB/memcached libs
let me try that
[13:30]
CDotshouldn't matter
All tests passed (20)
1..383
so given that you are missing some libs, how do you end up with 40 more asserts than me? :-/
[13:31]
pharveyAll tests passed (20)
1..383
does that help?
[13:31]
CDotshow me line 154 of CacheTests.pm, please? [13:32]
pharveyCDot: s/<meta[^>]*?foswiki\.SERVERTIME"[^>]*?>//gi; [13:33]
CDotok, revert my most recent checkin (which fixed that test) and run it again
12484
[13:33]
pharveyUnit test run Summary:
All tests passed (20)
1..423
[13:34]
***MartinCleaver has joined #foswiki [13:34]
CDotok, is line 154 now an $this->assert? [13:34]
pharveyyes [13:34]
CDotok, so tell me where in the core code foswiki.SERVERTIME gets added to the HTML?
cos I can't find it
and it's not in the HTML when I debug print it, so the test should fail
[13:35]
pharveyCDot: DefaultPreferences, EXPORTEDPREFERENCES [13:36]
CDotargh... so the test depends on SitePreferences...... [13:36]
pharveygotta run
SvenDowideit: btw, been watching your github, looking forward to figuring out how to properly splice your work back into my submodules :)
[13:37]
CDotnope, can't be that; I'm not overriding EXPORTEDPREFERENCES
CDot wonders what feature he's missing
[13:37]
pharveyif it's listed in EXPORTEDPREFERENCES, that should result in a <meta ...foswiki.SERVERTIME [13:38]
CDotCDot thanks pharvey for pointing him in that direction
it *is* listed in EXPORTEDPREFERENCES, but it's getting eaten somehow
[13:38]
pharveynp
I thought there was a .tmpl that uses it
g'night
[13:39]
***pharvey has quit IRC (Quit: ChatZilla 0.9.87 [Iceweasel 6.0/20110815162918]) [13:39]
CDotok, that's nasty. SERVERTIME is inserted iff it is in EXPORTEDPREFERENCES and IFF the FOSWIKI jquery plugin is installed, not otherwise.
so we have a core test that depends on a plugin
[13:47]
***MartinCleaver has quit IRC (Remote host closed the connection)
MartinCleaver has joined #foswiki
MartinCleaver has quit IRC (Changing host)
MartinCleaver has joined #foswiki
[13:48]
SvenDowideitwe have many such tests
thats why you're required to have a fully clean system to run the unit tests, and the pseudo-install and nightly tests generate that env
all other env's are 'tainted' by definition
[13:49]
CDotit's just one of those nasty situations where turning off a JQueryPlugin - the FOSWIKI plugin - cripples what is, on the face of it, a totally unrelated test.
yes, i know that using a different skin can have the same effect, it's just this was a particularly obscure relationship.
so I'm going to let my change stand. It makes the test robust to the JQueryPlugin not being enabled.
[13:54]
MichaelDaumCDot, the EXPORTEDPREFERENCES exports foswiki prefs to javascript; and as jquery is our javascript framework, it is no surprise that disabling it has this sideeffect. [13:59]
CDotMichaelDaum: it's a surprise that the CacheTests should assert a behaviour that is specific to the JQueryPlugin, and unrelated to the Cache code [14:00]
MichaelDaumwhich cache is it [14:01]
CDotdunno. yours?
the default.
[14:01]
***Alexander__ has quit IRC (Ping timeout: 258 seconds) [14:01]
MichaelDaumand it tests the content of a html page [14:01]
CDotyup [14:01]
MichaelDaumthere's absolutely no magic in here
pluguin -> addtozone -> renderzone -> cache
[14:02]
CDotno; i didn't say there was. I just said the test asserted a behaviour that was from another plugin, where it shouldn't have.
I removed that assert, and everything is fine now.
[14:03]
***Alexander__ has joined #foswiki [14:04]
MichaelDaumit obviously test an outcome on a different situation: plugin enabled vs plugin disabled
all of our tests could produce quite different markup depending on the plugins enabled. so tests don't make sure a specific plugin constellation is active while running. _that_ is the problem.
[14:04]
CDotfrom reading the test code, I think it is more likely to have been a cut-and-paste of the preceding lines, without thinking through all the implications
some tests *do* prepare their plugins configuration, but your are right, not all.
CDot is now fighting with a problem in the MetaCache
[14:06]
***dnavarro has joined #foswiki [14:16]
dnavarroI'm writing a small plugin to get the last changes since a certain time and return the changes in a JSON format [14:19]
CDotSvenDowideit: what is test_not_topics in Fn_FORMAT meant to test? [14:19]
dnavarroI'm registering a REST Handler with the default options
as http://foswiki.org/System/PerlDoc?module=Foswiki::Func#registerRESTHandler_40_36alias_44_92_38fn_44_37options_41
[14:19]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Func [ (Foswiki login) PerlDoc ] [14:19]
dnavarrobut it redirects me to a login page when trying to access the REST url
how do I make it publicly accessible?
[14:20]
CDotdnavarro: is 'rest' included in Foswiki::cfg{AuthScripts}? if so, take it out. [14:20]
SvenDowideitCDot: isn't that the non- topic thing you added to FORMAT?
where you added some hack to bypass checking and reading a topic
i think i later integrated that code better, but, iirc, its your feature :p
[14:22]
dnavarroCDot, I had it in AuthScripts, now it works, thanks! [14:23]
SvenDowideitmakes me think back to the idea that there should be core unit tests that work with just core :/ [14:24]
***gac410 has joined #foswiki [14:24]
CDotSvenDowideit: I don't think so. The problem I'm seeing is that the MetaCache is being asked to getRevisionInfo on a meta object for a web
it's processing search results, so I'm trying to undertand how a web Meta object could be returned by SEARCH
[14:24]
SvenDowideiti'm not sure what SEARCH has to do with Fn_FORMAT, except in passing [14:25]
CDotit is probably something I have changed in the store that is causing the problem, but I'm trying to understand the test so I can work it out [14:25]
gac410CDot: What release of perl was causing the failure with the ,v in the qw( ) on ConfigureTests? Here (perl v5.12.3) it just gives a warning. Tests pass and since the comma was legit, I ignored it. [14:25]
CDotme neither; hence my question :-)
gac410: 5.10.1
[14:25]
SvenDowideitok, CDot, do you recal that you added a non-topic feature to FORMAT [14:26]
CDotno
oh, wait, yes, sorry, I do
[14:26]
gac410Hm. they must have softened that error a bit in 5.12 Anyway, thanks for fixing it. [14:26]
SvenDowideitthat makes it hard, cos i keep assuming you can recal what you did :p [14:26]
CDotpffft.... /me has the memory of a goldfish [14:26]
SvenDowideiti'm reasonbly sure that test is from that feature [14:27]
CDotthank you for reminding me; that makes it clearer [14:27]
SvenDowideitsweet
http://foswiki.org/Development/PaulAlexanderWouldLikeToCheckIn
did we break fowiki.org Babar ?
[14:27]
gmcoh dear, don't tell me i have to fix things! [14:28]
SvenDowideitits the first time i've seen a 'would like to commit' topic escaped so much :/ [14:28]
gac410If a form redirects through the template login, all the fields are double encoded. I opened a task on that a while ago. [14:28]
Babarlovely
but yeah, I suspect it's what George says
[14:28]
SvenDowideitgmc: hummm :) [14:28]
Babargmc: no, I doubt it. I upgraded f.o to the latest apache and everything, put python 2.7 there, and everything seems to be running just fine. [14:28]
SvenDowideitgac410: aha - so we should get ph to ask pa aboot it :) [14:28]
CDotSvenDowideit: it's not a problm with search results; I was thrown out becuase the infocahce handling is in Foswiki::Search [14:29]
FoswikiBothttp://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Search [ (Foswiki login) PerlDoc ] [14:29]
CDotsomething is building a bogus infocache, somewhere :-/ [14:29]
SvenDowideitCDot: y, i'm hoping that MetaCache gets hidden inside Store2.0 [14:29]
gac410If that's what happened, it just confirms again the double-encoding issue. ArthurClemens confirmed it as well. And there is an opportunity there for topic corruption imho. [14:29]
SvenDowideitand infocache is a real shite thing that needs to die [14:30]
CDotwhy do you cache only topic objects? you got something against webs? [14:30]
SvenDowideitits a pre-de-optimisation due to bad impl
infocache predates me
[14:30]
CDotok. I have left quite a few bombs marked "pre-de-optimisation" around in my time, so no worries.
infocache was tch
[14:30]
***wdenk has quit IRC (Read error: Operation timed out) [14:31]
SvenDowideiti've been trying to work with it, but store2.0 allows me to kill meta, infocache and metacache
and harden up a few things :)
[14:31]
CDotexcellent [14:31]
***wdenk has joined #foswiki [14:31]
SvenDowideitespecially if no-one tells me i can't make our min version of perl 5.8.6 [14:31]
gac410Babar, are the prereqs for fastcgi or fcgid installed on f.o? Any reason not to enable for f.o? It would speed things up a bit esp. with our large .htpasswd file. [14:31]
SvenDowideitbetter way to speed up htpasswd file is not to use that stupid form
rather us a db - using httpadminuserscontrib
[14:32]
CDotgawd; it's coming from an expansion of $createusername [14:32]
SvenDowideitSvenDowideit is (in passing) surprised we use htpasswd) [14:32]
CDotI assume that's the name of the creator of the topic? [14:33]
gac410I'd guess I need to fit all my HtPasswdUser changes in to the contrib then. [14:33]
SvenDowideitmmm, i thught i changed that one :/
y
[14:33]
CDotbut if it *isn't* a topic, but is an "other thing" list..... [14:33]
SvenDowideitand if you're not putting $createusername in the format....
thats a wonderful pre-de-opt
[14:33]
CDotthe test has it in the format [14:34]
SvenDowideitsnigger [14:34]
CDotno problem with it being there, just trying to understand [14:34]
SvenDowideitmaybe i added that to test the problem
but i thought i'd changed the code to avoid doing the expansion when it was dumb
[14:34]
CDotmaybe. But in that case it shouldn't have passed. [14:35]
SvenDowideitdepends on the spec for the non-topic FORMAT [14:35]
CDotCDot is zeroing in on it. It's probably to do with rev numbers.
(obscurely enough)
[14:35]
SvenDowideitwhich should be in the VarFORMAT doc [14:35]
gac410Actually SvenDowideit I was thinking that another way to go about HtPasswd problems would be to establish subclasses - HtPasswd::File HtPasswd::Db ... so that the verification and cross-passwd type compatibility would be reusable. [14:35]
CDot$createusername on a non-topic format still shouldn't kablooie [14:35]
SvenDowideiter gac410 we already have subclassed
but once you don't use htpasswd, you're using something else
[14:39]
gac410HtPasswdUser ?? really I don't recall seeing anything in it. [14:40]
SvenDowideitCDot: all depends on what kablooie means :)
gac410: take a look at HttpAdminUsersContrib
in that you're not talking about a htpasswd file, we're talking about a user mapper and passwd manager replacement
the slowdown is not just the passwds, but also the mapping and group lookups
[14:40]
gac410I did - But it uses the CPAN code to maintaint the passwd and db - has none of the features to detect / permit migration between HtPasswd encodings. Very restricted. [14:41]
CDotah, getting it. The FORMAT code builds an infocache on list data that assumes it's a web.topic. If not, it creates a web-only inforcache that then crashes MetaCache when $createusername asks for the creator
CDot doesn't understand how this test could ever have passed (again)
[14:41]
SvenDowideityes, and your talking about adding code to our system that could just as easily be added to better and more useful code
ie - that cpan module
SvenDowideit is getting more worried about having spent 12 months assuming that the unit tests passing meant something :/
[14:42]
gac410I'll have to look at it again, but from first look, I thought the cpan module was not done very well. I don't remember now what the issue was - but the more I looked at it the more I didn't like what I saw at all. [14:43]
SvenDowideitbut as the girls just spent all day throwing tantrums because they were too tired to be willing to sleep, and finally have fallen asleep, i'm in no state to ponder the meaning of it
thing i liked the most about teh cpan module, is that what it produces is compatible with apache's mod_auth_* modules
so the db format alloed me to use apache auth
[14:44]
gac410what we produce is compatible as well - at least with some limited testing. I was able to flip between apache and template auth. [14:46]
SvenDowideitand it was a heck of a lot faster than using htpasswd files
we don't produce dbm, the other and database
we only produce simple flat slow files
thing i hate about it tho, is it seems to re-write the file every time it touches it - no idea why
i also wonder if its been maintained in a long time
but both those 2 issues are solveable
[14:46]
Babarhum, I was planning on installing fcgi
any recommandation on which one to chose? :)
[14:49]
SvenDowideithttps://rt.cpan.org/Public/Bug/Display.html?id=49931 [14:49]
gac410So HTTPDUserAdminContirb supports Crypt, and MD5 only. at least in our current impl. No SHA, or other formats. [14:49]
SvenDowideitok, gac410 i would like to know what you didn't like about the cpan module, cos there are good and bad points
and if things weigh up on the side of 'we could fix it' rather than 'we could write yet more code for us to maintain' maybe we should think about sending patches / taking it over..
[14:50]
gac410That was the major point. very limited encoding support. But I don't recall the rest - tbh that was some months ago now. [14:51]
SvenDowideitfor me, the point of using HTTPDUserAdminContirb, is to switch to using a real database [14:51]
gac410Agree - +1 on a real db. but invalidating all passwords for a site that wants to transition -1 -1 -1 [14:51]
SvenDowideitencoding support for file based really sin't important to me, unless we were to consider removing our code, which i wasn't originally thinking [14:52]
gac410So it's okay to have a site invalidate 10,000 passwords because they want to move {SHA1} passwords into a database? [14:52]
SvenDowideitso you haven't got an opinion on the code, just some (probly small) issue with missing code that we could trivially add?
given that we have code that does it, plugging it into the cpan module should be a pretty simple thing y?
[14:53]
gac410Well, joining yet another project, ... I've generally avoided touching cpan mods - either they work for me or I find another way - intimidated I guess. [14:54]
SvenDowideiti assumed that when you said 'I thought the cpan module was not done very well' you were commenting on the implementation of the module
which would be a reason for me to think twice
but if its just a somewhat trivial code change to add features, then its worth discussing with the author :)
as he's not dealt with bugs in a while
lets go see what unit tests there are, and if there are any newer cpan modules to replace it
[14:54]
gac410I don't know enough perl to comment on code quality - I was commenting on missing / limited features. Read docs and found that to do what I did for HtPasswdUser would need major surgery on cpan. [14:56]
SvenDowideitok, so you have read the code and feel that its not going to be easy?
cos i'm still not clear on what your objection is :(
[14:57]
gac410Didn't get that deep. To me changing a CPAN module was out. And it didn't support any encoding except CRYPT and MD5. And that was a problem. [14:58]
SvenDowideiti also can't recal what i felt about the impl atm :/
didi you read it to see how hard it would be to add your auto detection or no?
[14:58]
gac410It would be adding auto-detect and also adding all the other crypt types.
s/crypt/encoding/
[14:59]
SvenDowideityes, i realise, but did you look at what it might take to add the autodetection? [14:59]
gac410Anyway - I'm not planning on working on it at this point. No I didn't read their code. Didn't think i could change anything in CPAN and didn't want to make our own local copy.
to me, changing a CPAN module is like looking toward Mt. Everest. It's amazing that I've been able to contribute here. :-)
[15:00]
SvenDowideitok, sorry, i just kept reading that you thought the module wasn't done well / that it would be too hard to add XX and presumed that you'd meant that you'd looked at the code
cos imo its impossible to work out how hard something is to do from the docco
basically, if you had looked at the code and decided it was too hard, i'd simply trust you and move on
but as you've not, i'll read a little code and see myself
[15:02]
gac410Too hard - meaning to me jumping into someone else's CPAN module is insurmountable. Too hard for *me* politically etc. [15:02]
SvenDowideity, people reasons :)
thats why alias has lots of other people's modules in his svn repo
to allow people like you and me to update a small change, and he then tests, plays and releases
its a way to generate interest (for him) by allowing others to play
my issue with this cpan module, is that imo cpan really should have code that does this
cos its idiocy that projects like ours iplement our own
[15:03]
Sam687Did somebody know the HolidaylistPlugin? [15:04]
SvenDowideitthis one had the features i needed at the time
but it feels dead-ish
SvenDowideit ponders git pushing it to github :)
[15:05]
gac410yeah - looking at the bugs db - that module does indeed appear dying or dead. [15:07]
SvenDowideitthing is, it mostly works [15:07]
gac410we have lots of stuff that "mostly works" :dD [15:08]
SvenDowideitexactly
so not releaseing a new version doesn't mean no users, just no development
[15:08]
***Lavr_ has joined #foswiki
Lavr_ has quit IRC (Changing host)
Lavr_ has joined #foswiki
leik has quit IRC (Read error: Operation timed out)
[15:08]
SvenDowideitdead for me implies no users :/
tis a bit scary reading
http://search.cpan.org/~lds/
[15:09]
***harlan_ has joined #foswiki
_verboEse has joined #foswiki
[15:11]
Zenopus_ has joined #foswiki
wdenk has quit IRC (*.net *.split)
MartinCleaver has quit IRC (*.net *.split)
verboEse has quit IRC (*.net *.split)
Zenopus has quit IRC (*.net *.split)
Lavr has quit IRC (*.net *.split)
harlan has quit IRC (*.net *.split)
Lavr_ is now known as Lavr
Zenopus_ is now known as Zenopus
[15:18]
SvenDowideitmmm, tad scary - looks ot me like httpd::useradmin is more simplistic than our code, i wonder which is easier to make into 'good modern' perl [15:19]
gac410yeah - that was my thought - Didn't want to loose all the work Lavr did to ensure proper File consistency for the file users. He spent a lot of time on proper locking IIRC [15:21]
***MartinCleaver has joined #foswiki
MartinCleaver has quit IRC (Changing host)
MartinCleaver has joined #foswiki
[15:23]
SvenDowideitah, this uses flock and a loc file [15:23]
gac410If we refactored our code to separate out the File component, then add in SQL component. But didn't have time to dig into it at all. As long as the db format was compat with mod_auth_sql (or whatever the module is) ... [15:23]
SvenDowideitmore details to ponder [15:23]
***wdenk has joined #foswiki [15:24]
SvenDowideity, then the issue is working out enough tests
and then we get to - why are we not writing cpan modules
[15:24]
***ArthurClemens has quit IRC (Quit: Leaving...) [15:24]
gac410ignorance? laziness? [15:25]
SvenDowideitits so much more work to try to maintain our own duplicate code
but we've been doing it for soooo long :)
aka - comfort
[15:25]
gac410er... more work to maintain our own ... vs. challenge to maintain someone else's code, join a different project, [15:27]
SvenDowideitits all code reading :)
gads :/
so httpd::useradmin is from 1997 or before
and still works
thats alot of built in learning
[15:27]
gac410For what it does - yes. but crypt has become rather obsolete - part of what I was doing was making it less painful for users to migrate from the very insecure crypt encoding [15:29]
SvenDowideity, my pov is that the choice of encryption is a simple and trivial bit of the whole
and assuming i'm right, then the fact that this cpan module devotes all of 12 lines to it
suggests we should be ale to add that without too much effort
the question i'm now asking myself, is do we care about the other huge code base
and is it good enough code that the effort of learning it is worth it for me
[15:29]
gac410And politically how the heck do you take over or contribute to someone elses code - or do you just fork the CPAN module to HTTPD::UserAdmin-ReallyMaintained Like someone did for Net::SMTP::TLS-reallymaintained or whatever it was called.
(and which is just as broken as Net::SMTP::TLS )
[15:32]
SvenDowideitna, politics is trivial
at least, it is compared to being sure that you care to doit
goodness, that Realm.conf idea is 'nice' but takes alot of code
guess the next thing is to see if we cna separate our code better & and into a cpan module :)
:) and luck - my instant thought wrt our code, is that its not going to be too hard - cos it is probly simpler/better and more modren
just need to work out the pain oints, and the cpan module uses tie's, we use other weird things
[15:33]
***terceiro has joined #foswiki
Colas has quit IRC (Ping timeout: 258 seconds)
mark_doe has quit IRC (Read error: Connection reset by peer)
Sam687 has quit IRC (Quit: Leaving.)
ModAcOst has quit IRC (Remote host closed the connection)
MartinRowe has quit IRC (Quit: Leaving.)
[15:46]
Babargac410: the -reallymaintained modules are just from some asshole [16:00]
gac410yeah - that's what I figured - esp. since not much was done on it. [16:00]
Babarand yours was from Fayland [16:01]
***Alexander__ has quit IRC (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110902133214]) [16:01]
SvenDowideitBabar: is there a good copetent cpan module for talking to pwd files & db's competently?
it feels to me like its all too fragmented :/
[16:09]
Babaryou mean some abstraction module? [16:09]
SvenDowideitthat would be worst case, but y
think dbi, but for auth (read&write)
laters :)
[16:09]
***gac410 has left [16:10]
leik has joined #foswiki
mark_doe has joined #foswiki
[16:20]
terceiro has quit IRC (Remote host closed the connection) [16:27]
ArthurClemens has joined #foswiki [16:39]
dnavarro has quit IRC (Quit: Leaving) [16:48]
mark_doe has quit IRC (Ping timeout: 258 seconds) [16:57]
mark_doe has joined #foswiki [17:08]
.... (idle for 15mn)
mark_doe has quit IRC (Ping timeout: 258 seconds) [17:23]
uebera|| has joined #foswiki [17:30]
..... (idle for 21mn)
terceiro has joined #foswiki
milkman has quit IRC (Read error: Operation timed out)
[17:51]
milkman has joined #foswiki [18:02]
terceiro has quit IRC (Ping timeout: 276 seconds) [18:11]
MichaelDaum has quit IRC (Read error: Connection reset by peer) [18:25]
.... (idle for 17mn)
terceiro has joined #foswiki [18:42]
............ (idle for 59mn)
chdh has joined #foswiki
chdh has quit IRC (Client Quit)
GithubBot has joined #foswiki
[19:41]
GithubBot[foswiki] foswiki pushed 2 new commits to master: http://git.io/AjztkQ
[foswiki/master] Item11091: fix for unrelated failing test (Fn_FORMAT) - CrawfordCurrie
[foswiki/master] Item11091: correction of unrelated failing test (Fn_FORMAT) - CrawfordCurrie
[19:46]
***GithubBot has left [19:46]
FoswikiBothttp://foswiki.org/Tasks/Item11091 [ Item11091: RCS VC needs to handle mauled .txt better ] [19:46]
***MartinCleaver has quit IRC (Ping timeout: 276 seconds) [20:00]
harlan_ is now known as harlan
harlan has quit IRC (Changing host)
harlan has joined #foswiki
CDot has quit IRC (Quit: Leaving.)
MartinCleaver has joined #foswiki
MartinCleaver has quit IRC (Changing host)
MartinCleaver has joined #foswiki
GithubBot has joined #foswiki
[20:08]
GithubBot[foswiki] foswiki pushed 1 new commit to master: http://git.io/xx8ZHQ
[foswiki/master] Item9957: add release info text so we can release a code change Micha commited ~10months ago - SvenDowideit
[20:15]
***GithubBot has left [20:15]
FoswikiBothttp://foswiki.org/Tasks/Item9957 [ Item9957: Use of uninitialized value in foswiki.fcgi ] [20:16]
***Sam786 has joined #foswiki [20:18]
Sam786hellas [20:18]
***Sam901 has joined #foswiki [20:22]
Sam901Do somebody know the german foswiki irc channel address ? [20:23]
***Sam786 has quit IRC (Ping timeout: 252 seconds) [20:25]
Sam901 has quit IRC (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) [20:31]
............... (idle for 1h14mn)
GithubBot has joined #foswiki [21:45]
GithubBot[foswiki] foswiki pushed 1 new commit to master: http://git.io/LJ1RTw
[foswiki/master] Item11098: Update LinkedInPlugin to use revised api. Prior api no longer works. - SvenDowideit
[21:45]
***GithubBot has left [21:45]
FoswikiBothttp://foswiki.org/Tasks/Item11098 [ Item11098: Update LinkedInPlugin to use revised api. Prior api no longer works. ] [21:45]
......... (idle for 42mn)
***Rich_Morin has joined #foswiki [22:27]
Plazma-Rooolzso by default out of the box, is ldap support installed? or do i need to do something [22:35]
....... (idle for 31mn)
***ArthurClemens has quit IRC (Quit: Leaving...)
gac410 has joined #foswiki
[23:06]
Rich_Morin has left [23:17]
..... (idle for 23mn)
gac410Plazma-Rooolz: ldap is not installed by default. [23:40]
***pharvey has joined #foswiki [23:54]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)