Re: Perl 6 pod-handling code seems widely scattered
On 04/25/2016 03:27 PM, Tadeusz Sośnierz wrote: On 25/04/16 14:13, Tom Browder wrote: I would like to hack on the pod handling code (particularly the HTML generation) but it seems to be quite scattered around github. Is http://github.com/perl6/Pod::To::HTML>> the definitive repo location for that chunk? Yes, that's the module that turns Pod AST into HTML. That's what you're looking for :) It's a document tree, not really an AST. The AST is an intermediate format inside the compiler that user-space modules don't see. Cheers, Moritz :-)
[perl #127980] Smartmatching $item ~~ list does not DWIM (4 ~~ (4,5,6,7))
On Mon Apr 25 07:54:18 2016, sml...@gmail.com wrote: > That said, two of the edge cases you have discovered, *do* feel pretty > strange: > > - An *empty* RHS list returning self instead of False. > - A RHS list with a Match as its first element returning self instead > of False. > > It may make sense to investigate if those edge cases can be "fixed" - > but don't throw out the baby with the bathwater. They're there for a very practical, rather than a very beautiful, reason. :-) They are there to make: say 'abc' ~~ m:g/\d/ And: say 'abc' ~~ m:g/\w/ Do the right thing, and produce a List of Match results (which may be empty). Even before this, it was decided that `4 ~~ (4,5,6,7)` should not magically mean testing for inclusion in the list (I forget the exact reasoning, but confusion when considering lists of lists would be one good one). There are plenty of other ways to do that, such as: say 4 (elem) (4,5,6,7) So, ticket rejected since the current behavior is both serving an important purpose and the proposed DWIMmery has, best I can recall, been tried and rejected in the past. Thanks, /jnthn
[perl #127987] Block.assuming method apparently not reentrant
On Mon Apr 25 06:10:50 2016, sml...@gmail.com wrote:
> The following works fine:
>
> for (^100).race(batch=>1) { {1 + $^a}(10) }
>
> But the following pretty reliably crashes:
>
> for (^100).race(batch=>1) { {1 + $^a}.assuming(10)() }
>
> If even crashes when EVAL is used to make sure each thread has a
> completely different closure:
>
> for (^100).race(batch=>1) { EVAL(q[ ({1 + $^a}) ]).assuming(10)() }
>
I believe `assuming` uses `EVAL` under the hood, and that it's `EVAL` having
reentrancy issues that is at the heart of it. So adding an extra `EVAL` is only
making it worse. (And yes, this is fairly high on my list of stuff to hunt down
and fix.)
/jnthn
Re: [perl #122709] [PERF] await Promise in different thread
Now I'm at home I tried it on my Mac, I can confirm that:
perl6 -e 'my $waiter = Proc::Async.new(:path, :args).start; await start { await $waiter }'
prints Hello World and then hangs forever.
On Wed, Apr 27, 2016 at 2:58 PM Lloyd Fournier
wrote:
> Not sure if it's relevant here but last time I checked there is an issues
> with await and Proc::Async on Mac.
>
> RT #125758 for example which looks similar to this.
> On Wed, 27 Apr 2016 at 7:08 AM, Will Coleda via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
>> On Fri Sep 05 14:44:06 2014, elizabeth wrote:
>> > (since leont has been so busy with other stuff, I thought to report
>> > the problem he found)
>> >
>> > 12:11 * leont suspects he's observing Promise.allof spinlocking or
>> > some such. 100% CPU usage, but no input is coming in :-/
>> > 12:19 lizmat leont: could you gist that ?
>> > 12:22 leont Would need to reduce it first, but sure
>> > 13:14 leont My spinlock seems to have gone away when I await()ed
>> > in the same thread that created the Proc::Async…
>> > 13:16 lizmat leont: interesting datapoint :-)
>> > 13:16 wonder what jnthn would want to say about that :-)
>> > 13:22 leont perl6 -e 'my $waiter =
>> > Proc::Async.new(:path($*EXECUTABLE), :args(["helper.pl"])).start;
>> > await start { await $waiter };'
>> > 13:23 Let's make that easier: perl6 -e 'my $waiter =
>> > Proc::Async.new(:path("echo"), :args()).start; await
>> > start { await $waiter };'
>> > 13:29 moritz leont++ # golfing
>> > 13:30 leont: could you please submit that to
>> > rakudobugperl.org?
>> > 13:30 leont Sure
>>
>> This seems to work with no issue here. Is this ticket closable?
>>
>> $ perl6 -e 'my $waiter = Proc::Async.new(:path("echo"), :args(> World>)).start; await start { await $waiter };'
>> Hello World
>>
>> --
>> Will "Coke" Coleda
>>
>
Re: [perl #127980] Smartmatching $item ~~ list does not DWIM (4 ~~ (4,5,6,7))
It appears, then, that the problem is managing the user's understanding of the construction and expectations about results. On 4/27/16, jn...@jnthn.net via RT wrote: > On Mon Apr 25 07:54:18 2016, sml...@gmail.com wrote: >> That said, two of the edge cases you have discovered, *do* feel pretty >> strange: >> >> - An *empty* RHS list returning self instead of False. >> - A RHS list with a Match as its first element returning self instead >> of False. >> >> It may make sense to investigate if those edge cases can be "fixed" - >> but don't throw out the baby with the bathwater. > > They're there for a very practical, rather than a very beautiful, reason. > :-) They are there to make: > > say 'abc' ~~ m:g/\d/ > > And: > > say 'abc' ~~ m:g/\w/ > > Do the right thing, and produce a List of Match results (which may be > empty). Even before this, it was decided that `4 ~~ (4,5,6,7)` should not > magically mean testing for inclusion in the list (I forget the exact > reasoning, but confusion when considering lists of lists would be one good > one). There are plenty of other ways to do that, such as: > > say 4 (elem) (4,5,6,7) > > So, ticket rejected since the current behavior is both serving an important > purpose and the proposed DWIMmery has, best I can recall, been tried and > rejected in the past. > > Thanks, > > /jnthn > >
[perl #128009] “.uninames” exists but “.uniprops” doesn't (‘١٩’.uniprops)
# New Ticket Created by Alex Jakimenko # Please include the string: [perl #128009] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128009 > Code: say ‘١٩’.uninames Result: (ARABIC-INDIC DIGIT ONE ARABIC-INDIC DIGIT NINE) Code: say ‘١٩’.uniprops Result: Method 'uniprops' not found for invocant of class 'Str' in block at -e line 1 I've seen mentions of that before, but this time I've stumbled upon it myself: http://irclog.perlgeek.de/perl6/2016-04-27#i_12400195
[perl #128010] [BUG] reference to outside function prevents role instantiation
# New Ticket Created by grond...@yahoo.fr
# Please include the string: [perl #128010]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128010 >
In file A.pm6 :unit class A ; our sub f {}
In file B.pm6 :unit role B ; use A ; &A ::f ;
$ perl6 -I. -e ‘use B ; class :: does B {} ;’
===SORRY!=== Error while compiling -e
Could not instantiate role 'B':
Cannot find method 'package_at_key': no method cache and no .^find_method
at -e:1
Notice that &A ::f is not even called, only its reference is used in void
context.
Also notice that without explicit compilation units it works fine :
$ perl6 -e ‘class A { our sub f {} } ; role B { &A::f } ; class :: does B {} ;’
[perl #126205] [BUG] perl6: problem with regex match: Cannot assign to a readonly variable or a value
On Sun Apr 17 08:41:03 2016, coke wrote: > On Mon Sep 28 13:28:14 2015, emilbar...@ymail.com wrote: > > Hi, > > I posted a bug report yesterday with a complicated script and worked > > to make it simpler. Now I think it's probably not a bug but I'm still > > unable to find a solution. > > My new definition of the problem is sent in 2 attachments and can > > also be seen on > > "https://gist.github.com/emilbarton/7d6671529b0fd6d90423"; > > Thanks in advance for your answer. > > > > emilbarton > > The gist mentioned here no longer exists, and we've had the Christmas > release since the original ticket was opened. > > Please let us know if this is still an issue with a recent version of > Rakudo. Hearing no response, closing ticket. Please open a new ticket if you are still having issues. -- Will "Coke" Coleda
Re: Blobs and IEEE floating point
Sorry to be so long replying and thanking you for your help -- I've spent
most of the last week in hospital with very limited communications.
Thank you -- lots of interesting information.
I ended up for the moment with something like (retyping from memory)...
method double {
$!index += 8;
nativecast((num64), Blob.new(@!bytes[ $index - 8 ..^ $index ] );
}
which (summary to memory errors) is working fine, at least until I try to
run the code on a machine with big-endian floats, when it will require some
reversing of bytes, or a machine without IEEE floating point (do such
machines still exist?) in which case Marcel's code could be very useful. By
then perhaps there will have been consensus and implementation of a
pack/unpack native solution for Perl 6.
Thanks everybody.
On 21 April 2016 at 01:47, mt1957 wrote:
>
> On 19-04-16 10:21, Elizabeth Mattijsen wrote:
>
>> FWIW, I’ll take PR’s for the PackUnpack distribution to make ‘f’ and ‘d’
>> work :-)
>>
>
> Hi Elizabeth,
>
> For the PackUnpack distro this might come in handy... or might go in the
> examples corner?
>
> Done some experiments and looks well. Please check the attachment for
> encoding/decoding of doubles. decode-double has also an index in the buffer
> to pull out a specific spot in the buffer where the encoded double should
> be. The code is made from snippets from Timo Paulsen and
> David Warren.
>
> You might want to know how much faster it has become. Well it's not that
> much of an improvement, only encoding a double is about 4 times faster.
> The decoding only 1.13 times.
>
> emulated encoded
> 3000 runs total time = 7.211524 s, 0.002404 s per run, 416.000809 runs per
> s
>
> native encoded
> 3000 runs total time = 1.720918 s, 0.000574 s per run, 1743.256109 runs
> per s
>
> emulated decode
> 3000 runs total time = 1.038615 s, 0.000346 s per run, 2888.461538 runs
> per s
>
> native decode
> 3000 runs total time = 0.918133 s, 0.000306 s per run, 3267.498734 runs
> per s
>
>
> Before I pat myself on the back for the 'fast' emulated encode/decode
> already in place in the BSON package the above results might mean that the
> native routines can be done better.
>
> Regards,
> Marcel
>
>
>
