asterite changed the topic of #crystal-lang to: #crystal-lang The Crystal programming language | http://crystal-lang.org | Crystal 0.6.1 | Paste > 3 lines of text to https://gist.github.com | GH: https://github.com/manastech/crystal - Docs: http://crystal-lang.org/docs/ - API: http://crystal-lang.org/api/ - Logs: http://irclog.whitequark.org/crystal-lang
<crystal-gh> [crystal] asterite pushed 8 new commits to master: http://git.io/jR4o
<crystal-gh> crystal/master 3e51f66 Ary Borenszweig: Fixed an heredoc bug
<crystal-gh> crystal/master 8ac031b Ary Borenszweig: Added XML::Node.to_xml with options to indent the output
<crystal-gh> crystal/master 4a72073 Ary Borenszweig: Assume all C functions are marked with @[Raises], in case they invoke functions defined in Crystal
<travis-ci> manastech/crystal#2170 (master - 954ade7 : Ary Borenszweig): The build was broken.
eli-se has quit [Quit: Leaving...]
<crystal-gh> [crystal] asterite pushed 1 new commit to master: http://git.io/jRaD
<crystal-gh> crystal/master a0ce199 Ary Borenszweig: Added missing file
<travis-ci> manastech/crystal#2171 (master - a0ce199 : Ary Borenszweig): The build was fixed.
havenwood has quit [Remote host closed the connection]
ryanf has quit [Ping timeout: 252 seconds]
ryanf has joined #crystal-lang
shama has joined #crystal-lang
wanderer has quit [Quit: Page closed]
shama has quit [Quit: (╯°□°)╯︵ɐɯɐɥs]
havenwood has joined #crystal-lang
riceandbeans has joined #crystal-lang
<riceandbeans> I'm having issues getting crystal to compile on my os
ponga has quit [Remote host closed the connection]
ponga has joined #crystal-lang
ponga has quit [Ping timeout: 264 seconds]
ponga has joined #crystal-lang
havenwood has quit []
eli-se has joined #crystal-lang
<eli-se> hi
<riceandbeans> hi
the_asterite has joined #crystal-lang
the_asterite has quit [Ping timeout: 265 seconds]
asterite has joined #crystal-lang
<asterite> riceandbeans: what's your os?
asterite has quit [Ping timeout: 246 seconds]
eli-se has quit [Quit: Leaving...]
eli-se has joined #crystal-lang
Ven has joined #crystal-lang
eli-se has left #crystal-lang ["Leaving..."]
Ven has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wanderer has joined #crystal-lang
<wanderer> jhass: hi, do you know where __DIR__ is substituted? I'm cross-compiling which is why obviously the evaluated path isn't correct anymore. I need something like `evaluated_path.gsub(/home\/.../, "C:/Users/...")`
<jhass> grep didn't turn up anything?
<wanderer> the thing is I found it multiple times
<jhass> did you look at them?
<wanderer> I inserted `puts "here"` to see which one is relevant
<wanderer> so far without any success, nothing was printed yet
<wanderer> I have a `puts` below `when :__DIR__`
<jhass> the only location method
<jhass> (method named location)
<jhass> (again, just grepping here)
<jhass> and grep "\.filename =" should list the others that are Lexer#filename= I guess
<wanderer> jhass: err, I was using the compiler at .build/ and was compiling it to the same location, so I guess it couldn't be overwritten?
<jhass> it should overwrite it
<jhass> does so for me at least
<wanderer> I now deleted the .build/ one so that the installed crystal is being used
<wanderer> now the puts at syntax/parser.cr, line 787 works
havenwood has joined #crystal-lang
asterite has joined #crystal-lang
leafybas_ has joined #crystal-lang
leafybasil has quit [Ping timeout: 245 seconds]
<wanderer> asterite: hey, many specs contain __DIR__ whose path isn't correct anymore when cross-compiling
<asterite> I know, it's because File is not using SEPARATOR everywhere
<asterite> At least not in your copy
<wanderer> no, it's because the path is from an entirely different system
<asterite> Ah... how?
<wanderer> well, __DIR__ emits to /home/ubuntu/crystal-0.6.1/
<wanderer> on windows this path cannot work
<wanderer> I patched it so the correct windows path is emitted, but then there's an error in embed_ecr on executing run
<asterite> What's the patch?
<wanderer> it's just hardcoded for testing
<wanderer> because __DIR__ is always hardcoded
<asterite> But __DIR__ should have the value of the current file's dir, it's not hardcoded
leafybas_ has quit [Remote host closed the connection]
<wanderer> with hardcoded I mean specific to the very system
<wanderer> I changed it to: when :__DIR__ l = MagicConstant.expand_dir_node(@token.location) l.value = l.value.gsub(/\/home\/ubuntu/, "C:/Users/User/Desktop").tr("/", "\\") node_and_next_token l
<asterite> Ok, mmm... but I still don't understand why you need that change
<asterite> Does the compiler use __DIR__?
<wanderer> in syntax/parser.cr, line 786
<wanderer> the specs do
<wanderer> the specs use __DIR__ in various cases (haven't really looked into it)
<wanderer> now I'm cross-compiling the specs, on ubuntu for windows
<jhass> so you cross compile the specs and expect them to run on another system?
<jhass> ah
<jhass> I don't think that's a good goal
<jhass> you should cross compile the compiler and have as goal to be able to compile the compiler (and then the specs) on the target system
<wanderer> yes, but it's not working
<asterite> Ah, I see...
<wanderer> jhass: I have a compiler on windows that can successfully compile something like: Dir.foreach(Dir.working_directory) do |filename| puts filename end
<jhass> I don't think cross compiling the specs will make it work any sooner though ;)
<asterite> But I suggested him to first make all specs pass, then chances of cross-compiling the compiler are high :)
<asterite> But it's true, if __DIR__ is used in the specs its not good
<jhass> well either way around
<jhass> compiling the specs or the compiler, but on the target system
<jhass> I don't see how cross compiling the specs achieves much :)
<asterite> But if you don't have a compiler on the target system you can't compile the specs there
<wanderer> the win-compiler is able to compile such a small example, however, when trying to compile the compiler itself, strange errors occur
<asterite> Well, if something like File is not working well on windows, the compiler won't work
<asterite> wanderer: did you try compiling samples from the samples directory?
<asterite> It would be really awesome if you'd keep your changes as a github fork, though... we would go so much faster like that
<wanderer> not yet, but I tried to compile e.g. array_spec.cr, when cross-compiling it and linking it on windows, everything's fun and the .exe runs
<wanderer> however, when using the win-compiler for building array_spec.cr, I get "expected 1 to be < 0"
<jhass> cool, I think compiling individual spec files on the target system is a good approach too
<wanderer> *everything's fine*..
<wanderer> jhass: array_spec.cr only works when it's coss-compiled, though, when using crystal.exe (the compiler I cross-compiled) I get "expected 1 to be < 0" when running array_spec.exe
<jhass> yeah, so that's something to work on ;)
<wanderer> I don't know where to start fixing this, though
<jhass> can you link which spec it is that's failing?
<wanderer> when compiling the compiler sources with crystal.exe I get "undefined constant File"
<wanderer> not really, it just says "................................................................................ ..................................expected 1 to be < 0"
<jhass> I think we had a doc formatter or so? I don't recall
<jhass> anyway, there's no randomization, in theory you could count the it blocks ;)
<asterite> Yes, you can run the spec with -f d
<jhass> ^ do that in stead of counting :P
<asterite> wanderer: if you want us to help (well, you are helping us, or we are all helping each other :-P) you'll have to put the code in github at one point
<wanderer> I can try
<wanderer> is it a 0.6.1 branch then?
<asterite> Yes, you can branch from 0.6.1, otherwise you'll have to include libevent and libpcl as mandatory
<asterite> If you don't want to learn git from the command line you can use SourceTree
<wanderer> btw compiled the libs llvm, gc, pcre, crypto, ssl and zlib statically, so this should work on windows, too, and as they're static there are no imports
<asterite> (I use it, I'm lazy :-P)
<asterite> Cool
<wanderer> libllvm.a is 60mb, can you push individual files that big to github?
<jhass> 100M is the limit iirc
<wanderer> where to put the `-f d` btw?
<asterite> You can do: bin/crystal spec/std/array_spec -- -f d
<asterite> bin/crystal spec/std/array_spec.cr -- -f d
<asterite> You can put the .a files somewhere else, I guess
<riceandbeans> asterite: dragonflybsd
<asterite> I don't know much about oses... mmm... does that derive from centos or debian?
<riceandbeans> no
<riceandbeans> it's a BSD
<riceandbeans> it's a fork of FreeBSD from 11 years ago
<jhass> haha, is that still developed? :P
<riceandbeans> yes
<jhass> I thought Free and Net are basically the only active ones :P
<riceandbeans> no
<jhass> oh, OpenBSD there was too
<riceandbeans> there's probably an average of 40 commits made per day to dragonfly
<asterite> I guess you'll have to cross-compile the compiler then
<wanderer> btw. array_spec fails at Array#<=>
<wanderer> hm.. it's crashing at `(a <=> c).should be > 0` with the msg `expected 1 to be < 0`
<wanderer> *failing
leafybasil has joined #crystal-lang
<jhass> what's a and c?
<wanderer> it's in array_spec.cr, both are arrays being compared with <=>
<wanderer> so actually it seems like it should be passing, because the line is `(a <=> c).should be > 0` and it gets 1, which is > 0, but somehow it's expecting it to be < 0, although the line says > 1
leafybasil has quit [Ping timeout: 256 seconds]
<jhass> that's weird, I wonder if it could be an encoding issue? or endianess or something? Or maybe something completely else, no idea actually
<wanderer> ye, seems like more of a general problem
<wanderer> I'm checking out Be(T)#match atm, @op is actually < when it should be >
<wanderer> in src/spec/expectations.cr
<wanderer> `(a <=> c).should be > 0` makes @op falsely <
<wanderer> `(a <=> c).should be >= 0` makes @op correctly >= and it passes
<riceandbeans> asterite: but that's the thing man, at this point, your code is written in your own code
<riceandbeans> there isn't some C source I can compile
<riceandbeans> it's now a chicken and egg issue
<riceandbeans> I need crystal to build crystal
<asterite> This is what we are doing to make crystal happen on windows
<asterite> but it's a long and hard task :)
<asterite> Well, wanderer is doing all the work, really
<riceandbeans> my friend would love this language
<riceandbeans> he's dreamt of the syntax of ruby with the performance of c
<asterite> wanderer: you can try and see if the spec passes outside the spec, that is, write a small program and use puts. Maybe something with the spec isn't working well
<asterite> riceandbeans: do you have some other system (linux, mac) where you can install crystal? From there we can try to cross compile it to DragonFlyBSD
<riceandbeans> asterite: I can spin up a linux vm
<riceandbeans> that's trivial
<asterite> Ah, in fact, you can use docker: https://registry.hub.docker.com/u/manastech/crystal/
<asterite> That has crystal already... though I'm not sure it has everything there to compiler the compiler
<asterite> Or this one: https://registry.hub.docker.com/u/manastech/crystal-head/ (that should have everything, because it compiles the compiler)
<wanderer> asterite: the code itself works, however, `(a <=> c).should be > 0` it invoking Be(T)#self.< instead of Be(T)#self.>
<asterite> So it's invoking a wrong method?
<wanderer> sec, I'll link you the llvm code
<wanderer> asterite: http://pastebin.com/n0XVwnyc
<wanderer> are the dots supposed to be?
<wanderer> I can't even tell what functions is called because of them
<riceandbeans> not a fan of docker, and that doesn't fix the issue of it being in dragonfly
<riceandbeans> I'll have to try cross compiling
<riceandbeans> getting it into freebsd ports would be a good thing
<wanderer> asterite: I'll push it to github, so that you're able to debug it yourself, you know ways better where to look as for why the wrong function is called
<asterite> wanderer: aha!!
<asterite> Now I know the problem
<asterite> It's "easy" to fix :)
<wanderer> that'd be cool :P
<asterite> Yes :)
<asterite> The problem is here: String.new(22) do |buffer| LibC.sprintf(buffer, "%g", self) len = LibC.strlen(buffer) {len, len} end
<asterite> Well, not there, obviosuly
<wanderer> so it's "normalizing" the names?
<asterite> We use long and strange names for our function names, like *Exception::new<String>:Exception
<asterite> Now, unix and mac seems to be OK with that, but windows doesn't like some chars in function names, so for those we replace them with a dot
<asterite> I remember that was our first fix to make it work in windows
<riceandbeans> asterite: how does performance compare to topaz?
<asterite> It was just a test
<asterite> riceandbeans: check this https://gist.github.com/havenwood/4724778 (but it's unfair to benchmark Ruby vs. Crystal, Ruby can do more magic stuff)
<asterite> wanderer: so what we need to do is encode those chars in a different way
knoopx has joined #crystal-lang
<asterite> Basically, turn every char to its numeric value... I think that can still produce clashes, but it's harder. For now we can use this
<asterite> I was thinking that maybe that would mean the end of Crystal... at first. But even with those performance improvements, you don't get static checks, so I think we are safe for now :)
<riceandbeans> isnt that jvm?
<asterite> Ah, yes, that's another ugly thing about that, you need the elephant jvm
<jhass> which is impractical for CLI utils for example, because of boot time
<riceandbeans> jvm means slow startup, memory leaks, and security issues
<riceandbeans> no thanks
<asterite> Well, good then :)
<asterite> The argument about CLI is true. I was testing https://github.com/ddfreyne/rcpu and https://github.com/ddfreyne/rcpu-lang and it feels great to have something compiled instantly
<crystal-gh> [crystal] asterite pushed 6 new commits to master: http://git.io/jzgZ
<crystal-gh> crystal/master da1c153 Ary Borenszweig: When using "ditto" for a comment, this copies the previous comment
<crystal-gh> crystal/master 7daa6ee Ary Borenszweig: Simpler String::Formatter
<crystal-gh> crystal/master 5c45ce5 Ary Borenszweig: Support floats in sprintf
<wanderer> asterite: MinGW doesn't seem to have any problems with special characters
<wanderer> I commented out the snippet you mentioned, now the functions have their real names and array_spec.cr gets compiled and linked properly
<asterite> wanderer: you can try commenting that ifdef then
<wanderer> lol, this was also the cause of that strange "undefined constant File"-error
leafybasil has joined #crystal-lang
asterite has quit [Quit: Page closed]
asterite has joined #crystal-lang
<asterite> wanderer: what, it works now?
<wanderer> checking atm
knoopx has quit [Remote host closed the connection]
<travis-ci> manastech/crystal#2172 (master - 5ed8410 : Ary Borenszweig): The build has errored.
<wanderer> asterite: apparently yes, just compiled crystal_win.o with crystal.exe and linked it to crystal_win.exe
<jhass> asterite: mmh, not sure I like that ditto depends on order. Wouldn't see: #bar or something work?
<travis-ci> manastech/crystal#2172 (master - 5ed8410 : Ary Borenszweig): The build passed.
<asterite> jhass: probably, but I think it's more direct if you have the documentation right there instead of having through a link
<asterite> I actually copied that from D, they have ditto too
<jhass> ah, mh
<jhass> I think copying from arbitrary places would be nice too though
<asterite> Yes, I think that too. But one step at a time :) (this was very easy to implement)
<jhass> sure
<asterite> D actually has a full macro language in their docs, but I think that's too much
<jhass> yard is pretty powerful too
<asterite> wow, I didn't know yard supported that
<asterite> wanderer: cool!! I can't believe you made it :)
<asterite> wanderer: try compiling the compiler a few times. So compiler A -> compiler B -> compiler C. If B and C have the same size, it's a good sign :)
<wanderer> already did, works
<asterite> :o
<asterite> Can you compile the specs now on windows?
<asterite> In any case, do you want me to push your changes to master?
<wanderer> doesn't the compiler itself use libuv or libevent or something like that, after 0.6.1?
<wanderer> I don't know if the changes I made are compatible with the trunk
<wanderer> however, I can zip and send them to you
<asterite> Sure. These are changes made from the tag 0.6.1, right?
<wanderer> yes
<asterite> Cool :)
<asterite> So yes, please send me the zip. Thank you so much!! When you said you will port it to windows, you really meant it :)
riceandbeans has quit [*.net *.split]
Excureo has quit [*.net *.split]
<wanderer> preparing the package atm, however, I haven't added creating processes, waitpid, deleting environment variables & others yet, also the compiler's interface is still the same, means I call it with --cross-compile "windows" on windows, you'll see when I send it to you
Excureo has joined #crystal-lang
riceandbeans has joined #crystal-lang
riceandbeans has joined #crystal-lang
asterite has quit [Ping timeout: 246 seconds]
wanderer has quit [Quit: Page closed]
wanderer has joined #crystal-lang
<riceandbeans> is crystal ready for anything production?
<jhass> tricky question
<jhass> I think you need to decide that for yourself, start with a hobby project
<riceandbeans> how does the code thread?
<jhass> pthread
<jhass> also some preliminary libpcl stuff
asterite has joined #crystal-lang
<asterite> riceandbeans: I don't know. But we are using it in our workplace for a Slack bot, and it's working great. Of course it's an internal tool so it's not production. There's also DeBot made by jhass which is working pretty well. I don't know when one language starts to be "production ready"
<asterite> Oh, and this site https://crystalshards.herokuapp.com/ is done in Crystal, and it's working good too :)
<jhass> yeah, after we slayed the compiler bugs, github_desktop_notifications is running stable too
<jhass> well, "we", asterite did :P
<asterite> Well, you discovered the bugs ;-)
<asterite> Ah, you are using it and it's showing the notifications alright?
<asterite> Memory usage stays stable?
<asterite> By the way, the slack bot communicates with some google apis, quickbooks, and one service we have (brium), and uses redis as a backend, so I think Crystal is pretty capable by now, but there are still lots of things to do
<jhass> yeah, as far as I can tell it's stable
<asterite> I think I'll try to make github_desktop_notifications do that command line thingy on mac
<jhass> well, the neat things I have with libnotify are being able to update the notification and react to closing it, clicking on it and can even add buttons ;)
<asterite> Yeah... I was looking at the code, I have no idea how to do that with that terminal command :(
<jhass> you can't really, libnotify's equivalent is the notify-send command, which exposes none of those
<jhass> we could extract the github api client, though I don't have motivation to turn it into something full-blown myself atm :)
<asterite> Hehe, I know what you mean... those APis are huge and mapping them is boring
asterite has quit [Ping timeout: 246 seconds]
<riceandbeans> I'd say production ready is when you're willing to put your name on the line by using the language for something customer impacting
<riceandbeans> language or product
<jhass> dunno, it depends on the something really
<jhass> at this point you will most likely run into language bugs while developing something though
<jhass> so you would need to allot time to fixing such stuff
wanderer has quit [Ping timeout: 246 seconds]
asterite has joined #crystal-lang