github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 07:49
jnthn/lizmat: It's easy to add to the C API to provide one return the hash key on delete (for the MVMHash, because the "value" here is just one pointer) 07:50
nwc10 and I think I know how to make all the "delete at the current itetaror position" work, even with sanity checks on iterator position. 08:13
nine oh, how? 08:15
nwc10 if enforcing sanity checks, as well as having a serial number for the hash "state" in the hash (which the iterator records), on a delete, store in the hash, the bucket number of the last delete 08:20
and reset this to "invalid" (which needs to be ~0 for the UT hash stuff) on an insert 08:21
and for "next" in the iterator, either the serial number must match
or
the serial number must be exactly 1 behind, and the iterator's current bucket must match the hash's last deleted bucket
I belive that this will work. A build is running 08:22
(this works better with open addressing, where "bucket number" is the only state) 08:23
oh yes, debugging question. 08:48
Is there a good way to trigger a breakpoint at the C level by doing something in NQP code? 08:49
in that, for Perl 5, a trick was to put a breakpoint on the C function Perl_pp_study
and then add `study` to you test case code
(as almost nothing uses study. Or reset)
and so you could set a breakpoint in gdb, and it would first get hit at that point in the high level code 08:50
and then you could do your real work
without having to figure out how to skip over all the setup
MasterDuke nwc10: i've stuck a nqp::tanh(0e0) in code and then in gdb just break on tanh 09:06
nwc10 :-)
thanks, that sounds useful
nine MasterDuke: thanks for that! 09:29
nwc10 it seems you actually want nqp::tanh_n(0e0)
but this is exactly the thing I was lookign for
meanwhile, no plan surives contact with the enemy
in that this line of MVMIter.c is currently thwating me: 09:30
116 body->hash_state.curr = body->hash_state.next;
because `next` has already been advanced into safety, but I don't (directly) know that
there will be a solution
but I'm going to mow the lawn and figure it out 09:31
in the end, I think that MVMIter.c can actually get simpler
because my planned new hash has sentinel bytes at both ends, meaning it can easily have a state of "iterator not yet advanced to first", which probably means the whole curr/next dance can go
as I think that it's only needed in the C code to support 09:32
1) delete at current iterator location
2) having iterators that need to be advanced to the first real entry, when the C API (currently) has "first", and gives you the first entry.
but the lawn doesn't mow itself. 09:33
dogbert17 heh, a valgrind error, haven't seen one of these for a while 19:50
for those who might be interested: gist.github.com/dogbert17/caa46f52...2e89587231 19:52
MasterDuke huh. stock build? or small nursery or anything like that? 19:59
dogbert17 stock build
timotimo looks like checking for zero-length seperators may be missing? 20:05
dogbert17 could very well be, cur_sep_pos is zero here github.com/MoarVM/MoarVM/blob/mast...eam.c#L639 when the error occurs 20:07
timotimo yeah i saw
dogbert17 what's the proper fix? 20:07
timotimo it looks pretty much exactly like "an empty seperator at the start of the separators list causes this issue"
do we expect nl-in to be set to "" to give one character per "line"? 20:08
lizmat so there's no sanity check on the separator list ?
timotimo i'd say throw an exception at open time
lizmat throw it at nl-in setting time
timotimo sure
that can be done after opening 20:09
dogbert17 ah, so the fix should be made at a higher level then
timotimo why? 21:44
decoder_set_separators seems like the right spot to me 21:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!