<vegai>
I'll try to recompile it myself based on the instructions there
<vegai>
missing librt.a :-|
<vegai>
silly arch linux and its silly crusade against static linking...
havenwood has quit [Ping timeout: 244 seconds]
BlaXpirit has joined #crystal-lang
dbackeus has joined #crystal-lang
<vegai>
well, no luck there.
wonderbreadz has quit [Read error: Connection reset by peer]
wonderbreadz has joined #crystal-lang
sdogruyol has joined #crystal-lang
zamith has joined #crystal-lang
<zamith>
How feasible/interesting would it be to have pattern matching, on top of method overloading? Has this ever been discussed here?
<jhass>
the issue I see is that the only structured datatype crystal knows something value wise about at compile time is Tuple
<jhass>
so pattern matching would, I guess, complicate that runtime method dispatch a lot, and also bloat the binaries a bit since now you would need to include a lot more, if not all, methods/functions even if they're never used
<jhass>
and then, pattern matching is something many functional languages as tool to solve a certain problem class, OO languages choose different tools for that problem class and having both in the same language could feel a bit odd
<jhass>
*use as a tool
sdogruyol has quit [Remote host closed the connection]
<BlaXpirit>
wisely said
<dbackeus>
I seem to remember that Crystal was supposed to infer if a variable is nil or not if it passes through an if statement, but maybe I'm missing something? http://play.crystal-lang.org/#/r/9rr
<BlaXpirit>
dbackeus, there is a remark about this in docs
<BlaXpirit>
can't infer this about class variables
sdogruyol has quit [Remote host closed the connection]
sdogruyol has joined #crystal-lang
waj has quit [Quit: waj]
sdogruyol has quit [Remote host closed the connection]
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: http://git.io/vOiCy
<crystal-gh>
crystal/master 29890f8 Ary Borenszweig: Fixed wrong error message for "no overload matches" or "wrongn number of arguments" when tuple is involved
luislavena has joined #crystal-lang
<travis-ci>
manastech/crystal#29890f8 (master - Fixed wrong error message for "no overload matches" or "wrongn number of arguments" when tuple is involved): The build passed. https://travis-ci.org/manastech/crystal/builds/74233007
wonderbreadz has quit [Ping timeout: 246 seconds]
sdogruyol has joined #crystal-lang
havenwood has joined #crystal-lang
waj has joined #crystal-lang
sdogruyol has quit [Remote host closed the connection]
kostya has joined #crystal-lang
sdogruyol has joined #crystal-lang
<crystal-gh>
[crystal] asterite pushed 3 new commits to master: http://git.io/vOiip
<crystal-gh>
crystal/master 81519c6 TSUYUSATO Kitsune: Add spec for running a inherited hook after class def
<crystal-gh>
crystal/master c866f82 TSUYUSATO Kitsune: Fix to run a inherited macro after class def
<BlaXpirit>
dzv, well,... you can't do that with opaque structs :p
<BlaXpirit>
and otherwise - i'm not sure
<dzv>
then i'm stuck
<BlaXpirit>
dzv, you don't understand something
<dzv>
like?
<BlaXpirit>
well you're not supposed to get sizeof opaque struct
<dzv>
yes, yes i am. that's what's required by the c library
<BlaXpirit>
well then it's a crummy library
<dzv>
that's openssl
<BlaXpirit>
then i fall back to "dzv, you don't understand something"
<dzv>
then you don't understand the problem
<BlaXpirit>
i haven't a slightest clue what the problem is, because you haven't stated it
<dzv>
the structures are subject to change between version and platforms. they are considered opaque but sizeof() must be used to allocate memory for the structure
<BlaXpirit>
dzv, the library provides allocation tools
<BlaXpirit>
at least it should and that's how it was with every single lib thatr i worked with
<dzv>
really? how do you allocate a HMAC_CTX?
<BlaXpirit>
find a function CreateHmacCtx or whatever, and it should return a pointer
<dzv>
i see you've never used the library. that doesn't exist
<BlaXpirit>
yes, i'm just hypothesizing based on other libs
<dzv>
then i fall back to "BlaXpirit, you don't understand something"
<BlaXpirit>
dzv, the function is HMAC_CTX_init
<BlaXpirit>
actually no, dzv, you're right
<dzv>
that initializes an already allocated structure for use with other HMAC_ functions. look at the function signature. it doesn't return a pointer.
<BlaXpirit>
so, the answer is you must specify the fields of HMAC_CTX or hardcode its size
<dzv>
as a workaround i could create a small wrapper library with alloc functions and wrap the necessary macros (many functions in in openssl are actually macros) but that's not supported with crystal build
<BlaXpirit>
or make a c wrapper that either
<BlaXpirit>
welp you wrote it yourse;f
<dzv>
so i'm asking for either a) a c header parser (like go) or b) library building support in crystal build
<BlaXpirit>
dzv, no such thing
<BlaXpirit>
i made a c parser and crystal lib code generator written in Python
<dzv>
b) would be easy but it's not on the roadmap. if i made a pull request would it be accepted?
<BlaXpirit>
i don't think that this has to do anything with crystal build
<BlaXpirit>
but i'm just a nobody
<sardaukar>
example: @var ? method_call(@var) : 0
<dzv>
the c wrapper would be in the same git repo as the project. how do you easily build it otherwise?
<sardaukar>
how come the compiler still thinks method_call can be called with nil in this case?
<sardaukar>
is this something that will change?
<BlaXpirit>
dzv, oh building a wrapper. that can be useful
<BlaXpirit>
first of all, i'm not sure if ?: syntax supports this. maybe it's just if var
<sardaukar>
oh ok
<BlaXpirit>
2nd of all, this doesn't work with instance variables
<BlaXpirit>
see link for reasons
<sardaukar>
I though ?: was just sugar for the same thing
<sardaukar>
(for if, I mean)
<BlaXpirit>
sardaukar, maybe it's the same, try it
<BlaXpirit>
(but not with instance var)
luislavena has joined #crystal-lang
<asterite>
dzv: we discussed this with waj several times, maybe you'll be able to ask the compiler to figure out the size, by maybe compiling a small C file and getting its sizeof
<sardaukar>
I get the rationale about instance vars
<sardaukar>
BlaXpirit: thanks
<asterite>
dzv: for now you'll probably have to hardcode the size, using ifdef to vary it depending on platform
<dzv>
asterite: that's what i'm asking for. i just want crystal build to build my library or provide a way to do it.
<asterite>
dzv: but we don't want C files in repos, at least we want to delay having to do that as much as possible if we find other ways
<asterite>
but please open an issue to discuss this, with possible solutions :-)
blue_deref has joined #crystal-lang
<dzv>
personally i think that's a bad approach if you want library support. you have a problem with structures macros etc where they all REQUIRE c wrappers if you want compatibility with the library on all platforms (i don't have access to every platform openssl supports)
<asterite>
dzv: but how do we do that in an efficient way? How does go does it? We are using llvm, go compiles to C (as far as I know) so it's easy to include header files
<dzv>
as part of Projectfile or some other file: specify a list of commands. cd libfoowrapper && make
<asterite>
so you want to ship a library that has C wrappers, mainly C files, compile them to .o, link those and use them from Crystal?
<dzv>
yes
<dzv>
that's it
<asterite>
Ok, how do you access that struct in crystal?
<dzv>
i don't. that's what the wrapper does. it allocates the struct so i don't need platform specific ifdef's for size
<asterite>
So the wrapper just allocates memory for that struct and returns it?
<dzv>
it also has wrapper functions for any c macros so i don't need to reimplement those either
<dzv>
yes
<asterite>
Why the library doesn't give you a function that returns the size?
<dzv>
it doesn't *shrug*. i didn't write it
<dzv>
and it's not a single structure. it's many structures
<dzv>
it's actually nested structures. they are at least 3 structures deep so there's a lot that can change from version to version
<asterite>
but they are still opaque for the user, right?
<dzv>
yes
<dzv>
but the macros operate on them
<dzv>
so i don't want to reimplement those in crystal. i would rather write a wrapper function in a .c file and link to it
<asterite>
I see
<asterite>
I think we could do that
<asterite>
it's simpler than what I was talking about (autodiscovery of C structs)
<asterite>
Another idea that waj had is to be able to embed C functions directly in crystal, without the need for .c files
<dzv>
also, for openssl different versions have different lists of functions. 1.0.? added HMAC_CTX_copy. version prior don't have it. it's possible to put older compatible functions in the c file just like other language bindings have. see openssl_missing.c in ruby for examples
<dzv>
but for simplicity and to make things work right now what could be done?
<dzv>
that's my ticket
<asterite>
I think this is mostly a matter of the package manager or the build process be able to do that
<asterite>
Oh!
<asterite>
:-)
<dzv>
when i last asked it seemed like there wasn't a lot of movement so i tried to work around the issue with shards
<asterite>
Great
<asterite>
Right now you can link to an .o file, but there's no way to make the compiler compile it (or a sort of hook, of course)
<asterite>
I think Rust allows that, and we should probably allow that too
sdogruyol has joined #crystal-lang
<sdogruyol>
hey there
<dzv>
there is a 2nd use case which is rare libraries you want to directly embed in the project structure. something where packages don't exist on various systems and you want the build process simplified for the user
<dzv>
i think a command is appropriate where only support for .c/.o files would be too limiting
<dzv>
but you could add both
<asterite>
the last comment from ysbaddaden would solve these, right?
<dzv>
yes
<asterite>
Great :-) I hope we can integrate his work soon
<asterite>
dzv: the wrapper would allocate the struct and give you a pointer to it?
<dzv>
yes. also i need wrappers for macros
<sdogruyol>
asterite: hey ary genki?
<asterite>
sdogruyol: genki desu :-)
<dzv>
and then there's #if HAVE_FOO_FUNC, define the func. i can use wrappers for that also
<sdogruyol>
asterite: heheh ore mo genki da yo :P
<asterite>
sdogruyol: how do I ask back? I forgot...
<sdogruyol>
asterite: anata ha?
<asterite>
dzv: you'd use malloc in c and then free on crystal's side or something like that?
<asterite>
sdogruyol: oh, I was going to say that
<dzv>
sure
<sdogruyol>
asterite: :)
<sdogruyol>
asterite: i have a challenging question here
<sdogruyol>
asterite: what would it take to make channels multithread by default
<asterite>
dzv: I'll talk with waj and if he agrees (and I think he will) we'll add it to the roadmap. Maybe we can add it under the "package manager" section
<asterite>
sdogruyol: a lot of time and effort :-)
<sdogruyol>
asterite: that's for sure but is it c level stuff?
<dzv>
asterite: would it be upsetting if i was working on that (multithread)? am i duplicating anyone's work?
<asterite>
well, do make it work in a multhreaded environment you'll have to change the runtime scheduler, use locks in channel send/receive, and probably think how to do job stealing. If you do that and send a pull request, we'll gladly review it :-)
<asterite>
and also add the "select" expression, that probably means adding new syntax to the language
<asterite>
so I don't know it's c level stuff, but it's pretty low level
<asterite>
In all honesty, I know I can't do that, but waj can, and probably others too
<dzv>
i have that working. job stealing etc. i don't have the gc working
<sdogruyol>
dzv: oh really that's great
<sdogruyol>
i dont even know what's job stealing lol
<asterite>
dzv: where?
<BlaXpirit>
dzv, talking about that wrapper, why not make just a C lib that returns sizeof every struct
<BlaXpirit>
so you don't lose allocation flexibility
zamith has joined #crystal-lang
<dzv>
not public. there are LibC.printf statements everywhere and i've had to reorder prelude
<dzv>
it's messy currently
<sdogruyol>
dzv: lol that's ok imho :P
<asterite>
yes, the order is bothering for me too, there's a thing with constants and order that needs to be fixed
<dzv>
BlaXpirit: that's what i want to do but there's no way to build the .c files as part of crystal build. all i want is a way to automatically build them
<BlaXpirit>
ok
<dzv>
one problem was TimeVal. it's referenced in multiple places but part of time.cr which includes StringBuilder and a bunch of other things. would moving some structures to libc.cr (or another place) help?
<asterite>
Yes, definitely. I think right now they are placed near to their usage, but moving all of that to a single file would maybe be better, so we can see all dependencies to C at once
<asterite>
and try to shrink that list over time, if possible
<sdogruyol>
i'm completely out of this context :P
<sdogruyol>
heheh
zamith has quit [Ping timeout: 250 seconds]
<dzv>
would pull requests be accepted if i start moving things like TimeVal that have multiple dependencies?
zamith has joined #crystal-lang
<asterite>
dzv: for sure
<dzv>
will do when i have a moment to separate my changes
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: http://git.io/vOMfq
<crystal-gh>
crystal/master 04c11dd Ary Borenszweig: Fixed #1014: moved `IO#reopen` to `FileDescriptIO#reopen` and swap behaviour (self reopens to arg)
NeverDie has quit [Quit: I'm off to sleep. ZZZzzz…]
<sardaukar>
willl: thanks
willl has quit [Quit: Page closed]
<BlaXpirit>
sardaukar, i dont think that does anything related to the number 14
<travis-ci>
manastech/crystal#04c11dd (master - Fixed #1014: moved `IO#reopen` to `FileDescriptIO#reopen` and swap behaviour (self reopens to arg)): The build passed. https://travis-ci.org/manastech/crystal/builds/74316325
<sardaukar>
cool, but still not 100% intuitive, right?
<BlaXpirit>
yeah, sardaukar, these are basically workarounds
<BlaXpirit>
i'd expect this to work
<BlaXpirit>
of course it's difficult to implement or even think about this case, i understand
<BlaXpirit>
sardaukar, it's just that different tuple types are simply incompatible
<BlaXpirit>
>> a :: { Symbol, (UInt8 | UInt16) }; a = { :example, 1.to_u8 }
<DeBot_>
BlaXpirit: Error in line 4: type must be {Symbol, (UInt8 | UInt16)}, not ({Symbol, (UInt8 | UInt16)} | {Symbol, UInt8}) - http://carc.in/#/r/9vh
<BlaXpirit>
didnt need to involve an array to see this effect
<sardaukar>
I'm sure there are reasons, but a coder can dream :D
<sardaukar>
opened an issue, let's see what asterite says
<sardaukar>
I'd love to help out, but I have no idea how to even pick something like this up