#foswiki 2012-09-27,Thu

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

WhoWhatWhen
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/Nu0Zuw
[foswiki/master] Item11936: override umask when creating directory - GeorgeClark
[00:32]
***GithubBot has left [00:32]
FoswikiBothttp://foswiki.org/Tasks/Item11936 [ Item11936: Implement default htdigest protection for configure script ] [00:32]
.................. (idle for 1h29mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/8hMOSg
[foswiki/master] Item11983: Add a 1-second forgiveness on the time - GeorgeClark
[02:01]
***GithubBot has left [02:01]
FoswikiBothttp://foswiki.org/Tasks/Item11983 [ Item11983: prevent excessive calls into the revision system ] [02:01]
.................... (idle for 1h37mn)
flexibeastping pharvey [03:38]
........... (idle for 52mn)
SvenDowideityeah pharvey :p [04:30]
gac410SvenDowideit: - I released a Extensions/Testing version of LogDispatchContrib. Still needs work, but hopefully it can draw some feedback. [04:40]
SvenDowideit>:)
SvenDowideit says - twitter it
giggle
[04:41]
pharveyhi flexibeast
hi SvenDowideit
ping time round-trip 44 mins
[04:41]
SvenDowideitpharvey, i added createinfo. alias back, though i'm on the fence about its importance [04:41]
gac410Also, created Foswiki:Development.RedesignLoggerAPI [04:41]
FoswikiBothttp://foswiki.org/Development.RedesignLoggerAPI [ RedesignLoggerAPI ] [04:41]
SvenDowideitgac410, y, i've not read it, its on the cue :/ [04:42]
pharveySvenDowideit why? [04:42]
SvenDowideitonly 2000 odd tasks to review [04:42]
gac410:) [04:42]
SvenDowideitbecause 'createinfo.rev does not seem that much better than META:CREATEINFO.rev [04:42]
pharveyoh. I just thought it'd be good for consistency
but I see
[04:42]
SvenDowideityup, that was the only excuse i thought of
and it tipped me over the line to just do it
[04:43]
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/36t9dw
[foswiki/master] Item10678: finish up the query/search on createinfo (rev1's topicinfo) for 1.2.0 release - SvenDowideit
[04:45]
***GithubBot has left [04:45]
FoswikiBothttp://foswiki.org/Tasks/Item10678 [ Item10678: Allow SEARCH on CREATEINFO ] [04:45]
flexibeastHi pharvey. [04:50]
pharveyhowdy [04:51]
flexibeastSorry about trashing that README; thanks for the fix. :-) [04:51]
pharveyI have to go collect my daughter from school, be back in 20mins or so [04:51]
flexibeast*nod* [04:51]
pharveyoh, that's ok - obviously it wasn't important, nobody noticed :P [04:51]
***gac410 has left [04:58]
........................... (idle for 2h10mn)
Babargac410: indeed, VCStoreTests::verify_Inconsistent_getRevisionAtTime_VCStoreTests_RcsWrap passes individually. And also inside the suite. Odd.
SvenDowideit: I'm surprised noone did it before me, considering how easy it is :)
[07:08]
...... (idle for 28mn)
jastI've been thinking about locales some more...
I tend to think now that the right way to go is to just untaint everything that got tainted by locales, since users have no way to manipulate the locale definition anyway
[07:39]
CDotjast: the paranoid scenario is where a locale conversion, such as lc(), converts some seemingly meaningless jumble of characters into something dangerous
given perl's propensity for weird characters have fatal effects, that's not altogether unimaginable
[07:41]
jastyes, but the idea is that a proper locale (i.e. one not manipulated by bad people) won't magically turn word characters into punctuation, etc. [07:42]
CDotso long as you're sure.... [07:42]
Babarbut why would it matter? [07:42]
jastas an example, many things are tainted by a (\w+) match when locale is active [07:43]
Babaryou should know for all the stuff you untaint, what it should look like, and you can match accordingly [07:43]
jastthat's because locales define their own character class for that [07:43]
CDotBabar: I think jast means "untaint without an additional check" [07:43]
jastand if the locale is *sane*, that class will only contain actual alphanumeric chars and combining punctuation [07:43]
Babaryes. that's one of the first points of UTF8 conversion, iirc :) [07:43]
jasthere's the real problem [07:43]
Babarok, here I agree [07:43]
jastsuppose I want to call my topic ÖsterreichIstToll [07:44]
Babarso that you should be able to untaint anything that has just been tainted by a regex [07:44]
jastnow I have no choice but to use locale to test whether it starts with an uppercase character [07:44]
CDotright [07:44]
jastso I can't really do anything but categorically untaint the match [07:44]
CDoterm, if it's just a match, why do you have to untaint? [07:44]
Babarok, now I understand what you mean, and I agree [07:45]
jastwell [07:45]
CDotor are you drawing characters from the match [07:45]
jastsuppose I do 'ÖsterreichIstToll' =~ /^(\w+)$/ [07:45]
CDote.g. /(\W)(\w+)/ [07:45]
jast$1 is now tainted [07:45]
CDotonly if regex tainting is on, but yes [07:45]
jastthat's the thing
locale forces this to taint
[07:45]
CDoteven if regex tainting is off? [07:45]
jastregex tainting is only for the return values afaik
you mean "use re 'taint'", I suppose?
[07:46]
CDotyes [07:46]
Babaryeah, use re 'taint' is the opposite :) [07:46]
CDotno re 'taint' [07:46]
jastyeah, that only affects the values returned in list context
not the $1.. vars
[07:46]
CDotok, I thought it affected $1 as well [07:46]
jastbut locale affects both [07:46]
Babarwait...
'taint' mode is supposed to do exactly the opposite
[07:47]
jastWhen "use re 'taint'" is in effect, and a tainted string is the target of a regexp, the regexp memories (or values returned by the m// operator in list context) are tainted. [07:48]
Babarimagine $tainted is tainted. With use re 'taint', no match will untaint anything [07:48]
jastuh
I'm just gonna test it so we know for sure :)
[07:48]
CDotWhen use re 'taint' is in effect and a tainted string is the target of a regex, the numbered regex variables and values returned by the m// operator in list context are all tainted. [07:49]
Babarmeaning: ($x) = $tainted =~ /(.*)/; => $x is still tainted
yes. Everything will still be tainted if the input string is tainted
the question now is: what happens when locales are in use.
[07:49]
CDotbut that doesn't say what happens to $1 [07:49]
BabarI would assume 'taint' mode doesn't change anything
'the numbered regex variables' == $1
[07:49]
pharveyI seem to recall that locales affected whether lc/uc & friends tainted their results [07:50]
Babarpharvey: of course. [07:50]
CDotnormally no re 'taint' will $tainted =~ /^(.*)$/; $untainted = $1;
that's how you untaint, after all
[07:50]
BabarCDot: exactly
and "use re 'taint';" is to PREVENT that from happening accidentally
[07:50]
jasthmm, this is weird
echo ahoy | perl -e 'use Scalar::Util "tainted"; use re "taint"; my $a = <STDIN>; my ($b) = ($a =~ /^(\w+)$/); print tainted($b).tainted($1);'
[07:51]
CDotbut what happens with no re 'taint'; $tainted =~ /^(\w+)$/; $isthistainted = $1; [07:51]
jastoutputs '00'
given the docs, it should output '10'
well, except I forgot to enable tainting. doh.
[07:51]
BabarCDot: yes, this is tainted. [07:52]
jastright, with -T it outputs '10'
i.e. "use re 'taint'" keeps the memories tainted but the numbered variables are still untainted
[07:52]
Babar$ echo ahoy | perl -Te 'use Scalar::Util "tainted"; use re "taint"; my $a = <STDIN>; my ($b) = ($a =~ /^(\w+)$/); print tainted($b).tainted($1);'
10
of course, if you run perl without -T, there is not much point of checking for taintedness...
[07:52]
jastyeah, silly oversight on my part :) [07:53]
CDotno re 'taint' and $b and $1 are both untainted [07:53]
Babaralso... [07:53]
jastnow, interestingly, if I do the same thing with "use locale", I still get '10'
this goes against all the docs, really
and against what I've seen on the unicode branch
[07:54]
CDotuse locale and no re 'taint' and we're back to 10
snap
ok, so untainting is snafu
[07:54]
jastWhich of these modifiers [that decide whether regexes use locale] is in effect at any given point in a regular expression depends on a fairly complex set of interactions. [07:56]
CDotif you use locale, use re 'taint' / no re 'taint' has no effect [07:56]
jastwell that's great
Otherwise, "use locale" sets the default modifier to "/l"; and "use feature 'unicode_strings" or "use 5.012" (or higher) set the default to "/u" when not in the same scope as either "use locale" or "use bytes".
and, of course, there are differences between perl versions
[07:56]
CDotyes, and colourless green ideas sleep furiously too. [07:58]
Babar$ perl -Mlocale -MScalar::Util=tainted -Mre=taint -Tle'$a=shift; ($b) = ($a =~ /^(\w+)$/); print map{tainted($_)}($a,$b,$1)' foo
110
which we already established. So $1 isn't tainted. But...
$ perl -Mlocale -MScalar::Util=tainted -Mre=taint -Tle'$a=shift; ($b) = ($a =~ /^(\w+)$/); $c = $1; ($d) = $c =~ /(\w+)/; print map{tainted($_)}($a,$b,$c,$d,$1)' foo
11111
so $1 might not be tainted, but...
wait.
[07:58]
CDothuh? [07:59]
Babar($b) = ($a =~ /^(\w+)$/); print tainted($1);$c = $1;print tainted($c);print tainted($1); => 0 1 1
so assigning an untainted $1 taints both!
[08:00]
jastcompletely crazy
I can only assume that it's got something to do with how perl tries to not have taintedness affect output
let's try with a custom taint check
ah, that makes much more sense
perl -Mlocale -Mre=taint -Tle 'sub tainted { return !eval {eval("#".substr(join("", @_),0,0)); 1}; } $a = shift; ($b) = ($a =~ /^(\w+)$/); print map{tainted($_)}($a,$b,$1);' foo
so apparently Scalar::Util::tainted is broken
here's a better version:
perl -Mlocale -Mre=taint -Tle 'sub tainted { return !eval {eval("#".substr(join("", @_),0,0)); 1}?1:0; } $a = shift; ($b) = ($a =~ /^(\w+)$/); print map{tainted($_)}($a,$b,$1);' foo
now if you remove -Mlocale, everything is still tainted, so apparently re=taint affects the numbered vars, too
if you remove re=taint, too, it outputs 100
this is much saner
and with locale (no re=taint), everything is tainted as well
[08:02]
.... (idle for 15mn)
CDotAssert.pm has a TAINTED function as well.
best way to test taintedness is to let the interpreter fall over
looks to me like locale is causing taints where it shouldn't; but maybe I just haven't got my head round it yet.
[08:23]
jastthe reasoning behind locale operations tainting stuff is in section SECURITY of man perllocale
it really only applies if an attacker has sufficient access to change the system locale definitions
[08:28]
so, if Scalar::Util::tainted is unreliable, I suppose we should modify UNTAINTED? [08:34]
CDotwhy modify it?
UNTAINTED is a test; is it incorrect?
[08:37]
jastUNTAINTED calls Scalar::Util::tainted [08:37]
CDotdoes it? it didn't used to [08:37]
jastand that function seems to produce false negatives
it does
[08:37]
CDotsub UNTAINTED($) {
local ( @_, $@, $^W ) = @_;
my $x;
return eval { $x = $_[0], kill 0; 1 };
}
[08:38]
jasthmm, in the unicode branch it uses Scalar::Util [08:38]
CDotwe may have changed it there :-/ [08:38]
jastI'm just going to copy the implementation from man perlsec... it's shorter, too
normalizeWebTopicName is documented as keeping things tainted if the original $topic was tainted, but in fact it only does that if DEBUG is set
[08:39]
CDotI vaguely recall trying several different implementations before I landed on the kill version. Not all worked. [08:40]
jastI'm going to have to set up a playground with several perl versions
the implementation from the manpage is this:
return eval { eval( "#" . substr( $_[0], 0, 0 ) ); 1 } ? 1 : 0;
[08:41]
CDoty, I saw it [08:42]
..... (idle for 23mn)
jastI've now tested that implementation on perl 5.14.2, 5.10.1 and 5.8.8 [09:05]
CDotand? [09:11]
jastworks [09:14]
CDot:-) [09:17]
.... (idle for 19mn)
Babarbut I thought pharvey said he merged the changes from trunk into the unicode branch...
either he did a very sloppy job, or there is something fishy
[09:36]
jastthe change to UNTAINTED was made in the unicode branch, so a merge wouldn't have affected it
by CDot, incidentally ;)
[09:41]
pharveyoh, jast, working on unicode branch? Cool :) [09:46]
jastactually doing it is not so cool ;)
there are a lot of decisions to make
[09:47]
Babaroh, so CDot reverted his own change?! [09:49]
jastno
the unicode branch is what introduced the use of Scalar::Util::tainted in the first place
and the merge, of course, didn't magically revert that
[09:49]
Babaryes, but I'm wondering why CDot used Scalar::Util, when he had something better in trunk [09:50]
jastdefine 'better' ;) [09:50]
Babarmaybe because someone (me?) told him to? :) [09:50]
jastI suppose at that point nobody knew that Scalar::Util wasn't reliable
hmm, we'll keep limiting tag/macro names and such to ASCII, right?
[09:51]
pharveyjast, yes I think so - I've had that conversation with CDot before, IIRC. [09:52]
jastgood. fwiw I agree. [09:52]
CDotyes me too
Babar: yes, i think you did
[09:53]
pharveyjast: also, as somebody doing the work, you have a lot of say, too :) [09:53]
jast:) [09:53]
CDotor I found it and decided to try it. Frankly I don't remember. [09:53]
pharveyis jast able to push to unicode branche?
branch*. Stupid learning-to-type-again.
[09:54]
jasthmm, what's a good idiom to do a regex match without locale?
current: if ( ... =~ /...(\w+)/ ) { ... = $1 ... }
[09:55]
pharveythere are some good notes about this in tchrist's diatribe, I mean ... perl unicode checklist
\X comes to mind but, I'm a bit rusty and not in a perl place right now
oh, \X will match too much.
[09:58]
jastI suppose I can write out the char classes
or force everyone to use perl 5.14 :}
[10:00]
pharveylol
but seriously, if 5.14 makes unicode-foswiki feasible...
[10:01]
jastit's just much easier to write the regexes that way, because you have flags to influence their locale-ness
that said, ditching older perls is not really an option for my company :/
[10:02]
pharveyare we talking about \p{foo} classes? Doesn't perl 5.12 have them?
true.
[10:03]
jastno, we're talking about /foo/u and friends [10:03]
pharveyah [10:03]
jast(disables locales but still uses unicode for char classes, so no tainting) [10:03]
BabarCDot: I would tend to blame me :) [10:04]
***Babar sets mode: +oooo AndreU CDot gmc jast
Babar sets mode: +ooo Lynnwood padraig_lennon pharvey
[10:04]
jastyay! ;) [10:05]
pharveydoes it help if we break the unicode TODO list up a bit? IIRC the first phase was, let's just get unicode strings everywhere, and fix all the octet-centric code & resulting corruption bugs
oh, we're still talking about tainting
sorry, my brain is all over the place
and my eyes are bleeding
should probably do something non-screen related for a bit
[10:05]
CDotpharvey: bleeding eyes? You're a zombie? [10:05]
pharveyfor some reason I've taken to forgetting to blink when I use my datahand keyboard
it's weird, haha
my brain is weird.
[10:06]
jastall brains are like that [10:06]
Babarbut blinking is a reflex, you cannot forget a reflex. [10:06]
jastit's how you use them that makes the difference ;) [10:06]
CDotyikes; you need an eye-moistening spray. Optrex do one, it's really soothing. [10:06]
jastBabar: but you can (even inadvertently) train it out of yourself
and you can even do that in some contexts only
[10:06]
CDotBabar: you can't forget a reflex, but neurological damage can make you lose them. I have almost no reflexes in my feet for that reason. [10:07]
Babarin fact, you can force it not to blink... but after just a few seconds, my eyes already hurt [10:07]
pharveyI've never had this problem before. Don't know why learning a new keyboard would make me forget to blink. [10:07]
jasthmm, I'd suggest getting the blinking back... much cheaper than spray [10:07]
pharveyI'm sitting further away from the screen in my new setup. Hrm. [10:08]
BabarBabar needs a video of how you type using a datahand... let's ask YT [10:09]
pharveyBabar: I've mounted my datahands on to me chair, like this guy: http://octopup.org/img/computer/datahand/m/20021103-0000-P45Q9--Datahand--Chair.jpg
my*
[10:11]
jastI'm SO not interested in something like that :} [10:11]
pharveythe only reason I mounted them like that, is because I ended up with a pair that has the smallest palmrests for people with tiny hands. I have normal-sized hands, so I couldn't comfortably use it
with the units mounted on the chair, I can just completely relax all the muscles in my arms, and then hit the keys with little effort
[10:12]
Babarpharvey: down like that? Interesting [10:17]
pharveyyeah. I have a 30 minute reminder to pick my arms up & stretch, because if I get too absorbed into what I'm doing I end up barly moving my arms at all for hours, haha. [10:19]
jastFoswiki.pm should now be locale-clean
on to all the remaining files
[10:19]
pharvey1 down, 411 to go
did you get permission to push to unicode branch?
[10:20]
Babaras CDot is around, this shoudn't be an issue
also... should we move the master to github.com/foswiki ?
[10:21]
pharveysure, if it helps
Can we get the foswiki github account converted to an organizational one?
Would allow teams & admins (other than just yourself) to admin it :P
[10:22]
CDotpharvey: not has RSI since I started taiji. Replaced it with torn ligaments, damaged cartilage, and the occasional bruise instead. [10:24]
pharveylol, yeah. The doctor said I should pick something like that. [10:24]
Babarpharvey: it's not just myself, it's just CDot's self :p
and the foswiki organisation was converted to an organization eons ago... please keep up.
(and ignore my previous statement)
[10:26]
pharveyI've had the 's' in organisation beaten out of me in something I was writing a few months ago [10:28]
***ChanServ sets mode: +o MichaelDaum [10:28]
CDotyeah, but think positive. "Spot on" has taken hold in the USA, and their grammar nazis hate it. :-) [10:29]
pharveyhaha.
Our (English ex-pat) botanical greek/latin expert says Australian's preference for 'ise'-ing things is a French-ism imported and popularized via Macquarie who made the most popular "Australian" English dictionaries from about the 1970s
whereas most Australians think that '-ize' is an Americanism
[10:29]
CDoty, most brits think -ise is english and -ize is amerkin
in fact -ize is correct british english (if you are a language nazi, that is)
[10:32]
pharveywhen there's 6 reviewers there's bound to be one [10:33]
CDot:-) [10:34]
jastso I should actually use -ize?
who made all this so intangible?
btw, someone added the 'use locale' and 'BEGIN { locale stuff }' boilerplate several times to some files ;)
[10:34]
CDotjast: erm, the vikings, the saxons, the angles, the jutes, the normans - basically anyone who invaded Britain at any point - which means just about everyone.
y, I added the use locale in places where I found uc() etc calls
there were a few pre-existing; don't know why
[10:35]
jastI found one file which had 'use locale' three times in sequence :) [10:37]
CDothah! [10:37]
jastfavourite line of code so far: $howSmelly++; [10:38]
pharveyfantastic [10:48]
CDotfragrant, even [10:52]
CDot has gone to the hospital to get his knee poked and prodded. Back l8r. [10:57]
......... (idle for 42mn)
Babaroh jast... [11:39]
............... (idle for 1h14mn)
jastnoooo! UI::Manage::_isValidHTMLColor doesn't support the #abc syntax!
jast creates urgent task
oh man, /foo/i regexes taint matches, too
[12:53]
Babarof course. [12:57]
jastyeah, of course
but *blergh*
[12:57]
Babaryou should read ... hum... was it in the camel? [12:57]
jastwhy couldn't they just have made local tainting configurable?
*locale
[12:58]
BabarI was thinking about that too :) [13:01]
.......... (idle for 45mn)
jastI can now view the start page without locale errors [13:46]
..... (idle for 21mn)
gac410MichaelDaum: These 1-second timestamp errors... I wonder if it's a side-effect of the tests running on a VM, or other system contention. I get them only once in a great while, but they are common on the nightlies [14:07]
MichaelDaumgac410, yes I C what you mean. [14:08]
gac410I added a 1-second fuzz factor in one test. I'm wondering if I should just replicate that for all the tests - ensuring that the meta is +- 1 second [14:08]
MichaelDaumthe 1sec threshold was probably a too optimistic approach
basically the tests should check for an equal timestamp by capturing the current time just before the call generating a timestamp on its own.
... so far the theory
there is of course the forcedate param for some of the api ... not sure if that applies on the tests you are working on
another solution would be to "sanitize" the test string removing the random bits one can't expect beforehand s/date="\d+"/date="random"/
[14:08]
gac410Just looking at it. The VCStore test that faled yesterday was easy. It was just a single assert_equal ( date, metadate) The RCSHandler test that failed is a compare of the whole meta line :( Those are harder.
er... Don't we need to test that the date is set correctly?
[14:11]
MichaelDaumaaah ppfff ;)
no serious
I'd test for the correct date in exactly one test that takes care of it
and remove these bits from the equation everywhere else
[14:12]
gac410hm. Maybe a small bit of re-ordering. The one that failed last night sets the compare string first, then does a rcs->new() ... maybe flip that so the time is set after the addRevisionFromText. d
Probably chews up some cycles creating the new rcs instances.
[14:15]
hm.. I'm compiling chromium with parallel compiles, so my system is being hammered. RCSHandler ran with no errors after relocating that code. Trying it again running it under nice. Really slow. [14:24]
MichaelDaumheavy disk io is a good way to slow things down
not so much raw cpu jobs
[14:29]
gac410Well, RCSHandler and VCStore both passed. but not much disk activity.
They sure did run slower, but probably not the right type of slowdown.
[14:30]
MichaelDaumthe speedup you observed running all of the test is due to the lower numbers of rcs forks happening now
gotta run. telco.
[14:30]
gac410It sure makes a huge diff. [14:31]
MichaelDauml8tr [14:31]
.... (idle for 15mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/64nD7w
[foswiki/master] Item11983: reorder test to improve time check - GeorgeClark
[14:46]
***GithubBot has left [14:46]
FoswikiBothttp://foswiki.org/Tasks/Item11983 [ Item11983: prevent excessive calls into the revision system ] [14:46]
jasthow do I run the test suite? first thing I get when following instructions on Development.UnitTests is an exception from register/thanks (which I think is supposed to happen since it displays a message to a web user) [14:59]
gac410jast, I just cd to core/test/unit and run ../bin/TestRunner.pl -clean FoswikiSuite [15:00]
jaststill get the same thing...
OopsException(register/thanks web=>TemporaryAccessControlUsersWeb topic=>ScumBag params=>[A confirmation e-mail has been sent to scumbag@example.com,ScumBag])Error at /home/modellaachen/repos/_other/fw-unicode/core/lib/CPAN/lib/Error.pm line 151.
[15:01]
gac410And it stops there? [15:01]
jastyes [15:01]
gac410Any other output? Could you pastebin? [15:02]
jastsure
http://dpaste.org/HhG5A/
append raw/ to get without wrapping :)
[15:02]
gac410hm. That's a failure during the test setup, not the test itself. That's why things just stop. Registration is failing, [15:04]
jastyeah, I suspected as much
well, more work for tomorrow, then :)
[15:04]
gac410temporarily move your LocalSite.cfg aside, and run from core ./pseudo-install -A
That will create a minimal default LSC might be config related.
[15:05]
jastsame issue
I'll look at this more tomorrow, to see if it's something I broke.
[15:06]
gac410hm. So that fails without Locales set too. Do you know if registration works from the web. Maybe check that out tomorrow. [15:06]
jastit *seems* like it goes through
after all, the 'exception' says "we have sent a confirmation e-mail"
[15:07]
gac410Somethign strange. I *thought* that the 200 "error" from registration was normal. I'll look at the code a bit.
:P I have to checkout the unicode branch. Code doesn't line up.
jast, throwing that 200 thanks message is a normal end of registration. so it's something in FoswikiTestCase that doesn't like the results.
jast, it might just be an out-of-date test. FoswikiFnTestCase has conditional code to check the return of either "register" or "attention".
check out Foswikirev:15318
[15:07]
FoswikiBothttp://trac.foswiki.org/changeset/15318 [ Changeset 15318 – Foswiki ] [15:18]
......................... (idle for 2h4mn)
***imbezol_ has left [17:22]
....................... (idle for 1h54mn)
GithubBot[foswiki] FoswikiBot pushed 1 new commit to master: http://git.io/1pCdtg
[foswiki/master] Item11869: Remove check for years < 60 - GeorgeClark
[19:16]
***GithubBot has left [19:16]
FoswikiBothttp://foswiki.org/Tasks/Item11869 [ Item11869: Foswiki::Time::parseTime doesn't like 1901-1959 ] [19:17]
................... (idle for 1h34mn)
gac410Perl experts??? I'm confused by Item14860. In Foswiki.pm we've added "require v5.8.8" but also still have "use 5.006". If I'm reading this right, it says that we will at compile time only enable the v5.6 perl feature set, but at runtime will demand perl 5.8 ??? [20:51]
FoswikiBothttp://foswiki.org/Tasks/Item14860 [20:51]
gac410er. Try Foswikirev:14860 [20:52]
FoswikiBothttp://trac.foswiki.org/changeset/14860 [ Changeset 14860 – Foswiki ] [20:52]
gac410and configure does a "eval require 5.00503" [20:53]
BabarI don't get the first part of your question
the only difference between use and require is WHEN it is executed
use blah; is roughly equivalent to: BEGIN { require blah; import blah; } (import blah; == blah->import();)
and the BEGIN block is executed during the compilation phase, whereas the rest is executed at runtime
[20:58]
gac410I understand that for modules. The perldoc seems to imply it's the "use version" that does the enabling / disabling of features. or maybe it's just a bit vague. [21:00]
Babarso basically, what it means is that it will die one millisecond later with require v5.8.8 vs use 5.8.8; [21:00]
gac410So no reason to keep around the use 5.006. [21:01]
Babarah right. that's another side-effect. you're correct
but it's pretty stupid, as I doubt there are many features which could be used like that
[21:01]
gac410So if I understand what Sven did to Foswiki.pm, we are requiring 5.006 feature set, but 5.8.8 perl. Probably ought to just make it "use 5.8.8" [21:03]
BabarSven did both?! [21:03]
gac410YES
See the changeset I just posted 14860
[21:03]
Babarah no... [21:04]
gac410Hence my question / confusion :) [21:04]
Babarthe comments are crystal clear :)
he wanted to write only: require v5.8.8; because that's the "new" way to do it.
[21:05]
gac410But does that impact the "feature set" that perldoc talks about. [21:06]
Babarbut if you have a very ancient perl from the last century, this won't work and might create dragons.
hence he put before a "use 5.006" which would fail earlier and nicely would the perl not accept the v5 notation. (ergo, $[ < 5.006)
afaik, there are no features in 5.0.6 which are not enabled by default in 5.8.8 and later.
maybe perldoc feature, or http://perldoc.perl.org/feature.html can explain it better than I do?
[21:06]
gac410I was just reading that. [21:10]
Babarbasically, a feature is something in a more recent perl, not enabled by default so as not to break things
for example, say in 5.10. Say you had a sub called say, who can say what would happen to your program would say be enabled by default?
but, let's say you want to use say, you just "use v5.10", et voilà!
[21:10]
gac410Okay, so by specifing "use 5.006" he is making sure that new language features in 5.8, 5.10, 5.12 ... are all disabled. [21:11]
Babarno...
imagine you're running 5.12, and you want to use 'say'. All you have to do is to put "use v5.10", and then you can use 'say'.
if, in 5.16, say is made the default, and you still have "use v5.10" in your program, it will be a noop
does that make sense?
[21:12]
gac410but if you have "use 5.006" then say won't be available ... ah this is per module. So the use in Foswiki.pm ONLY is there, nothing to do with anything called [21:16]
jastcorrect
as with pretty much all pragmas
[21:16]
gac410So within the scope of Foswiki.pm, it locally is restricted to 5.006 features, overridden by feature specific use, like use unicode-strings or whatever the syntax is. (just trying for the concept)
So to change the subject. Looking more at time issues reported in Item11869. This is truly ugly. I fixed the year < 60 issue, but really, our date handling needs a complete facelift
[21:17]
FoswikiBothttp://foswiki.org/Tasks/Item11869 [ Item11869: Foswiki::Time::parseTime doesn't like 1901-1959 ] [21:19]
gac410perl Time::Local changes significantly in 5.8, 5.12, etc. so by depending on that, our time functions will give different results
Perl >= 5.12, 2-digit years are a +/- 50 year rolling horizon. 5.8, it gets really confused, jumping around in places. And Years > 100 < 999 are relative to Year 1900.
Of course spreadsheetplugin has to be different, uses a year 80 as the break, instead of +-50
I think ArthurClemens was on the right track to look at using the CPAN DateTime and DateTime::Format::* routines
[21:20]
Babarhum... they're both Dave Rolsky's, so... they should serve different purposes :) [21:30]
gac410DateTime does epoch -> human, and epoch manipulation. DateTime::Format does Human -> DateTime parsing
There are a lot of Format::* sub-modules. DateTime::Format::Flexible looks interesting.
[21:31]
Babarno no... I was talking about DateTime and Time::Local [21:34]
gac410Looks like it's Time::Local with lots of enhancements, it uses Time::Local for calculating the epoch. hm. I wonder if that means that it suffers from the same 2-digit year and year < 1000 "bugs".
Time::Local claims that the 2-digit year handling could be considered a bug.
[21:47]

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