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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #131965] Shaped arrays can't have zero size

[Brandon Allbery via RT]

> 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 via RT]

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 #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 #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 via RT]

On Mon, Jul 17, 2017 at 4:20 AM, Joachim Durchholz  wrote:

> Am 17.07.2017 um 09:32 schrieb Brandon Allbery:
> > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz  > > 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 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 #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 #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 #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 #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 #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 #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 #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 #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 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 #129240] [NativeCall] nativesizeof routine returns the different result from sizeof function in C when it takes a CArray object as an argument.

[Brandon Allbery via RT]

On Sat, Sep 10, 2016 at 10:11 AM, Itsuki Toyota <
perl6-bugs-follo...@perl.org> wrote:

> $ perl6 -MNativeCall -e 'my $null = Pointer; my $not-null =
> CArray[int32].new; $not-null[0] = 1; $not-null[1] = 1; $not-null[2] = 1;
> say nativesizeof($not-null)'
> 8
>

That size looks doubly wrong to me. Its not going to happen for a 3-element
array no matter how you slice it... so I suspect you're getting the size of
one element, which is itself twice the size of what C thinks.

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

Re: [perl #128831] t/spec/S16-io/eof.t is unportably assuming that /proc/1/comm exists

[Brandon Allbery via RT]

On Wed, Aug 3, 2016 at 3:12 PM, Nicholas Clark  wrote:

> I don't know what file would be safer. Maybe mem?


None of them. There's no guarantee that /proc exists (non-SVR4 commercial
Unixes), or that it is in any way compatible with Linux's notion of /proc
(FreeBSD, commercial SVR4 that didn't add Linux compatibility names like
Solaris did).

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

Re: [perl #128049] [BUG] "Cannot look up attributes in a type object" error has occurred in the context of using NativeCall

[Brandon Allbery via RT]

On Mon, May 2, 2016 at 9:20 AM, Elizabeth Mattijsen  wrote:
>
> You should probably rename your method “new” to BUILD, so that the default
> .new() implementation can find it.


Could definition of a method new throw a worry or something, pointing
people to BUILD and/or the object documentation?

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

Re: [perl #127482] Compilation check says Syntax OK but program gets error

[Brandon Allbery via RT]

On Sat, Feb 6, 2016 at 8:24 PM, James E Keenan  wrote:

> $ perl6 attempted_printf.pl6
> Type check failed in binding $format; expected Cool but got Pair
>   in block  at attempted_printf.pl6 line 5
>

The syntax is fine. The semantics aren't, and even simpler cases than
printf are NYI; printf itself is even harder to get right.

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

Re: [perl #127355] rakudo configuration and build overly dependent on specific version

[Brandon Allbery via RT]

On Mon, Jan 25, 2016 at 11:00 AM, Will Coleda via RT <
perl6-bugs-follo...@perl.org> wrote:

> 3) Try the macport version. It's possible that might work, even on your
> machine. No promises.
>

You could also get a modern cURL and git from MacPorts/Homebrew/whatever.
Note that your OS certificate store will also probably be too old, so you
will need some way to get updated certs where they will be found; on
MacPorts this will be the curl-ca-bundle port. (You may need to do extra
work to make these visible to programs using Carbon/Cocoa APIs; by default
they will only be seen by BSD APIs.)

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

Re: [perl #127308] Configure.pl with moar fails to find C compiler on older Darwin

[Brandon Allbery via RT]

On Thu, Jan 21, 2016 at 2:29 PM, Tobias Leich via RT <
perl6-bugs-follo...@perl.org> wrote:

> Can't we do something like this[^1] on darwin also?
>
> [^1] https://github.com/MoarVM/MoarVM/blob/master/build/setup.pm#L445
>
> Like, checking for the existance of clang, and falling back to gcc?
>

gcc and llvm-gcc-4.2 are symlinks to clang in later versions of xcode, so
that should work.

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

Re: [perl #127308] Configure.pl with moar fails to find C compiler on older Darwin

[Brandon Allbery via RT]

On Wed, Jan 20, 2016 at 11:37 AM, Steve Mynott 
wrote:

> My guess is that the PPC version of OS X probably still has the real
> GCC as its compiler rather than clang as on more modern systems.
>

This will also be true of Intel-based Macs with Xcode 3.x or earlier
(roughly OS X 10.6 and earlier).

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