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.
jnthn Think it worked out 00:00
vrurg jnthn: yep, it did. Thanks! 00:01
00:11 pamplemousse_ left
jnthn \o/ 00:19
sleep; 'night o/ 00:20
Geth roast: vrurg++ created pull request #544:
Add revision 6.e		 00:21
vrurg jnthn: g'night! o/ 00:22
00:34 MasterDuke joined, MasterDuke left, MasterDuke joined 00:52 TimToady left, TimToady joined 00:58 jdv79 left, jdv79 joined 01:54 dogbert17 joined 03:17 Xliff left 03:54 MasterDuke left
Geth rakudo: kazcw++ created pull request #2938:
fix install-dist		 04:53
[Tux] (vrurg++)++; # simplicity and explanation 07:32
yoleaux 29 May 2019 13:41Z <vrurg> [Tux]: there're couple possible causes to your problem: repo stuck in some messed up state; Makefile is not regenerated. The latter could be caused if your config.state contains --expand. Try running Configure.pl manually once.
[Tux] there indeed was --expand. After reading the --helps and reverting from config.status to simplified perl configure.pl commands, builds are back to working again 07:33
timing started …
Rakudo version 2019.03.1-507-ge623265e3 - MoarVM version 2019.05-20-g20930127e
csv-ip5xs0.719 - 0.725
csv-ip5xs-206.241 - 6.708
csv-parser23.644 - 23.942
csv-test-xs-200.445 - 0.461
test7.472 - 7.507
test-t1.697 - 1.830
test-t --race0.817 - 0.819
test-t-2029.739 - 30.411
test-t-20 --race9.578 - 10.448
 07:49
