Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-dev, 2017-06-02

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:09 Zoffix uhhh.... do I have to know whe the proc finished reading $*IN before I do Proc::Async.close-stdin? :/
00:10 Zoffix :| getting reaaaly weird results from my Proc herder
00:13 Zoffix m: https://gist.github.com/zoffixznet/df66845e3777f69205e215e4ff051514
00:13 camelia rakudo-moar b667e8: OUTPUT: «No such method 'out' for invocant of type 'X::AdHoc'␤  in block <unit> at <tmp> line 76␤␤»
00:14 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:15 Zoffix and the empty-string thing happens more oftener if I add `await Promise.in: 2; ` before $proc.close-stdin :S wat
00:18 MasterDuke don't think this is the problem, but it this a copy-pasto? https://gist.github.com/zoffixznet/df66845e3777f69205e215e4ff051514#file-p6-p6-L25-L26
00:18 MasterDuke *is this
00:19 Zoffix Yeah. Thanks.
00:22 Zoffix Ah, I'm a n00b. .write/.print return Promises you're supposed to await :}
00:23 Zoffix Yeah, changing the STDIN print line to `await $in ~~ Blob ?? $proc.write: $in !! $proc.print: $in;` fixed all the issues
00:54 astj joined #perl6-dev
01:02 astj joined #perl6-dev
01:08 Zoffix Proc::Async.kill don't work all the time :/
01:09 Zoffix hm, tho can't reproduce in smaller example :/
01:09 astj joined #perl6-dev
01:09 * Zoffix hopes it's a bug in my code
01:25 astj_ joined #perl6-dev
01:37 BenGoldberg joined #perl6-dev
01:49 ilbot3 joined #perl6-dev
01:49 Topic for #perl6-dev is now Perl 6 language and compiler development 2.0 | Logs at http://irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
01:50 MasterDuke general fyi. i updated https://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
03:49 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. https://irclog.perlgeek.de/perl6-dev/2017-06-01#i_14669729
03:50 BenGoldberg Here's my code so far: https://gist.github.com/BenGoldberg1/19e6e8b70cc5c838a15d72ea1dd182c9
03:52 BenGoldberg But, when I attempt to run it, I get this: http://fpaste.scsys.co.uk/563988
03:52 BenGoldberg Which is a seriously weird error message.
03:53 BenGoldberg How does NQPMu leak out?
03:57 BenGoldberg Oops, that was the wrong paste (and wrong error message for me to complain about)...
03:57 BenGoldberg http://fpaste.scsys.co.uk/563989
03:58 BenGoldberg ===SORRY!===␤QAST::Block with cuid 1 has not appeared
04:16 geekosaur joined #perl6-dev
05:07 astj joined #perl6-dev
05:21 samcv yay got rakudo in Sabayon (gentoo derivative binary distro)
05:21 samcv success! take over the world perl 6
05:21 samcv got it in the official repos i mean
05:59 [Tux] This is Rakudo version 2017.05-332-gb667e818c built on MoarVM version 2017.05-25-g62bc54e9
05:59 [Tux] csv-ip5xs        3.026
05:59 [Tux] test            13.331
05:59 [Tux] test-t           4.493 - 4.807
05:59 [Tux] csv-parser      12.943
06:06 astj joined #perl6-dev
06:09 stmuk_ joined #perl6-dev
07:41 [TuxCM] joined #perl6-dev
07:47 dct joined #perl6-dev
07:48 astj joined #perl6-dev
07:49 astj_ joined #perl6-dev
07:50 astj joined #perl6-dev
07:52 geekosaur joined #perl6-dev
07:53 astj_ joined #perl6-dev
08:04 Geth ¦ rakudo/nom: 348891488c | (Stefan Seifert)++ | src/core/Env.pm
08:04 Geth ¦ rakudo/nom: Revert "Implement %?ENV for the core setting"
08:04 Geth ¦ rakudo/nom:
08:04 Geth ¦ rakudo/nom: This reverts commit d3e8c82dc2f14b2bf1e41a39982644d33c8c47b2.
08:04 Geth ¦ rakudo/nom:
08:04 Geth ¦ rakudo/nom: Baking ENV into CORE.setting.moarvm at compile time prevents packaging rakudo
08:04 Geth ¦ rakudo/nom: for openSUSE as the rpm linter rightfully complains about the BUILDROOT path
08:04 Geth ¦ rakudo/nom: being included in the compiled file. This would also include much more
08:04 Geth ¦ rakudo/nom: information about the build server than the user should be able to get.
08:04 Geth ¦ rakudo/nom:
08:04 Geth ¦ rakudo/nom: As we don't know any use case for this unspecced and untested feature anyway,
08:04 Geth ¦ rakudo/nom: it's better to remove it.
08:04 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/348891488c
08:04 nine lizmat: ^^^
08:15 AlexDaniel joined #perl6-dev
08:40 Ven joined #perl6-dev
09:05 sivoais joined #perl6-dev
09:10 Ven joined #perl6-dev
09:24 Ven_ joined #perl6-dev
09:44 robertle joined #perl6-dev
09:49 lizmat nine: noted
09:50 lizmat fwiw, it was more a case of: now we can, let's do it :-)
10:02 lizmat afk again
10:22 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.
10:22 Zoffix samcv++ great!
10:22 Zoffix buggable: speed 6
10:22 buggable Zoffix, ▁▁▄▄█▃ data for 2017-05-31–2017-06-02; range: 4.364s–4.807s; 3% slower
10:22 Zoffix buggable: speed 20
10:22 buggable Zoffix, ▂▃▁▆▇▃▅▄▂▂▃▂▃▆▂▂▅▅↑▄ data for 2017-05-25–2017-06-02; range: 4.286s–4.807s; 4% slower
10:22 samcv what did i do?
10:23 Zoffix samcv │ yay got rakudo in Sabayon (gentoo derivative binary distro)
10:23 Zoffix samcv │ success! take over the world perl 6
10:23 samcv oh yay
10:23 samcv :)
10:23 Zoffix :)
10:23 samcv work domination
10:23 samcv *world
10:23 samcv typo but it works that way too i guess ;)
10:33 masak it worlds that way too :)
11:46 dogbert11 ZofBot: is Zoffix asleep?
11:46 ZofBot dogbert11, close }); }; my $v does IO = class { method close { say "closed" } }; rakudo-moar 6ef2ab: OUTPUT: «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 ) { $v
11:46 * dogbert11 hmm
12:05 Zoffix No. Why?
12:07 dogbert11 had a question
12:08 dogbert11 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 rakudo-moar 348891: OUTPUT: «grab 1␤grab 2␤»
12:10 Zoffix Yes, that's correct.
12:10 dogbert11 cool, then I'll have to change some docs
12:10 Zoffix The answer meant `flat` and `$( )` in that code are irrelevant.
12:11 Zoffix m: sub grab(+@a) { dd @a }; grab(flat $(1, 2))
12:11 camelia rakudo-moar 348891: OUTPUT: «(1, 2)␤»
12:11 Zoffix m: sub grab(+@a) { dd @a }; grab(flat (1, 2))
12:11 camelia rakudo-moar 348891: OUTPUT: «(1, 2)␤»
12:11 Zoffix m: sub grab(+@a) { dd @a }; grab(1, 2)
12:11 camelia rakudo-moar 348891: OUTPUT: «[1, 2]␤»
12:11 Zoffix ^ they all end up the same thing (basically)
12:12 dogbert11 interesting, the example I used came from here: https://docs.perl6.org/language/functions#Slurpy_Conventions
12:12 * Zoffix shakes head at "...which is shorthand for something very close to:"
12:13 Zoffix Explaining a thing by comparing it to a much more complex thing is a poor explanation :/
12:14 Zoffix It's a bit iffy the type @a ends up as is wobbly
12:14 Zoffix m: sub grab(+@a) { dd flat @a; }; grab (1, (2, 3)).Seq
12:14 camelia rakudo-moar 348891: OUTPUT: «(1, 2, 3).Seq␤»
12:14 Zoffix m: sub grab(+@a) { dd flat @a; }; grab (1, (2, 3))
12:14 camelia rakudo-moar 348891: OUTPUT: «(1, $(2, 3)).Seq␤»
12:15 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
12:16 Zoffix mc: m: sub grab(+@a) { dd flat @a; }; grab (1, (2, 3)).Seq
12:16 committable6 Zoffix, ¦2015.12: «(1, 2, 3).Seq»
12:16 dogbert11 oO(where will this end)
12:16 Zoffix Oh wait, I see the consistency.
12:17 Zoffix Oh wait, no I don't
12:19 Zoffix m: sub grab(+@a) { @a[3] = 42; dd @a }; grab (1, (2, 3))
12:19 camelia rakudo-moar 348891: OUTPUT: «[1, (2, 3), Any, 42]␤»
12:19 Zoffix m: sub grab(+@a) { @a[3] = 42; dd @a }; grab 1..*
12:19 camelia rakudo-moar 348891: OUTPUT: «(1, 2, 3, 42, 5, 6, 7, 8, 9, 10... lazy list)␤»
12:19 Zoffix m: sub grab(+@a) { @a[3] = 42; dd @a }; grab (1, 2, 3).Seq
12:19 camelia rakudo-moar 348891: OUTPUT: «Cannot modify an immutable Str (Nil)␤  in sub grab at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤»
12:19 Zoffix Has the potential for this ^ bug that'll only manifest itself for some particular input. LTA
12:19 dogbert11 this line will be changed later 'grab(flat $(1, 2));          # OUTPUT: «grab 1 2␤» '
12:20 [TuxCM] joined #perl6-dev
12:22 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 rakudo-moar 348891: OUTPUT: «[:a(42), :b(72)]␤[1, (2, 3)]␤[1, (2, 3)]␤(1, (2, 3))␤»
12:23 Zoffix So looks like only Seq is affected
12:26 Zoffix Filed as https://rt.perl.org/Ticket/Display.html?id=131483
12:33 Zoffix 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:34 * Zoffix puts on combat gear
12:34 Zoffix Time to find this bug!
12:34 Zoffix ZofBot: cancel all of my appointments!
12:34 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
12:39 timotimo ZofBot: i'm looking into it a little bit right now
12:39 ZofBot timotimo, perl,
12:41 timotimo oops, i meant Zoffix
12:43 Zoffix Cool :)
12:44 timotimo it seems like the tasks are being set up with a set of ops that doesn't include a "cancel" op
12:45 timotimo wait
12:45 timotimo i might be looking at the wrong part of the whole
12:48 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?
12:48 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 } }}
12:48 Zoffix ^ 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
12:48 timotimo "sleep" -> $p?
12:49 timotimo oh
12:49 timotimo that's a with there, k
12:49 Zoffix "sleep" is what the launched proc runs, -> 4p is the proc
12:49 timotimo yup i see it not terminate
12:51 timotimo bleh, SIGTTOU
12:51 timotimo i don't know how this works
12:51 Zoffix :)
12:52 timotimo ah!
12:52 timotimo $*EXECUTABLE
12:52 timotimo perl6-gdb-m
12:52 Zoffix ah :DF
12:58 timotimo Zoffix: you're killing before the process has started
12:58 timotimo that seems dangerous, but it shouldn't cause a hang
12:59 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
13:00 timotimo er, huh.
13:00 timotimo the await $p.start waits for far too long
13:01 Zoffix It awaits until the process is don't doesn't it?
13:01 timotimo ah
13:01 timotimo i've not used proc::async enough
13:02 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: https://gist.github.com/zoffixznet/7d3b2d9fae28c2d18fc4bdef6e68cc59
13:02 Zoffix (well, MasterDuke pointed this out last night, I'm just replicating)
13:03 timotimo interesting
13:03 Zoffix "It awaits until the process is don't doesn't it?".... is "done" :|
13:03 timotimo yeah
13:04 timotimo could it be it's accidentally cancelling the task that contains the second kill?
13:05 timotimo because it's not returning from the kill op
13:08 timotimo when i lower the number of max threads, the whole thing works
13:12 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 Zoffix This gives me "murder! Type check failed for return value; expected return type Int cannot be itself (perhaps returning a :D type object?)"
13:13 * Zoffix eyes that `once`: https://github.com/rakudo/rakudo/blob/3488914/src/core/Kernel.pm#L145-L151
13:14 Zoffix 'cause $*KERNEL wouldn't be inited until it's inside my Promise already
13:14 * Zoffix tries simlififying that bit
13:16 timotimo ooh, a race in $*KERNEL being set up?
13:17 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 Zoffix 'cause stuff in method signal is already setup
13:17 [Coke] in straight p6 code, I can replace stderr() with $*ERR; what about the QAST code: QAST::Op.new(:op<getstderr>) ?
13:17 Zoffix Well, thanks for help :D I'll clean it up to avoid the race and fix it.
13:20 timotimo [Coke]: what's the question?
13:20 Zoffix [Coke]: no idea; QAST::Var.new( :name('$*ERR'), :scope('dynamic') ) ?
13:20 [Coke] there are places in perl 6 that use the raw stderr, when everything should be using $*ERR
13:20 timotimo ah
13:21 timotimo yeah, what zoffix said should do it
13:21 [Coke] .. and Zoffix is probably very close there. Danke.
13:21 timotimo or maybe
13:21 timotimo DYNAMIC('$*ERR')?
13:21 timotimo that's what i get from a --target=ast
13:27 [Coke] https://github.com/hoelzro/p6-io-string/issues/10
13:27 [Coke] timotimo: oh, right, I can make p6 tell me how to do it. :)
13:35 [Coke] jnthn: does that io-string issue look like a familiar error message?
13:38 jnthn [Coke]: Well, I added it, so yes :)
13:39 jnthn [Coke]: However, it overrides method say
13:40 jnthn So I'm not really sure what'd be going on
13:40 [Coke] .seen hoelzro
13:40 yoleaux I saw hoelzro 5 May 2017 21:26Z in #perl6: <hoelzro> ok
13:41 Zoffix [Coke]: that sounds like you're using too old a version of it.
13:41 [Coke] error came off a zef install
13:42 [Coke] ===> Testing: IO::String:ver('0.1.0'):auth('Rob Hoelz')
13:42 [Coke] which is the version in the meta json
13:42 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 https://github.com/hoelzro/p6-io-string/commits/master
13:42 [Coke] (on master)
13:42 Zoffix Ah, damn, the version never got bumped
13:42 Zoffix [Coke]: I'll send a PR to fix it. In the meantime, you can do zef --force install https://github.com/hoelzro/p6-io-string/archive/master.zip
13:45 Zoffix .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.
13:45 Zoffix to forget to do
13:45 Zoffix yoleaux: dumb ass
13:45 [Coke] Zoffix++
13:45 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
13:45 yoleaux Zoffix: I'll pass your message to ugexe.
13:45 Zoffix thing to forget to do
13:48 * [Coke] wonders if $*ERR is defined early enough for me to use it in src/Perl6/Actions.nqp
13:48 [Coke] (get a lot of # Cannot find method 'print' on object of type NQPMu) after trying that change locally)
13:50 Zoffix Don't know. But for record it's defined in src/core/io_operators.pm: https://github.com/rakudo/rakudo/blob/nom/src/core/io_operators.pm#L188-L189
13:51 [Coke] Zoffix: on the plus side, jnthn has already greatly reduced the amount of uncaught stderr in xt/examples*
13:51 Zoffix cool
13:53 [Coke] Down to a few "Potential Difficulties", 'useless use', and "WARNINGS"
13:57 jnthn $*ERR in Actions.nqp won't work out
13:57 jnthn However, we could potentially make it do so
13:58 jnthn The trick is to ensure that we don't screw up error reporting when CORE.setting is being built
13:58 jnthn We could in method TOP or so do `my $*ERR := stderr();`
13:59 jnthn 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 jnthn Or some such
13:59 astj joined #perl6-dev
13:59 jnthn Which is what $*ERR falls back to
14:04 [Coke] note that in my use case, I'm getting these out of an EVAL much later than the initial compile.
14:05 [Coke] so it sounds like your approach would work there.
14:12 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:17 Zoffix m: dd $?BITS
14:17 camelia rakudo-moar 348891: OUTPUT: «64␤»
14:20 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 https://github.com/rakudo/rakudo/blob/348891488c67/src/core/Kernel.pm#L101
14:22 Zoffix .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 Zoffix s:2nd/32/64/;
14:24 dct joined #perl6-dev
14:28 Zoffix 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
14:30 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 Zoffix Or would it all get recompiled?
14:32 Geth ¦ rakudo/nom: 3f5cc5ad24 | (Zoffix Znet)++ | src/core/Rakudo/Iterator.pm
14:32 Geth ¦ rakudo/nom: Use $?BITS instead of $*KERNEL.bits
14:32 Geth ¦ rakudo/nom:
14:32 Geth ¦ rakudo/nom: Since we now[^1] have it.
14:32 Geth ¦ rakudo/nom:
14:32 Geth ¦ rakudo/nom: https://github.com/rakudo/rakudo/commit/505766f3a7fd95e8b4cfa4b
14:32 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3f5cc5ad24
14:34 Geth ¦ rakudo/nom: 34f62de854 | (Zoffix Znet)++ | src/core/Kernel.pm
14:34 Geth ¦ rakudo/nom: Make first call to $*KERNEL.bits 21x faster
14:34 Geth ¦ rakudo/nom:
14:34 Geth ¦ rakudo/nom: By using the now-available [^1] $?BITS instead of shelling out and stuff
14:34 Geth ¦ rakudo/nom:
14:34 Geth ¦ rakudo/nom: [1] https://github.com/rakudo/rakudo/commit/505766f3a7fd95e8b4cfa4b
14:34 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/34f62de854
14:35 timotimo no, it wouldn't get recompiled
14:35 timotimo um ... waitwhat
14:35 timotimo bits won't ever be 32 on moarvm
14:37 Zoffix It's calculated using `my constant $?BITS = nqp::isgt_i(nqp::add_i(2147483648, 1), 0) ?? 64 !! 32;
14:37 Zoffix `
14:37 timotimo yes
14:37 timotimo and native ints on moarvm are always 64bit big
14:37 Zoffix Ah right. I thought this was fixed already
14:38 timotimo "this"?
14:38 Zoffix $?BITS not being 32 on 32-bit boxes
14:38 timotimo ah
14:39 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.
14:40 Zoffix Hm, well, there's a commit saying a fix for $?BITS but it don't appear to fixed stuf: https://github.com/rakudo/rakudo/commit/d057efdbc435898de2c51a2b8a64c4f0c15e6839
14:41 timotimo well, the comment is correct for what the variable represents
14:41 timotimo "the number of bits a native int has"
14:42 Zoffix Ahh
14:42 Zoffix I thought it was OS bits
14:43 timotimo also: integers are usually also 32bit on 64bit systems
14:43 timotimo that's why so many programs exploded when attempted to run as 64bit; pointers became 64bit, but int remained 32bit
14:43 timotimo thus trying to go from pointer to int and back tore your addresses to pieces
14:44 Geth ¦ rakudo/nom: b879060100 | (Zoffix Znet)++ | src/core/Kernel.pm
14:44 Geth ¦ rakudo/nom: Revert "Make first call to $*KERNEL.bits 21x faster"
14:44 Geth ¦ rakudo/nom:
14:44 Geth ¦ rakudo/nom: This reverts commit 34f62de854de0baed2eb1e22262a7f7038fb29d0.
14:44 Geth ¦ rakudo/nom:
14:44 Geth ¦ rakudo/nom: $?BITS is how many bits a native int is, not the bits of the architecture
14:44 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b879060100
14:45 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.
14:45 timotimo i'd still call that pretty misleading
14:46 timotimo all of it
14:46 timotimo is it bits of the architecture? what if we're running in 32bit mode on a 64bit system?
14:46 timotimo 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"?
14:47 timotimo 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:59 AlexDaniel joined #perl6-dev
15:00 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
15:02 Zoffix Basically, IO::String has been fixed for ages, but zef still installs the pre-bug-fix commit. https://github.com/hoelzro/p6-io-string/issues/10#issuecomment-305794168
15:05 Zoffix Uhh... or is it
15:05 Zoffix Nope
15:05 Zoffix ugexe: never mind, I've just installed it and it's all good.
15:06 Zoffix [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
15:06 ugexe i thikn that will do it
15:07 ugexe 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
15:07 ugexe i see
15:07 Zoffix ugexe: nah, never mind. I think it works fine as it is.
15:08 Zoffix 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:09 ugexe ah good call
16:14 Geth ¦ rakudo/nom: 79b8ab9d3f | (Zoffix Znet)++ | src/core/Kernel.pm
16:14 Geth ¦ rakudo/nom: Make $*KERNEL.signal 64% faster, overall
16:14 Geth ¦ rakudo/nom:
16:14 Geth ¦ rakudo/nom: First call faster by: 628.50x (Signal arg),
16:14 Geth ¦ rakudo/nom:     70% (Str arg), 3.78x (overall), (no change for Int arg)
16:14 Geth ¦ rakudo/nom:
16:14 Geth ¦ rakudo/nom: Cached calls: 10.46x (Signal arg),
16:15 Geth ¦ rakudo/nom:     14% (Str arg), 64% (overall), (no change for Int arg)
16:15 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/79b8ab9d3f
16:15 astj joined #perl6-dev
16:37 robertle joined #perl6-dev
16:47 Geth ¦ rakudo/nom: 4 commits pushed by MasterDuke17++, (Zoffix Znet)++
16:47 Geth ¦ rakudo/nom: c81b7a4b1a | Suggest misspelled method names
16:47 Geth ¦ rakudo/nom: 7cf01296d9 | Tweak X::Method::NotFound some more
16:47 Geth ¦ rakudo/nom: f94202d841 | Make sure we nqp::can get the invocant's methods..
16:47 Geth ¦ rakudo/nom: 2500e50d55 | Merge pull request #1091 from MasterDuke17/suggest_misspelled_method_names_RT123078_RT127395
16:47 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/compare/79b8ab9d3f...2500e50d55
17:00 Zoffix looks like Proc::Async.kill's default value isn't tested.
17:00 Zoffix 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
17:01 Zoffix Or even tries to kill; just checks .kill on unstarted process complains about unstarted process
17:03 Zoffix doesn't-hang wants regexes for output instead of smartmatching.... what n00b wrote this routine
17:03 Zoffix Some Zoffix guy
17:09 Zoffix uhh
17:09 Zoffix m: $*KERNEL.signal('SIGSEGV')
17:09 camelia rakudo-moar 2500e5: OUTPUT: «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␤␤»
17:09 Zoffix did I break that :|
17:09 Zoffix mc: $*KERNEL.signal('SIGSEGV')
17:09 committable6 Zoffix, ¦2015.12: «»
17:10 Zoffix c: HEAD~100 say $*KERNEL.signal('SIGSEGV')
17:10 committable6 Zoffix, ¦HEAD~100: «11»
17:10 Zoffix oops :}
17:12 Zoffix Guess there ain't no tests for this either :)
17:14 Zoffix huh, I see some. Wonder why they didn't run
17:14 Zoffix Ah. They did, but previous tests removed the condition that caused the bug
17:30 Geth ¦ rakudo/nom: 01d948d2d2 | (Zoffix Znet)++ | src/core/Kernel.pm
17:30 Geth ¦ rakudo/nom: Fix regression in Kernel.signal: Str:D
17:30 Geth ¦ rakudo/nom:
17:30 Geth ¦ rakudo/nom: Previous commit[^1] made the mistake of accessing @!signals
17:30 Geth ¦ rakudo/nom: before they're initialized in `method signals`
17:30 Geth ¦ rakudo/nom:
17:30 Geth ¦ rakudo/nom: [1] https://github.com/rakudo/rakudo/commit/79b8ab9d3f
17:30 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/01d948d2d2
17:31 Geth ¦ roast: cbfd23d197 | (Zoffix Znet)++ | S02-magicals/KERNEL.t
17:31 Geth ¦ roast: Test $*KERNEL.signal: Str:D works
17:31 Geth ¦ roast:
17:31 Geth ¦ roast: ...with un-initialized $*KERNEL.signals
17:31 Geth ¦ roast:
17:31 Geth ¦ roast: Rakudo regression: https://github.com/rakudo/rakudo/commit/79b8ab9d3f
17:31 Geth ¦ roast: Rakudo fix: https://github.com/rakudo/rakudo/commit/01d948d2d2
17:31 Geth ¦ roast: review: https://github.com/perl6/roast/commit/cbfd23d197
17:32 Geth ¦ roast: d6be186791 | (Zoffix Znet)++ | packages/Test/Util.pm
17:32 Geth ¦ roast: Make doesn't-hang smartmatch stdout/stderr
17:32 Geth ¦ roast:
17:32 Geth ¦ roast: Instead of just taking a regex
17:32 Geth ¦ roast: review: https://github.com/perl6/roast/commit/d6be186791
17:34 Geth ¦ roast: 2c724fa3fd | (Zoffix Znet)++ | S02-magicals/KERNEL.t
17:34 Geth ¦ roast: Add commit reference to test
17:34 Geth ¦ roast: review: https://github.com/perl6/roast/commit/2c724fa3fd
17:36 Zoffix Stage parse      : Error while compiling, type X::Undeclared::Symbols
17:37 Zoffix routine_suggestion:
17:37 Zoffix post_types:         'StrDistance': (33372,33381)
17:37 Zoffix damn
17:37 Zoffix That don't look like my changes
17:40 Zoffix oh wait, yeah, it's my changes.
17:41 Zoffix That's what I get for coping files out of the checkout and then git pulling and then copying them back :P
17:41 Zoffix Guess I need to lookup wtf git stash is about
17:42 Zoffix Looks simple nough
17:52 Zoffix 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 Zoffix I hope that's just my VM being sluggish + more tests :/
17:53 Zoffix buggable: speed 6
17:53 buggable Zoffix, ▁▁▄▄█▃ data for 2017-05-31–2017-06-02; range: 4.364s–4.807s; 3% slower
17:53 Zoffix buggable: speed 60
17:53 buggable Zoffix, ▃▂▂▂▂▂▂▂▂↑▂▁▁▃▁▁▂▁▁▂▁▁▃▃▃▃▂▃▂▂▁▂▅▆▂▂▂▁▃▂▂▄▂▅▆▄▅▄▃▃▄▃▄▆▃▃▅▅█▄ data for 2017-05-07–2017-06-02; range: 4.194s–6.181s; 4% slower
17:55 dct joined #perl6-dev
17:57 Geth ¦ rakudo/nom: 99421d4caa | (Zoffix Znet)++ | 2 files
17:57 Geth ¦ rakudo/nom: Fix Proc::Async.kill failing to kill sometimes
17:57 Geth ¦ rakudo/nom:
17:57 Geth ¦ rakudo/nom: Fixes RT#131479: https://rt.perl.org/Ticket/Display.html?id=131479
17:57 Geth ¦ rakudo/nom: Fixes roast/#158: https://github.com/perl6/roast/issues/158
17:57 Geth ¦ rakudo/nom:
17:57 Geth ¦ rakudo/nom: The observed problems are due to multiple .kills in separate threads
17:57 Geth ¦ rakudo/nom: ending up calling $*KERNEL.signal, which isn't thread safe, ending
17:57 Geth ¦ rakudo/nom: <…commit message has 9 more lines…>
17:57 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/99421d4caa
17:58 Geth ¦ roast: e484c9f27e | (Zoffix Znet)++ | S17-procasync/kill.t
17:58 Geth ¦ roast: Test Proc::Async.kill kills all the things
17:58 Geth ¦ roast:
17:58 Geth ¦ roast: RT#131479: https://rt.perl.org/Ticket/Display.html?id=131479
17:58 Geth ¦ roast: Rakudo fix: https://github.com/rakudo/rakudo/commit/99421d4caa
17:58 Geth ¦ roast: review: https://github.com/perl6/roast/commit/e484c9f27e
17:58 Zoffix Sweet. It's now full-steam ahead for the ecosystem toaster \o/
18:10 travis-ci joined #perl6-dev
18:10 travis-ci Rakudo build failed. Zoffix Znet 'Make $*KERNEL.signal 64% faster, overall
18:10 travis-ci https://travis-ci.org/rakudo/rakudo/builds/238816737 https://github.com/rakudo/rakudo/compare/b87906010032...79b8ab9d3f9a
18:10 travis-ci left #perl6-dev
18:10 buggable [travis build above] ☠ Did not recognize some failures. Check results manually.
18:15 Zoffix You're trolling me, robot! It's just a failed nqp clone
19:17 Zoffix m: my $x; $x ~= Blob.new: 1, 2, 3; dd $x
19:17 camelia rakudo-moar 99421d: OUTPUT: «Cannot use a Buf as a string, but you called the Stringy method on it␤  in block <unit> at <tmp> line 1␤␤»
19:17 Zoffix This sucks
19:17 Zoffix m: my $x; $x ~= 'x'; dd $x
19:17 camelia rakudo-moar 99421d: OUTPUT: «Str $x = "x"␤»
19:24 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
19:50 Zoffix 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 Zoffix Perhaps the issue is something easy
19:50 * Zoffix relocates
19:51 jnthn Zoffix: I'm planning to rewrite Proc and friends in terms of Proc::Async anyway
19:51 jnthn Zoffix: So that should make the bug go away :)
20:19 Zoffix A baby beaver (I think) just came up to me at the bus stop and was following me around :D https://mobile.twitter.com/zoffix/status/870736176524787713
20:19 Zoffix kinda sad, since it's likely die soon, but it's sooooo cuute :)
20:21 moritz cute indeed
20:42 [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:43 [Coke] 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:48 Zoffix [Coke]: yeah, you need to nuke ~/.zef to nuke the cache as well
20:49 [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
20:49 Zoffix binary thing = error about .say in binary mode
21:01 Geth ¦ rakudo/nom: aebd0fab2e | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Kernel.pm
21:01 Geth ¦ rakudo/nom: Add note for future humans
21:01 Geth ¦ rakudo/nom:
21:01 Geth ¦ rakudo/nom: If they make Kernel.signal thread safe to toss lock in P::A.kill
21:01 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/aebd0fab2e
21:02 [Coke] Prock ?
21:03 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
21:05 AlexDaniel joined #perl6-dev
21:10 Zoffix jnthn: is this thread-unsafe? class { has $!x; method x { $!x //= 42 } }.new.x ?
21:11 timotimo that snippet alone doesn't tell enough about your question
21:11 timotimo you can do this in two separate threads just fine, because nothing in there is shared
21:11 timotimo do you mean running .new once and then .x two or more times in parallel?
21:11 Zoffix yes
21:13 Zoffix I guess a more prexise question is: what's a good way to thread-safely lazily initialize attributes
21:14 japhb Zoffix: Make the class into a monitor instead?
21:15 Zoffix No idea what that is. Is ot like OO::Monitor module or sonething?
21:15 Zoffix buggable: eco monitor
21:15 buggable Zoffix, Found 2 results: OO::Monitors, Monitor::Monit. See https://modules.perl6.org/#q=monitor
21:15 Zoffix buggable: eco monitors
21:15 buggable Zoffix, OO::Monitors 'Objects with mutual exclusion and condition variables': https://github.com/jnthn/oo-monitors
21:17 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
21:17 jnthn Zoffix: Well, it doesn't promise the RHS won't be evaluated more than once
21:18 Zoffix jnthn: OK. That's kinda LTA for Kernel then, due to it shelling out on instantiation
21:18 jnthn Yeah
21:18 jnthn For CORE.setting code I'd use a Lock to guard it
21:18 jnthn Is it for the set of signals available, though?@
21:19 * jnthn wonders if we can grab 'em at compile time
21:19 Zoffix hole bunch of stuff... most of kernel, in fact
21:20 Zoffix good idea. gonna look into that
21:20 jnthn Yeah...I wonder how much of it can actually change dynamically
21:20 * Zoffix debuses and goes home
21:20 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...
21:21 jnthn (That where it was compiled)
21:21 jnthn For things that call uname of course it can vary
21:33 Geth ¦ rakudo/nom: ef9872de9e | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Kernel.pm
21:33 Geth ¦ rakudo/nom: Fix typo in comment
21:33 Geth ¦ rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ef9872de9e
21:34 * Zoffix looks over Kernel code once more.
21:35 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.
21:36 lizmat joined #perl6-dev
21:51 Geth ¦ tap-harness6: 5654dcd94a | (Zoffix Znet)++ (committed using GitHub Web editor) | META6.json
21:51 Geth ¦ tap-harness6: Bump version
21:51 Geth ¦ tap-harness6:
21:51 Geth ¦ tap-harness6: Pre-emptively, "just in case," since core-rakudo version got removed.
21:51 Geth ¦ tap-harness6: review: https://github.com/perl6/tap-harness6/commit/5654dcd94a
21:54 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 rakudo-moar ef9872: OUTPUT: «More␤»
22:00 AlexDaniel ugexe: ?
22:00 ugexe core modules are all version 6.c
22:01 ugexe 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:03 Zoffix Bump it to v6.0.2? :)
22:03 Zoffix m: say Version.new(v6.c) cmp Version.new(v6.0.2);
22:03 camelia rakudo-moar ef9872: OUTPUT: «Less␤»
22:03 Zoffix m: say Version.new(v6.c) cmp Version.new(v6.0.1);
22:03 camelia rakudo-moar ef9872: OUTPUT: «Less␤»
22:04 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
22:04 Zoffix ok
22:05 * 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
22:05 Zoffix I've no idea how people "upgrade" their rakudos, since I nuke stuff
22:05 ugexe like if Test is ever removed from core it will be the same thing
22:05 MasterDuke joined #perl6-dev
22:08 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:09 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
22:09 ugexe zef install TAP would have actually had to choose
22:10 ugexe i think anyway
22:11 ugexe this assume TAP::Harness has a TAP.pm
22:15 astj joined #perl6-dev
22:31 geekosaur joined #perl6-dev
22:31 DrForr_ joined #perl6-dev
22:33 sivoais_ joined #perl6-dev
22:40 [_[Tux]_] joined #perl6-dev
22:41 [Coke] Zoffix: have fun!
23:03 MasterDuke m: class :: { method foo {} }.new.fob
23:03 camelia rakudo-moar ef9872: OUTPUT: «No such method 'fob' for invocant of type '<anon|76060416>'. Did you mean 'foo'?␤  in block <unit> at <tmp> line 1␤␤»
23:04 MasterDuke m: class C { method foo { self!bar }; submethod bar { say "hey, Im right here, too!" } }; C.new.foo
23:04 camelia rakudo-moar ef9872: OUTPUT: «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␤»
23:06 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
23:07 MasterDuke right, but `for $!invocant.^private_method_table.keys -> $method_name {` isn't either
23:07 MasterDuke those don't seem to be populated at compile time
23:08 timotimo oh?
23:08 timotimo huh.
23:08 MasterDuke seethe SORRY! in the second
23:08 timotimo oh
23:08 timotimo i meant the other way around
23:08 timotimo when you're doing a private method call, it wouldn't ever hit a submethod
23:09 MasterDuke m: class C { method foo { self!bar }; method bar { say "hey, Im right here, too!" } }; C.new.foo
23:09 camelia rakudo-moar ef9872: OUTPUT: «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␤»
23:09 MasterDuke it's the same submethod or method

| Channels | #perl6-dev index | Today | | Search | Google Search | Plain-Text | summary