[Coke] ... huh. cleaned out ./install and did a rebuild, now have a jvm perl6 00:34
Geth roast: skids++ created pull request #305:
Fix test that expected pre-GLR behavior. RT##124572.		 01:14
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=124572
Geth roast: skids++ created pull request #306:
Fix test that expected pre-GLR behavior. RT##124572.		 01:15
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=124572
Geth rakudo/nom: 1da075f93c | (Samantha McVey)++ | tools/lib/NQP/Configure.pm
Fix Configure.pl so --ignore-errors works for wrong NQP version

Make sure it properly sets the right flags and ignores the error properly.		 02:07
rakudo/nom: fc632cd8da | (Samantha McVey)++ | src/core/Match.pm
Add a comment explaining why INTERPOLATE has non-opt params
AlexDaniel .tell Skarsnik I have tested your proposed MoarVM fix. Are you sure that it affects anything on your machine? Have you tried the snippet from this bug report? RT #131003 03:14
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131003
yoleaux AlexDaniel: I'll pass your message to Skarsnik.
AlexDaniel .tell Skarsnik because it makes no difference at all here. :S 03:15
yoleaux AlexDaniel: I'll pass your message to Skarsnik.
samcv i'm gonna increase the max length of the needle for Knuth morris pratt to 8192 05:44
and store it in a 16 bit integer array instead of 32 bit array (which was larger than we needed) 05:45
[Tux] This is Rakudo version 2017.08-68-gfc632cd8d built on MoarVM version 2017.08.1-53-gad5a6464 06:19
csv-ip5xs 1.360 - 1.451
test 10.488
test-t 3.482 - 3.526
csv-parser 11.363
lizmat Files=1223, Tests=67674, 294 wallclock secs (13.80 usr 5.28 sys + 1980.49 cusr 207.52 csys = 2207.09 CPU) 06:25
[Tux] .hug 06:31
huggable hugs everyone
samcv :) 06:33
nine nice way to start into a Monday morning :) 06:53
lizmat good *, #perl6-dev 08:11
is there a reason why we can't coerce a Seq into a Channel?
masak lizmat: good afternoon. Seq->Channel seems like a sensible thing to want IMO 08:20
maybe Channel->Seq too, I dunno
lizmat masak o/ 08:21
lizmat makes mental note
samcv gonna bump moarvm so we get the new grapheme caching for KMP based indexing
\o/
masak .oO( Kolmogorov-Markov-Perelman based indexing!? ) 08:22
:P
samcv heh
masak clearly I've been away too long
needless to say, an indexing based on those three couldn't avoid being awesome 08:24
Geth rakudo/nom: 9dbc3c50c5 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Iterator.pm
Some minor cleanup on R:I.FirstNThenSinkAll

  - removed unnecessary attribute
  - made sure pull-one's are raw so containers can be passed
  - sink-all is supposed to return IterationEnd
  - added some comments for clarity of flow
  - removed some trailing whitespace		 08:56
jnthn wtf, just build Rakudo HEAD and all of make test fails :S 09:32
It seems it's going for the installed things rather than the ones in my local directory? 09:33
timotimo is that from having removed the relative paths from the default module search paths? 09:34
jnthn No, it seems it put them there in the wrong order :/ 09:35
Thing I figured out the fix 09:37
But really, did nobody try make test without doing make install first?
Geth rakudo/nom: fb0b3eb5c7 | (Jonathan Worthington)++ | tools/build/Makefile-Moar.in
Fix `make test` without `make install` first.
 09:39
timotimo is that the same runner that gets installed? 09:41
jnthn I sure hope not.
No, we call that script again in make install 09:42
Without . and blib in the path
timotimo good
Geth rakudo/nom: 0877278ede | (Jonathan Worthington)++ | src/core/Scheduler.pm
Give full thread backtrace under --ll-exception.

Which makes debugging certain problems that result in an unhandled exception on a thread easier.		 09:49
rakudo/nom: 59a2056a62 | (Elizabeth Mattijsen)++ | 2 files
Add Thread.is-initial-thread

