CraigBuchek has joined #crystal-lang
e_dub has joined #crystal-lang
e_dub has joined #crystal-lang
CraigBuchek has joined #crystal-lang
CraigBuchek has joined #crystal-lang
CraigBuchek has joined #crystal-lang
Kelet has joined #crystal-lang
CraigBuchek has joined #crystal-lang
CraigBuchek has joined #crystal-lang
CraigBuchek has joined #crystal-lang
CraigBuchek has joined #crystal-lang
asterite has joined #crystal-lang
<Kelet> asterite: Possibly the simplest solution is just to abuse dots. One dot is '#', two dots is ':', ...
<Kelet> Unless I misunderstand
<asterite> Yes, I was thinking the same thing :)
<asterite> But are dots allowed in assembly files in those places?
<asterite> (I just asked you the same in github)
<Kelet> It's weird that the double quotes don't work on Windows. The GNU Assembler manual states that double quotes can be used for symbols. I don't see any platform-specific documentation either.
<Kelet> dots, dollar signs, and underscores should work, but let me try
<asterite> Ah, dollar signs are also good :)
<asterite> and might bring money to the project
<asterite> ( ? )
<Kelet> haha
<Kelet> I've tried two versions of gas but apparently I have a th ird installed with qtcreator
<Kelet> let me make sure that doesn't work
<Kelet> It took me a while to get llvm and clang on my system.
<Kelet> clang has an installer but llvm tools do not.
<Kelet> (And then clang wants mingw installed of course)
<asterite> I can guess. I think they added windows support recently
<Kelet> You can use dollar signs or stack dots
<Kelet> hue.hue..hue$hueeee.e works
<asterite> Cool :)
<asterite> So we can stack dots. Then if we bump into a problem we can change it to something else, but I think that should work
<Kelet> It won't be pleasant to read but it's a solution for now
<asterite> Sure
<Kelet> Bah, it just pains me when tools like GNU assembler do this nonsense behavior
<Kelet> Because there is no real community around such a tool
<Kelet> Would probably take a fair amount of time to get an answer on a mailing list
<asterite> :(
<asterite> Ok, I’ll do a quick commit in some minutes replacing those invalid symbols with dots. Then we can try again
<Kelet> Alright I'm going to download Ubuntu and throw it in a virtual machine to do the compiling for me
travis-ci has joined #crystal-lang
<travis-ci> [travis-ci] Build details : http://travis-ci.org/manastech/crystal/builds/23219245
travis-ci has left #crystal-lang [#crystal-lang]
<travis-ci> [travis-ci] manastech/crystal#1015 (master - 7dc6b95 : Ary Borenszweig): The build passed.
<Kelet> I tried to compile Crystal on my laptop and it was pretty much locked for about an hour with no indication of progress
<Kelet> (It's a slow machine)
<asterite> (I didn’t commit yet, that was a recent commit where I merged another branch)
<asterite> Really? Wow, it shouldn’t take that long
<Kelet> Well
<Kelet> I'm talking ~700mhz
<asterite> Well, be sure to check out the latest release which I just pushed, it’s a bit faster
<asterite> Ah...
<Kelet> Yeah, the unfortunate story of my main development computer
<Kelet> But my Windows desktop has a modern CPU so I'll just virtualize a Linux box
<asterite> Cool
<Kelet> By the way, how far would you say you're off from beta? A ways?
<Kelet> I've never actually used Crystal until today. A year and some change ago someone in ##ruby was telling me about it and I started watching it.
<Kelet> Was kind of waiting until someone came in and got it working on Windows, but I realized that might not be for a while now.
<asterite> Mmm… we still need lambdas and closures to work well
<Kelet> Is there some concurrency model?
<asterite> That’s the other thing
<asterite> which we plan to have
<asterite> but we need to have lambdas and closures very well for this
<asterite> @waj has a better idea than me about it
<Kelet> As long as there is some type of heavyweight OS thread that does real parallelism
<Kelet> and also some type of lightweight thread that is not parallel
<Kelet> I'll be happy
<asterite> but we’ll use libevent or micoro for lightweight threads with message passing
<asterite> and a Thread class
<asterite> lightweight processes, I mean
<asterite> @waj wants to have processes like erlang, where you can fire up a lot of them real fast, and each have their own stack and, maybe, heap
<asterite> So I guess those are the things we plan to have to reach beta
<Kelet> interesting
<asterite> but there are so, so many things to do (besides that)...
<Kelet> I'm not too privvy on anything really but
<Kelet> I think Erlang can do what it does so well because it runs on a VM
<asterite> I don’t know
<Kelet> Either way, this language seems awesome. There are so many cool languages out there today. It's a shame they don't get more attention.
<asterite> On January 31 I got a mail from @waj that says
<asterite> (I have to translate from Spanish)
<asterite> he did some tests with coroutines in crystal
<asterite> he used PCL
e_dub has joined #crystal-lang
<asterite> he fires up a process and waits for a message with a number
<asterite> if the number if greater than zero, it creates another process and sends it the same number minus 1
<asterite> it seems it’s a typical example to test how fast you can fire up processes
<asterite> He said he could fire up 1 million of these processes that send messages to each other in just 3 seconds
<asterite> but in Erlang it only took 1 second!
<asterite> So then he tried with another library, micoro, which said it was faster than PCL but less portable
<asterite> it took just 300 milliseconds
<asterite> So, 10 times faster than PCL and also 3 times faster than Erlang
<asterite> I don’t think a VM can be faster than native code (some times it can)
<Kelet> Maybe I don't understand what processes are
<Kelet> Most operating systems wouldn't allow 1mil processes
<Kelet> And yeah, Erlang is very scalable but also slow. The U.S. Navy tried using Erlang but found it was 11x slower than an analogous C++ solution so they abandoned it
<Kelet> despite it obviously being easy to develop with and creating less bugs
<Kelet> (Although this was an acoustic ray tracer, so it was calculation-heavy)
<asterite> Ah, I see
<asterite> Yes, I’m not sure Erlang is for doing such programs :-P
<Kelet> OK, I'm installing Ubuntu right now so I can easily play with Crystal
<Kelet> BTW, is it planned to have a gc where you can say
<Kelet> gc.collect(600ms) etc
<Kelet> like Lua or Nimrod
<asterite> You mean, collect with a time limit?
<Kelet> yes
<Kelet> For things like video games, it is important
<asterite> Right now we are using the boehm gc
<asterite> but just because it was easy to integrate it
<Kelet> Is there anything specific planned for the future?
<asterite> we had in mind to have gc combined with some sort of automatic reference counting
<asterite> but it’s a long/hard task, so for now it’ll be boehm
<Kelet> Your type system
<Kelet> is very similar to one I saw last night
<Kelet> Not much information but it uses a similar union thing
<asterite> Nice
<CraigBuchek|922> @asterite: An Erlang-like concurrency model would be awesome!
<asterite> Yes, @waj really likes it, so I’m sure we’ll end up with something similar :)
<asterite> @Kelet I just pushed a commit with the chars replacement. To have a compiler that does this mangling, you need to do the cross compile thing and add “windows” to those flags. Be sure to do llc + clang then. Then you can try compiling that hello.cr file again, send it to windows and it should hopefuly work.
<asterite> In my case it was: --cross-compile "darwin windows x86_64"
<asterite> (the problem is that some structures are only defined for darwin and linux, like c’s file stat, so the compiler won’t compile if neither linux nor darwin are defined)
travis-ci has joined #crystal-lang
travis-ci has left #crystal-lang [#crystal-lang]
<travis-ci> [travis-ci] Build details : http://travis-ci.org/manastech/crystal/builds/23221533
<travis-ci> [travis-ci] manastech/crystal#1016 (master - 4cb29a3 : Ary Borenszweig): The build passed.
<Kelet> asterite: Even on Ubuntu your libunwind is out of date
<asterite> So bad :(
<Kelet> hmm come to think of it setup gets LLVM 3.3
<Kelet> On Windows I have 3.4
<Kelet> not sure if that messes with anything
<Kelet> I don't know why, but it never uses the new name mangling
<Kelet> i definitely have the latest revision and I recompiled
<Kelet> and i definitely cross-compiled for windows
<asterite> Mmm...
<Kelet> or at least i ran bin/crystal src/compiler/crystal.cr -o deps/crystal
<asterite> Did you do it in that Ubuntu?
<Kelet> yeah
<asterite> and afterwards did you run llc + clang on ubuntu?
<Kelet> no, I'm running that on Windows. Am I doing it wrong?
<asterite> Yes… the same thing happened to me just some minutes ago :)
<asterite> The thing is
<asterite> you must do bin/crystal src/compiler/crystal.cr —cross-compile “linux x86_64 windows”
<asterite> that will generate a crystal.bc file
<asterite> and output the command to build crystal with those flags
<asterite> so you must execute it in ubuntu
<asterite> and you will have now a “crystal” executable
<Kelet> ok
<asterite> then with that executable you can compile the hello.cr file, also with —cross-compile so you can copy the ‘bc” file
<asterite> maybe it would have been simpler to change the mangling for every os, or enable it with a flag
<Kelet> tbh
<Kelet> i would find a smarter way to mangle it maybe, and do that for all OS
<asterite> Sure
<asterite> For now I just wanted to do the simplest thing that could work so we can get into more interesting stuff
<Kelet> ls
<Kelet> oops :O
<CraigBuchek|1194> LOL.
<Kelet> asterite: I had to remove the x86_64 as I installed x86 ubuntu but
<Kelet> other than that, it works
<asterite> Yay! :)
<asterite> I’m thinking what’s the next step
<Kelet> i tried to compile without --prelude=empty (lol)
<asterite> We can try to compile an empty file, with the regular prelude, and run it in windows
<Kelet> and it says undefined constant Stat
<Kelet> src/file.cr:19
<asterite> good
<asterite> So, we can defer files for later
<asterite> In src/file/stat.cr you can see Stat isn’t defined for windows
<asterite> so define it empty for now and maybe it will compile
<asterite> Or, in prelude.cr, put the `require “file”` inside the else part of an “ifdef windows”
<Kelet> undefined constant C::ModeT
<Kelet> in src/dir.cr
<asterite> Hmm...
<asterite> In c.cr, define ModeT as UInt32 for now
<Kelet> ill just put UInt32 for now
<Kelet> lol
<asterite> :)
<Kelet> Error in src/raise.cr:120: instantiating 'caller()'
<asterite> Well, you’’ have to put stubs until it works… I guess later file.cr and dir.cr will have a huge section dedicated to windows (or we can put that in other files)
<Kelet> fun __crystal_raise(unwind_ex : ABI_UnwindException*) : NoReturn
<Kelet> that looks nasty
<asterite> :-P
<Kelet> also same thing for raise.cr:123:
<asterite> put the caller.each call inside the else part of an “ifdef windows"
<asterite> I think for now the best thing to do is just ignore everything that doesn’t work in windows
<asterite> later we’ll deal with each of them
<Kelet> the more i get rid of
<Kelet> the more i get
<Kelet> :/
<Kelet> I think I'll have to do this another day while documenting every change
<Kelet> otherwise it is no good
<asterite> ok
<asterite> now I’m thinking, the compiler uses exceptions and libunwind… I wonder if there’s something similar for windows
<Kelet> Yeah, that was where all the errors are coming from
<Kelet> Everytime I fix 1, 2 more pop up
<asterite> Is it always an “undefined …” method?
<asterite> error, I mean
<Kelet> pretty much
<Kelet> But then sometimes removing one of those makes a nil error
<Kelet> etc
<asterite> Ah, right
<asterite> Yes, it will be tough in the beginning
<asterite> moving from mac to linux was also hard, because types were incompatible so things just crashed at runtime
<Kelet> Ah well, back to work. Nice speaking with you, and I'll try to help you think about how to handle the libunwind thing
<asterite> Thank you!
<asterite> Nice speaking with you too
travis-ci has joined #crystal-lang
travis-ci has left #crystal-lang [#crystal-lang]
<travis-ci> [travis-ci] Build details : http://travis-ci.org/manastech/crystal/builds/23227581
<travis-ci> [travis-ci] manastech/crystal#1017 (master - ac42a12 : Ary Borenszweig): The build passed.
e_dub has joined #crystal-lang