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 :(
<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>
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> 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
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
<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 (https://github.com/asterite) 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) https://git.io/vFvGP
<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++ 👉 https://github.com/artagnon/rhine 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…]
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) https://git.io/vFv0M
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 a.cr 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 `foo.cr` and a `foo_bin.cr`, or `foo_lib.cr` and `foo.cr`
<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>
<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>
<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>
<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!)
<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?)
<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>
<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 😜 [https://gitter.im/crystal-lang/crystal?at=59f0ec8e8808bed73d29ebeb]
<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) https://git.io/vFvpO
<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
<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
<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 @nanobox.io or @pagodabox.com 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> 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 File.open
<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 ;)
<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 FIle.open
<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!
<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