After a question on perl6-users and some discussion on #perl6-dev, presenting class / instance method "is-initial-thread(--> Bool). Works by saving the current vm thread in Rakudo::Internals at startup, and then comparing that to either the current thread, or the vmthread given by the object.
1f411693bd | (Jonathan Worthington)++ | 2 files Make signal introspection in Kernel threadsafe.
This is a more general fix for the issue that Proc::Async was working around; it turned out to also be a problem for the `signal` sub.		 09:53
jnthn I'm...not sure wanting to know that isn't enough of an anti-pattern to warrant a method for it...
lizmat jnthn: well, otherwise people will just start asking for the thread's name, and checking for "Initial thread', which feels more fragile 09:55
in any case, I think we had a race condition in PROCESS::<$THREAD>
jnthn True, but they're likely writing fragile code anyway
Doesn't add much overhead to have the method though, so guess it can stay
lizmat in which case I will document it and write some tests 09:56
Skarsnik Can be usefull for something like Qt binding were it must live in the main thread 10:07
timotimo in that case you need to use a different scheduler like in the gtk bindings
the solution is not to check if it's the initial thread, because what if it isn't?
Skarsnik you have to die x) 10:08
timotimo also
no need to have the main thread be the UI thread
which makes is-initial-thread completely useless
jnthn Generally, it doesn't have to live in the main thread, it just has to use a consistent thread.
ah, timotimo beat me to it :) 10:09
jnthn is fixing RT #132016 fwiw
Well, trying, anyways :)
timotimo conveniently, that thread is usually one that has something event-loopy going on in it, which allows you to push work items onto that very thread
jnthn Indeed 10:10
timotimo synopsebot6: RT 132016
jnthn Which is how I arranged it in GTK::Simple
lizmat BTW, if any has an explanation why I can't do a any(@a) in github.com/rakudo/rakudo/commit/51...8515d47a5a , I'd like to hear it :-) 10:11
jnthn Well, got a fix, and cleaned up the whole $*KERNEL.signals safety issues in general, so the thing compensating for that in Proc::Async can also go away
Skarsnik I should finish my work to bind glibc/gstreamer in a nice OO fashion x) 10:12
timotimo that'd probably be cool. how about gobject introspection support? :) 10:13
rakudo/nom: 13b6a33c20 | (Jonathan Worthington)++ | src/core/signals.pm
Fix thread safety issues in the `signal` sub.
Skarsnik first I need to finish my libxml binding. Waiting 30sec each run of gptrixie on big header is kinda not fun
or you need to make rakudo 100x faster for the XML module to be faster maybe ^^ 10:18
jnthn s/rakudo/the specific parts of rakduo the XML module is using/ :-) 10:19
Skarsnik I think objects creation is also not that fast 10:20
jnthn Yup 10:21
Skarsnik my bench on the gumbo module are kinda scary. the C lib take 0.04 sec to parse the html file I use in my tests (and create the C tree), then perl6 take 1.5 sec to go throught the tree and create xml objects. 10:23
jnthn Is it a lot of C calls to access the tree? 10:24
If so, recent work by nine++ mighta sped up that part significantly 10:25
Skarsnik hm
jnthn Or might speed up that part...
I guess some of it is landed, some still in progress.
Skarsnik there is like 11 000 calls to one C function 10:26
nine The JIT part still lives in a branch. But that needs only one fix brrt++ pointed out today and a bit of commit cleanup.
jnthn Ah, then that's probably fairly hot path for the code
nine But all in all it speeds up csv-ip5xs by ~ 4 % which I have to admit is less than I'd hoped for. 10:27
jnthn :S
Yeah
nine OTOH 100000 calls to a C function take about ~ 20ms according to our profiler
jnthn That ain't bad :)
Geth roast: 43a0d860b6 | (Elizabeth Mattijsen)++ | S17-lowlevel/thread.t
Add tests for Thread.is-initial-thread
nine So those 11000 should be done in almost no time
Skarsnik gist.github.com/Skarsnik/1c356d1d3...778b6999b4 It's not these call yes 10:28
nine A cool fact btw: csv-ip5xs runs > 90 % JITed frames 10:30
lizmat nine: wouldn't that imply there isn't much space for improvement anymore ? :-( :-) 10:31
nine lizmat: no, both optimization strategies still very much apply: * do less work * do work more efficiently 10:32
jnthn Better JIT. Better spesh. Better Inline::Perl5. :P
nine First part is optimizations in Inline::Perl5 and Spesh, the last part is even-moar-jit
Something I want to have a look at in the near future is why encode-chars is not JITed currently 10:34
That should help other programs, too
Skarsnik 4% is not that much :( 10:35
nine I've learned quite a bit about spesh over the weekend and certainly want to spend more time with it :)
jnthn spesh-bus-number++ \o/ 10:36
tadzik spesh bus number bump and 4%? That's a fat improvement :) 10:38
Skarsnik benchable6, releases sub hanoi(int $n, int $d, int $a, int $i) {return if $n == 0; hanoi($n - 1, $d, $i, $a) ; hanoi($n - 1, $i, $a, $d) }; hanoi(15, 1, 2, 3); 10:53
benchable6 Skarsnik, starting to benchmark the 22 given commits
Skarsnik, benchmarked the given commits, now zooming in on performance differences 10:54
travis-ci Rakudo build failed. Jonathan Worthington 'Give full thread backtrace under --ll-exception.
travis-ci.org/rakudo/rakudo/builds/271620184 github.com/rakudo/rakudo/compare/f...77278edea1
buggable [travis build above] ? All failures are due to timeout (0), missing build log (0), GitHub connectivity (1), or failed make test (0).
benchable6 Skarsnik, gist.github.com/4b3b6a0bb2275650f4...a7c522af3a 10:55
Geth nqp: a260342ee0 | (Jonathan Worthington)++ | tools/build/MOAR_REVISION
Bump to latest MoarVM.
 11:20
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...59ac65d... No newline at end of file
roast: 5f7605d09f | (Jonathan Worthington)++ | S32-io/io-handle.t
Test for RT #131961.
 11:24
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131961
Geth rakudo/nom: 75c987047e | (Jonathan Worthington)++ | tools/build/NQP_REVISION
Bump for latest MoarVM.

Includes a fix for an occasional UTF-8 decoding bug and JIT refactors.		 11:25
¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....efba5b1... No newline at end of file
|Tux| This is Rakudo version 2017.08-75-g75c987047 built on MoarVM version 2017.08.1-99-gee06f56f 11:36
csv-ip5xs 1.273 - 1.285
test 9.529
test-t 3.405 - 3.436
csv-parser 11.295
Skarsnik right is previous?
|Tux| no, I run it twice. left is fastest, right is slowest. It depicts a range 11:37
Skarsnik ohh
|Tux| 2017-08-30 08:11:54 test-t 3.471 11:38
2017-09-04 08:16:39 test-t 3.482
2017-09-04 13:32:36 test-t 3.436
2017-09-04 13:34:23 test-t 3.405
there is no 3.3 or lower yet, so this 3.405 is a new low-record :) 11:39
timotimo cool 11:43
Geth nqp/master: 7 commits pushed by pmurias++ 12:23
jnthn wonders why sub exit ended up in src/core/Rakudo/Internals.pm 12:39
lizmat jnthn: there was a logic to it: perhaps because it was needed early in the setting ? 12:45
seems to be related to &*EXIT 12:46
jnthn mebbe :) 12:47
Doesn't affect me, just noticed it
I'm currently looking into switching on output buffering on non-tty handles fwiw 12:48
lizmat jnthn: now that we have atomic inc / cas, shouldn't we also fix any race conditions in once blocks ? 12:50
jnthn Not sure how they relate :)
lizmat well, once blocks use a hidden state var 12:51
jnthn If question is "can we use them to fix once blocks to be magically threadsafe" then no.
lizmat ah, but that can't be a native, right ?
jnthn The problem is
sub foo() { once { ...init work... }; ...code that relies on that init work... }
Here, the issue is not that we only need to do init work once
It's that there's also a race between it being done and something using it 12:52
So once isn't a good construct for those things
lizmat ok, gotcha
jnthn Not unless we introduce some kinda blocking 12:53
It would be nice to have something like a deferred operation that's certain to do the work once, and you block on it being available
lizmat implicitly lock all once blocks?
feels like a recipe for deadlock :-(
jnthn Right, I don't think we can overload this onto once very sanely
It's also like we want a phaser 12:54
*almost
Since there is at least precedent for those not just being once-per-lexical-scope 12:55
lizmat but unlike phasers, this would be in the line of the program :-(
jnthn No idea what we'd call it
That's fine though
lizmat it used to be called START :-)
jnthn my $foo = BEGIN ...;
my $foo = INIT ...;
Those are understood to run at certain times and once
For various definitions of once :-)
START ain't a good name for this. It's more like once-per-process-on-demand :) 12:56
lizmat
.oO( oppod )
jnthn :P
lizmat drops the idea for now :-) 12:57
jnthn Well, I like the idea, just dunno what to call it :)
jnthn glances at TimToady :)
A small number of tests suffering from buffering. 12:59
'not ok 1 - buffer is flushed when IO goes out of scope' 13:01
uh...no, dear test, that is not how Perl 6 works :P
Darn, these tests are utterly bogus :/ 13:08
timotimo that must be ooooold 13:09
jnthn Indeed
Well, they'll just have to change
I just worry that people will not be closing file handles in general and somehow expecting them to magically be closed for them at program exit 13:11
timotimo brian d foy pointed out that log10(10 ** 1000) doesn't work; should we have candidates for those functions that work with Int? (because right now it coerces 10 ** 1000 to Num yielding Inf, and log10 of Inf is Inf) 13:12
jnthn I've already stuck in a MoarVM patch for stdout/stderr to auto-flush at exit
timotimo yeah, the user code normally doesn't open stdout/stderr by itself :)
jnthn Right
releasable6: status
releasable6 jnthn, Next release in 12 days and ?5 hours. No blockers. Changelog for this release was not started yet
jnthn, Details: gist.github.com/dbaad6553900a1829b...a581374165
jnthn OK, 2 weeks is enough to find out what the impact will be
Zoffix timotimo: dunno; if log10 would work with big ints, I'd expect the rest of all these routines to work too; like cos(10 ** 1000) 13:17
And if we fix just a handful of them to work, it'd be harder to remember which of them do and don't work.
timotimo that's a good point i suppose 13:18
Zoffix Wonder if we should have some detection for these cases and a warning or something "warning, large Int coerced to Num ends up as Inf"
timotimo not sure if that's sane
Zoffix ok :)
wonder if there's a way to fix all of them; they're all periodic, aren't they 13:19
Geth roast: 72ce6bc930 | (Jonathan Worthington)++ | S32-io/io-handle.t
Fix/eliminate tests for IO handles and scope exit.

