github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:05 Kaiepi left, Kaiepi joined 01:51 lucasb left 03:40 eaterof joined 03:41 moritz_ joined, eater left 03:42 moritz left 04:55 squashable6 left 04:57 squashable6 joined 05:46 robertle left 05:55 ZzZombo_ joined 05:58 ZzZombo left, ZzZombo_ is now known as ZzZombo 06:40 sena_kun joined 07:18 moritz_ is now known as moritz, brrt joined 07:26 sena_kun left, domidumont joined 07:44 squashable6 left 07:46 squashable6 joined 07:56 MasterDuke left 08:23 dogbert17 left, avar left, Ulti left, jpf1 left 08:24 dogbert17 joined, avar joined, Ulti joined, jpf1 joined
brrt good * #moarvm 08:50
09:00 zakharyas joined
nine Good morning brrt! 09:01
brrt hi nine 09:02
good work on the bugfixing btw :-)
nine thanks :)
Trying to implement my new solution to the NativeCall relocatability issue. I think I've figured out how to call the passed function and get at its return value, but I end up with a "const_iX NYI" 09:09
brrt that means the bytecode is corrupted typically 09:25
(or that some jump doesn't jump far enough) 09:26
... including the within-interpreter jumps
apparently the internet considers 'good fences make good neighbours' confusing.... but to me it seems the most obvious thing in the world 09:31
(this in relation to the raku/perl rename thing)
nine No idea how an invocation of an MVMCode could lead to corrupted bytecode 09:42
Oooh...actually I do have an idea. I think it's just not possible to do a call at an arbitrary place like this, as the currently processed op is not yet done. There will still be at least something like cur_op += 6; 09:50
Seems like I actually have to use a nested runloop for my call
brrt is looking with horror
nine Well, I knew this wasn't going to be pretty. I also lack any alternative idea 09:51
brrt I don't know any better really... 09:52
lizmat shivers 09:54
nine Ironically NativeCall is already the one place where we do nested runloops (for callbacks) 09:55
brrt hmm, true 09:56
nine Btw. even if none of my work on parrot is in use anywhere now, the things I learned about how an interpreter works are incredibly useful in cases like this :) 09:59
brrt :-) 10:07
nwc10 it's the thing in the Mythical Man Month about prototypes, isn't it? "build one to throw away" 10:17
lizmat fwiw, I interpreted it as " the journey is more important than reaching the goal " :-)
nine Progress! The first call seems to work and I get the resolved lib_name. On the second call it dies with MoarVM panic: Internal error: Unwound entire stack and missed handler 10:19
nwc10 ship it! Hope no-one uses this feature in a loop. 10:23
10:38 sena_kun joined
lizmat m: use nqp; dd nqp::radix_I(10,"-42",0,0x02,Int) 10:44
camelia (-42, 100, 3)
lizmat m: use nqp; dd nqp::radix_I(10,"−42",0,0x02,Int)
camelia (0, 1, -1)
lizmat how difficult would it be to teach MoarVM to also accept '−' (U+2212) minus
?
src/math/bigintops.c 1290 I presume ? 10:47
nine Ok, it actually is an exception thrown by the callback. Looks like the closure isn't fully serialized 10:48
lizmat would this be a good diff for adding '−' (U+2212) minus support to nqp::radix(_I) 10:55
gist.github.com/lizmat/bcb3edaa307...35a35d2c1f
or is that too simplistic wrt to codepoint / graphemes ?
nine lizmat: I'd be surprised if the compiler would let that through. A char in C is really just one byte 10:57
lizmat didn't try to compile yet 10:58
nwc10 nine: on any current system yes. I've never used one, but IIRC on some embedded systems char was 32 bits.
unclear if on that system, it was considered that a byte was 32 bits
nine Oh, ch is actually an MVMint64
nwc10 s/it/whether/
10:59 domidumont left
lizmat so the name "ch" is actually confusing :-) 10:59
nwc10 typo *and* not the word I meant
insufficient coffee.
nine lizmat: the part that doesn't work however is '−' since single quotes in C are really just for chars. 0x2212 could work instead 11:00
lizmat oki
Geth MoarVM: 9442b1a7c2 | (Elizabeth Mattijsen)++ | 2 files
Add support for '−' (U+2212) minus for nqp::radix(_I)

Compiles cleanly, but cannot get my local nqp to work with it :-( Committing nonetheless, as Moar's compile is clean.		 11:09
lizmat hopes that nothing needs to be done for the JIT in that respect 11:10
brrt ^^ ??
brrt hmmwhat 11:12
no, not seeing anything that I'd think be jit-affected 11:13
lizmat okidoki 11:17
nine: any problem with bumping MoarVM atm ? 11:18
nine no 11:21
lizmat cool 11:22
11:37 brrt left 12:25 sena_kun left 12:37 zakharyas left 12:39 sena_kun joined 13:59 Kaiepi left, Kaiepi joined 14:05 zakharyas joined
nine Getting really close now! 14:12
14:22 lucasb joined 14:25 sena_kun left
nine I think, I finally got it :) 14:29
14:41 sena_kun joined 14:48 brrt joined 15:01 brrt left 16:25 sena_kun left 16:29 domidumont joined 16:39 sena_kun joined 17:10 robertle joined 17:14 AlexDaniel left 17:15 AlexDaniel joined 17:17 zakharyas left 17:19 zakharyas joined 18:06 domidumont left, domidumont joined 18:13 MasterDuke joined 18:26 sena_kun left 18:40 sena_kun joined 18:50 camelia left 18:57 zakharyas left 19:04 brrt joined
AlexDaniel squashable6: status 19:21
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 1 day and ≈8 hours (2019-12-07 UTC-12⌁UTC+20). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
nwc10 and the /win lottery? 19:22
/win ∞ 19:23
19:54 domidumont left 20:26 sena_kun left 20:40 sena_kun joined 22:20 brrt left 22:26 sena_kun left 22:41 MasterDuke left, sena_kun joined 23:58 sena_kun left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!