waj has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff has joined #crystal-lang
travis-ci has joined #crystal-lang
<travis-ci> [travis-ci] Build details : http://travis-ci.org/manastech/crystal/builds/21066604
travis-ci has left #crystal-lang [#crystal-lang]
<travis-ci> [travis-ci] manastech/crystal#984 (master - 8b3f8e0 : Ary Borenszweig): The build passed.
e_dub has joined #crystal-lang
bcardiff has joined #crystal-lang
Excurio has joined #crystal-lang
bcardiff has joined #crystal-lang
waj has joined #crystal-lang
bcardiff has joined #crystal-lang
bcardiff has joined #crystal-lang
Prep has joined #crystal-lang
<Prep> hey guys
<Prep> does anyone know if it's possible to get the size of a struct in crystal?
<_jumpman_> i will check
<_jumpman_> can't find it :(
e_dub has joined #crystal-lang
e_dub has joined #crystal-lang
edub has joined #crystal-lang
e_dub has joined #crystal-lang
waj has joined #crystal-lang
waj has joined #crystal-lang
asterite has joined #crystal-lang
<Prep> hey ary
<asterite> Hi Prep
<Prep> got a question for you :-)
<asterite> Tell me :)
<Prep> how hard would it be to add a size call to struct?
<Prep> sometimes you want to reserve some memory via Pointer to store a struct in that gets passed to a method (like File#read)
<Prep> it would be nice to be able to let crystal figure out the structure size to read, instead of hardcoding it, right?
<asterite> Yes, something like sizeof, right?
<Prep> yeah
<Prep> C::MyStruct.size
<asterite> Yes
<asterite> Right now we have byte_size
<asterite> For example: Int32.byte_size
<asterite> Int64.byte_size
<asterite> But it doesn't work in all cases :(
<asterite> but I'm not sure it should be a method, maybe it should be a different expression, like sizeof
<Prep> yeah, if you can interchange "class" for "struct" in some cases, a 'size' call on a struct would be counter intuitive
<Prep> but what's up with byte_size? It doesn't seem to work on a simple struct I made. Why does it work for the Int64 struct?
asterite has joined #crystal-lang
<asterite> I don't remember why is that so
<asterite> but I think it should be something special, sizeof, like pointerof
<asterite> because imagine you have: def foo(x : T); Pointer(Void).malloc(T.size); end
<asterite> and you invoke foo with a union, you want to allocate size for the union, but if size is a method it will be dispatched to each of the union types
<asterite> Another thing is, like you say, sizeof would return a pointer's size if T is a class
<asterite> so we'd need something like instance_sizeof (so for example you can implement "dup" by copying the memory contents)
<asterite> I think implementing sizeof should be easy
<asterite> What do you think?
<Prep> I'm not much of a language designer to feel comfortable to make that call :-)
<Prep> but a way, any way, of letting the compiler decide the size of the struct would work for me!
<asterite> Good. I'll try to implement it today, it should be easy. I'm still not sure about instance_sizeof... how would you handle that case?
<Prep> as a seperate issue?
<asterite> Yes, like, what if you want to get the instance size of a class? A class instance is represented as a pointer to some memory, how to get the size of that memory?
<asterite> I don't know how you do it in other languages... for example in D
<Prep> isn't getting that size a matter of keeping accounts on the sizes of instances before hand?
<asterite> what do you mean?
<asterite> I think I'll start with sizeof, then worry about the other case
<Prep> oh, nevermind. I understood your question incorrectly. You want to know the size of the instance of a class by providing the class. I thought you meant the size of an instance when you already had the instance
<Prep> listen Ary, I really wouldn't know :-) I don't have enough knowledge of these types of things to give you an educated answer :-)
<asterite> It's ok :)
<Prep> hehe, I'm just one to shout "I would like this feature!" and hope someone listens
<Prep> I can manage std features, but I won't be attempting too much compiler features
<asterite> Got it. We will listen :)
<Prep> yeah, you guys have been awesome in that regard. I also follow the back-and-forth with other people who open issues and your feedback is quite impressive
<asterite> Thanks :)
<asterite> We try to involve others into the project's decisions, because we don't program all kinds of programs and others may have better ideas than us
<Prep> I think that works out well for crystal. That is to say, I get the feeling the interest of other people (who contribute) is growing
<Prep> kostya had some nice commits lately
<Prep> as did the cat guy
<asterite> I don't think he's into cats if his nickname is nuisanceofcats :D
<asterite> Yes, kostya is a crack
<asterite> He writes super clean code, I'm a bit jealous
<Prep> well, if he hated cats he would have called himself "ihatecats". I think nuisanceofcats is someone who causes nuisance with his cats
<Prep> just a hypothesis, though
<asterite> :)
<asterite> I have two little cats for about three months, now
<asterite> Sometimes it's really nuisance :-P
<asterite> well, only at 6am every morning
<Prep> oh sure, I have a cat as well so I can relate. The nuisance is always secondary to the cuteness, though :-)
<asterite> Sure
bcardiff has joined #crystal-lang
<Prep> have you guys given the idea of DSLs in Crystal some thought?
<Prep> it's probably very hard to do, considering it's a compiled language, no?
<asterite> You can do some now with obj.yield
<Prep> but the dynamic loading of dsl files would still be a dealbreaker
<asterite> Ah, yes, dynamic loading is a problem
<Prep> I've tried to make a mini rake-like tool (called cake, very clever of me), but it came down to making the compiler part of the tool to do dynamic loading
<asterite> Yes... unless Crystal could also be run in an interpreted mode
<asterite> otherwise you have to compile the cake file, I guess, and run it
<asterite> but maybe this last thing is not a big deal
<Prep> which it can, with --run, but if you offered a load-like command in that mode, you'd have 2 different versions of the language
<asterite> Yeah... that's not something good, then incompatibilities between the two languages start to appear
<Prep> right now, cake behaves like a compiler in that it requires "prelude" and "cake/cakefile", following by creating a Parser for the custom Cakefile and load that all up in a Program
<Prep> I ran into some trouble with the task blocks, but this was more than a month ago and crystal changed a bit in that area, so I might give it another go
<asterite> Sure! I'd love to see a tool like that
<asterite> Ah, if for "task blocks" you mean converting a block into a closure, then it's probably still not working
<asterite> We started working on that but haven't finished
<Prep> indeed
<Prep> although I did got some mixed results another way, but the details have escaped me
<Prep> task(:foo) do
<Prep> puts "Task foo"
<Prep> end
<Prep> didn't work
<asterite> Why not?
<Prep> but I managed to get this working:
<Prep> task :foo, -> do
<Prep> puts "Task Foo"
<Prep> end
<asterite> Ah, yes, right
<asterite> a bit annoying, I know
<asterite> soon we'll make the first one work
<asterite> so for now I think you won't be able to continue with cake :(
<Prep> I can wait :-)
<Prep> I enjoy playing with crystal, even if I bump into some walls now and again
<Prep> I take it you guys have day jobs, so there is only so much time in a day to spend on crystal
<Prep> not to mention the kittens!
<asterite> hehe, in fact right now I'm working on something else in my workplace (html, css, js, *shrugs*)
<asterite> so yes, things are going slow mainly because of this... and the kittens, of course
<Prep> I got a daughter 8 months ago, speaking of things that slow down development! :P
<asterite> Nice :)
waj has joined #crystal-lang
asterite has joined #crystal-lang
<asterite> Hey @Prep, @waj came with an idea for getting the size in Crystal
<asterite> It works :)
<_jumpman_> i wish to have a daughter but instead i will have to program
<asterite> Hi _jumpman_ :)
<_jumpman_> ah the self.size trick is like the trick they teach you in the LLVM tutorial
<nuisanceofcats> i have a dayjob but i work from home ;)
<nuisanceofcats> and i like cats!
<nuisanceofcats> i have a little cat called catfriend
<asterite> @_jumpman_ yeah, it generates a similar code when you ask for a type's size in llvm
<nuisanceofcats> i like it at night when you're asleep and they wake you up by pushing their little heads into your hand
<asterite> yes, they want you to caress them
<nuisanceofcats> *bump bump wake up mr sleepy i want to be cuddled until you enjoy it then i don't want to be cuddled
<asterite> lol
<asterite> aaah... i just realized you are also jumpan
<asterite> :-P
<nuisanceofcats> what gave you the hint :P
<nuisanceofcats> hey are all methods virtual, so if i call def(p : Parent) ; p.virtual() ; end I'll get potentially Child#virtual being called?
<nuisanceofcats> like in D
<nuisanceofcats> D has some de-virtualising capabilities but they're almost useless, recently there's been talk about it being a big performance hit
<nuisanceofcats> especially on CPUs that can't cache indirect function calls
<nuisanceofcats> so anything pre-nehelem/phenom
<asterite> Yes, the "final by default" discussion
<asterite> I'm on that list too
<asterite> Surprisingly, right now Crystal has no virtual methods
waj has joined #crystal-lang
<asterite> it's always done by multiple dispatch
<asterite> Remember the Foo+? If you call a method on that, it will check at runtime the type of the object and dispatch to the correct "foo"... we could do that with a lookup table, but right now it's just a big switch
<asterite> (because the dispatch is triggered for the self argument, but also for any other argument)
<asterite> Another thing that's in our optimization list
<asterite> (surprisingly, the compiler code uses this "slow" dispatch, but it's quite fast, I think)
<asterite> I feel like I'm not using the word "surprisingly" very well :s
<nuisanceofcats> i see
<nuisanceofcats> that's not bad i guess
<nuisanceofcats> when i was messing about trying to implement a fast discriminated union type using llvm...
<nuisanceofcats> a giant switch was best up until 4 types
<nuisanceofcats> then it was faster using some type of table
<nuisanceofcats> at least on this crappy old linux pc
<asterite> in your language nyah?
<nuisanceofcats> yeah
<nuisanceofcats> i abandoned it until i'm able to retire, not possible with a day job and wife
<nuisanceofcats> do you store your discriminated unions on the heap.. like say if it's a variant of "float | largStruct"
<nuisanceofcats> or say int | largStruct | classObject
<nuisanceofcats> so classObject will always be a pointer anyway
<nuisanceofcats> but would the largeStruct also be put on the heap, or would the variant type be large enough to hold the largest type
<asterite> @waj's idea is that eventually all unions will be just a type id and a pointer, so we'd box primitive types and structs on the heap
<asterite> but right now it's a type id and a value that's the largest value of all types
<asterite> so it's like a c union, I guess (except c unions don't store the type id)
<nuisanceofcats> i woulda thought the current system is best
<nuisanceofcats> avoiding the heap when possible
<nuisanceofcats> guess it depends on the use case though
<asterite> Sure... it'll probably stay like this for a long time
<nuisanceofcats> in c++ people use boost::variant which stores on the stack, but it uses the heap for temporaries for types when the copy constructor can throw
<nuisanceofcats> when i told it that my types were all no-throw copy constructible i got a fairly significant performance boost on this financial app i was writing
<nuisanceofcats> avoiding the heap in tight loops can great for performance
<nuisanceofcats> but i suppose with waj's idea, you could still optimise for types <= sizeof pointer by storing them directly in the pointer space
<asterite> Yes, exactly
<nuisanceofcats> i guess to me though when someone chooses struct over class, it's a statement they probably want to use the stack at all costs (except maybe for parameter passing)
<nuisanceofcats> so to override that choice for a variant, i'd have to think hard about it
<nuisanceofcats> someone's going to complain no matter what you do :P
<asterite> hehehe, sure
<nuisanceofcats> D's Algebraic type is like your discriminated union
<nuisanceofcats> that also uses the stack, and if anything stored is a value type, the GC will incorrectly think it's a pointer to memory and avoid reaping it
<nuisanceofcats> in fact, D tells the GC the whole memory is an array of pointers, just in case
<nuisanceofcats> so a large struct could stop sizeof(bytes) from being reclaimed
<nuisanceofcats> i have a thing for Variant/Algebrianc/DiscriminatedUnion types :P
<asterite> Well, it's good then that Crystal supports them natively
<nuisanceofcats> i think so
<nuisanceofcats> it drew me to the language probably more than any other feature
<nuisanceofcats> i wanted the variant type to be built into nyah also
<nuisanceofcats> and with the same type of type-inference, although not quite as ambitious
<nuisanceofcats> but at least on like "a := if { some_type } else { other_type }"
<nuisanceofcats> "@assert(typeof a == some_type | other_type)
<nuisanceofcats> kinda thing
<nuisanceofcats> but i like the way it works in crystal, probably even more
<nuisanceofcats> especially when i found out the type inference for the compiler only takes 4 seconds
<asterite> Do you think that's good? Maybe the compiler is not that big... we don't know yet how fast it'll be with a real big app
<asterite> but since the compiler is the biggest app we have, we don't know
<nuisanceofcats> if there's some separate compiliatino ability
<nuisanceofcats> so you could create libraries and say... assignments to members of that type would cause an error rather than adding a new type to the union
<nuisanceofcats> then you can split any large project up into smaller libraries
<nuisanceofcats> and hopefully only have to recompile each one on ABI changes
<nuisanceofcats> handled by your lovely package manager
<nuisanceofcats> that doesn't exist yet
<asterite> hahaha
<asterite> yes, there's an idea of typing like the interface to a package to avoid recompiling it, but maybe that'll make things harder to interact... we are not sure
<asterite> (and haven't though much about it)
<asterite> There's this: https://github.com/somu/salt
<asterite> I like the name :)
<asterite> and also that he thought about using GitHub as a possible source
bcardiff has joined #crystal-lang
<asterite> Well, @Prep, there you have it. Now you have sizeof(...) and instance_sizeof(...)
<asterite> We'll use instance_sizeof for implementing dup using memcpy :)
e_dub has joined #crystal-lang
<nuisanceofcats> that's the thing i like about dub
<nuisanceofcats> that it just uses github
<nuisanceofcats> so then it forces everyone to use github
<asterite> :-P
<nuisanceofcats> although when i read about their staff members being sexist and their nasty comments online it made me a little sad :(
<asterite> But how do they version the projects?
<nuisanceofcats> with dub it's when you commit a tag v\d+_\d+_\d+
<nuisanceofcats> they have a cron that scans all the packages github repos once every 20 minutes or so
<asterite> and how they consult these tags efficiently to check dependencies? we didn't find a way
<nuisanceofcats> to look for new versions
<asterite> Aaaaaaaaaaaaaaah... that's how!
<nuisanceofcats> but you could also use the github hooks to do it automatically
<nuisanceofcats> maybe
asterite has joined #crystal-lang
<Prep> asterite: that sizeof thingy is a nice solution :-)
<Prep> going to see if it works for me in a minute
CraigBuchek has joined #crystal-lang
<Prep> asterite: hmmm, running into some problems with sizeof
<Prep> sizeof(UInt8) returns 1 (as expected), but adding an UInt8 to a struct increases the sizeof() that struct by 8
<CraigBuchek> Prep: The struct is probably rounded up for alignment.
<Prep> yes, that seems to be the case
<Prep> but wouldn't it be fair to say that this is undesirable behaviour?
<Prep> I know clang has __attribute__((packed)) for structures to counter this
asterite has joined #crystal-lang
waj has joined #crystal-lang
asterite has left #crystal-lang [#crystal-lang]
asterite has joined #crystal-lang
Excureo has joined #crystal-lang
Excureo has joined #crystal-lang
waj has joined #crystal-lang
waj has joined #crystal-lang
bcardiff has joined #crystal-lang