Quite simply, Perl 6 makes no promises whatsoever about handles being automatically closed for you at scope exit, and can't make any about flushing either. It never has done so; these tests simply passed due to a lack of output buffering. Thus they were never passing for the reason they claimed they were. ... (7 more lines)		 13:20
rakudo/nom: 138b6ce000 | (Jonathan Worthington)++ | src/core/IO/Handle.pm
Have tell do a flush first.

Otherwise it can report the position incorrectly if we have got buffering enabled.		 13:22
Zoffix well, other than log, but there's the multiplication -> sum thing; log(A*B) = log(A) + log(B) 13:23
m: sub huge_log_10($a) { my $ans = 0; $ans += log10 10**300 while ($ans /= 10**300) > 10**300; $ans + log10 $ans }; say huge_log_10 10**1000 13:26
camelia -Inf?
Zoffix hehe, well, that's the most wrong answer, I'd say :) 13:27
timotimo :D
m: say log10 10**300
camelia 300?
timotimo not sure if you should put $ans back into the calculation over and over like that 13:28
Zoffix m: 'sub huge_log_10($a is copy) { my $ans = 0; $ans += log10(10**300) while ($a /= 10**300) > 10**300; $ans + log10 $a }; say huge_log_10 10**1000
camelia 5===SORRY!5=== Error while compiling <tmp>?Unable to parse expression in single quotes; couldn't find final "'"?at <tmp>:1?------> 3s + log10 $a }; say huge_log_10 10**10007?5<EOL>? expecting any of:? single quotes? …
Zoffix m: sub huge_log_10($a is copy) { my $ans = 0; $ans += log10(10**300) while ($a /= 10**300) > 10**300; $ans + log10 $a }; say huge_log_10 10**1000
camelia 700?
timotimo close
Zoffix but no cigar
m: sub huge_log_10($a is copy) { my $ans = 0; repeat { $ans += log10(10**300) } while ($a /= 10**300) > 10**300; $ans + log10 $a }; say huge_log_10 10**1000 13:29
camelia 1000?
Zoffix m: sub huge_log_10($a is copy) { my $ans = 0; if $a > 10**300 { repeat { $ans += log10 10**300 } while ($a /= 10**300) > 10**300 }; $ans + log10 $a }; say huge_log_10 $_ for 10, 10**100, 10**99, 10**1000, 10**10000 13:31
camelia 1?100?99?1000?10000?
Geth rakudo/nom: 72bf0238a5 | (Jonathan Worthington)++ | src/core/IO/Handle.pm
Revert "Have tell do a flush first."

