<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
<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
<_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