<Regenaxer>
We must locate the place where it corrupts the heap
<Regenaxer>
it crashes only if gc runs by chance on a certain location
<Regenaxer>
in a certain state
<Regenaxer>
Ideally we find a *single* function like 'set' or 'con' which reproduces it
<Regenaxer>
or some other part from 'grid'
<Regenaxer>
Probably 'con' or 'set' are not the problem
<Regenaxer>
they don't make new cells
<Regenaxer>
But *something* in 'grid' seems to destroy the heap consistency
<tankf33der>
no crash.
<Regenaxer>
yes, thought so
<Regenaxer>
then lets go down from top in grid
<Regenaxer>
But (gc) between every primitive
<Regenaxer>
and (msg ...)
<Regenaxer>
to find out after which primitive the heap is broken
<Regenaxer>
You know what I mean?
<tankf33der>
yea
<Regenaxer>
The heap is corrupt at some point, and we find out of (gc) runs only
<Regenaxer>
Perhaps a binary search?
<Regenaxer>
If we have one (gc) which passes, then some primitive, and then the next (gc) crashes, we know it is *that* primitive
<Regenaxer>
(if it is really a bug in pil, which I cannot believe ;)
<tankf33der>
10mins.
<Regenaxer>
ok :)
<Regenaxer>
Just experiment :)
<Regenaxer>
With smaller pieces of code until you can reproduce
<Regenaxer>
Calling (gc) *very* often to increase the chance
<tankf33der>
code still running, afk.
<Regenaxer>
I try here too (though it seems not to happen in Linux)
<Regenaxer>
ok, see you!
<Regenaxer>
It will get *very* slow
<Regenaxer>
I thought more about it. I think it is no normal bug. Has to do with system and/or compiler
<Regenaxer>
And the only thing that comes to mind is alignment
<Regenaxer>
What if allocated heap chunks are aligned at a smaller unit? Then the *last* cell in the heap will be partially outside the legal space and *may* cause a crash
<Regenaxer>
Let's look at what is allocated
<Regenaxer>
When you are back, can you insert a line into heapAlloc() in src/main.l ?
<beneroth>
you will find it, I'm sure of it. Stay cool and get that nasty bugger
orivej has joined #picolisp
miskatonic has joined #picolisp
ubLIX has quit [Quit: ubLIX]
michelp has quit [Ping timeout: 248 seconds]
<Regenaxer>
Hi beneroth! mmmm, well
<miskatonic>
well what?
ubLIX has joined #picolisp
<Regenaxer>
Hi miskatonic, check the logs for the last week or so ;)
<beneroth>
hey miskatonic
<beneroth>
Regenaxer and tankf33der are hunting a weird segfault bug happening on some BSDs
<miskatonic>
hi
<beneroth>
what are you doing, miskatonic ? any picolisp projects?
michelp has joined #picolisp
<miskatonic>
not now
orivej has quit [Ping timeout: 244 seconds]
<miskatonic>
is msgpack implementable in picolisp/ffi? I have heard that this is used for neovim plugins
orivej has joined #picolisp
<beneroth>
lol @ msgpack.. the concept sounds like a bad idea to me (failed before)
<beneroth>
but yeah, sure you can implement msgpack purely in picolisp, or using (native) to ffi to an existing C library (there surely is one), or cli interface using (call)/(pipe)/(in 'list ..)/(out 'list)
<beneroth>
thanks for the hint of msgpack, didn't stumble on it yet, will add to my bookmarks :)
<miskatonic>
what would have been a better idea than msgpack?
<beneroth>
why I think its bad: human readability is a big usability/debuggability feature. it looks like DIME (https://en.wikipedia.org/wiki/Direct_Internet_Message_Encapsulation ) to me, which was an attempt to create a binary MIME format (I implemented dime in picolisp)
<miskatonic>
there is libmsgpack. I don't know where python or ruby use this one or native implementations. yeah, the binary stuff is very bad for debugging
<beneroth>
currently my stand-point is: either stay clear-text or go full custom binary format. "standardized" binary formats tend to never cover all your use cases. and in most environment the clear-text overhead matters way less than the dev-overhead.
<beneroth>
but yeah, YMMV, and I welcome counter-points :)
<beneroth>
also: what is the license of the specification? missing? so it defaults to copyrighted and authors must be asked?
<miskatonic>
so clear text, would be json-rpc ?
<beneroth>
yeah, human-readable text
<beneroth>
preferable UTF-8 encoding
miskatonic has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
ubLIX has quit [Quit: ubLIX]
rob_w has quit [Remote host closed the connection]
inara has joined #picolisp
ubLIX has joined #picolisp
<rick42>
sup peeps
<clacke_movim>
The number of "standardized" structured data formats out there is fantastic.
<clacke_movim>
I've collected names and will record an hpr episode about them all any year now