This reverts commit 138b6ce0009bd91d5d8893c61539773b8d0e41b1. Since the VM is doing the buffering, it's better to let it manage this bit of sync-up also.		 13:41
travis-ci Rakudo build failed. Jonathan Worthington 'Have tell do a flush first. 14:06
travis-ci.org/rakudo/rakudo/builds/271686300 github.com/rakudo/rakudo/compare/7...8b6ce0009b
buggable [travis build above] ? All failures are due to timeout (0), missing build log (0), GitHub connectivity (0), or failed make test (1). Across all jobs, 27 unique test files failed.
jdv79 any ideas why one would do "stat <= 0" before calling mkdir in C? 14:07
isn't that all return values?
ilmari according to both the POSIX and Linux manpages it always returns 0 or -1, yes 14:08
jdv79 maybe its a question for #moarvm then cause its in there. weird. 14:09
jnthn Well yay, got a clean spectest now with output buffering enabled by default for non-TTYs 14:10
timotimo that's lovely 14:11
Geth nqp: 83197a2721 | (Jonathan Worthington)++ | tools/build/MOAR_REVISION
Bump to latest MoarVM.
 14:32
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...3-g41e1b7c
rakudo/nom: 44680029b4 | (Jonathan Worthington)++ | tools/build/NQP_REVISION
Bump to get latest MoarVM version.

