github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke .tell samcv src/strings/decode_stream.c: In function ‘run_decode’: src/strings/decode_stream.c:142:27: warning: implicit declaration of function ‘MVM_string_utf16_decodestream’; did you mean ‘MVM_string_utf8_decodestream’? [-Wimplicit-function-declaration] reached_stopper = MVM_string_utf16_decodestream(tc, ds, stopper_chars, sep_spec, eof); 00:04
yoleaux MasterDuke: I'll pass your message to samcv.
samcv MasterDuke: ah that looks like a thing 00:12
yoleaux 00:04Z <MasterDuke> samcv: src/strings/decode_stream.c: In function ‘run_decode’: src/strings/decode_stream.c:142:27: warning: implicit declaration of function ‘MVM_string_utf16_decodestream’; did you mean ‘MVM_string_utf8_decodestream’? [-Wimplicit-function-declaration] reached_stopper = MVM_string_utf16_decodestream(tc, ds, stopper_chars, sep_spec, eof);
00:13 Kaiepi joined 00:14 p6bannerbot sets mode: +v Kaiepi 00:17 lizmat left
Geth MoarVM: ff0fb63a46 | (Samantha McVey)++ | 2 files
Make sure utf16 decodestream is declared in the header file

Fixes compiler warnings about the function not being predeclared.		 00:29
MasterDuke samcv++ 00:31
samcv and i probably need to check for endianess issues on deing $fh.write: for a 16 bit buffer 00:34
though i need to add specified endianess to decodestream and decode too. so i'll probably do it together with that. since we don't support specific endianess utf16 so i think that's in line with what we have other places atm 00:35
01:11 sulvone11 joined 01:14 MasterDuke left 01:16 sulvone11 left 01:32 v45h11 joined 01:33 v45h11 left 02:01 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 02:02 Kaiepi left, Kaiepi joined 02:03 p6bannerbot sets mode: +v Kaiepi 02:48 MasterDuke left 03:10 harrow joined 03:11 p6bannerbot sets mode: +v harrow 03:32 btorch_2 joined 03:33 btorch_2 left 04:02 AlexDani` joined, p6bannerbot sets mode: +v AlexDani` 05:06 pakettiale28 joined 05:11 pakettiale28 left 05:43 bertvdlingen26 joined 05:44 bertvdlingen26 left 05:48 asalor15 joined 05:53 asalor15 left 06:16 icedev21 joined 06:20 icedev21 left 06:23 robertle joined 06:24 p6bannerbot sets mode: +v robertle 07:03 rito29 joined 07:08 rito29 left 08:01 lizmat joined 08:02 p6bannerbot sets mode: +v lizmat 09:00 sc11tr23 joined 09:09 sc11tr23 left 09:46 rodgort8 joined 09:47 Kaiepi left 09:50 Kaiepi joined 09:51 p6bannerbot sets mode: +v Kaiepi 09:52 Kaiepi left 09:53 Kaiepi joined, rodgort8 left, p6bannerbot sets mode: +v Kaiepi 10:17 rdk31 joined 10:18 rdk31 left, sigtau2 joined 10:19 sigtau2 left 10:26 Kaiepi left 10:27 Kaiepi joined 10:28 p6bannerbot sets mode: +v Kaiepi 10:29 Kaiepi left 10:32 Kaiepi joined, bazz0 joined 10:33 p6bannerbot sets mode: +v Kaiepi 10:36 bazz0 left 10:48 Kaiepi left 10:52 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 10:55 brucebag6 joined 10:56 AlexDani` is now known as AlexDaniel 10:58 brucebag6 left
Geth MoarVM/fork-safety: 2587d1bc40 | (Bart Wiegmans)++ | 16 files
[fork] Implement fork() opcode

Stop system threads before fork(), to ensure that the child process is not left with a corrupt heap. Windows will report as fork-not-supported and the process will shortcircuit there.
Some final modifications necessary:
  - let MVM_thread_cleanup_thread_list count the number of alive threads
  - let MVM_io_eventloop_start handle restarts gracefully
  - let MVM_io_eventloop_destroy handle partial stops gracefully		 11:13
11:21 lizmat left 11:24 lizmat joined 11:25 p6bannerbot sets mode: +v lizmat 11:28 Kaiepi left 11:32 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi
nine almost.....there 12:04
12:18 Kaiepi left 12:21 Kaiepi joined 12:22 p6bannerbot sets mode: +v Kaiepi 12:38 Kaiepi left 12:42 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 12:50 ekneuss12 joined 12:56 ekneuss12 left 13:01 BiW29 joined 13:02 BiW29 left 13:15 zakharyas joined 13:16 p6bannerbot sets mode: +v zakharyas 13:22 Kaiepi left, Kaiepi joined 13:23 p6bannerbot sets mode: +v Kaiepi 13:29 crest18 joined 13:30 crest18 left 13:49 p6bannerbot joined, ChanServ sets mode: +o p6bannerbot 14:12 AngelDeath joined 14:16 AngelDeath left, okraits20 joined 14:21 okraits20 left 15:04 zakharyas left 15:12 zakharyas joined, p6bannerbot sets mode: +v zakharyas 16:04 zakharyas left 16:15 zakharyas joined 16:16 p6bannerbot sets mode: +v zakharyas 16:32 r4vi9 joined 16:39 r4vi9 left 17:20 domidumont joined, MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 17:21 p6bannerbot sets mode: +v domidumont 17:35 zakharyas left 17:42 bo_ joined 17:48 bo_ left 18:07 domidumont left 18:43 cryptk7 joined 18:48 cryptk7 left
nine And it runs! 19:11
jnthn :) 19:12
So much nice stuff going on. :) 19:13
jnthn is looking forward to digging back in this week :)
nine Who'd have thought that the const_i64 -> const_64_16 optimization was essential?
And indeed it compiles and runs a note("hello world") :) 19:15
jnthn Essential? :) 19:16
jnthn didn't know that either
nine Bytecode was kinda broken without that. I got the impression that some upper layer depends on that optimization
jnthn Hmm, that's...odd
nine Or.....oh no! 19:17
Of course it's my own bug :) $!bytecode.write_uint16(nqp::getattr($o, MAST::IVal, '$!value')); # FIXME need to pick int size from op_info
jnthn :D 19:18
jnthn is somewhat relieved :)
nine I even got the infrastructure for fixing that in place since I wrote the comment
Btw the work on reproducible builds now comes in quite handy. Comparing hex dumps is much more fun this way :) 19:22
I guess the next step is plugging this into the compiler backend 19:31
19:35 Kaiepi left, pepesza27 joined 19:36 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 19:40 reportable6 joined
timotimo very nice 19:40
19:40 pepesza27 left
timotimo this way we can even use the debugserver stuff to instrument the compiler, like to mark up every single byte in the resulting file with the line (or maybe a stack) of what wrote it 19:40
19:41 p6bannerbot sets mode: +v reportable6
timotimo i once did something like this where there was a #define for printf that would put a random color based on $?LINE (and $?COL?) along with a title="..." into an HTML formatted document 19:41
instead of the plain text
Geth MoarVM: bdw++ created pull request #967:
Safe fork in MoarVM		 19:53
19:54 brrt joined
nine Meh....seems like there's just no op for loading and running a CompUnit from memory 19:55
19:55 p6bannerbot sets mode: +v brrt
timotimo that sucks, we should fix that. 19:55
should be easy, though
but wait, don't we totally compile compunits in memory and run them immediately? 19:56
oh, that's probably the mast compiler doing that for you
nine That's masttocu
timotimo not an nqp op
yeah, we shall have cufrombytes or whatever
brrt nine++ 19:57
nine Instead of nqp::loadbytecodebuffer it'd be better to have an nqp::cufrombuffer + nqp::runcu
Or just have nqp::loadbytecodebuffer return the CompUnit like nqp::masttocu
brrt this should be easy-ish? :-) 19:58
timotimo i wonder how many different ways to use this there are for our compunit repo infrastructure
19:58 mattg joined
brrt jnthn: note that this (fork()) only started itching when you wrote the 'sister languages' post 20:00
timotimo that post includes a bit about fork not working?
jnthn :-)
brrt yes
how perl5 is closer to POSIX than perl6 is
timotimo tbqh i like having fork safety
brrt well, I guess that is still true
timotimo preforking can still be useful for resource management reasons
brrt it's limited though; It will only work if there are no user threads active
timotimo oh?
20:01 leonjza17 joined
brrt yeah 20:01
timotimo because restoring a stack is hard?
jnthn I think it only sanely *can* work in that case
brrt well, there is that
jnthn Well, there's a caveat to that remark
20:01 mattg left
timotimo so we're basically reproducing the "fork only lets the forking thread survive" semantics 20:01
brrt correct
timotimo but it should be possible to clean the other threads up fully post-fork? 20:02
jnthn timotimo: The patch as it stands throws an exception if there's more than one user thread active
Which I think is sensible
timotimo OK
that's probably a good idea, though with no current API to shut down worker threads in the TPS ...
don't we already get a user thread when we tap a signal for example?
jnthn Yup 20:03
nine brrt++ # awesome work!
jnthn And also if we have to spawn a process to compile a module
brrt I expect it *is* possible to have full thread restore, but that requires another level of hackery that I'm not ready for today
timotimo damn, that's very action-at-a-distance-y
jnthn That's solvable to resolivng what timo said and then making the pre-comp stuff use its own pool
Then we have to consider what happens if the compiler itself were to use threads internally, which is probably desirable at some point too :) 20:04
brrt :-)
nine I'd still much rather pre-comp in the same process. IIRC I've gotten pretty far on that already
timotimo oh, we'll have it in the same process
just with a cleanly separated namespace
that we can just completely tear down with ease
maybe even a complete MVMInstance
jnthn But again, we can probably find a way to deal with that.
brrt note that any of the async stuff will work; so asyncspawn, then fork(), that ought to work
but yeah, a thread pool, that might be difficult.... We probably need to do some HLL logic around that 20:05
jnthn As to supporting it with real userland threads...well...
timotimo i mean, we do offer Thread.join %) 20:06
brrt the perl6 implementation that I'm imagining, will probably have to do something of the sort of $*SCHEDULER.stop(); fork(); $*SCHEDULER.start();
jnthn If we re-invent locks and just use a single per-thread cond var to handle the "efficiently block" part, like the JVM does to back its park() operation, then we could be able to theoretically take some steps further 20:07
But if the thread is in C-land or blocking on I/O and so forth, we're again stuck
timotimo of course, if any thread (worker or otherwise) is blocked, we won't be able to do things right yet
nine well step by step
jnthn And I think that final step is close to unsolvable.
20:08 leonjza17 left
jnthn But 90% solutions are still useful 90% of the time. :) 20:08
timotimo next we implement fork() on windows
jnthn :P
brrt wonders how the linux-subsystem-for-windows does that
timotimo it switches the CPU to no-interrupts-mode for a few seconds :P 20:09
20:14 Guest51271 joined 20:15 Guest51271 left
AlexDaniel btw these moar changes can go right in because we're still in pretoasted state 20:15
or so I think
brrt cool 20:16
AlexDaniel and also my bisect logic for toaster almost works, so we'll likely get all the answers right away without needing to wait for me to bisect semimanually 20:18
brrt nice 20:20
AlexDaniel++ # automating things
AlexDaniel well, it doesn't trisect into moar but it will show the right bump right away no matter how many dependencies the module has
also reuses all the logic from bisectable bot so once that is improved to bisect moar it will start doing that as well 20:21
also I'm a bit late with that thing for the release, sorry for that 20:22
samcv ugh utf16 with the BOM handling is really disturbing me 20:26
github.com/MoarVM/MoarVM/issues/96...-421826781 i don't like the ambiguity at all
nine After getting around the obligatory bootstrap issues, the new MAST compiler passes its first tests :) The only oddity is that the test code seems to run twice. 20:29
brrt \o/
Geth MoarVM: 156b5bc3ff | (Stefan Seifert)++ | docs/bytecode.markdown
Clarify a few things in bytecode specification
 20:32
20:34 brrt left
nine Huh? The double run is not because of anything in the bytecode apparently. So it's probably something really stupid in the quickly hacked up nqp::runbytecodebuffer or so 20:44
timotimo if the code is in the mainline, then loading it probably already runs it? 20:46
and then you run it again? 20:47
nine Ah, of course. mast_to_cu does not run the whole thing. It just runs the deserialization frame. So indeed, just hacking up loadbytecodebuffer to return the CU won't do it. 20:48
But at least I now know that when I solve this for real, the rest is already in pretty good shape :)
20:53 vikikas2 joined 20:54 vikikas2 left
nine And indeed it is. And that concludes my hacking for this weekend 21:18
jnthn nine++ 21:19
21:48 Kaiepi left 21:49 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi
timotimo way cool. 22:10
22:41 Kaiepi left 22:42 Kaiepi joined, 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!