Geth 6.d-prep: a306a37dc9 | (Zoffix Znet)++ (committed using GitHub Web editor) | TODO/README.md
TODO: toss dead files

It's a bit annoying to write a test in a file, just to find out the file isn't being run and doesn't compile.		 00:02
roast: 986f263ef4 | (Zoffix Znet)++ | S10-packages/require-and-use--dead-file.t
Rename dead file squatting on a good name

The file isn't in t/spectest.data and doesn't even compile.		 00:05
roast: 5685050756 | (Zoffix Znet)++ | S10-packages/require-and-use.t
Test circular dependency is detected

RT#126688: rt.perl.org/Ticket/Display.html?id=126688
  (only the new test was added in this commit. The previous
contents of the file weren't being run nor did they compile. They were moved to require-and-use--dead-file.t in
  github.com/perl6/roast/commit/986f263ef4 )		 00:17
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126688
rakudo/nom: 3da62db991 | (Zoffix Znet)++ | t/spectest.data
Add new test file to list of test files to run
roast: 961b973779 | (Zoffix Znet)++ (committed using GitHub Web editor) | S10-packages/require-and-use.t
Fix Engrish in test description
 00:20
roast: 0b6742697d | (Zoffix Znet)++ (committed using GitHub Web editor) | S02-types/set.t
Remove unintendeded interpolation…

  …in test's description		 00:24
roast: 1e20619853 | (Zoffix Znet)++ | S02-types/set.t
Test List of Pairs/Hash .Set coercer

  - Ensure the .values of Pairs get interpreted as weights		 00:37
roast: 19d353dd98 | (Zoffix Znet)++ | 2 files
Add RT ticket references to new tests
 00:38
roast: 8e382fb938 | (Justin DeVuyst)++ | S32-io/IO-Socket-Async.t
Tests for async socket returned port values. See RT#132135.
 02:46
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132135
geekosaur welp. looks like more Apple Xcode changes is indeed what's behind the new clock_gettime errors 04:12
[Tux] This is Rakudo version 2017.09-42-g3da62db99 built on MoarVM version 2017.09.1-21-g523725a3 06:09
csv-ip5xs 1.333 - 1.337
test 9.747 - 9.940
test-t 3.424 - 3.453
csv-parser 12.126 - 12.806
samcv geekosaur, i think i fixed that? 06:17
do you have the latest Moar?
geekosaur that was commentary based on discussion elsewhere. 06:18
samcv ah
geekosaur and it may in fact be a distinct issue that might bite later
there's a new Xcode that has messed with all that stuff again :/ 06:19
bartolin i'm still struggling with teaching the EvalServer to find BOOTSTRAP.nqp before 'make install' (RT #132101). ideas about that issue are very welcome :-) 06:34
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132101
bartolin the best idea i had so far, is to use an environmental variable -- like this gist.github.com/usev6/9a2fde23088b...3175641b4c
lizmat Files=1227, Tests=75115, 298 wallclock secs (14.64 usr 5.32 sys + 2016.98 cusr 210.03 csys = 2246.97 CPU) 09:04
jnthn bartolin: Is it not just that the arguments to create-jvm-runner or whatever ended up the wrong way around? It happened at some point for the MoarVM build 09:38
bartolin: fb0b3eb5c79223f is where I did that 09:39
s/did/fixed/
Hmm, looks like a newly added test for IO::Socket::Async is racey
I thought I'd got another nasty problem to solve
But no, new racey test. 09:40
Geth roast: 5efc3e5644 | (Jonathan Worthington)++ | S32-io/IO-Socket-Async.t
Fix race condition in socket test

We can't be sure the server connection callback will fire before the connect method of the client returns from its await.		 09:45
bartolin jnthn: i quite, i already tried something similiar to fb0b3eb5c -- but i'll check again this evening. 09:51
*i'm quite sure ...
eater where are the constants from IO::Socket::INET::PIO sourced from? github.com/rakudo/rakudo/blob/nom/...et/INET.pm 10:06
they are at least not the same as bits/socket.h> 10:07
defines them
Geth rakudo/supply-block-refactor: 547839200a | (Jonathan Worthington)++ | 2 files
Queue Supply messages on recursion

