Re: [perl #133541] Grammer bug vs
"_" is not an alphabetic character. It's allowed in "alnum" because that is by intent what is \w in other regex implementations, which includes "_". On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal wrote: > # New Ticket Created by Vijayvithal > # Please include the string: [perl #133541] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=133541 > > > > In the attached code, the only difference between the Grammars G0 and G1 > is the defination of token 'type' it is defined as in one case > and as in another. > > Since the string being matched is 'sc_in' both the alpha and alnum > tokens should have captured it. But we see the following result on > execution > > === Example== > Nil > === Example== > 「sc_in bar」 > ruport => 「sc_in」 > type => 「sc_in」 > alpha => 「s」 > alpha => 「c」 > alpha => 「_」 > alpha => 「i」 > alpha => 「n」 > > > Perl Version is > > This is Rakudo Star version 2018.06 built on MoarVM version 2018.06 > implementing Perl 6.c. > > > > -- > Vijayvithal > Dyumnin Semiconductors > -- brandon s allbery kf8nh allber...@gmail.com
Re: [perl #133541] Grammer bug vs
"_" is not an alphabetic character. It's allowed in "alnum" because that is by intent what is \w in other regex implementations, which includes "_". On Thu, Sep 27, 2018 at 10:47 PM Vijayvithal wrote: > # New Ticket Created by Vijayvithal > # Please include the string: [perl #133541] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=133541 > > > > In the attached code, the only difference between the Grammars G0 and G1 > is the defination of token 'type' it is defined as in one case > and as in another. > > Since the string being matched is 'sc_in' both the alpha and alnum > tokens should have captured it. But we see the following result on > execution > > === Example== > Nil > === Example== > 「sc_in bar」 > ruport => 「sc_in」 > type => 「sc_in」 > alpha => 「s」 > alpha => 「c」 > alpha => 「_」 > alpha => 「i」 > alpha => 「n」 > > > Perl Version is > > This is Rakudo Star version 2018.06 built on MoarVM version 2018.06 > implementing Perl 6.c. > > > > -- > Vijayvithal > Dyumnin Semiconductors > -- brandon s allbery kf8nh allber...@gmail.com
Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever
And in the cases where it "works", the buffer is larger. Which runs the risk of consuming all available memory in the worst case, if someone tries to "make it work" with an expanding buffer. The fundamental deadlock between processes blocked on I/O is not solved by buffering. Something needs to actually consume data instead of blocking, to break the deadlock. Perl 5 and Python both call this the open3 problem. On Wed, Mar 7, 2018 at 6:42 PM, Timo Paulssen wrote: > This is a well-known problem in IPC. If you don't do it async, you risk > the buffer you're not currently reading from filling up completely. Now > your client program is trying to write to stderr, but can't because it's > full. Your parent program is hoping to read from stdin, but nothing is > arriving, and it never reads from stderr, so it's a deadlock. > > Wouldn't call this a rakudo bug. > > > On 07/03/18 23:04, Christian Bartolomaeus via RT wrote: > > On Fri, 10 Feb 2017 23:48:54 -0800, barto...@gmx.de wrote: > >> FWIW that hangs on FreeBSD as well (maybe not too much a surprise, > >> given the relationship of the OSes). > > Hmm, looks like it hangs on Linux too -- with more than 224000 bytes on > my machine: > > > > $ perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*ERR.print("8" x > 224001);|,:out,:err); say $proc.out.slurp' ## hangs > > ^C > > $ perl6 --version > > This is Rakudo Star version 2017.10 built on MoarVM version 2017.10 > > implementing Perl 6.c. > > $ uname -a > > Linux p6 3.2.0-4-amd64 #1 SMP Debian 3.2.96-2 x86_64 GNU/Linux > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #127682] [OSX] writing more than 8192 bytes to IO::Handle causes it to hang forever
And in the cases where it "works", the buffer is larger. Which runs the risk of consuming all available memory in the worst case, if someone tries to "make it work" with an expanding buffer. The fundamental deadlock between processes blocked on I/O is not solved by buffering. Something needs to actually consume data instead of blocking, to break the deadlock. Perl 5 and Python both call this the open3 problem. On Wed, Mar 7, 2018 at 6:42 PM, Timo Paulssen wrote: > This is a well-known problem in IPC. If you don't do it async, you risk > the buffer you're not currently reading from filling up completely. Now > your client program is trying to write to stderr, but can't because it's > full. Your parent program is hoping to read from stdin, but nothing is > arriving, and it never reads from stderr, so it's a deadlock. > > Wouldn't call this a rakudo bug. > > > On 07/03/18 23:04, Christian Bartolomaeus via RT wrote: > > On Fri, 10 Feb 2017 23:48:54 -0800, barto...@gmx.de wrote: > >> FWIW that hangs on FreeBSD as well (maybe not too much a surprise, > >> given the relationship of the OSes). > > Hmm, looks like it hangs on Linux too -- with more than 224000 bytes on > my machine: > > > > $ perl6 -e 'my $proc = run($*EXECUTABLE, "-e", q| $*ERR.print("8" x > 224001);|,:out,:err); say $proc.out.slurp' ## hangs > > ^C > > $ perl6 --version > > This is Rakudo Star version 2017.10 built on MoarVM version 2017.10 > > implementing Perl 6.c. > > $ uname -a > > Linux p6 3.2.0-4-amd64 #1 SMP Debian 3.2.96-2 x86_64 GNU/Linux > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132441] [SEVERE][WINDOWS][IO] IO::Handle.read-internal cannot handle fancy Unicode chars on TTY handles
On Tue, Dec 26, 2017 at 12:15 AM, Brandon Allbery via RT < perl6-bugs-follo...@perl.org> wrote: > IIRC this is known, and not really fixable. It's not even cmd.exe but a > Windows console mode limitation. > Come to think of it, there should be existing mention of this on the moarvm bug tracker (ticket may have been closed as unfixable). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132441] [SEVERE][WINDOWS][IO] IO::Handle.read-internal cannot handle fancy Unicode chars on TTY handles
On Tue, Dec 26, 2017 at 12:15 AM, Brandon Allbery via RT < perl6-bugs-follo...@perl.org> wrote: > IIRC this is known, and not really fixable. It's not even cmd.exe but a > Windows console mode limitation. > Come to think of it, there should be existing mention of this on the moarvm bug tracker (ticket may have been closed as unfixable). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132441] [SEVERE][WINDOWS][IO] IO::Handle.read-internal cannot handle fancy Unicode chars on TTY handles
On Mon, Dec 25, 2017 at 1:07 AM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > On Thu, 16 Nov 2017 09:53:46 -0800, c...@zoffix.com wrote: > > On 2017.07 on Win7 with 65001 code page enabled, the » char doesn't > > show up at all. Just seems to get removed from the content if I paste > > it into the terminal. > > Starting to think this might be a limitation of cmd.exe. Though strangely, > I'm failing to find anyone mentioning this problem on Google... > IIRC this is known, and not really fixable. It's not even cmd.exe but a Windows console mode limitation. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132441] [SEVERE][WINDOWS][IO] IO::Handle.read-internal cannot handle fancy Unicode chars on TTY handles
On Mon, Dec 25, 2017 at 1:07 AM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > On Thu, 16 Nov 2017 09:53:46 -0800, c...@zoffix.com wrote: > > On 2017.07 on Win7 with 65001 code page enabled, the » char doesn't > > show up at all. Just seems to get removed from the content if I paste > > it into the terminal. > > Starting to think this might be a limitation of cmd.exe. Though strangely, > I'm failing to find anyone mentioning this problem on Google... > IIRC this is known, and not really fixable. It's not even cmd.exe but a Windows console mode limitation. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)
On Sat, Oct 21, 2017 at 12:12 PM, Brad Gilbert via RT < perl6-bugs-follo...@perl.org> wrote: > On Sat, 21 Oct 2017 08:18:46 -0700, alex.jakime...@gmail.com wrote: > > https://irclog.perlgeek.de/perl6-dev/2017-10-21#i_15334639 > > > > I' think we should test that both are listed, and we can close the > > ticket. > > > > I don't think we should force all future implementations to add BUILDALL. > Being listed in the methods does not mean part of the spec. I mean, if it did then .^methods wouldn't be allowed to show user added methods either. Or did you mean something else here? in which case you need to explain it better. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)
On Sat, Oct 21, 2017 at 12:12 PM, Brad Gilbert via RT < perl6-bugs-follo...@perl.org> wrote: > On Sat, 21 Oct 2017 08:18:46 -0700, alex.jakime...@gmail.com wrote: > > https://irclog.perlgeek.de/perl6-dev/2017-10-21#i_15334639 > > > > I' think we should test that both are listed, and we can close the > > ticket. > > > > I don't think we should force all future implementations to add BUILDALL. > Being listed in the methods does not mean part of the spec. I mean, if it did then .^methods wouldn't be allowed to show user added methods either. Or did you mean something else here? in which case you need to explain it better. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132302] Str.trans grabs callers $/ for unknown reason
On Sat, Oct 14, 2017 at 1:15 PM, Zoffix Znet wrote: > 2) Why does Str.trans grabs caller's $/ in the first place? The commit > that added >it seems to claim to fix something that isn't meant to work as tr/// > replaces per >char and doesn't use special regex syntax (basically, author of the > commit seems >to be confusing it with s///). > Are you sure this isn't just a copypasto? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132302] Str.trans grabs callers $/ for unknown reason
On Sat, Oct 14, 2017 at 1:15 PM, Zoffix Znet wrote: > 2) Why does Str.trans grabs caller's $/ in the first place? The commit > that added >it seems to claim to fix something that isn't meant to work as tr/// > replaces per >char and doesn't use special regex syntax (basically, author of the > commit seems >to be confusing it with s///). > Are you sure this isn't just a copypasto? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132268] Floating point anomalies
On Fri, Oct 13, 2017 at 4:59 AM, wrote: > It's bad enough that perl5 and perl6 round to 15 decimal digits of > precision, but at least perl5's printf will give me 17 decimal digits when > I ask it to (and I think perl6 should do the same): > I am wondering if youve talked to any Intel FP engineers. 17 decimal digits sounds like you expect full internal 80-bit precision even if it's not in an internal register. Good luck. (gcc does have ways of doing this on sufficiently recent processors. msvc does NOT. So, you've just demanded a Windows vs. Unix difference be enshrined in the language?) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132268] Floating point anomalies
On Fri, Oct 13, 2017 at 4:59 AM, wrote: > It's bad enough that perl5 and perl6 round to 15 decimal digits of > precision, but at least perl5's printf will give me 17 decimal digits when > I ask it to (and I think perl6 should do the same): > I am wondering if youve talked to any Intel FP engineers. 17 decimal digits sounds like you expect full internal 80-bit precision even if it's not in an internal register. Good luck. (gcc does have ways of doing this on sufficiently recent processors. msvc does NOT. So, you've just demanded a Windows vs. Unix difference be enshrined in the language?) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132268] Floating point anomalies
On Thu, Oct 12, 2017 at 5:31 AM, wrote: > Perl6's printf() function looks a little suspect - though I might be > missing > something here. > > As with perl5's say function, doubles are rounded to 14 decimal digits of > precision, so we get: > > $ perl6 -e 'say 1.001e0;' > 1 > > $ perl -E 'say 1.001e0;' > 1 > > On perl5 we can get to see a more accurate rendition of the base 10 value > I question your use of 'accurate'. The low bits are *never* accurate. They're trying to be more 'precise', but the value they have will depend strongly on how exactly the value was calculated, and there are entirely reasonable design decisions that can cause them to differ between implementations. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132268] Floating point anomalies
On Thu, Oct 12, 2017 at 5:31 AM, wrote: > Perl6's printf() function looks a little suspect - though I might be > missing > something here. > > As with perl5's say function, doubles are rounded to 14 decimal digits of > precision, so we get: > > $ perl6 -e 'say 1.001e0;' > 1 > > $ perl -E 'say 1.001e0;' > 1 > > On perl5 we can get to see a more accurate rendition of the base 10 value > I question your use of 'accurate'. The low bits are *never* accurate. They're trying to be more 'precise', but the value they have will depend strongly on how exactly the value was calculated, and there are entirely reasonable design decisions that can cause them to differ between implementations. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132242] [BUG] Proc::Async running with yes command returns superfluous output and hangs
On Sat, Oct 7, 2017 at 10:21 PM, Itsuki Toyota wrote: > See the following result: > > $ perl6 -e 'my $proc = Proc::Async.new("yes"); > $proc.stdout.head(1).tap(&say); await $proc.start;' > > y > y > y > y > y > y > y > y > ... > > > I think tap(&say) should output just a 'y' char and completes its work. > No guarantee it's line based, nor do pipes deliver output in lines. You wanted a .lines in there to 'rechunk' the output; otherwise I suspect you get blocks based on the size of am OS pipe buffer, or similar. https://docs.perl6.org/type/Supply#method_lines -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132242] [BUG] Proc::Async running with yes command returns superfluous output and hangs
On Sat, Oct 7, 2017 at 10:21 PM, Itsuki Toyota wrote: > See the following result: > > $ perl6 -e 'my $proc = Proc::Async.new("yes"); > $proc.stdout.head(1).tap(&say); await $proc.start;' > > y > y > y > y > y > y > y > y > ... > > > I think tap(&say) should output just a 'y' char and completes its work. > No guarantee it's line based, nor do pipes deliver output in lines. You wanted a .lines in there to 'rechunk' the output; otherwise I suspect you get blocks based on the size of am OS pipe buffer, or similar. https://docs.perl6.org/type/Supply#method_lines -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #126757] [LTA] error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)
Is it possible to signal to the error handler that it is talking about a value somewhere instead of the program source, at least? Even if you can't reasonably say what value where? On Sat, Oct 7, 2017 at 5:18 PM, Aleks-Daniel Jakimenko-Aleksejev via RT < perl6-bugs-follo...@perl.org> wrote: > “Couldn't the confusing wording be fixed without additional information?” > > Yes. But how? We can't *remove* this hint because sometimes it is super > useful. > > On 2017-10-06 11:13:34, sml...@gmail.com wrote: > > On Wed, 04 Oct 2017 22:10:22 -0700, alex.jakime...@gmail.com wrote: > > > To produce an error message that is more precise we'll need more > > > information > > > than just a line number, but we don't have that during the run time. > > > > Couldn't the confusing wording be fixed without additional > > information? > > > > As I understand it, the problem with the current message is that the > > > > in '⏏~' (indicated by ⏏) > > > > part leads people to think it's referring to a position in the source > > code, when it is actually referring to a position in a string. > > Especially because the "in block ... in file ... at line ..." line > > comes directly after it. > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #126757] [LTA] error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)
Is it possible to signal to the error handler that it is talking about a value somewhere instead of the program source, at least? Even if you can't reasonably say what value where? On Sat, Oct 7, 2017 at 5:18 PM, Aleks-Daniel Jakimenko-Aleksejev via RT < perl6-bugs-follo...@perl.org> wrote: > “Couldn't the confusing wording be fixed without additional information?” > > Yes. But how? We can't *remove* this hint because sometimes it is super > useful. > > On 2017-10-06 11:13:34, sml...@gmail.com wrote: > > On Wed, 04 Oct 2017 22:10:22 -0700, alex.jakime...@gmail.com wrote: > > > To produce an error message that is more precise we'll need more > > > information > > > than just a line number, but we don't have that during the run time. > > > > Couldn't the confusing wording be fixed without additional > > information? > > > > As I understand it, the problem with the current message is that the > > > > in '⏏~' (indicated by ⏏) > > > > part leads people to think it's referring to a position in the source > > code, when it is actually referring to a position in a string. > > Especially because the "in block ... in file ... at line ..." line > > comes directly after it. > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132194] $*PROGRAM-NAME is not assignable / does not change process's name
On Sun, Oct 1, 2017 at 12:35 PM, Zoffix Znet wrote: > $*PROGRAM-NAME is supposed to be a replacement for Perl 5's $0, but it > doesn't work that way. > > What I'd expect to work: > > use v6; > $*PROGRAM-NAME = 'foo'; > This is not portable and not reliable --- although it will probably work on the limited set of systems moarvm/rakudo currently run on. But the linked ticket is not quite right either: even on Unix-likes that support it, the result would be shown by 'ps' as something like 'foo [moarvm]' (exact format will depend on OS and/or 'ps' implementation). This is forced for security-related reasons, and you can't override the process's execname to control the part in brackets. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132194] $*PROGRAM-NAME is not assignable / does not change process's name
On Sun, Oct 1, 2017 at 12:35 PM, Zoffix Znet wrote: > $*PROGRAM-NAME is supposed to be a replacement for Perl 5's $0, but it > doesn't work that way. > > What I'd expect to work: > > use v6; > $*PROGRAM-NAME = 'foo'; > This is not portable and not reliable --- although it will probably work on the limited set of systems moarvm/rakudo currently run on. But the linked ticket is not quite right either: even on Unix-likes that support it, the result would be shown by 'ps' as something like 'foo [moarvm]' (exact format will depend on OS and/or 'ps' implementation). This is forced for security-related reasons, and you can't override the process's execname to control the part in brackets. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132185] [LTA] file tests and Failure do not interact as expected
On Sat, Sep 30, 2017 at 4:35 PM, Sam S. via RT wrote: > To the extent that you're basing your expectations on the fact that a Perl > 5 `undef` can be used in ways that a Perl 6 `Failure` cannot (without > blowing up), well, that's just a matter of having to unlearn Perl 5 (or > other programming languages) while learning Perl 6... :) > So I included at least one discussion in the ticket that was utterly pointless and left unread. At this point I'm just going to assume only half-exposing the underlying mechanism is considered a feature and I need to use a different language when it's not. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132185] [LTA] file tests and Failure do not interact as expected
On Sat, Sep 30, 2017 at 4:35 PM, Sam S. via RT wrote: > To the extent that you're basing your expectations on the fact that a Perl > 5 `undef` can be used in ways that a Perl 6 `Failure` cannot (without > blowing up), well, that's just a matter of having to unlearn Perl 5 (or > other programming languages) while learning Perl 6... :) > So I included at least one discussion in the ticket that was utterly pointless and left unread. At this point I'm just going to assume only half-exposing the underlying mechanism is considered a feature and I need to use a different language when it's not. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132148] [RFC] native 'str' type unspecced, undocumented, and ill-defined
Possibly the right thing here is for perl 6 to reserve the name for implementations, and otherwise leave it unspecced. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132148] [RFC] native 'str' type unspecced, undocumented, and ill-defined
Possibly the right thing here is for perl 6 to reserve the name for implementations, and otherwise leave it unspecced. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132156] [LTA] Suggest polymod for bases > 36 (9123607.base(37))
On Mon, Sep 25, 2017 at 10:53 AM, Aleks-Daniel Jakimenko-Aleksejev via RT < perl6-bugs-follo...@perl.org> wrote: > * add a named arg for the alphabet, so that the user can provide any > character > set he wants > I'm in favor of the original suggestion: point the user to polymod. One way that is used in the wild for this is space separated and 37 => AA; I don't think you will fit that kind of scheme (and note that there are still questions as to where to go after AZ!) into a single simple interface. Moreover, anyone faced with this will likely need to customize to match whatever they are working with that requires it anyway, so they would probably end up punting to polymod regardless. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132156] [LTA] Suggest polymod for bases > 36 (9123607.base(37))
On Mon, Sep 25, 2017 at 10:53 AM, Aleks-Daniel Jakimenko-Aleksejev via RT < perl6-bugs-follo...@perl.org> wrote: > * add a named arg for the alphabet, so that the user can provide any > character > set he wants > I'm in favor of the original suggestion: point the user to polymod. One way that is used in the wild for this is space separated and 37 => AA; I don't think you will fit that kind of scheme (and note that there are still questions as to where to go after AZ!) into a single simple interface. Moreover, anyone faced with this will likely need to customize to match whatever they are working with that requires it anyway, so they would probably end up punting to polymod regardless. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132035] AutoReply: [LTA] temp on an undeclared dynamic variable produces a not very helpful error
Or maybe it's not that tricky after all; seems the Failure is actually a useful one (X::Dynamic:NotFound), so introspection of the Failure would reveal the issue. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132035] AutoReply: [LTA] temp on an undeclared dynamic variable produces a not very helpful error
Or maybe it's not that tricky after all; seems the Failure is actually a useful one (X::Dynamic:NotFound), so introspection of the Failure would reveal the issue. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132030] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout
On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT < perl6-bugs-follo...@perl.org> wrote: > Failing to close output handles has been clearly documented (and yes, > documented well before the recent buffering change) as something that can > cause data loss. Default output buffering just makes it quite a lot more > likely to show up. > > While there will be some ecosystem fallout like this, unfortunately I > don't think it's avoidable. If we whip out the patch that turns output > buffering on by default for non-TTYs for this release, then when will we > include it? The longer we leave it, the more painful it will be, because > more code will be written that is careless with handles. > > I don't think "leave it off by default" is a good option either, otherwise > we get to spend the next decade hearing "Perl 6 I/O is slow" because it'd > be one of the only languages that doesn't buffer its output without an > explicit flag being passed to enable that (which nearly nobody doing quick > benchmarks will know to use). > Are we missing something to flush/close handles at exit? Leaving it to a GC that may not finalize before exit is not really an option. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #132030] [REGRESSION] Broken Text::CSV tests and possibly other ecosystem fallout
On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT < perl6-bugs-follo...@perl.org> wrote: > Failing to close output handles has been clearly documented (and yes, > documented well before the recent buffering change) as something that can > cause data loss. Default output buffering just makes it quite a lot more > likely to show up. > > While there will be some ecosystem fallout like this, unfortunately I > don't think it's avoidable. If we whip out the patch that turns output > buffering on by default for non-TTYs for this release, then when will we > include it? The longer we leave it, the more painful it will be, because > more code will be written that is careless with handles. > > I don't think "leave it off by default" is a good option either, otherwise > we get to spend the next decade hearing "Perl 6 I/O is slow" because it'd > be one of the only languages that doesn't buffer its output without an > explicit flag being passed to enable that (which nearly nobody doing quick > benchmarks will know to use). > Are we missing something to flush/close handles at exit? Leaving it to a GC that may not finalize before exit is not really an option. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131965] Shaped arrays can't have zero size
> Well, what do you mean? Of course you can't put anything into it, and any > attempt to index it will throw. It may seem useless, however, if you can > have > an empty array, why can't you have a shaped empty array? > Only if all dimensions are unindexable. Otherwise you have something with inaccessible slots (and, potentially thereby, not truly leaked but unusable, memory). And an empty unshaped array, in addition to being usable as such (degenerate case of all shaped dimensions being size 0), can be made non-empty. Shaped arrays cannot.
Re: [perl #131965] Shaped arrays can't have zero size
> Well, what do you mean? Of course you can't put anything into it, and any > attempt to index it will throw. It may seem useless, however, if you can > have > an empty array, why can't you have a shaped empty array? > Only if all dimensions are unindexable. Otherwise you have something with inaccessible slots (and, potentially thereby, not truly leaked but unusable, memory). And an empty unshaped array, in addition to being usable as such (degenerate case of all shaped dimensions being size 0), can be made non-empty. Shaped arrays cannot.
Re: [perl #131965] Shaped arrays can't have zero size
How exactly do you index such an array? On Sat, Aug 26, 2017 at 8:11 PM, Aleks-Daniel Jakimenko-Aleksejev via RT < perl6-bugs-follo...@perl.org> wrote: > Indeed. The limit was introduced as a response to this ticket: > https://rt.perl.org/Ticket/Display.html?id=126800 > The check is probably too aggressive, and indeed, maybe there's nothing > wrong > with 0 sized arrays. I wonder what was the justification for making the > check > inclusive. > On 2017-08-26 16:15:33, david.warring wrote: > > This is OK: > > > > % perl6 -e'my $size = 2; my @xref[$size,3] = ([1,2,3], [4,5,6]); say > @xref' > > > > [[1 2 3] [4 5 6]] > > > > But this isn't: > > > > % perl6 -e'my $size = 0; my @xref[$size,3] = (); say @xref' > > > > Illegal dimension in shape: 0. All dimensions must be integers bigger > than > > 0 > > in block at -e line 1 > > > > % perl6 -v > > This is Rakudo version 2017.08 built on MoarVM version 2017.08.1 > > implementing Perl 6.c. > > > > Just seems an unreasonable restriction that the major shape size of an > > array can't be zero. > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131965] Shaped arrays can't have zero size
How exactly do you index such an array? On Sat, Aug 26, 2017 at 8:11 PM, Aleks-Daniel Jakimenko-Aleksejev via RT < perl6-bugs-follo...@perl.org> wrote: > Indeed. The limit was introduced as a response to this ticket: > https://rt.perl.org/Ticket/Display.html?id=126800 > The check is probably too aggressive, and indeed, maybe there's nothing > wrong > with 0 sized arrays. I wonder what was the justification for making the > check > inclusive. > On 2017-08-26 16:15:33, david.warring wrote: > > This is OK: > > > > % perl6 -e'my $size = 2; my @xref[$size,3] = ([1,2,3], [4,5,6]); say > @xref' > > > > [[1 2 3] [4 5 6]] > > > > But this isn't: > > > > % perl6 -e'my $size = 0; my @xref[$size,3] = (); say @xref' > > > > Illegal dimension in shape: 0. All dimensions must be integers bigger > than > > 0 > > in block at -e line 1 > > > > % perl6 -v > > This is Rakudo version 2017.08 built on MoarVM version 2017.08.1 > > implementing Perl 6.c. > > > > Just seems an unreasonable restriction that the major shape size of an > > array can't be zero. > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131877] [LTA] better error message for exit("hello")
At some point, one has to accept that this language is not Python, not call for one's favorite Python-isms to be incorporated into the core regardless of how it might interact with what is already there. On Thu, Aug 10, 2017 at 8:12 AM, Aleks-Daniel Jakimenko-Aleksejev via RT < perl6-bugs-follo...@perl.org> wrote: > There's a little problem with it. You see, right now this works: > > exit "1" > > So we simply cannot force it to do something else with Strs because that > can > break existing (perfectly valid) code. We can go through a long deprecation > cycle but it's not worth it (IMO). > > But it may be possible to catch X::Str::Numeric exception and print better > message for this situation… ¯\_(ツ)_/¯ > > On 2017-08-10 02:09:30, szab...@gmail.com wrote: > > In Python one can pass a string to the exit() function that will be > > displayed and the program exited. > > > > > > In Perl 6 I get: > > > > $ perl6 > > To exit type 'exit' or '^D' > > > exit("hello") > > Cannot convert string to number: base-10 number must begin with valid > > digits or '.' in '⏏hello' (indicated by ⏏) > > in block at line 1 > > > > Would it be possible to special case when someone passes a string to > > exit and give a better error message telling how to write that? > > > > Better yet, could exit accept a string? > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131877] [LTA] better error message for exit("hello")
At some point, one has to accept that this language is not Python, not call for one's favorite Python-isms to be incorporated into the core regardless of how it might interact with what is already there. On Thu, Aug 10, 2017 at 8:12 AM, Aleks-Daniel Jakimenko-Aleksejev via RT < perl6-bugs-follo...@perl.org> wrote: > There's a little problem with it. You see, right now this works: > > exit "1" > > So we simply cannot force it to do something else with Strs because that > can > break existing (perfectly valid) code. We can go through a long deprecation > cycle but it's not worth it (IMO). > > But it may be possible to catch X::Str::Numeric exception and print better > message for this situation… ¯\_(ツ)_/¯ > > On 2017-08-10 02:09:30, szab...@gmail.com wrote: > > In Python one can pass a string to the exit() function that will be > > displayed and the program exited. > > > > > > In Perl 6 I get: > > > > $ perl6 > > To exit type 'exit' or '^D' > > > exit("hello") > > Cannot convert string to number: base-10 number must begin with valid > > digits or '.' in '⏏hello' (indicated by ⏏) > > in block at line 1 > > > > Would it be possible to special case when someone passes a string to > > exit and give a better error message telling how to write that? > > > > Better yet, could exit accept a string? > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131801] Stranded strings with combiners or ZWJ on borders break my NFG expectations ( (“\x[0305]a” x 2).chars.say )
Combining chars look forward now? This breaks *my* expectations. On Wed, Jul 26, 2017 at 6:36 AM, Aleks-Daniel Jakimenko-Aleksejev < perl6-bugs-follo...@perl.org> wrote: > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev > # Please include the string: [perl #131801] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=131801 > > > > Code: > say (“\c[COMBINING OVERLINE]a” x 2).chars > > Result: > 4 > > > Code: > say (“\c[COMBINING OVERLINE]a” ~ “\c[COMBINING OVERLINE]a”).chars > > Result: > 3 > > > > Both should produce the same result (3). What happens here is “a” on one > side is not being squished into one grapheme with a combiner on another > side. > > Please note that combiners are not the only thing can cause this. Here is > the same thing with ZWJ: > > Code: > my $x = “\x[2695]\x[FE0F]a\x[1F468]\x[200D]”; > say ($x ~ $x).chars; > say ($x x 2).chars > > > Result: > 5 > 6 > > > > > I have a feeling that this is a known issue, and that there might be a > ticket for this already. However, I couldn't find it. > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #128062] [BUG] (MoarVM) chdir does not respect group reading privilege
It should not be testing, it should just try to do the operation and complain after if it fails. Race conditions should not be a language 'feature'. On Mon, Jul 17, 2017 at 6:02 PM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > On Mon, 17 Jul 2017 10:26:43 -0700, molecules wrote: > > This doesn't seem to be a problem with Rakudo 2017.04, so was probably > > fixed by Zoffix's I/O work (see > > http://blogs.perl.org/users/zoffix_znet/2017/04/perl-6-io-tpf-grant- > > monthly-report-april-2017.html). Thanks! > > > > I think that the only thing lacking is a good regression test in > > roast. I could easily write a Unix-specific test, but I think we want > > something more general. > > What was "fixed" is chdir by default only does the `.d` test now (it used > to do `.r` test too). > If that's what was needed, then there's a hole battery[^1] of tests > covering this behaviour. > > But I suspect the old behaviour is still there when doing `chdir :d, :r, > 'some dir'`, so it does the `.r` too. > THAT should respect group privileges, right? > > [1] https://github.com/perl6/roast/blob/9b51341b6c77bfe6f0ce045431942e > adc4301d78/S32-io/chdir.t#L61-L140 > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #128062] [BUG] (MoarVM) chdir does not respect group reading privilege
It should not be testing, it should just try to do the operation and complain after if it fails. Race conditions should not be a language 'feature'. On Mon, Jul 17, 2017 at 6:02 PM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > On Mon, 17 Jul 2017 10:26:43 -0700, molecules wrote: > > This doesn't seem to be a problem with Rakudo 2017.04, so was probably > > fixed by Zoffix's I/O work (see > > http://blogs.perl.org/users/zoffix_znet/2017/04/perl-6-io-tpf-grant- > > monthly-report-april-2017.html). Thanks! > > > > I think that the only thing lacking is a good regression test in > > roast. I could easily write a Unix-specific test, but I think we want > > something more general. > > What was "fixed" is chdir by default only does the `.d` test now (it used > to do `.r` test too). > If that's what was needed, then there's a hole battery[^1] of tests > covering this behaviour. > > But I suspect the old behaviour is still there when doing `chdir :d, :r, > 'some dir'`, so it does the `.r` too. > THAT should respect group privileges, right? > > [1] https://github.com/perl6/roast/blob/9b51341b6c77bfe6f0ce045431942e > adc4301d78/S32-io/chdir.t#L61-L140 > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131757] Untodoed evil hack in Backtrace.pm
On Mon, Jul 17, 2017 at 2:49 AM, Joachim Durchholz via RT < perl6-bugs-follo...@perl.org> wrote: > 1) It cannot handle non-runtime code that one might want to filter. > 2) It hardcodes the definition of what's interesting. > 3) You cannot have runtime code that you *want* to be included in the > backtrace. > 4) It adds a design constraint about what can go into which module of > the runtime. > 5) The design constraint is nonobvious. > 6) If somebody writes his own module in a different location but with a > matching name (e.g. they might be writing a wrapper, or an emulator), > then these files will be filtered as well. > 7. When Perl 6 gets used on the web, someone *will* find a way to abuse this (e.g. to obscure how they broke into something). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131757] Untodoed evil hack in Backtrace.pm
On Mon, Jul 17, 2017 at 2:49 AM, Joachim Durchholz via RT < perl6-bugs-follo...@perl.org> wrote: > 1) It cannot handle non-runtime code that one might want to filter. > 2) It hardcodes the definition of what's interesting. > 3) You cannot have runtime code that you *want* to be included in the > backtrace. > 4) It adds a design constraint about what can go into which module of > the runtime. > 5) The design constraint is nonobvious. > 6) If somebody writes his own module in a different location but with a > matching name (e.g. they might be writing a wrapper, or an emulator), > then these files will be filtered as well. > 7. When Perl 6 gets used on the web, someone *will* find a way to abuse this (e.g. to obscure how they broke into something). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131757] Untodoed evil hack in Backtrace.pm
On Mon, Jul 17, 2017 at 4:20 AM, Joachim Durchholz wrote: > Am 17.07.2017 um 09:32 schrieb Brandon Allbery: > > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz > <mailto:j...@durchholz.org>> wrote: > > > > I think the whole concept of defining what's "interesting" in > > a backtrace by looking at the file name is pretty evil: > > > > So does Perl 6, actually; there's some discussion in the spec, and > > possibly in the docs for callframe. > > Do you mean that the Perl6 spec considers this to be evil, too? > Yes. This is an acknowledged hack to provide the functionality when it can't currently be done "right", and the ticket is a reminder aside from the comment in the source that a proper solution is needed. > The problem is, in the setting most > > of that machinery is needed before it can be defined. > > Is my understanding correct: That we're looking at a chicken-and-egg > problem in the implementation? > That's my read, but jnthn's observation that this lives in NQP-land also complicates things. (This is not the first chicken-and-egg problem we've had. The setting needs booleans before perl 6 enums have been defined, so there's a BOOTEnum thing. At one point it started leaking out, and because it's not a proper perl 6 class but raw NQP it caused problems.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131757] Untodoed evil hack in Backtrace.pm
On Mon, Jul 17, 2017 at 4:20 AM, Joachim Durchholz wrote: > Am 17.07.2017 um 09:32 schrieb Brandon Allbery: > > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz > <mailto:j...@durchholz.org>> wrote: > > > > I think the whole concept of defining what's "interesting" in > > a backtrace by looking at the file name is pretty evil: > > > > So does Perl 6, actually; there's some discussion in the spec, and > > possibly in the docs for callframe. > > Do you mean that the Perl6 spec considers this to be evil, too? > Yes. This is an acknowledged hack to provide the functionality when it can't currently be done "right", and the ticket is a reminder aside from the comment in the source that a proper solution is needed. > The problem is, in the setting most > > of that machinery is needed before it can be defined. > > Is my understanding correct: That we're looking at a chicken-and-egg > problem in the implementation? > That's my read, but jnthn's observation that this lives in NQP-land also complicates things. (This is not the first chicken-and-egg problem we've had. The setting needs booleans before perl 6 enums have been defined, so there's a BOOTEnum thing. At one point it started leaking out, and because it's not a proper perl 6 class but raw NQP it caused problems.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131757] Untodoed evil hack in Backtrace.pm
On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz wrote: > I think the whole concept of defining what's "interesting" in a backtrace >> by looking at the file name is pretty evil: > > So does Perl 6, actually; there's some discussion in the spec, and possibly in the docs for callframe. The problem is, in the setting most of that machinery is needed before it can be defined. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131757] Untodoed evil hack in Backtrace.pm
On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz wrote: > I think the whole concept of defining what's "interesting" in a backtrace >> by looking at the file name is pretty evil: > > So does Perl 6, actually; there's some discussion in the spec, and possibly in the docs for callframe. The problem is, in the setting most of that machinery is needed before it can be defined. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131737] [BUG] WindowsOS: IO.dirname strips off drive name
'dirname' represents a component of a path, not a path. I suspect the internal field components should be renamed, though, as people do not generally think in terms of the implementation of the shell's 'dirname', but instead of its effective behavior. (The implementation splits a path into its components, but being a Unixy utility it doesn't consider splitting the volume off like it does the basename and extension.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131737] [BUG] WindowsOS: IO.dirname strips off drive name
'dirname' represents a component of a path, not a path. I suspect the internal field components should be renamed, though, as people do not generally think in terms of the implementation of the shell's 'dirname', but instead of its effective behavior. (The implementation splits a path into its components, but being a Unixy utility it doesn't consider splitting the volume off like it does the basename and extension.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131695] Confusion in precedence with <<$foo>>[0]
Perhaps this example should be provided somewhere as a 'gotcha'. On Mon, Jul 3, 2017 at 11:09 AM, jn...@jnthn.net via RT < perl6-bugs-follo...@perl.org> wrote: > On Mon, 03 Jul 2017 05:46:46 -0700, comdog wrote: > > It seems that term precedence with << >> gets confused. > > > The << >> quoting construct interpolates. The rule for interpolation of > method calls, indexing, etc. after a scalar is that there may be one, but > it may only end with a ], ), } or >. > > > { > > my $number = <<$string>>[0]; > > When the variable is encountered inside of the interpolating quoting > construct, which is being parsed by the quoting parser, it calls back into > the Perl 6 main language parser. This parses a variable and optionally a > postfix. The >>[0] is a valid postfix, where >> is the hyper-operator and > [0] is the indexer. Therefore the $string>>[0] is taken as the thing to > interpolate. It then hands back control to the quoting parser. > > > put "Type: " ~ $number; > > #`( > > ===SORRY!=== Error while compiling ... > > Cannot use variable $number in declaration to initialize itself > > --> put "Type: " ~ $⏏number; > > This is complaining that $number was used before its declaration was > complete, which is indeed the case because at we are still inside of the > quoting construct. > > I can see the potential for a human reader to be confused, but the Perl 6 > parser is not in the least bit confused. There isn't any question as to > what will parse the >>: if the main language parser understands it and > wants it, then it gets it, because the quoting parser doesn't get a say > again until the main language parser has done its bit. This is the same > reason that you can do stuff like: > > say "Foos: @foo.join("bar")" > > And there isn't a bit of confusion so far as Perl 6 is concerned that the > inner " is opening a new string, not closing the one we were already in. > Granted it's maybe kinder to the reader to write it with single quotes > inside of the string. But nestings of main language => quote parser => main > language => quote parser will Just Work, each eating as much as it > understands (or until seeing its terminator) before giving up control. > > /jnthn > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131695] Confusion in precedence with <<$foo>>[0]
Perhaps this example should be provided somewhere as a 'gotcha'. On Mon, Jul 3, 2017 at 11:09 AM, jn...@jnthn.net via RT < perl6-bugs-follo...@perl.org> wrote: > On Mon, 03 Jul 2017 05:46:46 -0700, comdog wrote: > > It seems that term precedence with << >> gets confused. > > > The << >> quoting construct interpolates. The rule for interpolation of > method calls, indexing, etc. after a scalar is that there may be one, but > it may only end with a ], ), } or >. > > > { > > my $number = <<$string>>[0]; > > When the variable is encountered inside of the interpolating quoting > construct, which is being parsed by the quoting parser, it calls back into > the Perl 6 main language parser. This parses a variable and optionally a > postfix. The >>[0] is a valid postfix, where >> is the hyper-operator and > [0] is the indexer. Therefore the $string>>[0] is taken as the thing to > interpolate. It then hands back control to the quoting parser. > > > put "Type: " ~ $number; > > #`( > > ===SORRY!=== Error while compiling ... > > Cannot use variable $number in declaration to initialize itself > > --> put "Type: " ~ $⏏number; > > This is complaining that $number was used before its declaration was > complete, which is indeed the case because at we are still inside of the > quoting construct. > > I can see the potential for a human reader to be confused, but the Perl 6 > parser is not in the least bit confused. There isn't any question as to > what will parse the >>: if the main language parser understands it and > wants it, then it gets it, because the quoting parser doesn't get a say > again until the main language parser has done its bit. This is the same > reason that you can do stuff like: > > say "Foos: @foo.join("bar")" > > And there isn't a bit of confusion so far as Perl 6 is concerned that the > inner " is opening a new string, not closing the one we were already in. > Granted it's maybe kinder to the reader to write it with single quotes > inside of the string. But nestings of main language => quote parser => main > language => quote parser will Just Work, each eating as much as it > understands (or until seeing its terminator) before giving up control. > > /jnthn > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131583] [BUG] Sort content of ^methods
On Fri, Jun 16, 2017 at 12:41 AM, Gabor Szabo wrote: > Would it be used by people who use the REPL to experiment with the > languages? In that case the listing should be as user friendly as > possible and require as little typing as possible. Having ABC order is > IMHO the easiest to look through. > If we're going to provide that ability, it should probably not be done via the metaobject interface. Relying on that can get you surprises, in particular quite a few anonymous methods for various things with low level implementations (and other surprises if you dig deeper and it's implemented in nqp). (dir() in python is a different issue, since as far as python is concerned it's just listing the keys in some dict, and sorting them would usually be desirable. That said dict happens to represent an object is irrelevant.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131583] [BUG] Sort content of ^methods
On Fri, Jun 16, 2017 at 12:41 AM, Gabor Szabo wrote: > Would it be used by people who use the REPL to experiment with the > languages? In that case the listing should be as user friendly as > possible and require as little typing as possible. Having ABC order is > IMHO the easiest to look through. > If we're going to provide that ability, it should probably not be done via the metaobject interface. Relying on that can get you surprises, in particular quite a few anonymous methods for various things with low level implementations (and other surprises if you dig deeper and it's implemented in nqp). (dir() in python is a different issue, since as far as python is concerned it's just listing the keys in some dict, and sorting them would usually be desirable. That said dict happens to represent an object is irrelevant.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
On Thu, Jun 8, 2017 at 6:22 AM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > > m: sub infix:<2> { $^a + $^b }; say 2 2 2 > rakudo-moar 1ac799: OUTPUT: «4» > > Because when an op is expected. There's just one op named `2`. And when > a term is expected, there's just one term named 2. There's a difference here: you have a token separator. ²² lacks one but acts like it has one. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131492] Camelia produces different error message from commandline
On Mon, Jun 5, 2017 at 5:32 PM, Parrot Raiser <1parr...@gmail.com> wrote: > perl6 –e "my \foo = Callable but role:: { };" Something bit you; note that you are not using "-e" but "–e" (U+2013 EN DASH). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131492] Camelia produces different error message from commandline
On Mon, Jun 5, 2017 at 5:32 PM, Parrot Raiser <1parr...@gmail.com> wrote: > perl6 –e "my \foo = Callable but role:: { };" Something bit you; note that you are not using "-e" but "–e" (U+2013 EN DASH). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131481] [BUG] No perl6-debug
I would argue that perl6-debug shouldn't exist; if you are debugging, you pretty much need to know the specific backend that's involved. Which is likely why rakudobrew killed the generic one (the directory listing, while mangled, *did* show perl6-debug-m). On Sun, Jun 4, 2017 at 2:12 AM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > On Thu, 01 Jun 2017 22:25:55 -0700, rnhainswo...@gmail.com wrote: > > Here is a copy of my session. No perl6-debug. > > > > All the documentation implies I should have the executable. I'm running > > Ubuntu 16.04 > > Which documentation, out of curiosity? rakudobrew is mostly for core > hackers, not end users, so it'd likely be best to remove that documentation. > > As for the perl6-debug. It's likely called perl6-debug-m > > However, it bitrotted a bit and even if you find it, it won't work ATM. > Hoping someone will find tuits to fix it before next release. > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131481] [BUG] No perl6-debug
I would argue that perl6-debug shouldn't exist; if you are debugging, you pretty much need to know the specific backend that's involved. Which is likely why rakudobrew killed the generic one (the directory listing, while mangled, *did* show perl6-debug-m). On Sun, Jun 4, 2017 at 2:12 AM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > On Thu, 01 Jun 2017 22:25:55 -0700, rnhainswo...@gmail.com wrote: > > Here is a copy of my session. No perl6-debug. > > > > All the documentation implies I should have the executable. I'm running > > Ubuntu 16.04 > > Which documentation, out of curiosity? rakudobrew is mostly for core > hackers, not end users, so it'd likely be best to remove that documentation. > > As for the perl6-debug. It's likely called perl6-debug-m > > However, it bitrotted a bit and even if you find it, it won't work ATM. > Hoping someone will find tuits to fix it before next release. > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131398] Feature Request: trait for unimplemented subs/methods
As already mentioned, we have three such stubbers already. You can even put a partial/incomplete implementation after them: just terminate the ... or w/e with a semicolon. What none of them will do for you is allow a syntactically incorrect body. But the proposed feature *also* will not allow that; you'd have to do it as a slang to get that, and even then I suspect you will find error recovery / parser resynchronization to be nontrivial. On Tue, May 30, 2017 at 10:21 AM, Parrot Raiser <1parr...@gmail.com> wrote: > That is so easy for a programmer to implement; I have an "nyi" > subroutine/function in the my skeleton scripts for both Perl 5 and > Bash. Is it worth cluttering the language? > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131398] Feature Request: trait for unimplemented subs/methods
As already mentioned, we have three such stubbers already. You can even put a partial/incomplete implementation after them: just terminate the ... or w/e with a semicolon. What none of them will do for you is allow a syntactically incorrect body. But the proposed feature *also* will not allow that; you'd have to do it as a slang to get that, and even then I suspect you will find error recovery / parser resynchronization to be nontrivial. On Tue, May 30, 2017 at 10:21 AM, Parrot Raiser <1parr...@gmail.com> wrote: > That is so easy for a programmer to implement; I have an "nyi" > subroutine/function in the my skeleton scripts for both Perl 5 and > Bash. Is it worth cluttering the language? > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131363] [LTA] Using dot instead of a semicolon as a statement end (say ‘hello’.)
On Thu, May 25, 2017 at 8:58 AM, Aleks-Daniel Jakimenko-Aleksejev < perl6-bugs-follo...@perl.org> wrote: > Arguably, it can probably figure out that . was used instead of ;. The > problem is that . is interpreted as an infix, and therefore it only blows > up when it sees the next occurrence of two terms in a row (or any other > issue)… Not sure if there is any easy way to implement something like this > (but a line ending with a dot should be a good heuristic, no?) Doesn't this conflict with splitting chained method calls over multiple lines? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #129843] [LTA] Indexing on a Str throws generic “out of range” message which is less than awesome (“hello”[2])
On Mon, May 8, 2017 at 4:49 PM, Joachim Durchholz wrote: > If the mental model for Perl6 strings is "array of characters" though Perl has never had that mental model, is my point. It's generally imported by folks who come from languages where strings *are* "arrays of characters" --- and where that model has a strong tendency to cause problems. (See Python 3's struggles with Unicode as an example. And C/C++, well, don't even get me started. Bytes stopped being the basis of characters even *before* Unicode. C and C++ are still struggling to understand that.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #129843] [LTA] Indexing on a Str throws generic “out of range” message which is less than awesome (“hello”[2])
On Mon, May 8, 2017 at 2:52 PM, Aleks-Daniel Jakimenko-Aleksejev via RT < perl6-bugs-follo...@perl.org> wrote: > Usually I'm against all perl5 error messages This is a Pythonism (and C and other such languages). Older Perl has the same behavior that you can't index a string that way, but must use e.g. substr. You will *not* likely see this from old Perlers; they will reach for substr. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131111] [@LARRY] %c = %a, %b and @c = @a, @b should behave similarly
IIRC this hash behavior is deliberate so that hashes can be accumulated. Also, your proposed behavior would require an object hash, not a standard hash; (%a => %b) would necessarily stringify %a. On Thu, Apr 6, 2017 at 4:46 PM, Aleks-Daniel Jakimenko-Aleksejev < perl6-bugs-follo...@perl.org> wrote: > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev > # Please include the string: [perl #13] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=13 > > > > Code: > my @a = ; > my @b = <1 2 3>; > my @c = @a, @b; > say @c > > Result: > [[a b c] [1 2 3]] > > > So with arrays, nothing is flattened and you get an array with two > elements. Makes sense. > > And if we want to get a different behavior, we can use slip: > > Code: > my @a = ; > my @b = <1 2 3>; > my @c = |@a, |@b; > say @c > > Result: > [a b c 1 2 3] > > > Everything is fine so far. Now, let's try the same thing with hashes: > > Code: > my %a = ; > my %b = <1 2 3 4>; > my %c = %a, %b; > say %c > > Result: > {1 => 2, 3 => 4, a => b, c => d} > > > To me that looks like an inconsistency, I would have expected it to create > a hash with one pair (%a => %b). In fact, both 「%c = %a, %b」 and 「%c = |%a, > |%b」 work exactly the same! > > The idea of %a => %b may seem weird, but it really isn't if you consider > object hashes (my %c{Hash} = %a => %b; or even my %c{Hash} = $%a, $%b) > > Another thing to note is that this array behavior was changed during the > GLR, but hashes remained the same. Perhaps that was an oversight. > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131076] [LTA] Rakudo sees Perl 5 code even if there is none (for $x(42), $x(50) {…})
That *is* Perl 5 syntax, though; it looks like the schema for $var (list) { ... } # the space is not required between the var and the parenthesized list On Wed, Mar 29, 2017 at 9:35 PM, Aleks-Daniel Jakimenko-Aleksejev < perl6-bugs-follo...@perl.org> wrote: > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev > # Please include the string: [perl #131076] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=131076 > > > > Code: > my $x = *²; for $x(42), $x(50) { say $_ } > > Result: > ===SORRY!=== Error while compiling -e > This appears to be Perl 5 code > at -e:1 > --> my $x = *²; for ⏏$x(42), $x(50) { say $_ } > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131043] [BUG] Binding to `state` variable silently fails
I can't help but think that binding a state variable should be illegal, and doing so will have unexpected effects. On Wed, Mar 22, 2017 at 1:48 PM, Zoffix Znet wrote: > # New Ticket Created by Zoffix Znet > # Please include the string: [perl #131043] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=131043 > > > > $ perl6 -v > This is Rakudo version 2017.03-20-g027aa54 built on MoarVM version > 2017.03-7-g029d121 > implementing Perl 6.c. > > $ perl6 -e 'state $x = 42; dd $x' > Int $x = 42 > > $ perl6 -e 'state $x := 42; dd $x' > Mu > > > I also have a small snippet where the `state` declaration uses assignment, > but later > in the code a binding is used for the same variable. The result of the > routine changes, > based on whether it's a binding or an assignment (also, I believe the > result with binding > is incorrect: > > use MONKEY; > sub z { > my @found; > for $^v.pairs { > my $value := .value; > state $max = $value; > my $cmp; > nqp::if( > nqp::iseq_i( ($cmp := $value cmp $max), 1 ), > > ### CHANGING FROM $max := to $max = BELOW CHANGES RESULT > nqp::stmts((@found = $_), ($max := $value)), > nqp::if( > nqp::iseq_i($cmp, 0), > @found.push: $_ > ) > ) > } > @found.List > } > > dd z (1, 2, 65, -6, 4); > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #131026] Failing to read from IO::Pipe fast enough, apparently loses data
Note that 65535 is the POSIX-specified minimum largest write size that is guaranteed to be atomic (_PIPE_BUF), and derives from the usual size of kernel-side pipe buffers (Linux's are actually larger, but sizes larger than the POSIX minimum _PIPE_BUF are likely to incur portability issues, so libuv may stick to the POSIX minimum). Reads and writes larger than _PIPE_BUF may not interact well with non-blocking I/O. Meaning, this may be a libuv-level bug, or moarvm using libuv incorrectly. ("Connection reset by peer" is an odd error for this, which is part of why I suspect libuv: feels like it picked a fake error to return on non-blocking read or write doing something it didn't expect.) On Mon, Mar 20, 2017 at 1:36 PM, Zoffix Znet wrote: > # New Ticket Created by Zoffix Znet > # Please include the string: [perl #131026] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=131026 > > > > zoffix@VirtualBox:~$ perl6 -e '$ = shell(:out, "yes | head -n > 10").out.lines' > head: write error: Connection reset by peer > head: write error > zoffix@VirtualBox:~$ perl6 -e '$ = shell(:out, "yes | head -n > 10").out.IO::Handle::lines' > zoffix@VirtualBox:~$ perl6 -e '$ = shell(:out, "yes | head -n > 10").out.IO::Handle::lines' > head: write error: Connection reset by peer > head: write error > > This is Rakudo version 2017.02-186-g9da6de4 built on MoarVM version > 2017.02-18-g5f9d698 > implementing Perl 6.c. > > Note that the same error doesn't happen with head -n 6, suggesting > it's some sort of buffer sized to 65536. Adjusting > RAKUDO_DEFAULT_READ_ELEMS doesn't solve it. > > Unsure if this is meant to be this way or not. I'd expect no write errors > to happen or for Perl 6 to complain about it. If this is normal, then at > least it should be documented as a caveat. > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130982] [PERF] "for $a..$b -> $i { ... }" loops are sometimes much slower than c-style loops
On Sun, Mar 12, 2017 at 12:48 AM, Lloyd Fournier wrote: > perl6-loop: 84.8739988 > c-loop: 67.65849241 (1.25 times faster) > native-loop: 0.4981954 (135.81 times faster) > Still quite a lot of optimization to be done on that front. WRT native int, one of the issues is needing to track when boxing is/isn't needed, otherwise nativizing can be a pessimization because of constant reboxing. The optimizer isn't up to tracking boxing like that yet. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130969] [LTA] more inconsistent coercions for Bool
The discussion I'm thinking of starts around here: http://colabti.org/irclogger/irclogger_log/perl6?date=2017-03-04#l1490 On Thu, Mar 9, 2017 at 4:04 PM, Zefram wrote: > Brandon Allbery via RT wrote: > >In any case I am specifically thinking of a discussion recently in IRC > >which went over why at least some of this is actually self-consistent *for > >perl 6*. > > I would be interested in seeing that discussion. > > >(That said, there may actually be some lingering inconsistency left over > >from when Bool had to be special-cased > > I haven't noticed any such inconsistency between Bool and other enums. > That's certainly not the cause of the present inconsistent coercions, > which happen equally with Order: > > > Less.Int > -1 > > Less.Real > Less > > Less.Numeric > -1 > > -zefram > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130969] [LTA] more inconsistent coercions for Bool
Self-consistency is itself a fuzzy concept. In any case I am specifically thinking of a discussion recently in IRC which went over why at least some of this is actually self-consistent *for perl 6*. I may be able to dig it up again, or hopefully someone else already has it on tap. (That said, there may actually be some lingering inconsistency left over from when Bool had to be special-cased because it needed to exist in the setting before Enums could be defined.) On Thu, Mar 9, 2017 at 3:41 PM, Zefram wrote: > Brandon Allbery via RT wrote: > >This should be your hint. Enums *are* numeric, specifically Int. > > I'm aware of that, and that's why I call this an LTA rather than > a bug, and why I didn't say conclusively which coercion was wrong. > Indeed, on the basis of the enum/Int subclassing, I proposed in [perl > #127019] that the inconsistency that then existed between Bool.Int and > Bool.Numeric coercions ought to be resolved by making both return the > operand unchanged. The decision was made the other way, that they should > both return a basal Int. > > So I'm not saying in this ticket that it's a priori wrong for True.Real > to return True. On the contrary, the fact that True.^does(Real) makes > that a priori a reasonable answer. The problem is that it's inconsistent > with the results for the similar .Int and .Numeric coercions, and with the > decision on those coercions that was made in [perl #127019]. There are > two ways in which these coercions can be made mutually consistent, > and either would resolve this ticket. > > >I don't know what language you are trying to force Perl 6 to be, > > I'd like it to be a self-consistent language, as far as possible. > I don't recall anyone saying yet that that's an undesirable principle > in the design of Perl 6. > > -zefram > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130969] [LTA] more inconsistent coercions for Bool
On Thu, Mar 9, 2017 at 2:55 PM, Zefram wrote: > The same goes for coercions from other enum types. This should be your hint. Enums *are* numeric, specifically Int. I don't know what language you are trying to force Perl 6 to be, but you might want to consider the possibility that Perl 6 is not that language but instead is Perl 6. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130970] [BUG] Set.new confused by Nil
Erm. Isn't Nil a silent Failure? Insisting that it be propagated and retained in all circumstances basically asserts that it must be a distinct concrete value, and specifically *not* any form of Failure. Could someone clarify this? (At present my understanding is that it is a silent Failure and most if not all of today's Nil tickets are at best missing the point.) On Thu, Mar 9, 2017 at 3:03 PM, Zefram wrote: > # New Ticket Created by Zefram > # Please include the string: [perl #130970] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=130970 > > > > > Set.new(Nil).perl > set(Any) > > set(Nil).perl > set(Any) > > set(Nil).WHICH > Set|Any|U16962232 > > Attempting to put Nil into a Set instead puts Any into one. Happens with > both Set.new() and set() constructors. The .WHICH result shows that > it really is the set construction that mangled the value, not .perl. > There's no reason for Nil not to be a distinguishable value in a set. > > -zefram > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #128526] [CONC] Proc::Async's .write appears to exit when the process run doesn't exist
On Wed, Mar 8, 2017 at 11:33 AM, jn...@jnthn.net via RT < perl6-bugs-follo...@perl.org> wrote: > Fixed and tested in S17-procasync/nonexistent.t. (The change is to default > to ignoring SIGPIPE, since we error-check all operations anyway. Those who > do want to exit on SIGPIPE can write `signal(SIGPIPE).tap: { exit 1 }` or > so. > Hm. I'm going to guess this will interact badly with use as part of a shell pipeline. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130900] [BUG] nul in pathname
On Thu, Mar 2, 2017 at 9:14 AM, Joachim Durchholz wrote: > For the other invalid characters, the error will (well: should) be caught > by the filesystem. > Trying to check that in advance is a security hole in waiting - somebody > might mount or unmount filesystems between check and use. > This, sadly, is not always true. The // prefix is a specific case in point. CIFS/NTFS *does* catch invalid characters... unless the kernel filesystem is buggy, which Linux's has been. Multiple times. The result of that is files that you can write but fail to read back, sometimes on Linux and sometimes on the remote / the Windows dual-boot, as appropriate. Again, this knowledge *should not* be coded into perl; we can't be nannies for Linux filesystem driver developers. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130900] [BUG] nul in pathname
On Thu, Mar 2, 2017 at 8:56 AM, Brandon Allbery wrote: > - the sequence `//` which is specifically undefined by POSIX In the interests of heading off incoming pedanticness, possibly to "defend" the indefensible: this is only undefined as a prefix. It is an error as an infix. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130900] [BUG] nul in pathname
To be clear: the POSIX spec does, specifically, disallow NUL. *Only* NUL. Which then leaves: - any character disallowed by specific filesystems (consider CIFS) - the sequence `//` which is specifically undefined by POSIX Among others. Is it correct to disallow NUL and thereby have a special case where all other implementation-undefined filenames are not caught --- and not catchable? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130900] [BUG] nul in pathname
On Thu, Mar 2, 2017 at 5:29 AM, Zefram wrote: > It is less than awesome that > Perl 6 accepts "foo\x[0]bar" as a pathname, when it doesn't resemble > any pathname valid on the OS > It's also less than awesome that POSIX, at least, doesn't let you confirm that a filename is syntactically valid, either on the OS or on a specific filesystem. And hardcoding that knowledge into Perl (any version) would be a severe mistake. The code is a "bug" but Perl cannot be prescient for you, or hack the kernel and filesystem drivers to find out what is valid. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)
Or to put this another way: the current behavior seems like an overoptimization where it finds the target container in the source and optimizes into an update. This is only safe if the target is the first thing in the list of new contents; you must deoptimize in all other situations (unless your optimizer is *really* clever), and it's on the programmer to accept the resulting deoptimization and if necessary rewrite to avoid it. On Mon, Feb 27, 2017 at 11:08 AM, Brandon Allbery wrote: > To unpack this a bit: in this case I understand the comma to be an infix > operator that creates a container by unpacking any containers it encounters > and combining their contents with any non-containers it finds, in the > specified order, to make a new collection of contents. It operates on the > level of contents, not containers. If I want a container to be an item, I'm > fine with itemizing it explicitly. > > On Mon, Feb 27, 2017 at 11:03 AM, Parrot Raiser <1parr...@gmail.com> > wrote: > >> I agree with Brandon on this one. >> >> RHS retaining its original value, even when being updated on the LHS >> is a fundamental behaviour in Perl. Changing that, especially in >> obscure special circumstances would be bad. >> >> On 2/27/17, Brandon Allbery wrote: >> > And yes, I know that it *is* retaining its value as an object pointer, >> just >> > not the contents. But if I write something like that, I pretty clearly >> mean >> > the *contents*. >> > >> > On Mon, Feb 27, 2017 at 10:46 AM, Brandon Allbery >> > wrote: >> > >> >> I disagree; this is not Haskell, if I do something like that then I >> >> expect >> >> %h2 to retain its original value while the RHS is being evaluated. >> >> >> >> On Mon, Feb 27, 2017 at 4:35 AM, Elizabeth Mattijsen >> >> wrote: >> >> >> >>> FWIW, this feels like a DIHWIDT case >> >>> >> >>> > On 27 Feb 2017, at 00:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) >> < >> >>> perl6-bugs-follo...@perl.org> wrote: >> >>> > >> >>> > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev >> >>> > # Please include the string: [perl #130870] >> >>> > # in the subject line of all future correspondence about this issue. >> >>> > # https://rt.perl.org/Ticket/Display.html?id=130870 > >> >>> > >> >>> > >> >>> > Code: >> >>> > my %h1 = <1 a 2 b>; >> >>> > my %h2 = <3 c 4 d>; >> >>> > my %h3 = <5 e 6 f>; >> >>> > %h2 = %h1, %h2, %h3; >> >>> > say %h2 >> >>> > >> >>> > Result: >> >>> > {1 => a, 2 => b, 5 => e, 6 => f} >> >>> > >> >>> > >> >>> > Notice that it has everything except for elements of %h2. >> >>> > >> >>> > If this behavior is correct, then it should throw a warning. But I'd >> >>> argue that it should work exactly the same way as if it was an >> >>> assignment >> >>> to a different hash. >> >>> >> >> >> >> >> >> >> >> -- >> >> brandon s allbery kf8nh sine nomine >> >> associates >> >> allber...@gmail.com >> >> ballb...@sinenomine.net >> >> unix, openafs, kerberos, infrastructure, xmonad >> >> http://sinenomine.net >> >> >> > >> > >> > >> > -- >> > brandon s allbery kf8nh sine nomine >> > associates >> > allber...@gmail.com >> > ballb...@sinenomine.net >> > unix, openafs, kerberos, infrastructure, xmonad >> > http://sinenomine.net >> > >> > > > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)
To unpack this a bit: in this case I understand the comma to be an infix operator that creates a container by unpacking any containers it encounters and combining their contents with any non-containers it finds, in the specified order, to make a new collection of contents. It operates on the level of contents, not containers. If I want a container to be an item, I'm fine with itemizing it explicitly. On Mon, Feb 27, 2017 at 11:03 AM, Parrot Raiser <1parr...@gmail.com> wrote: > I agree with Brandon on this one. > > RHS retaining its original value, even when being updated on the LHS > is a fundamental behaviour in Perl. Changing that, especially in > obscure special circumstances would be bad. > > On 2/27/17, Brandon Allbery wrote: > > And yes, I know that it *is* retaining its value as an object pointer, > just > > not the contents. But if I write something like that, I pretty clearly > mean > > the *contents*. > > > > On Mon, Feb 27, 2017 at 10:46 AM, Brandon Allbery > > wrote: > > > >> I disagree; this is not Haskell, if I do something like that then I > >> expect > >> %h2 to retain its original value while the RHS is being evaluated. > >> > >> On Mon, Feb 27, 2017 at 4:35 AM, Elizabeth Mattijsen > >> wrote: > >> > >>> FWIW, this feels like a DIHWIDT case > >>> > >>> > On 27 Feb 2017, at 00:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) < > >>> perl6-bugs-follo...@perl.org> wrote: > >>> > > >>> > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev > >>> > # Please include the string: [perl #130870] > >>> > # in the subject line of all future correspondence about this issue. > >>> > # https://rt.perl.org/Ticket/Display.html?id=130870 > > >>> > > >>> > > >>> > Code: > >>> > my %h1 = <1 a 2 b>; > >>> > my %h2 = <3 c 4 d>; > >>> > my %h3 = <5 e 6 f>; > >>> > %h2 = %h1, %h2, %h3; > >>> > say %h2 > >>> > > >>> > Result: > >>> > {1 => a, 2 => b, 5 => e, 6 => f} > >>> > > >>> > > >>> > Notice that it has everything except for elements of %h2. > >>> > > >>> > If this behavior is correct, then it should throw a warning. But I'd > >>> argue that it should work exactly the same way as if it was an > >>> assignment > >>> to a different hash. > >>> > >> > >> > >> > >> -- > >> brandon s allbery kf8nh sine nomine > >> associates > >> allber...@gmail.com > >> ballb...@sinenomine.net > >> unix, openafs, kerberos, infrastructure, xmonad > >> http://sinenomine.net > >> > > > > > > > > -- > > brandon s allbery kf8nh sine nomine > > associates > > allber...@gmail.com > > ballb...@sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > > http://sinenomine.net > > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)
And yes, I know that it *is* retaining its value as an object pointer, just not the contents. But if I write something like that, I pretty clearly mean the *contents*. On Mon, Feb 27, 2017 at 10:46 AM, Brandon Allbery wrote: > I disagree; this is not Haskell, if I do something like that then I expect > %h2 to retain its original value while the RHS is being evaluated. > > On Mon, Feb 27, 2017 at 4:35 AM, Elizabeth Mattijsen > wrote: > >> FWIW, this feels like a DIHWIDT case >> >> > On 27 Feb 2017, at 00:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) < >> perl6-bugs-follo...@perl.org> wrote: >> > >> > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev >> > # Please include the string: [perl #130870] >> > # in the subject line of all future correspondence about this issue. >> > # https://rt.perl.org/Ticket/Display.html?id=130870 > >> > >> > >> > Code: >> > my %h1 = <1 a 2 b>; >> > my %h2 = <3 c 4 d>; >> > my %h3 = <5 e 6 f>; >> > %h2 = %h1, %h2, %h3; >> > say %h2 >> > >> > Result: >> > {1 => a, 2 => b, 5 => e, 6 => f} >> > >> > >> > Notice that it has everything except for elements of %h2. >> > >> > If this behavior is correct, then it should throw a warning. But I'd >> argue that it should work exactly the same way as if it was an assignment >> to a different hash. >> > > > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)
I disagree; this is not Haskell, if I do something like that then I expect %h2 to retain its original value while the RHS is being evaluated. On Mon, Feb 27, 2017 at 4:35 AM, Elizabeth Mattijsen wrote: > FWIW, this feels like a DIHWIDT case > > > On 27 Feb 2017, at 00:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) < > perl6-bugs-follo...@perl.org> wrote: > > > > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev > > # Please include the string: [perl #130870] > > # in the subject line of all future correspondence about this issue. > > # https://rt.perl.org/Ticket/Display.html?id=130870 > > > > > > > Code: > > my %h1 = <1 a 2 b>; > > my %h2 = <3 c 4 d>; > > my %h3 = <5 e 6 f>; > > %h2 = %h1, %h2, %h3; > > say %h2 > > > > Result: > > {1 => a, 2 => b, 5 => e, 6 => f} > > > > > > Notice that it has everything except for elements of %h2. > > > > If this behavior is correct, then it should throw a warning. But I'd > argue that it should work exactly the same way as if it was an assignment > to a different hash. > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130834] Is `use v5` still a thing?
It should do *something*; I suspect the intent was to offload that something, since there was at one point the idea of exec()ing a perl 5. At the very least it should throw --- but that might be handled sufficiently by the default. On Wed, Feb 22, 2017 at 8:45 AM, Zoffix Znet wrote: > # New Ticket Created by Zoffix Znet > # Please include the string: [perl #130834] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=130834 > > > > I notice the first thing[^1] our `use` pragma looks for when it gets a > version is `v5` and tries to load `Perl 5` module: > > That doesn't appear to be a thing any more. Should that conditional be > tossed from the grammar? > > m: use v5 > 13:41 camelia rakudo-moar 91a4ac: OUTPUT: > «===SORRY!===Could not find Perl5 at line 1 in:/home/camelia/.perl6 > /home/camelia/rakudo-m-inst-1/share/perl6/site > /home/camelia/rakudo-m-inst-1/share/perl6/vendor > /home/camelia/rakudo-m-inst-1/share/perl6CompUnit::Repos…» > > > https://github.com/rakudo/rakudo/blob/91a4ac5a671b7943793a8fdb13a2fd > a952671f71/src/Perl6/Grammar.nqp#L1595-L1599 > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130723] [BUG] .pick on large ranges gives unexpected results on Windows only
On Mon, Feb 6, 2017 at 3:31 PM, Nicholas Clark wrote: > OK, this is a bit of guessing, and I would like to think that I've guessed > wrongly because someone else *should* have hit this before... > You'd be surprised. Verifying randomness is fairly tricky... and Perl 3 went through this on a bunch of platforms where the random bits needed to be tuned per platform (before there was any sort of standardization between unixlikes, not to mention Windows, VMS, ...). Nobody noticed for several years that the randbits were wrong on various platforms --- and not all of those platforms were obscure. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130713] 42.expmod(-1,1) hangs
On Fri, Feb 3, 2017 at 4:33 PM, Elizabeth Mattijsen < perl6-bugs-follo...@perl.org> wrote: > Assume this is a MoarVM issue, as this does not appear to be an issue on > MoarVM. ...which of those was supposed to be something else? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130588] [BUG] Feed operators final sub / routine parens
On Thu, Jan 19, 2017 at 6:43 AM, Sam M wrote: > > "my string" ==> reverse > ===SORRY!=== Error while compiling: > Unsupported use of bare "reverse"; in Perl 6 please use .reverse if you > meant $_, or use an explicit invocant or argument, or use &reverse to refer > to the function as a noun > --> "my string" ==> reverse⏏; > > This bug is similar to https://rt.perl.org/Ticket/Display.html?id=112396 > Actually, it's not; it's just the "catch common perl 5 idioms that don't do the same thing in perl 6" (specifically, reliance on $_ as default parameter) interacting oddly with a semantic perl 5 didn't have. Arguably there should be a way to suppress the p5-trap in that situation. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130512] Proc::Async STDIN isn't handled correctly for all apps
On Wed, Jan 4, 2017 at 11:20 PM, David E. wrote: > SSH is one example. When using key-based logins everything works > perfectly. If not using key-based logins (as required for a certain piece > of hardware I need to work with), the password prompt is not captured by > Proc::Async. STDIN is read directly from the user shell, and the prompt > itself is never output from the 'tapped' stdout. Further, SSH will refuse > to get even that far if the "-T" parameter is not given to it. > > Screen is another example (I'm trying to use this because > Device::SerialPort hasn't been ported to Perl6 yet). No matter what I try, > screen always aborts with the error "Must be connected to a terminal." > Strictly speaking, this is not a bug: the interface for these kinds of programs is usually some variant of expect (the original being in Tcl, with versions for Perl 5, Python, and other languages). ptys are a more limited and more complex (and *far* less portable, in particular not possible on Windows) resource than pipes, and general subprocess interfaces usually aren't suitable; and adding the necessary logic to allow ptys to work properly complicates the common case considerably. The portability concern also means that pty support likely does not belong in Perl 6's core, but should be provided by a POSIX support module. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130460] Can we relax indir's test on the target directory?
On Tue, Jan 3, 2017 at 12:58 AM, Joachim Durchholz wrote: > > indir solves all these things. (Provided it changes the current directory > back even in the face of exceptions.) Edge case: current directory can't be re-entered by path (as with the old MMDF trick: daemon launcher running as root chdir()s to a directory via a path where one component is only searchable by root, then drops perms and runs the real daemon. Another way to do it is rename() or rmdir() one path component). This can be worked around if the platform supports fchdir(), otherwise you just can't get back where you were. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130460] Can we relax indir's test on the target directory?
On Fri, Dec 30, 2016 at 5:41 PM, Joachim Durchholz wrote: > > The usual reason would be portability, but at least Windows follows the > Posix path in this regard. But all bets are off if it's a network filesystem. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130443] [REGRESSION] [LTA] Trying to put an infinite range into a native array no longer throws (my int @a = ^Inf)
On Thu, Dec 29, 2016 at 1:43 PM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > I see 16 fail()s in src/core/native_array.pm and I'm unsure what the best > way to do this (lizmat, any idea?) > Is this making moritz's point on IRC yesterday? 2016 Dec 28 18:39:27 I think fail() was a mistake, and it's time we admitted it -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130339] make install failure on rakudo star 2016.11
On Wed, Dec 14, 2016 at 8:39 AM, mark carter wrote: > The perl 5 script "prove" was not found. Adding (for me, anyway) > > /usr/bin/core_perl > ...so Red Hat decided too many people had figured out how they broke Perl, and broke it even more to compensate? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #130217] [LTA] No warning when using complex rules as a character class (/<+ident>/)
On Tue, Nov 29, 2016 at 4:53 PM, Aleks-Daniel Jakimenko-Aleksejev < perl6-bugs-follo...@perl.org> wrote: > Obviously, the code above does not make any sense, which is why I think > Perl 6 should be smart enough to give a warning in this case. > Could be something like “attempt to use a complex rule as a character > class” or something along the lines. > There's another similar confusion that I asked the finder to file as a bug, but I don't recall if they did: if you define a rule named "before" or "after", it changes the meaning of the "" and "" constructs, which are still parsed as if they are lookahead/behind but then behave as the user defined rule (or as whatever the regex engine makes of trying to negate them, if you used those forms). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #128897] [LTA] [MATH] "-0".Num isn't negative
On Wed, Nov 23, 2016 at 1:53 AM, Zefram wrote: > There is no flag attached to a zero A status flag is not attached to a value, it is a processor status flag. Why would you say I claimed that? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #128897] [LTA] [MATH] "-0".Num isn't negative
And my own misspeaking was a slight mis-description of the relevance of signed zero in the ticket, which I corrected to Zoffix in IRC. On Wed, Nov 23, 2016 at 1:20 AM, Brandon Allbery wrote: > > On Wed, Nov 23, 2016 at 1:11 AM, Zefram wrote: > >> In which aspect did I misspeak? > > > iirc underflow doesn't work quite the way either you or Darren said; it's > not just the signed zero, it's also a status flag indicating that that > signed zero reflects an underflow condition. What it is not is a separate > value as Darren seemed to think. But it's also not merely the signed zero, > although in some cases that may be sufficient. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #128897] [LTA] [MATH] "-0".Num isn't negative
On Wed, Nov 23, 2016 at 1:11 AM, Zefram wrote: > In which aspect did I misspeak? iirc underflow doesn't work quite the way either you or Darren said; it's not just the signed zero, it's also a status flag indicating that that signed zero reflects an underflow condition. What it is not is a separate value as Darren seemed to think. But it's also not merely the signed zero, although in some cases that may be sufficient. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #128897] [LTA] [MATH] "-0".Num isn't negative
Zefrem and I both misspoke on this, but I clarified on IRC and this was iirc already fixed as a result. On Tue, Nov 22, 2016 at 11:33 PM, Darren Duncan wrote: > And here I thought IEEE floats had distinct values to represent overflows > and underflows that were distinct from both the zeros and the infinities. > -- Darren Duncan > > On 2016-11-22 8:19 PM, Zefram wrote: > >> Zoffix Znet via RT wrote: >> >>> The reason we have a negative floating point zero at all is more due to >>> underlying implementations at whose level such zeros are used to signal >>> various exceptions. >>> >> >> No, that's not what negative zero is about in floating point. (Maybe >> you're thinking of ones-complement integer formats.) In floating point, >> zero doesn't only represent exact zero quantities, it also represents >> underflow, and it's useful to know from which side of zero a quantity >> underflowed. Generally, IEEE 754 provides well defined semantics >> for signed zeroes throughout, which put negative zero on a par with >> positive zero. >> >> Are you able to describe any usecases where the string cast resulting >>> in a positive zero as opposed to negative zero creates a problem? >>> >> >> Getting the right zero particularly matters in trigonometry and in complex >> arithmetic, where the zeroes are on opposite sides of many branch cuts. >> For example: >> >> atan2(0e0, -1) >>> >> 3.14159265358979 >> >>> atan2(-0e0, -1) >>> >> -3.14159265358979 >> >> The above behaviour is correct and desirable. In a situation where the >> arguments come from string input, getting this correct behaviour depends >> on the Str->Num conversion properly supporting signed zeroes. >> >> -zefram >> >> > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #128897] [LTA] [MATH] "-0".Num isn't negative
On Thu, Nov 17, 2016 at 10:13 AM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > > The reason we have a negative floating point zero at all is more due to > underlying implementations at whose level such zeros are used to signal > various exceptions. But such usage isn't needed on Perl 6 level. IEEE supports negative zero because it is useful when working with limits of series. Are you suggesting Perl 6 should not support this usage? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #129994] [NATIVECALL][BUG] C functions required to be called once in one thread are hung up
On Tue, Nov 1, 2016 at 12:01 PM, Itsuki Toyota wrote: > I think I properly call the MeCab functions from Perl 6(e.g. > $model.create-tagger, $model.create-lattice) according to the above > instructions. > So I think something is wrong in the NativeCall. > Not sure NativeCall even knows about TLS as yet. Probably needs a new attribute for functions that use TLS, and code to ensure those always run on the same thread. (This also needs to group functions so they will all use the same thread... which, given the usage for this particular library, may need to be dynamic where the init call picks an available thread and "pins" it for subsequent calls. Which will be tricky, because it needs to be attached to the object returned by init. Urgh.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #129994] [NATIVECALL][BUG] C functions required to be called once in one thread are hung up
On Tue, Nov 1, 2016 at 12:01 PM, Itsuki Toyota wrote: > I think I properly call the MeCab functions from Perl 6(e.g. > $model.create-tagger, $model.create-lattice) according to the above > instructions. > So I think something is wrong in the NativeCall. > Not sure NativeCall even knows about TLS as yet. Probably needs a new attribute for functions that use TLS, and code to ensure those always run on the same thread. (This also needs to group functions so they will all use the same thread... which, given the usage for this particular library, may need to be dynamic where the init call picks an available thread and "pins" it for subsequent calls. Which will be tricky, because it needs to be attached to the object returned by init. Urgh.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #129986] Constraints on ‘our’-scoped variables are not allowed (our Int $x)
On Sat, Oct 29, 2016 at 12:04 PM, Aleks-Daniel Jakimenko-Aleksejev < perl6-bugs-follo...@perl.org> wrote: > This is the commit that added these messages > https://github.com/rakudo/rakudo/commit/bfd8508f5ceee565380da201ef25bd > fb6feb2b3d > https://github.com/rakudo/rakudo/commit/bfd8508f5ceee565380da201ef25bdfb6feb2b3d#diff-deae5f68054ef8116f04d6cb78bc4395L1903 shows the messages were there before, just in a different place. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: [perl #129830] [BUG] Cannot call .type method on an Array instance
[08 02:06:10] m: class TypeHouse { has Int @.array; }; dd TypeHouse.^attributes[0]; [08 02:06:11] rakudo-moar 2285d3: OUTPUT«Attribute @!array = Attribute.new [08 02:06:11] » [08 02:06:24] m: class TypeHouse { has Int @.array; }; dd TypeHouse.^attributes[0].type; [08 02:06:25] rakudo-moar 2285d3: OUTPUT«Positional[Int] [08 02:06:25] » So it's the implicit .gist done by say on the type object that is dying, not something on the way to it. (This may be expected.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net