Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:10 lucasb left 01:10 Kaiepi left 01:14 Kaiepi joined 01:19 Kaiepi left, Kaiepi joined
Geth rakudo: ZhongnianTao++ created pull request #3079:
Add gb2312 to the encoding lists		 01:31
02:21 pamplemousse_ left 02:32 Kaiepi left, Kaiepi joined
Geth roast: ZhongnianTao++ created pull request #563:
Add test for gb2312 encoding		 03:18
lizmat Files=1268, Tests=108554, 193 wallclock secs (26.74 usr 7.82 sys + 2684.23 cusr 255.44 csys = 2974.23 CPU) 04:46
m: dd :{ 42 => 666 } # behold, an object hash 05:52
camelia :{42 => 666}
lizmat m: dd :{ 42, 666 } # behold, a block ???
camelia -> ;; $_? is raw { #`(Block|58607360) ... }
lizmat bisectable6: dd :{ 42, 666 } 05:53
bisectable6 lizmat, Bisecting by output (old=2015.12 new=60cfbb3) because on both starting points the exit code is 0
lizmat, bisect log: gist.github.com/a5fcda2d7bdf0e43db...0f2d4d0f2d
lizmat, (2015-12-25) github.com/rakudo/rakudo/commit/07...dc61f84053
lizmat, The result looks a bit unrealistic, doesn't it? Most probably the output is different on every commit (e.g. ｢bisect: say rand｣)
lizmat yeah, so it's always been a block 05:54
ah, this is even mentioned in the doc: "Note: Rakudo implementation currently erroneously applies the same rules for :{ } as it does for { } and can construct a Block in certain circumstances." 05:55
05:59 |Tux| left
[Tux] Rakudo version 2019.07-86-g60cfbb39e - MoarVM version 2019.07-28-gd605648fe
csv-ip5xs0.702 - 0.705
csv-ip5xs-205.165 - 5.317
csv-parser21.284 - 22.726
csv-test-xs-200.431 - 0.442
test6.881 - 6.950
test-t1.710 - 1.723
test-t --race0.813 - 0.877
test-t-2028.720 - 29.285
test-t-20 --race9.132 - 9.311
 06:09
06:19 |Tux| joined 06:37 squashable6 left 06:40 squashable6 joined, ChanServ sets mode: +v squashable6 07:15 patrickb joined 07:24 mst left, mst joined, mst left, mst joined 07:37 b2gills left 07:38 b2gills joined
AlexDaniel I feel so weird about deepmap, nodemap, duckmap 08:32
I read the docs, totally makes sense. They Look like very useful features 08:33
but then
greppable6: deepmap 08:34
greppable6 AlexDaniel, 72 lines, 8 modules: gist.github.com/dc8dc3763646666fd7...09e8f22671
AlexDaniel greppable6: nodemap
greppable6 AlexDaniel, 12 lines, 1 module: gist.github.com/99151d0c9c84a97a2e...886fa580cb
AlexDaniel greppable6: duckmap
greppable6 AlexDaniel, 16 lines, 2 modules: gist.github.com/6f6ecd173efb2d5dd7...dc9f65ed2c
AlexDaniel one of the “modules” is the doc repo itself
so we have not a single module using nodemap, one module using duckmap
deepmap is probably fine
jnthn Yeah, I've got a load of use of deepmap in $dayjob codebase also 09:24
duckmap always feels a bit too swallowy to me 09:25
Though I can imagine using it in some cases
masak had completely missed those 09:43
probably more a statement of my attention (or lack thereof) of recent features, than of the features themselves :) 09:44
AlexDaniel “recent” features? :) 10:09
c: 2014.01 <a b c d e f g>.duckmap(-> $_ where <c d e>.any { .uc }).say; 10:10
committable6 AlexDaniel, ¦2014.01: «Cannot find method 'duckmap'␤ in block at /tmp/8d6S5VAYPr:1␤␤ «exit code = 1»»
AlexDaniel c: all <a b c d e f g>.duckmap(-> $_ where <c d e>.any { .uc }).say;
10:11 |Tux| left
jnthn Wll, if you've been following Perl 6 for the better part of 2 decades, then relatively... ;) 10:12
AlexDaniel slaps committable 10:13
10:13 reportable6 left, shareable6 left, greppable6 left, committable6 left 10:14 bisectable6 left, quotable6 left, evalable6 left, shareable6 joined, ChanServ sets mode: +v shareable6, committable6 joined, ChanServ sets mode: +v committable6, bisectable6 joined
AlexDaniel c: all <a b c d e f g>.duckmap(-> $_ where <c d e>.any { .uc }).say; 10:15
10:17 greppable6 joined, quotable6 joined, evalable6 joined 10:18 |Tux| joined, reportable6 joined
committable6 AlexDaniel, gist.github.com/ad4ef87725bf43e9f9...60b2eb825e 10:20
AlexDaniel O_o 10:21
this one is indeed very recent 10:22
c: all say [[1,2,3], [[4,5],6,7], 7].nodemap(*+1);
committable6 AlexDaniel, gist.github.com/6e4c32cc232ec9ac99...976f04e4ac 10:23
13:21 lucasb joined 13:28 pamplemousse joined 13:56 hankache joined, pamplemousse left
hankache Hello #perl6-dev 13:57
.tell kawaii regarding the Rakudo Star release we'll start as soon 2019.07.1 is released 14:01
yoleaux hankache: I'll pass your message to kawaii.
14:08 robertle joined 14:14 hankache left 15:17 robertle left 15:32 patrickb left 15:33 hankache joined 15:34 hankache left
ugexe loop { say ++$; run("xxx", :err).err.slurp(:close); run("xxx", :err).err.slurp(:close); } 16:03
why does that deadlock at 32
timotimo hm, if there's no :in, you don't have to .close-stdin? 16:04
but 32 sounds like that's the default thread pool size limit
16:05 robertle joined
timotimo try the thread pool scheduler debug env var maybe 16:05
ugexe it doesn't do anything beyond setting up the initial general worker thread 16:10
it wont deadlock if the command exists fwiw 16:12
a non-zero exitcode is fine. the command must not exist afaict 16:14
dogbert17 ugexe: perhaps a spesh problem 16:16
ugexe if I add `:out` / `$proc.out.close` then it immediately throws an exception 16:18
The spawned command 'xxx' exited unsuccessfully (exit code: 1)
it seems like the same should happen when accessing .err 16:19
16:27 AlexDaniel left 17:08 chloekek joined 17:15 pamplemousse joined
Voldenet the real question is "why does loop { say ++$; my $r = run("xxx"); }" deadlock after a while 18:10
…while this works flawlessly: loop { say ++$; await Proc::Async.new("xxx").start.then({$}); } 18:14
ugexe because has syncronization and one does not 18:19
since the former is built using the later 18:20
Voldenet Oh, that makes sense 18:34
ugexe so its something like a command that doesn't exist can finish faster than a normal command, and this occurs before all the setup can occur 18:37
and it gets stuck awaiting X promises (and doesn't add more threads to compensate?) 18:38
Voldenet > MoarVM panic: Internal error: Unwound entire stack and missed handler 18:50
that's a cooler error
ugexe that just randomly pops up too? 18:54
Voldenet my $is-spawned = await $!proc.ready.then({ if .status ~~ Broken { self!set-status(0x100); return False; }; $!pid = .result; return True; }); 18:55
I know, return there is wrong and this isn't js ¯\_(ツ)_/¯
ugexe how does self!set-status not throwing an error? is there more to this?
Voldenet I've just replaced the relevant line in Proc.pm6 18:57
ugexe ah thats code from Proc.pm6, i see
im guessing that error is because you removed the CATCH { } handler 18:59
(although that much is obvious)
i dont think .ready means the .status is ready though 19:00
Voldenet > my $is-spawned = await $!proc.ready.then({ if .status ~~ Broken { self!set-status(0x100); False } else { $!pid = .result; True } }); 19:07
this seems to work correctly, sets the proper is-spawned result in this case, but I'm not sure if there are other cases 19:08
btw, .then is invoked after invocant is kept or broken 19:24
and ready is a promise created with Proc::Async, so i'm pretty convinced that this should work 19:25
ugexe yea, but does .ready mean anything more than ready to start the process?
Voldenet ready means that vow containing PID was resolved 19:26
ugexe sounds like it doesn't mean the process is finished then 19:27
Voldenet Ah, yes, it's only a replacement for this is-spawned block 19:29
wait-for-finish is still in spawn-internal
github.com/rakudo/rakudo/blob/925c...c.pm6#L179 19:31
ugexe you think thats where the threads are getting blocked? 19:34
Voldenet Yes, I've tested it and `await $!proc.ready` is where the problem is 19:35
ugexe so something about await $!proc.ready + non-existant command 19:36
still seems weird it doesn't happen for any non-zero exit though 19:37
Voldenet > $!pid = await $!proc.ready.then({$}); 19:38
well, this just ignores the problem, I'm guessing it's some problem with the promise 19:39
Whoa, you don't even need a process promise to cause a deadlock there 19:42
any broken promise works 19:43
samcv i'm working on updating unicode from 11.0 to 12.1 for MoarVM 19:49
Geth nqp: 9d7d90aa52 | (Patrick Böker)++ | tools/templates/windows/nqp-m-build.c
Fix return code of nqp build runner

Don't use `exec()` as that's broken on Windows. Directly use
  `CreateProcess()`, wait for it to finish, retrieve the exit code and
exit with that ourselves.		 20:00
nqp: c0f3ab3d77 | (Patrick Böker)++ | tools/templates/moar/Makefile.in
Link build runners with correct flags

Forgot to include them as given.
nqp: fde335ddf6 | (Patrick Böker)++ (committed using GitHub Web editor) | 2 files
Merge pull request #566 from patzim/fix-windows-build-runner

Fix return code of nqp build runner + A little makefile cleanup
rakudo/master: 4 commits pushed by (Patrick Böker)++ 20:03
Voldenet ugexe: I've reduced that problem into something more apparent 20:09
loop { say ++$; do { CATCH { default { } }; await Promise.broken(":("); }; }
I don't think that code is supposed to deadlock 20:10
20:33 pamplemousse left
Voldenet more reduced case: loop { say ++$; CATCH { default { } }; { CATCH { }; X::AdHoc.new(payload => ":(").rethrow; }} 20:51
ugexe it took me a minute to realize :( was a frown face and not part of :(")
nice work 20:53
Voldenet use nqp; loop { say ++$; CATCH { default { } }; { CATCH { }; my $ex := nqp::newexception(); try nqp::setmessage($ex, "test"); nqp::rethrow($ex) }} 20:59
21:12 chloekek left 21:20 robertle left 22:43 pamplemousse joined
ugexe Voldenet: github.com/rakudo/rakudo/issues/3080 23:15
23:42 pamplemousse left 23:43 pamplemousse joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!