github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
japhb AlexDaniel, timotimo: Looks like the GH issues image upload trick worked; see latest README at github.com/japhb/Terminal-QuickCharts , which gets its images from github.com/japhb/Terminal-QuickCharts/issues/1 05:41
07:03 patrickb joined 07:22 domidumont joined 07:59 domidumont left 08:16 domidumont joined 08:33 domidumont left 08:37 sena_kun joined 08:46 domidumont joined 09:19 domidumont left 09:30 brrt joined
brrt \o 09:30
nwc10 o/
brrt ohai nwc10... 09:31
I think I figured out how comparison works for floating points
surprisingly, it works differently from integers
nwc10 I assume that when you say "surprisingly" this is at the level of the CPU operands, or the bit level representation. And not the higher level problem of aaaaaaaargh, rounding. 09:33
brrt no, not that 09:34
the problem of bits
and cpu flags
etc
jnthn o/
brrt ohai jnthn
it means I have to tweak the model a bit :-)
nwc10 given the problem of aaaaaaaaargh, rounding, surely one can cheat a bit and optimise it to "not equal" :-) 09:35
although that doesn't get far, as one still has to implement comparsion operations
brrt there's already a bit of aaaargh around NaN 09:36
jnthn Two things with the same bit pattern might be unequal in floating point. Such fun :)
nwc10 I was aware of NaN. Because I was going to say that (IIRC) you could then actually still implement == and != atop the comparison operators 09:37
because IIRC NaN < NaN is (also) bonkers
brrt thing is, 'the comparison operators' becomes a single instruction (ucomisd), and the results map to a specific flag pattern... 09:38
09:45 zakharyas joined 10:27 brrt left 10:39 brrt joined 11:46 brrt left, domidumont joined 11:53 AlexDaniel left 12:05 AlexDaniel joined 12:06 domidumont1 joined 12:09 domidumont left 12:21 brrt joined 12:38 pamplemousse joined
pamplemousse o/ 12:38
brrt \o 12:43
pamplemousse: one idea I had is... you know how we usually set up the lib-path during VM initialization? 12:51
what if we'd have some opcodes to do that while the VM is running
(maybe that already exists though)
that way, supposing you knew the set of libraries that were loaded, the compiler could emit code to set up the search path to load them 12:52
(the rakudo or nqp compiler)
12:57 domidumont1 left 13:00 domidumont joined
pamplemousse That could be a thought. I think that might be a bit above my comfort level with the codebase at this point, but could potentially be helpful if taking the approach of tacking the initialization stuff onto the front of the bytecode in the ELF file. 13:00
Right now the approach I'm focusing on (because it feels the most accomplishable) is modifying main.nqp to a point where I could execute bytecode, but I'm struggling a bit with figuring out how to chunk that into accomplishable tasks. 13:01
patrickb pamplemousse: I'd try to strip main.nqp down by removing parts irrelevant to your core problem. 13:13
Remove lines 22 to 46 and set $PERL6_HOME and $NQP_HOME to fixed values.
Also remove all the command line stuff. 13:15
You should be left with setup of the Perl6::Compiler object and the call to $comp.command_line() 13:16
github.com/rakudo/rakudo/blob/mast...mpiler.nqp <- That's the Perl6 Compiler class 13:19
which is based on: github.com/perl6/nqp/blob/master/s...mpiler.nqp
I guess the relevant bits are mostly in one of those two files.
pamplemousse Thanks! I've been trying to track down where command_line was defined. 13:21
patrickb jnthn has created and published an excellent course on the compiler internals that I think also cover those bits: edumentab.github.io/rakudo-and-nqp-...ls-course/
If you haven't seen that I think that's a great resource to get the bigger picture. 13:22
pamplemousse: day 1 slide 85 onwards 13:24
or 84 13:25
pamplemousse patrickb: Thank you, I really appreciate it. I worked through the course at the beginning of the summer but it's probably worth looking through again, it's been a minute :)
13:38 dogbert17 joined
patrickb pamplemousse: I think this is the magic line where a piece of bytecode is changed to something executable: github.com/perl6/nqp/blob/cc13c5ec...d.nqp#L718 13:49
brrt well, either that, or MVM_load_bytecode, in src/core/loadbytecode.c, depending on your PoV 13:50
13:54 pamplemousse_ joined
dogbert17 jnthn: wrt M#1129, running the program under helgrind lists a lot of possible data races. Any ideas as to what I should be looking for? 13:56
synopsebot M#1129 [open]: github.com/MoarVM/MoarVM/issues/1129 Intermittent failure when running S17-supply/return-in-tap.t
pamplemousse_ brrt, patrickb: Thanks, taking a look now
13:58 pamplemousse left 14:02 MasterDuke left 14:03 pamplemousse_ is now known as pamplemousse 14:07 zakharyas left
dogbert17 .seen timotimo 14:13
yoleaux I saw timotimo 09:20Z in #perl6-dev: <timotimo> where not all of them are used often before spesh hits
dogbert17 any C-hackers around? I'm wondering if this code is dangerous as I get the impression that variable 'name' is not necessarily initialized? github.com/MoarVM/MoarVM/blob/mast...ent.c#L877 14:16
nwc10 I think that you're correct. It sure looks like uninitalised name can be passed to fprintf and then to free 14:26
if n->sf is always true then this won't happen. But if n->sf is alway true, then why did the programmer write the if test? 14:27
brrt yeah, that code is wrong
dogbert17 nwc10, brrt: thx, do you think that 'if (n->sf) {' should encompass the fprintf and MVM_free lines? 14:34
brrt I don't know, I don't know the context of those lines. The alternative is that there may be another name that can be used 14:35
ask timotimo for context, I think
dogbert17 brrt, will do 14:36
nwc10 dogbert17: no, because in that case the ouput to stderr can't be correct, because there is no newline. And, likely, n->num_succ should still be output in that case 14:39
dogbert17 nwc10: oops, thx for pointing that out. I'll cleverly let timotimo fix this :) 14:44
14:53 domidumont left
dogbert17 while waiting for timotimo, is anyone up for another C lang question? This time about github.com/MoarVM/MoarVM/blob/mast...ache.c#L17 15:28
when we come to this line isn't the variable 'type_index', which is used as a loop variable above, equal to 4? 15:29
nwc10 line 10. break; 15:30
dogbert17 cool, so it can never be 4 then? 15:32
nwc10 I think that type_index can end up having any value between 0 and 4 at that point (I'm not fully awake here) 15:33
dogbert17 enocoffe :)
nwc10 but if the loop runs to completion then type_index is 4 and right_slow is -1, because it never got assigned
and if right_slot isn't -1, then it will ahve the same value as type_index 15:34
ENOTEA, in the "eat tea" sense
dogbert17 line 28 uses type index and it is declared like this github.com/MoarVM/MoarVM/blob/mast...cache.h#L2 that's why I'm asking
if I understand this correctly (doubtful), the highest allowed index is 3 15:36
nwc10 yes, oh, sorry, not clear
at the end of the loop, right_slot is in the range -1 to 3 inclusive
and I believe that it's now tea time 15:37
dogbert17 :)
thx for the help
15:39 patrickb left
timotimo o/ 15:50
dogbert17 yay, it's timotimo
timotimo partially 15:51
dogbert17 uh oh :)
timotimo need to get some breakfast
dogbert17 just woke up?
timotimo no, i've been running chores
dogbert17 without food, ouch 15:52
timotimo not the worst that could happen
dogbert17 there's a question for you half a page up, give it a glance after breakfast if you have time
timotimo i didn't plug in my mouse again, i can't click the link :P
dogbert17 haha
16:26 zakharyas joined 16:28 MasterDuke joined 16:29 zakharyas1 joined 16:30 zakharyas2 joined 16:31 zakharyas left 16:33 zakharyas1 left 16:39 zakharyas2 left 16:53 domidumont joined 17:04 domidumont left 17:21 domidumont joined 17:23 brrt left 17:57 domidumont left 18:20 brrt joined 18:25 brrt left 18:27 robertle joined
timotimo i mean, MVM_dump_callgraph is a thing you'd be using if you're already in gdb, so it's barely dangerous to crash there :) 18:35
but yeah, that would like to be fixed probably 18:36
just not urgent
19:14 pamplemousse left 19:15 pamplemousse joined 19:19 Kaiepi left
dogbert17 timotimo: thx for looking into it 19:44
20:08 pamplemousse left 20:21 Kaiepi joined 20:29 brrt joined
Geth MoarVM: MasterDuke17++ created pull request #1130:
Throw if MVM_is_prime called with too many rounds		 20:35
MasterDuke fg 20:36
20:39 robertle left 21:09 Kaiepi left 21:11 Kaiepi joined 21:13 patrickb joined 21:23 pamplemousse joined
brrt good evening 21:28
timotimo yo brrt 21:29
pamplemousse o/
timotimo yo pamplemousse
brrt ohai timotimo, pamplemousse 21:32
pamplemousse Hi timotimo, brrt! 21:33
21:53 pamplemousse left 22:08 MasterDuke left 22:18 patrickb left 22:32 Kaiepi left, Kaiepi joined
Geth MoarVM: 0e7599e756 | (Daniel Green)++ | src/math/bigintops.c
Throw if MVM_is_prime called with too many rounds

Valid range is 0..PRIME_SIZE (defined in libtommath).		 23:08
MoarVM: 8b6e6d715c | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/math/bigintops.c
Merge pull request #1130 from MasterDuke17/throw_when_too_many_rounds_in_is_prime

Throw if MVM_bigint_is_prime called with too many rounds
23:14 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!