08:14 leont joined
lizmat Files=1262, Tests=108009, 201 wallclock secs (26.62 usr 7.22 sys + 2823.11 cusr 274.53 csys = 3131.48 CPU) 08:43
08:52 AlexDaniel joined
kawaii Hey AlexDaniel, IIRC you said you might have some time in June to guide me through a first release right? 08:54
So we should probably choose a commit in the next few days to pin 2019.06 to, and create a release branch for that 08:55
AlexDaniel kawaii: it sounds like a great idea but I don't know if it's going to work in practice 09:22
kawaii: for example, moarvm will need to have a release branch also, then
kawaii: also whateverable and therefore blin don't work that great with branches (yet) 09:23
I tried to fix that some time ago but it's still not working, I'll work hard on this during this summer
well, hopefully… 09:24
lizmat fwiw, I think we need a release rather sooner than later :-( 09:25
AlexDaniel lizmat: are you implying that June 20th is “later”? :)
lizmat I guess I do 09:27
AlexDaniel why?
lizmat because we already missed the 2019.04 *and* 2019.05 releases ?
AlexDaniel and? There's something wrong with 2019.03? 09:28
lizmat no, there isn't 09:29
but there's a reason for the meme "release early, release often" :-)
AlexDaniel lizmat: IIRC there were complaints about memory growth, or something like that, and github.com/MoarVM/MoarVM/pull/1072 was merged 6 days ago 09:30
so that's nice
but it can wait till 20th for sure, I think
kawaii 2019.03 is a very stable release, hence why I did not bother Alex with such urgency for 04 and 05, since it seemed that it would be safe to wait for an 06 release - I would rather have him available to guide me through my first one, rather than put out a potentially bad release :)
AlexDaniel personally I dislike the idea of making releases just because we have to 09:31
kawaii Alex's time is far more limited than my own at this time, so I felt like waiting was the best option
AlexDaniel and I think for every new release we should be able to confidently say that it is better than the previous one
lizmat all true 09:32
I just hope that we *will* make a June release
AlexDaniel 18-30th I'm all yours :) 09:33
leont Ah, I was already wondering what happened to 2019.05
AlexDaniel before that too, to a limited extent :)
lizmat AlexDaniel++
kawaii AlexDaniel: we can coordinate with the moarvm team to push out a release around then :)
lizmat and let's make it a whopper of a release then :-)
kawaii 3 months of fixes and changes, should be a nice upgrade 09:34
AlexDaniel yess
timotimo: so are Cro::ZeroMQ tests passing for you? 09:36
timotimo: I started getting `zmq_poll returned error: -1` a few days ago, even though I didn't upgrade rakudo, or any modules, or zeromq… it's really weird 09:37
but it does “work”, as in whenever I send something from one side, it immediately crashes with `zmq_poll returned error: -1` on the other side. So the messages are being sent!
timotimo oh, sorry, i didn't have a look yet 09:38
AlexDaniel timotimo: just run prove in Cro::ZeroMQ and tell me it works at all, that's all I need to know right now :)
although… I'm not sure… I think I had the same error in tests too, but in practice the module worked without any issue 09:39
"depends" : [ "Net::ZMQ", "Cro::Core", "Cro" ], 09:41
how does it know which Net::ZMQ it depends on
github.com/perl6/ecosystem/issues/457 09:48
kawaii AlexDaniel: I just triggered another Blin ecosystem run, just to see how things look 09:50
Hopefull will have results in 3 or 4 hours
AlexDaniel kawaii: and it's working?
kawaii yeah it's just updating mirrors etc now 09:51
www.irccloud.com/pastebin/kkdAbUdP/
hm, or not
AlexDaniel e: say 42
evalable6 42
AlexDaniel shareable6: e623265e3 09:52
shareable6 AlexDaniel, whateverable.6lang.org/e623265e3
AlexDaniel kawaii: random guess: zstd and lrzip are not installed
kawaii AlexDaniel: I have both of those installed already from the previous run 09:53
timotimo yeah i get the test failure, too
lizmat also: in a prokect 09:54
again: in a project I'm working on, I need to nuke .precomp every time I make a change in one of the modules of the project
otherwise it dies with: Failed to open file /Users/liz/.../foo.pm6: Too many open files 09:55
I traced this back to IO::Handle indeed failing to open a file for slurping
timotimo oh that's interesting 09:56
strace should say what file descriptor number it's trying to use
lizmat but I also verified that all handles *are* closed after having been slurped
timotimo and there's not only file descriptors for files, but also for ... random other stuff
kawaii AlexDaniel: hm, I nuked my entire Blin and cloned a new one, same error 09:57
timotimo but it would surprise me if a perl6 script managed to start too many threads to blow the file descriptor limit that way 09:59
there were some tickets that expected to spawn a few hundred threads without issue, and that ran into a "too many open files" issue that wasn't being reported, instead it just crashed i think
AlexDaniel kawaii: do you have access to whateverable.6lang.org/e623265e3 from that machine?
kawaii AlexDaniel: yes
AlexDaniel kawaii: then umm… debug it? 10:06
kawaii I'm at work but I'll see what the cause is 10:08
10:17 leont left
lizmat "dtrace: 3758 dynamic variable drops with non-empty dirty list" any idea what that means and how worrisome that is? 10:20
I guess stackoverflow.com/questions/493159...-in-dtrace 10:21
10:27 vrurg left 10:34 donaldh joined
AlexDaniel timotimo: hmmm, with proper error reporting I'm getting ZMQ error: Socket operation on non-socket (code 88) 10:40
“All ØMQ sockets passed to the zmq_poll() function must share the same ØMQ context and must belong to the thread calling zmq_poll().” 10:42
I wonder if that is related…
timotimo perhaps it's in fact a "tasks being shoved between threads when they shouldn't be" issue 10:44
AlexDaniel oh nice, my software now magically works 10:48
for no reason whatsoever
awesome
timotimo \o/ 10:54
lizmat seems my issue goes away with increasing my ulimit -n from 256 to 1024 11:11
timotimo wow, 256 is pretty low 11:30
lizmat yeah, not sure where that comes from 11:31
11:33 llfourn joined
lizmat m: my @a; push @a, 10 for ^100000; say now - INIT now 11:34
camelia 0.855711
lizmat m: my @a; @a.push(10) for ^100000; say now - INIT now 11:35
camelia 0.0367584
lizmat that's quite a difference, isn't it ?
AlexDaniel yes 11:43
6c: my @a; push @a, 10 for ^100000; say now - INIT now
committable6 AlexDaniel, gist.github.com/d828d7e6e4f955c75f...ee246b1a32 11:44
AlexDaniel looks like it has never been fast
buut
c: 2016.06,2016.07.1 my @a; push @a, 10 for ^100000; say now - INIT now 11:45
committable6 AlexDaniel, ¦2016.06: «0.475832␤» ¦2016.07.1: «1.40916737␤»
AlexDaniel bisect: 2016.06,2016.07.1 my @a; push @a, 10 for ^100000; say (now - INIT now) < 1
bisectable6 AlexDaniel, Using old=2016.06 new=2016.07.1 in an attempt to DWIM
AlexDaniel, Bisecting by output (old=2016.06 new=2016.07.1) because on both starting points the exit code is 0
AlexDaniel, bisect log: gist.github.com/31acb600f04a24fcdf...716a349345
AlexDaniel, (2016-06-29) github.com/rakudo/rakudo/commit/d5...fc37032b78
AlexDaniel c: d5c750f74cd^,d5c750f74cd my @a; push @a, 10 for ^100000; say now - INIT now 11:46
committable6 AlexDaniel, ¦d5c750f74cd^: «0.47477656␤» ¦d5c750f: «1.56509728␤»
AlexDaniel jnthn: ↑?
lizmat: it's probably a good idea to file a ticket 11:47
even if nobody fixes it today, someone later checks can check it out
lizmat yeah, will do after some more investigatin 11:48
m: my %h; %h<A> //= :[]; dd %h # why is :[] legal, and what does it mean ? 11:54
camelia Hash %h = {:A($[])}
AlexDaniel lizmat: it kinda works with {}, () and «» 12:04
not sure what for :)
lizmat m: dd :{}.keyof; dd {}.keyof
camelia Any
Str(Any)
lizmat :{} is short for an empty object hash 12:05
m: dd :[]
camelia Array element = []
lizmat nothing there
jnthn AlexDaniel: no idea, make an issue 12:25
Wonder if it's to do with slurpy/flattening stuff, though 12:26
12:32 MasterDuke joined 12:36 MasterDuke left 13:17 vrurg joined
Geth rakudo: 13d3f0d4ea | (Elizabeth Mattijsen)++ | lib/MoarVM/Profiler.pm6
MoarVM::Profiler tweaks
 14:17
