<asterite>
On my machine it's -lpthread -ledit -lm
<asterite>
zlib might be libz
canhtak has quit [Quit: canhtak]
<Exilor>
asterite: you can marge my Matrix pull request already if there are no objections
<asterite>
Exilor: sure! I still didn't have time to finish looking at it
<Exilor>
asterite: ok, just in case you hadn't seen my comment at the PR :)
ismaelga has joined #crystal-lang
<jhass>
asterite: I found a workaround by casting the return value of a rather unrelated map, with which it is working now. Using a compiler from that branch produces a binary that raises "Could not raise" immediately, even though I'm not starting a thread
<jhass>
there'S some round trips of passing functions to GLib and so on though
<asterite>
jhass: :(
<asterite>
jhass: can you go back to the point where you got the "can't infer block type" and compile that with the other compiler?
<jhass>
oh, I did of course, forgot to mention
<asterite>
jhass: so sad, I thought I had it
<jhass>
My application doesn't seem to be working right yet, but I guess I'll put it up so you can look at it
<asterite>
Thanks :)
<asterite>
Is it with gobject?
<stuffl>
asterite: it was "zlib1g-dev", now it's stuck on "-ledit"
<jhass>
asterite: yeah, and libnotify, you'll need a VM
asterite has quit [Ping timeout: 246 seconds]
weskinner_work has joined #crystal-lang
weskinner_work has quit [Ping timeout: 246 seconds]
waj has quit [Quit: Leaving.]
<stuffl>
How do I install the llvm dependencies?
zamith has joined #crystal-lang
<jhass>
what's your OS again?
<stuffl>
ubuntu
<stuffl>
uses apt-get
<jhass>
what do you run and what's the error?
<stuffl>
I need the libs required by llvm, the ones from `llvm-config --system-libs`
<stuffl>
I installed crystal by adding it to the repo and then I downloaded the source and tried to compile it
<stuffl>
yep
<jhass>
some file in /etc/ld.so.conf.d/ lists that directory though?
Exilor has quit [Quit: Page closed]
<stuffl>
yes, x86_64-linux-gnu.conf
<jhass>
ah, google says you want to install libedit-dev
<jhass>
yay debian :/
<stuffl>
how do you know? tried googling and it gave me nothing about libedit
<stuffl>
it worked btw, thanks
<jhass>
I googled "/usr/bin/ld: cannot find -ledit"
<jhass>
with the quotes
<jhass>
second entry for me had the following summary: "Initially the compilation failed with "/usr/bin/ld: cannot find -ledit" which was solved by installing libedit-dev package. I don't have at the moment ..."
<jhass>
so I didn't even need to click on a result :P
<stuffl>
ah, thanks
<stuffl>
crystal's standard lib is in /src/, everything except /src/compiler/, isn't it?
<jhass>
yeah
<stuffl>
so when compiling crystal itself, you'd only need the compiler-src because you already have the stdlib-src installed with the compiler?
<jhass>
no
<jhass>
the stdlib isn't read from the compiler binary
<jhass>
it's read in source
<stuffl>
what if you compile a normal program which requires sth from the stdlib?
<jhass>
I guess it's somewhere under /opt/crystal/src
<jhass>
the compiler binary should have the path to ^ baked in or called through a wrapper that sets CRYSTAL_PATH to it
<jhass>
also 95% of the stdlib is automatically required
<stuffl>
so it's not like require first looks into the current directory and then if nothing was found into the directory where it was installed?
<jhass>
when you compile the compiler you can set CRYSTAL_CONFIG_PATH to a default list of base directories for lookup, specifying CRYSTAL_PATH when invoking the compiler overrides that value
<jhass>
the package should have built a compiler with CRYSTAL_CONFIG_PATH="libs:/opt/crystal/src" (or wherever it installs stdlib to)
<jhass>
so require "foo" searches in `pwd`/libs first and then in /opt/crystal/src
<jhass>
doing require "./foo" searches relative to the file the require is written into
<jhass>
you shouldn't worry about all this until you hit issues with it though, for the first experiments crystall foo.cr should just work
<jhass>
*crystal
<stuffl>
I was just wondering how the stdlib gets handled in that case
<stuffl>
and what is needed to port it to windows
<jhass>
if you want to hack on the compiler or stdlib (and you're very welcome to), you should clone the repository, run make to get a compiler built from it and tehn run it with bin/crystal
<jhass>
that'll make sure to use the stdlib and the compiler from the repo
<jhass>
uh, probably lots
<jhass>
windows is not too posix compliant anymore
<jhass>
you would start by looking into mingw32 cross compilation with LLVM (does that even exist?) and adding the bindings for Windows
<jhass>
to the standard calls that are different
<stuffl>
I looked at the windows.cr example and at first I didn't know how the stdlib is handled and everything was required manually instead of using prelude.cr
<jhass>
yeah I doubt that still works tbh
<stuffl>
the example works, it also got modified 8 days ago
<jhass>
well, the last few commits were general refactors, that probably just got into the sed calls
<stuffl>
ah
<jhass>
it seems pretty much leave out all the IO stuff, which is different on windows
<jhass>
and for which stdlib doesn't work then I guess
<jhass>
so I see higher chances for proper ARM support than for Windows tbh :P
<jhass>
we only recently brought linux/os x 32bit support up to par
<stuffl>
crystal uses llvm so codegeneration for windows isn't the problem, is it?
<jhass>
doesn't mean I would discourage you from working on it though!
<jhass>
yeah, that's probably not the problem
<jhass>
the work lies into making the bindings/stdlib compatible
<stuffl>
so porting the stdlib and using external references the linker can actually find
<jhass>
yeah
<stuffl>
the c runtime references should be valid by simply linking to msvcrt and other posix functions would need to have wrapper functions which use winapi functions, I guess
<jhass>
wouldn't know, I avoid doing windows dev as long as possible :P
<stuffl>
I still don't quite understand how crystal works, but if I'm not entirely mistaken the only problem is "binding it to windows", which means equipping crystal's stdlib with loads of "ifdef windows"
<jhass>
that's most likely 95% of the work, if not 100%
<jhass>
there's always the chance of hitting a compiler bug that only happens on one platform though :P
<stuffl>
I'm atm in an Ubuntu VM trying to get a little more familiar with the compiler
<stuffl>
but using linux without knowledge is plain annoying, also I use a different keyboard layout on windows which drives me mad when typing in the VM
<stuffl>
also ubuntu with unity is so fugly
<jhass>
well, you have plenty other DEs to choose from :P
<jhass>
keyboard layout: why don't you just set it to the same one?
the_asterite has joined #crystal-lang
<stuffl>
it's a custom one, it's dvorak but with qwerty virtual keys, also many keys are rearranged and some are turned into dead keys and stuff
<stuffl>
I should probably become more familiar with linux and port it
asterite has joined #crystal-lang
weskinner_work has joined #crystal-lang
asterite has quit [Remote host closed the connection]
asterite has joined #crystal-lang
<jhass>
mmh, dvorak is shipped, rest of the stuff would probably need some xkbcomp or what it was tweaking
<jhass>
wb asterite
<asterite>
stuffl: you are correct, with `ifdef windows` things should work, except... we are using libunwind for exceptions, and we don't know what's the equivalent in windows
<asterite>
jhass: thanks :-)
<asterite>
stuffl: let me see if the windows example still runs in windows
<stuffl>
asterite: the msvcrt contains some windows-custom seh-functions
<jhass>
asterite: so your branch seems to workaround the issue, the Could not raise was something else
<jhass>
looking at the commit it feels like a workaround to me though tbh :/
<jhass>
the functions is a -> Void but complains that I return Bool
<jhass>
I thought you fixed that but apparently not fully :/
<asterite>
jhass: you can mark a fun as @[Raises]
<stuffl>
asterite: yeah, it got compiled so I assumed it worked. And as I'm atm having trouble setting up a shared folder in the Ubuntu VM I couldn't inspect the file. Just did, though, and it is ELF64, so it's already completely compiled
<asterite>
jhass: I wonder if we should always treat C functions as possible "raises", so we don't have to mark them individually (I don't know if that could affect performance)
<asterite>
I don't know what's the llvm target host for windows
<jhass>
asterite: it's like def foo(&block); LibFoo.call_me_later(block.pointer); end; foo { raise "nope" } though
<asterite>
stuffl: I managed to make the windows program run :)
<asterite>
I'll update the example's comments
<jhass>
that gives another can't infer block type without the cast
<stuffl>
asterite: when I use the outdated command, it prints "cc windows.o -o windows" but 1. windows.o already is compiled, so that would only link it, 2. when I try to execute the printed command ld says __iob_func wasn't found
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: http://git.io/A8HN
<stuffl>
jhass: just tried to use the winapi function timeGetTime and cross-compile for windows, it's stdcall, however, that's why its name is also mangled, I've now used `fun timeGetTime = "timeGetTime@0": Int32`, which works but 1. only because it has no parameters thus cdecl=stdcall and 2. is ugly to use
<stuffl>
jhass: I should or I have to? does a `for`-loop exist?
<jhass>
it exists in the macro language, ruby does have it, I never checked whether Crystal added it to the normal language
<jhass>
it's highly discouraged to use it in Ruby
<jhass>
>> for x in %w(a b c); print x; end
<DeBot>
jhass: Syntax error in eval:5: expecting token 'EOF', not 'rescue'
<jhass>
mmh
<stuffl>
that's what I got, expecting EOF
<stuffl>
which sounds rather strange
<stuffl>
there must be some error in the parser I guess
<jhass>
yeah
<jhass>
so the answer is no I guess :P
<jhass>
or it's supposed to, but it's so uncommon to use that no one ever noticed it's broken :P
<stuffl>
Also I see no real difference in using .each or for to enumerate over an enumeratable object, the first is probably more idiomatic, but I'd say the latter could be faster
<jhass>
no, it's not faster
<jhass>
all it would do is syntax rewrite to .each
<stuffl>
so blocks do not have any overhead?
<jhass>
since the compiler has no other way of getting the elements of a collection
<stuffl>
I'm not familiar with their facilities
<jhass>
depends, if they're small enough LLVM inlines them
<jhass>
so afaik they do generate a function call, but LLVM optimizes many of those away
<stuffl>
a for-loop, however, would always be a plain-loop
<jhass>
no
<jhass>
see, the things you would iterate over are all written in crystal itself
<jhass>
plain classes
<jhass>
the compiler would need to know the internal representation of whatever you iterate over in order to make it faster
<jhass>
and as said, LLVM is amazing at optimizing stuff, you would gain very little for the cases where you could special case it
<jhass>
even Ruby these days just rewrites for to .each, and using .each directly is even a few microseconds faster interestingly
<stuffl>
hm, the thing is I don't know a thing about what code gets generated, I thought it'd might resemble C++ where every iteration some function like e.g.e iter.get_next() is called
<stuffl>
so I thought using blocks could have overhead while using a simple loop with "getnext()" would be faster
<jhass>
looking at the yield case, it doesn't even seem to generate a function
<stuffl>
what about a bug report regarding the for-loop?
<jhass>
you can always open isssues ;)
<jhass>
also if you have ideas for things to add or change in the language
<jhass>
it's still young enough so that design choices can be made fairly freely
<stuffl>
is there a difference between begin/end-blocks and { }-blocks?
<jhass>
begin / end is used to group code, for example to rescue exceptions happening in that group: begin; raises_or_not rescue; handle; ensure; always; end
<jhass>
I never tried, but I guess Crystal also adopted it for the "do while" hack as seen in Ruby: begin; do_it; end while condition
<jhass>
that last one is actually using the modifier-while ( do_it while condition), just for a group of statements
<stuffl>
oh, sorry, didn't mean begin/end, but rather do/end, like normal blocks, I've seen some ruby code where braces are used instead
<jhass>
blocks however are a concept of chunk of codes you can pass around, sort of like anonymous functions, often closures is used as the generic term
<jhass>
do / end and { / } both generate the same thing, they have a slightly different semantic however, that is their precedence rules differ
<jhass>
foo bar do end passes the block to foo, foo bar { } passes the block to bar
<jhass>
or to generalize, do end passes the block to the leftmost call, braces pass it to the rightmost call
<jhass>
beyond that, in the ruby community, there are different conventions of when to use which that are irrelevant to the language
<jhass>
one's is to use do /end for multiline blocks and braces for single line blocks
<jhass>
another one, and the the one I personally follow mostly, is to use do / end for blocks which you run for their side-effect, like .each, and braces for blocks that you run for their return value, like .map or .select
<stuffl>
ah, and when you're using parenthesis for grouping the semantic difference wouldn't even be relevant, would it?
<jhass>
yes
<stuffl>
got it, thanks
waj has joined #crystal-lang
<stuffl>
is `LLVM::CodeGenOptLevel::Aggressive` as instable as gcc's `-O3`?
<jhass>
uh, no idea tbh
<jhass>
but I can imagine someone asked that on StackOverflow before :P
<stuffl>
just noticed that `--release` is using it and with gcc it's more sane to use `-O2` afaik, so I just wondered
the_asterite has joined #crystal-lang
the_asterite has quit [Client Quit]
asterite has joined #crystal-lang
canhtak has joined #crystal-lang
<asterite>
stuffl: I'm reading the irc logs
<asterite>
stuffl: There's no `for` in crystal, it's redundant so we didn't bring it from Ruby
<asterite>
You can do .each
<asterite>
That is, it's not a mistake in the parser, it was intentionally left out
<stuffl>
asterite: hi
<asterite>
stuffl: hi :)
<jhass>
asterite: why doesn't it syntax error on for x in then? it considers them as method calls?
<asterite>
Yes, `for` would just be a method call
<jhass>
k
<asterite>
stuffl: what's stdcall? A calling convention?
<asterite>
Awesome! I was looking at the llvm c api, not the wrapper :)
<stuffl>
I compiled a small example which uses timeGetTime with Crystal & MinGW
<asterite>
So, yes, I guess we would need to add an attribute to specify the calling convention
<stuffl>
with stdcall, the callee is responsible to clean up the stack, different to cdecl where the caller does that
canhtak has quit [Quit: canhtak]
<asterite>
Like @[CallConvention("stdcall")] or something
<stuffl>
as timeGetTime doesn't have any parameters it effectively makes no difference except for the name mangling
<asterite>
Is the mangling of functions in windows different too?
<asterite>
Oh, it's C++
<asterite>
Ugh
<asterite>
There's no C API for windows?
<stuffl>
the winapi isn't mangled like c++, only regarding stdcall
<stuffl>
but I guess llvm takes care of it
<asterite>
stuffl: jhass: about blocks: non-captured blocks are *always* inlined
<stuffl>
like timeGetTime@0, GetCurrentProcess@0, ExitProcess@4
<asterite>
So blocks have absolutely no overhead
<asterite>
Doing 10.times { ... } is exactly the same as a C for loop
<asterite>
File.open(...) { } is exactly the same as opening, doing what the block does, and ensuring to close, without any function or closure being involved there
<jhass>
yeah, I guessed so later from the codegen code :P
<asterite>
stuffl: I don't think llvm takes care of that if you specify a calling convention, but on our side we could do that automatically for stdcall (adding the @N)
<stuffl>
Implementing a stdcall-attribute that uses the llvm connstant should be enough
<asterite>
Oh, sorry, didn't finish reading the logs
<jhass>
don't worry
<asterite>
In fact it's good that it's like that because even if you don't turn optimizations on, still will be relatively fast
<stuffl>
POSIX has many functions like gettimeofday which are not c-standard and thus on windows the winapi needs to be used for such functions, however, without stdcall it'll fux up the stack
<stuffl>
asterite: can you give some hints how I can easily implement a stdcall-attribute for a `fun` so I can test the name mangling?
<asterite>
stuffl: will you really try to port crystal to windows? Because if you do, that would be really amazing :)
<asterite>
And anything you need (like stdcall), we can see how to integrate it nicely into the language
<asterite>
Well, without changing the compiler I don't see a way to do it
<asterite>
because functions and calls right now use the default calling convention, and there's nothing in the language's syntax to change that
<waj>
Hi! just joining the conversation
<waj>
a Windows port would be amazing! :)
<stuffl>
asterite: I know, but quickly implementing a check in the compiler and call the llvm_set_calling_convention shouldn't take long
<stuffl>
asterite: just need to know where such `fun`-attributes are checked
<asterite>
Oh, I get what you mean
<asterite>
Were you able to compile the compiler just fine already?
<stuffl>
asterite: yes, on my ubuntu vm
<waj>
if you want to start testing things in windows but don't want to make changes in the compiler you can try making a call wrapper in C
<asterite>
stuffl: you will need to change things in two places, it's not hard :)
<waj>
the CallConvention attribute should be the way to go anyway
<stuffl>
waj: it's easier, however, to add stdcall to the compiler, it's not breaking anything and can always be useful
<asterite>
You have a target_def variable there, you can ask for its mangled_name (I think, you must pass self_type to it)
<waj>
OT: I'm really happy with the commit I just pushed. It has big implications for evented mode, like there is no need to "spawn" the entire main code anymore.
<asterite>
But, the LLVMSetInstructionCallConv C API call is not in our LLVM bindings, you would need to add it and add a method to LLVM::Value to use it
<asterite>
stuffl: I think with all of that you will be able to try it out. But if not, let us know! Or maybe open an issue in GitHub, it's much easier to discuss things like this there
<asterite>
stuffl: but, in any case, we'll soon add that CallConvention attribute, because it's needed. We just need to decide which names to use :)
<travis-ci>
manastech/crystal#2038 (master - e7692ae : Juan Wajnerman): The build passed.
<stuffl>
asterite: the calling convention has to be applied to both the callee and caller? makes sense, but I'd think applying it to the callee was sufficient
<asterite>
Yes, me too, but llvm is quite lazy in that sense
<asterite>
You have to say the type of everything
<stuffl>
asterite: where can I implement something like @[stdcall] for `fun`s?
<asterite>
You would have to touch type_inference.cr
<asterite>
(yeah, that's not a good name for a file, but almost all semantic happens there)
<asterite>
Can you first compile a C programs that does a WinAPI call, get the llvm ir from that and paste it somewhere?
<asterite>
I want to be sure the missing calling convention is the problem
<asterite>
Then in the codegen, for an AST node, you can ask: node.has_attribute?("StdCall")
<asterite>
With that you will be able to do it faster than hardcoding, I think
<stuffl>
I don't know how llvm ir looks like, but when calling winapi funcs, they end with e.g. "retn 0Ch", so having normal cdecl calls to them would look like "push 4; push 3; push 2; push 1; call func; add esp, 0Ch", so it only makes sense that the stack gets corrupted
<asterite>
Do you have clang on windows?
<stuffl>
asterite: yes
<asterite>
You can try to compile a file like this: clang foo.c -emit-llvm -S
<asterite>
That will produce a foo.ll file, and there we can see if llvm uses a different calling convention, or what
<asterite>
(we just want to be sure that that's what we would need to do, before implementing the new CallConvention attribute)
<asterite>
Well, those x86_stdcallcc must mean something :)
<stuffl>
asterite: it's also already mangled
<stuffl>
asterite: stdcall functions just have their parameters' stack size prepended with an @
<asterite>
Yes, but we don't know if clang did that, or llvm already does that
<asterite>
Ah, I see
<asterite>
Well, we'll add that CallConvention attribute there
<asterite>
then, I mean
<asterite>
Today or tomorrow :)
<stuffl>
MessageBox@16, ExitProcess@4, etc.
<stuffl>
I will look into the sources line you gave me and see if I can quickly add some lines so the imported stdcall function also gets its stdcall-attribute and see whether linking works without hassle
<asterite>
stuffl: great. Just so you know, I'll implement the CallConvention attribute now, I don't know how long it'll take me, but I don't think too long
<stuffl>
asterite: question is how the attribute should look like, one attribute for every convention like @[stdcall], @[fastcall], @[thiscall] and @[vectorcall] (cdecl not needed as it's default), however, these are all only for x86, on windows they're all used, though, so it makes sense to implement a switch for all of them
<stuffl>
asterite: or something more dynamic like for example @[callingconv=thiscall/stdcall/...]?
leafybasil has joined #crystal-lang
<stuffl>
the latter is rather ugly, I'd say, but with the first an attribute has to be implement for every possible calling convention (at least for x86, don't know if the others are needed), also I haven't tested compiling for x64 yet
<asterite>
I'd go with @[CallConvention("X86_StdCall")]
<asterite>
stuffl: I'm implementing it right now, unless you want to implement it yourself. I'm contemplating checking errors on valid values and so on
<crystal-gh>
[crystal] waj pushed 2 new commits to master: http://git.io/A0Ik
<crystal-gh>
[crystal] asterite pushed 2 new commits to master: http://git.io/A0qk
<crystal-gh>
crystal/master a905e59 Ary Borenszweig: Added Enum#parse and Enum#parse?
<crystal-gh>
crystal/master 90c374d Ary Borenszweig: Added CallConvention attribute for funs
<asterite>
II hope you don't mind, but it was faster if I implemented it because I know all the places that need modification, plus I added checks to make sure people use that attribute correctly
<asterite>
stuffl: Now, I checked, and llvm doesn't do any special mangling, one would have to specify it, like you did with "timeGetTime@0"
leafybasil has quit [Remote host closed the connection]
<stuffl>
asterite: I'm atm compiling the actual master-branch
<stuffl>
asterite: btw I always get "config.cr:4: error executing command: (git describe --tags --long 2>/dev/null), got exit status 128"
<jhass>
did you do a git clone?
<jhass>
or did you download the tarball?
<stuffl>
downloaded the zip
<jhass>
that's why
<jhass>
I would recommend to use a git clone
<jhass>
but you can get past that error by setting CRYSTAL_CONFIG_VERSION to anything
<crystal-gh>
[crystal] Exilor opened pull request #439: Added bit operators for BigInt (master...master) http://git.io/A08U
<crystal-gh>
[crystal] asterite pushed 2 new commits to master: http://git.io/A0zI
<crystal-gh>
crystal/master 058afa1 Ary Borenszweig: Added some macro methods to Call and NamedArgument. Also, fixed that it was impossible to execute macro methods on a Call node
<crystal-gh>
crystal/master ef95810 Ary Borenszweig: Added a macro spawn(exp)
<stuffl>
asterite: I just tested it and it works accordingly: `@[CallConvention("X86_StdCall")] fun msgbox = "MessageBoxA" (a: Int32, b: UInt8*, c: UInt8*, d: Int32): Int32` the stack is fine and so is the name mangling
asterite has joined #crystal-lang
<asterite>
stuffl: cool! Progress :-)
<asterite>
You've been very little here but you already improved the language. Thanks!