asterite changed the topic of #crystal-lang to: #crystal-lang The Crystal programming language | http://crystal-lang.org | Crystal 0.6.0 | 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
weskinner_mac has joined #crystal-lang
weskinner_mac has quit [Client Quit]
waj has quit [Quit: Leaving.]
waj has joined #crystal-lang
ismaelga has quit [Remote host closed the connection]
<crystal-gh> [crystal] waj pushed 1 new commit to master: http://git.io/Aee5
<crystal-gh> crystal/master 0e3ab30 Juan Wajnerman: Run Travis build using multi OS (linux and mac)
<jhass> oh, you got a slot for it?
<jhass> docs still say there's no capacity left
<waj> yes! I sent an email to support and I got it activated for this repo ;-)
<jhass> nice!
<travis-ci> manastech/crystal#2015 (master - 0e3ab30 : Juan Wajnerman): The build passed.
<waj> and it works! :)
waj has quit [Quit: Leaving.]
shama has quit [Quit: (╯°□°)╯︵ɐɯɐɥs]
bcardiff has joined #crystal-lang
bcardiff has quit [Quit: Leaving.]
canhtak has joined #crystal-lang
leafybasil has quit [Remote host closed the connection]
leafybasil has joined #crystal-lang
canhtak has quit [Quit: canhtak]
<crystal-gh> [crystal] asterite pushed 1 new commit to master: http://git.io/Av1N
<crystal-gh> crystal/master 13fafc6 Ary Borenszweig: [Spec] Show elapsed time in a better way
<travis-ci> manastech/crystal#2016 (master - 13fafc6 : Ary Borenszweig): The build passed.
ismaelga has joined #crystal-lang
ismaelga has quit [Remote host closed the connection]
canhtak has joined #crystal-lang
ismaelga has joined #crystal-lang
asterite has joined #crystal-lang
asterite has quit [Quit: Page closed]
ismaelga has quit [Remote host closed the connection]
waj has joined #crystal-lang
ismaelga has joined #crystal-lang
ismaelga has quit [Ping timeout: 245 seconds]
weskinner_mac has joined #crystal-lang
hplar_ is now known as hplar
bcardiff has joined #crystal-lang
canhtak has quit [Quit: canhtak]
canhtak has joined #crystal-lang
weskinner_mac has quit [Quit: weskinner_mac]
ismaelga has joined #crystal-lang
<travis-ci> manastech/crystal#2017 (master - a3254d2 : Juan Wajnerman): The build passed.
waj has quit [Quit: Leaving.]
weskinner_ has joined #crystal-lang
waj has joined #crystal-lang
_whitelogger has joined #crystal-lang
waj has quit [Quit: Leaving.]
shama has joined #crystal-lang
weskinner_ has quit [Ping timeout: 256 seconds]
weskinner_ has joined #crystal-lang
<weskinner_> how can I get a Void* on the stack to use for passing to c functions?
<weskinner_> currently I'm just Pointer(Void).malloc(1)
<weskinner_> but wondering if there is a better / cleaner way
<jhass> value :: Void*
<jhass> not that's currently not zeroed
<jhass> *note
leafybasil has quit [Remote host closed the connection]
ismaelga has quit [Remote host closed the connection]
canhtak has quit [Quit: canhtak]
<weskinner_> ahh thank you.
leafybasil has joined #crystal-lang
waj has joined #crystal-lang
bcardiff has quit [Quit: Leaving.]
<travis-ci> manastech/crystal#2018 (master - a5ef56d : Juan Wajnerman): The build passed.
<crystal-gh> [crystal] asterite pushed 1 new commit to master: http://git.io/AkwE
<crystal-gh> crystal/master 1f1b748 Ary Borenszweig: Fixed #427: Blocks with a Void return value should ignore the actual return value in any case
canhtak has joined #crystal-lang
<crystal-gh> [crystal] asterite pushed 1 new commit to master: http://git.io/AkKB
<crystal-gh> crystal/master 24be518 Ary Borenszweig: Leave the void check to the end so it's faster
bcardiff has joined #crystal-lang
<crystal-gh> [crystal] waj pushed 1 new commit to master: http://git.io/AkPF
<crystal-gh> crystal/master a3ee03f Juan Wajnerman: Cleanup apt caches after docker builds
<travis-ci> manastech/crystal#2020 (master - 24be518 : Ary Borenszweig): The build passed.
<travis-ci> manastech/crystal#2021 (master - a3ee03f : Juan Wajnerman): The build was broken.
<jhass> waj: just so I understand correctly. Does that mean you want to make applications "multithreaded" by default, that is 2.times do File.open("foo#{i}") do |io| @contents << io.read end end would be concurrent access to shared state?
<waj> no.. unless yo make an explicit "spawn" there is no concurrency
<waj> but if you do, every time you make a "read" it wouldn't block the entire process. It would give control to another fiber
<waj> in fact… at the beginning I'm thinking having just a single worker thread
<waj> so there would never be concurrency unless you make explicit use of threads
<waj> but, although concurrency != parallelism, there is still a chance to have shared state among different fibers
<waj> it would be just like Go
<jhass> I don't know Go tbh
<waj> mm… but Go has more than one worker thread
<jhass> so how would ("accidental") shared state in the new model look like?
<waj> if you read/write a global variable from a fiber for example
<waj> that was the motivation for the changes that asterite did in the regex results ;)
<jhass> well, that's why I used @content there
<waj> so now the $~, $1, etc… aren't global variables anymore
<waj> besides global variables, "spawn" works with a block so closured variables are shared state as well
<jhass> let's try content = ""; 2.times do File.open("foo#{i}") do |io| contents << io.gets end end; would that still be deterministic?
<waj> yes
<waj> Int#times is not spawning new fibers so the files are sequentially processed
<jhass> what would spawn new fibers by default?
<waj> only the "spawn" method
<waj> in other words… if you don't use "spawn", everything works exactly the same
<waj> the difference is… if you make a read in one of the fibers, instead of just blocking it gives control to another fiber waiting to run
bcardiff has quit [Quit: Leaving.]
<waj> mm… no, because I think it's desirable that HTTP calls are handled at the same time
<jhass> okay, so I think we arrived at my main concern: I have the feeling (and that might very well be FUD given I did almost zero evented programming yet) that when it's non obvious which stdlib call will result in a concurrent program and which won't, that will make the language more confusing and prone to subtle bugs
<weskinner_> waj: I missed the beginning of this convo but are you working on non-blocking IO for crystal?
<jhass> weskinner_: uhm, you didn't join or part in the mid ;)
<jhass> weskinner_: we're talking about https://github.com/manastech/crystal/issues/430
<weskinner_> thanks!
<weskinner_> ha
<waj> jhass: I think that's not a problem because as soon as you start using "spawn" you know that your program is going to be concurrent
<waj> and if you're serving HTTP requests that's exactly what you want
<weskinner_> just slightly more than I have :P
<weskinner_> at least it was good experience writing the C bindings
<waj> weskiner_: currently we have (incomplete) implementations for TCPSocket, TCPServer, File and sleep
<jhass> waj: maybe it is, the question I'm having is whether it's obvious that the block you pass to for example File.open is run sequentially while the callback you pass to HTTP::Server is run concurrently
<waj> well yes… that should be explicitly documented
<jhass> and while I agree you want to have the later happen concurrently, it's also the perfect example for where you often access shared state
<jhass> like a database connection or whatever
<jhass> or even just a logger
<waj> exactly
<waj> but you have the same problems in ruby ;)
<jhass> so if you're new and coming from something like Ruby, you'll wonder why your logger call there is all messed up all of the sudden
<jhass> which is why I liked the idea of having separate libraries for the evented stuff, you very explicitly decide to use that mode of operation, and since you decided you're aware
<jhass> well, stdlib logger being thread safe doesn't defy the general argument :)
<waj> it doesn't but currently if you write a logger you might want to consider concurrent calls
<jhass> let's get past the logger, that was just an example
<jhass> my argument really is that I'm not sure that documentation is sufficient to make a newcomer aware of that fact which in turn might make the experience with language more frustating since you don't understand why it behaves the way it behaves
<jhass> especially if you mix and mash the modes in stdlib
<waj> maybe you're thinking the change would much more drastic than what really is
<jhass> maybe, I said it might be FUD for reason ;)
<waj> besides the http server I can't easily find another case where concurrency is implicitly started
<waj> (in the std)
<jhass> so evented_io.cr will stay as it is?
<jhass> not replace io.cr?
<waj> he… evented_io should have gone away long time ago :P
<jhass> what about socket?
<jhass> which one will become the default?
<waj> there would be only one implementation backed by libuv
asterite has joined #crystal-lang
<waj> but… again, unless you make explicit use of spawns, the calls would behave just linear and blocking like they are right now
<jhass> mmhkay, FUD then. Thanks for clearing that up
<asterite> Don't you have the same shared access problems with HTTP::Server using threads?
<jhass> yes
<asterite> I think the conclusion that we came with waj is that having shared state is bad, for many reasons
<asterite> If you are using threads, or fibers, but you share global state, then your are in for trouble
<jhass> my point is that you easily are not aware that you're using shared state because you might not be aware you're code is run concurrently because other parts of stdlib you used before aren't
<asterite> So, I don't think the change to evented-io-only will solve these issues
<waj> Absolutely. Although shared access with fibers and a single worker is often more controllable even without locks
canhtak has quit [Quit: canhtak]
weskinner_ has quit [Ping timeout: 255 seconds]