[perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)

2017-10-21 Thread Aleks-Daniel Jakimenko-Aleksejev via RT 
You're right, sorry, I should've been more clear.

Tickets are not closed without tests, but as you pointed out not everything
should be spec-ed. That's correct. Therefore, some tests go to
https://github.com/rakudo/rakudo/tree/nom/t (these tests can be changed at any
moment and don't serve as a guarantee for anything, they exist merely to keep
rakudo from regressing).
I don't know if there are docs on that topic anywhere. I mentioned it in the
squashathon guide
(https://github.com/rakudo/rakudo/wiki/Rakudo-SQUASHathon-Guide#resolving-testneeded-tickets)
but we probably need a proper explanation somewhere.

On 2017-10-21 11:54:34, allber...@gmail.com wrote:
> 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.
>

Re: who own my code?

2017-10-21 Thread Brandon Allbery 
On Sat, Oct 21, 2017 at 5:56 AM, ToddAndMargo  wrote:

> On Sat, Oct 21, 2017 at 12:57 AM, ToddAndMargo >> > wrote:
>>> On 10/21/2017 12:40 AM, ToddAndMargo wrote:
>>>
>>> If I write a program for a customer who pays my labor to
>>> write it, who own the program?  Me or the customer?
>>>
>>>
>>> I am a private contractor.  What they payed me for fixing a/the
>>> problem.  They don't care how.  I was wondering if they owned
>>> any of the code I wrote to fix the problem.  The customer did
>>> not specifically ask me to write anything.
>>>
>>>
> On 10/21/2017 01:07 AM, Brent Laabs wrote:
>
>> This depends on the contract you signed with the customer, and laws in
>> your local jurisdiction.  As such, it's probably a question more
>> appropriate to ask a lawyer than this list.
>>
>>
> There is no contract involved.  The customer wants a problem fixed.
> He does not want to know how.  And he is not commissioning me for
> any software.  Just a fix.
>

My working assumption in this case is that for fixing/patching existing
software, any code is subject to the original copyright and ownership;
because I am working as an agent for the customer, new stuff is owned by
the customer unless specified otherwise.

BUT.

If this situation comes up, you need to be talking to the *customer* about
it. It doesn't necessarily need to be a formal contract, but the final
decision should be in writing and you and the customer should both have
signed copies of it in case questions come up in the future.

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

2017-10-21 Thread 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)

2017-10-21 Thread 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

[perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)

2017-10-21 Thread Aleks-Daniel Jakimenko-Aleksejev via RT 
“I don't think we should force all future implementations to add BUILDALL.”

Not sure what this remark is for. Can be rakudo tests.

On 2017-10-21 09:12:32, brad 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.
> Especially since Rakudo didn't need this added to work correctly.
>
> > On 2017-10-13 04:50:32, elizabeth wrote:
> > > > On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via
> > > > RT)
> > > >  wrote:
> > > >
> > > > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> > > > # Please include the string: [perl #132283]
> > > > # in the subject line of all future correspondence about this
> > > > issue.
> > > > # https://rt.perl.org/Ticket/Display.html?id=132283 >
> > > >
> > > >
> > > > Code:
> > > > class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say
> > > > $f.^methods;
> > > >
> > > > ¦«2015.12»:
> > > > (bar)
> > > >
> > > > ¦«2016.06»:
> > > > (bar)
> > > >
> > > > ¦«2016.12»:
> > > > (bar)
> > > >
> > > > ¦«2017.06»:
> > > > (bar)
> > > >
> > > > ¦«f72be0f130cf»:
> > > > (bar BUILDALL)
> > > >
> > > >
> > > >
> > > > Bisectable points at two relevant commits:
> > > > First it was BUILDALL_UNDER_CONSTRUCTION after
> > > >
> >
https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc
> > > > Now it is BUILDALL after
> > > >
> >
https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
> > > >
> > > >
> > > > I don't know if BUILDALL should be listed or not. My gut feeling
> > > > says
> > > > that it shouldn't be, but feel free to argue otherwise. I'm just
> > > > the
> > > > messenger.
> > >
> > > Well, it *is* an auto-generated method that is installed in the
> > > namespace. Just like “bar”. So either we should show both, or
> > > neither. Or introduce a flag to include/exclude auto-generated
> > > methods. But then we would need to mark those methods as auto-
> > > generated somehow.
>
> I think BUILDALL is different than bar for several reasons,
> it is all uppercase (which usually means it is special)
> it is only an optimization
> the programmer didn't use a pragma to add it
> the programmer didn't even implicitly declare it
>
> (I mean that ｢has $.bar｣ as an implicit declaration
> of a method of the same name)
>
> So I think discussing whether this use of BUILDALL needs to be hidden
> can be
> discussed independently of whether an atribute method needs to be
> hidden.

