I believe the problem comes from `"{"` which actually starts an
interpolated code block containing a string immediately. That's also why
it doesn't complain about the "else" being in an odd place; it's also
inside the string!
So here's an equivalent piece of code that shows what's wrong:
if reque
with jnthn's recent patch to give every thread its own free-list for the FSA,
the behavior is now much nicer.
Here's a paste of a 40-core machine:
https://gist.github.com/anonymous/650ff6b00a0f8dc34b9e358992e572b4
here's a 24-core box (some google compute cloud machine zoffix rents)
before the
Fixed it with rakudo commit 46b11f54c0
timotimo │ bench: 46b11f54c0,abfb52be1d for ^10_000_000 { }
+benchabl+│ timotimo, starting to benchmark the 2 given commits
+benchabl+│ timotimo, ¦46b11f5: «1.6712» ¦abfb52b: «4.4582»
timotimo │ m: say 4.4582 / 1.6712
+camelia │ rakudo-
the problem here is that we have a flag to ensure gcc explodes at us
when we write code on linux that'd immediately explode on windows due to
MSVC being somewhat archaic, but that flag is also set for third-party
code, and since the arm dyncall stuff only gets tested once every few
months at best,
this was caused by instructions coming back from the dead, haunting usage
counts by mysteriously dropping them by 1 or more, and then both the dead
instruction and the lawful citizens of other blocks of code being executed by
the local authorities.
fixed with https://github.com/MoarVM/MoarVM/co
this was caused by instructions coming back from the dead, haunting usage
counts by mysteriously dropping them by 1 or more, and then both the dead
instruction and the lawful citizens of other blocks of code being executed by
the local authorities.
fixed with https://github.com/MoarVM/MoarVM/co
I wrote a fix, could you try downgrading to 2017.06, running the script,
applying the patch to your 2017.07, making sure the Makefile itself gets
regenerated via Configure.pl, and install, then see if the program still
crashes?
https://github.com/rakudo/rakudo/commit/02667bd890
the commit message
Already fixed in newer versions
It could be that the commit i just pushed to moarvm fixes this, please
verify (the code doesn't crash with the patch)
Annoyingly, 2017.07 has a bug that makes every --ll-exception print that
exact error. Here's what a newer version of rakudo gives you:
> Cannot invoke this object (REPR: Null; VMNull)
>at SETTING::src/core/Exception.pm:57
> (/home/timo/perl6/install/share/perl6/runtime/CORE.setting.moarvm:th
I just committed a hotfix so the upcoming release can go through.
Hopefully it can be replaced with a proper implementation of optional
parameters for the nativecall compiler soon.
https://github.com/rakudo/rakudo/commit/1818de980fe39a37b405c0353d088932bd4d034a
This also happens with other metaops than R, like [Z+]=, [X+]=, and also [S+]=
(which admittedly doesn't do sensible things)
The tests are bogus just the assumption that a substr of length 8 will give you
8 bits rather than 8 bytes, that's already wildly inconsistent with what substr
does otherwise.
really this code looks like the desire to have `vec` from perl5 implemented in
perl6 by re-using the substr name. I thi
Also, the design docs say you get the same kind of buffer back from substr on a
buf, but we have subbuf for that now.
This runs reliably when you let the lock-protected block return
something unrelated to the hash:
#!/usr/bin/env perl6
use v6.c;
my $lock = Lock.new;
my $set = SetHash.new;
await (^12).map: {
start {
for (^1000) {
$lock.protect: { $set<1> = True }
$lock.protect
storage when the hash is resized) this will probably
just get inconsistent results in whether it'll sink a true or a false.
On 11/10/17 08:06, Timo Paulssen via RT wrote:
> This runs reliably when you let the lock-protected block return
> something unrelated to the hash:
>
> #!/usr/
fixed in moarvm commits a9267cb, 650e797, and 676723d.
Needs a bump, as well as tests.
On 17/10/17 19:22, Aleks-Daniel Jakimenko-Aleksejev via RT wrote:
> Bisected: (2016-06-29)
> https://github.com/rakudo/rakudo/commit/d5c750f74cd4cdbc4746da8bf32d42fc37032b78
>
> On 2017-10-14 06:33:04, c...@zo
if you can, please re-compile MoarVM passing the same options that were
used before (you can find them on the first screenfuls of the Makefile
inside moarvm's source folder) to Configure.pl but also include
--debug=3 and --optimize=0. This is an optional step. After that, please
run perl6-valgrind-
can you get us strace output for this?
I already figured out that it's about sinking the result of assigning to
the SetHash. When you access it you get a proxy, that is the return
value of the lock-protected block, and the proxy gets sunk outside of
it, thus causing concurrent access to the SetHash.
On 14/11/17 16:03, Elizabeth Mattij
On Mon, 20 Nov 2017 12:13:47 -0800, ronaldxs wrote:
> What about a native perl6 range loop? Couldn't there be some way for
> Perl 6 / Rakudo to generate code competitive on a small range with the
> "native-loop" example?
>
> perl6 -e '
> {
> my int ($a, $one, $three) = (42, 1, 3);
>
a look at a profile makes me suspect the problem is having pod_string_character
match a single character at a time, causing rather large numbers of match
objects for comparatively short strings.
It's probably worthwhile to steal a piece of implementation from "nibbling",
aka parsing strings. a
Curious sidenote:
when you use [Z+]= it will complain about "useless use of [Z+]= in sink
context" and the modifications actually go through. With Z[+=] - which
is probably the default parsing of this - it will not complain about
useless use, but it also won't Do The Thing.
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, a
I've unsuccessfully tried to fix this, but I've come up with an idea how an
actual fix might go.
When the merge flag (which I added in recent commits) gets passed to
MVM_proc_spawn or MVM_proc_shell, we have to first create a new pipe on our
own, then set up both stdio 1 and 2 to UV_REUSE_STREA
I don't think that's what's happening. It looks like you're creating an
iterator three times and are trying to get the first element through
each iterator.
Check out what happens when you call .iterator only once:
perl6 -e 'my \a = (gather for ^Inf { take $_ }).iterator; say do for ^3
{ a.pull-on
26 matches
Mail list logo
