Zoffix uhhh.... do I have to know whe the proc finished reading $*IN before I do Proc::Async.close-stdin? :/ 00:09
:| getting reaaaly weird results from my Proc herder 00:10
m: gist.github.com/zoffixznet/df66845...e4ff051514 00:13
camelia No such method 'out' for invocant of type 'X::AdHoc'
in block <unit> at <tmp> line 76
Zoffix Which isn't that ^ but rather it's meant to output `"barBAR\n"␤"mooMOO\n"␤"meowMEOW\n"␤"berBER\n"␤"fooFOO\n"` but sporadically, some of the strings are missing the uppercase part, which comes from $*IN.slurp; and sometimes the strings are entirely empty 00:14
and the empty-string thing happens more oftener if I add `await Promise.in: 2; ` before $proc.close-stdin :S wat 00:15
MasterDuke don't think this is the problem, but it this a copy-pasto? gist.github.com/zoffixznet/df66845...p6-L25-L26 00:18
*is this
Zoffix Yeah. Thanks. 00:19
Ah, I'm a n00b. .write/.print return Promises you're supposed to await :} 00:22
Yeah, changing the STDIN print line to `await $in ~~ Blob ?? $proc.write: $in !! $proc.print: $in;` fixed all the issues 00:23
Proc::Async.kill don't work all the time :/ 01:08
hm, tho can't reproduce in smaller example :/ 01:09
Zoffix hopes it's a bug in my code
MasterDuke general fyi. i updated github.com/rakudo/rakudo/pull/1091 to not hang with lizmat's test case, and then rebased and resolved the merge conflicts. i believe it's good to go 01:50
BenGoldberg So I am attempting to create a solution for one of the feature requests I rakudobugged -- namely, something perl6ish which is equivilant to C's typedef double (*callback_t)(int); 03:49
yoleaux 03:36 EDT <AlexDaniel> BenGoldberg: oh yeah, but it doesn't mean that it will default to 2014.01, because in most cases this is not what people are looking for. irclog.perlgeek.de/perl6-dev/2017-...i_14669729
BenGoldberg Here's my code so far: gist.github.com/BenGoldberg1/19e6e...ea1dd182c9 03:50
But, when I attempt to run it, I get this: fpaste.scsys.co.uk/563988 03:52
Which is a seriously weird error message.
How does NQPMu leak out? 03:53
Oops, that was the wrong paste (and wrong error message for me to complain about)... 03:57
fpaste.scsys.co.uk/563989
===SORRY!===␤QAST::Block with cuid 1 has not appeared 03:58
samcv yay got rakudo in Sabayon (gentoo derivative binary distro) 05:21
success! take over the world perl 6
got it in the official repos i mean
[Tux] This is Rakudo version 2017.05-332-gb667e818c built on MoarVM version 2017.05-25-g62bc54e9 05:59
csv-ip5xs 3.026
test 13.331
test-t 4.493 - 4.807
csv-parser 12.943
Geth rakudo/nom: 348891488c | (Stefan Seifert)++ | src/core/Env.pm
Revert "Implement %?ENV for the core setting"

This reverts commit d3e8c82dc2f14b2bf1e41a39982644d33c8c47b2.
Baking ENV into CORE.setting.moarvm at compile time prevents packaging rakudo for openSUSE as the rpm linter rightfully complains about the BUILDROOT path being included in the compiled file. This would also include much more information about the build server than the user should be able to get.
As we don't know any use case for this unspecced and untested feature anyway, it's better to remove it.		 08:04
nine lizmat: ^^^
lizmat nine: noted 09:49
fwiw, it was more a case of: now we can, let's do it :-) 09:50
afk again 10:02
Zoffix .tell BenGoldberg `===SORRY!===␤QAST::Block with cuid 1 has not appeared` is a bug and users should never see errors about QAST stuff. In this case, it looks a lot like the error you get when you try to use whatevercode in chained ops, like `5 < *.abs <7` Do you got any of that in your module? 10:22
yoleaux Zoffix: I'll pass your message to BenGoldberg.
Zoffix samcv++ great!
buggable: speed 6
buggable Zoffix, ▁▁▄▄█▃ data for 2017-05-31–2017-06-02; range: 4.364s–4.807s; 3% slower
Zoffix buggable: speed 20
buggable Zoffix, ▂▃▁▆▇▃▅▄▂▂▃▂▃▆▂▂▅▅↑▄ data for 2017-05-25–2017-06-02; range: 4.286s–4.807s; 4% slower
samcv what did i do?
Zoffix samcv │ yay got rakudo in Sabayon (gentoo derivative binary distro) 10:23
samcv │ success! take over the world perl 6
samcv oh yay
:)
Zoffix :)
samcv work domination
*world
typo but it works that way too i guess ;)
masak it worlds that way too :) 10:33
dogbert11 ZofBot: is Zoffix asleep? 11:46
ZofBot No such method 'close' for invocant of type 'Variable'
in block at <tmp> line 1
in block <unit> at <tmp> line 1