15:34 robertle joined 15:59 skids joined 16:21 donaldh left
lizmat m: use MoarVM::Profiler; .say for profile( { for ^10000 { Nil } } ).my_allocations # did we lose the ^10000 optimization again ? 17:12
camelia ===SORRY!===
Could not find MoarVM::Profiler at line 1 in:
inst#/home/camelia/.perl6
inst#/home/camelia/rakudo-m-inst-1/share/perl6/site
inst#/home/camelia/rakudo-m-inst-1/share/perl6/vendor
inst#/home/camelia/rakudo-m-inst-1…
lizmat m: 42
camelia WARNINGS for <tmp>:
Useless use of constant integer 42 in sink context (line 1)
17:13 pamplemousse joined
lizmat timotimo moritz looks like Camelia is stuck quite a few commits ago ? 17:13
17:16 lucasb joined
lizmat m: class A { }; dd Rakudo::Internals::JSON.to-json(A.new) # shouldn't that just die ?? 17:57
camelia "\{\n \"0\": null\n}"
vrurg Is it possible to declare a ?-twigil constant in core setting? 18:11
[Tux] vrurg++; # just for good measure 18:34
lizmat vrurg: yes 18:42
m: dd Rakudo::Internals::JSON.to-json(i) # another one I think should die
camelia "\{\n \"0\": null\n}"
vrurg lizmat: sorry, the question was incomplete. I want it to have different value for each setting. 18:43
lizmat tricky... am about to finish something up, and then go see some Godzilla, so if you don't have an answer by tomorrow, ping me again tomorrow 18:44
vrurg Wanna have something that would report revision letter of the loaded setting for testing purposes. Currently I achieve this with a sub in each setting. But $?CORE-SETTING-REV would fit the best.
Geth roast/master: 5 commits pushed by (Vadim Belman)++ 19:00
19:09 leont joined 19:11 pamplemousse left 19:21 pamplemousse joined 20:10 ufobat__ joined 20:14 ufobat_ left 20:56 AlexDaniel left 20:57 AlexDaniel joined 21:31 leont left
ugexe vrurg: what is a scenario when you would want that? it seems that as the one writing the code i can always be aware of what the revision is by declaring it outright. 22:50
im sure there is one, im just drawing a blank
vrurg ugexe: only to test if the expected core.setting is loaded and functional. 22:51
ugexe oh testing perl6/rakudo. i kept thinking for module test cases ala if $?FOO < 6.e { die "need 6.e!" } 22:53
vrurg I've ended up with defining $*CORE-SETTING-REV on PROCESS::.
ugexe a subkey of $*PERL might work 22:55
vrurg Yep... github.com/rakudo/rakudo/pull/2852...91818bd0R4 and then github.com/rakudo/rakudo/pull/2852...bd835deR11
ugexe m: use v6.c; say $*PERL 22:57
camelia Perl 6 (6.c)
ugexe m: use v6.d; say $*PERL
camelia Perl 6 (6.d)
vrurg I'm trying to avoid namespaces polluting. Bsides, the compiler and core setting are different eventhough linked things.
22:58 ggoebel left 23:04 pamplemousse left 23:56 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!