vikaton has quit [Quit: Connection closed for inactivity]
fowlduck has joined #crystal-lang
fowlduck has quit [Ping timeout: 248 seconds]
vikaton has joined #crystal-lang
havenn is now known as havenwood
NeverDie has joined #crystal-lang
waj has quit [Quit: waj]
fowlduck has joined #crystal-lang
waj has joined #crystal-lang
fowlduck has quit [Ping timeout: 252 seconds]
ozra_ has quit [Ping timeout: 246 seconds]
fowlduck has joined #crystal-lang
fowlduck has quit [Remote host closed the connection]
genericpenguin has joined #crystal-lang
<genericpenguin>
hi. I'm having an issue with the C fun declaration. Specifically, passing pointers char arrays. I'm trying to declare readlink in Crystal
<genericpenguin>
ssize_t readlink(const char *path, char *buf, size_t bufsiz), but I can't get crystal to recognise the pointer declarations. I create a Char array and create a pointer to it using pointerof
<genericpenguin>
But when compiling, it complains that the function is expecting a Char pointer (Char*) instead of a Char array pointer (Array(Char)*).
<genericpenguin>
I expect I'm doing something very stupid (IANAP) but I have gone through the docs, apis, numerous chat logs of #crystal-lang but have been unable to hit the nail on the head.
<willl>
you want to pass a string from crystal to a C char* ?
<genericpenguin>
Great, thanks heaps! I will give that a whack.
waj has quit [Quit: waj]
strcmp1 has joined #crystal-lang
<genericpenguin>
so it compiles and runs fine, but the empty string I pass to readlink (which is the buffer that will have the results) is empty. Does it work differently if I'm passing a string that I want to be written back?
<willl>
yes, for that you either want the out keyword, or to do it manually
<willl>
actually out should work, the case I was remembering where I had to do something manually was a c function that would move a pointer you passed in to a weird data structure, so you shouldn't need to worry about that
<genericpenguin>
So how would that work for a string, when UInt8 is a single value? It compiles fine but I just get a zero in the output.
<willl>
ok, yeah, if you have the pointer to that, String.new has an initialize method that takes pointers to strings, or if that third parameter there is the size, slice might be the right thing to look at since it has bounds checking
<crystal-gh>
[crystal] yui-knk opened pull request #899: Implement Hash#merge with block (master...feature/hash_merge_block) http://git.io/vtaBL
lokulin has joined #crystal-lang
lokulin has quit [Changing host]
bcardiff has joined #crystal-lang
<willl>
genericpenguin: I played around with it, and found out I think you'll need a slice
<genericpenguin>
willl: I tried your gist but I get an empty string. I'm using crystal 0.7.3 on a Mac (10.10). Might that be a problem? I'm going to try it on one of my C7 boxes since that's where they'll be running anyway
<willl>
are you sure you're passing in a full path to a symlink?
<willl>
what is the return code of the function?
<genericpenguin>
-1 is the return code but I figure it's a mac thing. I just ran it on Centos 7 and it works fine
<willl>
my run there was 0.7.4 on os x
<genericpenguin>
hmmm. I might be doing something non-kosher. I'm going to have another check for sheer stupidity
<genericpenguin>
Yep, I fat-fingered the ln. Works as expected
<willl>
:)
<willl>
also it looks like this lib sets errno, so p Errno.new("error") would have printed
<asterite>
That's because only system and backtick (`) set $?
<asterite>
Process.run already returns the status
<Kilobyte22>
oh hmm...
<asterite>
But of course thee's no way for you to know it because it's not documented
<Kilobyte22>
well, what would i do with async Process.run
<asterite>
But we can make Process.run also set it, sounds reasonable
<Kilobyte22>
that as well
<Kilobyte22>
yeah
<Kilobyte22>
is $? thread local?
<asterite>
No, it's method local
<asterite>
it's implemented by defining $? in the method where the call is, and passing a pointer to it to the method that defines it
<asterite>
So basically Process.run also receives a pointer to $? and sets it
<asterite>
(well, Process.run does that now that I fixed it :-P)
<asterite>
It's done that way so there's no problem with concurrency... that was our main issue with those magic vars
<Kilobyte22>
yeah, thats even a better solution
<Kilobyte22>
:D
<asterite>
but honestly I'd still like to remove them, even if they'll make some code larger/harder to read
<Kilobyte22>
because race conditions
<Kilobyte22>
maybe, yeah
<jhass>
asterite: so the compiler detects it always raises and thus doesn't ignore NoReturn because it's not a union?
sandelius has joined #crystal-lang
ashleyis has joined #crystal-lang
sandelius has quit [Client Quit]
<asterite>
When you do "$~", that actually it parsed to "$~.not_nil!", where "$?" is just a regular variable that is automatically defined when used
<asterite>
Well, $~/$?
<Kilobyte22>
now to figuring out why crystal links against libpcl
<Kilobyte22>
.not_nil! sounds useful
<asterite>
because it was never set a value, it gets the type Nil (it always has that type anyway), and nil.not_nil! always raises and that is typed as NoReturn
<asterite>
Kilobyte22: but don't worry, in a next release waj will push the new-fibers branch which does the context switch in assembly, and we won't need libpcl anymore :)
<Kilobyte22>
i want that now D: because libpcl apparently is not in mint sources
<Kilobyte22>
nvm unexpected package name
<Kilobyte22>
sudo pacapt -S libpcl1-dev
<Kilobyte22>
should be it
<asterite>
You can manually merge the new-fibers branch locally and create a compiler out of it. I'm not sure it's well tested, though, and it only works in x64_64 (as usual -_-)