» m: multi sub trait_mod:<does>(Variable:D $v, IO ) { $
dogbert11 hmm
Zoffix No. Why? 12:05
dogbert11 had a question 12:07
m: sub grab(+@a) { "grab $_".say for @a }; grab(flat $(1, 2)) # is this correct, wasn't sure I understood your answer correctly yesterday 12:08
camelia grab 1
grab 2
Zoffix Yes, that's correct. 12:10
dogbert11 cool, then I'll have to change some docs
Zoffix The answer meant `flat` and `$( )` in that code are irrelevant.
m: sub grab(+@a) { dd @a }; grab(flat $(1, 2)) 12:11
camelia (1, 2)
Zoffix m: sub grab(+@a) { dd @a }; grab(flat (1, 2))
camelia (1, 2)
Zoffix m: sub grab(+@a) { dd @a }; grab(1, 2)
camelia [1, 2]
Zoffix ^ they all end up the same thing (basically)
dogbert11 interesting, the example I used came from here: docs.perl6.org/language/functions#...onventions 12:12
Zoffix shakes head at "...which is shorthand for something very close to:"
Explaining a thing by comparing it to a much more complex thing is a poor explanation :/ 12:13
It's a bit iffy the type @a ends up as is wobbly 12:14
m: sub grab(+@a) { dd flat @a; }; grab (1, (2, 3)).Seq
camelia (1, 2, 3).Seq
Zoffix m: sub grab(+@a) { dd flat @a; }; grab (1, (2, 3))
camelia (1, $(2, 3)).Seq
dogbert11 perhaps there are more mistakes on that page 12:15
Zoffix I'd even say that's a bug. In both cases the inner list isn't containerized, but in some instances it gets containerized when given to a +@a slurpy
mc: m: sub grab(+@a) { dd flat @a; }; grab (1, (2, 3)).Seq 12:16
committable6 Zoffix, ¦2015.12: «(1, 2, 3).Seq»
dogbert11 oO(where will this end)
Zoffix Oh wait, I see the consistency.
Oh wait, no I don't 12:17
m: sub grab(+@a) { @a[3] = 42; dd @a }; grab (1, (2, 3)) 12:19
camelia [1, (2, 3), Any, 42]
Zoffix m: sub grab(+@a) { @a[3] = 42; dd @a }; grab 1..*
camelia (1, 2, 3, 42, 5, 6, 7, 8, 9, 10... lazy list)
Zoffix m: sub grab(+@a) { @a[3] = 42; dd @a }; grab (1, 2, 3).Seq
camelia Cannot modify an immutable Str (Nil)
in sub grab at <tmp> line 1
in block <unit> at <tmp> line 1
Zoffix Has the potential for this ^ bug that'll only manifest itself for some particular input. LTA
dogbert11 this line will be changed later 'grab(flat $(1, 2)); # OUTPUT: «grab 1 2␤» '
Zoffix m: sub grab(+@a) { dd @a }; grab %(:42a, :72b); grab (1, (2, 3)); grab [1, (2, 3)]; grab (1, (2, 3)).Seq 12:22
camelia [:a(42), :b(72)]
[1, (2, 3)]
[1, (2, 3)]
(1, (2, 3))
Zoffix So looks like only Seq is affected 12:23
Filed as rt.perl.org/Ticket/Display.html?id=131483 12:26
I need Proc::Async.kill fixed for my toaster. I can think of a way to workaround it, but it's too much work and blocks most of functionality being in one shiny module 12:33
Zoffix puts on combat gear 12:34
Time to find this bug!
ZofBot: cancel all of my appointments!
ZofBot Zoffix, ^@array], @array[*-1] xx * Note that hypers promise that you don't care in what order the processing happens, only that the resulting structure ends up in a form consistent with the inputs
timotimo ZofBot: i'm looking into it a little bit right now 12:39
ZofBot timotimo, perl,
timotimo oops, i meant Zoffix 12:41
Zoffix Cool :) 12:43
timotimo it seems like the tasks are being set up with a set of ops that doesn't include a "cancel" op 12:44
wait 12:45
i might be looking at the wrong part of the whole
Zoffix possibly, the the killing works fine if it's just 1 proc 12:48
timotimo Zoffix: in what way does your Proc::Q fail?
Zoffix timotimo: I golfed it down: perl6 -e 'await ^2 .map: {start { with Proc::Async.new: $*EXECUTABLE, "-e", "sleep" -> $p { Promise.in(⅓).then: {say "Killing"; $p.kill: SIGTERM}; await $p.start } }}
^ that will more often than not hang, because one of the procs doesn't get killed, but if you change that `^2` to `^1` then it works fine all the time
timotimo "sleep" -> $p?
oh 12:49
that's a with there, k
Zoffix "sleep" is what the launched proc runs, -> 4p is the proc
timotimo yup i see it not terminate
bleh, SIGTTOU 12:51
i don't know how this works
Zoffix :)
timotimo ah! 12:52
$*EXECUTABLE
perl6-gdb-m
Zoffix ah :DF
timotimo Zoffix: you're killing before the process has started 12:58
that seems dangerous, but it shouldn't cause a hang
Zoffix Ah, right. I'll amend the final code to compensate for that. But it hangs with later periods before killings too. Original issue was discovered with kill after 4 seconds 12:59
timotimo er, huh. 13:00
the await $p.start waits for far too long
Zoffix It awaits until the process is don't doesn't it? 13:01
timotimo ah
i've not used proc::async enough
Zoffix I added some print statements to Proc::Async.kill and MVM_proc_kill_async and looks like despite two .kills being called, the op is called just once: gist.github.com/zoffixznet/7d3b2d9...ef6e68cc59 13:02
(well, MasterDuke pointed this out last night, I'm just replicating)
timotimo interesting 13:03
Zoffix "It awaits until the process is don't doesn't it?".... is "done" :|
timotimo yeah
could it be it's accidentally cancelling the task that contains the second kill? 13:04
because it's not returning from the kill op 13:05
when i lower the number of max threads, the whole thing works 13:08
Zoffix perl6 -e 'use v6.d.PREVIEW; await ^2 .map: {start { with Proc::Async.new: $*EXECUTABLE, "-e", "say qq|started \$*PID|; sleep" -> $p { Promise.in(1).then: {CATCH { default { say "murder! $_" } }; say "Killing " ~ $p.WHERE; $p.kill: SIGTERM}; await $p.start } }} 13:12
This gives me "murder! Type check failed for return value; expected return type Int cannot be itself (perhaps returning a :D type object?)"
Zoffix eyes that `once`: github.com/rakudo/rakudo/blob/3488...#L145-L151 13:13
'cause $*KERNEL wouldn't be inited until it's inside my Promise already 13:14
Zoffix tries simlififying that bit
timotimo ooh, a race in $*KERNEL being set up? 13:16
Zoffix Ahaha! Yes. This is where the bug's at! This no longer hangs: perl6 -e '$*KERNEL.signal: SIGTERM; await ^2 .map: {start { with Proc::Async.new: $*EXECUTABLE, "-e", "sleep" -> $p { Promise.in(⅓).then: {say "Killing"; $p.kill: SIGTERM}; await $p.start } }}' 13:17
'cause stuff in method signal is already setup
[Coke] in straight p6 code, I can replace stderr() with $*ERR; what about the QAST code: QAST::Op.new(:op<getstderr>) ?
Zoffix Well, thanks for help :D I'll clean it up to avoid the race and fix it.
timotimo [Coke]: what's the question? 13:20
Zoffix [Coke]: no idea; QAST::Var.new( :name('$*ERR'), :scope('dynamic') ) ?
[Coke] there are places in perl 6 that use the raw stderr, when everything should be using $*ERR
timotimo ah
yeah, what zoffix said should do it 13:21
[Coke] .. and Zoffix is probably very close there. Danke.
timotimo or maybe
DYNAMIC('$*ERR')?
that's what i get from a --target=ast
[Coke] github.com/hoelzro/p6-io-string/issues/10 13:27
timotimo: oh, right, I can make p6 tell me how to do it. :)
jnthn: does that io-string issue look like a familiar error message? 13:35
jnthn [Coke]: Well, I added it, so yes :) 13:38
[Coke]: However, it overrides method say 13:39
So I'm not really sure what'd be going on 13:40
[Coke] .seen hoelzro
yoleaux I saw hoelzro 5 May 2017 21:26Z in #perl6: <hoelzro> ok
Zoffix [Coke]: that sounds like you're using too old a version of it. 13:41
[Coke] error came off a zef install
===> Testing: IO::String:ver('0.1.0'):auth('Rob Hoelz') 13:42
which is the version in the meta json
Zoffix Infact, twice too old; this was a bug that got fixed, then it got broken again with .lines and that got fixed too :P github.com/hoelzro/p6-io-string/commits/master
[Coke] (on master)
Zoffix Ah, damn, the version never got bumped
[Coke]: I'll send a PR to fix it. In the meantime, you can do zef --force install github.com/hoelzro/p6-io-string/ar...master.zip
.ask I recall there was some thing (made by tony-o IIRC) that figures out what commit a particular version is at. Any idea where it is? Seems it needs a bit of mending to point to HEAD for latest version instead of the commit the version got bumped at. Otherwise, any bug fixes, say coming in from PRs, won't get propagated to users if the author never bumps the version in meta file,. which is an easy thing 13:45
yoleaux Zoffix: I'll pass your message to I.
Zoffix to forget to do
yoleaux: dumb ass
[Coke] Zoffix++
Zoffix .ask ugexe I recall there was some thing (made by tony-o IIRC) that figures out what commit a particular version is at. Any idea where it is? Seems it needs a bit of mending to point to HEAD for latest version instead of the commit the version got bumped at. Otherwise, any bug fixes, say coming in from PRs, won't get propagated to users if the author never bumps the version in meta file,. which is an easy
yoleaux Zoffix: I'll pass your message to ugexe.
Zoffix thing to forget to do
[Coke] wonders if $*ERR is defined early enough for me to use it in src/Perl6/Actions.nqp 13:48
(get a lot of # Cannot find method 'print' on object of type NQPMu) after trying that change locally)
Zoffix Don't know. But for record it's defined in src/core/io_operators.pm: github.com/rakudo/rakudo/blob/nom/...#L188-L189 13:50
[Coke] Zoffix: on the plus side, jnthn has already greatly reduced the amount of uncaught stderr in xt/examples* 13:51
Zoffix cool
[Coke] Down to a few "Potential Difficulties", 'useless use', and "WARNINGS" 13:53
jnthn $*ERR in Actions.nqp won't work out 13:57
However, we could potentially make it do so
The trick is to ensure that we don't screw up error reporting when CORE.setting is being built 13:58
We could in method TOP or so do `my $*ERR := stderr();`
And then in the code after we load the setting, for the case where we do, we can do $*ERR := $*W.find_symbol(['PROCESS', '$ERR']) 13:59
Or some such
Which is what $*ERR falls back to
[Coke] note that in my use case, I'm getting these out of an EVAL much later than the initial compile. 14:04
so it sounds like your approach would work there. 14:05
Zoffix Looks like most of Kernel.pm isn't thread-safe. I presume class { has $!foo; method foo { $!foo //= 42 } } isn't safe, 'cause `//=` isn't atomic? 14:12
m: dd $?BITS 14:17
camelia 64
Zoffix So $*KERNEL.bits can be replaced by $?BITS, eh? Instead of — look away if you're easily disturbed or have a pre-existing heart condition — shelling out and stuff github.com/rakudo/rakudo/blob/3488...el.pm#L101 14:20
.oO( wonder what would happen if you install rakudo on a 32-bit box, but then replace the CPU to be 32-bit... )
 14:22
s:2nd/32/64/;
ZOFFLOP: t/spec/S11-modules/nested.t 14:28
timotimo no need to do any replacing. you can install a 32bit rakudo on a 64bit machine
Zoffix No, I meant $?BITS is a constant that'd get precompiled to 32-bit and then lie if you swap to 64-core 14:30
Or would it all get recompiled?
Geth rakudo/nom: 3f5cc5ad24 | (Zoffix Znet)++ | src/core/Rakudo/Iterator.pm
Use $?BITS instead of $*KERNEL.bits

Since we now[^1] have it.
  github.com/rakudo/rakudo/commit/50...5e8b4cfa4b		 14:32
rakudo/nom: 34f62de854 | (Zoffix Znet)++ | src/core/Kernel.pm
Make first call to $*KERNEL.bits 21x faster

By using the now-available [^1] $?BITS instead of shelling out and stuff
  [1] github.com/rakudo/rakudo/commit/50...5e8b4cfa4b		 14:34
timotimo no, it wouldn't get recompiled 14:35
um ... waitwhat
bits won't ever be 32 on moarvm
Zoffix It's calculated using `my constant $?BITS = nqp::isgt_i(nqp::add_i(2147483648, 1), 0) ?? 64 !! 32; 14:37
`
timotimo yes
and native ints on moarvm are always 64bit big
Zoffix Ah right. I thought this was fixed already
timotimo "this"? 14:38
Zoffix $?BITS not being 32 on 32-bit boxes
timotimo ah
Zoffix .ask dogbert11 do remember the story about $?BITS not being 32 on 32 bit boxes? I recall pmurias was fixing something in that area. 14:39
yoleaux Zoffix: I'll pass your message to dogbert11.
Zoffix Hm, well, there's a commit saying a fix for $?BITS but it don't appear to fixed stuf: github.com/rakudo/rakudo/commit/d0...f0c15e6839 14:40
timotimo well, the comment is correct for what the variable represents 14:41
"the number of bits a native int has"
Zoffix Ahh 14:42
I thought it was OS bits
timotimo also: integers are usually also 32bit on 64bit systems 14:43
that's why so many programs exploded when attempted to run as 64bit; pointers became 64bit, but int remained 32bit
thus trying to go from pointer to int and back tore your addresses to pieces
Geth rakudo/nom: b879060100 | (Zoffix Znet)++ | src/core/Kernel.pm
Revert "Make first call to $*KERNEL.bits 21x faster"

This reverts commit 34f62de854de0baed2eb1e22262a7f7038fb29d0.
  $?BITS is how many bits a native int is, not the bits of the architecture		 14:44
Zoffix .tell dogbert11 never mind, turns out $?BITS isbits in an int, not OS bits 14:45
yoleaux Zoffix: I'll pass your message to dogbert11.
timotimo i'd still call that pretty misleading
all of it 14:46
is it bits of the architecture? what if we're running in 32bit mode on a 64bit system?
is it size of "native int", as in "my int $foo", or native int as in "C compiler's and ABI's idea of what an int is"?
one of those would pretty much always give 32, another one of those would pretty much always give 32, another one would give you 64bits on a 64bit system and 32bit on a 32bit system, another one would give 32 on 32bit and 64bit systems, and 32 on 32bit systems 14:47
ugexe timotimo: would you happen to know if a nqp json parser would likely be significantly faster than, say, JSON::Fast? 15:00
yoleaux 13:45Z <Zoffix> ugexe: I recall there was some thing (made by tony-o IIRC) that figures out what commit a particular version is at. Any idea where it is? Seems it needs a bit of mending to point to HEAD for latest version instead of the commit the version got bumped at. Otherwise, any bug fixes, say coming in from PRs, won't get propagated to users if the author never bumps the version in meta file,. which is an easy
Zoffix Basically, IO::String has been fixed for ages, but zef still installs the pre-bug-fix commit. github.com/hoelzro/p6-io-string/is...-305794168 15:02
Uhh... or is it 15:05
Nope
ugexe: never mind, I've just installed it and it's all good.
[Coke]: then, I'd guess it got installed from your zef cache or something 15:06
ugexe git log -G '"version"\s*:\s*"' -- META6.json
i thikn that will do it
oh wait, you would also have to find the last commit of each version 15:07
Zoffix I've just installed IO::String and ran this test file and it all passed, so yeah, it fetches the right stuff
ugexe i see
Zoffix ugexe: nah, never mind. I think it works fine as it is.
I just assumed it was installing some old commit because [Coke] still had buggy version despite just installing the module, but I can't repro taht issue and I think the reason [Coke] had it is because of older version of the module in cache 15:08
ugexe ah good call 15:09
Geth rakudo/nom: 79b8ab9d3f | (Zoffix Znet)++ | src/core/Kernel.pm
Make $*KERNEL.signal 64% faster, overall

First call faster by: 628.50x (Signal arg),
   70% (Str arg), 3.78x (overall), (no change for Int arg)
Cached calls: 10.46x (Signal arg),
   14% (Str arg), 64% (overall), (no change for Int arg)		 16:14
rakudo/nom: 4 commits pushed by MasterDuke17++, (Zoffix Znet)++ 16:47
Zoffix looks like Proc::Async.kill's default value isn't tested. 17:00
There's one indirect test that would've caught the mistake I made (forgetting .kill() candidate), but it don't check what the default value is
Or even tries to kill; just checks .kill on unstarted process complains about unstarted process 17:01
doesn't-hang wants regexes for output instead of smartmatching.... what n00b wrote this routine 17:03
Some Zoffix guy
uhh 17:09
m: $*KERNEL.signal('SIGSEGV')
camelia Type check failed for return value; expected return type Int cannot be itself (perhaps returning a :D type object?)
in block <unit> at <tmp> line 1
Zoffix did I break that :|
mc: $*KERNEL.signal('SIGSEGV')
committable6 Zoffix, ¦2015.12: «»
Zoffix c: HEAD~100 say $*KERNEL.signal('SIGSEGV') 17:10
committable6 Zoffix, ¦HEAD~100: «11»
Zoffix oops :}
Guess there ain't no tests for this either :) 17:12
huh, I see some. Wonder why they didn't run 17:14
Ah. They did, but previous tests removed the condition that caused the bug
Geth rakudo/nom: 01d948d2d2 | (Zoffix Znet)++ | src/core/Kernel.pm
Fix regression in Kernel.signal: Str:D

Previous commit[^1] made the mistake of accessing @!signals before they're initialized in `method signals`
  [1] github.com/rakudo/rakudo/commit/79b8ab9d3f		 17:30
roast: cbfd23d197 | (Zoffix Znet)++ | S02-magicals/KERNEL.t
Test $*KERNEL.signal: Str:D works

  ...with un-initialized $*KERNEL.signals
Rakudo regression: github.com/rakudo/rakudo/commit/79b8ab9d3f Rakudo fix: github.com/rakudo/rakudo/commit/01d948d2d2		 17:31
roast: d6be186791 | (Zoffix Znet)++ | packages/Test/Util.pm
Make doesn't-hang smartmatch stdout/stderr

Instead of just taking a regex		 17:32
roast: 2c724fa3fd | (Zoffix Znet)++ | S02-magicals/KERNEL.t
Add commit reference to test
 17:34
Zoffix Stage parse : Error while compiling, type X::Undeclared::Symbols 17:36
routine_suggestion: 17:37
post_types: 'StrDistance': (33372,33381)
damn
That don't look like my changes
oh wait, yeah, it's my changes. 17:40
That's what I get for coping files out of the checkout and then git pulling and then copying them back :P 17:41
Guess I need to lookup wtf git stash is about
Looks simple nough 17:42
ZOFVM: Files=1253, Tests=138321, 128 wallclock secs (24.81 usr 3.35 sys + 2679.06 cusr 140.39 csys = 2847.61 CPU) 17:52
I hope that's just my VM being sluggish + more tests :/
buggable: speed 6 17:53
buggable Zoffix, ▁▁▄▄█▃ data for 2017-05-31–2017-06-02; range: 4.364s–4.807s; 3% slower
Zoffix buggable: speed 60
buggable Zoffix, ▃▂▂▂▂▂▂▂▂↑▂▁▁▃▁▁▂▁▁▂▁▁▃▃▃▃▂▃▂▂▁▂▅▆▂▂▂▁▃▂▂▄▂▅▆▄▅▄▃▃▄▃▄▆▃▃▅▅█▄ data for 2017-05-07–2017-06-02; range: 4.194s–6.181s; 4% slower
Geth rakudo/nom: 99421d4caa | (Zoffix Znet)++ | 2 files
Fix Proc::Async.kill failing to kill sometimes

Fixes RT#131479: rt.perl.org/Ticket/Display.html?id=131479 Fixes roast/#158: github.com/perl6/roast/issues/158
The observed problems are due to multiple .kills in separate threads ending up calling $*KERNEL.signal, which isn't thread safe, ending ... (9 more lines)		 17:57
roast: e484c9f27e | (Zoffix Znet)++ | S17-procasync/kill.t
Test Proc::Async.kill kills all the things

RT#131479: rt.perl.org/Ticket/Display.html?id=131479 Rakudo fix: github.com/rakudo/rakudo/commit/99421d4caa		 17:58
Zoffix Sweet. It's now full-steam ahead for the ecosystem toaster \o/
travis-ci Rakudo build failed. Zoffix Znet 'Make $*KERNEL.signal 64% faster, overall 18:10
travis-ci.org/rakudo/rakudo/builds/238816737 github.com/rakudo/rakudo/compare/b...b8ab9d3f9a
buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
Zoffix You're trolling me, robot! It's just a failed nqp clone 18:15
m: my $x; $x ~= Blob.new: 1, 2, 3; dd $x 19:17
camelia Cannot use a Buf as a string, but you called the Stringy method on it
in block <unit> at <tmp> line 1
Zoffix This sucks
m: my $x; $x ~= 'x'; dd $x
camelia Str $x = "x"
Zoffix Looks like this bottoms out at Blob.Stringy coercing self into Str like an idiot 19:24
Zoffix leaves it as is for now
I notice Proc.exitcode is busted (always returns zero; there's a ticket for it) when both :out and :err are subscribed to, however, the Proc returned from Proc::Async's .start Promise doesn't have this problem, even if you tap to both stdout and stderr 19:50
Perhaps the issue is something easy
Zoffix relocates
jnthn Zoffix: I'm planning to rewrite Proc and friends in terms of Proc::Async anyway 19:51
Zoffix: So that should make the bug go away :)
Zoffix A baby beaver (I think) just came up to me at the bus stop and was following me around :D mobile.twitter.com/zoffix/status/8...6524787713 20:19
kinda sad, since it's likely die soon, but it's sooooo cuute :)
moritz cute indeed 20:21
[Coke] Zoffix: (zef cache) it was a fresh rakudo (with one line of code changed), a fresh zef installed into that, and then a fresh install of IO::String from that. 20:42
if there's a zef cache that is cross-zef install, that's bad. I'm willing to believe it was somehow related to my rakudo change, however. 20:43
Zoffix [Coke]: yeah, you need to nuke ~/.zef to nuke the cache as well 20:48
[Coke] urk. ok. 20:49
Zoffix cache is a more likely explanation, since the binary thing is IO::Handle.say complaining and latest IO::String provides own .say, avoiding the bug
binary thing = error about .say in binary mode
Geth rakudo/nom: aebd0fab2e | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Kernel.pm
Add note for future humans

If they make Kernel.signal thread safe to toss lock in P::A.kill		 21:01
[Coke] Prock ? 21:02
Zoffix damn... I guess using my phone to make a commit wasn't as awesome of an idea :p 21:03
Zoffix will fix when home
jnthn: is this thread-unsafe? class { has $!x; method x { $!x //= 42 } }.new.x ? 21:10
timotimo that snippet alone doesn't tell enough about your question 21:11
you can do this in two separate threads just fine, because nothing in there is shared
do you mean running .new once and then .x two or more times in parallel?
Zoffix yes
I guess a more prexise question is: what's a good way to thread-safely lazily initialize attributes 21:13
japhb Zoffix: Make the class into a monitor instead? 21:14
Zoffix No idea what that is. Is ot like OO::Monitor module or sonething? 21:15
buggable: eco monitor
buggable Zoffix, Found 2 results: OO::Monitors, Monitor::Monit. See modules.perl6.org/#q=monitor
Zoffix buggable: eco monitors
buggable Zoffix, OO::Monitors 'Objects with mutual exclusion and condition variables': github.com/jnthn/oo-monitors
timotimo japhb: OO::Monitor is not in core, so a bad fit for the core setting ;) 21:17
Zoffix japhb: that just locks each method call, would be preferable not to lock since only initialization is unsafe
jnthn Zoffix: Well, it doesn't promise the RHS won't be evaluated more than once
Zoffix jnthn: OK. That's kinda LTA for Kernel then, due to it shelling out on instantiation 21:18
jnthn Yeah
For CORE.setting code I'd use a Lock to guard it
Is it for the set of signals available, though?@
jnthn wonders if we can grab 'em at compile time 21:19
Zoffix hole bunch of stuff... most of kernel, in fact
good idea. gonna look into that 21:20
jnthn Yeah...I wonder how much of it can actually change dynamically
Zoffix debuses and goes home
jnthn Like, can you have a situation where Rakudo is packaged, and then installed on some system using a package manager and then there are a different set of signals there...
(That where it was compiled) 21:21
For things that call uname of course it can vary
Geth rakudo/nom: ef9872de9e | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Kernel.pm
Fix typo in comment
 21:33
Zoffix looks over Kernel code once more. 21:34
timotimo .o( a kernel written in perl6 ) 21:35
Zoffix Yeah, I think I'll leave it, as is and play the "unskilled to fix" card. I know nothing about uname, signals, any other kernel stuff, or async.
Geth tap-harness6: 5654dcd94a | (Zoffix Znet)++ (committed using GitHub Web editor) | META6.json
Bump version

Pre-emptively, "just in case," since core-rakudo version got removed.		 21:51
ugexe m: say Version.new(v6.c) cmp Version.new(v0.0.2); # if it is a problem it might still be one 21:54
camelia More
AlexDaniel ugexe: ? 22:00
ugexe core modules are all version 6.c
when you upgrade rakudo, do those get uninstalled? if not then that TAP will be a higher version than the ecosystem until v6 or some such 22:01
Zoffix Bump it to v6.0.2? :) 22:03
m: say Version.new(v6.c) cmp Version.new(v6.0.2);
camelia Less
Zoffix m: say Version.new(v6.c) cmp Version.new(v6.0.1);
camelia Less
Zoffix ugexe: what's your advice? Should we bump it to 6.0.1? 22:04
ugexe if someone complains. otherwise i wouldnt do anything
Zoffix ok
Zoffix is slightly worried the "someone complains" might be someone who's using releases or something... 22:05
ugexe possible problem for someone to chew on re: how to version core modules though
Zoffix I've no idea how people "upgrade" their rakudos, since I nuke stuff
ugexe like if Test is ever removed from core it will be the same thing
Zoffix IIRC this "throw tap out" thing started because some users were using buggy ecosystem TAP::Harness. I guess that means `zef install TAP::Harness` was still installing the ecosystem version even tho there was one with higher version in core. 22:08
ugexe that is a side effect of its renaming to just TAP, and there not being a includes with a lib/Tap/Harness.pm 22:09
Zoffix Alright. This is my last long-weekend-thanks-to-vacation-days of the year. Gonna de-socialize for three days and enjoy some peace and quiet :) See ya Tuesday
ugexe zef install TAP would have actually had to choose
i think anyway 22:10
this assume TAP::Harness has a TAP.pm 22:11
[Coke] Zoffix: have fun! 22:41
MasterDuke m: class :: { method foo {} }.new.fob 23:03
camelia No such method 'fob' for invocant of type '<anon|76060416>'. Did you mean 'foo'?
in block <unit> at <tmp> line 1
MasterDuke m: class C { method foo { self!bar }; submethod bar { say "hey, Im right here, too!" } }; C.new.foo 23:04
camelia 5===SORRY!5=== Error while compiling <tmp>
No such private method 'bar' for invocant of type 'C'
at <tmp>:1
------> 3class C { method foo { self!7⏏5bar }; submethod bar { say "hey, Im righ
MasterDuke my recent PR implemented the first case, but ^methods isn't returning anything in the second 23:06
timotimo of course, private methods are entirely distinct
MasterDuke right, but `for $!invocant.^private_method_table.keys -> $method_name {` isn't either 23:07
those don't seem to be populated at compile time
timotimo oh? 23:08
huh.
MasterDuke seethe SORRY! in the second
timotimo oh
i meant the other way around
when you're doing a private method call, it wouldn't ever hit a submethod
MasterDuke m: class C { method foo { self!bar }; method bar { say "hey, Im right here, too!" } }; C.new.foo 23:09
camelia 5===SORRY!5=== Error while compiling <tmp>
No such private method 'bar' for invocant of type 'C'
at <tmp>:1
------> 3class C { method foo { self!7⏏5bar }; method bar { say "hey, Im right h
MasterDuke it's the same submethod or method

Powered by Cro and the Raku® Programming Language.

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

Thank you!