jhass changed the topic of #crystal-lang to: The Crystal programming language | http://crystal-lang.org | Crystal 0.5.8 | Paste > 3 lines of text to https://gist.github.com | GH: https://github.com/manastech/crystal - Docs: http://crystal-lang.org/docs/ - API: http://crystal-lang.org/api/ - Logs: http://irclog.whitequark.org/crystal-lang
<epitron> like, "ls" gets a pty in ruby if you run system("ls"), so you get colour output
<epitron> yours is like running popen
<epitron> which ls thinks is a pipe
<jhass> >> Process.run("/bin/ls", {"-a", "/"}, output: true).output.not_nil!.gsub('\n', ',')
<CeBot> jhass: ".,..,bin,boot,crystal-git,dev,etc,home,lib,mnt,opt,proc,root,run,sbin,srv,sys,tmp,usr,var,"
<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
<epitron> i see
<jhass> doesn't seem to be defined for integers
<epitron> ooo, neat
<epitron> maybe the reason nobody has integer exponentiation is because it doesn't take constant time
<epitron> which is bad for crypto
<jhass> I know, crystal feels so dynamic, it's sometimes hard to accept it's actually a static language ;)
<epitron> of course, crypto needs discrete exponents
<jhass> as said, I think it's actually mathematically more correct too
<epitron> floats are imprecise
<epitron> you can't use that for crypto
<jhass> what I mean that the general definition of the operation operates in R, not N
<epitron> what? :)
<jhass> real numbers vs natural numbers ;)
<epitron> yeah, but the "general definition" doesn't include decimals if you have no decimals in your exponent or your base
<epitron> it's like saying the "General definition" for addition uses floats :)
<epitron> it depends on what you're adding
<jhass> mmh
<jhass> yeah, you're probably right
<jhass> you won't get rid of the point that returning a union is bad though :P
<jhass> we could return Ints if the arg is a UInt I guess
r20 has quit [Ping timeout: 245 seconds]
<jhass> but then that would be sort of a subtle difference
r20 has joined #crystal-lang
<epitron> you actually have a definition for when the arg is an int :)
<epitron> it just turns itself into a float first
<epitron> i wonder if dependent typing helps in this case
<epitron> dependent types use the value as well as the type when deciding what to do
<epitron> it could check how big the exponent is when deciding the return value
<jhass> eh, does that work in compiled languages?
<jhass> in functional languages maybe, though iirc that guessing there falls apart when it comes to IO too
<epitron> i totally get why julia exists now
<epitron> :)
<epitron> you can't make ruby behave like C without on-the-fly compiling
<epitron> (err, C behave like ruby)
travis-ci has joined #crystal-lang
<travis-ci> manastech/crystal#1887 (master - 66b3eac : Ary Borenszweig): The build is still failing.
travis-ci has left #crystal-lang [#crystal-lang]
asterite has joined #crystal-lang
<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
<jhass> >> require "json"; class A; json_mapping({a: Hash(String, JSON::Any)}); end; A.from_json(%({"a": 1}))
<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.
travis-ci has left #crystal-lang [#crystal-lang]
<jhass> wut, net split?
<jhass> okay, looks good on 32bit linux too
asterite has joined #crystal-lang
<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 ;)
<jhass> oh
<jhass> try closing the read end
<asterite> I don't really understand how you can trigger an "exceptional condition" :)
<jhass> can you try closing the read end of the pipe?
<jhass> I guess it would also work if we spin up a tcp server and client and send some weird stuff to the other side, but meh
<asterite> I tried: read.close, and also write.close; read.close
<asterite> It still fails :/
<jhass> can you join the thread after read.close ?
<jhass> ah, that's why it worked for me
<asterite> Yes. I still get the bad file descriptor
<asterite> Why it worked for you?
<jhass> because the wrapper closes the write end and it reached the select call before reaching that for me
<jhass> I'll see what ruby does in its tests for IO.select
<asterite> So if you thread.join it also fails for you?
<asterite> Oh, nevermind, I misread
<asterite> The good thing is that if I comment that spec it doesn't segfault anymore, so the segfault only happens in that case :)
<jhass> yeah, I really think it's just another case of where raising in a thread segfaults
<jhass> great, looks like Ruby has no test for that m(
<asterite> :-P
<jhass> we might need to drop that test, as your SoF links indicate there seems to be no portable way to provoke the right condition for it
<asterite> Can you try this in Ruby? https://gist.github.com/asterite/820e16be4bbb7d7c3c65
<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
bcardiff has joined #crystal-lang
<asterite> jhass: I wonder about this line: ` ios.select {|io| {read_fdset, write_fdset, error_fdset}.any?(&.is_set(io)) }`
<asterite> If you pass the same fd in both read and write, what happens?
<asterite> My question is: shouldn't the read_ios be searched in read_fdset, write_ios in write_fdset and so on?
<asterite> (but I don't know if that scenario is even possible)
<jhass> so, two cases there
<jhass> either only one is ready
<jhass> then you get that returned
<jhass> but if you pass one in both, readable and writable
<jhass> and it's both, read ready and write ready
<jhass> you don't care
<jhass> know if it's only one of the two, you have a problem anyways
<jhass> *now
<jhass> mmh, maybe we should go with the yield API the other guy suggested
<asterite> English makes me have those typos all the time
<jhass> though it feels a bit more verbose to me
<asterite> yield the IOs instead of returning them as an array?
<jhass> yield or return {ready, writeable, errored} I guess
<jhass> but I think that API is too verbose
<asterite> I can't comment on that because I never used IO.select
<jhass> let's wait til somebody with a usecase that the current API doesn't support comes along :)
<asterite> but if there's room for improvement one can always open an issue on github ;)
<asterite> Yes, that :)
<jhass> I think it's rather rare to wait on read and write ready for the same IO
<jhass> you're either the sender, the receiver or the middleman and have two different IOs
travis-ci has joined #crystal-lang
<travis-ci> manastech/crystal#1890 (master - c1df753 : Ary Borenszweig): The build is still failing.
travis-ci has left #crystal-lang [#crystal-lang]
<jhass> meh, we should fix that AF_INET spec
<jhass> do you understand why it's failing?
travis-ci has joined #crystal-lang
<travis-ci> manastech/crystal#1891 (master - 723a6fb : Ary Borenszweig): The build is still failing.
travis-ci has left #crystal-lang [#crystal-lang]
<asterite> Nope
<asterite> It works on my side
<jhass> it's because on a modern system v6 is preferred
<jhass> so your /etc/hosts is probably missing the localhost entry for ::1
<jhass> but on most modern systems it's there, and the v6 socket is prefered
<jhass> so, the solution would be eiter to pass 127.0.0.1 there
<asterite> I have this on /etc/hosts: `::1 localhost`
<asterite> That should make the spec fails on my machine?
<jhass> mmh, maybe it's just that your system doesn't prefer v6 then
<asterite> I'd like to try that same thing with Ruby on that travis machine
<jhass> anyway, so to fix passing 127.0.0.1 instead of localhost should work
<jhass> makes the assertion on the address a bit pointless I guess
<jhass> but then it's system configuration that localhost points to that address anyway
<jhass> I think there's a flag for connect to force v4
<jhass> so exposing that would be another option I guess
<jhass> wait, actually it's exposed already
<jhass> I'll just force it to v4
<jhass> oh, nvm, that's just the addrinfo call, mmh
<asterite> If the specs depends on the machine's configuration, I can't see how we can test it like that
<asterite> But are we sure that's the case?
<asterite> (I ask again because I don't know much about these, the APIs are similar to Ruby and it seems to work, so...)
<jhass> well, if somebody changes localhost to something else than 127.0.0.1 then their problem really, IMO
<jhass> it's just that way for 99% of the systems
<jhass> I'll see if I can add API to force v4/v6
<jhass> and then use that
<asterite> I think the spec just says "localhost" and expects AF_INET for the family, but that's not necessarily true, right?
<jhass> right
<jhass> as said, it depends on what the prefered socket type of the system is
<jhass> which is actually system configuration
<asterite> But for "::" it must always return AF_INET6, right?
<jhass> yes, :: is the same as 0.0.0.0, which means all interfaces, except for v6
<asterite> Good
<jhass> ::1 is the same as 127.0.0.1
<asterite> So, for now I'll comment that line of the spec
<asterite> Then we can re-enable it if we can force v4/v6...
<jhass> I'd say force the socket v4
<jhass> it's easy
<asterite> But if we really think that's what we want
<asterite> Can you do the same in Ruby?
<jhass> you just pass it instead of nil
<jhass> in getaddrinfo
<jhass> dunno
<asterite> I mean, I think you can't force it in Ruby, and so far I don't know if anyone complained :)
<jhass> well, it's actually no forcing, but just a hint on what's your prefered method
<asterite> Good
<jhass> simple as that
<jhass> I'm not sure if we want the user to pass LibC stuff though
<jhass> so I'd say remap those constants into Socket
<asterite> Yes, definitely
<jhass> or even allow to pass symbols like :inet/:inet6
<asterite> I will map them to enums, so it'll be type safe and more descriptive
<asterite> (I know you like symbols better, but...)
<jhass> you, know, const_get would be neat :D
<asterite> It would actually be cool to be able to pass a symbol literal where an enum is expected, and do the mapping automatically
<jhass> yeah
<asterite> It won't work if the symbol is in a variable, but that case might be less often
<asterite> Then we can have type safety and less verbosity
<asterite> But I'll put that on the backlog for now :)
travis-ci has joined #crystal-lang
<travis-ci> manastech/crystal#1892 (master - 31caf36 : Ary Borenszweig): The build is still failing.
travis-ci has left #crystal-lang [#crystal-lang]
<asterite> Nobody invited you here, travis
<asterite> Ugh
zamith has quit [Quit: Be back later ...]
<jhass> :P
<jhass> btw, why travis but not GH? :)
<asterite> How?
<jhass> in the repo settings, go to services and add the IRC service ;)
travis-ci has joined #crystal-lang
<travis-ci> manastech/crystal#1893 (master - 6c97a3e : Ary Borenszweig): The build is still failing.
travis-ci has left #crystal-lang [#crystal-lang]
<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.
travis-ci has left #crystal-lang [#crystal-lang]
asterite has joined #crystal-lang
asterite has quit [Client Quit]
leafybasil has quit [Remote host closed the connection]
bcardiff has quit [Quit: Leaving.]
CeBot has joined #crystal-lang
zamith has joined #crystal-lang
vifino has joined #crystal-lang
r20 has quit [Ping timeout: 245 seconds]
zamith has quit [Quit: Be back later ...]
zamith has joined #crystal-lang
leafybasil has joined #crystal-lang
gr33n7007h has quit [Quit: Leaving]
CeBot has quit [Quit: Crystal]
CeBot has joined #crystal-lang
CeBot has quit [Ping timeout: 252 seconds]
CeBot has joined #crystal-lang
zamith has quit [Quit: Be back later ...]
zamith has joined #crystal-lang
gr33n7007h has joined #crystal-lang