<epitron>
and because system() is hooking the command into your pty, it also streams its output a line at a time
<epitron>
instead of your output being a giant string
<epitron>
like, try Process.run("less") :)
<jhass>
output takes nil (=print to stdout), true (assign to output attribute of returned status object), false (redirect to dev/null) and an io
<epitron>
ok, i'll try less
<epitron>
ah, ok, that works
<jhass>
basically the same for input: btw
<jhass>
and I'll add error soon
<epitron>
weird
<epitron>
>> 2**64
<CeBot>
epitron: 1.84467e+19
<epitron>
exp is float?
<jhass>
mmh, well, mathematically it is
<jhass>
>> 2**-2
<CeBot>
jhass: 0.25
<jhass>
I don't think somebody spent much effort on designing that part yet though but just bound the corresponding C or LLVM function ;)
<epitron>
def **(other : Int)
<epitron>
(to_f ** other)
<epitron>
end
<epitron>
._.
<jhass>
check how float's is implemented and whether you can find a function that does it for int directly ;)
<jhass>
I doubt there is and if there is it'd only work for other >= 0, as I showed
<jhass>
so that'd give a messy API anyways
<jhass>
in ruby you can just return either thing, in crystal you'd return a union and then the caller has to deal with that if they want a method only available on either
<epitron>
sheesh, this is pretty hacky
<epitron>
you have to estimate the magnitude of the result to make sure it fits into the integer type you're using
<jhass>
how so?
<epitron>
then you multiply it a bunch of times
<jhass>
oh, you mean converting to integer for e >= 0 ?
<epitron>
my dumb implementation broke on 2**64 :)
<jhass>
;)
<epitron>
not converting
<epitron>
actually doing integer power
<epitron>
i assumed it was like ruby, where your result magically converted into a bignum for you
<jhass>
pretty sure that requires a runtime too
<epitron>
hmm?
<jhass>
well, you change the type of a variable based on its value
<epitron>
oh, okay
<jhass>
which you don't know at compile time
<epitron>
what does "requires a runtime" mean?
<jhass>
something that makes decisions that have effects on your code while it's run
<asterite>
epitron: we could make numbers automatically turn into BigInt, but that would be a serious performance loss, we believe
<asterite>
I believe when you are doing a program you know beforehand the magnitude of the values you are going to deal with, so you can probably choose to use BigInt or not and not always loose performance
<asterite>
Like, in most of the programs I write I never needed a BigInt
<CeBot>
jhass: in /usr/lib/crystal/json/from_json.cr:75: no overload matches 'Hash(String, JSON::Any)#[]=' with types String, (Nil | Bool | Int64 | Float64 | String | Array(JSON::Type) | Hash(String, JSON::Type))
<jhass>
:(
<asterite>
For the case of pow, at first it returned an int, but then we realized the int can be negative and the result must be a float, so it's always better to make it float and you can do to_i if you want (in other statically compiled languages it's like that)
<asterite>
jhass: interesting, I wonder how we can solve that
<asterite>
I think what we would need to do is to be able to define static methods on an alias type
<jhass>
I guess I can workaround it by JSON:Any'ing the hash for now and then overwriting the setter and/or getter
<asterite>
then the type would be JSON::Type, and you'd have JSON::Type.from_json
<jhass>
so maybe not too important
<jhass>
I'd rather like to get IO.select finished :P
<asterite>
In fact I think that will open a lot of possibilities, like have `alias Int64OrString = Int64 | String` and the defining a from_json method on it
<asterite>
jhass: I was going to take a look at IO.select, I think I will merge it and then I can try to fix it
<jhass>
dunno, it seems to segfault on os x currently :/
<asterite>
but I don't have much time right now, so if I merge it it'll break things for other devs... imagine those millions of pour souls out there, not being able to compile crystal
<asterite>
poor, I guess
<jhass>
yeah, I'm not asking to merge it ;)
<jhass>
I just have no way to further debug it
<jhass>
as it's working fine on linux
<jhass>
(okay, didn't actually try on a 32bit one yet, but I can do that)
<asterite>
jhass: checking the type of tv_usecs on my machine should be enough, right?
<jhass>
maybe
<jhass>
I wonder why it worked with Int32 before though
<jhass>
I set it to Int32 for OS X (I think)
<jhass>
but yeah, verifying that type again is at least a good start
<asterite>
I think that for Int32 it was working for me
<asterite>
I'll merge it and then we'll be forced to fix it, and I like that :)
<jhass>
heh
<jhass>
it segfaults make spec
<jhass>
quite drastic ;)
<asterite>
Well, we are not many yet developing, and less on a mac, so...
<asterite>
but it puts a bit of pressure to fix it, so I guess I'll do that soon ;-)
leafybasil has quit [Ping timeout: 256 seconds]
asterite has quit [*.net *.split]
<jhass>
hold on, looks like it segfaults on my 32bit box right away
<jhass>
dman
<jhass>
*damn
<jhass>
mmh
<jhass>
look like the compiler segfaults on 32bit when built from master
<jhass>
I got to investigate a bit
leafybas_ has joined #crystal-lang
<jhass>
okay, false alarm, must've been some left over from the earlier experiments
travis-ci has joined #crystal-lang
<travis-ci>
manastech/crystal#1888 (master - 4ec7fce : Ary Borenszweig): The build is still failing.
<asterite>
jhass: so on your machine `make clean crystal spec` doesn't segfault?
<jhass>
yup
<jhass>
neither on 32bit, just verified
<asterite>
jhass: in the "returns the ios with an error condition" spec, does ret from LibC.select gives -1?
<asterite>
In my case it gives a timeout, only that it's inside the Thread that's never joined
<asterite>
(I put a ::puts "error" in the -1 case to check this)
<jhass>
mmh
<jhass>
maybe just closing the pipe is not enough to trigger an error condition on OS X then
<jhass>
the third parameter is meant to return FDs/IOs of which the next operation would return an error
<jhass>
if I got that right
<jhass>
If the errorfds argument is not a null pointer, it points to an object of type fd_set that on input specifies the file descriptors to be checked for error
<asterite>
I ran it on a linux 64 bits and it doesn't give me -1 in that spec
<jhass>
conditions pending, and on output indicates which file descriptors have error conditions pending.
<jhass>
what errno does it set?
<asterite>
9
<asterite>
In my case thats EBADF
<jhass>
interesting
<asterite>
[EBADF] One of the descriptor sets specified an invalid descriptor.
<asterite>
I'll debug it a bit more, that must be the problem
<asterite>
It's strange that it doesn't happen on linux, though
<jhass>
maybe the scheduling is different so that it gets closed before reaching the select call in the thread
<jhass>
might instead want to close in the thread maybe?
<asterite>
How?
<jhass>
just flip the lines I guess
<jhass>
it's just an experiment
<asterite>
I don't know which lines. The problem is... I don't know much about IO, I don't know what LibC.select is supposed to do
* asterite
hides in shame
<asterite>
I should RTFM, but I'm lazy right now :-P
<asterite>
Also, I never did that low-level stuff thing related to IO, so...
<jhass>
you pass it a bunch of FDs
<jhass>
and it returns those that are "ready"
<jhass>
where ready is defined by in which parameter you passed the FD
<jhass>
the first one is for when there's data to read
<jhass>
the second is for when you can safely write stuff
<jhass>
and the third one is for when the FD hits an error condition
<asterite>
I see
<asterite>
Thanks :)
<jhass>
like it was closed by the other side or something like that
<jhass>
so, if I flip lines I get EBADF on linux :D
<jhass>
let me think a bit
<asterite>
Which lines?
<asterite>
read.close, write.close ?
<jhass>
the write.close with the IO.select in the thread
<jhass>
what we want here is pass an FD to the third parameter
<jhass>
for that to succeed it must be a valid, open active FD
<jhass>
we then want to trigger an error condition
<jhass>
so the select call returns
<asterite>
so for that we close the IO?
<asterite>
write.close?
<jhass>
yes
<asterite>
Ah, and you say that maybe that doesn't trigger an error on mac osx, right?
<asterite>
Maybe the thread gets executed before the write.close?
<jhass>
it does, I think it's scheduling problem
<asterite>
Does that make sense?
<jhass>
rather the other way around
<jhass>
on linux it does get run first
<jhass>
so it works
<jhass>
and on os x it doesn't
<jhass>
having different schedulers that actually sounds like a reasonable explanation I think
<jhass>
the segfault is then just one of the raising an exception in a thread issues I hope
<asterite>
I tried doing `sleep 1` right before write.close and it raises (but not segfaults)
<asterite>
But still fails the spec
<jhass>
works with the sleep here too :/
<jhass>
still raises EBADF?
<asterite>
Yes
<jhass>
mh
<asterite>
Now it nicely says: Error waiting with select(): Bad file descriptor
<asterite>
Maybe if you close a fd it becomes invalid?
<asterite>
Is there another way to make it an error without closing it?
<jhass>
I'm currently trying to find out ;)
<jhass>
I know some basics about FDs and stuff, but I researched that stuff while implementing too ;)
<asterite>
On mac it gives me foo.cr:11:in `select': closed stream (IOError)
<asterite>
And I tried that in the VM and I get the same error
<jhass>
yeah, I just had extreme luck with the scheduling I think
<jhass>
the ruby interpreter does a lot more stuff, so that that results in a different scheduling makes sense
<asterite>
Yes, it seems ruby checks the file descriptors to see if they are still open
<asterite>
(I think)
<asterite>
Well, we can drop the spec for now :)
<asterite>
If you agree
<jhass>
yeah, drop it
<jhass>
I tried to manually drive the scheduling with condition variables and just get EBADF there too
<asterite>
Good. I also made some changes to make the method less long and with less allocations
<asterite>
I'm just not sure about one thing
<asterite>
I can change the long `ios` line to `ios = [] of FileDescriptorIO`
<r20>
when you define a top level method in some_file.cr is it local to that file?
<jhass>
asterite: nope, since the OpenSSL socket is none
<asterite>
However, I can also see that CFileIO can potentially be a valid IO to pass there, so it won't work with STDIN/STDOUT for example
<asterite>
But that socket doesn't have a file descriptor (or at least I can't find the method for it)
<jhass>
we need to ducktype on .fd or add a marker module to everything that defines a .fd
<jhass>
it doesn't
<jhass>
but it should for this usecase
<jhass>
which just returns the one for the underlying
<asterite>
Yes, I was thinking about a marker module, makes more sense
<asterite>
The problem is, FileDescriptorIO is already taken :-P
<asterite>
Maybe IOWithFileDescriptor?
<asterite>
Maybe find a better name :-P
<asterite>
Or we can just do the typeof... I wonder why typeof(nil[0]) works
<jhass>
yeah, me too :D
<jhass>
so, re openssl, its .fd should return the underlying FD
<asterite>
Oh, no, it doesn't. It works because there's `read_ios ||= [] of FileDescriptorIO`
<jhass>
Ruby uses the to_io method for that
<jhass>
so if something doesn't respond to .fd they call to_io on it
<asterite>
Hehe, I was going to suggest a method to convert to that IO
<asterite>
But maybe to_io is not good here because IO is a module... maybe to_fd_io?
<jhass>
yeah, maybe something like that
<asterite>
Good :)
zamith has quit [Quit: Be back later ...]
<jhass>
r20: I think they are automatically private and can then only be resolved in the current file, so essentially yes
<jhass>
asterite would need to say whether redefining them in different files is save though :P
<jhass>
*safe
<r20>
jhass, ok good to know, i was curious because i see the tests do that sometimes, and i wasn't sure if they were scoped or not.
<asterite>
When you define a top-level method it's visible everywhere unless you mark it as private, which makes it file-local
<jhass>
ah, that way around
<asterite>
:)
<jhass>
I remembered something with private and file local :D
<asterite>
It's not documented anywhere yet, so... you can also guess ;-)
<asterite>
I find it useful to have helper methods that I don't want to have attached to any object, nor the top level
<r20>
defining a top level method doesn't add it to Object though right?
<asterite>
I used it mostly in specs, but only because it's a recent feature
<asterite>
r20: nope
<jhass>
do they have a self?
<asterite>
We could have actually added it to Object as a private method, only we didn't have private methods back then
<jhass>
no ivars iirc
<asterite>
But maybe it's better this way, I don't know
<r20>
i would say yes it's better =)
<asterite>
The top-level doesn't have a self nor ivars
<asterite>
r20: why better? :-)
<jhass>
so they're essentially functions, not methods :)
<asterite>
Yes :-)
<asterite>
(my answer to my question would be that I wouldn't expect a top-level method to act like that, as a private method on Object... it's... strange)
<r20>
because they don't pollute all objects
<jhass>
it's a side effect in ruby because of what the top level
<jhass>
is
zamith has joined #crystal-lang
<asterite>
Good :)
<jhass>
self there is an anonymous instance of Object, but the definee is Object
<asterite>
You can also do ::foo to invoke a top-level method
<jhass>
instead of the singleton class of that instance
<asterite>
Ugh, I have to put the commit message and it will have to explain that non-portable stuff
<asterite>
I think I'll just "Fixed IO specs" for now :-P
<jhass>
asterite: the whole tests depends on a v4 client conenecting to a v6 server :P
<jhass>
*test
<asterite>
:(
<asterite>
So I just remove all the addr-related stuff from the spec?
<jhass>
mh, I should write a guard plugin for crystal
<asterite>
I think with the change to IO.select I made it return FileDescriptorIOs even though the original ones might not be those
<asterite>
so the given objects might not be returned, but instead FileDescriptorIO objects... ugly
<asterite>
I'll fix it later
<asterite>
For now, I'll go to sleep. Too many fixes left, hehe
<jhass>
uh, right
asterite has quit [Quit: Page closed]
<epitron>
if i want to distribute the crystal source code to machines that don't have crystal installed, is there a way to generate something that llvm/clang can compile?
<epitron>
files full of IL instructions or something?
<jhass>
epitron: yup, build --ll --single-module should do
<jhass>
llc should be able to compile that, though I never tried with something that requires linker flags
<jhass>
epitron: you can cross compile an .o with build --cross-compile "linux_x86" --target "i686-pc-linux-gnu" for example
<jhass>
then crystal will give you an .o for that platform and a cc invocation that links it to an executable that you should run on the target
<epitron>
nice
<epitron>
hmm.. --ll --single-module made a binary
<jhass>
yes, it doesn't prevent that
<jhass>
but it should also have dumped you an .ll
<jhass>
maybe it's somewhere in .crystal/, I don't quite remember
<jhass>
it's more thought as a debugging tool ;)
<epitron>
it's not in there either
<epitron>
ah well
<jhass>
if I do bin/crystal build --ll samples/tree.cr
<epitron>
is .crystal a temporary directory?
<jhass>
I get .crystal/home/jhass/projects/crystal/samples/tree.cr/main.ll
<jhass>
sort of, it's also a cache
<epitron>
oh, there it is!
<epitron>
nice!
<jhass>
llc -filetype=obj -o foo.o main.ll compiles it
<jhass>
and then you need a linker invocation like --cross-compile prints it
bcardiff has quit [Quit: Leaving.]
[tymat] has joined #crystal-lang
tymat has quit [*.net *.split]
Liothen has quit [*.net *.split]
leafybas_ has quit [*.net *.split]
irclogger_______ has quit [*.net *.split]
[tymat] is now known as tymat
leafybasil has joined #crystal-lang
Liothen has joined #crystal-lang
Liothen has quit [Max SendQ exceeded]
irclogger_______ has joined #crystal-lang
Liothen has joined #crystal-lang
leafybasil has quit [Remote host closed the connection]
CeBot has quit [Ping timeout: 277 seconds]
zamith has joined #crystal-lang
zamith has quit [Quit: Be back later ...]
bcardiff has joined #crystal-lang
leafybasil has joined #crystal-lang
travis-ci has joined #crystal-lang
<travis-ci>
manastech/crystal#1898 (master - 98d2cd3 : Ary Borenszweig): The build was fixed.