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