github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nine .tell brrt I guess we could get rid of nativecallinvoke. The difference from a user's perspective is really just that nativecallinvoke expects the arguments in a list while nativeinvoke expects them in the args buffer like other invoky ops. 05:57
yoleaux nine: I'll pass your message to brrt.
lizmat . 10:51
lizmat is trying to create a QAST::Var and make it dynamic, but is not getting much further :-( 10:52
jnthn ?
"make it dynamic" doesn't make sense
Or at least, I'm not sure what you're trying to do 10:53
If fixing that result of declaration thing, it'd just be a lexical scoped lookup for $*FOO
lizmat jnthn: I'm trying to fix the DYNAMIC issue when a dynamic variable is used in a declaration with a possible initialization 11:09
it currently enters Actions.declarator with a DYNAMIC stuff 11:10
my theory is that if I'm in a declarator, I should get rid of the DYNAMIC stuff and replace it with just a QAST::Var
before it gets further codegenned 11:12
gist.github.com/lizmat/7f82e393e3d...d50f629eae # work so far 11:19
Geth MoarVM: 58e5161ebd | (Bart Wiegmans)++ | src/jit/graph.c
[JIT] Fix legacy jit of strfromname
MoarVM: 95d227987a | (Bart Wiegmans)++ | 3 files
[JIT] Make jit-bisect.pl work in the new world order (spesh log)

I still want the jit sequence number for uniquely identifying frames, but it makes no sense to have them separate from the spesh sequence number. This also fixes jit-bisect.pl to use the spesh log.
brrt \o 11:25
yoleaux 05:57Z <nine> brrt: I guess we could get rid of nativecallinvoke. The difference from a user's perspective is really just that nativecallinvoke expects the arguments in a list while nativeinvoke expects them in the args buffer like other invoky ops.
brrt right
travis-ci MoarVM build failed. Bart Wiegmans '[JIT] Make jit-bisect.pl work in the new world order (spesh log) 11:39
travis-ci.org/MoarVM/MoarVM/builds/442121296 github.com/MoarVM/MoarVM/compare/f...d227987a17
lizmat in QAST: + - QAST::Var(lexical %*foo :decl(contvar)) 11:57
+ [value]
+ -
what does the [value] and the empty line signify ?
lizmat it's not coming from QAST::Var's dump_extra_node_info method 12:00
ah, I guess it comes from the "extra_children" method 12:01
brrt nine: I wonder if we can move the boxing of return values to the HLL as well 13:47
basically, treat the return value of nativecall, if a pointer, as an opaque integer, and have nativecallbox() as an opcode 13:48
Geth MoarVM/faster-Int-str: 8f6b2ac8b0 | (Zoffix Znet)++ | src/math/bigintops.c
Make big Int stringification 1.58x as fast

For Ints larger than 2⁶⁰ and only in base-10.
We do it by reducing the value by largest 10**n number that fits into a single mp_digit and doing so until our remaining number fits into a single mp_digit, at which point we continue ... (21 more lines)		 17:11
dogbert17 brrt: are you around? 17:12
Geth MoarVM: zoffixznet++ created pull request #984:
Make big Int stringification 1.58x as fast		 17:14
Geth MoarVM/faster-Int-str: 3740cd0bb9 | (Zoffix Znet)++ | src/math/bigintops.c
Clamp the value before we count its digits
 17:27
timotimo wowza, libssh will let you authenticate by sending a "success" message instead of a "request" message for auth 17:34
japhb timotimo: link? 17:35
timotimo www.libssh.org/2018/10/16/libssh-0...x-release/ 17:36
tadzik yeah, it look scary :o 17:51
timotimo who uses libssh anyway? 17:52
tadzik I checked my server, and not only it uses libssh2, which is apparently a different thing, but also calls it a "client-side library"
timotimo the problem is only in the server code, and even our perl6 binding to libssh doesn't have server code bound
tadzik so yeah, I was wondering the same thing: who does it affect in practice? Maybe it's me but I don't know
nine brrt: what would be the advantage? 18:05
japhb tadzik: A friend on an RPM-based distro says curl/libcurl link to it. Of course, that's client-side. 18:08
tadzik japhb: nodnod, makes sense 18:12
so if my client can bypass auth, that's a feature, right? :P
brrt \o 20:33
yoleaux 17:32Z <Zoffix> brrt: PR sent: github.com/MoarVM/MoarVM/pull/984
brrt dogbert17: I am now 20:34
how can I help?
nine: each individual ops becomes simpler, and it's easier to implement JITting for 20:35
dogbert17 hi brrt 20:38
I have a GC bug which might be JIT related since I can't repro with the JIT off 20:39
it looks like this, gist.github.com/dogbert17/7f475e44...42da223c12 20:40
timotimo anything with gc debug?
or is that already gc debug?
dogbert17 timotimo: gc debug is on
brrt that does look annoying, yes 20:41
hmm
and it's using the spesh plugin
dogbert17 if I set MVM_JIT_DISABLE=1 it seems to vanish
brrt can you set jit-bisect.pl on it
specifically, jit.bisect.pl --spesh 20:42
dogbert17 does that work even if the fail doesn't occur every run?
brrt nope... do you have an approximate failure rate? 20:43
dogbert17 50%, that's with a small nursery 20:44
if it is small enough it will probably break every time though
brrt if you do, then you can write a script that will run it a number of times, up to the desired level of accuracy, until you either get a crash or don't
dogbert17 tries a jit-bisect ... 20:46
SPESH Broken frame: 577. 20:48
SPESH Acquiring log: spesh-0577.txt
what do I do now? 20:49
a second bisect run complains about frame 567 instead 20:52
brrt hmm, that's annoying 20:55
then it is presumably not reliable enough
(the crash) 20:56
dogbert17 a third run gave 567 again 20:57
file is 892 lines, perhaps I can gist it if you want 20:58
brrt yes, please
dogbert17 gist.github.com/dogbert17/fddecf8d...8dbd9c818f 20:59
brrt it does call speshresolve, so that's suspicious 21:00
unfortunately I don't think I can help you much further now 21:26
dogbert17 thanks for trying 21:27
I wonder if there's a way to make this crash 100% reliable
brrt dogbert17: I have a branch outstanding though that you might test with this 22:09
it's called expr-jit-invoke
it might fix this

Powered by Cro and the Raku® Programming Language.

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

Thank you!