github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:03 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
MasterDuke hm, there's no way to mention a constant #define'd in a .h file in a jit template is there? 00:12
samcv MasterDuke: not sure what you're asking? 00:15
oh. you mean to have inserted into the expr template? 00:16
00:38 Monkeh1 joined 00:44 Monkeh1 left 01:10 nukedclx13 joined 01:13 nukedclx13 left
MasterDuke yeah 01:50
oh, wait, maybe there is 01:51
02:55 MasterDuke left 04:01 avar left, avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 05:42 domidumont joined 05:43 p6bannerbot sets mode: +v domidumont 06:18 brrt joined
Geth MoarVM/fork-safety: 73156ba02a | (Bart Wiegmans)++ | 5 files
[Spesh] Tear down spesh worker in full_cleanup

If the spesh worker is still active the GC can try to free a lock that is being held, which leads to an abort in libuv. Stopping the thread makes full-cleanup work (although it still leaks).
Thread is stopped by signalling with VMNull. Ideally we'd unshift this to the front of the queue, but that is more complicated.		 06:18
06:19 p6bannerbot sets mode: +v brrt
MoarVM/fork-safety: ac44769b9f | (Bart Wiegmans)++ | 3 files
[ConcBlockingQueue] Unmoving body

The locks structure was already malloc'd, and I extended this to include the entire body. This prevents the GC from moving the body while we are blocked on acquiring a lock, simplifying the code, and has negligible cost.
MoarVM/fork-safety: f5e4dfde79 | (Bart Wiegmans)++ | 3 files
[IO] Stop event loop thread

Stop loop with uv_stop(uv_loop) and join the thread
MoarVM/jit-expr-optimizer: 4 commits pushed by (Bart Wiegmans)++ 06:20
06:21 domidumont left 06:52 robertle joined 06:53 p6bannerbot sets mode: +v robertle
Geth MoarVM/template-compiler-refactor: c09e4595a2 | (Bart Wiegmans)++ | 5 files
[JIT] New template compiler

  - Single-pass compilation (no separate 'validate_template' step
  - Better type and format checking (operands should be expressions or
   references, parameters should be barewords, numbers or macros)
  - Write-out parameters need to be refered with a \$ sigil, like \$0,
   and templates without output operands should not get a '!' suffix		 07:04
MoarVM/template-compiler-refactor: 16c45f2c57 | (Bart Wiegmans)++ | tools/expr-template-compiler.pl
[JIT] Tighten scope rules

  - Reintroduce lexical scope for let declarations
  - Forbid redeclarations (even inner-scope shadowing), because this is
   currently unhygienic
  - We do allow right-to-left references to declarations in the same let
   scope
... (9 more lines)
brrt also a rebase..... 07:08
07:11 fake_space_whale left
Geth MoarVM/template-compiler-refactor: 5c8e050d8c | (Bart Wiegmans)++ | tools/expr-template-compiler.pl
[JIT] Bind 'let:' declarations eagerly

If we resolve 'let:' declarations before applying macros, then there is no possibility of macros introducing a name clash. Also the compiler no longer needs to maintain an environment, and can reuse the deduplication logic that was already necessary due to macros.		 07:11
07:25 domidumont joined 07:26 p6bannerbot sets mode: +v domidumont
brrt I intend to merge the above ^ 07:29
07:33 Kinsmir0 joined 07:34 zakharyas joined 07:35 p6bannerbot sets mode: +v zakharyas 07:36 Kinsmir0 left
nine brrt: what I've seen so far looks good 07:38
07:56 zakharyas left 07:57 zakharyas joined, p6bannerbot sets mode: +v zakharyas 08:15 zakharyas left 08:21 graingert8 joined 08:25 graingert8 left 08:39 lizmat left 08:53 lizmat joined 08:54 p6bannerbot sets mode: +v lizmat 08:59 zakharyas joined 09:00 p6bannerbot sets mode: +v zakharyas
brrt ok, then i'll go for it 09:01
09:10 zakharyas left
brrt ugh, fill_macro still manages to screw up substitution 09:19
09:36 See joined 09:37 See left
Geth MoarVM/template-compiler-refactor: 620acf556a | (Bart Wiegmans)++ | tools/expr-template-compiler.pl
[JIT] Maintain link identity during macro expansion

Because the expand_macro routine constructs a new expression (it makes a copy of the original macro) it is necessary to maintain a substitution table to ensure that we replace the same references with identical substitutions. Added a test case to prove that we do this.		 09:51
09:56 zakharyas joined 09:57 p6bannerbot sets mode: +v zakharyas 10:09 brrt left
lizmat Q: is QASTOperationsMAST.nqp still used? I'm trying to add a "nqp::ifnull_s" there, but it won't even get compiled after a do a configure 10:34
ah, it's in NQP, duh 10:38
10:44 brrt joined, p6bannerbot sets mode: +v brrt
Geth MoarVM/master: 4 commits pushed by (Bart Wiegmans)++ 10:45
lizmat brrt: feels like a bump is in order ? 10:46
brrt Let me see, what else is there to merge 10:50
I want to get ugexe++'s libuv bump in as well
lizmat sounds like a plan
brrt what's cool about these patches is that macro's and let declarations kind of work like you should expect in the template compiler 10:51
the blurb for the weekly is that this makes writing expression templates safer and simpler
:-)
lizmat brrt: thanks 10:52
weekly: the blurb for the weekly is that this makes writing expression templates safer and simpler
notable6 lizmat, Noted!
lizmat brrt: perhaps make them separate bumps for easier bisectability 10:54
brrt that's possible too
11:03 aaron7 joined 11:06 aaron7 left
lizmat brrt: should we see any performance difference after these changes ? 11:13
brrt no
there's a tiny memory leak cleanup
and the template compiler bit is all about correctness
lizmat ok, well, test-t feels a bit slower after the bump 11:14
but that could be noise
brrt there could be a *tiny* advantage since we now correctly do the implied subexpression elimination in let: expressions
but I don't think it makes any difference
lizmat if there is a difference, it's not positive :-) 11:15
at least, I'm not seeing it :-)
brrt oh well
I'll give speed for correctness :-)
lizmat indeed 11:16
masak a commonly held stance in software development :P 11:17
Geth MoarVM/master: 7 commits pushed by (Jeremy Studer)++, (Bart Wiegmans)++ 11:50
MoarVM: 73e2f53d73 | (Nick Logan)++ (committed by Bart Wiegmans) | 3rdparty/libuv
Update libuv to 1.23.0
 11:51
