01:16 FROGGS_ joined 01:49 ilbot3 joined 02:20 harrow joined 02:27 harrow joined 02:55 btyler joined 03:28 benabik joined
dalek href="https://moarvm.org:">moarvm.org: c8c9e11 | (Alexander Moquin)++ | index.html:
s/releaes/release/
 05:47
href="https://moarvm.org:">moarvm.org: 1b850f8 | timo++ | index.html:
Merge pull request #4 from Mouq/patch-1

s/releaes/release/
timotimo oh, in serialization, all references (for read_ref and write_ref) are 32bit integers, but they are indices to a table 05:52
it would seem logical that we could save a bit of space by using varints there
11:53 zakharyas joined
retupmoca timotimo: I used read_int vs read_varint mostly because I don't entirely know what I'm doing 13:00
timotimo: should I just replace my use of _varint with _int?
timotimo heh 14:06
no, replace your uses of _int with _varint
a _varint can write up to a 64bit integer, but if the integer uses fewer bits, the serialized version will be using fewer bytes 14:07
if it does use all bits, it ends up being one byte longer than it'd have to
but the savings in the general case are significant
especially for things like offsets into tables
which tend to be between 0 and 1000
retupmoca timotimo: gotcha. PR updated! 14:10
timotimo did you check if it still works, though? :) 14:11
retupmoca I did!
timotimo sometimes the length of a thing in the serialization blob has to be known 14:12
so if you put a varint, you have to be a bit more careful
retupmoca well, my little test worked anyway, let me try my actual use-case
timotimo please check if read_varint_func comes with an ensure_can_read or what it's called
otherwise, put ensure_can_read before the read_varint portions; i think there's an assertion function that knows how to handle varints 14:13
retupmoca yeah, read_varint_func has 'assert_can_read_varint(tc, reader);' as it's first line of actual code 14:14
and my modules still compile and work with the _varint 14:15
so I don't think this will break anything my first version doesn't
(and I haven't even seen my first version breaking anything yet!)
14:19 brrt joined
timotimo ah, very good 14:32
JimmyZ Good evening 14:33
timotimo in that case i feel somewhat confident in merging it. revert's cheap anyhow 14:37
dalek arVM: 3f5c316 | (Andrew Egeler)++ | src/6model/reprs/CStruct.c:
Serialize CStruct repr_data
arVM: 80b9695 | (Andrew Egeler)++ | src/6model/reprs/CStruct.c:
s/_int/_varint/ in CStruct serialization
MoarVM: 1a41aa3 | timo++ | src/6model/reprs/CStruct.c:
MoarVM: Merge pull request #94 from retupmoca/cstruct_serialize
MoarVM:
MoarVM: Serialize CStruct repr_data
MoarVM:
MoarVM: fixes a precomp bug: gist.github.com/retupmoca/11290398
retupmoca \o/
timotimo++ # Now my Compress::Zlib stream functions work! 14:38
timotimo yays :)
masak wow! 14:59
16:03 benabik joined 16:16 lizmat joined
tadzik found a pub that serves "the empire strikes" 16:54
I'm gonna bring some bottles to Poznan :) 16:55
17:11 zakharyas joined 18:28 woosley joined 20:08 LLamaRider joined 20:12 woolfy joined
cognominal so long a time I have not used gdb. What does it complain about no debugging symbols found when I have have compiled moar with -g and file(1) says moar and libmoar.so are not stripped? 20:58
s/What/Why/
that's in on an unbuntu running in virtualbox 21:06
timotimo cognominal: it may be complaining about debug symobols for something like glibc or so 21:23
cognominal I tried a simple hello world and it works 21:24
21:25 benabik joined
cognominal I have never debugged program with threads 21:25
timotimo ah, yeah, that takes a bit of getting used to :)
basically you want to do something like "thread foreach bt full" or something remotely similar to that 21:26
cognominal anyway I have not got so far apparently 21:27
22:14 zakharyas joined 22:58 colomon joined 23:26 btyler joined 23:48 btyler 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!