Re: [perl #133541] Grammer bug vs

[Brandon Allbery via RT]

"_" 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

[Brandon Allbery]

"_" 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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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)

[Brandon Allbery via RT]

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)

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery via RT]

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

[Brandon Allbery via RT]

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(); await $proc.start;'
>
> y
> y
> y
> y
> y
> y
> y
> y
> ...
>
>
> I think tap() 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

[Brandon Allbery]

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(); await $proc.start;'
>
> y
> y
> y
> y
> y
> y
> y
> y
> ...
>
>
> I think tap() 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)

[Brandon Allbery via RT]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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))

[Brandon Allbery via RT]

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))

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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

[Brandon Allbery]

> 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

[Brandon Allbery]

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")

[Brandon Allbery via RT]

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")

[Brandon Allbery]

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 )

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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

[Brandon Allbery via RT]

On Mon, Jul 17, 2017 at 4:20 AM, Joachim Durchholz <j...@durchholz.org> wrote:

> Am 17.07.2017 um 09:32 schrieb Brandon Allbery:
> > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz <j...@durchholz.org
> > <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

[Brandon Allbery]

On Mon, Jul 17, 2017 at 4:20 AM, Joachim Durchholz <j...@durchholz.org> wrote:

> Am 17.07.2017 um 09:32 schrieb Brandon Allbery:
> > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz <j...@durchholz.org
> > <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

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery via RT]

'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

[Brandon Allbery]

'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]

[Brandon Allbery via RT]

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]

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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)

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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

[Brandon Allbery via RT]

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’.)

[Brandon Allbery]

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])

[Brandon Allbery]

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])

[Brandon Allbery]

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

[Brandon Allbery]

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) {…})

[Brandon Allbery]

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

[Brandon Allbery]

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

[Brandon Allbery]

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

[Brandon Allbery]

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

[Brandon Allbery]

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 <zef...@fysh.org> 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

[Brandon Allbery]

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 <zef...@fysh.org> 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

[Brandon Allbery]

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 #128526] [CONC] Proc::Async's .write appears to exit when the process run doesn't exist

[Brandon Allbery]

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

[Brandon Allbery]

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

[Brandon Allbery]

On Thu, Mar 2, 2017 at 8:56 AM, Brandon Allbery <allber...@gmail.com> 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

[Brandon Allbery]

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

[Brandon Allbery]

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)

[Brandon Allbery]

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 <allber...@gmail.com>
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 <allber...@gmail.com> 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 <allber...@gmail.com>
>> > 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 <l...@dijkmat.nl>
>> >> 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)

[Brandon Allbery]

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 <allber...@gmail.com> 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 <allber...@gmail.com>
> > 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 <l...@dijkmat.nl>
> >> 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)

[Brandon Allbery]

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 <allber...@gmail.com>
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 <l...@dijkmat.nl>
> 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)

[Brandon Allbery]

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?

[Brandon Allbery]

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/perl6␤CompUnit::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

[Brandon Allbery]

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

[Brandon Allbery]

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

[Brandon Allbery]

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  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 #130460] Can we relax indir's test on the target directory?

[Brandon Allbery]

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?

[Brandon Allbery]

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)

[Brandon Allbery]

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

[Brandon Allbery]

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>/)

[Brandon Allbery]

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

[Brandon Allbery]

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

[Brandon Allbery]

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 <allber...@gmail.com>
wrote:

>
> On Wed, Nov 23, 2016 at 1:11 AM, Zefram <zef...@fysh.org> 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

[Brandon Allbery]

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

[Brandon Allbery]

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

[Brandon Allbery]

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

[Brandon Allbery via RT]

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

[Brandon Allbery]

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)

[Brandon Allbery]

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

[Brandon Allbery via RT]

