<FromGitter>
<HertzDevil> so crystal-lang/crystal#10527 currently fixes this by always choosing the first option when it should have been the second instead
<FromGitter>
<HertzDevil> fixed
andremedeiros has quit [Read error: Connection reset by peer]
andremedeiros has joined #crystal-lang
hendursaga has joined #crystal-lang
andremedeiros has quit [Read error: Connection reset by peer]
hendursa1 has quit [Ping timeout: 240 seconds]
andremedeiros has joined #crystal-lang
andremedeiros has quit [Read error: Connection reset by peer]
andremedeiros has joined #crystal-lang
andremedeiros has quit [Read error: Connection reset by peer]
andremedeiros has joined #crystal-lang
_ht has joined #crystal-lang
andremedeiros has quit [Read error: Connection reset by peer]
andremedeiros has joined #crystal-lang
<FromGitter>
<naqvis> @HertzDevil 👍
alexherbo2 has joined #crystal-lang
HumanG33k has quit [Quit: Leaving]
alexherbo2 has quit [Ping timeout: 265 seconds]
alexherbo2 has joined #crystal-lang
<_ht>
How can I specify the type of a splat argument? I understand that it is inferred to be a tuple, but I would like to specify that each and every element in the splat is of type Path. Is that possible?
<_ht>
Would Tuple(Path) work, or is that only for a singleton tuple?
<FromGitter>
<oprypin:matrix.org> im just realizing, it probably needs to generate one method body per each combination of splat args
<jhass>
well, yeah
<FromGitter>
<oprypin:matrix.org> splat could've actually been an array-like structure
<jhass>
not sure I follow
<FromGitter>
<oprypin:matrix.org> crystal could've been made with whatever changes are necessary to not need to generate a method body per splat combination
<FromGitter>
<oprypin:matrix.org> in the end people are still free to use an actual Array
<jhass>
would probably also mean less chance for LLVM to optimize though
<jhass>
also not sure if there aren't any implications re. heap vs stack allocation there
<FromGitter>
<oprypin:matrix.org> that's what i was gonna say - there's no way to get both things at the same time, even though it would be possible to implement in the language (i think). the things being (1) it's still on the stack and (2) method bodies are not duplicated
<FromGitter>
<oprypin:matrix.org> C puts the `...` stuff on the stack, right?
<jhass>
variadic args are their own rabbit hole. Depends entirely on the types, sizes and numbers of arguments and the ABI
_whitelogger has joined #crystal-lang
<FromGitter>
<asterite> The reason we went with tuple is that you can forward arguments from one method to another and the types and preserved. But maybe it's not the best thing ever.
<FromGitter>
<Blacksmoke16> usecase being, say i wanted to add a `"baz"` key if one wasnt provided, but not override it if it was provided
<FromGitter>
<Blacksmoke16> best thing i can think of is have a `Hash` `.new` overload and just not use that
<FromGitter>
<naqvis> why `Hash`?
<FromGitter>
<Blacksmoke16> why not `Hash`?
<FromGitter>
<naqvis> as long as your custom type has argless cons and `[]=` method, that can be used as hash like type literal
<FromGitter>
<Blacksmoke16> right, but the problem is the logic that would check/add default key/values would be invoked before there are actually any values in the hash.
<FromGitter>
<naqvis> not sure I follow
<jhass>
you could let [] do the fallback
<FromGitter>
<Blacksmoke16> so `HashLike.new({"foo" => "bar"})` would work and not be that much diff than `HashLike{"foo" => "bar"}`
<FromGitter>
<Daniel-Worrall> I'm not following your end goal
<FromGitter>
<naqvis> either provide default in con or do a check in `[]=` method call
<FromGitter>
<Blacksmoke16> hmm, yea nvm ill have to revisit this to figure out why i thought that wouldnt work
<FromGitter>
<Blacksmoke16> thanks
postmodern has joined #crystal-lang
<FromGitter>
<naqvis> 👍
HumanG33k has joined #crystal-lang
<FromGitter>
<oprypin:matrix.org> @Blacksmoke16: that sounds like it's surprising even if it was possible
HumanG33k has quit [*.net *.split]
Nekka has quit [*.net *.split]
markmarkmark has quit [*.net *.split]
jhass has quit [*.net *.split]
HumanG33k has joined #crystal-lang
Nekka has joined #crystal-lang
markmarkmark has joined #crystal-lang
jhass has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 260 seconds]
alexherbo2 has joined #crystal-lang
<FromGitter>
<alexherbo2> are crystal releases on githubstatic?
<FromGitter>
<alexherbo2> on my machine I have to run `crystal` and `shards` with `nix-shell --command nu --packages pcre libevent libyaml`
alexherbo2 has quit [Remote host closed the connection]
<FromGitter>
<asterite> They are not static
<straight-shoota>
what does static mean in this context? =)
<FromGitter>
<Blacksmoke16> > hmm, yea nvm ill have to revisit this to figure out why i thought that wouldnt work ⏎ ⏎ I guess what i was thinking is there any benefit of calling some method *after* they've all been loaded, e.g. like `after_initialize`
<FromGitter>
<Blacksmoke16> as i realized the problem comes from having another hash inside the wrapper to keep track of some specific state that gets initialized depending on what other values are in the hash
<FromGitter>
<Blacksmoke16> since its empty to start, calling `.new` runs the logic but returns the wrong default given not all other values are present
<jhass>
"TIL side-effects in constructors are a bad idea" >.>
<FromGitter>
<Blacksmoke16> i mean isnt that the point of a constructor? Create a new instance applying any defaults?
<FromGitter>
<Blacksmoke16> just the way hash-like syntax works kinda breaks that
<jhass>
Your default is part of the contract of any accessor method to the value, not the objects constructor. That it might be convenient to implement in the constructor instead is a mere implementation detail -> side effect
<FromGitter>
<Blacksmoke16> for context the type is wrapping a `HTTP::Headers` instance, defining default/required headers if not supplied
<FromGitter>
<Blacksmoke16> which i setup that logic in the constructor since normally you'd pass your headers to it and everything works fine
<FromGitter>
<ryanstout> ^ a simplified example, I'm trying to process an image in parallel scanlines
<FromGitter>
<ryanstout> at the end, line 40 blocks forever
<FromGitter>
<ryanstout> I tried things with channel.close also instead of sending nil's, but it never gets to that part anyway
<FromGitter>
<oprypin:matrix.org> @ryanstout: uhh `available_lines.receive` is done only `1000.times`, but there are more sends than that possibly?
<FromGitter>
<ryanstout> there shouldn't be. In my actual code, I'm allocating a working buffer of X scanlines where X is the number of fibers. I pull a scanline from disk and put it into the available_line.. etc..
<FromGitter>
<ryanstout> the idea is it takes an available_line, fills it, then sends it to the pool of fibers to process it, then they put that line number back into available_lines
<FromGitter>
<ryanstout> (back and forth producer/consumer)
<FromGitter>
<ryanstout> whats weird is with an unbuffered channel, shouldn't send never block?
ua has joined #crystal-lang
<FromGitter>
<oprypin:matrix.org> @ryanstout: i think you misunderstand what "unbuffered" means
<FromGitter>
<oprypin:matrix.org> quite the contrary, `send` *always* blocks. unless there's already a `receive` that happens to be waiting already
<FromGitter>
<ryanstout> ok, interesting. I was assuming this was similar to Ruby's Queue
<FromGitter>
<ryanstout> or I thought how go's channels worked
<FromGitter>
<ryanstout> though its been a while
<FromGitter>
<ryanstout> guess I'll switch to buffered, thanks
_ht has quit [Remote host closed the connection]
<FromGitter>
<ryanstout> just curious, what is the state of -Dpreview_mt currently?
<FromGitter>
<Blacksmoke16> still experimental, afaik havent been much progress in that rea
<FromGitter>
<Blacksmoke16> area
<FromGitter>
<erdnaxeli:cervoi.se> that's really nice but… shouldn't this have been done *before* 1.0 ? :D
<FromGitter>
<oprypin:matrix.org> whats the difference
<FromGitter>
<erdnaxeli:cervoi.se> well, now you are looking for real world code to not break too much, while before 1.0 it was ok to break. ⏎ Just add Nil as a return type will probably break someone's code…
<FromGitter>
<oprypin:matrix.org> erdnaxeli (https://matrix.to/#/@erdnaxeli:cervoi.se): thats why my PRs dont do that
<FromGitter>
<erdnaxeli:cervoi.se> I misunderstood something then
<FromGitter>
<erdnaxeli:cervoi.se> the part you say you might miss the fact that you are changing the actual type? ^^
<FromGitter>
<erdnaxeli:cervoi.se> ok this will not "probably" breaks, but it could
<FromGitter>
<oprypin:matrix.org> i'd miss it if my approach was different. but this approach should be fine
<FromGitter>
<oprypin:matrix.org> it's not 100% safe,yes
<FromGitter>
<erdnaxeli:cervoi.se> should or is? The fact that you need real usages of the code means that if there is one usage that you miss, it will potentially break, right?
<FromGitter>
<erdnaxeli:cervoi.se> yes
<FromGitter>
<erdnaxeli:cervoi.se> that's why I think it should have been done before 1.0
<FromGitter>
<erdnaxeli:cervoi.se> but still, I'm in favor of it
<FromGitter>
<oprypin:matrix.org> well a lot of things shouldve been
<FromGitter>
<erdnaxeli:cervoi.se> probably
hendursaga has quit [Quit: hendursaga]
entel has quit [Quit: Connection closed for inactivity]