[perl #127208] [CONC][SEGV] Non-deterministic segfaults in parallel code
Fudged tests added in https://github.com/perl6/roast/commit/02d698835e Still segfaults about once in 10 runs on 2016.08.1-145-g87f772e
Re: Observations from a C++/Python developer that never used Perl5
The pair constructor seems to be in a different category than the other
quoting operators since the expression that it quotes must look like an
identifier:
https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Grammar.nqp#L1776
token fatarrow {
\h* '=>' <.ws>
}
Brian
On Saturday, September 10, Aaron Sherman wrote:
> You cannot currently define your own quote-like operators. That will come
> with true macros (though you could certainly do it via a slang...
> everything is possible with a slang). But they are operators. Not only are
> they operators, but they nest other operators. vis:
>
> say "These are my args: {@*ARGS.join(',')}";
>
>
>
>
> Aaron Sherman, M.:
> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
> Toolsmith, developer, gamer and life-long student.
>
>
> On Fri, Sep 9, 2016 at 8:59 PM, Joseph Garvin
> wrote:
>
> > Wait, quotes *are an operator* ? If so how would I define them? If the
> > operator returns string, what is the type of its argument? If so that's
> > even stranger -- most languages they're a hard coded bit of syntax -- the
> > closest thing I can think of is in C++11 you can add your own string
> > literal types, but even with that the closest you could get would be:
> >
> > "Foo"_mytype => bar
> >
> > You still wouldn't be able to omit the quotes.
> >
> > On Sep 9, 2016 12:12 AM, "Aaron Sherman" wrote:
> >
> >> it is combining too many new things at once:
> >>
> >>
> >> Well, it is meant to be the up-front example of everything at once before
> >> the step-by-step...
> >>
> >>
> >>> * BUILD
> >>> * new
> >>
> >>
> >> These are the heart of construction. I don't think there's any avoiding
> >> that in a class tutorial.
> >>
> >> * submethod
> >>> * bless
> >>
> >>
> >> These are simply necessary components of the above. BUILD is a submethod.
> >> new uses bless. These are non-negotiable aspects of the tutorial.
> >>
> >> * named arguments syntax
> >>> * slurping parameter syntax
> >>
> >>
> >> Named arguments are pretty standard stuff. Slurpy args... I suppose it's
> >> one more thing, but is it really that unusual that we expect someone
> >> reading this not to understand variadic arguments?
> >>
> >>
> >>> * code golfing cleverness of mapping arguments to identically named
> >>> named arguments
> >>
> >>
> >> Again, this is how you take arguments to BUILD that set attributes.
> >> That's the correct form, not code golfing.
> >>
> >> Constructors in a language that supports a flexible metaobject protocol
> >> aren't trivial beasts.
> >>
> >>
> >> The real nail in the coffin though is that it's an example that doesn't
> >>> need to use any of those features (nothing about Task really require
> >>> special construction),
> >>>
> >>
> >> This is, I think, the only really significant problem with that example.
> >> The BUILD method is doing no work, and doesn't need to. An example where
> >> new and BUILD were actually required would be vastly more useful.
> >>
> >>
> >>> * If I have a member that is read-only, when am I allowed to initialize
> >>> it and after what point must already be initialized? Can I assign to it in
> >>> BUILD but not new or vice versa?
> >>>
> >>
> >> You always get a free initializer, so if the user is going to provide it
> >> or it's going to get a static default, you're good to go. But let's say you
> >> have this:
> >>
> >> class Foo {
> >> has $.a;
> >> has $.b;
> >> submethod BUILD(:$!a) { $!b = $!a * 10 }
> >> }
> >>
> >> In this case, you need the BUILD submethod because you wanted to have a
> >> dynamic value for the .b attribute that is based on whatever the .a
> >> attribute was set to.
> >>
> >> Now, that out of the way, let's make $.b readonly:
> >>
> >> has $.b is readonly;
> >>
> >> This doesn't make $.b constant, it merely affects the automatically
> >> generated constructors. So your BUILD routine keeps working. The private
> >> form ($!b) only works within the class, but is not affected by such
> >> strictures.
> >>
> >> * If I want a constructor that takes positional arguments, do I write new
> >>> or BUILD?
> >>>
> >>
> >> For positionals, you have to define a new. Here's another example that
> >> does unecessary work, but in this case to show you what's going on:
> >>
> >> $ perl6 foo.p6
> >> new(1, 2) pre-bless
> >> BUILD(1, 2)
> >> 12
> >> $ cat foo.p6
> >> class Foo {
> >> has $.a;
> >> has $.b is readonly;
> >> multi method new($a, $b) {
> >> say "new($a, $b) pre-bless";
> >> self.bless(:$a, :$b);
> >> }
> >> submethod BUILD(:$!a, :$!b) {
> >> say "BUILD($!a, $!b)";
> >> }
> >> }
> >>
> >> my $f = Foo.new(1,2);
> >> say $f.a, $f.b;
> >>
> >>
> >>
> >>
> >>>
> >>> * If I need to do some computation when the object is constructed in
> >>> order to properly initialize the members, do I write new or BUILD? What if
> >>> one of the members I need to initialize is read-only?
> >>>
> >>
>
[perl #129240] [NativeCall] nativesizeof routine returns the different result from sizeof function in C when it takes a CArray object as an argument.
# New Ticket Created by Itsuki Toyota
# Please include the string: [perl #129240]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=129240 >
See the following result
$ 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
I think that it should return 12, since the following equivalent C code returns
12.
--
#include
int main() {
int a[3];
a[0] = 1;
a[1] = 1;
a[2] = 1;
printf("sizeof a: %d\n", sizeof(a)); // sizeof a: 12
}
--
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ perl6 --version
This is Rakudo version 2016.07.1-199-gdd9b760 built on MoarVM version
2016.07-17-g40948f6
implementing Perl 6.c.
Re: Help mechanism in REPL?
On Fri, 09 Sep 2016 16:30:28 -0700
Alex Elsayed wrote:
> On Wednesday, 7 September 2016 17:57:32 PDT Parrot Raiser wrote:
> > This isn't a request for a feature, merely a thought experiment.
> > We're still in the phase where it's more important to ensure that
> > existing features work properly than add new ones.
> >
> > How difficult would it be to include a mechanism within the REPL to
> > select either documentation or an example, (possibly from the test
> > suite), for a particular command? Selection might be by some control
> > key combination, cursor positioning, or an alternative to "enter"
> > at the end of the line. The purpose would be to speed development,
> > by enabling an inexperienced developer to look up details while
> > testing.
> >
> > Syntax errors generate messages which attempt to provide help; could
> > this provide the basis for a "help" mechanism? Would this be useful?
> >
> > Opinions?
>
> Well, this sounds like a job for the meta-object protocol
> (specifically, `.WHY`):
>
> https://docs.perl6.org/language/mop#WHY
>
> The simplest option for handling this in the REPL is probably to have
> some sort of automatic handling of Pod sent to sink context,
> rendering it and sending it to a pager. Then, the user could simply do
>
> >> Hash.WHY
> (LET THERE BE DOCS!)
>
> And there would be docs.
>
+1 to this; it wouldn't be too hard to have the REPL pick up on Pod types and
render them
properly. However, hardly any of the core types or subs have a WHY (due to
Rakudo setting
compilation time). There were a few ideas flying around a while ago about how
to remedy this:
- Generate a postamble that is optionally included in the setting that sets
up WHY for core objects
retroactively.
- Alter WHY's implementation slightly so that if an object has no WHY
associated with it, there is
the option to consult a "WHY repository", which would store WHYs
off-setting on disk or as a service
on docs.perl6.org.
I think that Parrot Raiser's original intent, in addition to object and
function-specific help, was offering
broader categories of help from within the REPL, like Python's
"help('keywords')".
Re: Help mechanism in REPL?
There was some talk in the past about having `.WHY` look up the descriptions in the POD6 doc ( so that we don't have to bloat Rakudo with that information ) On Fri, Sep 9, 2016 at 6:30 PM, Alex Elsayed wrote: > On Wednesday, 7 September 2016 17:57:32 PDT Parrot Raiser wrote: >> This isn't a request for a feature, merely a thought experiment. We're >> still in the phase where it's more important to ensure that existing >> features work properly than add new ones. >> >> How difficult would it be to include a mechanism within the REPL to >> select either documentation or an example, (possibly from the test >> suite), for a particular command? Selection might be by some control >> key combination, cursor positioning, or an alternative to "enter" at >> the end of the line. The purpose would be to speed development, by >> enabling an inexperienced developer to look up details while testing. >> >> Syntax errors generate messages which attempt to provide help; could >> this provide the basis for a "help" mechanism? Would this be useful? >> >> Opinions? > > Well, this sounds like a job for the meta-object protocol (specifically, > `.WHY`): > > https://docs.perl6.org/language/mop#WHY > > The simplest option for handling this in the REPL is probably to have some > sort of automatic handling of Pod sent to sink context, rendering it and > sending it to a pager. Then, the user could simply do > >>> Hash.WHY > (LET THERE BE DOCS!) > > And there would be docs.
Re: [perl #129240] [NativeCall] nativesizeof routine returns the different result from sizeof function in C when it takes a CArray object as an argument.
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 #129240] [NativeCall] nativesizeof routine returns the different result from sizeof function in C when it takes a CArray object as an argument.
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
[perl #129242] [BUG] split gives incorrect results when splitting a number with the :skip-empty adverb
Thanks for the report.
It appears all of .split's adverbs were broken on Cool, including the
.split(@needles) call form.
Fixed in https://github.com/rakudo/rakudo/commit/b771bcc97a
Tests added in https://github.com/perl6/roast/commit/060cf7abff
On Sat Sep 10 09:01:27 2016, jan-olof.hen...@bredband.net wrote:
> Tested with:
>
> dogbert@dogbert-VirtualBox ~/.rakudobrew/moar-nom $ perl6 -v
> This is Rakudo version 2016.08.1-151-g20ed9e2 built on MoarVM version
> 2016.08-43-g3d04391
> implementing Perl 6.c.
>
> # the problem
>
> dogbert@dogbert-VirtualBox ~/.rakudobrew/moar-nom $ perl6 -e 'dd
> 123456.split("", :skip-empty)'
> ("", "1", "2", "3", "4", "5", "6", "")
>
> # as can be seen the result contains two empty strings
> # compare with
>
> dogbert@dogbert-VirtualBox ~/.rakudobrew/moar-nom $ perl6 -e 'dd
> "123456".split("", :skip-empty)'
> ("1", "2", "3", "4", "5", "6")
>
>
>
> # some discussion on irc, contains results from bisectable, commitable etc
>
> http://irclog.perlgeek.de/perl6/2016-09-10#i_13184978
>
> /dogbert17
>
Re: Help mechanism in REPL?
FWIW, the .WHY is a method just like any other. What would need to be changed, is the behaviour of Mu.WHY (around line 60 in Mu.pm). > On 10 Sep 2016, at 16:41, Brad Gilbert wrote: > > There was some talk in the past about having `.WHY` look up the > descriptions in the POD6 doc ( so that we don't have to bloat Rakudo > with that information ) > > On Fri, Sep 9, 2016 at 6:30 PM, Alex Elsayed wrote: >> On Wednesday, 7 September 2016 17:57:32 PDT Parrot Raiser wrote: >>> This isn't a request for a feature, merely a thought experiment. We're >>> still in the phase where it's more important to ensure that existing >>> features work properly than add new ones. >>> >>> How difficult would it be to include a mechanism within the REPL to >>> select either documentation or an example, (possibly from the test >>> suite), for a particular command? Selection might be by some control >>> key combination, cursor positioning, or an alternative to "enter" at >>> the end of the line. The purpose would be to speed development, by >>> enabling an inexperienced developer to look up details while testing. >>> >>> Syntax errors generate messages which attempt to provide help; could >>> this provide the basis for a "help" mechanism? Would this be useful? >>> >>> Opinions? >> >> Well, this sounds like a job for the meta-object protocol (specifically, >> `.WHY`): >> >> https://docs.perl6.org/language/mop#WHY >> >> The simplest option for handling this in the REPL is probably to have some >> sort of automatic handling of Pod sent to sink context, rendering it and >> sending it to a pager. Then, the user could simply do >> Hash.WHY >> (LET THERE BE DOCS!) >> >> And there would be docs.
[perl #129241] Odd corruption of attribute of type Grammar
# New Ticket Created by Andrew Buchanan # Please include the string: [perl #129241] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=129241 > Running the test file will produce multiple successful outputs of grammar.parse, that suddenly fails for no good reason. Details in the file. -- Andrew Buchanan tomentiru...@gmail.com Running the test file will produce multiple successful outputs of grammar.parse, that suddenly fails for no good reason. Details in the file. --Andrew Buchanantomentiru...@gmail.com Test.p6 Description: Binary data
[perl #129242] [BUG] split gives incorrect results when splitting a number with the :skip-empty adverb
# New Ticket Created by Jan-Olof Hendig
# Please include the string: [perl #129242]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=129242 >
Tested with:
dogbert@dogbert-VirtualBox ~/.rakudobrew/moar-nom $ perl6 -v
This is Rakudo version 2016.08.1-151-g20ed9e2 built on MoarVM version
2016.08-43-g3d04391
implementing Perl 6.c.
# the problem
dogbert@dogbert-VirtualBox ~/.rakudobrew/moar-nom $ perl6 -e 'dd
123456.split("", :skip-empty)'
("", "1", "2", "3", "4", "5", "6", "")
# as can be seen the result contains two empty strings
# compare with
dogbert@dogbert-VirtualBox ~/.rakudobrew/moar-nom $ perl6 -e 'dd
"123456".split("", :skip-empty)'
("1", "2", "3", "4", "5", "6")
# some discussion on irc, contains results from bisectable, commitable etc
http://irclog.perlgeek.de/perl6/2016-09-10#i_13184978
/dogbert17
[perl #129244] No way to close IO::Socket::Async as documented
# New Ticket Created by hanenkamp # Please include the string: [perl #129244] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=129244 > my $listener = IO::Socket::Async.listen(...); $listener.close; #!> Method 'close' not found for invocant of class 'Supply' #!> in block at ./try.p6 line 2 #!> in block at /home/example/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm line 1 #!> in block at /home/example/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm line 1 #!> in method emit at /home/example/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm line 1 I believe at one time this worked, but sometime ago, possibly with the split up between Supply and Supplier, this changed. There is no .close method on supplies, but the docs for Supply on docs.perl6.org states: "In order to close the underlying listening socket created by listen you can simply close the Supply." I am fairly certain that no longer works. I suspect there's no way to close a listening socket in the current implementation. -- Sterling Hanenkamp http://sterling.hanenkamp.com/stfl/ 785-370-4454
[perl #129245] [BUG] *$foo accepted in signatures
# New Ticket Created by Brandon Allbery
# Please include the string: [perl #129245]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=129245 >
[11 06:36] m: sub subparams(($head, *$tail)) { ($head,
$tail).flat }; say subparams((1,2,3,4));
[11 06:36] rakudo-moar 0a7125: OUTPUT«Too many positionals
passed; expected 2 arguments but got 4 in sub-signature
[11 06:36]in sub subparams at line 1
[11 06:36]in block at line 1
[11 06:36] 
[11 06:36] »
[11 06:41] "An array or hash parameter can be marked as slurpy
by leading asterisk(s)" suggests *$ should be illegal
[11 06:45] geekosaur: I would tend to agree
[11 06:46] m: dd :(*$a) # apparently, it's just $a
[11 06:46] rakudo-moar 0a7125: OUTPUT«:($a)
[11 06:46] »
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
[perl #129246] [DOCS] bad link to "Slurpy Arguments" at https://docs.perl6.org/type/Signature#Constraining_Slurpy_Arguments
# New Ticket Created by Brandon Allbery # Please include the string: [perl #129246] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=129246 > It goes to https://docs.perl6.org/type/Slurpy_(A$FULL_STOPK$FULL_STOPA$FULL_STOP_Variadic)_Parameters which is 404; I suspect https://docs.perl6.org/type/Signature#Slurpy_(A.K.A._Variadic)_Parameters was intended. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
