01:13 jnap joined 01:52 jnap joined
dalek arVM/patch-1: 14c623e | jimmy++ | src/6model/ (2 files):
removed REFVAR_VM_HASH_STR_VAR, and fix MSVC build
 02:00
JimmyZ timotimo: ^^
dalek arVM/patch-1: d5a6b8c | jimmy++ | src/6model/ (2 files):
removed REFVAR_VM_HASH_STR_VAR, and fix MSVC build
 02:14
02:47 ilbot3 joined 04:08 lue joined 04:59 krunen joined 05:02 flussence joined 05:04 flussence joined 06:57 krunen joined 07:35 FROGGS joined
timotimo JimmyZ: msvc doesn't have 0b... literals? :o 07:41
FROGGS timotimo: I learned recently: is has not :o) 07:42
timotimo thank you, JimmyZ 07:43
JimmyZ timotimo: I removed REFVAR_VM_HASH_STR_VAR too, it's not needed in MoarVM after bump version :P
timotimo i didn't know that. seems good, feel free to merge 07:44
can i force my gcc to enforce the "define vars only at the beginning" stuff?
JimmyZ timotimo: feel free to merge if you compile nqp ok, I got problems on windows, not sure if it's because of my patch or not. 07:46
it is: Invalid dependencies table index encountered (index -2139095040) 07:47
timotimo oh 07:49
i'll have a look
FROGGS timotimo: maybe try this? -std=c89 -pedantic-errors
timotimo it could very well be a mistake i made. where does it explode?
JimmyZ Thanks
compile NQPCORE.setting 07:50
FROGGS (or -std=c89 -pedantic)
see gcc.gnu.org/onlinedocs/gcc-3.4.6/gc...dards.html
timotimo thank you 07:51
3.4 is a tad old, though :)
FROGGS I guess the flags are still there :o)
timotimo fair enough
JimmyZ: if you want i'll push my "varint_stats" branch that will verify every varint it writes to make sure it's the same before as after 07:52
i'm building rakudo-moar right now, so i can build nqp fine :\
dalek arVM/varint_diagnostics: 25f59e1 | (Timo Paulssen)++ | src/6model/ (2 files):
statistics for varint serialization
 07:54
arVM/varint_diagnostics: 45dedae | (Timo Paulssen)++ | src/6model/serialization.c:
Merge branch 'varint' into varint_diagnostics

Conflicts: src/6model/serialization.c
timotimo JimmyZ: ^^ try that
dalek arVM/varint_diagnostics: a2f48d3 | (Timo Paulssen)++ | src/6model/serialization.c:
more verbosity
MoarVM/varint_diagnostics: af02b68 | (Timo Paulssen)++ | src/6model/ (2 files):
JimmyZ timotimo: still the same error 08:04
dalek arVM: f40b466 | jimmy++ | src/6model/ (2 files):
removed REFVAR_VM_HASH_STR_VAR, and fix MSVC build
 08:12
