Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-09-29

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

All times shown according to UTC.

Time Nick Message
01:21 zakharyas joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:50 mtj_ joined #moarvm
05:13 domidumont joined #moarvm
05:18 domidumont joined #moarvm
05:41 brrt joined #moarvm
05:49 brrt good * #moarvm
05:50 nwc10 good *, brrt
05:52 brrt i'm stuck on a design choice again
05:55 brrt the basic underlying issue is that i'd like the register allocator to be able to insert tiles (code) that refers to live range keys, rather than hard-coded registers
05:55 brrt as that would allow the actual registers to be assigned in a single register assignment step
05:55 nwc10 I don't know enough to be helpful here
05:56 brrt (and failing to do so would mean that the tile insertion step would have to wait until after the register assignment step, which means that it requires another buffer, and, yada yada yada)
05:56 nwc10 you can tell "me" sutff, but I'm about as effective as a teddy bear
05:56 brrt heh
05:56 brrt teddy bears are definitely useful
05:57 domidumont joined #moarvm
05:57 brrt anyway, maybe if i just put it out here, then someone maybe has a better idea
06:00 brrt (sidenote: I have a feeling that throughout this process, the chain from 'i need this feature' and 'this needs to be implemented' is… long, and convoluted)
06:01 brrt because the design question is: - store tree node + order position in the tile, vs. store the node 'opcode'
06:05 brrt the node = the position of the refered thing, e.g. 1,17, the node 'opcode' is the refered thing itself, e.g. IF, DO, ADD, etc.
06:06 brrt take it as a given that we need the opcode itself in later stages, because we need to know where the IFs are that yield different 'value paths' and hence need resolving
06:06 brrt (like PHI nodes)
06:08 brrt however, we only want to do that for the 'postorder' IF nodes
06:08 brrt which, ironically, do nothing otherwise
06:08 brrt the 'inorder' IF nodes represent labels and jumps etc
06:08 brrt but are not relevant from the perspective of the register allocator
06:11 brrt so the question is, what labeling do we use for the inorder/preorder tiles to distinguish them from postorder tiles
06:11 brrt (why cant it just be a flag?)
06:16 brrt my information-preserving instincts say: store both the node position and the tree-order position
06:17 brrt the counterpoint: that is both difficult to deal with (which tree-order position is postorder, exactly)
06:18 brrt and redundant, because if (as is my plan) at tile generation time you already perform all necessary node extraction, then you don't need the exact node position anymore
06:18 brrt however....
06:20 brrt not having the node means that you have to store the 'self' node in the 'values' tile array instead
06:20 brrt that is okay… but… ugly
06:21 brrt furthermore, you still need the 'opcode' itself
06:24 brrt i think that conceptually, opcode + self node in values is cleaner than self-node + order position, because it removes all tree order considerations
06:24 brrt that means that the opcode for synthetic ops still needs to be synthetic, but because it doesn't refer to anything anymore, why not
06:25 brrt (one of the problems of an earlier approach was that using e.g. -1 as a sentinel value conflicted with repeated access into the array using it as an offset
06:25 brrt )
06:27 brrt okay, i'm decently happy about that conclusion
06:43 brrt joined #moarvm
06:49 nine wrl: https://github.com/niner/Inline-Perl6/blob/master/Perl6.xs embeds a moarvm and Perl 6 in Perl 5. It's a bit hacky, but not as bad as I expected it to turn out.
06:52 nine brrt: so you're gonna go with opcode + self?
06:53 brrt i think so yeah, that eliminates all references to the tree at that point…..
06:53 brrt hmmm
06:53 brrt hang on :-(
06:53 brrt we do kind of need, or rather, want, the default storage location
07:51 btyler joined #moarvm
07:54 andrzejku joined #moarvm
07:54 andrzejku hello
07:54 andrzejku :)
07:57 brrt hi andrzejku
07:57 andrzejku I come here to help you
07:57 brrt (hope i spelled that right)
07:57 brrt well, that's great
07:57 andrzejku yeah
07:57 brrt how would you like to help
07:58 andrzejku who is scrum master?
08:00 andrzejku brrt,
08:00 brrt we… are an open source project. we don't have a scrum master
08:00 andrzejku oh okay
08:00 andrzejku brrt, who is team leader than?
08:01 brrt i was not under the impression that anyone was
08:01 brrt jnthn is a very active contributor, and some might say he's the 'architect'
08:02 brrt project leader, i could agree with
08:02 brrt team leader, I probably wouldn't think he'd agree with
08:02 andrzejku oh okay
08:03 brrt maybe it is better if you could tell me (us) what you are looking for
08:03 psch andrzejku: is there a specific question you'd want to ask a hypothetical team leader?
08:03 andrzejku yep
08:03 andrzejku I am looking for position for me
08:03 brrt okay, there are plenty of things to do, really
08:04 brrt what are some things that you'd be interested in?
08:04 brrt have you seen our issue tracker on github?
08:04 andrzejku ye there plenty bugs
08:04 andrzejku ;p
08:04 brrt right :-)
08:04 brrt so maybe the easiest thing to start with would be to pick something that seems tractable
08:05 brrt and if you need any help or advice, just ask
08:06 andrzejku w8 i will back soon [kid]
08:06 brrt this is irc, there is an expectation of asynchrony
08:06 brrt :-)
08:10 brrt andrzejku: this is a good issue to start with i think
08:10 brrt https://github.com/MoarVM/MoarVM/issues/293
08:12 stmuk_ jnthn: last comment on https://github.com/tadzik/panda/issues/324 looks interesting! (in case you haven't seen it)
08:52 stmuk_ hmm the BSD reproduce works on Bay Trail which doesn't have HLE AFAIK (?) - I suspect its not supported in the BSD libraries
08:55 andrzejku joined #moarvm
08:56 andrzejku brrt, stmuk_ thnks
09:11 brrt1 joined #moarvm
09:37 jnthn stmuk_: I'd kinda like it to turn out to be Moar's fault because then we can actually do something about it then...
09:38 jnthn stmuk_: I had a hard time seeing where our locking code could be wrong in this instance, alas. I'll dig some more.
09:42 stmuk_ jnthn: if you need a shell accn on FreeBSD (where the prob is more easily reproduced than Linux) give me a shout
09:45 andrzejku some bad things happened during my nqp build
09:45 andrzejku it looks for generated nqp's files but they weren't copied to expected path
09:46 andrzejku I should do cp ./lib/MAST/* ./share/nqp/lib/MAST/
09:47 andrzejku and it looks there no --backend prefix anymore
09:48 timotimo at the moment all our parts still expect everything to be installed with the same --prefix
09:48 timotimo mst has a few patches in the works to make it properly separate the three things
09:48 stmuk_ timotimo: I think mst has his own patches to fix that .. see the YAPC::EU talk
09:49 stmuk_ snap :)
09:49 timotimo i discussed it with him on irc, too :)
09:49 timotimo really looking forward to getting his cleanups for the build system mainlined
09:49 andrzejku also one test failed t/moar/05-decoder.t .................... Lookup by name of unknown REPR: Decoder
09:50 timotimo that probably means your moarvm is too old for this nqp
09:50 timotimo though that makes me wonder why it'd go through Configure.pl without complaining about the version
09:50 andrzejku no it is not the last commit were Date:   Wed Sep 28 14:40:39 2016 +0200
09:51 andrzejku by Johathan
09:51 timotimo well, that's strange
09:52 timotimo what does ls src/6model/reprs/Decoder.* give you in the moarvm checkout?
09:52 timotimo .c, .h, and .o?
09:52 andrzejku yeah
09:53 andrzejku exactly
09:53 timotimo the only thing i could imagine is that you have more than one moarvm in your system and for some reason the "make test" is using the wrong one
09:53 jnthn stmuk_: Will do, thanks. There's a few more things I can try locally first.
09:53 andrzejku timotimo, yeah it is possible
09:55 timotimo cat ./nqp-m in your nqp, it'll tell you the path it's using for the moar binary; and also check out cat (which nqp-m) to see what it's actually using from your path?
09:56 andrzejku the path is proper
09:57 andrzejku wait I will check something
09:58 andrzejku ok it runs command
09:58 andrzejku prove -r --exec "./nqp-m" t/nqp t/hll t/qregex t/p5regex t/qast t/moar t/serialization t/nativecall
09:59 andrzejku and the file got proper path
10:00 timotimo if you have the newest moarvm code, and you've built and installed it successfully, i don't see how it could complain about the Decode repr missing :|
10:00 andrzejku timotimo, wait let me check it manually x)
10:01 timotimo unless you've got a nqp-j that it's running and for some reason it runs the moar tests by accident
10:01 timotimo which would be quite astounding
10:11 andrzejku timotimo, hey what's nqp.moarvm?
10:13 brrt1 it's the executable bytecode for the NQP compiler
10:13 timotimo well, it's just the "main" file
10:15 andrzejku and this? --target=mbc --output=NQPP5QRegex.moarvm gen/moar/stage2/NQPP5QRegex.nqp
10:15 timotimo that's our support for perl5 regexes
10:15 timotimo (non-complete support)
10:19 andrzejku moar nqp.moarvm
10:19 andrzejku should be the same as perl6 interpreter
10:19 andrzejku yeah?
10:21 brrt no.
10:21 brrt but it's complicated :-)
10:22 andrzejku brrt, maybe on another hand what I am trying to do ;D
10:22 timotimo well, nqp isn't perl6 for starts
10:22 andrzejku I want to run decoder test
10:22 andrzejku using moar
10:23 timotimo moar nqp.moarvm blah blah should be the same as nqp-m blah blah
10:23 andrzejku yeah I know
10:24 andrzejku brb
11:42 andrzejku joined #moarvm
12:07 andrzejku joined #moarvm
12:46 andrzejku joined #moarvm
13:15 andrzejku joined #moarvm
13:55 andrzejku joined #moarvm
14:12 andrzejku joined #moarvm
14:53 diakopter joined #moarvm
14:54 nwc10 joined #moarvm
15:47 brrt joined #moarvm
16:08 domidumont joined #moarvm
16:19 timotimo jnthn: would it make any sense to give the fixed size alloc one lock per size class instead of a global lock?
16:20 jnthn Not sure...I think they'd still contend heavily
16:20 jnthn On promoted frames, for example
16:21 timotimo i know that when i tried to multithread my cellular automaton i got a very big amount of overhead for invocation, i believe
16:22 jnthn What we really want is to introduce thread-local pages and a scheme for handing them back to the global one if they empty
16:22 timotimo ah
16:22 timotimo that'd be nice, yeah
16:23 timotimo otherwise i was considering committing epic tight-cohesion sin by building a "lock the allocator for allocating *two* things" function
16:23 timotimo because right now we're doing lock+unlock+lock+unlock when we allocate the environment + the frame
16:23 jnthn *nod*
16:24 timotimo i'm not sure if it's likely that something snatches the lock in between those two operations from another thread
16:24 timotimo and i don't know how costly exactly it is to unlock and immediately lock again; like, is there a memory fence involved?
16:24 jnthn For locking surely yes
16:24 timotimo probably not; there might even be HLE (that doesn't crash)
16:27 timotimo ok, for locking. so it could be worthwhile to have either a allocate-two-things-please, or maybe a separate "lock", "allocate", "unlock" functions
16:27 jnthn Sure, but it'd be better still to fix up the thread local thing :)
16:27 timotimo but in the long run, thread-local pages sounds like a necessity
17:34 andrzejku joined #moarvm
17:44 FROGGS joined #moarvm
19:10 Ven_ joined #moarvm
20:25 Ven_ joined #moarvm
20:46 Ven_ joined #moarvm
20:55 Util joined #moarvm
21:01 Ven_ joined #moarvm

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