Grokbase
x

Tux (h.m...@xs4all.nl)

Profile | Posts (717)

User Information

Display Name:Tux
Partial Email Address:h.m...@xs4all.nl
Posts:
717 total
716 in Perl 5 Porters
1 in PostgreSQL - Bugs

5 Most Recent

All Posts
1) Tux Re: Call for opinions on defering [perl #56444] until after 5.12
| +1 vote
Sounds VERY DWIM-ish :) ...
Perl 5 Porters
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
On Thu, 18 Feb 2010 11:39:58 +0100, Abigail <abigail@abigail.be> wrote:

> On Wed, Feb 17, 2010 at 04:28:58PM -0700, karl williamson wrote:
> > karl williamson wrote:
> >> Nicholas Clark wrote:
> >>> On Wed, Feb 17, 2010 at 09:57:13AM -0700, karl williamson wrote:
> >>>
> >>>> A complication is the added meaning of \N alone. (I don't think
> >>>> that this has been adequately commented in the pods.) And if my
> >>>> patch, or some other, isn't applied to 5.12, I think it might be
> >>>> advisable to defer adding this other meaning as well until we know
> >>>> more of the consequences and complications.
> >>>
> >>> And by "defer adding" you mean "in a stable release", which means
> >>> reversing
> >>> the code changes sufficient that \N is no longer parsed as "not-a-\n"?
> >>>
> >>
> >> Yes.
> >>
> >>> Meaning that you don't think that the semantics of code as-is is in a
> >>> good
> >>> consistent and therefore releasable state - either we should change
> >>> by backing
> >>> \N out of the parser, or change by going forwards with your patch?
> >>>
> >>> Nicholas Clark
> >>>
> >>
> >> \N meaning not-a-newline can break existing, though unlikely, code.
> >> Several examples have been pointed out in recent discussions of this.
> >> I'll reiterate one of them: There are essentially no constraints that
> >> Perl places on what '...' can be in \N{...}. I think that was a
> >> mistake, but nonetheless that is how it is. We document how it is
> >> possible to create a charnames translator, which can accept any '...'
> >> you want, including punctuation, even metacharacters. The new meaning
> >> of \N removes some of these, for example, \N{2} previously has meant
> >> the sequence whose name is 'two', but will soon mean instead to match
> >> two non-newlines. I don't think that this change is in the delta pod.
> >> Similarly \N{3,} is legal in 5.10 if your charnames translator accepts
> >> 'three-comma' as a legal name. But it will soon mean instead to match
> >> at least 3 non-newlines.
> >>
> >> I actually don't see these as sufficient cause to not go ahead with \N
> >> having additional meaning. But they should be documented. There is a
> >> change I would make to the existing implementation, though, and I did
> >> in my patch. And that is for something like the case \N{4F}. In the
> >> past that means to match the character whose name is 'four-f'. But the
> >> current 5.11.4 implementation has this mean match one non-newline
> >> followed by '{' followed by '4', followed by 'F', followed by '}'. I
> >> think that the implementation should use the named character
> >> interpretation unless the non-newline one makes as much or more sense,
> >> which isn't the case here. This is a simple fix to correct.
> >
> > In thinking about this some more, an alternative implementation of the
> > non-newline meaning of \N, would be to not take that meaning if the
> > charnames understands the construct. That is, \N followed by anything
> > besides a '{' would mean non-newline, as would '\N{' without a closing
> > '}", as both can't be legal \N{...} constructs. However, something of
> > the form \N{...} would be passed to charnames. If it accepted the
> > '...', then that meaning would be used. If it didn't, then the
> > non-newline meaning would be used. That way no existing code would be
> > broken.
> >
> > But consider that overloading \N means that someone who makes a typo no
> > longer gets feedback; instead the regex silently compiles into something
> > that wasn't at all what they intended.
>
>
> I suggest the following:
>
>   \N not followed by a {    ->   [^\n]
> \N{ but no following } -> Error (as it does in 5.10)
>   \N{...} && ... matches /^[0-9]+(?:,[0-9]*)?$/
>                             ->   [^\n]{...}
> Otherwise -> Pass to charnames.
>
>
> The only code that would break is code that defines charnames like "17",
> "23," and "5,19". Which I find it hard to believe if there's a lot of
> such code around.
>
> This way people making typos (unless you typo "loo" as "100") still get
> charnames feedback.

Sounds VERY DWIM-ish :)
+1

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
2) Tux Re: time.t 64bit fail
| +1 vote
perl-current 103 > grep LOCALTIME_ config.sh sLOCALTIME_max='974284125319987199'...
Perl 5 Porters
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
On Thu, 18 Feb 2010 01:21:27 -0800, Michael G Schwern
<schwern@pobox.com> wrote:

> H.Merijn Brand wrote:
> > Fails on 64bit HP-UX since not too long. Note that HP-UX 11.11 and up
> > are fine.
> >
> > ok 51 - year check, gmtime(-70368744177664)
> > ok 52 - year check, localtime(-70368744177664)
> > ok 53 - year check, gmtime(281474976710656)
> > not ok 54 - year check, localtime(281474976710656)
> > # Failed at t/op/time.t line 174
> > #      got "-2837665"
> > # expected "8921556"
> > ok 55 - year check, gmtime(4.5035996273705e+15)
> > not ok 56 - year check, localtime(4.5035996273705e+15)
> > # Failed at t/op/time.t line 174
> > #      got "1604708"
> > # expected "142715360"
> > ok 57 - year check, gmtime(70368744177664)
> > ok 58 - year check, localtime(70368744177664)
>
> Hrm.  2**46 is fine but 2**48 and 2**52 are not.
>
> What's your LOCALTIME_MIN and LOCALTIME_MAX please?

perl-current 103 > grep LOCALTIME_ config.sh
sLOCALTIME_max='974284125319987199'
sLOCALTIME_min='-62167219200'

> If LOCALTIME_MAX is over 2**48 could you try localtime(2**48) in C please
> and see if the system library is at fault?

tmp 107 > ./timecheck
  0:7fffffffffffffff:      1587287-03-17 15:30:07
  0:8000000000000000:   4293383948-10-16 08:29:52
======================
Sizeof time_t = 8
  8:7fffffffffffffff:      1587287-03-17 15:30:07
max:  0x7fffffffffffffff      9223372036854775807
  8:8000000000000000:   4293383948-10-16 08:29:52
min: -0x8000000000000000     -9223372036854775808


gmtime 2**48
======================
Sizeof time_t = 8
  8:   1000000000000:   4292129631-11-18 10:44:16
  0x0001000000000000          281474976710656

localtime 2**48
======================
Sizeof time_t = 8
  8:   1000000000000:   4292129631-11-18 10:44:16
  0x0001000000000000          281474976710656

> Also please compare what Configure's LOCALTIME_MAX is with what Time::y2038's
> SYSTEM_LOCALTIME_MAX is.

