01:23 TimToady joined 01:46 TimToady joined 02:41 MasterDuke joined
Geth MoarVM/collation-arrays: 4 commits pushed by (Samantha McVey)++ 02:57
samcv \o/ my rewrite of the collation stuff now finally passes all of my tests that the old one passed 03:30
gotta find my testing for unicode's own tests, but making good progress
though it will fail if the strings are over 100cp's long but. aside from that lol 03:35
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:37
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
Add back in support for configurable sort
MoarVM/collation-arrays: 27ff30efd4 | (Samantha McVey)++ | src/strings/unicode_ops.c
Remove the old algorithm now that the new one is passing
04:14 TimToady joined 05:33 domidumont joined 05:39 domidumont joined 05:44 TimToady joined 05:51 TimToady_ joined 06:05 domidumont joined 06:09 brrt joined
brrt good * 06:17
nice progess samcv! 06:18
samcv thanks
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:19
and make sure i have things working in decent way 06:20
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
one key per codepoint
06:23 TimToady joined
brrt has found a GC bug in the nativecall tests 06:35
:'-( i still get GC failure for sp_fastcreate 06:48
samcv what's sp_fastcreate do? 06:53
brrt sp_fastcreate is a specialized op for initializing an object 06:54
normal objects can override creation
(normal REPR's)
specialized objects cannot, hence they're faster
well, i'm saying that all wrong
we can sometimes specialiaze object creation so that the creation process is nonpolymorphic and faster 06:55
samcv ah ok 06:56
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
07:11 brrt joined
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:12
brrt which checks are we discussing? 07:14
nine brrt: gist.github.com/jnthn/95d0705d225e...faa337624b "Cannot strip out type checks on various internal calls" 07:15
brrt: I was arguing that stripping those checks would be much easier if they were separate ops
brrt aye 07:20
but 07:21
you quickly walk into what i call the 'm0' problem
m0 was an attempt to rewrite parrot in an 'assembly language' which has much the same strengths as the expr node language
the point being that it's really difficult to choose the 'correct' level of opcode abstraction 07:22
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
the way i see that tradeoff is:
suppose you did make a JIT backend based on LLVM 07:25
because LLVM represents the world in such a low-level way, you have to expand the code from MoarVM instructions to LLVM IR
this LLVM 'IR' has the same information content as the original code 07:26
but it's much bigger, making a lower information density
typically, it gets exponentially harder to extract information from a lower density to a higher density
more patterns to match, more preconditions to check, etc 07:27
(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:28
ehm.. with all that out of the way 07:29
yes, i agree :-P
and it is probably the way to go to do exactly this
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?)
but yes, compiler work is fun
07:34 TimToady joined
nine brrt: it's the one I wrote for my master thesis: niner.name/DTML_Compiler.pdf 07:35
brrt ah, that's interesting...
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...
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
maybe not such a language
(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.
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:41
07:53 zakharyas joined
brrt i'm going to need new theories for my sp_fastcreate fromspace bug 07:56
possible theory #1 - we still don't collect the values because we mistakingly do not mark them as object
08:03 TimToady joined 08:20 TimToady joined
jnthn morning, #moarvm 08:49
nine Good morning, jnthn! 08:51
08:51 TimToady joined
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
jnthn That's the way to SEGVs and exploits 08:52
But yeah, we do need a general scheme for this so there's a consistent way to separate out the validation and the operation
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:53
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. 08:57
jnthn Perhaps so, but that's perhaps over-thinking it 09:01
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
And then spesh just sees if it already can prove that it has those arguments 09:02
And then call the thing directly
09:06 TimToady joined
nine Ah, yes, in this case a specialized solution surely trumps the generic one as spesh already deals with type checks. 09:12
09:17 TimToady joined 09:29 TimToady joined
jnthn finally gets chance to properly read/understand arxiv.org/pdf/1411.0352v2.pdf 09:38
nine </win 10 09:48
09:56 TimToady joined 10:05 colomon joined
Geth MoarVM: f0a0983ad1 | (Jonathan Worthington)++ | 6 files
Remove/deprecate sync process related ops.

All process-related operations should now we done with the async API instead.		 10:10
MoarVM: 6a44e30a45 | (Jonathan Worthington)++ | 2 files
Remove sync process implementation.
 10:20
MoarVM: 14dcd12279 | (Jonathan Worthington)++ | 6 files
Remove now-unused syncpipe/syncstream.
10:21 TimToady joined
jnthn And with that, github.com/MoarVM/MoarVM/issues/165 is closed \o/ 10:27
lizmat whee! 10:33
jnthn And MoarVM is quite some lines of code lighter. :)
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 ?
jnthn lizmat: Pretty much, yeah. Much like we do for accessors 10:35
There's already infrastructure for such things
10:41 AlexDaniel joined
dogbert17 possibly stupid question: 10:58
I'm running perl 6 on a Linux vm which means that the following works: 'my $fh = open('~/scratch.pl6')' 10:59
but this fails
no I mean that the above does NOT work while this does work: my $fh = open('/home/dogbert/scratch.pl6'); 11:00
11:01 brrt joined
dogbert17 sorry for the messup, question is should the tilde shortcut for the home directory work on 'open' ? 11:01
ww, sorry 11:02
11:11 ggoebel joined
timotimo automatic "expanduser" for open()? 11:16
11:18 TimToady joined 11:31 brrt joined
AlexDaniel dogbert17: I think it works 12:02
dogbert17: if you have a ‘~’ directory and ‘scratch.pl6’ file in it, it should open just fine
yea, just tested it, works just fine :) 12:03
dogbert17: now, you're expecting your path to go through shell, which is not the case 12:04
… and it would have been horrible if it did…
dogbert17: I guess you want to use %*ENV<HOME> 12:05
m: say %*ENV<HOME>
camelia /home/camelia
AlexDaniel like, “{%*ENV<HOME>}/scratch.pl6”
m: say “%*ENV<HOME>/scratch.pl6” 12:06
camelia /home/camelia/scratch.pl6
AlexDaniel oh, don't even need {} :)
12:10 brrt joined 12:11 domidumont joined
lizmat m: say $*HOME 12:15
camelia "/home/camelia".IO
lizmat AlexDaniel: even shorter :-) ^^^
12:20 TimToady joined
AlexDaniel lizmat: … right :) 12:45
12:46 domidumont joined 12:49 TimToady joined, ZofBot joined 13:12 TimToady joined
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.
jnthn brrt: Disableable in what way? 13:42
yoleaux 13:41Z <brrt> jnthn: i would highly appreciate a potential 'multithreaded' spesh to be…. disableable
jnthn I mean, MVM_SPESH_DISABLE=1 will stay
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:43
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
brrt i.e. if the JIT crashes, it crashes in the same way virtually always
indeed
that's not going to be true if there is a separate spesh thread 13:45
jnthn Indeed.
Though we can likely introduce a mode where we block running until the specialization thread comes back with the answer 13:46
That'll help for the baseline spesh/JIT
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
(Provided we add a "make the thread wait" mechanism) 13:47
lizmat jnthn: I think a generic "make a thread wait" mechanism would be very useful 13:48
jnthn lizmat: In what sense?
I mean, in the most general sense that's a condition variable
lizmat e.g. when you notice you need backpressure in another thread? 13:49
brrt well, that'd work
could be a compile-time flag for me as well
jnthn Yeah, not sure off hand where the cost will be
lizmat: If we got bounded channels then we'd have a higher level way to do that :) 13:50
Actually that already exists in module space, but we should probably do it in core 13:52
14:04 TimToady joined
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:26
We'll add an nqp::permit(async-task-handle, channel, permits) op 14:27
Where permits is -1 to mean "a reader that never stops", 10 means "can emit 10 things", etc. 14:28
And channel allows us to not have to epicly refactor proc stuff; we can use it to signifiy stdout vs stderr
This same mechanism can then work across socket accepts and socket reads in the future also 14:29
14:50 TimToady joined
Geth MoarVM: 3111b0d325 | (Jonathan Worthington)++ | 8 files
Stub in new async task permit op.