This handles the case where a Supply does an emit/done/quit and there is a code path that ends up looping back to the Supply itself. Due to messages on a Supply being serialized, this would result in a deadlock after the recent changes to the Supply concurrency model. Previously, it would work out for `supply`/`react` blocks due to their queueing of ... (24 more lines)		 10:09
jnthn That was tricky...
Now don't have any stresstest regression from that branch, at least 10:13
heh, an NYI survives in the branch that no spectest covers :) 10:35
jnthn adds some
pmurias bartolin: re the nativecallinvoke op, I can implement that as it's just a simpler nativecall op that doesn't do deconting 10:37
DrForr Well, Prague.pm last night was actually pretty large, I think we got ~12 people.
Geth rakudo/supply-block-refactor: 397692aca5 | (Jonathan Worthington)++ | src/core/Supply.pm
Some small optimizations to `supply`/`react`
 10:38
rakudo/supply-block-refactor: e0e5e6fac9 | (Jonathan Worthington)++ | src/core/Supply.pm
Handle await-all during adding a whenever
moritz DrForr: wow, that's nice
jnthn DrForr: Nice. Will it be a regular-ish meeting?
DrForr It apparently is; I was sitting next to the guy who ran the website and he sheepishly admitted that he hadn't updated it in a while. 10:39
jnthn Haha
jnthn will keep an eye on it
Hopefully I can join next time 10:40
DrForr Hope so. I also got a note saying that the mailing list had stopped working a few months ago as well, so apparently that side of things has been running on autopilot for a while. 10:41
jnthn I'd assumed not updated website and defunct mailing list = no meetings :P
DrForr I would have assumed much the same. 10:42
bartolin pmurias: that would be great. 10:46
Geth rakudo/supply-block-refactor: b16aba019b | (Jonathan Worthington)++ | src/core/Lock/Async.pm
Optimize recursion handling in Lock::Async

No semantic changes, this just rewrites a hot path in a more optimal way, without too much cost to its overall clarity.		 11:00
jnthn Well, I guess it's merge time :) 11:04
timotimo exciting! 11:09
dogbert17 jnthn: if you merge, I can subject hte code to some 'nasty' testing while you enjoy your lunch :)
Geth rakudo: the-eater++ created pull request #1169:
Fix PIO table so they are equal to the kernel values + add family packing		 11:14
rakudo/nom: 26 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/3...6646e36475		 11:16
jnthn That is decidedly the most difficult stuff I've done in a while.
Geth roast: 0cec8b172d | (Jonathan Worthington)++ | S17-supply/syntax-nonblocking-await.t
Test various cases of await in react/supply blocks
 11:18