$ ./check_max
# Trying gmtime(67768036160140800) max... failed
# Trying gmtime(33884018080070400) max... success
# Trying gmtime(50826027120105600) max... failed
# Trying gmtime(42355022600088000) max... success
# Trying gmtime(46590524860096800) max... failed
:
:
# Trying gmtime(-42489252465868816) min... failed
# Trying gmtime(-42489252465868784) min... success
# Trying gmtime(-42489252465868800) min... success
# Trying gmtime(-42489252465868808) min... failed
# Trying gmtime(-42489252465868800) min... failed
# Trying gmtime(-42489252465868800) min... failed
# Trying localtime(67768036160140800) max... failed
# Trying localtime(33884018080070400) max... success
# Trying localtime(50826027120105600) max... failed
# Trying localtime(42355022600088000) max... success
:
:
# Trying localtime(-42489252465868816) min... failed
# Trying localtime(-42489252465868784) min... success
# Trying localtime(-42489252465868800) min... success
# Trying localtime(-42489252465868808) min... failed
# Trying localtime(-42489252465868800) min... failed
# Trying localtime(-42489252465868800) min... failed
# Trying mktime(42489252465868800) max... failed
# Trying mktime(21244626232934400) max... failed
# Trying mktime(10622313116467200) max... failed
# Trying mktime(5311156558233602) max... failed
:
:
# Trying mktime(46382541670799) max... success
# Trying mktime(46382541670817) max... failed
# Trying mktime(46382541670808) max... failed
# Trying mktime(46382541670804) max... failed
# Trying mktime(46382541670802) max... failed
# Trying mktime(46382541670801) max... failed
# Trying mktime(-42489252465868800) min... failed
# Trying mktime(-21244626232934400) min... failed
# Trying mktime(-10622313116467200) min... failed
# Trying mktime(-5311156558233600) min... failed
:
:
# Trying mktime(-2147483647) min... success
# Trying mktime(-2147483649) min... failed
# Trying mktime(-2147483648) min... success
# system time.h limits, as JSON
{   "gmtime":    { "max": 42489252465868800, "min": -42489252465868800 },
    "localtime": { "max": 42489252465868800, "min": -42489252465868800 },
    "mktime":    {
"max": { "tm_sec": 59, "tm_min": 59, "tm_hour": 1, "tm_mday": 27, "tm_mon": 2, "tm_year": 1469874, "tm_wday": 0, "tm_yday": 85, "tm_isdst": 0 },
"min": { "tm_sec": 52, "tm_min": 45, "tm_hour": 21, "tm_mday": 13, "tm_mon": 11, "tm_year": 1, "tm_wday": 5, "tm_yday": 346, "tm_isdst": 0 }
        }
}


> http://search.cpan.org/~mschwern/Time-y2038-20100216.1421_04/

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
3) Tux time.t 64bit fail
| +1 vote
Fails on 64bit HP-UX since not too long. Note that HP-UX 11.11 and up are fine. CPAN/perl-current...
Perl 5 Porters
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
Fails on 64bit HP-UX since not too long. Note that HP-UX 11.11 and up
are fine.

CPAN/perl-current 110 > ./perl -Ilib t/op/time.t
1..62
ok 1 - very basic time test
ok 2 - very basic times test
ok 3 - localtime() list context
ok 4 -   month day
ok 5 -   year
ok 6 - localtime(), scalar context
ok 7 - changes to $ENV{TZ} respected
ok 8 - gmtime() list conext
ok 9 -   month day
ok 10 -   year
ok 11 - gmtime() and localtime() agree what day of year
ok 12 - gmtime(), scalar context
ok 13 - gmtime(1073741824) list context
ok 14 -   scalar
ok 15 - gmtime(-34359738368) list context
ok 16 -   scalar
ok 17 - gmtime(-4294967296) list context
ok 18 -   scalar
ok 19 - gmtime(-2147483648) list context
ok 20 -   scalar
ok 21 - gmtime(1) list context
ok 22 -   scalar
ok 23 - gmtime(2147483648) list context
ok 24 -   scalar
ok 25 - gmtime(0) list context
ok 26 -   scalar
ok 27 - gmtime(4294967296) list context
ok 28 -   scalar
ok 29 - gmtime(549755813888) list context
ok 30 -   scalar
ok 31 - gmtime(-1) list context
ok 32 -   scalar
ok 33 - localtime(5000000000) list context
ok 34 -   scalar
ok 35 - localtime(-8589934592) list context
ok 36 -   scalar
ok 37 - localtime(-1296000) list context
ok 38 -   scalar
ok 39 - localtime(1163500000) list context
ok 40 -   scalar
ok 41 - localtime(1296000) list context
ok 42 -   scalar
ok 43
ok 44 - Ignore fractional time
ok 45
ok 46 - Ignore fractional time
ok 47 - year check, gmtime(-281474976710656)
ok 48 - year check, localtime(-281474976710656)
ok 49 - year check, gmtime(-4.5035996273705e+15)
ok 50 - year check, localtime(-4.5035996273705e+15)
ok 51 - year check, gmtime(-70368744177664)
ok 52 - year check, localtime(-70368744177664)
ok 53 - year check, gmtime(281474976710656)
not ok 54 - year check, localtime(281474976710656)
# Failed at t/op/time.t line 174
#      got "-2837665"
# expected "8921556"
ok 55 - year check, gmtime(4.5035996273705e+15)
not ok 56 - year check, localtime(4.5035996273705e+15)
# Failed at t/op/time.t line 174
#      got "1604708"
# expected "142715360"
ok 57 - year check, gmtime(70368744177664)
ok 58 - year check, localtime(70368744177664)
ok 59
ok 60
ok 61
ok 62


