<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.
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>
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
<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
<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>
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
<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"
<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
<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