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 | ||