lizmat pulls, builds and sets of a spectest
jnthn Basically, the concurrency model underneath supplies has changed and been unifited, so supply blocks and the other stuff share a common approach 11:19
It's also been made much more 6.d friendly
So that you can now do an `await` in a react/supply/whenever without actually clogging the thread pool up (provided you're in the pool when you do the await)
s/unifited/unified/ 11:20
dogbert17 jnthn++, might this be worthy of a blog post perhaps
jnthn Note, `use v6.d.PREVIEW` required for that
Yeah, will go in my queue 11:21
At the heart of it is a new Lock::Async, which is a pretty interesting mechanism
dogbert17 do you want me to be really 'mean', i.e. try with MVM_SPESH_NODELAY and _BLOCKING etc
jnthn Can try, sure
dogbert17 ok, will do :) 11:22
timotimo so awaiting a lock::async will - in 6.d - put your continuation into the thread pool and one of the registered waiting tasks will be woken up each time the lock is "released"?
jnthn Yes
Though actually we already are doing that today for supplies
Inside of CORE.setting 11:23
timotimo OK, but the user can't do it like that without significant effort
jnthn supply/react blocks already use this model too
Though you actually need to have competing incoming data to really hit this 11:24
The only effort you need to take to get the full non-blocking semantics is to stick in `use v6.d.PREVIEW` :)
Supplies now use some of the 6.d internals even in 6.c, as an implementation detail 11:25
But the exact mechanism supply/react blocks used for concurrency control was always an implementation detail; that's kinda the point of an abstraction :)
timotimo right, since whenever blocks must already be assumed to run on any thread, right?
jnthn Right
Also the new affinity scheduling makes competition less likely 11:26
*contention
If it's for procs/sockets
dogbert17 starts a 'MVM_SPESH_BLOCKING=1 make spectest'
jnthn There's some other neat things you can do now though
m: my $s = supply { my $done; until $done { emit $++ }; CLOSE { $done = True } }; react { whenever $s { .say } } 11:28
camelia (timeout)
jnthn Or maybe better 11:29
lizmat 14-15, 19-20 # jnthn, fails in t/spec/S32-io/IO-Socket-Async.t
jnthn my $s = supply { my $done; until $done { emit $++ }; CLOSE { $done = True } }; react { whenever $s { .say; done if $++ == 5 } }
lizmat jnthn: reliably so
jnthn Oh
Probably because those tests were put in without a MoarVM bump
timotimo is it the "get socket address" tests?
jnthn And they are testing the port number fix in MoarVM that was merged last night
lizmat perhaps.. I did do a reconfig, so, maybe we need a bump? 11:30
jnthn m: my $s = supply { my $done; until $done { emit $++ }; CLOSE { $done = True } }; react { whenever $s { .say; done if $++ == 5 } }
That's the one I meant
That now works
Before it would queue messages up forever
camelia (timeout)
lizmat jnthn: shall I do a bump ?
jnthn Now it prints 0 up to 5
lizmat: Yes, please do :)
timotimo hm, is that due to more than just backpressure?
jnthn timotimo: Yeah, that's 'cus we handle whenever differently now 11:31
Geth nqp: 59612c4229 | (Elizabeth Mattijsen)++ | tools/build/MOAR_REVISION
Bump MOAR for latest async fixes
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...23725a3... No newline at end of file
jnthn If the process of tapping something awaits, then we intercept it, take a continuation and then resume it after the lock is freed
timotimo OK, and now we await when there's too many things we've emitted 11:33
jnthn Yeah 11:35
timotimo that sounds good :)
jnthn hehe 11:36
$ ./perl6-m -e 'my $s = supply { my $done; until $done { emit "foo" }; CLOSE { $done = True } }; react { my $i = 0; whenever $s { $i++ }; whenever Promise.in(5) { say "Did $i emits in 5 seconds"; done } }'
Did 195981 emits in 5 seconds
m: my $s = supply { my $done; until $done { emit "foo" }; CLOSE { $done = True } }; react { my $i = 0; whenever $s { $i++ }; whenever Promise.in(5) { say "Did $i emits in 5 seconds"; done } } 11:37
camelia Did 137035 emits in 5 seconds
jnthn Oh, I guess it's bumped already :)
yeah :)
c: 2017.09 my $s = supply { my $done; until $done { emit "foo" }; CLOSE { $done = True } }; react { my $i = 0; whenever $s { $i++ }; whenever Promise.in(5) { say "Did $i emits in 5 seconds"; done } }
committable6 jnthn, ¦2017.09: ««timed out after 10 seconds» «exit signal = SIGHUP (1)»» 11:38
jnthn I need to add more tests :)
(To cover this new stuff)
But first, lunch :)
lizmat jnthn: confirm a bump fixes the test issues... running fill spectest now 11:39
dogbert17 I got some fails in t/spec/S32-io/IO-Socket-Async.t, wasn't there some changes done there a couple of hours ago 11:56
Geth rakudo/nom: d8890a8284 | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION
Bump NQP to get the latest Moar async fixes
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....f92f2fe... No newline at end of file
73aeee6ce7 | (Jonathan Worthington)++ | src/core/Supply.pm
jdv79 jnthn: oops - thanks for that race fix 12:06
jnthn jdv79: np :) 12:25
timotimo when i need my race fix i play mario kart :P
eater timotimo: I'm mostly content with Need For Speed 12:35
|Tux| This is Rakudo version 2017.09-69-gd8890a828 built on MoarVM version 2017.09.1-36-gfbd89898 12:38
csv-ip5xs 1.289 - 1.307
test 9.549 - 9.580
test-t 3.381 - 3.395
csv-parser 12.133 - 12.146
timotimo eater: the original? personally i was a big fan of nfs2 12:39
eater timotimo: tbh, Porsche Unleashed / Porsche 2000
timotimo haven't heard of those 12:40
lizmat .speed 12:41
TimToady just had S17-supply/syntax.t hang up while slowly chewing up gigs over a period of some minutes 12:49
timotimo after test 68? 12:50
that's also what i'm seeing
TimToady yeah, about there 12:51
jnthn After my merge, I presume? 12:55
timotimo i think so
jnthn :/
It's passed consistently here
timotimo yeah, after the merge
jnthn In a bunch of stresstest runs
dogbert17 ZOFFLOPS when using ASAN and MVM_SPESH_BLOCKING: t/spec/S02-literals/string-interpolation.t, t/spec/S17-promise/allof.t, t/spec/S17-supply/syntax.t and t/spec/S17-promise/basic.t
timotimo i'll try to golf a little 12:56
dogbert17 meh, ==18046== ERROR: AddressSanitizer failed to allocate 0x200000 (2097152) bytes of SizeClassAllocator32: Cannot allocate memory 12:57
in t/spec/S17-supply/syntax.t 12:58
#9 0xb5643498 in MVM_realloc /home/dogbert/repos/rakudo/nqp/MoarVM/src/core/alloc.h:20
#10 0xb5643498 in set_size_internal /home/dogbert/repos/rakudo/nqp/MoarVM/src/6model/reprs/VMArray.c:359
#11 0xb5643498 in push /home/dogbert/repos/rakudo/nqp/MoarVM/src/6model/reprs/VMArray.c:467
dogbert17 afk &
timotimo i put a "say supply done" in front of the done inside the interval supply, and that gets executed a seemingly-random amount of times 12:59
dogbert17 the errors in t/spec/S17-promise/basic.t and t/spec/S17-promise/allof.t are the 'time sensitive' tests discussed the other day 13:02
timotimo jnthn: when i reduce the for loop outside the start block to 2, i get it working. maybe it's a thread pool exhaustion issue, but that doesn't explain to me why it would consume cpu resources
jnthn Me either 13:03
Curiously, syntax.t just failed in my current stresstest run
Though I've a couple of locally applied optimizations that I was testing
ah, and they seem to have other fallout too
So likely not the same issue
Zoffix buggable: speed
buggable Zoffix, ▂▂▃▁▂▂▇▃▃▃▃█▅↑▄▂▃▃▃▄▂▃▁▁▃▅▄▄↑█▃▃▂▃▂▁▂▂▂▂▁▁▂▂▁▄▂▂▁▁ dates: 2017-09-05–2017-09-22; range: 3.376s–4.237s; speed: 2% faster
Zoffix buggable: speed :4
buggable Zoffix, ▆ ▇ ↑ ↑█ dates: 2017-09-05–2017-09-22
Zoffix, █ █▃█ ▃ ██ range: 3.376s–4.237s
Zoffix, █▃ ▄███▆ ▃▁ █ ▂ ▃█▆▄██▂▃ ▁ ▅ speed: 2% faster
Zoffix, ▆▅▇▁▄▅██▇▇█████▆██▇█▆█▂▂████████▇█▄▃▅▇▃▆▃▃▇▅▃█▄▅▁▂
timotimo locally i have moar compiled with --optimize=0, if that makes a difference
TimToady I don't 13:04
timotimo perhaps there's an issue with the timer being too short? i'll try a higher number
weird! 13:05
Zoffix lizmat: ^ it's that command... `buggable: speed 42 :4` `buggable: speed [show last N measurements only] :[show graph on 1..4 lines]`
timotimo i increased the number and got it to hang after a second, but after another two or three seconds it rushes through to the finish line
jnthn oh dammit, I know why the opt I thought of won't work :/
jnthn scraps that 13:06
timotimo even weirder: when i increase the interval to 10 seconds it still finishes in under one
jnthn What test are you looking at?
timotimo does Supply.interval(10) immediately fire the first one? it shouldn't
jnthn Yes
timotimo oh, sorry, one sec
jnthn It fires right away, then after 10, 20, etc. 13:07
iirc there's a second arg to control how long until the first firing
timotimo github.com/perl6/roast/blob/master...tax.t#L512
this is the one that hangs for me
jnthn Stresstesting again here
jnthn sticks that one test in a loop 13:10
So far 50 iterations without trouble 13:11
timotimo maybe your computer is too fast :)
jnthn It's competing with a stresstest run
timotimo mhm
jnthn Maybe but...I'd figure that a stresstest run going on at the same time would sahke it out
timotimo i wonder if you can get it to freeze like we have it by adding more timers to the program 13:12
jnthn Dunno. It's almost at 400 iterations now without a problem 13:13
jnthn And now nearly 500 13:14
timotimo i assume supply.interval isn't so happy when i stop the program in gdb? 13:25
would it try to catch up when i resume?
jnthn Mebbe, not sure 13:30
It's just passing on ticks that could from libuv
and so I presume that's suspended too 13:44
Geth rakudo/nom: 2a82623831 | (Jonathan Worthington)++ | src/core/Supply.pm
Optimize creation of supply block state object
 13:52