--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
4) Tux Re: Failures with bleadperl and NYTProf
| +1 vote
FYI Don just mailed me he will try to fix DWIW for C89 :)
Perl 5 Porters
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
On Tue, 16 Feb 2010 10:14:31 +0000, Tim Bunce <Tim.Bunce@pobox.com>
wrote:

> On Tue, Feb 16, 2010 at 08:40:09AM +0100, H.Merijn Brand wrote:
> > On Mon, 15 Feb 2010 18:08:00 -0600, Steve Peters
> > <steve@fisharerojo.org> wrote:
> >
> > > I've been doing some testing with bleadperl and ran into some bad
> > > results with NYTProf. Specifically, t/50-errno.t causes a
> > > segmentation fault on MAC OS X. I compiled my bleadperl with -des
> > > -Dusedevel -Duseithreads. Just wanted to see if anyone else had run
> > > into this while I start digging to see if I can reproduce on other
> > > OS's.
> >
> > On a side note: Devel::NYTProf depends on JSON::DWIW, which is not C89
> > compliant, and thus won't build on C89 compilers.
>
> Devel::NYTProf depends on JSON::Any. JSON::Any will prefer JSON::XS and then
> JSON over JSON::DWIW, so I think C89 isn't a significant issue for NYTProf.
>
> Hopefully JSON::DWIW will be fixed soon anyway
> https://rt.cpan.org/Public/Bug/Display.html?id=50302

FYI Don just mailed me he will try to fix DWIW for C89 :)

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
5) Tux Re: Failures with bleadperl and NYTProf
| +1 vote
It is not *your* package, but I hope that JSON::Any will change the test suite, which is extremely...
Perl 5 Porters
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
On Tue, 16 Feb 2010 10:14:31 +0000, Tim Bunce <Tim.Bunce@pobox.com>
wrote:

> On Tue, Feb 16, 2010 at 08:40:09AM +0100, H.Merijn Brand wrote:
> > On Mon, 15 Feb 2010 18:08:00 -0600, Steve Peters
> > <steve@fisharerojo.org> wrote:
> >
> > > I've been doing some testing with bleadperl and ran into some bad
> > > results with NYTProf. Specifically, t/50-errno.t causes a
> > > segmentation fault on MAC OS X. I compiled my bleadperl with -des
> > > -Dusedevel -Duseithreads. Just wanted to see if anyone else had run
> > > into this while I start digging to see if I can reproduce on other
> > > OS's.
> >
> > On a side note: Devel::NYTProf depends on JSON::DWIW, which is not C89
> > compliant, and thus won't build on C89 compilers.
>
> Devel::NYTProf depends on JSON::Any. JSON::Any will prefer JSON::XS and then
> JSON over JSON::DWIW, so I think C89 isn't a significant issue for NYTProf.
>
> Hopefully JSON::DWIW will be fixed soon anyway
> https://rt.cpan.org/Public/Bug/Display.html?id=50302

It is not *your* package, but I hope that JSON::Any will change the test
suite, which is extremely noisy when JSON::XS is not installed (it is
forbidden here), and JSON is.

I'm esp wondering why t/1[012]* issue those messages. Best one is this:

