01:15 <FromGitter> <Blacksmoke16> can you build a binary from input via stdin or something?

01:15 <FromGitter> <Blacksmoke16> i.e. w/o needing a file

02:36 <FromGitter> <didactic-drunk> This is an idea I'm playing with. Is it possible to translate "#{class}.{method}" to a fixed offset at compile time? Example:

02:39 <FromGitter> <didactic-drunk> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=60ebab4617929c14e680f248]

02:42 <FromGitter> <Blacksmoke16> so that the methods are created in a specific order?

02:45 <FromGitter> <HertzDevil> something like https://play.crystal-lang.org/#/r/bj2m

02:46 <FromGitter> <HertzDevil> however this index is the overload order not the declaration order

02:46 <FromGitter> <HertzDevil> it's still unique though

07:00 <FromGitter> <wyhaines> @Blacksmoke16 ⏎ ⏎ ```{{ system("cat") }}``` ⏎ ⏎ STDIN is defined for macro code, but off the top of my head right now I don't know if there is a way to read from it with macro code currently. [https://gitter.im/crystal-lang/crystal?at=60ebe88f48f9b1084a25ecda]

17:28 <FromGitter> <jrei:matrix.org> `{{ read_file }}`

17:29 <FromGitter> <jrei:matrix.org> I didn't read before on what you want to do, here is only a better snippet

17:31 <FromGitter> <didactic-drunk> Is it possible to monkey patch `IO::FileDescriptor#read`? https://carc.in/#/r/bj7v

17:31 <FromGitter> <oprypin:matrix.org> why tho

17:56 <FromGitter> <didactic-drunk> Measure wait time

18:23 <xyhuvud> it should work to monkeypatch as long as you make certain the original is already loaded. file_descriptor should be loaded though

18:24 <xyhuvud> it works for me, but then I don't depend on previous_def.

18:33 <FromGitter> <didactic-drunk> `previous_def` is the important part. `require "socket" ` doesn't seem to help. Is this a load order problem or issue with modules? https://carc.in/#/r/bj8y

18:36 <FromGitter> <Blacksmoke16> `IO` doesn't implement `unbuffered_read`

18:36 <FromGitter> <Blacksmoke16> `FileDescriptor` should because it includes the module, so it should deff have that method

18:37 <FromGitter> <Blacksmoke16> wonder if it's because the method is coming from another module

18:37 <FromGitter> <Blacksmoke16> in this case you'd prob want to use `super`

18:52 <xyhuvud> FileDescriptor implements it by itself though

18:53 <FromGitter> <Blacksmoke16> it's implemented via the `include Crystal::System::FileDescriptor`

18:53 <FromGitter> <Blacksmoke16> so ends up not being a redefinition

19:15 <mikko> well this is a fun bug https://github.com/crystal-lang/crystal/issues/2485

19:16 <mikko> my almost trivial code has been compiling for many minutes due to this line: StaticArray(Bool, 10_000).new(true)

19:16 <FromGitter> <Blacksmoke16> nice

19:17 <FromGitter> <Blacksmoke16> is there a reason to have a 10k member static array tho?

19:17 <mikko> i was just wanting to experiment with bitarray vs staticarray vs array

19:17 <mikko> trying to see what kind of performance i get with each

19:17 <FromGitter> <Blacksmoke16> fair enough

19:25 <FromGitter> <wyhaines> I think that if you search the archives in here, you will find some other discussion of StaticArray and that compilation performance cost. I remember seeing it....a yearish-ish ago.

19:27 <FromGitter> <didactic-drunk> @Blacksmoke16 `super` doesn't work. https://carc.in/#/r/bj9h

19:29 <FromGitter> <Blacksmoke16> welp