<c0c0>
what is the status of the GC implementation?
<waj>
404 - Not Found :)
<waj>
we just started with very simple stuff to implement mark&sweep, but we'll probably delay the implementation until we have the compiler written in crystal itself running
<c0c0>
hmm more like "is there already a plan on how to do it"?
<c0c0>
to state my personal agenda: I always wanted to have a nice language to progam games in
<c0c0>
now crystal obviously fits "nice language"
<waj>
that's great! :)
<c0c0>
But most GC implementations are completely unsuited for games
<waj>
yup, actually the idea is to have a pluggable memory management model
<c0c0>
*FUCKYEAH*
<c0c0>
:]
<c0c0>
you just made me very happy^^
<waj>
so, in theory you'll be able to select if you want to use GC, reference counting or plain old new/free
<waj>
:D
<c0c0>
so what I would really love would be refcounting + occasional mark&sweep (manually triggered / only if space gets really rare)
<c0c0>
have you considered using libgc?
<waj>
libgc is not "accurate" gc... I'm not a big fan of it
<c0c0>
it seems to play nicely with LLVM and implemnting GC seems to be quite painfull
<c0c0>
yeah not accurate is a downside
<c0c0>
but then if there is a layer of ref counting to begin with I'd expect that this woulnd hurt much
<waj>
that's true
<waj>
we're quite open to the discussion and nothing is written in stone yet
<c0c0>
obivously ref counting wouldn't quite yield the best performance
<c0c0>
awesome
<c0c0>
I should definitively read into the sources then :]
<waj>
absolutely!
<c0c0>
on another note, the raytracing sample completely freezes my machine, I have no clue why^^
<asterite>
Do you know which line freezes your machine?
<c0c0>
nope
<c0c0>
I really have no idea whats going one
<waj>
are you running on mac? I didn't tried on linux
<c0c0>
maybe something with my graphics card
<c0c0>
htop doesn't even update befor my machine freezes
<c0c0>
waj ubuntu
<c0c0>
other samples work though
<waj>
64 bit?
<c0c0>
yes
<c0c0>
also great stuff using the carthesian product algorithm for an acctual type system
<c0c0>
don't know any other language doing that
<waj>
Julia actually uses a similar approach AFAIK
<asterite>
:)
<c0c0>
but the guy who published laser 2week before my bachelors thesis deadline...
<c0c0>
(I was doing ruby type inference but with a stupid lattice based approach)
<c0c0>
(laser is a carthesian product algorithm based type inference tool for ruby)
<asterite>
Yes, we expect someone to write about it :-P
<asterite>
Nah, just kidding
<asterite>
Thanks for noticing it
<asterite>
We actually do CPA, but when you have unions in the arguments we don't do the cross product unless there are restrictions. That makes it work faster, and it's more efficient in the generated code
<c0c0>
cross = carthesian I assume?
<c0c0>
what do you mean by "restrictions"?
<asterite>
def foo(x : Int32)
<asterite>
Int32 is a restriction
<asterite>
there
<c0c0>
In other words if I call f(Int), f(String) and f(Union(Int| String) ), you will generate 3 different versions of f
<c0c0>
ah ok
<asterite>
Yes
<c0c0>
instead of 2 with a runtime switch that decides which of the former one to call
<waj>
that topic probably deserves a blog post
<c0c0>
I have to get some sleep, thanks for all the help :)