MoarVM: aacd1a7883 | (Nick Logan)++ (committed by Bart Wiegmans) | build/Makefile.in
Update libuv timer source path

The unix and win implementations were consolidated and thus the path of the source no longer had 'unix/' in it.
  github.com/libuv/libuv/commit/95c5...6730ae703b
lizmat brrt: hmmm.... :-)
lizmat will bump unless told otherwise
brrt hasn't yet tested the libuv changes
that said, I trust ugexe 11:52
lizmat is going to test nqp ow
now and if clean, bump rakudo
Geth MoarVM: f71f55cf76 | (Daniel Green)++ (committed by Bart Wiegmans) | src/jit/graph.c
JIT decoder(empty|takebytes)
 11:56
MoarVM: e4b75b8b8d | (Daniel Green)++ (committed by Bart Wiegmans) | src/jit/graph.c
Use uintptr_t for decoder* char * to integer casts
lizmat hmmm... rakudo doesn't build anymore 12:10
'uv/errno.h' file not found 12:11
#include "uv/errno.h"
In file included from src/vm/moar/ops/perl6_ops.c:2:
In file included from /Users/liz/Github/rakudo.moar/install/include/moar/moar.h:19:
gist.github.com/lizmat/1cc5df073b8...05edecf460 12:14
FWIW, make test on NQP was fine
commute& 12:17
12:17 lizmat left 12:18 lizmat joined, lizmat left 12:21 brrt left 12:25 brrt joined 12:26 p6bannerbot sets mode: +v brrt
jnthn Lots going on here, I see. Nice. :-) 12:35
dogbert2 lizmat is correct rakudo doesn't build with the new libuv 12:36
In file included from /home/dogbert/repos/rakudo/nqp/MoarVM/../../install/include/moar/moar.h:19:0, from src/vm/moar/ops/perl6_ops.c:2:
/home/dogbert/repos/rakudo/nqp/MoarVM/../../install/include/libuv/uv.h:48:22: fatal error: uv/errno.h: No such file or directory #include "uv/errno.h"
jnthn OK, maybe not entirely nice :D 12:37
dogbert2 it's probably not impossible to fix :) 12:38
12:40 ori12 joined
dogbert2 comparing rakudo (with the new libuv) with the previous version, i.e. my rakudobrew uncovers a difference 12:40
12:40 ori12 left
dogbert2 /home/dogbert/repos/rakudo/install/include/libuv/uv-errno.h 12:40
/home/dogbert/repos/rakudo/nqp/MoarVM/3rdparty/libuv/include/uv/errno.h 12:41
12:41 lizmat joined 12:42 p6bannerbot sets mode: +v lizmat
dogbert2 eh, I meant this 12:42
/home/dogbert/.rakudobrew/moar-master/nqp/MoarVM/3rdparty/libuv/include/uv-errno.h
lizmat dogbert2: there are more cases where it looks like uv/foo.h became uv-foo.h 12:52
nuking install doesn't fix the issue 12:54
perhaps we should revert the libuv update ? 12:55
dogbert2 unless brrt can fix it in a flash :)
jnthn Probably easier to wait a few hours to see if somebody can fix it (not me, alas, teaching :)) and just don't bump the MOAR_REVISION/NQP_REVISION 12:56
dogbert2 the difference seems to be that previously the libuv include files were present in 3rdparty/libuv/include but now all except one have been moced to 3rdparty/libuv/include/uv 12:57
*moved
lizmat what I don't understand is why this doesn't show up with building MoarVM / NQP ? 12:59
lizmat tries a fresh checkout of MoarVM 13:01
fresh checkout of MoarVM builds ok 13:05
dogbert2 aha
lizmat !
dogbert2 ah, MoarVM, that worked before no
lizmat dogbert2: is that a question ? 13:09
dogbert2 I think so, didn't MoarVM build before you did a fresh checkout ? 13:15
lizmat it also built 13:16
dogbert2 I'm probably just confused atm .)
lizmat but I was thinking that since there are files missing in the rakudo case, maybe my checkout somehow had the files
so it built ok using files not in the repo 13:17
a fresh checkout also builds, so scratch that idea
I'm out of ideas atm 13:18
timotimo could be another case of "submodules changing around too much makes git pull unhappy", just in a different way this time 13:23
lizmat yeah, that was my idea in nuking install 13:24
alas
timotimo perhaps nuking 3rdparty/ would have been more helpful 13:25
well
nuking is not quite the right word
some things in there aren't submodules, and therefor won't just be restored after an rm -rf
lizmat rm -rf install # that's nuking to me
lizmat tries a fresh rakudo checkout 13:26
timotimo oh
the Makefile.in has been changed, right?
so what you need is at least a Configure.pl in moarvm
dogbert2 I got it working with some shenanighans 13:29
lizmat doesn't make a differece :-(
timotimo hans, is that you?
dogbert2 then you run 'make install' in the MoarVM directory it seems as if some/most 3rdparty h-files are copied to <rakudodir>/install/include 13:31
s/then/when/
unfortunately only one libuv h-file is copied, i.e. uv.h the files in the new uv directory are not copied
lizmat datapoint: a fresh rakudo checkout + NQP bump doesn't build either (same error) 13:32
dogbert2 lizmat, see above
lizmat feels like a workaround at best ? 13:33
dogbert2 yes, I suspect that should be done automatically 13:34
brrt make reeconfig?
i'm slightly confused as to what is the issue
dogbert2 rakudo doesn't build 13:35
brrt i'll check it out...
dogbert2 I suspect this line is not enough (taken from a Makefile in my MoarVM dir) - $(CP) 3rdparty/libuv/include/*.h $(DESTDIR)$(PREFIX)/include/libuv 13:37
brrt that could well be possible yes
dogbert2 the libuv header files, except one, have moved to rdparty/libuv/include/uv 13:38
brrt right 13:39
13:57 AlexDani` joined, p6bannerbot sets mode: +v AlexDani` 14:00 zakharyas left 14:01 zakharyas joined, AlexDaniel left, p6bannerbot sets mode: +v zakharyas 14:05 zakharyas left 14:06 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDani` joined 14:07 p6bannerbot sets mode: +v AlexDani`
brrt has a fix 14:13
there are reasons to want to overhaul the Configure.pl
and there are reasons not to, including 'time limits' 14:14
I think mst++ once complained loudly about our Configure.pl, and not without reason
Geth MoarVM: ccc315f712 | (Bart Wiegmans)++ | Configure.pl
[LibUV] Install subdirectory of headers

Now that we have libuv 1.23, platform specific headers are placed under
  'libuv/uv/', rather than directly under 'libuv/'n and we didn't install
them yet, but now we do.		 14:17
lizmat brrt++ # rakudo's building 14:28
dogbert2 brrt++ 14:29
lizmat spectesting now
bumped! 14:37
dogbert2 didn't nine have some cool stuff in the works, something with hllbool? 14:47
lizmat afk for a bit& 14:49
14:49 lizmat left
brrt I think so, and timotimo also had branches 14:57
timotimo i have some branches, yeah
brrt what's the deadline for those :-P
timotimo hm 14:58
i've got some changes that want a coordinated moarvm and nqp merge
japhb timotimo: ready to go, or still working on them? 15:03
timotimo i think i actually want to change the api just a little bit 15:05
15:08 brrt left 15:16 robertle left 15:19 fake_space_whale joined 15:20 p6bannerbot sets mode: +v fake_space_whale 15:27 BuildTheRobots4 joined 15:29 BuildTheRobots4 left 15:35 lizmat joined 15:36 p6bannerbot sets mode: +v lizmat 15:42 domidumont left 15:49 zakharyas joined 15:50 p6bannerbot sets mode: +v zakharyas 15:56 robertle joined 15:57 p6bannerbot sets mode: +v robertle
timotimo you see, it's about adding more data from the program to the profile, more precisely it's about getting type info; size of objects of that given type, and whatever other info we can get 16:09
16:10 zakharyas left 17:22 zakharyas joined, p6bannerbot sets mode: +v zakharyas 17:38 AlexDani` is now known as AlexDaniel 17:48 zakharyas left
dogbert11 lizmat: I've now reported the RPi SEGV problem, from yesterday, as github.com/MoarVM/MoarVM/issues/951 19:04
20:56 lizmat left 21:29 robertle left 21:44 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke 21:46 MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
Geth MoarVM: ugexe++ created pull request #952:
Fix sprintf formatting for the debugserver port		 22:04
22:06 Kaiepi joined 22:07 p6bannerbot sets mode: +v Kaiepi

Powered by Cro and the Raku® Programming Language.

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

Thank you!