Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-06-23

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

All times shown according to UTC.

Time Nick Message
01:23 TimToady joined #moarvm
01:46 TimToady joined #moarvm
02:41 MasterDuke joined #moarvm
02:57 Geth ¦ MoarVM/collation-arrays: 4 commits pushed by (Samantha McVey)++
02:57 Geth ¦ MoarVM/collation-arrays: cda3939662 | Initial work toward having proper collation arrays
02:57 Geth ¦ MoarVM/collation-arrays: f1ec193db6 | Get primary always checking before secondary
02:57 Geth ¦ MoarVM/collation-arrays: cd03476aaa | Get them pushing onto the stack for the whole length
02:57 Geth ¦ MoarVM/collation-arrays: ba70c37f82 | Fix the order of checking and grabbing codepoints
02:57 Geth ¦ MoarVM/collation-arrays: review: https://github.com/MoarVM/MoarVM/compare/0000000000...ba70c37f82
03:30 samcv \o/ my rewrite of the collation stuff now finally passes all of my tests that the old one passed
03:30 samcv gotta find my testing for unicode's own tests, but making good progress
03:35 samcv though it will fail if the strings are over 100cp's long but. aside from that lol
03:37 samcv to fix that i'm probably going to figure out the longest length of a series of codpoints with a special collation elements, then go to the point the two strings differ minus the longest special sequence
03:38 samcv as there's no point to store all the collation values on the collation stack, only where the strings differ
03:38 Geth ¦ MoarVM/collation-arrays: cda30444a2 | (Samantha McVey)++ | src/strings/unicode_ops.c
03:38 Geth ¦ MoarVM/collation-arrays: Add back in support for configurable sort
03:38 Geth ¦ MoarVM/collation-arrays: review: https://github.com/MoarVM/MoarVM/commit/cda30444a2
03:38 Geth ¦ MoarVM/collation-arrays: 27ff30efd4 | (Samantha McVey)++ | src/strings/unicode_ops.c
03:38 Geth ¦ MoarVM/collation-arrays: Remove the old algorithm now that the new one is passing
03:38 Geth ¦ MoarVM/collation-arrays: review: https://github.com/MoarVM/MoarVM/commit/27ff30efd4
04:14 TimToady joined #moarvm
05:33 domidumont joined #moarvm
05:39 domidumont joined #moarvm
05:44 TimToady joined #moarvm
05:51 TimToady_ joined #moarvm
06:05 domidumont joined #moarvm
06:09 brrt joined #moarvm
06:17 brrt good *
06:18 brrt nice progess samcv!
06:18 samcv thanks
06:19 samcv once this is polished up a bit then will work more on the data structure to hold the specialized collation data. but i basically specialcased æ and Æ so i can play around. which is working pretty well
06:20 samcv and make sure i have things working in decent way
06:20 samcv er specialcased just in that they push multiple arrays onto the stack. since the data isn't in our unicode database. and otherwise it just pushes single keys onto the stack for all the other letters, since that's the extent of our support atm
06:20 samcv one key per codepoint
06:23 TimToady joined #moarvm
06:35 * brrt has found a GC bug in the nativecall tests
06:48 brrt :'-( i still get GC failure for sp_fastcreate
06:53 samcv what's sp_fastcreate do?
06:54 brrt sp_fastcreate is a specialized op for initializing an object
06:54 brrt normal objects can override creation
06:54 brrt (normal REPR's)
06:54 brrt specialized objects cannot, hence they're faster
06:54 brrt well, i'm saying that all wrong
06:55 brrt we can sometimes specialiaze object creation so that the creation process is nonpolymorphic and faster
06:56 samcv ah ok
07:11 nine jnthn: regarding "Cannot strip out type checks on various internal calls", that sounds as if it were almost trivial if the type checks were separate ops. Then superfluous ops could be stripped even by the static optimizer.
07:11 brrt joined #moarvm
07:12 nine With the checks being part of the work ops, I guess only the JIT even has a chance of removing them. And only with much further work.
07:14 brrt which checks are we discussing?
07:15 nine brrt: https://gist.github.com/jnthn/95d0705d225ebfbad5dee0faa337624b "Cannot strip out type checks on various internal calls"
07:15 nine brrt: I was arguing that stripping those checks would be much easier if they were separate ops
07:20 brrt aye
07:21 brrt but
07:21 brrt you quickly walk into what i call the 'm0' problem
07:21 brrt m0 was an attempt to rewrite parrot in an 'assembly language' which has much the same strengths as the expr node language
07:22 brrt the point being that it's really difficult to choose the 'correct' level of opcode abstraction
07:24 brrt because not only have you the familiar problem of instructions-per-opcode * number-of-opcodes, you also have the problem of …. 'assertion strength per opcode', if that idea makes any sense
07:24 brrt the way i see that tradeoff is:
07:25 brrt suppose you did make a JIT backend based on LLVM
07:25 brrt because LLVM represents the world in such a low-level way, you have to expand the code from MoarVM instructions to LLVM IR
07:26 brrt this LLVM 'IR' has the same information content as the original code
07:26 brrt but it's much bigger, making a lower information density
07:26 brrt typically, it gets exponentially harder to extract information from a lower density to a higher density
07:27 brrt more patterns to match, more preconditions to check, etc
07:28 brrt (the expr jit tries to avoid this problem by A): doing the more information-heavy optimizations before we ever reach it, B): tieing pretty strongly to MoarVM internal structure and using its assumptions, C): optimizing for a small language with relatively strong contracts per action)
07:29 brrt ehm.. with all that out of the way
07:29 brrt yes, i agree :-P
07:29 brrt and it is probably the way to go to do exactly this
07:33 nine It's funny how at work I spent two days this week alone improving our compiler and it's the most fun I've ever had coding, yet I do so very little of that in rakudo.
07:33 brrt (which compiler is that?)
07:33 brrt but yes, compiler work is fun
07:34 TimToady joined #moarvm
07:35 nine brrt: it's the one I wrote for my master thesis: http://niner.name/DTML_Compiler.pdf
07:35 brrt ah, that's interesting...
07:36 nine It's the one taking code in a fugly "language" written by non-programmers and trying to generate decently performing Perl from it.
07:36 brrt huh, i've been arguing for something like that for some time here...
07:38 nine A language that makes PHP3 code looking maintainable ("what, you didn't memorize the 37 steps to determine what the hell this name in the code refers to?", "why specify the object a method is called on when you can have an invisible context object"?)
07:38 brrt o.O
07:38 brrt maybe not such a language
07:40 brrt (the (in)famous whipuptitude of perl… <3)
07:40 nine So "foo()" could be calling a Python builtin with that name, a script lieing in the website's root folder, a call to a website template, a call to an anonymous sub stored in a lexical, or a dynamic variable (they are the same thing anyway), or a sub stored in the REQUEST object or a method call on the context object.
07:41 nine And those are only the cases where it will actually succeed. "foo" could refer to a couple of more things that would end up in a "this thing is not callable" error message...
07:53 zakharyas joined #moarvm
07:56 brrt i'm going to need new theories for my sp_fastcreate fromspace bug
07:56 brrt possible theory #1 - we still don't collect the values because we mistakingly do not mark them as object
08:03 TimToady joined #moarvm
08:20 TimToady joined #moarvm
08:49 jnthn morning, #moarvm
08:51 nine Good morning, jnthn!
08:51 TimToady joined #moarvm
08:51 jnthn nine: You can't have a static optimizer outside of MoarVM stripping out safety checks that are there for the VM's memory safety
08:51 brrt morning, jnthn
08:52 jnthn That's the way to SEGVs and exploits
08:52 jnthn But yeah, we do need a general scheme for this so there's a consistent way to separate out the validation and the operation
08:53 jnthn That point was talking purely about the validation the VM does to make sure it's been given an appropriate thing when we call down to I/O or other such VM-provided services
08:57 nine Maybe we need µops that ops are made of. Something invisible to MoarVM's users but handy for manipulation by spesh and the JIT.
09:01 jnthn Perhaps so, but that's perhaps over-thinking it
09:01 jnthn All we really need is a mechanism for saying what types arguments passed to a function should be and having them checked, then calling the function
09:02 jnthn And then spesh just sees if it already can prove that it has those arguments
09:02 jnthn And then call the thing directly
09:06 TimToady joined #moarvm
09:12 nine Ah, yes, in this case a specialized solution surely trumps the generic one as spesh already deals with type checks.
09:17 TimToady joined #moarvm
09:29 TimToady joined #moarvm
09:38 * jnthn finally gets chance to properly read/understand https://arxiv.org/pdf/1411.0352v2.pdf
09:48 nine </win 10
09:56 TimToady joined #moarvm
10:05 colomon joined #moarvm
10:10 Geth ¦ MoarVM: f0a0983ad1 | (Jonathan Worthington)++ | 6 files
10:10 Geth ¦ MoarVM: Remove/deprecate sync process related ops.
10:10 Geth ¦ MoarVM:
10:10 Geth ¦ MoarVM: All process-related operations should now we done with the async API
10:10 Geth ¦ MoarVM: instead.
10:10 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f0a0983ad1
10:20 Geth ¦ MoarVM: 6a44e30a45 | (Jonathan Worthington)++ | 2 files
10:20 Geth ¦ MoarVM: Remove sync process implementation.
10:20 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6a44e30a45
10:20 Geth ¦ MoarVM: 14dcd12279 | (Jonathan Worthington)++ | 6 files
10:20 Geth ¦ MoarVM: Remove now-unused syncpipe/syncstream.
10:20 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/14dcd12279
10:21 TimToady joined #moarvm
10:27 jnthn And with that, https://github.com/MoarVM/MoarVM/issues/165 is closed \o/
10:33 lizmat whee!
10:33 jnthn And MoarVM is quite some lines of code lighter. :)
10:34 timotimo it's simpler than type checks, even; we only need to check some REPR IDs, i imagine we could just put some info into the oplist for that
10:34 lizmat jnthn: re object initialization: is the idea to basically generate a code block that will get run on object creation ?
10:35 jnthn lizmat: Pretty much, yeah. Much like we do for accessors
10:35 jnthn There's already infrastructure for such things
10:41 AlexDaniel joined #moarvm
10:58 dogbert17 possibly stupid question:
10:59 dogbert17 I'm running perl 6 on a Linux vm which means that the following works: 'my $fh = open('~/scratch.pl6')'
10:59 dogbert17 but this fails
11:00 dogbert17 no I mean that the above does NOT work while this does work: my $fh = open('/home/dogbert/scratch.pl6');
11:01 brrt joined #moarvm
11:01 dogbert17 sorry for the messup, question is should the tilde shortcut for the home directory work on 'open' ?
11:02 dogbert17 ww, sorry
11:11 ggoebel joined #moarvm
11:16 timotimo automatic "expanduser" for open()?
11:18 TimToady joined #moarvm
11:31 brrt joined #moarvm
12:02 AlexDaniel dogbert17: I think it works
12:02 AlexDaniel dogbert17: if you have a ‘~’ directory and ‘scratch.pl6’ file in it, it should open just fine
12:03 AlexDaniel yea, just tested it, works just fine :)
12:04 AlexDaniel dogbert17: now, you're expecting your path to go through shell, which is not the case
12:04 AlexDaniel … and it would have been horrible if it did…
12:05 AlexDaniel dogbert17: I guess you want to use %*ENV<HOME>
12:05 AlexDaniel m: say %*ENV<HOME>
12:05 camelia rakudo-moar a13bad: OUTPUT: «/home/camelia␤»
12:05 AlexDaniel like, “{%*ENV<HOME>}/scratch.pl6”
12:06 AlexDaniel m: say “%*ENV<HOME>/scratch.pl6”
12:06 camelia rakudo-moar a13bad: OUTPUT: «/home/camelia/scratch.pl6␤»
12:06 AlexDaniel oh, don't even need {} :)
12:10 brrt joined #moarvm
12:11 domidumont joined #moarvm
12:15 lizmat m: say $*HOME
12:15 camelia rakudo-moar 4a37de: OUTPUT: «"/home/camelia".IO␤»
12:15 lizmat AlexDaniel: even shorter  :-)   ^^^
12:20 TimToady joined #moarvm
12:45 AlexDaniel lizmat: … right :)
12:46 domidumont joined #moarvm
12:49 TimToady joined #moarvm
12:49 ZofBot joined #moarvm
13:12 TimToady joined #moarvm
13:41 brrt .tell jnthn i would highly appreciate a potential 'multithreaded' spesh to be…. disableable
13:41 yoleaux brrt: I'll pass your message to jnthn.
13:42 jnthn brrt: Disableable in what way?
13:42 yoleaux 13:41Z <brrt> jnthn: i would highly appreciate a potential 'multithreaded' spesh to be…. disableable
13:42 jnthn I mean, MVM_SPESH_DISABLE=1 will stay
13:43 jnthn Also it's not so much that spesh itself will be multi-threaded, so much as it will have a single thread that does specialization work rather than impacting a running thread
13:44 brrt well, currently spesh is completely deterministic, and that's super handy for debugging
13:44 jnthn Oh, you mean when the specializations become available
13:44 brrt i.e. if the JIT crashes, it crashes in the same way virtually always
13:44 brrt indeed
13:45 brrt that's not going to be true if there is a separate spesh thread
13:45 jnthn Indeed.
13:46 jnthn Though we can likely introduce a mode where we block running until the specialization thread comes back with the answer
13:46 jnthn That'll help for the baseline spesh/JIT
13:46 jnthn In fact, for that we'll probably be in a better situation than today as we'll likely make the threshold for baseline compilation quite low
13:47 jnthn (Provided we add a "make the thread wait" mechanism)
13:48 lizmat jnthn: I think a generic "make a thread wait" mechanism would be very useful
13:48 jnthn lizmat: In what sense?
13:48 jnthn I mean, in the most general sense that's a condition variable
13:49 lizmat e.g. when you notice you need backpressure in another thread?
13:49 brrt well, that'd work
13:49 brrt could be a compile-time flag for me as well
13:49 jnthn Yeah, not sure off hand where the cost will be
13:50 jnthn lizmat: If we got bounded channels then we'd have a higher level way to do that :)
13:52 jnthn Actually that already exists in module space, but we should probably do it in core
14:04 TimToady joined #moarvm
14:26 jnthn Having been through loads of ways to do the permits thing with a dozen different things we could change and re-work I think I've found a way that doesn't need any significant rework of existing things :-)
14:27 jnthn We'll add an nqp::permit(async-task-handle, channel, permits) op
14:28 jnthn Where permits is -1 to mean "a reader that never stops", 10 means "can emit 10 things", etc.
14:28 jnthn And channel allows us to not have to epicly refactor proc stuff; we can use it to signifiy stdout vs stderr
14:29 jnthn This same mechanism can then work across socket accepts and socket reads in the future also
14:50 TimToady joined #moarvm
14:56 Geth ¦ MoarVM: 3111b0d325 | (Jonathan Worthington)++ | 8 files
14:56 Geth ¦ MoarVM: Stub in new async task permit op.
14:56 Geth ¦ MoarVM:
14:56 Geth ¦ MoarVM: This will be used to provide a back-pressure mechanism as well as
14:56 Geth ¦ MoarVM: to delay the starting of readers.
14:56 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3111b0d325
15:05 Geth ¦ MoarVM: 2a79727deb | (Jonathan Worthington)++ | 7 files
15:05 Geth ¦ MoarVM: Add permit operation to async task vtable.
15:05 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2a79727deb
15:10 brrt joined #moarvm
15:22 Ven joined #moarvm
15:27 TimToady joined #moarvm
15:38 Geth ¦ MoarVM: 6667bc0a1a | (Jonathan Worthington)++ | 2 files
15:38 Geth ¦ MoarVM: Implement the permit op.
15:38 Geth ¦ MoarVM:
15:38 Geth ¦ MoarVM: Now "all" that's needed is for async operations themselves to pay some
15:38 Geth ¦ MoarVM: attention to it.
15:38 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6667bc0a1a
15:38 jnthn And I'll do that "all" next week, I think :)
15:39 jnthn But of an unexpected twist from the problem I set out to solve, but guess it's nice I'm ending up building a much more general mechanism that solves something I knew we'd have to at some point in the future also :)
15:40 TimToady joined #moarvm
15:43 brrt ….
15:43 brrt *drumrolls....*
15:45 * jnthn wonders what the drum roll was for... :)
15:46 brrt well, i have gotten a little bit further with sp_fastcreate...
15:46 brrt but now it seems as if i'm looping forever somehow
15:48 Geth ¦ MoarVM/even-moar-jit: 384e4d21c3 | (Bart Wiegmans)++ | src/gc/roots.c
15:48 Geth ¦ MoarVM/even-moar-jit: spesh cand may not have local types while jitcode has
15:48 Geth ¦ MoarVM/even-moar-jit:
15:48 Geth ¦ MoarVM/even-moar-jit: We'd ignore the jitcode local types if the spesh cand local
15:48 Geth ¦ MoarVM/even-moar-jit: types weren't defined. This gets us a bit further in compiling NQP
15:48 Geth ¦ MoarVM/even-moar-jit: with sp_fastcreate.
15:48 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/384e4d21c3
15:48 jnthn aha :)
15:52 jnthn Aww, though just realized that spawnprocasync returns an MVMOSHandle, not the AsyncTask that it also creates, which it seems vanishes off into the ether
15:53 jnthn So I'll need a way to get a hold of htat
15:53 jnthn *that
15:54 jnthn Will figure that out on Monday :)
15:54 jnthn o/
15:56 TimToady joined #moarvm
16:12 Ven_ joined #moarvm
16:21 hoelzro joined #moarvm
16:40 TimToady joined #moarvm
17:23 domidumont joined #moarvm
17:38 TimToady joined #moarvm
17:42 Ven joined #moarvm
18:01 TimToady joined #moarvm
18:05 timotimo will we get a way to put more file descriptors into a proc::async than just stdin, stdout, and stderr?
18:07 TimToady joined #moarvm
19:24 colomon_ joined #moarvm
19:31 hoelzro joined #moarvm
20:03 AlexDaniel joined #moarvm
20:32 domidumont joined #moarvm
20:46 lizmat_ joined #moarvm
22:01 lizmat joined #moarvm
22:02 lizmat joined #moarvm

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