rakudo/nom: 3deda84224 | (Jonathan Worthington)++ | src/core/Supply.pm
Avoid a closure per emit into a supply/react block
rakudo/nom: f58ac99918 | (Jonathan Worthington)++ | 2 files
Streamline async socket message Supply

Implement the Tappable interface directly, rather than going through the `Supply.on-demand` machinery that adds extra safety checks and indirections. This boosts the number of requests per second in a simple Cro HTTP example by around 13%; for more direct users of IO::Socket::Async it will be more significant than that.		 14:41
nine jnthn: a stress test in another terminal window may not slow down your test as much as you'd think. AFAIK the Linux scheduler puts processes that run with the same pseudo terminal in a scheduling group with the express purpose of having e.g. a kernel compilation now slow down your UI too much. 15:36
jnthn nine: Hm, interesting :) 15:37
Though I did note that it sped up a lot after the stresstest got done :)
Geth rakudo/nom: 40c2d0cd52 | (Jonathan Worthington)++ | 2 files
Move socket reader tappable into socket class

The initial idea was to share it with Proc::Async, but it turns out they're just different enough it's probably not worth it.
rakudo/nom: c46de00f0b | (Jonathan Worthington)++ | src/core/IO/Socket/Async.pm
Optimize IO::Socket::Async.listen Supply

