ChanServ changed the topic of #crystal-lang to: The Crystal programming language | | Crystal 0.23.1 | Fund Crystal's development: | GH: | Docs: | API: | Gitter:
RickHull has joined #crystal-lang
<FromGitter> <Sija> @drosehn yes, it’s `Crystal::VERSION`
Disrecollection has quit [Quit: Leaving.]
Disrecollection has joined #crystal-lang
Disrecollection has quit [Ping timeout: 248 seconds]
DTZUZO has joined #crystal-lang
lacour has joined #crystal-lang
martinium has joined #crystal-lang
DTZUZO has quit [Ping timeout: 240 seconds]
martinium has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
martinium has joined #crystal-lang
alex`` has joined #crystal-lang
martinium has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohitpaulk has joined #crystal-lang
snsei has joined #crystal-lang
<FromGitter> <Rinkana> Morning
Papierkorb_ has joined #crystal-lang
<watzon> faustinoaq oh that's great
lacour has quit [Quit: Leaving]
<watzon> lol
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
<Groogy> Morning! o/
<Papierkorb_> Morning
<FromGitter> <Rinkana> Man, GDC tickets are still expensive :/
<Groogy> lol yeah
flaviodesousa has joined #crystal-lang
<Groogy> is there not like a indie pass or something that's cheaper?
rohitpaulk has quit [Ping timeout: 252 seconds]
rohitpaulk has joined #crystal-lang
snsei has quit [Remote host closed the connection]
claudiuinberlin has joined #crystal-lang
mark_66 has joined #crystal-lang
<FromGitter> <Rinkana> Yeah, but you miss out on much with that pass
<FromGitter> <Rinkana> The trip will cost me around 4k (EUR). And while i do want to go again, i can't really think it's a good idea as i'm not in the industry :(
rohitpaulk has quit [Ping timeout: 240 seconds]
<FromGitter> <pnloyd> Is there no Enumerable concatenation method? I searched through and I can't find it
<FromGitter> <pnloyd> Crystal is not really supporting efficient chaining of functional methods is it.
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter> <bew> well, an enumerable cannot be necessarily concatenable
<FromGitter> <pnloyd> I'm coming from the point of view of C#/.net, where most collection implement an Enumerable interface.
<FromGitter> <pnloyd> But it is obviously working very differently there.
<FromGitter> <bew> take for example an Iterator, it's enumerable, but you can't concatenate 2 iterator (though you can chain them, and create an iterator that will consume the first one, then the second one)
<RX14> @pnloyd you mean you want an enumerable which reads all items from enumerable a and then enumberable b
<RX14> that's certainly possible
<RX14> how does C# do this?
<FromGitter> <bew> here, the enumerable interface enforce you only the `each` method iirc
<RX14> oh, so you just want an Enumerable.conact(a, b) which returns some kind of abstract enumerable
claudiuinberlin has joined #crystal-lang
<FromGitter> <pnloyd> All collections like objects implement an IEnumerable interface, which basically just says this object can product an iterator. Then methods can "extend" objects that implement an interface.
<RX14> oh
<FromGitter> <pnloyd> Well I don't care so much if it exists.
<FromGitter> <pnloyd> Ya you have the right idea.
<RX14> Enumerable in crystal doesn't eman it can produce an iterator
rohitpaulk has joined #crystal-lang
<RX14> it means it provides an each {} method
<FromGitter> <pnloyd> Ya exactly. I just want to make sure I'm not using the Crystal Enumerable methods to write really bad code because I don't understand what it's doing.
<RX14> Iterable means it can provide an iterator
<RX14> and Iterators *can* be chained
<RX14> for example
<RX14> string.each_char.chain(other_string.each_char)
<RX14> gets you an Iterator(char) with the characters of both strings
<FromGitter> <pnloyd> I'm dealing with an array of objects that I'm reducing, and I wanted to use a concat to "inject" some other objects into the reduce.
<FromGitter> <pnloyd> But I can easilly rewrite it to work another way.
<FromGitter> <pnloyd> Chaining functional methods kind of leads to hard to read code anyways
<FromGitter> <yxhuvud> Also you may want to look into Iterable which DO require an each that gives an iterator. I am not certain why there is no concat though - ruby also doens't have that.
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter> <yxhuvud> sigh, I should read the whole backlog before commenting :/
gcds has joined #crystal-lang
<FromGitter> <pnloyd> Also Array implements a concat already. Iterable would have to use another name I guess
<FromGitter> <pnloyd> Assuming Array would implement it..
rohitpaulk has quit [Ping timeout: 248 seconds]
rohitpaulk has joined #crystal-lang
<FromGitter> <yxhuvud> Well, in that case it would be the iterator, not the iterable that supported it. That is, (some_array.each + some_set.each).each {|el| .. } could be possible.
claudiuinberlin has joined #crystal-lang
<FromGitter> <pnloyd> I don't think that reads very well
<FromGitter> <yxhuvud> (concat is a bad name as it has a semantics of actually modifying the receiver. I don't see how that would be wanted).
<FromGitter> <yxhuvud> append could work I guess.
rohitpaulk has quit [Ping timeout: 260 seconds]
rohitpaulk has joined #crystal-lang
<Papierkorb_> What was wrong with `Iterator#chain` as RX14 suggested?
<FromGitter> <yxhuvud> I didn't see it! But yeah, that is probably even better.
<FromGitter> <pnloyd> Is there already a way to do this?
<FromGitter> <pnloyd> I'm lost now
<Papierkorb_> ‎[10:47] ‎<‎RX14‎>‎ string.each_char.chain(other_string.each_char)
<FromGitter> <pnloyd> can that same method be applied to Arrays?
<Papierkorb_> It's `Iterator#chain`, not `DoesntWorkOnArray#chain`
<Papierkorb_> all you need is an iterator. `Array#each` without a block will gladly give you one
<FromGitter> <pnloyd> I don't know enough about Crystal to know that Array#each produces an Iterator.
RickHull has quit [Ping timeout: 260 seconds]
rohitpaulk has quit [Ping timeout: 248 seconds]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 255 seconds]
rohitpaulk has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #crystal-lang
<gcds> ahm stupid question is there an easy way to construct UInt32 value from 4 UInt8? in C i usually just shift by position and do OR but how I should do it in Crystal? :D
rohitpaulk has quit [Ping timeout: 240 seconds]
rohitpaulk has joined #crystal-lang
<Papierkorb_> gcds: Nothing much better built-in wise. On this level, most "tricks" from C apply to Crystal too.
<gcds> okay :)
<Papierkorb_> gcds: If you want to really go Crystal, you could build a `StaticArray(UInt8, 4)` of your bytes, then use `IO::ByteFormat.decode` to get the int32 out of it
<Papierkorb_> gcds: See for sample snippets of that
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #crystal-lang
<gcds> Papierkorb_ maybe you could also help with this? I have this opreration in C "a = -(...)" its from crc stuff I tried the same in crystal but I think its not the same I guess. If I remember its negation in c
<FromGitter> <bew> hmm should work in Cr too
<gcds> was getting wrong number of arguments for 'UInt32#-' (given 0, expected 1)
<Papierkorb_> Please post the actual code you're using
<FromGitter> <bew> `-(2+3)` => `-5`
<FromGitter> <bew> `-(2u32+3u32)` => error
<gcds> cool.. :D
<gcds> i guess because of unsigned
<Papierkorb_> yup
<Papierkorb_> bew, good catch
<FromGitter> <bew> `-(2u32 - 3u32)` should work
<Papierkorb_> Or just `0u32 - (2u32 + 3u32)`
<FromGitter> <bew> yeah sure
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #crystal-lang
rohitpaulk has quit [Ping timeout: 240 seconds]
rohitpaulk has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gcds> fun stuff: I have this line which compares sent crc vs calculated: if !=
<gcds> i does not match so I print it out the values
<gcds> 2222206545 != 2222206545
<gcds> and I am like wtf
<gcds> so apprentrly a > b && a < b all eq false :D
<gcds> sorry a > b = true a < b = false
<gcds> nvm...
<FromGitter> <bew> what was it?
<gcds> naming of variable... was printing wrong parameter..
<FromGitter> <bew> arf ^^
<gcds> rx_checksum and rx_frame_checksum looks similar...
claudiuinberlin has joined #crystal-lang
<gcds> apparently that calculation is wrong which I ported from C :D
rohitpaulk has quit [Ping timeout: 240 seconds]
<crystal-gh> [crystal] asterite closed pull request #5178: Parser: correctly parse local variable in implicit block exception handler (master...fix/crystal/5177-local-variable-in-implicit-block-exception-handler)
<21WAAN3HJ> [crystal] asterite pushed 2 new commits to master:
<21WAAN3HJ> crystal/master 2d2ebac Ary Borenszweig: Merge pull request #5176 from MakeNowJust/fix/crystal-format/indent-implicit-exception-handler-with-do-end...
<21WAAN3HJ> crystal/master f8af24e TSUYUSATO Kitsune: Formatter: correctly indent implicit exception handler of do/end block...
<32NAA8Z9B> [crystal] asterite closed pull request #5176: Formatter: correctly indent implicit exception handler of do/end block (master...fix/crystal-format/indent-implicit-exception-handler-with-do-end)
<DeBot_> (Formatter: correctly indent implicit exception handler of do/end block)
<DeBot_> (Formatter: correctly indent implicit exception handler of do/end block)
<Papierkorb_> c c c combo breaker
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<crystal-gh> [crystal] asterite pushed 2 new commits to master:
<crystal-gh> crystal/master 03bf122 Luis Lavena: Honor no-color option from `spec` command...
<crystal-gh> crystal/master 08aaa7b Ary Borenszweig: Merge pull request #5168 from luislavena/pass-spec-no-color-option...
<crystal-gh> [crystal] asterite pushed 1 new commit to master:
<crystal-gh> crystal/master c8ee444 Harisankar P S: Time#days_in_year returns the no of days in a given year (#5163)
<gcds> a bit of work :D
claudiuinberlin has joined #crystal-lang
claudiuinberlin has quit [Client Quit]
Papierkorb_ has quit [Quit: Konversation terminated!]
<travis-ci> crystal-lang/crystal#2d2ebac (master - Merge pull request #5176 from MakeNowJust/fix/crystal-format/indent-implicit-exception-handler-with-do-end): The build passed.
<DeBot_> (Formatter: correctly indent implicit exception handler of do/end block)
rohitpaulk has joined #crystal-lang
<jokke> is there anything like YAML/JSON.mapping in ruby?
<travis-ci> crystal-lang/crystal#c8ee444 (master - Time#days_in_year returns the no of days in a given year (#5163)): The build passed.
<DeBot_> (Time#days_in_year returns the no of days in a given year)
ShalokShalom has joined #crystal-lang
<FromGitter> <yxhuvud> jokke: No.
<jokke> :/
<jokke> well there's dry-types
<FromGitter> <yxhuvud> many ORMs (ActiveRecord for example) have constructors that accept parsed json though.
claudiuinberlin has joined #crystal-lang
<gcds> ahm, is there a way to do something similar like memcpy Array(UInt8) to struct?
<FromGitter> <bew> no
<gcds> ech
<FromGitter> <bew> iirc it's because the binary order of fields cannot be verified, it may not be as you write it
<gcds> hmm I am sending struct to crystal side have no idea how to unpack it :D
<gcds> on c side i just do memcpy
<FromGitter> <bew> just read the struct field by field, and construct the struct when you have them all?
<FromGitter> <bew> I posted an example yesterday, let me try to find it
<gcds> yeah I remember that
<FromGitter> <bew> it was:
<gcds> ok what is quickest way to convert Array(UInt8) to Bytes?
<gcds> figured out
<gcds> to_unsafe and then used IO::Memory to read_bytes(UInt8) :P
<FromGitter> <bew> where does your array come from?
<FromGitter> <bew> it should never be an array in the first place I think
<gcds> I created it
<FromGitter> <bew> could you create a Bytes directly?
<gcds> ahm, I dont know... I dont have all bytes instantly... I read by byte
<gcds> and then append
<FromGitter> <bew> how do you read?
<FromGitter> <bew> reading byte by byte is slow!
<gcds> its from serial :)
<FromGitter> <faustinoaq> Interesting comments about Crystal in Elixir forum 👉
<FromGitter> <petoem> you can convert a Array(UInt8) to Bytes in an unsafe way, like this. ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ but if you are reading byte by byte, you should rework that. []
<FromGitter> <petoem> if you read from io, you could use #read method ⏎ to read bigger chunks at once
<gcds> petoem the problem is that it's uart if for e.g. something fucks up i need to restart parsing or etc. if I go parsing by chunks I will still need to iterate by byte
<FromGitter> <faustinoaq> `ary.to_unsafe` be careful, I think ary ( want to be safe 😆
<gcds> :DDDDD
<crystal-gh> [crystal] asterite opened pull request #5183: Implement JSON::Any and YAML::Any without recursive aliases (master...refactor/no-recursive-aliases)
<FromGitter> <bew> iterating is different than reading, it's fast to manipulate things in your memory, but it's "slow" to read byte by byte from a FD as it'll make a 'lot' of syscalls for a small number of result, where you could have the same 'slowness' but get more bytes out of it, making lower number of syscalls for a bigger amount of bytes read.
rohitpaulk has quit [Ping timeout: 240 seconds]
<FromGitter> <faustinoaq> Interesting, Rhine is a Typed Ruby made in C++ 👉 his README refers to Crystal 😉
ShalokShalom has quit [Remote host closed the connection]
<FromGitter> <bew> cool ;)
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
claudiuinberlin has joined #crystal-lang
claudiuinberlin has quit [Client Quit]
claudiuinberlin has joined #crystal-lang
claudiuinberlin has quit [Quit: Textual IRC Client:]
flaviodesousa has quit [Quit: KVIrc 4.2.0 Equilibrium]
<FromGitter> <drosehn> @Sija wrt `Crystal::VERSION` - thanks!
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Quit: Ping timeout (120 seconds)]
rohitpaulk has joined #crystal-lang
<crystal-gh> [crystal] luislavena opened pull request #5184: Avoid misleading error message in HTTP::Params.encode (master...restrict-type-on-http-params-encode)
claudiuinberlin has joined #crystal-lang
hightower3 has joined #crystal-lang
hightower4 has quit [Ping timeout: 260 seconds]
rohitpaulk has quit [Remote host closed the connection]
mark_66 has quit [Remote host closed the connection]
<jsn-> does crystal have something like python's if __name__ == "__main__"? something in flags, maybe?
<FromGitter> <bew> hmm no don't think so, why do you need that?
<FromGitter> <unreadable> It doesn't have
<FromGitter> <unreadable> python is python, crystal is crystal
<jsn-> it's useful to add an optional main() to a file, that is only compiled when the file is the main entry point (and not when it is require-d)
<FromGitter> <unreadable> I know, but it's not end of the world though. You can code without it pretty fine
<jsn-> ruby does that with if if __FILE__ == $0, python with __name__ == "__main__", nim with isMainModule or something
<FromGitter> <unreadable> I'm pretty sure you can find an workaround
<FromGitter> <asterite> it's called a "samples" directory :-)
<FromGitter> <bew> :D
<jsn-> it most definitely is not :)
gcds has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lacour has joined #crystal-lang
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter> <asterite> why not?
<jsn-> it's more verbose, you lose private's, etc
<jsn-> if __FILE__ is visible to macros, perhaps adding another magic var for main module would solve this
<FromGitter> <asterite> But crystal is compiled
<FromGitter> <asterite> you compile into, say, some_other_name
<jsn-> yeah, so is nim
<FromGitter> <asterite> you can do that in nim?
<jsn-> yeah, "when isMainModule" is compile-time thing
<FromGitter> <asterite> but in crystal you can pass multiple files to compile together...
<FromGitter> <asterite> there's no "main" file (well, not always)
<FromGitter> <asterite> In any case, I don't see the point of it. A samples directory is better, you have one place to show samples instead of having them sprinkled in all of your sources
<jsn-> why would you want that? to make a concatenated main()?
<FromGitter> <asterite> Yes. That's how you can run multiple spec files, for example
<FromGitter> <bew> @asterite never tried to compile multiple files, what is it for? when will the "main" of the second file will start? after the one of the first file?
claudiuinberlin has joined #crystal-lang
<FromGitter> <unreadable> In Go, compiling multiple files is pretty common
<FromGitter> <unreadable> Didn't know you can do that in crystal
<FromGitter> <asterite> Yes, "main" in Crystal is just all the top-level code you can find. If you compile two files they get concatenated
<FromGitter> <asterite> Actually, the compiler just concatenates everything you pass to it, plus every file you require. In the end it's just a big huge file that's compiled (at least it's one way to see it)
<FromGitter> <asterite> We could, however, have something like `{% if isMainModule %}` or something like that, but I never needed such thing in my life so at least I won't implement it
gcds has joined #crystal-lang
<Papierkorb> Just have a `` and a ``, or `` and ``
<Papierkorb> the lib one you can require for specs or w/e, the bin one you run for the program. If it's done well™, the bin one shouldn't host many lines of logic anyway
<FromGitter> <eliasjpr> Hello I felt compelled to reply to the Elixir forum on a Discusion about Crystal
<FromGitter> <asterite> Nice, thanks :-)
<Papierkorb> eliasjpr, your comment is like the most reasonable one in the whole thread. "Durr it's just ruby but on llvm" u wot m8
<FromGitter> <asterite> I wonder how to do a simple smiley in gitter...
<FromGitter> <asterite> :) :D
<dom96> wow, how did you guys improve Crystal's performance in these benchmarks so much? :)
<FromGitter> <asterite> Oh, they are different...
<Papierkorb> tried `:smile:` or so?
<FromGitter> <unreadable> Are all the go frameworks techempower benchmarks run with `gomaxprocs(numcpu)`?
<Papierkorb> though ascii emoticons best emoticons
<FromGitter> <bew> nice answer @eliasjpr !
<FromGitter> <asterite> dom96: it's a good question, i'd like to know that too :-D
<dom96> heh :)
<FromGitter> <bew> @asterite try (:
<FromGitter> <bew> or :] ;)
<FromGitter> <eliasjpr> I got you guys! :D
<FromGitter> <eliasjpr> We got this
<FromGitter> <sdogruyol> @eliasjpr great job 👍
<FromGitter> <sdogruyol> However I still see the same dangerous pattern with Elixir = Phoenix
<FromGitter> <sdogruyol> I'd like to keep that away from Crysta
<FromGitter> <sdogruyol> Crystal*
<FromGitter> <eliasjpr> Whats that pattern @sdogruyol?
<FromGitter> <sdogruyol> Ruby = Rails, Elixir = Phoenix pattern
<FromGitter> <eliasjpr> Crystal = ~
<FromGitter> <eliasjpr> :D
<FromGitter> <bew> 👍
<FromGitter> <Rinkana> Crystal = Life
<FromGitter> <Rinkana> However Amber does look promising. So who knows if that happens. While i personally prefer not to use crystal for web.
<FromGitter> <asterite> I downloaded Amber and it took like 45 seconds to compile the first time. Then it was about 5~7 seconds so it's probably acceptable. I should stop complaining so much about compile times :-)
<FromGitter> <sdogruyol> @asterite isn't it awesome to see how your creation inspires others :P
<FromGitter> <asterite> (though watching those Nim casts and seeing the compiler compile itself in a few seconds...)
<FromGitter> <Rinkana> For when Crystal is 1.0+ partial compiliation might be a good idea
<FromGitter> <unreadable> Does nim generates safe c code?
<FromGitter> <asterite> sdogruyol: I just had an initial idea, but the overall result was shaped by all of us (:
<FromGitter> <sdogruyol> @asterite what's the most time consuming part of compiling, type inference?
<FromGitter> <bew> llvm codegen!
<FromGitter> <bew> on crystal part, I think it's type inference too
<FromGitter> <asterite> Yes, well. There's no "type inference" phase really, it's just "semantic"
<FromGitter> <asterite> finding methods, instantiating them, typing method bodies
<FromGitter> <sdogruyol> what if we go full typed Crystal, does it make miracles? Can we compile everything say 10x faster?
<Papierkorb> No. The most important change would be that full typed methods are instantiated as such. Then you can choose what you "want"
<Papierkorb> Which would be the best of both worlds
<FromGitter> <asterite> Full typed Crystal means you can compile a file into an .o and then only recompile it when it changes
<FromGitter> <unreadable> I wouldn't mind a full typed crystal
<FromGitter> <asterite> but it's not that simple
<FromGitter> <asterite> but that also means no more reopening classes, redefining methods, etc.
<FromGitter> <asterite> so I guess that will never happen (and that's probably good)
<Papierkorb> I *would* mind unreadable
<Papierkorb> unreadable, it's not even about "just do things fast", leaving your algorithms open to some extend allows you to just use it with whatever in the future, without having to change any code. that's amazing.
<FromGitter> <unreadable> It is
<Papierkorb> Without creating a mess at that. Doesn't mean you don't want to type where it makes sense, if not for compilation speed (c'mon), but for type safety and documentation purposes
<FromGitter> <mvlootman> Hi all, is there a way to call/execute another compiled Crystal file into a running Crystal app?
<FromGitter> <mvlootman> I want to generate some code and then call that.
<Papierkorb> mvlootman, simplest: call out to the crystal compiler program
<Papierkorb> mvlootman, but what do you want to achieve?
<FromGitter> <mvlootman> ok that is what I thought too
<FromGitter> <mvlootman> I want to transform decision tables into code (ast > codegen)
<FromGitter> <Rinkana> @mvlootman i was just reading this issue: it might help you
<FromGitter> <mvlootman> but I would like to simulate/test the generated code
<FromGitter> <mvlootman> so I can call the generated code through a web ui
<Papierkorb> You could dive into the play command, how it does it, for inspiration
<FromGitter> <mvlootman> @Rinkana I saw that too, but I guess that would need to recompile my main program to let the macro run. I would like a closed main program and only calling the generated code/executable
<FromGitter> <mvlootman> @Papierkorb that is a fine idea! thanks
<FromGitter> <asterite> Papierkorb: for extensibility there exists the concept of interfaces and traits. But it's true that one has to write more for that. The tradeoff is faster compile times and maybe better documentation.
<Papierkorb> asterite, I think it's simply upfront/honest to say "I couldn't care less what you give me", instead of hiding behind tons of traits. Or, I'm not really convinced that forcing to write a interface-thing really improves code quality across the board.
<Papierkorb> Note that I'm fine with the current compilation times.
<FromGitter> <sdogruyol> I'm also okay with compilation times, except --release which is quite normal to take time
<Papierkorb> Sometimes, it actually readability. If you have `foo` as argument in your class everywhere (or use it like that even application-globally), no need to say for the umpteenth time that `foo` is an instance of `Fooable`. At least it's what I noticed in my projects
<Papierkorb> it actually improves readability*
<jsn-> mvlootman, well, you can use LLVM module
<jsn-> but it's rather cumbersome
<FromGitter> <sdogruyol> @asterite have you take a look at how rust improves compile times
<FromGitter> <mvlootman> that kinda scares me 😄 I will first look into how the playground handles the input text -> code -> output and see if I can do something similar
<FromGitter> <asterite> sdogruyol: no, but I don't think anything we can use anything rust uses because Rust is fully typed
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter> <sdogruyol> btw that might be not directly related, do you have any idea on how full parallelism will affect Crystal
<FromGitter> <sdogruyol> if so I'd love to hear your opinions
<FromGitter> <asterite> Sure
<FromGitter> <asterite> It will make most of the current things slower. Probably the techempower benchmark will give worse results
<FromGitter> <asterite> but at least more (all) cores could be used
<FromGitter> <asterite> so more stuff done at parallel, but each stuff slower
<FromGitter> <asterite> then one would have to be very careful not to accidentally share memory, because that will either lead to segfaults or undefined behaviour
<FromGitter> <asterite> that is, if we go the Go route
<FromGitter> <unreadable> Wait, is it worth the trade?m
<FromGitter> <asterite> another way could be doing something like Ruby guilds, or that new node vm by microsoft where you have isolated threads
<FromGitter> <unreadable> Is thay how Go handle it??
<Papierkorb> What would be fantastic (on the long run) would be a race/thread sanitizer to tell you if you were about to write to a variable from multiple threads. Or if it can, for some cases maybe possible, fix it "by itself" without using mutexes
<FromGitter> <asterite> unreadable: yes, but I think in Go you'd get a panic instead of a segfault, not sure
<FromGitter> <asterite> and Go has a built-in race detector (at runtime)
<FromGitter> <unreadable> Oh ok
<Papierkorb> Those sanitizers are really doing gods work in Clang. Took a while, it's far from trivial that's for sure
gcds has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter> <sdogruyol> @asterite which one do you feel like more natural for CSP
claudiuinberlin has joined #crystal-lang
<FromGitter> <sdogruyol> I don't know any language other than Go using CSP so feels like having race detector e.g is the norm..
<Papierkorb> No idea if anyone does it, but if we could 1) mark classes/structs as thread-safe 2) have a "borrow" mechanism to pass re-entrant class instances around - I think that'd solve almost every issue there is
<Papierkorb> So a bit rust-y on that end, but still more "open"
<FromGitter> <Rinkana> @asterite do you have any idea what kind of performance impact it would give?
<jsn-> mvlootman, from what I see, playground just compiles the source to a temporary executable file, executes it and picks up the output using pipes
gcds has joined #crystal-lang
<Papierkorb> that "borrow" could be implicit though. `a = 4; spawn{ puts(a) }; a = 5` could e.g. error while compiling.
<FromGitter> <sdogruyol> @Papierkorb that just feels like Rust
<FromGitter> <bew> Papierkorb but then the Proc's second pointer is useless
<Papierkorb> why?
<FromGitter> <bew> the closure data
<FromGitter> <bew> there's no closure if you can't compile one (for a spawn at least)
<Papierkorb> As long `a` isn't thread-safe you can't modify it concurrently. If it was, you could do so just fine
<FromGitter> <bew> ah ok got it!
<FromGitter> <mvlootman> @jsn- OK thanks for looking into that, that was a way I could see working too. Or calling crystal eval
<FromGitter> <bew> `spawn` is a stdlib method, but a `@[Attribute]` could tell the compiler that things in there will "implicitely borrow"
<Papierkorb> That part is important, that you can mark stuff as being so. That of course means that you have to get it right. I think that's worth it, there are plenty use-cases where that'd really help. Compiler-guaranteed secure by default, user-guaranteed on demand
<Papierkorb> bew, it should really be that you say "this variable here can be changed concurrently, it's fine" and/or "this whole class is thread-safe". But not "these two methods are thread-safe, others are not"
<Papierkorb> Either your stuff is thread-safe, or it's not. There are tons of papers where people describe how "sometimes thread-safe, sometimes whatever" went up in fireworks.
<FromGitter> <sdogruyol> @Papierkorb how to explicitly mark then?
<FromGitter> <bew> right, but I was mentionning how the compiler would know that variables must be thread-safe or not when used in this or that block
<Papierkorb> sdogruyol, for class, an attribute could do I think. for vars, maybe a `concurrent` keyword?
gcds has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Papierkorb> bew, assuming "what is used is borrowed" in the compiler would be fine I think
<FromGitter> <sdogruyol> wonder how hard is that though
<FromGitter> <sdogruyol> (to implement)
<Papierkorb> No idea!
<Papierkorb> :P
<FromGitter> <drosehn> (aside: From what I see when building both the `crystal` and `rust` compilers on macOS, it takes *MUCH* longer to build `rust`. So I'm not sure that I'd look there for speed improvements! 😄 )
<Papierkorb> sdogruyol, "non-trivial" territory I'd say
gcds has joined #crystal-lang
<dom96> asterite: yay, you watched our livestreams? :D
<FromGitter> <sdogruyol> hey @dom96 I watched a bit, good job 👍
<FromGitter> <sdogruyol> I saw Andreas using Windows :O
<dom96> Yeah, he loves Windows :)
<FromGitter> <unreadable> Where can I find that livestream :)
<FromGitter> <unreadable> Dom96
<FromGitter> <sdogruyol> it's great to see Nim fully working on Windows
<FromGitter> <asterite> dom96: I just watched a bit to see how it looks like. Nim looks fun, and fast! I read the manual but never coded anything in it (but want to!)
<dom96> unreadable: there are multiple videos, some by me:
<FromGitter> <unreadable> Thanks!
<Yxhuvud> regarding the discusssion earlier on shared memory, I wouldn't mind having to declare all shared memory explicitly. It is and shouold be an edge case in most code, so being more verbose is ok.
<dom96> asterite: It means to see you say that :) Crystal is awesome too btw, you're doing an awesome job :D
<dom96> *It means a lot
<FromGitter> <sdogruyol> @dom96 do you have any other core member except you two
<FromGitter> <asterite> (:
<dom96> sdogruyol: zahary as well, but he doesn't get much time unfortunately
<Papierkorb> Yxhuvud: I think it's fine as long the compiler can guarantee everyones just reading from them, not writing. It's possible, just expensive. Though it should be cachable, so maybe cpu cycles well spent :)
<Yxhuvud> Papierkorb: regardless, I'd want it explicit. Even read-only code will need consistency guarantees in many cases.
<Yxhuvud> unless it is something atomic, but most things ain't
<dom96> Still curious about how you guys made Crystal run so fast on the web framework benchmarks
Kug3lis has joined #crystal-lang
Kug3lis has quit [Client Quit]
<Papierkorb> basically, LLVMs optimizer has a field day when it comes to the stdlibs HTTP code (client AND server) dom96.
<FromGitter> <akzhan> crystal 0.24 tempo is twice about 0.23 tempo… and it takes twice less memory )
<Papierkorb> that's lit
<FromGitter> <asterite> akzhan: you mean to compile a program?
<dom96> Papierkorb: interesting, but how do you guys parallelise it and what do you use for the networking? (libuv? custom code?)
<Papierkorb> 1) parallelize? Nada. 2) LibEvent ftw
<Papierkorb> tbh libevent and boehmgc continue to exceed my expectations
<FromGitter> <akzhan> @asterite any estimates to get good hasher. I skill want to embded it and numberlizer )
<Papierkorb> dom96: Those techempower people may have forked $ncpu times, haven't checked
<Papierkorb> dom96: if they don't, it's single core
<FromGitter> <akzhan> @asterite just
<FromGitter> <sdogruyol> @papierkob forked
<FromGitter> <akzhan> 1) 23 was in development two months!
<dom96> I see, so are you using libevent directly in your HTTP server?
<dom96> or do you have some nice abstraction?
<Papierkorb> everything I/O is libevent
<Papierkorb> You can't not use it
<Papierkorb> Well, you can directly interact with LibC and get around it, but ....
<Papierkorb> (... not sure about File I/O)
<FromGitter> <sdogruyol> does nim have nonblocking io as well @dom96
<FromGitter> <asterite> akzhan: it's just I know nothing about hasing, but we'll probably merge the PR by funny falcon
gcds has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<FromGitter> <pnloyd> Is it normal for `{{ str_obj }}` to come out as `"str_val"` with the double quotes?
<Papierkorb> if str_obj is a StringLiteral, yes
<dom96> sdogruyol: yep, supports futures and async await too
<Papierkorb> you can use `#id` if you don't want that
<FromGitter> <sdogruyol> that's cool
<FromGitter> <akzhan> @asterite it will be fine. a lot of languages use new algorithms, spihash is just one cryptographic (we need nothing of crypto here)
<dom96> How does Crystal handle this? Does it also use coroutines?
<Papierkorb> green-threads, so yes, we call them fibers
<FromGitter> <pnloyd> @Papierkorb thanks that is what I wanted.
<Papierkorb> dom96: fibers switch among themselves if once one is sleeping, or waits for I/O. Only then is another fiber (automatically) woken up
<dom96> so basically what Go does except single threaded
<FromGitter> <sdogruyol> yes
<FromGitter> <asterite> for now (:
<dom96> oh? What's the plan for the future?
<Papierkorb> that but in multi-threaded
<FromGitter> <sdogruyol> @asterite are you working on parallelism or is it out of your specialty :P
<dom96> ahh
<FromGitter> <faustinoaq> > @sdogruyol: what if we go full typed Crystal, does it make miracles? Can we compile everything say 10x faster? ⏎ >> Full typed Crystal means you can compile a file into an .o and then only recompile it when it changes ⏎ ⏎ @asterite An experiment achieving would be very interesting, so Full typed Crystal would be a subset of Crystal, I means valid FTC(FullTypedCrystal) code is valid Crystal, however
<FromGitter> ... all Crystal (type inference,reopening classes, redefining methods, etc.) isn't valid FTC WDYT? []
<FromGitter> <sdogruyol> @faustinoaq that sounds interesting, however I'm not sure if we have the resource for that :P
<FromGitter> <faustinoaq> Hi dom96!
<FromGitter> <akzhan> All i need is scheduler multicore
<FromGitter> <asterite> sdrogruyol: I'll say parallelism is out of everyone's speciality, regarding it implementing it well and fast :-P
<FromGitter> <akzhan> All other can be written by myself and friends )))
<FromGitter> <asterite> But no, I'm not doing anything related to that. Just fixing some issues and other things when I have time
<FromGitter> <sdogruyol> @asterite I know that waj and gustavo is more experienced at least :P
gcds has joined #crystal-lang
<FromGitter> <faustinoaq> > however I'm not sure if we have the resource for that ⏎ ⏎ Making a experiment for a Full Typed Crystal subset should just remove a lot of code (type inference algorithm) and enforce typing, isn't? 😅 ⏎ Sounds interesting, I think should be an excellent learning experience about Crystal 😜 []
<dom96> hi faustinoaq :)
<FromGitter> <asterite> For sure! They did most of what there is now. But believe me, it's super, super hard. You get crashes and you have no idea where to start debugging that. So it's reasonable that it takes a lot of time
<FromGitter> <sdogruyol> I can't think of anything harder than that for a programming language..
<Yxhuvud> well, writing a GC that fits everyone is pretty close.
<Papierkorb> +without halting the world
<Yxhuvud> that is part of fitting everyone
gcds has quit [Client Quit]
gcds has joined #crystal-lang
gcds has quit [Client Quit]
nicbet has joined #crystal-lang
<crystal-gh> [crystal] luislavena opened pull request #5185: Avoid misleading error when using HTTP::Client form options (master...restrict-http-client-form-hash-types)
<RX14> i always find it interesting how crystal appears faster than go in HTTP benchmarks yet has the same concurrency model
<RX14> i wouldn't have put it down to LLVM myself
<RX14> perhaps it's the preemptive scheduling overhead
<RX14> perhaps it's the less-mature optimizer
<RX14> perhaps it's a side-effect of handling parallelism
<RX14> but it'd be interesting to *know*
claudiuinberlin has quit [Quit: Textual IRC Client:]
<FromGitter> <asterite> I think it's a combination of many things. LLVM, single thread (multiple threads will actually decrease throughput)... there's also the fact that Go reserves a few registers for making context switches super fast, at the cost of making some other things slower. I think the GC is also optimized for short pauses time at the cost of making things evenly a bit slower. Go prioritizes stuff for servers. Right now in
<FromGitter> ... Crystal with one thread maybe you have some code that blocks the entire thread and stops other requests (for example computing bcrypt). Go is also preemptive so there are some context switches where you didn't put them.
<FromGitter> <asterite> But they optimize Go every day, and eventually I think it will be faster than anything else
<Papierkorb> Well, LLVM nor GCC are sleeping
<RX14> they've had quite some time to optimize go
<RX14> i'd be surprised if there are any major or easy wins outside the compiler
<RX14> and i don't see their codegen or opt in the compiler ever beating LLVM
<RX14> so overall I really don't see them getting much faster in the benchmarks
<RX14> we still haven't implemented escape analysis
<RX14> which i think would really help a http benchmark
<FromGitter> <sdogruyol> @asterite what if we had the same optimization for Crystal :P
<RX14> which one?
<RX14> and it's never just that simple
<FromGitter> <ylluminate> rx14, you might want to check out #crystal
<RX14> why
<Papierkorb> why another channel
<FromGitter> <ylluminate> that's nanobox's preferred method for work
<Papierkorb> There's gitter for those who want a web ui, and IRC for those who don't
<RX14> but why nanobox
<FromGitter> <ylluminate> and it looks like they're finally getting crystal support in place
<RX14> whats the context here
<FromGitter> <ylluminate> marketing
<RX14> what is nanobox
<Papierkorb> ylluminate, isn't that their job?
nicbet has quit [Quit: Laters!]
<FromGitter> <ylluminate> crystal is essentially a more cost effective heroku running on your preferred platform
<FromGitter> <ylluminate> papierkorb, it's a little bit of both. this can only help crystal
<Papierkorb> Ah well. If they need help, they know how to contact the community
<RX14> i mean
<RX14> that link is also useless to me
<RX14> since it's invite only
<FromGitter> <ylluminate> i don't think there's enough motivation to just reach in here. crystal's not a big target for them as far as the main languages go, but they're going for it nonetheless
<RX14> if they're willing to do it
<RX14> they're willing to open up a browser tab
<FromGitter> <ylluminate> it's not invite only, i just got an email activation in 30 seconds and was in
<RX14> and use gitter
<RX14> uhh
<RX14> from where?
nicbet has joined #crystal-lang
<RX14> "If you have an or email address, you can create an account."
<RX14> guess what
<RX14> i dont work there
<FromGitter> <ylluminate> i just used a generic gmail account
<FromGitter> <ylluminate> popped right in
<RX14> to
<RX14> where
<RX14> you must have been GIVEN an invite link
<RX14> there's nowhere to register
<RX14> thats not how slack works
<FromGitter> <ylluminate> no i used
<RX14> ok
<RX14> so you just sent the wrong link
<Papierkorb> /r/WhatCouldGoWrong
<FromGitter> <ylluminate> yeah, i was grabbing what was in my chat window
alex`` has quit [Quit: WeeChat 1.9.1]
RickHull has joined #crystal-lang
<FromGitter> <asterite> RX14: there's another thing. Go is probably safe from ddos attacks, slow attacks, etc. Crystal is not. So only when Crystal can run on multiple threads and is safe from those attacks it's fair to do benchmarks
<RX14> people were advising go to always run behind a load balancer well past 1.0
<RX14> i think we're fairly safe
<RX14> the problem is that our API doesn't encourage people to use it safely wrt attacks
<RX14> i.e. it encourages people to read without limits
<RX14> well maybe not encourage
<RX14> but makes it easy
<RX14> read without limits is my main concern
<FromGitter> <asterite> that, but also hash randomization is not present in the techempower benchmarks, so if you know the hash you could just kill the server
<RX14> surely slow attacks would be mitigated by event
<FromGitter> <asterite> event?
<RX14> being nonblocking
<RX14> any attempt to make the server block just switches fiber
<RX14> you can get a memory leak from that though hmm
<RX14> since the ~8k/fiber memory overhead
<RX14> 4k being the stack page thd the other 4k being os/other allocations
<RX14> when iw as doing my loop { spawn } tests I saw roughly equal memory usage from the OS and from crystal
<RX14> which surprised me
<RX14> seems that with so many 4k stacks the OS ends up doing a lot of bookkeeping
<RX14> this was at 5 million fibers though
<RX14> i don't see too many pressing issues on the suitablity of exposing crystal raw to the public
<RX14> apart from hasdos
<FromGitter> <asterite> yeah, I think you are right
<RX14> which will be solved shortly
<RX14> typically you'll hit other limits before exhausting the crystal fiber memory limits
<RX14> not sure though
<RX14> actually i'm not sure about that
<RX14> actually
<RX14> if you have the incorrect sysctl settings, crystal will simply abort after 32k fibers
<RX14> because linux refuses to allocate it more virtual memory
<RX14> which is a problem
<RX14> perhaps there should be a way to gracefully handle a failure spawning a fiber
<RX14> spawn? or similar
<RX14> and have HTTP drop the connection if it fails to spawn
<RX14> i think the wrong max_maps setting is pretty limited to arch though
<RX14> it certainly was unlimited by default on debian
c-c has joined #crystal-lang
<c-c> Hello
<RX14> hi
<c-c> I'm considering porting my simple game project to crystal from rubyland
<c-c> It has three basic modules it needs to work. Process based concurrency (ie. execution in diff processes), yml parsing - and named pipes. The named pipes are implemented using linux mkfifo, so all the program needs to do is open/read/close/flush them.
<c-c> - And I'm not so certain about the process based concurrency.
<c-c> Does crystal support these features?
<RX14> what exactly do you mean by process based concurrency
<RX14> what's the larger problem you're trying to solve
<RX14> not the exact solution you're using in ruby
<RickHull> fork() ?
<RX14> we have fork but it's not really the best way to go
<c-c> The larger problem is 'computer game that runs fast and can utilize +2 cores'.
<RX14> although it does work
<c-c> It is a planet simulator.
<RX14> c-c, you say multi-process
<c-c> *May be, one day
<RX14> hopefully some day we will support native parallelism in crystal
<c-c> RX14: suppose you have separate execution for ui process, that is updated independent of the game rule logic process, that is independent from the planet state server.
<RX14> but for now you can spawn other "worker" processes, yes
<c-c> RX14: process based concurrency is what ruby uses.
<RX14> yeah thats cool
<c-c> I'm mosly concerned about the IO
<RX14> named pipes (sockets?) are a thing
<c-c> RX14: IPC methods in order of throughput: shared memory, named pipes, unix domain sockets, pipes, tcp sockets
<c-c> pipes can sometimes be faster than domain sockets
<RX14> why are named pipes faster than pipes
<c-c> and what did I forget
<c-c> well, the last on the list should be "file on disk"
<RickHull> don't forget email ;)
<RX14> c-c, i'm not sure we have explicit support for named pipes
<c-c> RickHull: email for IPC? Not happening
<RX14> but they're just "normal files" is a large sense
<RX14> so surely they'd work just from
<c-c> RX14: named pipes are faster than pipes because they are implemented inside the kernel differently (short answer)
<RickHull> c-c: email makes about as much sense as tcp sockets and file on disk
nicbet has quit [Quit: nicbet]
<c-c> So if on linux, one isntalls crystal, writes $ mkfifo /tmp/a_test_named_pipe, and then in a crystal program says "require 'IO'; open '/tmp/a_test_named_pipe'" - will it error out?
<RX14> email over tcp's probably still faster than file on disk lol
<RickHull> c-c: I'm pretty new to Crystal, but I'm guessing if you stick to Unix conventions, as you are proposing, Crystal will not be in your way
<RX14> assuming localhost
<RX14> c-c, probably not
<RX14> it just calls open on it
<RX14> normal libc open
<RX14> and you get a class which inherits from IO::FileDescriptor
<c-c> RickHull: well, file on disk is the oldest IPC method. TCP sockets etc are used for convinience
<RX14> and so you can perform all your normal read, write, ioctls, whatever you want
<RickHull> c-c: and my boss always wants my programs to send emails and copy me personally ;)
<RX14> just normal
<RX14> without special checks on the type of file
<c-c> hm, may be that in my ruby, 'open' isn't in 'IO' but base
<RX14> yeah this isn't ruby
<RX14> you use
<RX14> and File and IO are core
<RX14> people say crystal is like ruby
<RX14> but that's only true in feeling
<RX14> not in any reliable technical fashion
<RX14> things move, we clean things up, we make radical changes, and we do it because we think we can do better than ruby
<c-c> Anyway, named pipes are my idea of fastest possible IPC without actually sharing access to memory.
<RX14> we'll have typical shared memory at 1.0 release
<RX14> at least we think so
<RX14> or at least parallelism of some kind
<c-c> Its not pop, or even common, most ppl use sockets, but what I've seen named pipes can be a magnitude faster than (domain) sockets.
<RX14> try it out
<c-c> Shared memory is not parallellism.
<RX14> report back
<c-c> Its an IPC method ;)
<RX14> c-c, no but we use typical memory
<RX14> it's shared memory
<RX14> oh nvm
<RX14> you mean shared memory between multiple processes
<c-c> hehe where I'm from processes don't let other processes mess with their memory
<RX14> i always forget that exists
<RX14> instead of just threads
<RX14> when people talk about shared memory
<c-c> ok perhaps child process memory can be exchanged when they are small
<RX14> ??
<c-c> (that last one is me attempting humor)
<RX14> so you don't want typical threads
<RX14> you want shared memory?
<c-c> No, I want processes. Processes have a clear lifecycle, ownership, execution state. I want named pipes. The fastest way two processes can send messages to each other without sharing access to memory.
<RX14> ok
<RX14> well you have that
<RX14> and i encourage you to try it out
<RX14> if it doesn't work it's a bug
<c-c> The OS can manage processes, even the user can do that. Threads: opaque.
<RX14> we should bind mkfifo as a function too
<c-c> On linux, mkfifo is system level.
<RX14> so you shouldnt need to shell out
<c-c> So, if you can do '' system("mkfifo /tmp/another_pipe") '' in your lang, you are set.
<RX14> even better
<RX14> LibC.mkfifo
<c-c> I think OSX can use that too. And to delete it, its just a file on disk.
<RX14> it's not bound "nicely"
<RX14> but it has LibC "raw C" bindings
<RX14> so you can pass a Char* (hint, String) to it
<c-c> I'm arguing that at least on linux or OSX you don't need language level 'mkfifo'
<RX14> sure you can shell out
<RX14> but you could also bind it directly
<c-c> (just as long you can open/read/close the pipe end in your program)
<RX14> i said you can
<RX14> just tests it
<c-c> - So is there a 'translate from ruby to crystal' guide?
<c-c> Or maybe a video I should see, or?
<RX14> uhh
<RX14> learn the language first
<FromGitter> <bew> Probably the crystal docs to read first!
<RX14> then see if it's feasible to translate
<c-c> I read most of the already
<c-c> everything looks familiar from ruby
<FromGitter> <bew> "looks" :p
<c-c> Thats as deep as I can go by reading
<FromGitter> <bew> Did you tried some mini exercises in crystal?
<FromGitter> <bew> Improve them a little see how it goes when the compiler yields a (beautiful) error at you ;)
<c-c> bew naw
<c-c> I want to write my game
<FromGitter> <bew> You should!
<FromGitter> <bew> Yeah but first be sure that you know how the language work!
<c-c> Also would like to see "If you're coming from ruby you'll be screwed by these..."
<FromGitter> <bew> There 2-3 article/post on that iirc
<c-c> Is the idea of "I will port my ruby programz to crystal" deadborn?
<c-c> When will crystal implement borrowing (CG free memory management) from rust?
<FromGitter> <bew> Probably not! I've never worked with ruby myself, so I won't help much here, but you should be able to do it!
<FromGitter> <bew> Probably never, Crystal uses a GC
<FromGitter> <bew> It's not meant to be used without
<RX14> c-c, depends how you used ruby
<c-c> But, memory leaks
<FromGitter> <bew> Unless you want to write another stdlib
<RX14> it won't be smooth
<RX14> it depends largely on the program whether porting from ruby will be better than writing from scratch...
<c-c> named pipes would enable me to port the program part by part (ie. process by process), so some parts could still run as ruby, and some, like the super intensive planet state, be faster crystal
<FromGitter> <bew> Nice idea!
<c-c> Thanks! Only thing that peeves me is the weird unknowns about named pipes under windows
<c-c> Then it would be truly cross platform approach
<RX14> c-c, well we dont support windows at all yet
martinium has joined #crystal-lang