<FromGitter>
<3n-k1> is this a bug, or part of crystal's type inference? https://play.crystal-lang.org/#/r/9juf ⏎ i feel like since i explicitly typed `f` as taking an argument of type `IFoo`, it should only be able to access things from that module, nothing else
<FromGitter>
<Blacksmoke16> it only would accept types that include that module
<FromGitter>
<Blacksmoke16> which in this case your method does, and compiler knows that other method exists
<FromGitter>
<Blacksmoke16> your type*
<FromGitter>
<3n-k1> i can understand that i guess, just feels icky to me lol
<FromGitter>
<Blacksmoke16> :shrug:
<FromGitter>
<wyhaines> The way that works is the way that I would expect it to.
<FromGitter>
<mwlang> Does build time for Crystal projects grow linearly with lines of code like a C or C++ project would or does build time depend on what was changed since the last compile/build like a Pascal project?
<FromGitter>
<Blacksmoke16> i find it depends on what your code is, a lot of unions dont help
<FromGitter>
<mwlang> well, that's helpful -- tells me that at least design decisions can factor into build times.
<FromGitter>
<mwlang> my project is starting to gain enough of a code base that watching it compile is becoming a thing.
<FromGitter>
<mwlang> vs. just "crystal build" <blink> "done"
<FromGitter>
<mwlang> so what I'm starting to ask or reflect on is whether decision choices factor into the equation at all or if it's going to be a linear thing.
<FromGitter>
<mwlang> I guess with unions, we're talking about time spent resolving all implicit typecasting.
<FromGitter>
<Blacksmoke16> yea, compile times have been getting worse as time goes on (apparently due to LLVM version upgrades)
<FromGitter>
<mwlang> Oh, good. Others are already noticing a big change between 0.29 and 0.35. (that's the other thing I also did..upgraded Crystal across the board)
andremedeiros has quit [Quit: ZNC 1.8.1 - https://znc.in]
andremedeiros has joined #crystal-lang
sorcus has joined #crystal-lang
_whitelogger has joined #crystal-lang
<oprypin>
i'm confused about making bindings to a lib function which returns you a pointer to a struct
<oprypin>
first let's assume that the library itself owns the pointer. and i need the ability to modify that struct in-place, i can't just return it as a value
<oprypin>
so maybe i make a dummy class that just stores a pointer to that
<oprypin>
then what really sucks is that every time i call that library function i'll be getting a different dummy object that has that same pointer
<oprypin>
this is in addition to the fact that sometimes i need to clean up the objects when they're owned by me and sometimes i don't
<oprypin>
my point isn't that i don't understand some part of this process, but that i don't see any non-messy way to represent this in Crystal
<FromGitter>
<alexherbo2> how to specify the block argument type and return value?
<FromGitter>
<alexherbo2> can blocks have named parameters?
<FromGitter>
<iambudi> > how to specify the block argument type and return value? ⏎ ⏎ @alexherbo2 `def test(&block : Int32, Int32 -> Int32)` after -> is the return type
<FromGitter>
<Aaron-JM> Does anyone know the wchar_t conversion for crystal?
_whitelogger has joined #crystal-lang
<yxhuvud>
oprypin: you might be able to use a dummy struct instead if you want to avoid the indirection. as it is only a pointer (and some methods interacting with said pointer, it should work fine.
<oprypin>
yxhuvud, it works for unowned pointers. with a struct i cant ensure destruction of the unowned pointer
<oprypin>
unless there's a way to tell gc about ti
<oprypin>
yxhuvud, it works for unowned pointers. with a struct i cant ensure destruction of the **owned** pointer
<FromGitter>
<alexherbo2> thanks budi
<yxhuvud>
opryppin: Crystal uses a conservative gc. There is no such thing as an unowned pointer - the GC will see the pointer.
<yxhuvud>
You might have a problem if you are interacting with a lib that insists on destructing the objects you have itself if it doesn't keep proper pointers around.
<yxhuvud>
or ah, what you mean when you say unowned pointer was the opposite of what I meant :D
<yxhuvud>
so what you are saying make sense. That is a bit icky indeed.
<yxhuvud>
sounds like a very non-nice library to interact with.
<oprypin>
yxhuvud, thats almost all libraries though
<oprypin>
it is important for a library to not have to expose its structs' exact fields because they're subject to change
<oprypin>
if the struct is supposed to remain opaque, it always is passed by pointer. and crystal has no definition of it, so it doesn't know how to allocate it then, only C knows
<oprypin>
from that it follows that crystal also doesnt know how to deallocate it
<oprypin>
o shit i just found what i was looking for
<oprypin>
the lib allows you to "SetAllocatorFunctions"
<oprypin>
so i just set it to GC.mallocc and forget about needing to deallo?
* FromGitter
* dscottboggs_gitlab just looked up what "conservative" GC means
<FromGitter>
<dscottboggs_gitlab> yeah but not how I thought it worked. I.E. if you call `LibC.malloc` it will still get tracked by the GC.
<oprypin>
dscottboggs_gitlab, im not sure about that
<oprypin>
that would break so many things
<oprypin>
like if theres a C library that offsets all its stored pointers by -4
<oprypin>
the gc would just wreck everything
<yxhuvud>
yeah, and if you are not telling the lib you are not using stuff you might end up never releasing it
<oprypin>
dscottboggs_gitlab, it frees only memory that it was informed about
<FromGitter>
<dscottboggs_gitlab> oh ok
<oprypin>
and i also think that maybe it doesnt scan the entire heap for things that could be referring to it, but only the crystal-owned parts of it. but could be wrong
<FromGitter>
<dscottboggs_gitlab> thanks for clarifying
HumanG33k has joined #crystal-lang
f1refly has quit [Ping timeout: 244 seconds]
f1refly has joined #crystal-lang
<FromGitter>
<alexherbo2> @dscottboggs_gitlab I may have missed something, but how does your example work?
<oprypin>
https://carc.in/#/r/9jy7 would do it along with `LibImGui.igSetAllocatorFunctions(->(size, data) { GC.malloc(size + sizeof(Void*)) + sizeof(Void*) }, ->(ptr, data) { }, nil)`
<oprypin>
>> class A; end; class B; end; p! A.crystal_type_id, B.crystal_type_id