Again, by avoiding Supply.on-demand and its various protections. Gives a performance boost to async socket servers; in Cro it amounts to ~4% more requests per second.
jnthn Didn't yet manage to reproduce the issue, BTW. Will see if I can on my home machine over the weekend. 15:54
nine Missing serialize REPR function for REPR MVMCode (BOOTCode) 16:01
Oh...that one. Why does this stuff have to be so complicated?
Some milliseconds really are harder earned than others... 16:02
travis-ci Rakudo build failed. Jonathan Worthington 'Avoid a closure per emit into a supply/react block' 16:08
travis-ci.org/rakudo/rakudo/builds/278628591 github.com/rakudo/rakudo/compare/7...eda842247f
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
jnthn nine: Same with some RTs ;) 16:12
Righty, I'm off for a bit :)
samcv can we pass arrays to nativecall functions and how? 16:23
nine samcv: there's the CArray type 16:49
samcv: NativeCall is well documented on doc.perl6.org :)
samcv thanks. i tried to point my friend to that, after checking it out myself 16:54
dogbert11 .tell jnthn wrt the failing syntax.t test, got this after several attempts: gist.github.com/dogbert17/d018b0f6...0f734d0dbc 17:26
yoleaux dogbert11: I'll pass your message to jnthn.
Zoffix So, $?USAGE.... it just gotta be compile time? 18:27
(as opposed to being a run time thing)
jnthn The ? twigil means compile time, yeah 18:29
Zoffix Yeah, but I meant changing it to $*USAGE
jnthn Is that useful?
I mean, it's not like you'd really need to override it...I guess :) 18:30
And I'm not sure what'd bind it
Zoffix thinks more about it
jnthn I guess my first pass at implementing it would be to keep track of if $?USAGE is mentioned, and if it is then install if in the UNIT scope 18:31
Though perhaps at the end of parsing so we get all the multi MAIN candidates
So if somebody writes it ahead of them all then it has all that it should
That'd not work out too well if somebody did constant foo = $?USAGE but, well, tough :) 18:32
Zoffix I have a patch that has it as Nil at compile time but proper message at run time. I just don't get what's supposed to happen with: `BEGIN say $?USAGE; sub MAIN($a) {}` how can it have compile time value if MAIN wasn't compiled yet? 18:33
jnthn Yeah, that doesn't make so much sense
tbh it feels more like a subroutine than a variable... 18:36
I thought there even was a sub you could define to get custom usage messages
Zoffix Yeah, there is
jnthn m: sub MAIN($x) { }; sub USAGE() { "foo" }
camelia ( no output )
Zoffix m: sub MAIN($x) { }; sub USAGE() { "foo".say }
camelia foo
jnthn m: sub MAIN($x, $y) { }; sub USAGE() { "foo" }
camelia ( no output )
jnthn Of, you have to say it yourself :/ 18:37
m: sub MAIN($x, $y) { }; USAGE()
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared name:
USAGE used at line 1
jnthn Though I guess that's flexible too
Zoffix I think the usecase I noticed most common for people wanting $?USAGE is they just want to slightly alter the default message...
jnthn Right 18:38
Geth rakudo/userland-USAGE: bbedf18d3c | (Zoffix Znet)++ | src/core/Main.pm
Make $?USAGE available in userland

  - This patch makes $?USAGE available in userlange and its compile-time
   value is `Nil`. When MAIN_HELPER has been run, then its value
   is the default usage message
  - The problem is `$?` signifies compile-time value, but what's meant
   to happen with `BEGIN say $?USAGE; sub MAIN($a) {}`? How can it
