<Kilo`byte>
well, not that many users can access this box anyways, but i prefer professional solutions :P
<flaviu>
keep in mind that the crystal compiler is also additional complexity here.
<Kilo`byte>
that is my main concern :P
<Kilo`byte>
i mean, i have discovered compiler bugs before :P
<jhass>
the exploitable ones I'd expect in a category of producing segfaulting binaries
<jhass>
which I think is none known left atm
<flaviu>
has anyone run the compiler test suite with fsanitize flags?
<jhass>
doubt it
<Kilo`byte>
btw, completely unrelated, i have talked to someone else about crystal and he was kinda disappointed that it forces a garbage collector on you. which leaved the question: how likely is it that crystal will get a manual memory mode which makes you need to manage memory manually?
<Kilo`byte>
i assume not very likely, but its worth thinking about it
<jhass>
yeah, not very likely
<Kilo`byte>
as the entire standard api would have to be able to cope with that
<jhass>
there are a few ways to obtain memory that's managed by the GC though
<jhass>
basically calling through to LibC malloc/mmap
<jhass>
(and releasing it with LibC free again)
<Kilo`byte>
well, i think the point is that for many things the overhead of a garbage collector is not what everyone was
<jhass>
er, that's not managed
<jhass>
like?
<flaviu>
Kilo`byte: you can always use malloc and free and stack allocation.
<flaviu>
and memory pools
<Kilo`byte>
its not my complaint :P
<Kilo`byte>
tbh, its not like there are many uses of manually managing memory imo
<jhass>
and afaik asterite_ & waj's standpoint is that doing shared libs with Crystal makes no sense due to GC
<Kilo`byte>
flaviu: that sounds horribly hacky and seems like a lot of overhead
<jhass>
flaviu: you can use it as a library to produce new executables, not to modify the currently running one
<Kilo`byte>
so probably the best to do a plugin system would be using a named pipe or similar for communications
<Kilo`byte>
or a binary thats launched by the core with them communicating over stdin/out
<Kilo`byte>
but for that to be comfortable one would need something like marshal
<Kilo`byte>
we'll see
asterite_ is now known as asterite
<Kilo`byte>
only thing you could possibly do would be to compile libraries to some bytecode and then compile the bytecode to native code at load time with a special interface to do stuff like gc initialization
<Kilo`byte>
idk how doable that is though :P
<Kilo`byte>
(it'd also make the code depend on a big part of the compiler)
<jhass>
well, I guess you could have calls or better yet classes and modules tagged with "extract to foo.so"
<jhass>
and then some language level if foo.so_loaded? and stubs that raise if it isn't
<jhass>
but it's really not worth it at this point I'd say
blue_deref has quit [Quit: bbn]
leafybasil has quit [Remote host closed the connection]