[perl #132339] [REGRESSION] =SEE-ALSO pod comment can no longer be parsed (=SEE-ALSO foo)

2017-10-21 Thread Aleks-Daniel Jakimenko-Aleksejev via RT 
And also:
https://github.com/tadzik/perl6-Acme-Meow/blob/35286b14447d22516fbf68767c4d7e18b7396971/lib/Acme/Meow.pm#L65-L69
https://github.com/skids/perl6-Control-Bail/blob/3e6ab6c3bab9176a44476bd0883ba99205306400/lib/Control/Bail.pm6#L81
https://github.com/tadzik/Grammar-BNF/blob/14f51ca5882f00f0acee643c9845ab37559b5119/lib/Grammar/ABNF.pm#L435

On 2017-10-21 11:07:33, alex.jakime...@gmail.com wrote:
> Just for the record, there was another module affected by this:
> https://github.com/nkh/P6-Text-
>
Template/blob/5e1752c08ddb064e366be862fd500c4de0c4b833/lib/Text/Template.pm#L142
>
> On 2017-10-21 10:44:51, c...@zoffix.com wrote:
> > On Sat, 21 Oct 2017 09:06:24 -0700, alex.jakime...@gmail.com wrote:
> > > Code:
> > > =SEE-ALSO foo
> > >
> > >
> > > ¦«2017.09,963a0f0657^»:
> > >
> > >
> > > ¦«963a0f0,HEAD(312cac7)»:
> > > ===SORRY!=== Error while compiling /tmp/8cNEnQJfmq
> > > Preceding context expects a term, but found infix = instead
> > > at /tmp/8cNEnQJfmq:1
> > > --> =SEE⏏-ALSO foo «exit code = 1»
> > >
> > >
> > > Bisected to
> > >
>
https://github.com/rakudo/rakudo/commit/963a0f0657abaa0431d465e601c75b50462b4cd2
> > >
> > > So it is probably related to || fixes in :ratchet mode.
> > >
> > > Maybe worth mentioning that lowercase “see-also” seems to be ok.
> > >
> > > This was toasted from a real module:
> > >
>
https://github.com/skids/perl6xproto/blob/6750e05da9b70b180eeaebaeb9e15d35d5856cd3/lib/X/Protocol.pm6#L185
> >
> >
> > Thank you for the report. This is now fixed.
> >
> > Fix: https://github.com/rakudo/rakudo/commit/ba718f4581a95e1
> > Test: https://github.com/perl6/roast/commit/2ede0d1fc3f2e0536

[perl #132339] [REGRESSION] =SEE-ALSO pod comment can no longer be parsed (=SEE-ALSO foo)

2017-10-21 Thread Aleks-Daniel Jakimenko-Aleksejev via RT 
Just for the record, there was another module affected by this:
https://github.com/nkh/P6-Text-Template/blob/5e1752c08ddb064e366be862fd500c4de0c4b833/lib/Text/Template.pm#L142

On 2017-10-21 10:44:51, c...@zoffix.com wrote:
> On Sat, 21 Oct 2017 09:06:24 -0700, alex.jakime...@gmail.com wrote:
> > Code:
> > =SEE-ALSO foo
> >
> >
> > ¦«2017.09,963a0f0657^»:
> >
> >
> > ¦«963a0f0,HEAD(312cac7)»:
> > ===SORRY!=== Error while compiling /tmp/8cNEnQJfmq
> > Preceding context expects a term, but found infix = instead
> > at /tmp/8cNEnQJfmq:1
> > --> =SEE⏏-ALSO foo «exit code = 1»
> >
> >
> > Bisected to
> >
https://github.com/rakudo/rakudo/commit/963a0f0657abaa0431d465e601c75b50462b4cd2
> >
> > So it is probably related to || fixes in :ratchet mode.
> >
> > Maybe worth mentioning that lowercase “see-also” seems to be ok.
> >
> > This was toasted from a real module:
> >
https://github.com/skids/perl6xproto/blob/6750e05da9b70b180eeaebaeb9e15d35d5856cd3/lib/X/Protocol.pm6#L185
>
>
> Thank you for the report. This is now fixed.
>
> Fix: https://github.com/rakudo/rakudo/commit/ba718f4581a95e1
> Test: https://github.com/perl6/roast/commit/2ede0d1fc3f2e0536

[perl #132341] [BUG] Pod 6 table handling should ensure table rows have the same number of cells even if they are empty

2017-10-21 Thread via RT 
# New Ticket Created by  Tom Browder 
# Please include the string:  [perl #132341]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132341 >


Consider the following pod 6 tables:

=begin table
a | b | c
m | n | o
x | y
=end table

my $r =  $=pod[0];
is $r.contents.elems, 3;
is $r.contents[0].join(','), 'a,b,c'; # 3 cells
is $r.contents[1].join(','), 'l,m,n'; # 3 cells
is $r.contents[2].join(','), 'x,y';# 2 cells; should change to
"x,y," after a fix for this bug  (3 cells vs 2)

=table
X | O |
   ---+---+---
  | X | O
   ---+---+---
  |   | X

$r = $=pod[1];
is $r.contents.elems, 3;
is $r.contents[0].join(','), 'X,O';   # 2 cells; should change to
"X,O," after a fix for this bug (3 cells vs 2)
is $r.contents[1].join(','), ',X,O';  # 3 cells
is $r.contents[2].join(','), ',,X'; # 3 cells

[perl #132339] [REGRESSION] =SEE-ALSO pod comment can no longer be parsed (=SEE-ALSO foo)

2017-10-21 Thread Zoffix Znet via RT 
On Sat, 21 Oct 2017 09:06:24 -0700, alex.jakime...@gmail.com wrote:
> Code:
> =SEE-ALSO foo
> 
> 
> ¦«2017.09,963a0f0657^»:
> 
> 
> ¦«963a0f0,HEAD(312cac7)»:
> ===SORRY!=== Error while compiling /tmp/8cNEnQJfmq
> Preceding context expects a term, but found infix = instead
> at /tmp/8cNEnQJfmq:1
> --> =SEE⏏-ALSO foo «exit code = 1»
> 
> 
> Bisected to
> https://github.com/rakudo/rakudo/commit/963a0f0657abaa0431d465e601c75b50462b4cd2
> 
> So it is probably related to || fixes in :ratchet mode.
> 
> Maybe worth mentioning that lowercase “see-also” seems to be ok.
> 
> This was toasted from a real module:
> https://github.com/skids/perl6xproto/blob/6750e05da9b70b180eeaebaeb9e15d35d5856cd3/lib/X/Protocol.pm6#L185


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/ba718f4581a95e1
Test: https://github.com/perl6/roast/commit/2ede0d1fc3f2e0536

[perl #132339] [REGRESSION] =SEE-ALSO pod comment can no longer be parsed (=SEE-ALSO foo)

2017-10-21 Thread Zoffix Znet via RT 
On Sat, 21 Oct 2017 09:06:24 -0700, alex.jakime...@gmail.com wrote:
> Code:
> =SEE-ALSO foo
> 
> 
> ¦«2017.09,963a0f0657^»:
> 
> 
> ¦«963a0f0,HEAD(312cac7)»:
> ===SORRY!=== Error while compiling /tmp/8cNEnQJfmq
> Preceding context expects a term, but found infix = instead
> at /tmp/8cNEnQJfmq:1
> --> =SEE⏏-ALSO foo «exit code = 1»
> 
> 
> Bisected to
> https://github.com/rakudo/rakudo/commit/963a0f0657abaa0431d465e601c75b50462b4cd2
> 
> So it is probably related to || fixes in :ratchet mode.
> 
> Maybe worth mentioning that lowercase “see-also” seems to be ok.
> 
> This was toasted from a real module:
> https://github.com/skids/perl6xproto/blob/6750e05da9b70b180eeaebaeb9e15d35d5856cd3/lib/X/Protocol.pm6#L185


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/ba718f4581a95e1
Test: https://github.com/perl6/roast/commit/2ede0d1fc3f2e0536

Re: [perl #132330] Sets can be equal even though their elements aren’t

2017-10-21 Thread Elizabeth Mattijsen 
Which goes back to the behaviour of nqp::unbox_n():

$ 6 'use nqp; say nqp::unbox_n(1e0); say nqp::unbox_n(1e0 + 4e-15)'
1
1


> On 21 Oct 2017, at 11:30, Elizabeth Mattijsen  wrote:
> 
> The problem is that both these values have the same .WHICH:
> 
> $ 6 'say 1e0.WHICH; say (1e0 + 4e-15).WHICH'
> Num|1
> Num|1
> 
> Nothing to do with Sets/Bags/Mixes/object hashes.
> 
>> On 20 Oct 2017, at 17:02, Victor ADAM (via RT) 
>>  wrote:
>> 
>> # New Ticket Created by  Victor ADAM 
>> # Please include the string:  [perl #132330]
>> # in the subject line of all future correspondence about this issue. 
>> # https://rt.perl.org/Ticket/Display.html?id=132330 >
>> 
>> 
>> How to reproduce
>> 
>> 
>> perl6 -e 'my ($a, $b) = set(1e0), set(1e0 + 4e-15); say $a ~~ $b,
>> $a.keys »≅« $b.keys'
>> 
>> Expected behavior
>> -
>> 
>> Prints `False(False)`.
>> 
>> Actual behavior
>> ---
>> 
>> Prints `True(False)`.
>> 
>> This contradicts the documentation of the Setty ACCEPTS method:
>> “Returns True if $other and self contain all the same elements, and no
>> others.” The sets’ elements aren’t equal, or even approximately equal
>> (≅), and yet ACCEPTS (~~) returns `True`.
>> 
>> Note that other set methods show similar behavior: `1e0 ⊖ (1e0 +
>> 4e-15)` is the empty set, `set(1e0, 1e0 + 4e-15)` only has one
>> element…
>> 
>> Version information
>> ---
>> 
>> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
>> implementing Perl 6.c.

[perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)

2017-10-21 Thread Brad Gilbert via RT 
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.
Especially since Rakudo didn't need this added to work correctly.

> On 2017-10-13 04:50:32, elizabeth wrote:
> > > On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> > >  wrote:
> > >
> > > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> > > # Please include the string: [perl #132283]
> > > # in the subject line of all future correspondence about this
> > > issue.
> > > # https://rt.perl.org/Ticket/Display.html?id=132283 >
> > >
> > >
> > > Code:
> > > class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say
> > > $f.^methods;
> > >
> > > ¦«2015.12»:
> > > (bar)
> > >
> > > ¦«2016.06»:
> > > (bar)
> > >
> > > ¦«2016.12»:
> > > (bar)
> > >
> > > ¦«2017.06»:
> > > (bar)
> > >
> > > ¦«f72be0f130cf»:
> > > (bar BUILDALL)
> > >
> > >
> > >
> > > Bisectable points at two relevant commits:
> > > First it was BUILDALL_UNDER_CONSTRUCTION after
> > >
> https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc
> > > Now it is BUILDALL after
> > >
> https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
> > >
> > >
> > > I don't know if BUILDALL should be listed or not. My gut feeling
> > > says
> > > that it shouldn't be, but feel free to argue otherwise. I'm just
> > > the
> > > messenger.
> >
> > Well, it *is* an auto-generated method that is installed in the
> > namespace. Just like “bar”. So either we should show both, or
> > neither. Or introduce a flag to include/exclude auto-generated
> > methods. But then we would need to mark those methods as auto-
> > generated somehow.

I think BUILDALL is different than bar for several reasons,
it is all uppercase (which usually means it is special)
it is only an optimization
the programmer didn't use a pragma to add it
the programmer didn't even implicitly declare it

(I mean that ｢has $.bar｣ as an implicit declaration
of a method of the same name)

So I think discussing whether this use of BUILDALL needs to be hidden can be
discussed independently of whether an atribute method needs to be hidden.

[perl #132339] [REGRESSION] =SEE-ALSO pod comment can no longer be parsed (=SEE-ALSO foo)

2017-10-21 Thread via RT 
# New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
# Please include the string:  [perl #132339]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132339 >


Code:
=SEE-ALSO foo


¦«2017.09,963a0f0657^»:


¦«963a0f0,HEAD(312cac7)»:
===SORRY!=== Error while compiling /tmp/8cNEnQJfmq
Preceding context expects a term, but found infix = instead
at /tmp/8cNEnQJfmq:1
--> =SEE⏏-ALSO foo «exit code = 1»


Bisected to 
https://github.com/rakudo/rakudo/commit/963a0f0657abaa0431d465e601c75b50462b4cd2

So it is probably related to || fixes in :ratchet mode.

Maybe worth mentioning that lowercase “see-also” seems to be ok.

This was toasted from a real module: 
https://github.com/skids/perl6xproto/blob/6750e05da9b70b180eeaebaeb9e15d35d5856cd3/lib/X/Protocol.pm6#L185

[perl #126721] $/ in closure arg of subst

2017-10-21 Thread Zoffix Znet via RT 
On Mon, 23 Nov 2015 19:40:36 -0800, raiph wrote:
> What I did
> ==
> 
> $/ := "Uhoh";
> put "Foo".subst: /Foo/, -> $/ {$/};
> put "Foo".subst: /Foo/, -> $/ {$/} for 1;
> put "Foo".subst: /Foo/,   {$/};
> put "Foo".subst: /Foo/,   {$/} for 1;
> 
> What I expected
> ===
> 
> FooFooFooFoo
> 
> What I got
> ==
> 
> FooFooUhohUhoh
> 
> Is it a bug?
> 
> 
> The way it's working now might make sense from a purist pov but not a
> pragmatic or Perlish one imo. I'm hoping this will be obvious to
> whoever reads this so I'll defer giving a detailed rationale for
> calling this a bug in the anticipation that it won't be necessary. :)
> 
> Does it look like any other bug?
> 
> 
> Yes, at least the previously resolved s/// bug #118705.
> 
> See also http://www.perlmonks.org/?node_id=1148378


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/738908be4d
Test: https://github.com/perl6/roast/commit/80a49c4324

[perl #126721] $/ in closure arg of subst

2017-10-21 Thread Zoffix Znet via RT 
On Mon, 23 Nov 2015 19:40:36 -0800, raiph wrote:
> What I did
> ==
> 
> $/ := "Uhoh";
> put "Foo".subst: /Foo/, -> $/ {$/};
> put "Foo".subst: /Foo/, -> $/ {$/} for 1;
> put "Foo".subst: /Foo/,   {$/};
> put "Foo".subst: /Foo/,   {$/} for 1;
> 
> What I expected
> ===
> 
> FooFooFooFoo
> 
> What I got
> ==
> 
> FooFooUhohUhoh
> 
> Is it a bug?
> 
> 
> The way it's working now might make sense from a purist pov but not a
> pragmatic or Perlish one imo. I'm hoping this will be obvious to
> whoever reads this so I'll defer giving a detailed rationale for
> calling this a bug in the anticipation that it won't be necessary. :)
> 
> Does it look like any other bug?
> 
> 
> Yes, at least the previously resolved s/// bug #118705.
> 
> See also http://www.perlmonks.org/?node_id=1148378


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/738908be4d
Test: https://github.com/perl6/roast/commit/80a49c4324

[perl #132283] [REGRESSION] BUILDALL is listed as one of the methods, maybe that's not right (say $foo.^methods)

2017-10-21 Thread Aleks-Daniel Jakimenko-Aleksejev via RT 
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.

On 2017-10-13 04:50:32, elizabeth wrote:
> > On 13 Oct 2017, at 07:52, Aleks-Daniel Jakimenko-Aleksejev (via RT)
> >  wrote:
> >
> > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
> > # Please include the string: [perl #132283]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=132283 >
> >
> >
> > Code:
> > class Foo { has $.bar }; my $f = Foo.new(bar=>'u'); say $f.^methods;
> >
> > ¦«2015.12»:
> > (bar)
> >
> > ¦«2016.06»:
> > (bar)
> >
> > ¦«2016.12»:
> > (bar)
> >
> > ¦«2017.06»:
> > (bar)
> >
> > ¦«f72be0f130cf»:
> > (bar BUILDALL)
> >
> >
> >
> > Bisectable points at two relevant commits:
> > First it was BUILDALL_UNDER_CONSTRUCTION after
> >
https://github.com/rakudo/rakudo/commit/9837687d93c907ec232b1c7635776aa0c7faa6bc
> > Now it is BUILDALL after
> >
https://github.com/rakudo/rakudo/commit/63cf246fd4caa43c52a212054a98e9b450c54127
> >
> >
> > I don't know if BUILDALL should be listed or not. My gut feeling says
> > that it shouldn't be, but feel free to argue otherwise. I'm just the
> > messenger.
>
> Well, it *is* an auto-generated method that is installed in the
> namespace. Just like “bar”. So either we should show both, or
> neither. Or introduce a flag to include/exclude auto-generated
> methods. But then we would need to mark those methods as auto-
> generated somehow.

[perl #122789] [BUG] `.subst` does not work inside BEGIN block ($/ is set too late)

2017-10-21 Thread Zoffix Znet via RT 
Fix:  
https://github.com/rakudo/rakudo/commit/a62b221a8048238edaa1f6e62070b42ed8bd5cd3
Test: https://github.com/perl6/roast/commit/9585230c26

[perl #122789] [BUG] `.subst` does not work inside BEGIN block ($/ is set too late)

2017-10-21 Thread Zoffix Znet via RT 
Fix:  
https://github.com/rakudo/rakudo/commit/a62b221a8048238edaa1f6e62070b42ed8bd5cd3
Test: https://github.com/perl6/roast/commit/9585230c26

[perl #126479] [IO] IO::Handle Supply is never done

2017-10-21 Thread Zoffix Znet via RT 
On Wed, 28 Oct 2015 17:41:39 -0700, hanenkamp wrote:
> Turning a socket or file into a Supply using .Supply works, but the
> reactor listening to those events cannot detect a close condition
> without using something like an interval to monitor for connection
> closure.
> 
> IO::Handle's Supply method should call use done to terminate the
> supply on eof/socket closure.


Tried on a few of 2015.* releases and couldn't reproduce the described issue.

There are roast tests for .Supply on sockets, handles, and cathandles. Closing.

[perl #126479] [IO] IO::Handle Supply is never done

2017-10-21 Thread Zoffix Znet via RT 
On Wed, 28 Oct 2015 17:41:39 -0700, hanenkamp wrote:
> Turning a socket or file into a Supply using .Supply works, but the
> reactor listening to those events cannot detect a close condition
> without using something like an interval to monitor for connection
> closure.
> 
> IO::Handle's Supply method should call use done to terminate the
> supply on eof/socket closure.


Tried on a few of 2015.* releases and couldn't reproduce the described issue.

There are roast tests for .Supply on sockets, handles, and cathandles. Closing.

[perl #124527] [BOGUSTEST] [REGEX] S05-metasyntax/interpolating-closure.t line:28 reason: 'dunno'

2017-10-21 Thread Sam S. via RT 
This look like a bogus test to me.

On the RHS of the ~~ operator, `$_` is bound to the LHS string "aaabccc".

`$var ??` evaluates the regex $var in boolean context, which causes it to match 
against this string.

Since there is no match, this causes the ternary operator to return the 
`rx{abc}` branch, which in turn matches at the current position in the outer 
regex.

So unless I'm missing something, it is wrong for the test to expect no match 
for the outer regex, and Rakudo already does the right thing.

What's the protocol for removing/changing tests in roast?

[perl #132337] [BUG] Code block inside `andthen`/`orelse` doesn't close over lexical variables correctly

2017-10-21 Thread via RT 
# New Ticket Created by  Sam S. 
# Please include the string:  [perl #132337]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132337 >


Golfed example:

 sub foo ($str) {
 { say $str }() orelse Nil
 }

 foo "aa";  # aa
 foo "bb";  # aa

The second call should print "bb", not "aa".

Replacing the `say` with `return`, throws "Attempt to return outside of 
any Routine" on the second call (but not the first), indicating that 
something is going wrong with cloning the interpolated closure.

Re: who own my code?

2017-10-21 Thread Theo van den Heuvel 

Hi Todd,

please discuss this in an appropriate forum. This discussion has 
absolutely nothing to do with Perl6.


Thanks,
Theo van den Heuvel

[perl #132335] [LTA] pure numeric values of address families are not useful enough ( IO::Socket::INET.new(:host, :port(42)) )

2017-10-21 Thread via RT 
# New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
# Please include the string:  [perl #132335]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132335 >


Code:
IO::Socket::INET.new(:host, :port(42))

¦«2017.09,9dba498f7f^»:
Failed to resolve host name 'http'. Error: 'Name or service not known'
  in block  at /tmp/hRNZQdcfV3 line 1
 «exit code = 1»

¦«9dba498,HEAD(7cf5ce7)»:
Failed to resolve host name 'http' with family 0. Error: 'Name or service not 
known'
  in block  at /tmp/hRNZQdcfV3 line 1
«exit code = 1»


It says “with family 0” but that may look very weird for unsuspecting users. By 
the way, 0 is AF_UNSPEC.


“with family …” addition appeared after this rakudo bump: 
https://github.com/rakudo/rakudo/commit/9dba498f7fb93710803d0dca0fb30b6b813a9b19
And here is the important MoarVM commit that was brought by that bump: 
https://github.com/MoarVM/MoarVM/commit/d43ea5a8#diff-898921f5583c52e0766ebdcc00cd6492L298

IRC discussion: https://irclog.perlgeek.de/moarvm/2017-10-21#i_15334051 
(culmination here: https://irclog.perlgeek.de/moarvm/2017-10-21#i_15334114)

Re: who own my code?

2017-10-21 Thread ToddAndMargo 
On 21 Oct 2017 8:26 PM, "ToddAndMargo" > wrote:


On Sat, Oct 21, 2017 at 12:57 AM, ToddAndMargo
mailto:toddandma...@zoho.com>
>> wrote:

 On 10/21/2017 12:40 AM, ToddAndMargo wrote:

 If I write a program for a customer who pays my
labor to
 write it, who own the program?  Me or the customer?


 I am a private contractor.  What they payed me for
fixing a/the
 problem.  They don't care how.  I was wondering if they
owned
 any of the code I wrote to fix the problem.  The
customer did
 not specifically ask me to write anything.



On 10/21/2017 01:07 AM, Brent Laabs wrote:

This depends on the contract you signed with the customer, and
laws in your local jurisdiction.  As such, it's probably a
question more appropriate to ask a lawyer than this list.


There is no contract involved.  The customer wants a problem fixed.
He does not want to know how.  And he is not commissioning me for
any software.  Just a fix.

I can not afford a lawyer.



On 10/21/2017 04:12 AM, Andrew Kirkpatrick wrote:
You'll need to read up on the laws in your area, but generally contracts 
have IP ownership clauses to ensure the employer ends up with it. 
Without a contract, it's seems likely there was no such transfer and you 
remain the owner.




I am thinking it is the same a hiring a gardener.  He develops a tool
to pull weeds while under your hire.  He own the tool.

Re: who own my code?

2017-10-21 Thread Andrew Kirkpatrick 
You'll need to read up on the laws in your area, but generally contracts
have IP ownership clauses to ensure the employer ends up with it. Without a
contract, it's seems likely there was no such transfer and you remain the
owner.

On 21 Oct 2017 8:26 PM, "ToddAndMargo"  wrote:

> On Sat, Oct 21, 2017 at 12:57 AM, ToddAndMargo >> > wrote:
>>>
>>> On 10/21/2017 12:40 AM, ToddAndMargo wrote:
>>>
>>> If I write a program for a customer who pays my labor to
>>> write it, who own the program?  Me or the customer?
>>>
>>>
>>> I am a private contractor.  What they payed me for fixing a/the
>>> problem.  They don't care how.  I was wondering if they owned
>>> any of the code I wrote to fix the problem.  The customer did
>>> not specifically ask me to write anything.
>>>
>>>
>>>
> On 10/21/2017 01:07 AM, Brent Laabs wrote:
>
>> This depends on the contract you signed with the customer, and laws in
>> your local jurisdiction.  As such, it's probably a question more
>> appropriate to ask a lawyer than this list.
>>
>>
> There is no contract involved.  The customer wants a problem fixed.
> He does not want to know how.  And he is not commissioning me for
> any software.  Just a fix.
>
> I can not afford a lawyer.
>

Re: who own my code?

2017-10-21 Thread ToddAndMargo 
On Sat, Oct 21, 2017 at 12:57 AM, ToddAndMargo > wrote:


On 10/21/2017 12:40 AM, ToddAndMargo wrote:

If I write a program for a customer who pays my labor to
write it, who own the program?  Me or the customer?


I am a private contractor.  What they payed me for fixing a/the
problem.  They don't care how.  I was wondering if they owned
any of the code I wrote to fix the problem.  The customer did
not specifically ask me to write anything.




On 10/21/2017 01:07 AM, Brent Laabs wrote:
This depends on the contract you signed with the customer, and laws in 
your local jurisdiction.  As such, it's probably a question more 
appropriate to ask a lawyer than this list.




There is no contract involved.  The customer wants a problem fixed.
He does not want to know how.  And he is not commissioning me for
any software.  Just a fix.

I can not afford a lawyer.

Re: [perl #132330] Sets can be equal even though their elements aren’t

2017-10-21 Thread Elizabeth Mattijsen 
The problem is that both these values have the same .WHICH:

$ 6 'say 1e0.WHICH; say (1e0 + 4e-15).WHICH'
Num|1
Num|1

Nothing to do with Sets/Bags/Mixes/object hashes.

> On 20 Oct 2017, at 17:02, Victor ADAM (via RT)  
> wrote:
> 
> # New Ticket Created by  Victor ADAM 
> # Please include the string:  [perl #132330]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=132330 >
> 
> 
> How to reproduce
> 
> 
> perl6 -e 'my ($a, $b) = set(1e0), set(1e0 + 4e-15); say $a ~~ $b,
> $a.keys »≅« $b.keys'
> 
> Expected behavior
> -
> 
> Prints `False(False)`.
> 
> Actual behavior
> ---
> 
> Prints `True(False)`.
> 
> This contradicts the documentation of the Setty ACCEPTS method:
> “Returns True if $other and self contain all the same elements, and no
> others.” The sets’ elements aren’t equal, or even approximately equal
> (≅), and yet ACCEPTS (~~) returns `True`.
> 
> Note that other set methods show similar behavior: `1e0 ⊖ (1e0 +
> 4e-15)` is the empty set, `set(1e0, 1e0 + 4e-15)` only has one
> element…
> 
> Version information
> ---
> 
> This is Rakudo version 2017.09 built on MoarVM version 2017.09.1
> implementing Perl 6.c.

Re: who own my code?

2017-10-21 Thread Brent Laabs 
This depends on the contract you signed with the customer, and laws in your
local jurisdiction.  As such, it's probably a question more appropriate to
ask a lawyer than this list.

On Sat, Oct 21, 2017 at 12:57 AM, ToddAndMargo 
wrote:

> On 10/21/2017 12:40 AM, ToddAndMargo wrote:
>
>> If I write a program for a customer who pays my labor to
>> write it, who own the program?  Me or the customer?
>>
>
> I am a private contractor.  What they payed me for fixing a/the
> problem.  They don't care how.  I was wondering if they owned
> any of the code I wrote to fix the problem.  The customer did
> not specifically ask me to write anything.
>

Re: who own my code?

2017-10-21 Thread ToddAndMargo 

On 10/21/2017 12:40 AM, ToddAndMargo wrote:

If I write a program for a customer who pays my labor to
write it, who own the program?  Me or the customer?


I am a private contractor.  What they payed me for fixing a/the
problem.  They don't care how.  I was wondering if they owned
any of the code I wrote to fix the problem.  The customer did
not specifically ask me to write anything.

who own my code?

2017-10-21 Thread ToddAndMargo 

Dear List,

If I write a program for a customer who pays my labor to
write it, who own the program?  Me or the customer?

Many thanks,
-T