ChanServ changed the topic of #crystal-lang to: The Crystal programming language | https://crystal-lang.org | Crystal 0.35.0 | Fund Crystal's development: https://crystal-lang.org/sponsors/ | GH: https://github.com/crystal-lang/crystal | Docs: https://crystal-lang.org/docs/ | Gitter: https://gitter.im/crystal-lang/crystal
<FromGitter> <ImAHopelessDev_gitlab> hmmm
deavmi_ has quit [Ping timeout: 246 seconds]
deavmi has joined #crystal-lang
coderobe has joined #crystal-lang
<FromGitter> <j8r> It is a known issue
<FromGitter> <j8r> StaticArrays are slow to compile
<FromGitter> <j8r> That's LLVM related
<FromGitter> <jwaldrip> Is there any reasons to access the HTTP response once its been upgraded to a websocket?
<FromGitter> <jwaldrip> Did something change with websockets in 0.35.0?
<FromGitter> <Blacksmoke16> some stuff it looks like it
<FromGitter> <jwaldrip> Hmm
<FromGitter> <jwaldrip> I am not able to test a websocket using IO::Memory anymore
<FromGitter> <jwaldrip> ``
<FromGitter> <jwaldrip> If I create a test with that, send a message to the socket and close it then I could usually assert the response
zorp has quit [Ping timeout: 265 seconds]
<FromGitter> <jwaldrip> Well, I dont know if that matters
<FromGitter> <jwaldrip> its the same IO
<FromGitter> <jwaldrip> thus rewinding the response should give me the data from `ws.send`
<FromGitter> <jwaldrip> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee6e96929d8bc28f9f87dfc]
<FromGitter> <jwaldrip> thats the error now
<FromGitter> <Daniel-Worrall> What does the core team use to communicate, and is it public?
<FromGitter> <Blacksmoke16> :shrug: to both questions :P
_whitelogger has joined #crystal-lang
gangstacat has joined #crystal-lang
<FromGitter> <watzon> That would be a good question for @asterite I think
<FromGitter> <watzon> But whyyyyyy ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee706707a7f8d2d6336b41f]
<FromGitter> <watzon> There is definitely a valid conversion path here
_ht has joined #crystal-lang
<FromGitter> <naqvis> seems too many different value types your code is generating
<FromGitter> <naqvis> also iirc usage of Symbols as key in Hash is not recommended
<FromGitter> <naqvis> recommended one is String
<FromGitter> <watzon> True, this isn't my library though. Pretty sure things were working fine before 0.35.0.
<FromGitter> <watzon> Hmm, apparently `**T` isn't a valid syntax for generics
<FromGitter> <naqvis> hmmm? isn't `NamedTuple` itself defined as generic?
_whitelogger has joined #crystal-lang
<FromGitter> <watzon> Yep, but apparently that part is implemented in the compiler
<FromGitter> <watzon> The generic syntax it uses, `**T`, is actually invalid for normal code
<FromGitter> <naqvis> hey Girng
<FromGitter> <naqvis> :D
<FromGitter> <ImAHopelessDev_gitlab> hi @naqvis
<FromGitter> <ImAHopelessDev_gitlab> i'm still on `0.31.1` of crystal
<FromGitter> <ImAHopelessDev_gitlab> lol it's been a while...
alexherbo2 has joined #crystal-lang
<FromGitter> <naqvis> yeah, quite a while
<FromGitter> <naqvis> any specific reason of sticking to 0.31.1?
<FromGitter> <naqvis> or just because of `if it ain't broken, don't fix it` :P
<FromGitter> <ImAHopelessDev_gitlab> yeah
<FromGitter> <naqvis> make sense
<FromGitter> <ImAHopelessDev_gitlab> once i get new computer, i'll install WSL2 and then upgrade then but right now, it's meh
<FromGitter> <Daniel-Worrall> idk, I actually prefered WSL1 to its current state
<FromGitter> <Daniel-Worrall> it still has its quirks
<FromGitter> <ImAHopelessDev_gitlab> oh really
<FromGitter> <ImAHopelessDev_gitlab> well maybe i'll stick to the current wsl then
<FromGitter> <ImAHopelessDev_gitlab> WSL and Crystal have been good to me, i don't want to break anything
alexherbo2 has quit [Quit: The Lounge - https://thelounge.chat]
rocx1 has joined #crystal-lang
rocx has quit [Ping timeout: 260 seconds]
rocx1 is now known as rocx
rocx has quit [Remote host closed the connection]
rocx has joined #crystal-lang
repo has quit [Ping timeout: 260 seconds]
Xeago_ has joined #crystal-lang
Xeago has quit [Read error: Connection reset by peer]
Xeago_ is now known as Xeago
repo has joined #crystal-lang
repo has quit [Client Quit]
chachasmooth_ has quit [Quit: Quit]
chachasmooth has joined #crystal-lang
repo has joined #crystal-lang
<FromGitter> <jwaldrip> Confirmed there is definately an issue with websockets. See my issue: https://github.com/crystal-lang/crystal/issues/9484
<FromGitter> <wontruefree> I just released our new podcast where I interview @bcardiff enjoy and subscribe http://podcast.chicagocrystal.org/1030945/4180763-brian-cardiff-the-cores-of-crystal
sorcus has quit [Quit: WeeChat 2.8]
sorcus has joined #crystal-lang
repo has quit [Quit: WeeChat 2.8]
repo has joined #crystal-lang
HumanGeek has quit [Remote host closed the connection]
HumanGeek has joined #crystal-lang
<FromGitter> <ArtLinkov> Hey Jack, long time no see :)
<FromGitter> <ArtLinkov> Has anyone else had this problem with `Kemal` ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee786c149260560aa60f5f3]
<FromGitter> <ArtLinkov> I'm guessing it's due to last update
<FromGitter> <naqvis> @ArtLinkov 0.35.0 has changed the namespace for compression modules. they are under `Compress` now. https://github.com/crystal-lang/crystal/blob/master/CHANGELOG.md#files
<FromGitter> <ArtLinkov> I figured it's something like that
<FromGitter> <ArtLinkov> Thanks @naqvis
<FromGitter> <ArtLinkov> Anyone know when a patch is due in Kemal?
<FromGitter> <Blacksmoke16> can set the commit for now
<FromGitter> <Blacksmoke16> essentially the same thing
<FromGitter> <aravindavk> I think patch merged in Kemal master, but no release yet
<FromGitter> <Blacksmoke16> right, can just do `commit: commit_hash_in_master` until a new release is created
<FromGitter> <Blacksmoke16> safer than `branch: master`
<FromGitter> <ArtLinkov> Good idea, thanks :)
ht_ has joined #crystal-lang
_ht has quit [Ping timeout: 258 seconds]
ht_ is now known as _ht
zorp has joined #crystal-lang
<FromGitter> <wontruefree> hey @ArtLinkov it has been a while :)
<FromGitter> <watzon> @Blacksmoke16 any idea if this would be possible? I want to make an arg parser, using macros, that takes a named tuple and attempts to parse a string into that named tuple, where the named tuple is something like `{value: Booll, other: String}`
<FromGitter> <Blacksmoke16> got an example?
<FromGitter> <watzon> I'm just trying to figure out if there's a way to build a named tuple like that using macros
<FromGitter> <watzon> An example string to parse?
<FromGitter> <Blacksmoke16> you can deff make a named tuple in a macro
<FromGitter> <Blacksmoke16> `{% {value: value, other: string} %}`
<FromGitter> <Blacksmoke16> if the keys are dynamic however you would have to use a hash
<FromGitter> <watzon> That's the problem I'm dealing with. I know exactly the arguments I want and their types at compile time, so I'm trying to figure out how to use that to my advantage to output a NamedTuple rather than a Hash, since with a hash I'd end up with something like `Hash(String, String | Int32 | Bool)` and then I have to do runtime type conversion.
<FromGitter> <watzon> Maybe it would be possible to build a macro HashLiteral and then use that to create a NamedTuple?
<FromGitter> <watzon> I doubt it, but maybe?
<FromGitter> <Blacksmoke16> im assuming you want like `some_macro "some_string" # => NamedTuple(..)`?
<FromGitter> <watzon> More like ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee79fb529d8bc28f9fa41c2]
<FromGitter> <Blacksmoke16> `.parse` is the macro?
<FromGitter> <Blacksmoke16> you could do something like
<FromGitter> <watzon> Well I was hoping I could rely on macro expressions inside of a normal method rather than an actual macro, since with a macro the string being parsed would have to be known at compile time.
<FromGitter> <watzon> Wait, when did this become a thing? https://crystal-lang.org/api/0.35.0/NamedTuple.html#from(hash:Hash):self-class-method
<FromGitter> <watzon> Has it always been there?
<FromGitter> <Blacksmoke16> yes
<FromGitter> <Blacksmoke16> similar to `Tuple.from(arr : Array)`
<FromGitter> <watzon> Hmm, well that could work
<FromGitter> <Blacksmoke16> > Well I was hoping I could rely on macro expressions inside of a normal method rather than an actual macro, since with a macro the string being parsed would have to be known at compile time. ⏎ ⏎ right and what was your plan to get the runtime value to parse in the macro?
<FromGitter> <Blacksmoke16> or you just want to build the parsing logic with a macro based on the named tuple type as the "blueprint"?
<FromGitter> <watzon> Yeah that was the idea
<FromGitter> <Blacksmoke16> gotcha
<FromGitter> <watzon> This is more or less what I wanted https://carc.in/#/r/99u7
<FromGitter> <watzon> Awesome
<FromGitter> <Blacksmoke16> 👍
<FromGitter> <watzon> Now the question becomes, how to handle nilable arguments that aren't included https://carc.in/#/r/99u9
<FromGitter> <Blacksmoke16> i use the tuple version for athena, works quite well
<FromGitter> <Blacksmoke16> would need to populate the hash with default values
<FromGitter> <Blacksmoke16> like maybe check if the value is nilable and use `nil`, otherwise raise an error?
<FromGitter> <watzon> Ahh yeah, good idea
<FromGitter> <jwaldrip> Any plans for a require hook?
<FromGitter> <jwaldrip> ```macro required ⏎ # ... ⏎ end``` [https://gitter.im/crystal-lang/crystal?at=5ee7a6ae30401c1f245a9741]
<FromGitter> <Blacksmoke16> what would be the use case?
<FromGitter> <jwaldrip> Run something when the file is initially required
<FromGitter> <Blacksmoke16> wouldnt it just be the same as putting code in the top level
<FromGitter> <jwaldrip> heres the example
<FromGitter> <jwaldrip> ```require "orion" ⏎ include Orion::DSL ⏎ get "/hello" do ⏎ "Hello World" ⏎ end``` [https://gitter.im/crystal-lang/crystal?at=5ee7a6d77b6da9126a9807dc]
<FromGitter> <jwaldrip> the include of Orion::DSL runs some `macro included` code to get some things set up
dostoyevsky has quit [Quit: leaving]
dostoyevsky has joined #crystal-lang
<FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee7a7135dcbb760b6ef7c56]
<FromGitter> <Blacksmoke16> does that not work?
<FromGitter> <jwaldrip> Nope
<FromGitter> <jwaldrip> I get an error saying that I tried to invoke a private macro of `included`
<FromGitter> <Blacksmoke16> add it at the end of the file
<FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee7a76c013105125a383e43]
<FromGitter> <jwaldrip> I will give that a try
<FromGitter> <Blacksmoke16> afaik require just includes the code of that file where you require it, so i would think that should be equivalent...
<FromGitter> <watzon> https://carc.in/#/r/99ue
<FromGitter> <watzon> Beautiful
<FromGitter> <Blacksmoke16> 👍 nice
<FromGitter> <Blacksmoke16> i think you can also do `while token = tokens.shift`
<FromGitter> <Blacksmoke16> `.shift?`
<FromGitter> <Blacksmoke16> might be able to clean some of it up via case
<FromGitter> <watzon> Ahh yeah that's true huh
<sorcus> Hi :-)
<sorcus> https://gist.github.com/MrSorcus/e91d06a351c389432ff145b37ed12b78 - size output in another fiber/thread possible only with `-Dpreview_mt`?
<oprypin> sorcus: this is a busyloop; yes, nothing else can happen within one thread
<oprypin> if u had 4 threads with preview_mt, you'd also be able to run only 4 of these and 5th would get stuck
<oprypin> if you really want to make this work, you could add Fiber.yield into the bottom loop
<oprypin> i think sleep 0 is equivalent
<oprypin> probably add it once every 1000 iterations or so, not to kill performance too much
<oprypin> additionally, this is probably not thread safe
<oprypin> no i guess it's fine regarding the last part
<FromGitter> <naqvis> this is not thread-safe and there will be race-condition. Per my understanding IO isn't thread-safe in Crystal
<FromGitter> <naqvis> writing from main thread and reading from other threads is definitely going to cause race-condition
<FromGitter> <naqvis> `Do not communicate by sharing memory; instead, share memory by communicating.`, so `Channel` should be your best friend
<FromGitter> <ImAHopelessDev_gitlab> LOL i thougt that said "token = tokens.shit" for a second
<FromGitter> <naqvis> rofl
<oprypin> @naqvis: yes but this isn't IO :D
<FromGitter> <naqvis> damn, GFW of China is so much annoying, can’t access gist without vpn or proxy. i’m on cell, so don’t have access to vpn/proxy
<FromGitter> <naqvis> but i had this impression that above gist was using IO::Memory
<FromGitter> <naqvis> Thanks oprypin ❤️
<oprypin> @naqvis: yep. and IO::Memory doesn't do any I/O 🙃
<oprypin> @naqvis: uhh for what? :o
<FromGitter> <naqvis> agree, but I was referring to IO as the base class
<FromGitter> <naqvis> not means system IO
<FromGitter> <naqvis> thanks for correction
<oprypin> actual I/O is quite well confined to IO::FileDescriptor
<oprypin> IO base also has no relation
<FromGitter> <naqvis> yeah, but I meant to say IO base class 😄
<oprypin> me too
<FromGitter> <naqvis> I should be more specific by saying IO::Memory isnt thread safe
<FromGitter> <naqvis> well actually majority of stdlib isnt thread safe
<FromGitter> <naqvis> hope i’m not exaggerating here
<FromGitter> <bararchy> What's the best way to know if a Path is under another Path? ⏎ `Path[/foo/bar/].parent_of?(Path[/foo/bar/file.txt]) => true`
<FromGitter> <Blacksmoke16> sounds like a feature request
<sorcus> Thanks oprypin.
<sorcus> naqvis what does you mean? I shoudn't use `-Dpreview_mt` with `output.size` inside `spawn`?
_ht has quit [Quit: _ht]
narayana has left #crystal-lang ["User left"]
<FromGitter> <mattrberry> Since StaticArrays are so slow to compile (my compile times jumped 30x from adding a single 4096-long StaticArray), I moved them to a different file that I wouldn't be touching much in the hopes that Crystal would incrementally compile them. That doesn't seem to be the case though. Is there any way to tell crystal that a certain file doesn't need to be recompiled?
<FromGitter> <Blacksmoke16> dont think so
<FromGitter> <mattrberry> As of right now, it seems like my only real solution is using StaticArray to work around the supposed gc issue. Build times of 5-8 minutes are just ridiculous though
<FromGitter> <Blacksmoke16> maybe make a forum thread about it?
<jhass> not too much point, it's a well known issue
<FromGitter> <Blacksmoke16> ah, 👍
<jhass> one big hack around I could imagine is to define it in a little C file as an exported global, compile to an object file and link and bind to on the Crystal side, wrapping it into a Slice
<FromGitter> <mattrberry> I'll give that a shot. It's worth it to get these compile times down.. Thanks Jonne!
<FromGitter> <j8r> How can I handle NaN? I would like to have `0 / 0` be `0`
<FromGitter> <Blacksmoke16> https://crystal-lang.org/api/master/Float.html#nan?-instance-method ?
<FromGitter> <j8r> ha thanks
<FromGitter> <Blacksmoke16> `value = quotient.nan? ? 0 : quotient`
<FromGitter> <Blacksmoke16> 👍
<FromGitter> <j8r> yep, actually `0_f64`
<FromGitter> <j8r> but `-NaN` is a special `Float64`?
<FromGitter> <Blacksmoke16> i like how its implemented `!(self == self)` :thinking:
<FromGitter> <j8r> what is it, I mean the same approach could have been used for overflow then
<oprypin> @mattrberry: lol i wonder if putting that constant into a class would help (probably not..)
<oprypin> a class of its own i mean
<oprypin> but yea the idea by jhass would definitely work
<jhass> well, after all what crystal does for StaticArray is just define an LLVM type that big and then LLVMM chokes on that
<FromGitter> <j8r> I tried to use macros, a custom struct with a big case/when - does not improve anything
<FromGitter> <j8r> That's too bad, StaticArray is quite good
<jhass> weird thing is, just putting StaticArray(Int32, 4096).new into a file isn't slow at all
<jhass> so I wonder what kind of instructions using such a type get slow and maybe there's actually an easy way to hide the type from LLVM prior by casting it to a pointer and then back or so
<FromGitter> <j8r> you missed the `[...].new 0`
<FromGitter> <j8r> I tried `{{ "StaticArray(Int32, 4096).new 0".id }}`, didn't change the compilation time
<jhass> ?!
<oprypin> jhass: yes at this point maybe it's worth looking for a workaround
<FromGitter> <j8r> yes jhass, `StaticArray(Int32, 4096).new` does not work
<FromGitter> <j8r> `StaticArray(Int32, 4096).new 0` does ;)
<jhass> I just compiled the former?!
<jhass> or you mean doesn't reproduce?
<oprypin> i think j8r is going through macro to_s
<oprypin> which could well be broken
<FromGitter> <j8r> crystal eval 'StaticArray(Int32, 4096).new' ⏎ Showing last frame. Use --error-trace for full trace. ⏎ ⏎ error in line 1 ⏎ Error: private method 'new' called for StaticArray(T, N).class [https://gitter.im/crystal-lang/crystal?at=5ee7e197013105125a38d7ca]
<jhass> >> StaticArray(Int32, 4096).new
<DeBot> jhass: Error: private method 'new' called for StaticArray(T, N).class - https://carc.in/#/r/99w7
<jhass> huh
<oprypin> >> StaticArray(Int32, 4096).new
<DeBot> oprypin: Error: private method 'new' called for StaticArray(T, N).class - https://carc.in/#/r/99w8
<jhass> how does that work locally :D
<FromGitter> <j8r> Haha :)
<jhass> it's really broken in macros?
<oprypin> woops too slow on mobile
<jhass> super weird
<FromGitter> <j8r> you're mind connected oprypin and jhass
<jhass> ahaha, stdlib makes it private?
<jhass> with an empty prelude it compiles :D
<FromGitter> <j8r> Are you sure you are not using Crystal 0.11? (just kidding)
<oprypin> jhass: lol ok
<jhass> anyways, even with stdlib and .new(0), that's still fast
<FromGitter> <j8r> you are putting it on a file, then `read_file`?
<jhass> ?!
<oprypin> i think that's incompatible with the point jhass is makng
<FromGitter> <j8r> I don't understand?
<oprypin> why would you load the literal text [23:01:58] <ffffffoprypin> >> StaticArray(Int32, 4096).new from a file
<FromGitter> <j8r> also, it is fast on --release or without?
<FromGitter> <j8r> for me it is only slow on release mode
<FromGitter> <mattrberry> For anyone who's curious, this is how I use the StaticArray. If you change this line to ⏎ ⏎ ```@buffer = StaticArray(Float32, 4096).new 0_f32``` ⏎ ⏎ it nukes the compile time with the release flag https://github.com/mattrberry/CryBoy/blob/master/src/cryboy/apu.cr#L135 [https://gitter.im/crystal-lang/crystal?at=5ee7e2ba49260560aa61f75f]
<jhass> mmh. yeah stdlib and release makes it slow. empty prelude and release is still fast
<FromGitter> <mattrberry> It's noticeably slower even not on release, but it's not significant
<oprypin> on release there's basically no caching anyway
<oprypin> so disregard my idea from before
<oprypin> jhass: what kind of workaround could one even do? crystal has no other way of putting massive data on the stack
<oprypin> @mattrberry: do you get a big win from using static array over slice? I'd doubt it
<jhass> as a user? I'd give my object file + slice idea a shot
<jhass> but I guess that's not on the stack anymore
<FromGitter> <mattrberry> If I use slice or array instead of staticarray, the memory somehow gets corrupted when passing it to SDL
<FromGitter> <mattrberry> Consistently
<FromGitter> <mattrberry> So that's not an option
<jhass> later down above I was talking about workarounds the compiler could make
<oprypin> @mattrberry: let's try to solve that issue then!!
<oprypin> jhass: i was thinking your idea would work but it works only for a single global value
<jhass> yeah
<oprypin> for stack it doesn't help, yea
<FromGitter> <mattrberry> I'm down to keep trying! I've brought it up a number of times in this channel to no avail though :/ Spent awhile debugging with Jonne last week
<jhass> I mean maybe you could have a C function returning you one?
<jhass> but then you have type in crystal again, no that doesn't help
<oprypin> @mattrberry: oh with Jonne? ok then it's hopeless to try anymore :D
<FromGitter> <j8r> But you need a pointer somehow to use Slice?
<oprypin> jhass: Crystal needs to allocate the stack stuff for C to return into
<jhass> yeh
<jhass> I still susupect some LLVM instruction getting slow on such types
<jhass> which C just manages to avoid to generate
<oprypin> well yea that's what it is
<oprypin> does it end up generating a struct like {int1,int2,int3,...4095} or something lol
<jhass> but then if I dump IR, llvm-extract and llc -O3, it's kinda slow for a single function, but not terribly, minutes slow
<oprypin> @mattrberry: do you have a repro case (even with your whole repo) for that corruption?
<jhass> ah, maybe I extracted the wrong function, not the one being slow
<jhass> mmh, no the constructor on its own isn't slow either
<FromGitter> ... program. The behavior changes depending on whether I add a new instance variable or anything to the APU class
<FromGitter> <mattrberry> There are a number of ways in which it presents itself. Do you know how digital audio works by chance? If (the buffer)[https://github.com/mattrberry/CryBoy/blob/master/src/cryboy/apu.cr#L135] is filled with only 0's, SDL should not play any audio. Everything should be silent. However, I often (but not always) get random background noise. Other times, SDL just starts reading invalid memory and segfaults the
<FromGitter> <j8r> the slow thing seems to be `array = uninitialized self`
<FromGitter> <j8r> 30 seconds for me
<FromGitter> <j8r> but that's still reasonable
<FromGitter> <mattrberry> And I'm just giving the SDL_QueueAudio function a pointerof(@buffer), which it then should be copying into its own internal structure
<jhass> I guess there's one instruction that adds up
<FromGitter> <mattrberry> I figure it's somewhat related to how the GC is moving values around on the heap, but I have no evidence of that necessarily. All I know is that the issues seem to not be present when I use StaticArray..
<jhass> idk, llc is just significantly faster, even on the entire dumped IR
<jhass> maybe that's a workaround for ya, dump unoptimized IR and compile with llc xD
<FromGitter> <mattrberry> I'm gonna try just making them global constants in C unless you think there's a better workaround :)
<FromGitter> <j8r> I have something, try ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee7e7dd1e099b0388caddd2]
<FromGitter> <j8r> For me it is faster, it did compile in 40 seconds
<jhass> fast to compile, not fast to run xD
<FromGitter> <j8r> why?
<FromGitter> <j8r> the actual implementation is `N.times do`
<jhass> huh
<jhass> mmh, maybe LLVM tries to unroll the loop or so?
<jhass> and gets slow at that?
<FromGitter> <j8r> that loop is probably the thing yes
<oprypin> @j8r uhh `0...N` ?
<oprypin> jhass, do you actually see a loop in llvm ir?
<FromGitter> <j8r> right oprypin
<jhass> oprypin: yeah https://p.jhass.eu/8q.ll#L30-59
<oprypin> mattrberry, well ok it's a bit of a repro, but is it possible to get a repro without requiring proprietary stuff (rom)
<oprypin> huh interesting
<jhass> well, unoptimmized LLVM IR
<jhass> let's see what it makes out of it
<oprypin> oh you can do that? :)
<FromGitter> <mattrberry> > I have something, try ⏎ > ```cr ⏎ > struct StaticArray(T, N) ⏎ > def self.new_fast(& : Int32 -> T) ⏎ > array = uninitialized self ... [https://gitter.im/crystal-lang/crystal?at=5ee7e92f5782a31278ffd837]
<jhass> oprypin: yeah, just adding --release dumps the optimized IR :)
<FromGitter> <j8r> @mattrberry My bad, use using `0...N` is better
<jhass> I guess there's some additional passes during call lowering, but it gets you a long way
<oprypin> are we on a brink of a breakthrough
<FromGitter> <j8r> also `#times` is a while loop
<FromGitter> <j8r> in this case may not be properly handled
<FromGitter> <mattrberry> > *<oprypin>* @mattrberry, well ok it's a bit of a repro, but is it possible to get a repro without requiring proprietary stuff (rom) ⏎ ⏎ You could probably just initialize SDL then keep passing it slices full of 0's. I imagine that might do the same thing
<oprypin> there's probably some additional factor, it won't repro just like that
<FromGitter> <mattrberry> Ah :/ It seems to depend on the structure of my APU class, so I'm not surprised :/
<jhass> I wonder what the heck we enable for --release that llc -O3 doesn't thouggh
<FromGitter> <mattrberry> @j8r Is there a downside to using your approach? It's just slightly slower to initialize at runtime? Shouldn't matter though since I'm only doing it once?
<jhass> it generates a lot more code, so slightly bigger binary probably
<oprypin> i think you have your solution :)
<FromGitter> <mattrberry> I'll take it, that's worth the tradeoff for me :)
<FromGitter> <mattrberry> Is this worth submitting an issue on github for? At least to investigate further?
<FromGitter> <mattrberry> I don't know enough about llvm to be remotely useful here..
<FromGitter> <j8r> I tried ⏎ ⏎ ``` (0...N).each do |i| ⏎ buf[i] = yield i ⏎ end``` ⏎ ⏎ Instead of the macro, slow too - no change :( [https://gitter.im/crystal-lang/crystal?at=5ee7eacd24a3382d5d6bc155]
<jhass> we already have an issue for it somewhere
<jhass> j8r: not too surprising, it's about the same code
<jhass> on LLVM IR level
<jhass> since Crystal evaluates the yield's
<jhass> and all loops are somemthing like condition, branch here, branch there
<FromGitter> <j8r> oh ok, thanks
<FromGitter> <j8r> obviously using `block.call` instead of yield is the same
<jhass> yeah I think it gets stuck at trying to optimize the loop, for some reason
<jhass> oh wow, I got to show you guys
<FromGitter> <j8r> True, I confirm that's the loop
<FromGitter> <j8r> Using a "bare" while inside reproduce the issue
<sorcus> Good night :-)
<jhass> so the optimizer takes the loop
<jhass> and turns it into this beauty https://p.jhass.eu/8r.ll
<oprypin> 👏👏👏
<jhass> sorry, maybe https://p.jhass.eu/8r.txt is the better link xD
<FromGitter> <j8r> wow :o
<jhass> it's called loop unrolling, I guess? :D
<FromGitter> <j8r> Not sure the binary would even be bigger, with macro by seing this :)
<jhass> yeh
<oprypin> :D
<FromGitter> <mattrberry> Lmao
<jhass> I mean the macro should generate pretty much exactly the samme
<jhass> (I didn't test, you can check with --emit=llvm-ir)
<oprypin> jhass, ummm i think theres no issue opened for this staticarray stuff
<jhass> I definitely seen one
<oprypin> could be a passing mention
<jhass> could be a tangent somewhere, don't nail me
<jhass> okay for whatever reason its closed https://github.com/crystal-lang/crystal/issues/2485
<oprypin> ok reopen it then :>
<FromGitter> <j8r> Reduced issue: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee7ee1b1e099b0388caeb1d]
<FromGitter> <j8r> I can post it in the issue
<oprypin> definitely do and post the workaround too 😊
<jhass> still, llc -O3 manages to do the same unrolling much faster
<jhass> in like 5 seconds on my machine
<FromGitter> <mattrberry> All of this said, I can't wait for the next release of Crystal 😏
<oprypin> mattrberry, for what reason?
<oprypin> https://llvm.org/docs/TransformMetadata.html might be relevant for a proper solution to this
<FromGitter> <mattrberry> Hoping that this might be resolved :)
<jhass> j8r: can't harm to document findings :)
<FromGitter> <j8r> Sure
<FromGitter> <j8r> I was not sure if it was the correct place
<FromGitter> <j8r> Because closed
<FromGitter> <mattrberry> You could always create a new issue and link to the old one. Might be a more effective way to "bump" it
<jhass> I think I'll reopen it indeed
<jhass> there's one more thing I want to try
<FromGitter> <j8r> I think we may have a `new!` as a work-around, if the fix is not easy
<FromGitter> <j8r> or change the existing `new`
<jhass> I see no reason to not workaround in the existing new
<jhass> it's functionally the same, probably not even really different tradeoffs
<FromGitter> <j8r> you're right yes
<jhass> just if we can fix it at compiler level, it might turn out to be generally better
<jhass> and fixing at compiler level could be figuring out whatever the diff between crystal build --release and llc -O3
<jhass> my first guess doesn't seem to be it :/
<FromGitter> <mattrberry> And fixing at the compiler level could also potentially fix other sticking points in the compiler that we just don't know about yet!
<FromGitter> <mattrberry> Rather than a super localized patch
<jhass> yeah that's what I meant
<FromGitter> <j8r> sure
<FromGitter> <j8r> Maybe we should rename or open a new issue
<FromGitter> <j8r> I can open a PR to fix slow compile times for StaticArray, then the remaining root issue will be the reduced sample
<FromGitter> <j8r> the one I posted, which is slow to compile
<FromGitter> <j8r> of course a code comment will mention this issue, to explain why a macro is used
<FromGitter> <watzon> Waiting for the bus and I just got asked if I have any Crystal
<FromGitter> <watzon> Why yes, yes I do
<FromGitter> <Blacksmoke16> *no, but i have some rust*
<FromGitter> <j8r> In your "GitHub" haha :D
<FromGitter> <Blacksmoke16> *elixir*
<FromGitter> <j8r> Ask a Police man if he has some Crystal in his GitHub :P
Human_G33k has joined #crystal-lang
<FromGitter> <j8r> When thinking more about it, for those who doesn't know what Git is, a a Hub of Gits can seem weird
<FromGitter> <Blacksmoke16> *a hub of gits is essentially a bunch of bits*
<FromGitter> <watzon> Could be worth asking Andrew from Zig-lang if Zig has a similar issue with loop unrolling. If not he may have a solution.
<FromGitter> <Blacksmoke16> *they zigged instead of zagged*
<FromGitter> <Blacksmoke16> ok im done
<jhass> gosh, I hope that's any understandable
HumanGeek has quit [Ping timeout: 256 seconds]
<FromGitter> <ImAHopelessDev_gitlab> hi
<FromGitter> <watzon> Oh look who it is
<FromGitter> <watzon> Hey bud
<FromGitter> <ImAHopelessDev_gitlab> hi @watzon how u been
<FromGitter> <watzon> Not too shabby
<FromGitter> <j8r> the Gir called Ng
<FromGitter> <watzon> Lolll
<FromGitter> <j8r> alternatively, Gir is also a village in Iran - Ng from Gir
<FromGitter> <j8r> anyway, nice to see you
<FromGitter> <Blacksmoke16> *ng-repeat*
<jhass> gir is the file extension used for gobject introspection metadata files. I think the r there is repository :D
<FromGitter> <ImAHopelessDev_gitlab> funny thing is, "girng" came to be from when i rage quit on the godot repo a long time ago from my old account, and wanted to make a new one. so when i registered, i just slammed my hands on the keyboard really quick and "girng" showed up. ⏎ ⏎ I do like IAmAHopelessDev though, which is from opryprin
<FromGitter> <j8r> lol haha
<FromGitter> <j8r> from rage came a name
<oprypin> https://freenode.irclog.whitequark.org/crystal-lang/2019-01-17#23894617; pretty sure it was addressed at Blacksmoke16 (uncalled for and untrue either way; sorry)
<FromGitter> <Blacksmoke16> hm?
<FromGitter> <ImAHopelessDev_gitlab> wtf they got logs
<jhass> nothing is ever forgotten :P
hightower3 has joined #crystal-lang
<hightower3> Hey folks, is it true that method overloads don't distinguish a case where just the block restriction is different? Like, this example https://play.crystal-lang.org/#/r/99wh should print "int11", but it prints "string11" because the second definition overwrites the first one.
<hightower3> And if that assessment is true, is there any workaround?
<FromGitter> <Blacksmoke16> well you're not typing the argument you're passing
<FromGitter> <Blacksmoke16> nor yielding
<FromGitter> <Blacksmoke16> https://play.crystal-lang.org/#/r/99wx
<hightower3> Maybe my play example was bad, let me try to improve it
<hightower3> Check this one out: https://play.crystal-lang.org/#/r/99xq
<hightower3> This example seems to show that the second def overwrote the first one, and then complains about the type. If the order of the defs is changed (so that int version is second), then that example works without an error.
<FromGitter> <Blacksmoke16> i think thats accurate, cant say i recall an issue/seeing anything about it tho
<hightower3> Is this because the block signature is just a type restriction, and not the real thing used in deciding the overloads?
<FromGitter> <Blacksmoke16> im not sure
<hightower3> I'm reluctant to submit a new issue as most probably I'll receive the answer "yes it's a type restriction which is not used in overloads"... although I could use an idea how to work around it (other than using different method or argument names, which pretty much limits the choices :-)
<FromGitter> <watzon> Ok this is the second time I've seen something like this ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5ee80a2e30401c1f245b9d37]
<FromGitter> <ImAHopelessDev_gitlab> is bytes_written becoming nil somehow ?
<FromGitter> <Blacksmoke16> @watzon it's being reverted in `0.35.1`
<FromGitter> <watzon> Is that patch coming soon? Seems like this broke a bunch of shit haha.
<FromGitter> <Blacksmoke16> :shrug:
<FromGitter> <ImAHopelessDev_gitlab> reason #12123 why i'm on `Crystal 0.31.1 [0e2e1d067] (2019-09-30)`
<FromGitter> <ImAHopelessDev_gitlab> 😂😂