08:30 odc joined 08:43 arnsholt_ joined, timotimo joined
JimmyZ doesn't know how to debug into moar.dll by using msvc2012 09:07
Is there a easy way to do it? 09:08
diakopter did you --debug ?
JimmyZ yeah
moar.exe is fine. just can't debug into moar.dll 09:09
Microsoft Visual Studio 2012 Express
diakopter hm, don't know..
timotimo i better get rid of my changes until we can figure out what's wrong? 09:12
but maybe jnthn wants to try building it before we do that
diakopter wants to see the branch diff
timotimo github.com/MoarVM/MoarVM/compare/d......cc57bd4 ā† diakopter 09:15
JimmyZ timotimo: I think it read int32 as int64 somewhere 09:16
timotimo oof. 09:18
JimmyZ timotimo: I tried to debug into moar.dll and msvc doesn't allow me to do it and I don't know how to ...
timotimo :o 09:19
i looked through the diff to make sure i never replaced an int\d\d with a varint directly
and at least in reprs/ there are no read_int\d\d left to transform 09:20
maybe you can find it like that?
i'm AFK for a bit now
JimmyZ can't find it 09:32
09:47 krunen joined
timotimo JimmyZ: just a safety-ask, did you try a complete clean rebuild yet? 09:54
JimmyZ timotimo: yeah
timotimo i have no idea what's wrong :(
JimmyZ me either. 09:55
09:58 crab2313 joined
JimmyZ timotimo: I think it's a easy fix if someone get a `bt ful` output on msvc :P 10:00
JimmyZ decommutes 10:01
timotimo maybe i'll tackle storing a 32bit integer for our big ints if we can today 10:24
now i'll have to lay out p6smallbigintbody so that it matches up its "these must all be 1" field with the mp_digit *dp 11:05
that should be fairly easy
oh, huh, but i need to make extra sure i handle 32bit architectures right 11:07
moritz and big endian :( 11:15
timotimo in this case, i don't think i'll have to 11:16
oh, wait.
i think i know what you mean
but in this case i don't care if the int32s end up switched, i'm thinking i should first approximate bigint serializing for "compressed" bigints by turning them into a bigint before serializing 11:17
since there'll have to be a bounds check on creation anyway
hm. and since i don't have to serialize the padding anyway, i think it'd Just Work
is there some sane place i can put an assertion like "assert sizeof(MVMP6smallbigintbody) == sizeof(mp_int)? 11:20
"
hm. i could use a value of 1 instead of 0b1111....1111 for the flag, because pointer 11:21
and then i don't have to #define a constant that'll have the proper amount of ones on each platform
11:23 colomon joined
timotimo is some ways into the thing and will soon be able to try it out 13:32
where soon is like ... half an hour to an hour :P
src/6model/reprs/P6bigint.h:18:9: error: unknown type name ā€˜MVMP6smallbigintBodyā€™ 13:35
... but i declared it just above that?!
i even copypasted the name and it's still complaining :o
FROGGS timotimo: gist? 13:36
timotimo one sec.
dalek arVM/small_big_ints: e8654bb | (Timo Paulssen)++ | src/6model/reprs/P6bigint. (2 files):
first progress into smallbigints.
timotimo github.com/MoarVM/MoarVM/commit/e8...91aeebaR18 13:37
FROGGS timotimo: maybe you need to add it to: MoarVM/src/types.h:76:typedef struct MVMP6bigintBody MVMP6bigintBody; 13:38
timotimo oh!
who would have known >_<
FROGGS ā†
:P
timotimo yeah. 13:39
i was sure i'd have to put a typedef in there for C, but i didn't see one in that file and the only other file that file included was libtommatht
how do i manually set the address of a pointer to a specific value? 13:40
&thepointer = thevalue says i need an lvalue on the left side
is it just thepointer = thevalue?
hoelzro timotimo: yes
assuming thevalue is a pointer
if you want to point to where thevalue is stored, thepointer = &thevalue; 13:41
timotimo no, thevalue is an integer
i want to put the integer into the raw storage of the pointer
so if thevalue is 0, i get a null pointer
FROGGS thepointer = &thevalue ? 13:42
err, hoelzro mentioned it already
timotimo ā€¦
FROGGS ahh
*thepointer = thevalue
timotimo ... er
doesn't that look where thepointer points and changes the data that it points at?
FROGGS yes
timotimo how can i express myself any more clearly? 13:43
FROGGS you want to cast the integer value to a pointer address instead?
timotimo yes
FROGGS cast it then, no?
timotimo that will work?
fine, then
FROGGS should work
[Coke] (moar had better numbers) yes, but that was when the JVM was failing. 13:44
if you check the # of passing tests, I bet it's steadily climbing.
nwc10 how are the numbers? Is there a web site with a simple graph for the lazy and curious? 13:46
timotimo we have a csv file 13:47
FROGGS nwc10: github.com/coke/perl6-roast-data/b..._rates.csv
it is a pure textual graph
dalek arVM/small_big_ints: 80e7764 | (Timo Paulssen)++ | src/ (3 files):
first progress into smallbigints.
 13:49
arnsholt Small bigints ^_^ 13:50
timotimo :)
i expect this to explode horribly when i try to compile stuff
but i'll set up some debug output to see what's happening 13:51
[Coke] you can search for "moar" at that URL, which helps a bit.
arnsholt timotimo: Making bigints for small numbers less memory-hungry, or somesuch I assume? 13:53
timotimo yes 13:55
if the number fits into a 32bit integer, we store that and then we don't have to mp_init which mallocs
moritz and moar storage efficient
timotimo well, at the moment a smallbigint will force itself to become an actual bigint before serialization
at some point i can implement that, though 13:56
how do i factor out the force_bigint and make_smallbigint functions so that i can use it inside the math ops?
oh, wait
the bigintops act on mp_int rather than P6bigint 13:57
i'd have to move the code one layer up, that'd probably be in interp.c
alternatively i can just introduce the P6smallbigintBody to the ops and do the logic that way with just a cast 13:58
ah, i was wrong 13:59
it *does* handle MVMObjects, just further down in the code file
arnsholt: the program "say 1" in rakudo takes 98 megs of ram on my machine now; the same with parrot takes about 240 14:05
arnsholt Nice! What's the win relative to master Moar? 14:10
JimmyZ timotimo: union needs a name, solaris doesn't support anonymous union 14:11
timotimo JimmyZ: thank you, i can do that a bit later
arnsholt: this is about a change already in master
i'm not at the point where smallbigints do anything but segfault in compilation 14:12
but it used to be about 100.5 mb before the serialization with varints stuff
unfortunately there seems to be a bug that makes nqp not compile on JimmyZ's windows
:(
arnsholt Oh, that's annoying
But 2.5 megs shaved off sounds like a pretty good win to me 14:13
JimmyZ well, I think I cant fix it if I know how to debug into maor.dll
s/cant/can/
14:25 jnap joined 14:28 cognominal joined 14:43 cognominal joined
timotimo what type do i cast a pointer to if i want it to be an integer value? 14:46
arnsholt long, IIRC 14:47
But there be dragons
diakopter uint_ptr
timotimo what diakopter said sounds nice.
what do i have to include to get that? 14:48
arnsholt Looks like uint_ptr might be a Windows-only type
diakopter wtypes
timotimo OK
i'm having some difficulty with IS_SBI and SET_SBI >_> 14:49
diakopter er
arnsholt Why do you need to convert a pointer to an int, though? That's really, really evil
dalek arVM/small_big_ints: 8fd1d5e | (Timo Paulssen)++ | / (6 files):
towards a p6smallbigint that does nothing

especially not crash. which it currently does.		 14:50
timotimo i am using the same data region as a pointer to store a flag
in the spot where normally there'd be the mp_digit * i want to have a flag that i can set to 1
diakopter usually one uses the lowest 2-3 bits 14:51
arnsholt Oh
You just want to set the pointer to some flag value?
timotimo yes
i should probably just use long instead of mp_digit * 14:52
arnsholt In that case you can just set it to a literal, I think
timotimo i don't understand what i'm doing wrong. i ought to check more stuff i'm doing 14:53
diakopter well in moarvm source, AO_t is already an alias of pointer-sized integer due to libatomicops 14:54
timotimo: you can also use a union 14:55
timotimo i was using an union :) 14:56
but apparently too far outside
gist.github.com/timo/5804138fc21801a3498e 14:59
the flag is 0x1 and it steps into the else-branch of that ... ?!?
dalek arVM/small_big_ints: 346850c | (Timo Paulssen)++ | src/6model/reprs/P6bigint.h:
maybe this is correcter?
 15:07