This will be used to provide a back-pressure mechanism as well as to delay the starting of readers.		 14:56
MoarVM: 2a79727deb | (Jonathan Worthington)++ | 7 files
Add permit operation to async task vtable.
 15:05
15:10 brrt joined 15:22 Ven joined 15:27 TimToady joined
Geth MoarVM: 6667bc0a1a | (Jonathan Worthington)++ | 2 files
Implement the permit op.

Now "all" that's needed is for async operations themselves to pay some attention to it.		 15:38
jnthn And I'll do that "all" next week, I think :)
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:39
15:40 TimToady joined
brrt …. 15:43
*drumrolls....*
jnthn wonders what the drum roll was for... :) 15:45
brrt well, i have gotten a little bit further with sp_fastcreate... 15:46
but now it seems as if i'm looping forever somehow
Geth MoarVM/even-moar-jit: 384e4d21c3 | (Bart Wiegmans)++ | src/gc/roots.c
spesh cand may not have local types while jitcode has

We'd ignore the jitcode local types if the spesh cand local types weren't defined. This gets us a bit further in compiling NQP with sp_fastcreate.		 15:48
jnthn aha :)
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:52
So I'll need a way to get a hold of htat 15:53
*that
Will figure that out on Monday :) 15:54
o/
15:56 TimToady joined 16:12 Ven_ joined 16:21 hoelzro joined 16:40 TimToady joined 17:23 domidumont joined 17:38 TimToady joined 17:42 Ven joined 18:01 TimToady joined
timotimo will we get a way to put more file descriptors into a proc::async than just stdin, stdout, and stderr? 18:05
18:07 TimToady joined 19:24 colomon_ joined 19:31 hoelzro joined 20:03 AlexDaniel joined 20:32 domidumont joined 20:46 lizmat_ joined 22:01 lizmat joined 22:02 lizmat 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!