01:24 <crystal-gh> [crystal] will closed pull request #1840: Build all files in ./src when there are no arguments (master...buildall) http://git.io/vltCV

14:59 <[spoiler]> Should #first and #last use Enumerable's methods, or should they behave more like Ruby's? Namely Range's first returns @begin regardless whether the range is `x...x`, same for last. While the Enumerable spec requires a raise. If Raising is required, I could just remove first() and add first(n) to Enumerable (same for last, but last is missing altogether)

15:00 <[spoiler]> however in (a...b).last will return b even if the range is exclusive

15:00 <[spoiler]> so it's essentially a synonym for end

15:00 <[spoiler]> (which I disagree with, personally)

15:01 <[spoiler]> so I would vote we change this from Ruby's behaviour. Should I modify the PR and start a discussion there?

15:07 <jhass> Yes, let's have this as a less epheremal discussion

15:07 <[spoiler]> k

15:07 <jhass> [spoiler]: also maybe split your PR up into smaller parts so we can get the uncontroversial stuff out of the way

15:13 <[spoiler]> jhass: meant to, yeah

15:13 <[spoiler]> oh you meant into multiple PRs or multiple commits?

15:15 <jhass> multiple PRs actually

15:19 <[spoiler]> Ah right

15:35 <[spoiler]> jhass: done (for range). lemme just add the specs for #last and #last? in Enumerable specs

15:36 <[spoiler]> well lemme run the full spec actually last time i just ran the spec for range lol

15:36 <[spoiler]> This will take an hour

15:54 <[spoiler]> ok they all passed on my pc, but the i368 check fails on travis for some reason

15:54 <[spoiler]> i386

15:54 <[spoiler]> but it seems unrelated

16:07 <RX14> http://elm-lang.org/blog/compilers-as-assistants

16:07 <RX14> This looks like a cool article

16:08 <RX14> Crystal has great error messages but I'm sure some I'd the ideas are new

16:12 <jhass> [spoiler]: doesn't look unrelated at all to me

16:13 <jhass> [spoiler]: though you may just want to change the includes? call to .covers? I guess

16:15 <[spoiler]> jhass: oh you mean `CallStack.makecontext_range.includes?`

16:16 <[spoiler]> Still slightly confused why it didn't break on 64bit though! *fixes*

16:36 <[spoiler]> jhass: yep changing to covers? worked

16:53 <crystal-gh> [crystal] omninonsense opened pull request #1896: Enumerable improvements (master...enumerable_improvements) http://git.io/v4SRe

16:53 <[spoiler]> oh drat

16:54 <[spoiler]> ok fixed

16:55 <[spoiler]> I'm getting good at rebasing (not sure if yay or nay)

18:58 <sdogruyol> does File and HTTP::Server share the same event loop?

19:00 <jhass> there's only one globally

19:01 <sdogruyol> jhass: does spawn also share the same event loop?

19:01 <jhass> I repeat, there's only one globally

19:01 <jhass> sdogruyol: all File and HTTP::Server internally do is use spawn

19:02 <sdogruyol> jhass: that explains it

19:03 <sdogruyol> jhass: i'm having a weird issue when trying to use 1 file handle to log the output to a file and a http server to listen at the same time

19:03 <sdogruyol> jhass: sometime the logs are appended after closing the server

19:03 <sdogruyol> jhass: not in order

19:03 <jhass> you still don't need to highly me on every message

19:03 <jhass> my client doesn't want to be a christmas tree

19:04 <jhass> do you use Logger?

19:05 <jhass> er, highlight

19:05 <sdogruyol> no i dont use Logger to output to file

19:06 <sdogruyol> code speaks louder https://github.com/kemalcr/kemal/blob/master/src/kemal.cr#L20-L30

19:06 <jhass> why not?

19:07 <sdogruyol> because i'm writing to a file

19:07 <jhass> Logger can write to any IO

19:07 <sdogruyol> okay

19:08 <sdogruyol> i'm not sure if it solves my problem though

19:08 <sdogruyol> need to check

19:10 <jhass> oh, mh, https://github.com/manastech/crystal/issues/1781 is still open

19:12 <sdogruyol> non atomic

19:12 <sdogruyol> :(

19:35 <crystal-gh> [crystal] hoffi opened pull request #1897: Enhance HTML::Builder (master...html_builder_enhancement) http://git.io/v49ol

19:37 <[spoiler]> oh that bug

19:40 <[spoiler]> in hindsight. I think you can't puts to stdout from a coroutine?

19:40 <[spoiler]> ie from a fiber

19:41 <jhass> pretty sure you can

19:41 <jhass> you can't from a Thread, that might be what you're remembering

19:46 <[spoiler]> Oh might be

22:09 <jokke> hey

22:09 <jokke> https://p.jreinert.com/Fhi/ruby

22:10 <jokke> this throws an error at the last puts

22:10 <jokke> File not open for writing (IO::Error)

22:10 <jokke> this used to work

22:10 <jokke> but doesn't with the latest crystal version