timotimo errand& 15:22
i figured out what's wrong with the code at least.
jnthn Shouldn't do force_bigint modifying the thing in place. P6bigint must the immutable or we're in for a world of pain when we thread... 15:47
um, when I try and build NQP on Moar HEAD, I get "Invalid dependencies table index encountered (index -2139095040)" 15:49
diakopter eww 15:50
jnthn It's NQP HEAD also 15:51
I wish folks would make atomic commits 15:56
f40b466739 does two things, meaning I can't revert half of it easily to see if it's to blame :/
timotimo git reset --patch :) 16:04
jnthn Well, reverting the hash_str_ref thing still leaves it broken... 16:05
timotimo JimmyZ mentioned it breaks on nqp for him, but he can't debug into moar.dll 16:06
it builds cleanly for me on linux, so i can't help debug :(
jnthn :(
Well, going back to before the varint merge works... 16:07
timotimo some of my bit operations may be unsafe on MSVC? 16:13
i have a branch that reads a varint after it writes it and makes sure the values match up
it didn't give any extra output for JimmyZ, though 16:14
jnthn I don't immediately see what's wrong... 16:16
Tried one thing, but no help
timotimo i looked the diff over twice :(
jnthn int read_on = !!(buffer[offset] & 0x80) + 1; 16:17
huh...
What's the !!
timotimo ensure it's either 0 or 1
tadzik boolification
jnthn oh... 16:18
timotimo could have used > 1, too, but that has looser precedence
oof. in order to convert the smallbigints, i'll have to carry around the threadcontext and probably steal the type of the MVMObject, too 16:19
jnthn Convert? 16:22
timotimo i mean create new big integers that are actually big integers 16:23
like you said; they must remain immutable
jnthn Yeah, but that only needs creating an mp_int...
timotimo er ... it does? 16:24
i think i misunderstood you in that case and all is going to be well :)
but they are never shared, so all i need to do is have an atomical swap from one pointer to the other and mp_clear the other one? 16:25
jnthn huh 16:26
There should be no atomic ops needed in this.
If the operation needs a bigint the logic should be just like 16:27
timotimo okay. please rephrase this sentence: Shouldn't do force_bigint modifying the thing in place. P6bigint must the immutable or we're in for a world of pain when we thread...
jnthn if (it's already big)
the_mp_int_to_work_with = directly_from_P6bigint;
else
the_mp_int_to_work_with = make_mp_int_from(the_32_bit_value); 16:28
And some tracking so we know the free the mp_int at the end of the operation in the latter caes.
*case
timotimo huh. but then using the same value over and over will cause a conversion from 32bit int to mp_int every time we use it 16:29
jnthn Yes, but that's going to be relatively rare, given most operations (e.g., not is_prime) can be done directly on the 32-bit integers...
timotimo fair enough.
i'll try that then 16:30
jnthn Oh, and you don't need to free track...
timotimo not exactly sure how to do the tracking properly yet
jnthn Just keep the mp_int we box to on the stack
And the free tracking is just checking if the address matches or so...
timotimo you mean if the address of the mp_int i got from the force_bigint is the same as TheMVMObject->body.i 16:31
jnthn Yeah
timotimo that sounds fair
thank you for your insight :)
jnthn Though I think obtain_bigint is maybe a better name.
Hopefully most of the time we don't need that, though... 16:32
timotimo yes, that'll be a better name now that it's had its functionality changed
that's my hope as well.
i just wanted to get to a state where i do have small bigints that are just always forced to become bigints immediately again
jnthn I mean, I know we will for primality testing and a few other thing, but the common operations (add, etc) don't...
timotimo so that i can make sure the fallbacks already work and don't segfault :)
jnthn That's a reasonable way to go.
timotimo do you see a problem with force_smallbigint? 16:33
jnthn I'm having no luck working out what's wrong with varint :(
timotimo okay then; revert it and we'll get back to it some time in the future?
i could also rewrite the serialization code that it can emit either version 8 or 9
and have the current version ifdef decide what it does 16:34
that way we could get the old, working, but fixed-sized ints on windows and the new, shiny, also working varints on linux
jnthn I'm sure it's going to work out to something small/weird...
timotimo that's my fear :(
jnthn Not immediately sure of the best way to debug it, though...
What's the goal of force_smallbigint? 16:36
timotimo: I added to the end of read_varint9 this: 16:42
printf("read %d bytes; got %d\n", (int)inner_offset, (int)*value);
And see things like 16:43
read 8 bytes; got 0
read 8 bytes; got 8
I'm guessing for numbers that size it should...not have read 8 bytes?
16:57 krunen joined
timotimo that's right 16:59
i'll try it now, too 17:06
i'm filtering out every output with inner_offset == 1 17:07
the values here seem correct 17:08
you should check if the bytes really do have their 8th bit set
or if it keeps going regardless
assuming we're writing them correctly and the read part is wrong in reading 8 bytes instead of 1, the following bytes must 1) have their 8th bit set and 2) must otherwise be null, otherwise you'd get much different values 17:09
jnthn timotimo: Yeah, it claims it's 128 each time... 17:12
timotimo that doesn't seem right 17:13
does the writer write properly at all?
i do value & 0x7f, so the uppermost bit shouldn't leak through
and the other line sets the uppermost bit for all except the needed_bytes-1th bit 17:14
does needed_bytes give you the expected values?
jnthn Well, now, the 128 each time is the flag bit
timotimo yeah 17:15
does the writer write the value and then a bunch fo 128?!
well, the value | 0xf0
jnthn Writing 0 in 11 bytes 17:16
oops :)
That's from
printf("Writing %d in %d bytes\n", (int)value, (int)needed_bytes);
timotimo wow, yowch! 17:17
yeah, that's not right at all
jnthn What's log2 of 0? :)
timotimo oh ... minus infinity?
diakopter infinity over zero 17:18
timotimo fortunately i nudge it +1
if the value is 0
before calculating the log2
jnthn oh...
timotimo at least now we know the failure is inside varintsize
jnthn If I do: 17:20
printf("%d, %d, %d\n", (int)sign_nudge, (int)varlog, (int)needed_bytes);
I get
1, 8100, 1158
1, 128, 19
Writing 0 in 19 bytes
17:20 jnap joined
timotimo er .. huh? 17:21
jnthn indeed
given it was meant to be being called with the same value each time... 17:22
timotimo stack corruption?
undefined behaviour?! 17:23
... the ... what ?
diakopter teh wut 17:24
jnthn Seems it's the log2 to blame... 17:27
What's odd is that I look it up and it claims it's not supported by MSVC... 17:29
diakopter oh, assumes positive?
jnthn We're only giving it positive...
question is, if math.h with MSVC is supposedly missing log2...where're we getting it from... 17:30
diakopter url to the algorithm?
oh
timotimo it's a function pointer into a random place? :) 17:32
and that place changes itself in between invocations?
jnthn no clue 17:33
size_t varlog = ceil(log(abs(value) + sign_nudge) / log(2));
seems to work
timotimo very well
gcc will be able to turn that into a log2 easily, i believe.
or even into a "what's the highest bit set?" operation if available
jnthn tossed my debug code, doing make test... 17:34
pass 17:35
timotimo thank you kindly
jnthn I still don't quite know how/where log2 is getting defined to...something. 17:36
timotimo yes, agreed. it's very wacky
jnthn ah well, at least we don't need to revert it now... 17:37
Happy Rakudo make test too 17:39
dalek arVM: 6558605 | jonathan++ | src/6model/serialization.c:
Make varint serialization work on MSVC.
jnthn There we go. 17:40
And yeah, makes a good difference to size of various things 17:41
diakopter :) 17:45
timotimo++ jnthn++
(likely adds negligible unmeasurable cpu time)
jnthn What we add in CPU instructions we win back in cache locality, I suspect. 17:46
timotimo we only ever run through that thing once, don't we?
oh, but we don't trash as many cache lines, i guess
jnthn Well, we just have to go through less memory 17:47
timotimo how does instruction caching work? is the instruction cache usually separate from the data cache? 17:48
diakopter likely depends on the OS 17:49
jnthn Probably varies...I would imagine it typically is.
diakopter and config
jnthn I'd have guessed it's hardware dependent more than OS dependent...
I would imagine if it's separate then it's only separate instruction cache and L1 data cache, though, and they both source stuff through L2. Could be wrong... 17:50
timotimo well, anyway. using less memory for the source data before making a round trip on the same instructions again might indeed help us
and for things like integer arrays, we get a bunch of small varints in a row 17:51
i bet someone proficient in C could make that code a whole bunch prettier, too 17:53
the different parts of the data i used are all over the place 17:54
17:57 FROGGS joined
tadzik which MoarVM level structs are used the most when running rakudo-moar? 17:59
apart from 6model
by used the most I mean: allocated most often 18:00
jnthn Probably MVMFrame 'cus we don't hit the frame cache as much as we should 18:05
(improvable, though) 18:06
timotimo another thing i like hearing :3
that would also cause the memory usage to be too big, eh? 18:07
18:07 tgt joined
jnthn Well, also malloc/free more than needed 18:07
timotimo i wonder if the february release gets down to 50 MB of ram usage for "say 1" in perl6
that would be amazing
well, everything else is amazing, too :P
diakopter jnthn: why missing the frame cache? 18:09
jnthn diakopter: 'cus it's full 18:10
diakopter: Many frames live longer than they really should.
The easy case to fix is lexotic.
The tricker one is immediate
bbl
tadzik heh. I tried reordering the struct members in src/6model by size, in order to improve their caching. The performance win, as expected, is zero :P 18:22
it was worth a try though
timotimo it may make more sense to group by which attributes are often accessed together 18:32
moritz tadzik: what did you go for? alignment? 18:39
nwc10 suggests taking a look at linux.die.net/man/1/pahole 18:40
in debian (at least) it's in package dwaves
coo, MoarVM is fast at building the setting when you're not doing anything "stupid" :-) 18:41
18:41 krunen joined
tadzik moritz: yup 18:43
well, mostly space-saving in the end
moritz and thus cache saving 18:44
tadzik so if it has MVMint8 and then a pointer, it doesn't waste 56 bytes
moritz and thus performance, and world saving
tadzik yeah
that was the general idea :)
nwc10 just use pahole
tadzik interesting, thanks 18:45
18:48 tgt joined 19:03 FROGGS[mobile] joined 19:19 tgt joined 19:37 tgt joined
nwc10 aarrrrrrrrrrgh. zillions of bloody errors under valgrind. Not Good. 19:54
timotimo :(
nwc10 including, but certainly not limited to, varintsize 19:55
timotimo varintsize? oops :) 19:56
that'd be me
nwc10 not totally - it's being fed bogus data
writer->write_varint(tc, writer, repr_data->unbox_slots[i].repr_id); 19:57
I think that repr_data->unbox_slots[i].repr_id is the culprit
yaks :-( 20:03
jnthn: when it comes to serialize_repr_data, are all of repr_data->unbox_slots supposed to be initialised? 20:06
diakopter if they're not currently, sounds like they should be 20:08
<- captain obvious, sorry :)
FROGGS jnthn: am I allowed to commit that? gist.github.com/FROGGS/cc7e4db40bd18c1aec66 20:12
nwc10 jnthn: specifically, static void compose in P6opaque.c does repr_data->unbox_slots = (MVMP6opaqueBoxedTypeMap *)malloc(total_attrs * sizeof(MVMP6opaqueBoxedTypeMap)); 20:14
jnthn: and in this case, total_attrs is 3, but only the first is used, so the rest are garbage memroy
memroy
gah
jnthn nwc10: I'm not sure if we look at the invalid ones to use them... 20:15
nwc10 serialise (attempts to) serialise garbage memory
jnthn Yeah. It's wasteful now we've varint.
nwc10 which gives a ton of crap from valgrind, which gets in the way of working out if something else is unhappy.
jnthn Since a 0 would encode much smaller
nwc10 I think I can make it a 0 with calloc() 20:16
jnthn That'll do too
nwc10 also not sure why the code likes malloc() and memset()
as best I can tell from the source of jemalloc() (used at least by FreeBSD() calloc() is no real advantage over malloc() [other than maybe less code size]
but I thought that one some OSes, calloc() would track if memory was already zeroed, and avoid work 20:17
diakopter nwc10: jnthn explained he preferred malloc/memset because later we might need to change what it memset to - ie for pointers to the null pmc
nwc10 also, serialising crap means that I can't binary compare the setting to see if the build is unchanged
aha
jnthn Yes, that holds true in various cases
nwc10 but I think you can searcn & destroy^Wreplace on calloc() just as easily as memset() 20:18
diakopter hm, true
afk&
jnthn FROGGS: Looks good to me 20:19
FROGGS cool, thanks
dalek arVM: f22a386 | (Tobias Leich)++ | src/6model/serialization.c:
port reposession conflict resolution for objects from nqp-p
 20:21
jnthn FROGGS: How's v5 now? 20:23
FROGGS jnthn: stumbling about the STable still :/
jnthn FROGGS: I guess it doesn't do that on Parrot?
FROGGS I am bisecting Perl5::Terms atm, but it looks like it explodes when a critical number of mixins is reached 20:24
jnthn: correct 20:25
m: multi infix:Ā«P5<=>Ā»(\a, \b) is export { nqp::p6box_i(nqp::cmp_I(nqp::decont(&prefix:<P5+>(a)), nqp::decont(&prefix:<P5+>(b)))) } 20:29
camelia rakudo-moar acf7bd: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/JkcPUJdup2ā¤Undeclared name:ā¤ &prefix:<P5+> used at line 1ā¤ā¤Ā»
FROGGS m: sub prefix:<P5+>(\a) { }; multi infix:Ā«P5<=>Ā»(\a, \b) is export { nqp::p6box_i(nqp::cmp_I(nqp::decont(&prefix:<P5+>(a)), nqp::decont(&prefix:<P5+>(b)))) } 20:30
camelia ( no output )
FROGGS yeah, it *is* about some sort of critical mass 20:37
it does not matter what infix/prefix I uncomment, either breaks the code 20:38
I can precompile Perl5::Terms (the one with the infixes), and I can precompile Perl5::Config, which uses it
but when I load Config, it asplodes
funny thing is that I can uncomment subs but not multis 20:41
jnthn: where do I need to bump MAX_MULTI_COUNT_PER_CU ?
btw, I do not declare any proto 20:43
jnthn Max...multi count? Huh? 20:44
jnthn didn't know that existed...
FROGGS well, it does not... (officially) 20:45
but... why does it explode?
can you make sense of it whatsoever?
jnthn No, though one thing you may wish to do is to add something into the STable write barrier in sc.c and see when it gets hit 20:46
When I was tracking donw the others I just shoved an MVM_exception_throw_adhoc into there 20:47
FROGGS yeah, printing a backtrace (without dying) is also helpful 20:48
I remember I did that in interp.c once or twice
jnthn also that, yeah
FROGGS hmmm, it already hits, even for the working-code-case 20:50
when loading the setting or so 20:51
jnthn yeah, the problem tends to show up downstream though 20:53
Where's it hit?
And which setting? The Rakudo one?
FROGGS gist.github.com/FROGGS/75012929138cb207b35e 20:55
rakudo's yeah
that is a backtrace for every time MVM_sc_wb_hit_obj is called... that was right, right? 20:56
jnthn oh, I thought you were going for the _st one, since it's an STable conflict? 20:57
FROGGS ahh :o) 20:58
that looks different, yes: gist.github.com/FROGGS/75012929138cb207b35e 20:59
this is the offending line btw: multi infix:<P5cmp>(int $a, int $b) is export { nqp::p6box_i(nqp::cmp_i($a, $b)) } 21:01
and the last bt shows that pretty well
jnthn hmm, i wonder... 21:04
FROGGS: Does v5 work under JVM, ooc? 21:13
FROGGS dunno 21:15
need to create a Makefile.in for it first
but I can do that (tomorrow)
timotimo what, it'll take you more than 1.75 hours? :) 21:19
FROGGS no, it will take less, but I am too sleepy to do that right today :o) 21:21
FROGGS does it now 21:27
dah!
gah*
21:36 jnap joined
dalek arVM: ae04515 | jonathan++ | src/io/fileops.c:
Don't try to sync things that can't.
 21:46
FROGGS cool 21:48
hmmm, v5-j explodes because it can't find Perl6::Pod 21:49
jnthn: tomorrow by that time I will have v5 on jvm I guess... 21:53
but now: sleep
gnight all
timotimo jnthn: i just got some $workload for $dayjob, so we'll see if i'll get to something semi-working for smallbigint tomorrow 21:56
jnthn timotimo: OK, no hurry. I'm quite distracted with $dayjob these next days also. 21:57
timotimo d'aaw
well, i don.t think i can keep my fingers off of rakudo and moarvm for long :3 21:58
jnthn :)
22:37 eternaleye joined 23:24 dalek joined 23:47 colomon_ joined 23:55 krunen 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!