... (5 more lines)
Zoffix .in 8d so, what's happening with $?USAGE? 18:40
yoleaux Zoffix: I'll remind you on 30 Sep 2017 18:40Z
Zoffix &
perlpilot S06 says "If there is no C<USAGE> routine, a default message is printed to standard error." and "This usage message is automatically generated from the signature (or signatures) of C<MAIN>. This message is generated at compile time, and hence is available at any later time as C<$?USAGE>." That implies (to me) that it's only available in $?USAGE *after* compile time and that *during* compile time, Nil should be fine. 18:51
(but, perhaps there's an argument for building it piece-wise so that it's value is available during compile time as it's being built) 18:53
Zoffix As far as I can tell, it's currently it's generated at runtime. 19:00
And I don't think it needs to be generated at compile time. Most cases of MAIN won't get precompiled, so whatever we do at compile time for this the user is paying for it on each run, and if the message is never printed, it's all wasted effort 19:02
perlpilot Zoffix: it would be very useful if $?USAGE were available in the USAGE sub for those that just want to tweak it rather than re-gen the whole thing. 19:24
Zoffix perlpilot: yeah, that's what my patch does
sub USAGE is called at runtime
committable6: help 19:25
committable6 Zoffix, Like this: committable6: f583f22,HEAD say ‘hello’; say ‘world’ # See wiki for more examples: github.com/perl6/whateverable/wiki/Committable
Zoffix c: bbedf18d3c say $?USAGE
committable6 Zoffix, ¦bbedf18: «Cannot find this revision (did you mean “8efffb1”?)»
perlpilot then I'd merge it if I were you (assuming there's no roast breakage)
Zoffix Hm, I thought there was a way to run a commit from a branch... 19:26
But anyway `sub MAIN ($x) {}; sub USAGE { $?USAGE.uc.say }` prints default usage in uppercase
perlpilot: ok, thanks :) I'll merge in a week unless someone has better ideas. Just kinda iffy for `$?` variable to not have a proper value at compile time. 19:27
I guess the crux of my hesitation is that the variable is mis-named.
S02 says "All $? variables are considered constants, and may not be modified after being compiled in." 19:29
.oO( install a Proxy; hey, technically I'm not "modifying" any variables ^_^ )
 19:30
perlpilot That negates any argument about a piece-wise $?USAGE during compile time as far as I'm concerned. It sounds like $?VARS should be built once at some canonical time (the very end of compile time?) 19:33
Zoffix S02 says you can modify them at compile time 19:34
But I don't get the usefulness of piece-wise making of $?USAGE; also there's a problem that we don't wanna pay for making it
I'd just shove it into PROCESS:<$USAGE> from within MAIN_HELPER. Let it live in the bunch with $*KERNEL and stuff 19:36
.ask TimToady S02 says $? vars must not be changed after compile time; that makes $?USAGE kinda iffy, since we run all the sub MAIN bits at runtime. I'm thinking of changing it to $*USAGE on Sept 30th. Thoughts? IRC discussion: irclog.perlgeek.de/perl6-dev/2017-...i_15204296 19:43
yoleaux Zoffix: I'll pass your message to TimToady.
Zoffix .tell TimToady worth clarifying: currently $?USAGE isn't available to users (so the change won't be breaking any code) 19:44
yoleaux Zoffix: I'll pass your message to TimToady.
bartolin jnthn: i can't find a way to fix the issue with perl6-eval-server by moving the arguments to create-jvm-runner around. the evalserver starts, but once I run eval-client.pl I get a NoSuchFileException because it looks for BOOTSTRAP.jar below libdir 19:54
jnthn bartolin: Aww, too bad. Then it must be something else. 19:55
bartolin jnthn: the relevant line seems to be here: github.com/rakudo/rakudo/blob/c46d...er.nqp#L52
falling back to blib/Perl6/BOOTSTRAP.jar 'works': gist.github.com/usev6/9a2fde23088b...3175641b4c (second comment) 19:56
maybe i'm missing an easy fix ... 19:57
Geth rakudo/nom: 17aead2759 | usev6++ | 4 files
[jvm] Update requirement for jdk 1.8