Has a number of fixes related to output buffering.		 14:33
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....2-g83197a2
4b02b8aadc | (Jonathan Worthington)++ | src/core/IO/Handle.pm

Prior to this change, output buffering had to be explicitly turned on using `:buffer` when opening a file, and was never turned on for the standard output handles. Now it will be turned on for handles that are not TTYs. This gives a sizable performance boost for output. For example, writing a million line file drops from ~2.05s to ~1.29s, thus running in 63% of the time it used to. Presuming UTF-8 encoding, this brings us to being 1.4x slower than Perl 5 (which is also doing output buffering) at this benchmark, as opposed to 2.2x slower before.
geekosaur jdv, iirc mkdir in moarvm is shell mkdir -p, so it tests for existence/not a directory at each level 14:36
which is not how I'd do that, but I already tilted at that windmill
timotimo yes! i love it! 14:43
Zoffix \o/ 14:44
lizmat afk for dinner& 15:35
japhb OK, so the three major benchmarks we seem to be running of late are: the [Tux] CSV benchmark, jnthn's "read a million lines", and jnthn's "write a million lines". Any others in relatively active use? 16:19
jnthn The write one just got faster again :) 16:24
japhb W00t! 17:12
travis-ci Rakudo build passed. Jonathan Worthington 'Bump to get latest MoarVM version. 17:24
travis-ci.org/rakudo/rakudo/builds/271715837 github.com/rakudo/rakudo/compare/7...680029b417
BenGoldberg m: sub huge_log_10($a is copy, $pow) { my $ans = 0; if $a > 10**$pow { repeat { $ans += log10 10**v } while ($a /= 10**$pow) > 10**$pow }; $ans + log10 $a }; say huge_log_10($_, 300) for 10, 10**100, 10**99, 10**1000, 10**10000 18:14
camelia 5===SORRY!5=== Error while compiling <tmp>?Undeclared routine:? v used at line 1??
BenGoldberg m: sub huge_log_10($a is copy, $pow) { my $ans = 0; if $a > 10**$pow { repeat { $ans += log10 10**$pow } while ($a /= 10**$pow) > 10**$pow }; $ans + log10 $a }; say huge_log_10($_, 300) for 10, 10**100, 10**99, 10**1000, 10**10000
camelia 1?100?99?1000?10000?
BenGoldberg m: sub huge_log_10($a is copy, $pow) { my $ans = 0; if $a > 10**$pow { repeat { $ans += log10 10**$pow } while ($a /= 10**$pow) > 10**$pow }; $ans + log10 $a }; say huge_log_10($_, 100) for 10, 10**100, 10**99, 10**1000, 10**10000 18:15
camelia 1?100?99?1000?10000?
BenGoldberg m: sub huge_log_10($a is copy, $pow) { my $ans = 0; if $a > 10**$pow { repeat { $ans += log10 10**$pow } while ($a /= 10**$pow) > 10**$pow }; $ans + log10 $a }; say huge_log_10($_, 1) for 10, 10**100, 10**99, 10**1000, 10**10000
Zoffix ?
camelia (timeout)1?
Zoffix The 10**300 is just near-upper limit before that Int when numified would be Inf
huggable: log 18:16
huggable Zoffix, Comes out 2.41x faster than core .log10 and can handle Ints larger than 1.8e308: gist.github.com/zoffixznet/2539e8b...43e173fe8f
Zoffix Also; ^ improved version of the routine
well, performance-wise, not readability-wise :P
BenGoldberg nqp looks very lisp-y to me. 18:17
Sure, it's got commas, and the names of the functions are on the wrong side of the (, and progn is misspelled stmts, but it's still clearly lisp. 18:18
Zoffix :)
geekosaur somewhere there's a backronym for "perl" where the "l" is LISP 18:19
[Coke] the malformed utf8 issue is fixed for me on the mac; any idea why I was able to reproduce so much more consistently than others? 18:23
jnthn++
jnthn [Coke]: Glad it's fixed. It could have been something about where boundaries fell in the input or some such 19:03
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/09/04/...a-reading/ 20:59
samcv lizmat++ 23:14

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!