<FromGitter>
<mattrberry> I'm just gonna throw this question out here but I'm going offline now so sorry if I don't respond to replies haha. Just figured I'd get the question out before I go off. I have my bitfield macro here: https://github.com/mattrberry/bitfield ⏎ It lets you define bitfield-like objects like: ⏎ ⏎ ```abstract class Base8 < BitField(UInt8) ⏎ def foo ⏎ puts "bar" ⏎ end ⏎ end``` ⏎ ...
<FromGitter>
<mattrberry> And again sorry if I don't respond tonight, but gotta run soon :)
<yxhuvud>
j8r: no. io_uring requires way too new kernels to be possible to merge. This will be a standalone shard.
yukai has quit [Ping timeout: 256 seconds]
<FromGitter>
<phykos> a good part of LLVM-based languages can be compiled to webassembly. ⏎ can Crystal do that?
zorp has joined #crystal-lang
<yxhuvud>
no.
<jhass>
Doing ABI compat for that would probably be relatively straight forward, but stdlib compat would be a very very big task
<yxhuvud>
There is that, but also getting GC to work could be a nightmare
<jhass>
well yeah. It kinda is part of stdlib I guess though. In theory you could build an stdlib that requires explicit memory management
<jhass>
I guess our line between stdlib and runtime is blurry
<jhass>
I kinda included runtime into stdlib for my statement above, so that's GC + MT/evented IO
<jhass>
/coroutine support
<yxhuvud>
right. I think it is mostly all the runtime stuff that is problematic, rather than stdlib itself.
<yxhuvud>
except for oddities like regexp lib and other dependencies that particular classes need.
<yxhuvud>
but you can do without those. You really can't do without gc or some sort of io.
<FromGitter>
<j8r> yxhuvud it can be a macro, like done to support very new LLVM versions
<yxhuvud>
we don't have any good way to detect kernel versions in macros, AFAIK. And the point of the exercise at this point is to get it working and get something that shows if further interest is warranted or not. Not to produce a pull request.
<FromGitter>
<j8r> ha ok
<FromGitter>
<j8r> I thought you were working just to patch libevent, no Crystal involved
<FromGitter>
<halfdan> Howdy! Building a Crystal wrapper for a C-library. The library has a function that allows passing a void* as context for a callback. No matter what I try I always end up with ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ I tried Object instead of pointer too. The whole point of this argument is to pass an arbitrary value to a callback. What's the crystal way of achieving this?
<FromGitter>
<halfdan> @naqvis Seems to work (same @Blacksmoke16 ). How do I then cast an arbitrary pointer to a Void*? I.e. ⏎ ⏎ ```var = 12 ⏎ pointerof(var) # Pointer(Int32) but should be Void*``` [https://gitter.im/crystal-lang/crystal?at=5fa94b2db4283c208a547ed5]
<FromGitter>
<Blacksmoke16> afaik doesnt using `Void*` just mean that value is ignored?
<FromGitter>
<Blacksmoke16> (granted I don't really know C but my understanding was you use Void* when you aren't using that value or something)
<FromGitter>
<halfdan> @Blacksmoke16 negative - it means you're referencing memory still, but the exact structure of it is unknown
<FromGitter>
<halfdan> you can later cast it to a struct/union/whatever and access memory this way
<FromGitter>
<halfdan> also to answer my own question: `(Void*).as(Int32*)`
<FromGitter>
<Blacksmoke16> 👍 ah gotcha
<FromGitter>
<naqvis> @halfdan `Box.box(var)`
<FromGitter>
<halfdan> Now how can I make the Void* an optional param? Can't use `pointerof(nil)` nor `= nil` as defaults
<FromGitter>
<halfdan> Oooh interesting
<FromGitter>
<halfdan> @naqvis Well... Error: can't use Box(T) as proc argument yet, use a more specific type
<FromGitter>
<naqvis> can you share more detailed code?