It's no longer possible to build NPQ with JDK 1.7, since nqp::codes requires Java8 (cmp. nqp commits de18e88970 and 8d8bb5d3bc).		 20:33
nqp: cd588c17da | usev6++ | 2 files
[jvm] Add note about requirement for jdk 1.8
 20:35
gfldex jnthn: while siegeing the golfed httpd I got "MoarVM oops: Return label is NULL!" 21:10
stacktrace: gist.github.com/gfldex/8999a8bd511...e6887ff08b
Geth rakudo/nom: ffd17990d0 | (Nick Logan)++ (committed using GitHub Web editor) | .travis.yml
[jvm] Update requirement for jdk 1.8

  See: github.com/rakudo/rakudo/commit/17...5b901428b0		 21:12
bartolin ah, missed that, ugexe++ 21:18
gfldex jnthn: the evil RAMz eating monster seams to be banished tho 21:57
jnthn Well, I guess that's bad news and good news respectively :) 22:11
Will probably be Monday before I dig any further; quite tired from the week's supply guts hackery, and it's both national railway day *and* some food truck festival here tomorrow, so I figure I'll distract myself with at least one of those :) 22:13
thundergnat seen samcv 22:26
argh
tell samcv I tried out that branch with the 'natural' number collation and was found things I would consider suspect if not completely wrong. Demo test script at gist.github.com/thundergnat/8a4857...7777e85874 22:30
argh again. 22:31
geekosaur leading ,.
thundergnat .tell samcv I tried out that branch with the 'natural' number collation and was found things I would consider suspect if not completely wrong. Demo test script at gist.github.com/thundergnat/8a4857...7777e85874
yoleaux thundergnat: I'll pass your message to samcv.
geekosaur er .
I can't type
samcv hey
yoleaux 22:31Z <thundergnat> samcv: I tried out that branch with the 'natural' number collation and was found things I would consider suspect if not completely wrong. Demo test script at gist.github.com/thundergnat/8a4857...7777e85874
thundergnat geekosaur, yeah you and me both. :)
samcv can you give me some of the output?
thundergnat sure, here or a gist? 22:32
samcv gist is fine. depends how long it is 22:33
thundergnat gist.github.com/thundergnat/87cd09...df5443e679
Not ALL of that is suspect but a bunch of it is. 22:34
first line is Sort::Naturally natural sort second is collate method in that gist ^^ 22:35
samcv ok thank you 22:38
would you mind making an issue on the moarvm issue tracker for feature request and link to both of those gists?
thundergnat Sure
samcv awesome :) 22:39
Geth roast: skids++ created pull request #328:
Add tests for RT#104980		 23:24
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=104980
Geth roast: 49f2e05f05 | skids++ | S12-construction/BUILD.t
Add tests for RT#104980
roast: d06b0a2308 | skids++ (committed using GitHub Web editor) | S12-construction/BUILD.t
Merge pull request #328 from skids/rt104980

Add tests for RT#104980
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=104980
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=104980
travis-ci Rakudo build errored. Nick Logan '[jvm] Update requirement for jdk 1.8 23:44
travis-ci.org/rakudo/rakudo/builds/278783880 github.com/rakudo/rakudo/compare/1...d17990d013
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
Geth rakudo/nom: 7af339b91d | (Nick Logan)++ (committed using GitHub Web editor) | .travis.yml
Use proper java 8 jdk package
 23:49
Zoffix Travis error on all Linux builds only: E: Package 'openjdk-8-jdk' has no installation candidate 23:50
ah fixed already 23:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!