Found deprecated package JSON::Syck. Please upgrade to or XS at t/11-string-escape.t line 46

With JSON::Syck from CORE, it's hard to uninstall it from the user's
point of view

$ modlist -i JSON
Module name               Description                                  Version
JSON                                                                       2.17
JSON::Any                                                                  1.22
JSON::PP                                                                2.27000
JSON::PP5005                                                               1.09
JSON::PP56                                                                 1.08
JSON::PP58                                                                 1.03
JSON::Syck                                                                 0.30
$ perl -MV=JSON,JSON::Any,JSON::PP,JSON::PP5005,JSON::PP56,JSON::PP58,JSON::Syck
JSON
        /pro/lib/perl5/site_perl/5.10.1/JSON.pm: 2.17
JSON::Any
        /pro/lib/perl5/site_perl/5.10.1/JSON/Any.pm: 1.22
JSON::PP
        /pro/lib/perl5/site_perl/5.10.1/JSON/PP.pm: 2.27000
JSON::PP5005
        /pro/lib/perl5/site_perl/5.10.1/JSON/PP5005.pm: 1.09
JSON::PP56
        /pro/lib/perl5/site_perl/5.10.1/JSON/PP56.pm: 1.08
JSON::PP58
        /pro/lib/perl5/site_perl/5.10.1/JSON/PP58.pm: 1.03
JSON::Syck
        /pro/lib/perl5/site_perl/5.10.1/IA64.ARCHREV_0-LP64/JSON/Syck.pm: 0.30



t/00-load.t ........... 1/7 # Testing JSON::Any 1.22, Perl 5.010001, /pro/bin/perl
t/00-load.t ........... ok
t/01-JSON.t ........... 1/19 # Testing JSON.pm backend
t/01-JSON.t ........... ok
t/02-JSON-XS.t ........ skipped: JSON::XS not installed: Couldn't find a JSON package. Need XS, JSON, or DWIW at (eval 4) line 2
t/03-JSON-DWIW.t ...... skipped: JSON::DWIW not installed: Couldn't find a JSON package. Need XS, JSON, or DWIW at (eval 4) line 2
t/04-ENV.t ............ no_plan takes no arguments at t/04-ENV.t line 11.
t/04-ENV.t ............ ok
t/05-JSON-Syck.t ...... Found deprecated package JSON::Syck. Please upgrade to XS, JSON, or DWIW at (eval 4) line 2
t/05-JSON-Syck.t ...... ok
t/10_unicode.t ........ # XS: Couldn't find a JSON package. Need XS, JSON, or DWIW at t/10_unicode.t line 18
# handler is JSON
t/10_unicode.t ........ 1/? # DWIW: Couldn't find a JSON package. Need XS, or JSON at t/10_unicode.t line 18
Found deprecated package JSON::Syck. Please upgrade to or XS at t/10_unicode.t line 18
# Syck: JSON::Syck does not support utf8 at t/10_unicode.t line 19
t/10_unicode.t ........ ok
t/11-string-escape.t .. # XS: Couldn't find a JSON package. Need XS, JSON, or DWIW at t/11-string-escape.t line 46
Exiting subroutine via next at t/11-string-escape.t line 52.
# handler is JSON
t/11-string-escape.t .. 1/? # DWIW: Couldn't find a JSON package. Need XS, or JSON at t/11-string-escape.t line 46
Exiting subroutine via next at t/11-string-escape.t line 52.
Found deprecated package JSON::Syck. Please upgrade to or XS at t/11-string-escape.t line 46
t/11-string-escape.t .. ok
t/12-boolean.t ........ # XS: Couldn't find a JSON package. Need XS, JSON, or DWIW at t/12-boolean.t line 38
t/12-boolean.t ........ 1/24 # handler is JSON
# DWIW: Couldn't find a JSON package. Need XS, or JSON at t/12-boolean.t line 38
t/12-boolean.t ........ ok
All tests successful.


--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

spacer
Profile | Posts (717)
Home > People > Tux