[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

Re: [perl #129830] [BUG] Cannot call .type method on an Array instance

[Brandon Allbery]

[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

Re: [perl #129820] [NATIVECALL][LTA] callback returns useless error message

[Brandon Allbery via RT]

On Thu, Oct 6, 2016 at 1:48 PM, Brandon Allbery via RT <
perl6-bugs-follo...@perl.org> wrote:

> I believe this is known. and it's difficult to fix: you simply can't map
> exceptions across languages, so an exception in a Perl callback from a C
> function called from Perl can only be caught in the context of the callback
> itself. C has no clue about the exception, so you can neither catch it in C
>

Actually, now that I think about it, there is something that can be done;
not ideal, but the best we could do under the circumstances. Callbacks
should be given default exception handlers that at minimum output the
original exception (which currently is being lost when finding the
exception handler fails) and say they're aborting because there's no way to
pass the exception back through C to the outer Perl scope. Something like:

Exception in Perl callback cannot be passed back through native code.
All we can do is die. Sorry.
Unhandled exception:
(actual thrown exception here)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #129820] [NATIVECALL][LTA] callback returns useless error message

[Brandon Allbery]

On Thu, Oct 6, 2016 at 1:48 PM, Brandon Allbery via RT <
perl6-bugs-follo...@perl.org> wrote:

> I believe this is known. and it's difficult to fix: you simply can't map
> exceptions across languages, so an exception in a Perl callback from a C
> function called from Perl can only be caught in the context of the callback
> itself. C has no clue about the exception, so you can neither catch it in C
>

Actually, now that I think about it, there is something that can be done;
not ideal, but the best we could do under the circumstances. Callbacks
should be given default exception handlers that at minimum output the
original exception (which currently is being lost when finding the
exception handler fails) and say they're aborting because there's no way to
pass the exception back through C to the outer Perl scope. Something like:

Exception in Perl callback cannot be passed back through native code.
All we can do is die. Sorry.
Unhandled exception:
(actual thrown exception here)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #129820] [NATIVECALL][LTA] callback returns useless error message

[Brandon Allbery via RT]

On Thu, Oct 6, 2016 at 1:39 PM, Itsuki Toyota 
wrote:

> In the following example, ` my  = sub (Int $piyo) ` has wrong
> signature (` my  = sub (Int $piyo, Num $fuga) ` is a right one)and
> it returns the error message of "Internal error: Unwound entire stack and
> missed handler".
> Honestly to say, it doesn't seem to make sense to me and I can't imagine
> what to do.
>

I believe this is known. and it's difficult to fix: you simply can't map
exceptions across languages, so an exception in a Perl callback from a C
function called from Perl can only be caught in the context of the callback
itself. C has no clue about the exception, so you can neither catch it in C
nor have C relay it to the original Perl context. The error is, not very
clearly (or rather, saying it clearly but in terms of internals), saying
this: it can't find an exception handler in the callback's Perl context
(and, implicitly, it can never reach one outside of the callback's
context). Distilling this down to a short error message is a bit difficult.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #129820] [NATIVECALL][LTA] callback returns useless error message

[Brandon Allbery]

On Thu, Oct 6, 2016 at 1:39 PM, Itsuki Toyota 
wrote:

> In the following example, ` my  = sub (Int $piyo) ` has wrong
> signature (` my  = sub (Int $piyo, Num $fuga) ` is a right one)and
> it returns the error message of "Internal error: Unwound entire stack and
> missed handler".
> Honestly to say, it doesn't seem to make sense to me and I can't imagine
> what to do.
>

I believe this is known. and it's difficult to fix: you simply can't map
exceptions across languages, so an exception in a Perl callback from a C
function called from Perl can only be caught in the context of the callback
itself. C has no clue about the exception, so you can neither catch it in C
nor have C relay it to the original Perl context. The error is, not very
clearly (or rather, saying it clearly but in terms of internals), saying
this: it can't find an exception handler in the callback's Perl context
(and, implicitly, it can never reach one outside of the callback's
context). Distilling this down to a short error message is a bit difficult.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #122732] [jvm] control operator crossed continuation barrier

[Brandon Allbery]

On Wed, Sep 21, 2016 at 2:58 PM, Christian Bartolomaeus via RT <
perl6-bugs-follo...@perl.org> wrote:

> I must admit that I don't understand the purpose of the two lines I
> removed from src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java. They were
> added with nqp commit bfee0177b1 back in 2013.
>

I don't recall either, but as rakudo was IIRC changed within the past few
months to use control exceptions for `return`, it's not that surprising
that they cause problems now.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #129261] accessing a class attribute too early nils it/leaves it uninitialized

[Brandon Allbery]

On Mon, Sep 12, 2016 at 11:40 PM, Brian S. Julin <
perl6-bugs-follo...@perl.org> wrote:

> $ perl6 -e 'class A { my $.bar = 42; }; class D { constant bar =
> A.bar.say; }; A.bar.say'
> (Any)
> (Any)
>

The first one is expected, as the bodies of class definitions run at
compile time but initializers at run time. I don't know why the second one
happens, though.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net