Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-02-20

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:12 ggoebel joined #moarvm
01:28 IRCFrEAK joined #moarvm
01:28 IRCFrEAK left #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:16 BenGoldberg joined #moarvm
04:35 madgoat joined #moarvm
04:35 madgoat left #moarvm
07:31 brrt joined #moarvm
07:32 brrt good *, #moarvm
07:32 nwc10 good *, brrt
07:33 brrt ohai nwc10
07:33 brrt i was just trying to figure out how to do the special tiles thing…..
07:34 nwc10 "with a hammer"
07:34 nwc10 or, "bigger hammer"
07:34 brrt well, everything looks like a nail anyway
07:34 nwc10 given that it's tiles, maybe that's *not* the right tool
07:36 brrt i hadn't taken the complexity of dealing with the 'synthetic' tiles properl into account yet
08:17 brrt joined #moarvm
08:23 zakharyas joined #moarvm
09:04 brrt so another thing i thought of; a 'node' of the expr jit is now necessarily 64 bits wide in order to store pointers; but that is in a way a ridiculous requirements while virtually all trees I can think of can be stored in 16 bits, and certainly all in 32 bits
09:05 brrt but if I add some syntax to detect pointer references in the expression tree, I could compile code to store them in a list (i.e. use an extra layer of indirection to store the, relatively rare, pointers)
09:07 brrt an advantage of that is that it could go some way to make storage-and-linking work, i.e. those pointers could be stored in the data section and matched with labels and addresses
09:07 brrt i don't really see a disadvantage to that….
09:32 lizmat brrt: fwiw, it smells like a premature optimization to me
09:38 brrt possibly, yes
09:38 brrt (what, me, overingieer?)
09:43 jnthn morning, #moarvm
09:45 brrt moarning jnthn
09:48 brrt that said this bit has been on my mind for a *long* time now, so i'm just going to record a plan for it, and do it later :-)
09:55 brrt more to the point, this has some beneficial side-effects as well, since 'real' large 64 bit values typically want to be handled differently from 32 bit constants, at least in x86
09:56 brrt i.e. loading a 64 bit const requires a movabs (which requires a register), or a load-from-data-section; which means that it doesn't work inline like a 32 bit constant does
09:56 brrt so ultimately, from the tile perspective, this could be a large simplification, since I could just make tiles like ADD not support loading 64 bit constants
10:03 Geth ¦ MoarVM/even-moar-jit: 4494d851d7 | (Bart Wiegmans)++ | 2 files
10:03 Geth ¦ MoarVM/even-moar-jit: Find 'special' tiles and stub handling them
10:03 Geth ¦ MoarVM/even-moar-jit:
10:03 Geth ¦ MoarVM/even-moar-jit: Some of the infrastructure (notably, a map of register -> live range) to
10:03 Geth ¦ MoarVM/even-moar-jit: actually compile CALL and ARGLIST is not yet available. But now we can
10:03 Geth ¦ MoarVM/even-moar-jit: at least find these tiles.
10:03 Geth ¦ MoarVM/even-moar-jit:
10:03 Geth ¦ MoarVM/even-moar-jit: That said, it might be nice to roll ARGLIST and CALL into a single tile
10:03 Geth ¦ MoarVM/even-moar-jit: so we can ensure that loading the argument to CALL (sometimes a dynamic
10:03 Geth ¦ MoarVM/even-moar-jit: pointer) will not conflict with call arguments set up by ARGLIST.
10:03 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/4494d851d7
10:03 Geth ¦ MoarVM/even-moar-jit: 3374d2844f | (Bart Wiegmans)++ | docs/jit/plan.org
10:03 Geth ¦ MoarVM/even-moar-jit: Investigate large constants
10:03 Geth ¦ MoarVM/even-moar-jit:
10:03 Geth ¦ MoarVM/even-moar-jit: Large (64 bit) constants currently force a excessive expression node
10:03 Geth ¦ MoarVM/even-moar-jit: size, and they typically need distinct handling from 'regular'
10:03 Geth ¦ MoarVM/even-moar-jit: constants, esp. pointers, which we would like to have in a table for
10:03 Geth ¦ MoarVM/even-moar-jit: linking, and for binary operators, in which directly using a 64 bit
10:03 Geth ¦ MoarVM/even-moar-jit: constant is not directly supported on x86 while a 32 bit constant is. So
10:03 Geth ¦ MoarVM/even-moar-jit: it would be interesting to split the large constants from the small
10:03 Geth ¦ MoarVM/even-moar-jit: ones.
10:03 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/3374d2844f
10:03 brrt (i did not decide to use the queue, after all, although elegant, a cursor would do just as well)
11:23 pyrimidine joined #moarvm
12:15 sivoais joined #moarvm
12:27 dogbert11 jnthn: sorry to be a nuisance :) but should I do anything else wrt lizmat's bug. Do you have all the info you need (or a hint if you would like me and/or timotimo to fix it)?
12:30 jnthn dogbert11: Mostly now I just need time to look more closely at what you've found :-)
12:32 dogbert11 jnthn: ok, let me now if you want me to try something else in case you need more info
12:32 jnthn Will do; thanks! :)
12:32 * dogbert11 will check out the RT SEGV list in the meantime
12:35 lizmat dogbert11: which bug are you referring to?
12:35 lizmat something I did, or something I reported ?
12:36 dogbert11 lizmat the latter your harness6 troubles
12:36 lizmat aaaahhh  :-)  ok  *phew*  :-)
12:37 dogbert11 do you run it with a high number of TEST_JOBS?
12:38 lizmat 8
12:38 lizmat not sure that's high, it's the number of virtual cores my MBP has
12:44 dogbert11 cool, so you have a 4 core CPU with hyperthreading then
12:48 MasterDuke joined #moarvm
13:02 zakharyas joined #moarvm
14:48 TimToady I regularly run with 6, and still get the occasional flakeouts
14:48 TimToady (on a 4-core)
14:51 brrt yeah, same here
14:51 brrt but mostly on linux, though
14:52 TimToady same
15:15 dogbert11 TimToady, brrt are you both running with harness6?
15:16 brrt well, i'm running whatevers the default, really
15:17 dogbert11 'make spectest' defaults to harness5 if I'm not mistaken. What kind of flakeouts are we talking about here?
15:21 brrt well, tbh, i don't have it available, but last I knew IO::Async::Sockets test could still lock up
15:22 TimToady t/spec/S11-modules/require.rakudo.moar                          (Wstat: 65280 Tests: 11 Failed: 1) Failed test:  11 Non-zero exit status: 255 Parse errors: Bad plan.  You planned 27 tests but ran 11.
15:22 TimToady but then run by hand it worked fine
15:22 TimToady that's just with default harness
15:44 dogbert11 hmm
16:05 brrt joined #moarvm
17:46 BenGoldberg joined #moarvm
18:17 dogbert17 joined #moarvm
18:56 pyrimidine joined #moarvm
21:50 BenGoldberg Can someone give me some advice?  I want to compile moarvm, and I'm on windows.
21:50 jnthn I tend to build it with the MS VC++ toolchain
21:50 * BenGoldberg was hoping he wouldn't have to learn visual studio ....
21:50 jnthn You don't
21:51 jnthn Just need the command line tools
21:51 BenGoldberg That sounds much less sucky ;)
21:51 BenGoldberg What would you recommend I install?
21:52 BenGoldberg Any specific version which is easier to put in and use?
21:52 jnthn On https://www.visualstudio.com/downloads/ I think if you find "Microsoft Visual C++ Build Tools " (near the bottom) that should get you just the command line tools
21:54 BenGoldberg "Microsoft Visual C++ Build Tools 2015 Update 3
21:54 BenGoldberg " ?
21:55 jnthn Yeah
21:56 BenGoldberg I also see "Build Tools for Visual Studio 2017 RC"
21:56 BenGoldberg The desc says "These Build Tools allow you to build native and managed MSBuild-based applications without requiring the Visual Studio IDE"
21:58 jnthn Think that's just a newer version
21:58 jnthn I'd stick with the older one
21:58 jnthn Last time I used an RC of something from MS it was a screw-up
21:59 BenGoldberg And here's the reason why I want to build moar -- I want a perl6 plugin for my favorite irc client, hexchat, and, since there isn't one, I'm writing it.
22:01 BenGoldberg I've got the start of a plugin here: https://gist.github.com/BenGoldberg1/de4528223af21e5aabea689805528115
22:04 jnthn Cool :)
22:12 jnthn https://gist.github.com/BenGoldberg1/de4528223af21e5aabea689805528115#file-perl6-c-L91
22:12 jnthn You'll get a compile error in MSVC on at least this line, fwiw
22:12 jnthn (It wants all decls at the top of the function)
22:12 jnthn (or block)
22:12 BenGoldberg Right, C not C++ :)
22:14 jnthn Well, C99 lets you do that
22:14 jnthn But Microsoft decided they'd bet the whole house on C++
22:15 * BenGoldberg tries to remember where he copied this code from -- who the f sticks pointers to local variables into a global object.
22:18 jnthn Inline::Perl6, maybe? :)
22:19 BenGoldberg Yeah, Perl6.xs, I'm looking at you.
22:20 BenGoldberg Are those pointers not needed after toplevel_initial_invoke?
22:20 BenGoldberg Also, what's with that start_frame?  It's never used anywhere.
22:21 jnthn heh, indeed, so it can go away
22:22 jnthn Which local vars are you worrying about?
22:22 jnthn Oh, I see
22:23 jnthn No, they won't be used after toplevel_initial_invoke returns
22:23 BenGoldberg Ok, I was worried.
22:24 BenGoldberg Also I see that 'MVMCompUnit *cu' is only used inside of initialize, but it's declared as a global.
22:25 jnthn That's a tad curious also
22:25 jnthn Should probably take this and hide some of the structure pokery behind a proper API
22:33 BenGoldberg Since hexchat is a gui irc client, it doesn't have a proper stdout/stderr.  Is simply assigning my own object (with .print and .say methods) to $*OUT and $*ERR sufficient to make sure all errors and prints get sent to the screen?
22:34 BenGoldberg I'm worried about low level C code doing a printf :)
22:34 moritz that wouldn't land in $*OUT or $*ERR
22:35 moritz but shouldn't happen in normal Perl 6 code either
22:35 BenGoldberg It would land in the bitbucket.
22:41 jnthn Sleep time for me; 'night
22:45 BenGoldberg G'night, then

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary