<Davy_CC>
I'm reading it and doing some try and error. Could you tell me which page points out the behavior you mentioned? thanks
elia_ has quit [Read error: Connection reset by peer]
elia has joined #crystal-lang
pawnbox has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
<BlaXpirit>
sorry that i didn't reply. no, i don't remember exact page
<BlaXpirit>
I recommend reading everything, then trying
<BlaXpirit>
aand apparently I was wrong that it is written there :(
srenatus has joined #crystal-lang
sdogruyol has joined #crystal-lang
sdogruyol has quit [Client Quit]
<BlaXpirit>
i've been trying to come up with some game idea to write for practice
<BlaXpirit>
but nothing interesting ever comes to mind
pawnbox has joined #crystal-lang
ssvb has quit [Read error: Connection reset by peer]
pawnbox has quit [Remote host closed the connection]
alanwillms has joined #crystal-lang
xender has joined #crystal-lang
<xender>
Hi. I'm new to Crystal and I'd like to ask about cross-compiling: I already know it's not possible to bootstrap the compiler on Windows at the moment, but is it possible to cross-compile *for* Windows at all? If so, which parts of standard library can I use and which I can't?
pawnbox has joined #crystal-lang
alanwillms has quit [Quit: Saindo]
pawnbox has quit [Remote host closed the connection]
fowlduck has quit [Remote host closed the connection]
elia has quit [Read error: Connection reset by peer]
elia has joined #crystal-lang
pawnbox has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
<Davy_CC>
xender: I'm keeping moving Crystal 0.9.1 to Windows. Standard library depends on many unix only library, we have two choice, one is using Cygwin or other unix capitable layer; the other is moving standard library to use Windows APIs.
trapped has joined #crystal-lang
<Davy_CC>
I'm trying to let Crystal use Windows APIs. But I'm poor at it, so I have to do much research between these libraries and Windows APIs. But if you want, you can try cross-compile with Cygwin first.
elia has quit [Read error: Connection reset by peer]
<xender>
Davy_CC: Well, how about MinGW?
<xender>
I suspect Cygwin can have problems with wide acceptance among Windows users, but MinGW seems to be pretty popular option.
<Davy_CC>
all unix capitable layer is okay, but I haven't try them yet
<xender>
It doesn't really implement some heavily-UNIX-specific things, though
elia has joined #crystal-lang
<xender>
With MinGW, you get standard libc (GNU libc I think), you can get pthreads, but no fork()
<xender>
There is fork() on Cygwin, but it's evil hack anyway...
<Davy_CC>
yes, so if you want to use MinGW, you have to implement one or remove fork()
<xender>
Removing fork() on Windows is the only sensible option.
luislavena has joined #crystal-lang
<Davy_CC>
but we can provide some windows APIs on Crystal, like CreateProcess
<xender>
It's the same situation as if you were developing a new language on Windows, making it expose some WinAPI functions as a window into low-level API, and then wondering what to do with them when porting to Linux. "Should we use Wine for this?"
<xender>
Actually, people who were making .NET were not even that nice, Mono devs were on their own :P
<xender>
Well, I don't know much about Crystal and it's stdlib yet, but the real answer is that there needs to be some abstraction.
<xender>
As Crystal looks pretty nice and high-level, I would expect something like Python's 'subprocess' module, not just having bare fork, exec and CreateProcess exposed
<xender>
Yeah, I've seen the discussion, thank you for pointing it though.
<Davy_CC>
Crystal's Standard Library is the abstract layer, and keeping moving to be a high-level layer
<xender>
So I think the real answer is to expose low-level system functions only on systems where they are implemented, and have high-level functionalities covered by abstraction layer.
<xender>
It's no different than coding in C++ - trying to use fork() on *NIX or Cygwin will work (or somehow work), but under MinGW or MSVC it will be a compile-time error
trapped has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<xender>
There have been some discussion about what's more proper to do on fork()-less platform: an exception or a compile-time error. The latter is only sensible option to me...
ponga has quit []
<Davy_CC>
I think Windows is not a POSIX-capitable system, so I won't implement fork() on Windows
elia has quit [Read error: Connection reset by peer]
elia has joined #crystal-lang
<BlaXpirit>
Davy_CC, good
<xender>
Davy_CC: You can take a look at how Cygwin folks have done it. Maybe it will scare you :P
<Davy_CC>
But in my opinion, standard lib will provide a method calls fork() on POSIX, and a method calls CreateProcess on Windows. But they won't be the same method in standard lib.
<xender>
Of course
<xender>
They should be in different modules
<Davy_CC>
xender: I know that's so terrible
<xender>
Separate modules for underlying OS API-s...
<Davy_CC>
BlaXpirit: good for what
<xender>
Davy_CC: So you know that they spawn a new process from the same executable in suspended state, set some flag in there, let it execute until entry point (which contains Cygwin-provided code as it was compiled by Cygwin's GCC), which then checks the flag, then parent copies it's own memory into child address space, which triggers some antivirus software and bloats the RAM...
<BlaXpirit>
not implementing fork on windows is good
<xender>
Nightmare, horror and terror in one ^ ^
<Davy_CC>
BlaXpirit: lol many languages aren't implementing fork on windows :P
<BlaXpirit>
good
<xender>
Though, Cygwin's compiler detects fork+exec, so it can substitute the pair with a normal-ish CreateProcess.
<Davy_CC>
we are not talking about Cygwin lol
<xender>
Davy_CC: But you were mentioning the mere possibility that implementing fork() on Windows could be done... So I thought mentioning how exactly terrible Cygwin's implementation (the only one I know) is. :P
<Davy_CC>
I know using Cygwin is a bad idea. So I'm porting Crystal to Windows without Cygwin and MinGW
<Davy_CC>
many of libraries Crystal used have windows version
<xender>
No, Cygwin itself is not a bad idea
<xender>
Their implementation of fork isn't either. It's terrible because that's the only way.
<xender>
I also don't know to what extent MinGW can interface with MSVC-compiled libraries.
<xender>
But I'd be more inclined towards supporting MinGW than MSVC.
<xender>
It would be best to support both, but MinGW is more familiar when you're coming from Linux/UNIX background, and it has a free license.
<Davy_CC>
Crystal uses many portable libraries, so I think it would be ok on MinGW.
trapped has joined #crystal-lang
<Davy_CC>
gc-lib, libpcre, libevent (event2) are working on Windows. The only problem is libunwind seems not have windows version.
<Davy_CC>
maybe i'll use windows api to solve it
<xender>
SEH?
<xender>
(Structured Exception Handling) - native Windows exception handling
<xender>
Just don't make the mistake of some implementors of C++ exceptions who used SEH...
<xender>
I think it was on some old versions of MSVC...
<xender>
Doing catch(...) (catch all exceptions) in C++ catched all SEH exceptions, not only C++ exceptions
<xender>
So also things like segfaults I think? :D
<BlaXpirit>
neat
<xender>
They took "catch-all" too literally ^ ^
<Davy_CC>
how about RtlUnwind?
<xender>
Hmm
<xender>
How about compiling to C++ and let it handle unwinding the stack? :P
<xender>
Would it be possible to just use this instead / as an alternative to libunwind?
<xender>
Also, what about things like Emscripten that allow compiling LLVM-IR to Javascript?
<Davy_CC>
I'll read this later. But there must a reason Crystal didn't use this instead of libunwind.
<BlaXpirit>
wise words
<xender>
The problem is that libunwind seems to be horribly unportable
<xender>
Or no, that's not the real problem
<xender>
The real problem is that it's separate from the rest of compiler pipeline...
<xender>
Also, programmers with different backgrounds have different expectations about how often exceptions occurs, how reliable are they etc.
<xender>
Python programmers use exceptions commonly, but in C++ people sometimes disable it altogether.
<xender>
So a C++ programmers reaction might be "come on, it shouldn't throw in the first place / when it throws we are screwed anyway" and Python's programmer reaction will be "you're trying to take integral path of the language from me? Are you nuts?"
<xender>
So the point is: it should be decided/agreed upon and documented what is the intended use case for exceptions, can programmers rely on them heavily or not...
<xender>
It probably needs to wait as there are more urgent things to do I suppose :D
<xender>
Davy_CC: That's not the worst part, that's just a matter of name mangling and calling conventions.
<xender>
Davy_CC: Actually parsing the headers is much worse.
<xender>
Davy_CC: And if you want any support for templates... Then you just need a full C++ compiler anyway.
<xender>
Davy_CC: There even are header-only libraries for C++ - consisting of only template classess/functions (which have to be places in header file), so the need to have a linking-stage library vanishes altogether.
<Davy_CC>
humm
<Davy_CC>
is there any language can be compiled with C++ in the way you metioned?
<BlaXpirit>
only languages that compile TO c++
<xender>
Davy_CC: Maybe Objective-C++. But I don't know how they implement it.
<Davy_CC>
supporting C++ template with only headers? (as I know, if there is only header, it couldn't compile templates
<xender>
Davy_CC: Of course you need something that will instiantiate the templates. But in case of header-only libraries, this will be a code of a program that uses the library.
<Davy_CC>
Crystal can link with these libraries, with rewriting the header(or called library binding) in Crystal way
<Davy_CC>
it's the same if you exposed the func in C++
<Davy_CC>
but if you want to share classes from C++, it could be hard
<xender>
Davy_CC: Regular functions in C++ can have their names overloaded
<xender>
You can have 2 or more function with the same name, as long as count or types of their arguments are different
<Davy_CC>
yes, your right
<Davy_CC>
but if you use `extern "C"`, it could be easier
<xender>
And a lots of other stuff, less or more diverging from C
<xender>
Yeah, of course, but if you want to interface with any non-trivial C++ library which doesn't already have C-compatible interface, you end up making a wrapper over every class and method.
<xender>
Or only over needed ones... Or even place some abstraction in there. So, not a trivial task.
elia_ has quit [Read error: Connection reset by peer]
elia has joined #crystal-lang
elia has quit [Read error: Connection reset by peer]
elia has joined #crystal-lang
elia has quit [Read error: Connection reset by peer]
elia has joined #crystal-lang
elia has quit [Read error: Connection reset by peer]
elia has joined #crystal-lang
endou_ has quit [Ping timeout: 240 seconds]
g3funk is now known as braidn
fowlduck has quit [Remote host closed the connection]
jnylen has joined #crystal-lang
endou has joined #crystal-lang
fowlduck has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
shama has joined #crystal-lang
tomchapin has joined #crystal-lang
pawnbox has joined #crystal-lang
emmanueloga has quit [Ping timeout: 250 seconds]
jwaldrip has quit [Ping timeout: 252 seconds]
ponga has quit [Ping timeout: 240 seconds]
iamstef has quit [Ping timeout: 240 seconds]
x0f has quit [Ping timeout: 252 seconds]
krtv` has quit [Ping timeout: 240 seconds]
ponga has joined #crystal-lang
x0f has joined #crystal-lang
iamstef has joined #crystal-lang
jwaldrip has joined #crystal-lang
kostya has joined #crystal-lang
emmanueloga has joined #crystal-lang
kostya has quit [Quit: Leaving]
krtv` has joined #crystal-lang
elia has quit [Read error: Connection reset by peer]
elia_ has joined #crystal-lang
elia_ has quit [Quit: Computer has gone to sleep.]
trapped has joined #crystal-lang
trapped has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
joshcarter has quit [Ping timeout: 240 seconds]
jeromegn has quit [Ping timeout: 260 seconds]
victor_lowther has quit [Ping timeout: 240 seconds]
jeromegn has joined #crystal-lang
victor_lowther has joined #crystal-lang
joshcarter has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #crystal-lang
pawnbox has quit [Remote host closed the connection]
A124 has quit [Ping timeout: 276 seconds]
A124 has joined #crystal-lang
srenatus has quit [Quit: Connection closed for inactivity]
<BlaXpirit>
ldlework, why not read the whole tutorial then check some examples
<ldlework>
BlaXpirit: I'm just trying to quickly prove to myself, or not, a simple trivial factory which is apparently impossible in Nim, is well trivial in Crystal.
<BlaXpirit>
but yeah, I did have to read ruby docs to get into all this stuff