<FromGitter>
<sam0x17> any way I can break early from a `.each` ?
<FromGitter>
<sam0x17> (in a captured block)
<FromGitter>
<sam0x17> `Error: can't return from captured block, use next` :(
<FromGitter>
<sam0x17> figured out my problem -- this guy defined `.each` for this collection via a captured block ... just had to access it in a different way not using his `.each` and it worked
Groogy has quit [Quit: WeeChat 2.5]
gangstacat has joined #crystal-lang
ht_ has quit [Quit: ht_]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Remote host closed the connection]
return0e_ has joined #crystal-lang
return0e has quit [Ping timeout: 246 seconds]
DTZUZO has quit [Ping timeout: 245 seconds]
Raimondi has quit [Read error: Connection reset by peer]
Raimondi has joined #crystal-lang
<FromGitter>
<asterite> @didactic-drunk I can't see how having a buffer from C, `buffer = [....]`, you'll make it so that you'll put some bytes before that buffer and then cast the whole thing to a Crystal String. You can try to make it work but I think it's impossible
beepdog has quit [Remote host closed the connection]
olbat[m] has quit [Read error: Connection reset by peer]
beepdog has joined #crystal-lang
<FromGitter>
<absolutejam_gitlab> n
olbat[m] has joined #crystal-lang
DTZUZO has joined #crystal-lang
chachasmooth_ has joined #crystal-lang
chachasmooth has quit [Ping timeout: 276 seconds]
HumanG33k has joined #crystal-lang
Human_G33k has quit [Read error: Connection reset by peer]
<FromGitter>
<yxhuvud> oh, multithreading was just merged.
<FromGitter>
<asterite> I'm guessing the blog post will appear when 0.31.0 is released
<FromGitter>
<Blacksmoke16> we shall see
<FromGitter>
<bajro17> @yxhuvud Amazing <3
return0e has joined #crystal-lang
return0e_ has quit [Ping timeout: 246 seconds]
ht_ has joined #crystal-lang
chachasmooth_ has quit [Read error: Connection reset by peer]
chachasmooth has joined #crystal-lang
chachasmooth has quit [Read error: Connection reset by peer]
chachasmooth has joined #crystal-lang
<FromGitter>
<Qu4tro> Hey 👋 . What's the best lightweight router around here? I'm not sure of the status of `router.cr` or `crouter`, which seems they may un-maintained (especially crouter).
<FromGitter>
<waghanza> of course if using `spider-gazelle` no need to add `router.cr` as a dependency (as it is already the case)
<FromGitter>
<Qu4tro> Amazing. Thanks! I'll create the issue. ⏎ Can you explain or point to somewhere where it explains the issue I was having. Would like to understand why it's failing.
<FromGitter>
<Qu4tro> Ah thanks! My google-fo seems to have failed me.
dretnx has quit [Ping timeout: 245 seconds]
return0e_ has joined #crystal-lang
return0e has quit [Ping timeout: 264 seconds]
sagax has joined #crystal-lang
<FromGitter>
<shinzlet> I'm trying to overload `self.new` on a class, and it's only working when the constructor doesn't take an argument. Anyone know what's going on? I think that the `self.new` method made by the class might be shadowing only the one in the second example for some reason. ⏎ ⏎ Sample one (works) ⏎ ⏎ ``` code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5d6d50e00d4b1f5d88a2ca96]
<FromGitter>
<Blacksmoke16> what happens if you move `self.new` below the initialize method
<FromGitter>
<Blacksmoke16> they're the same so its prob using the last defined overload
<FromGitter>
<shinzlet> I'll give that a try
<FromGitter>
<shinzlet> Hey that worked! Thanks a ton
<FromGitter>
<Blacksmoke16> np
<FromGitter>
<shinzlet> is there any way to make crystal just perform macro subs and code gen without compiling it?
<FromGitter>
<shinzlet> So that I could debug something like that a little easier haha
<FromGitter>
<Blacksmoke16> hm?
<FromGitter>
<shinzlet> Self.new is automatically defined as a class method on all classes, according to the docs, so I'm guessing there's a preprocessing step where it actually puts that method into the class body before compilation
<FromGitter>
<shinzlet> It is absolutely possible I don't know what I'm talking about here, but that's the hunch I had :p
<FromGitter>
<ezrast_gitlab> There is `crystal tool expand` for seeing macro results, but implicit `.new` methods aren't a macro so not related.
<FromGitter>
<shinzlet> I just found that in my own digging! and yup, unfortunately not helpful in this specific case
<FromGitter>
<shinzlet> I don't think there's any way to see generated code currently from my searching these last ten minutes
<FromGitter>
<shinzlet> Anyhow, thank you @ezrast_gitlab and @Blacksmoke16 ! Got it working now.
<FromGitter>
<ezrast_gitlab> Aside from reordering, you can also avoid the method signature collision by doing this: https://carc.in/#/r/7h39
<FromGitter>
<shinzlet> Clever! I was thinking about using named arguments, but in my case I would only ever need the overloaded new method
<FromGitter>
<asterite> each `initialize` will add a matching `self.new` at the end of the first pass
<FromGitter>
<shinzlet> Good to know!
olbat has joined #crystal-lang
dannyAAM has quit [Quit: znc.saru.moe : ZNC 1.6.2 - http://znc.in]
<FromGitter>
<watzon> @Blacksmoke16 you can have named arguments in an annotation right?
<FromGitter>
<Blacksmoke16> Yes
<FromGitter>
<Blacksmoke16> And positional
<FromGitter>
<watzon> How do you access named params? I tried doing it like you would with a named tuple and it didn't work? Do I need to do it more like a hash?
<FromGitter>
<Blacksmoke16> Got some example code?
<FromGitter>
<watzon> There are going to be multiple serializers?
<FromGitter>
<Blacksmoke16> at least YAML, but should be easy to support other formats
<FromGitter>
<watzon> Then I like the last option personally
<FromGitter>
<watzon> With the helper method as well
<FromGitter>
<Blacksmoke16> is it a common use case to have application specific formats? im thinking no
<FromGitter>
<Blacksmoke16> if so the first would be easiest to expand as you could just define a module that implements that method, vs having to PR the lib
<FromGitter>
<Blacksmoke16> but yea, i tend to like the last one as well, could enum the formats, and provide some method to get the module used in the first based on the type
<FromGitter>
<Blacksmoke16> the idea is `Object` (or some module you can include) defines the `#serialize` method
<FromGitter>
<Blacksmoke16> uses the enum type to get the correct converter?, then passes an array of structs to the converter's serialize method, which is responsible for turning that array of metadata into the output string
<FromGitter>
<Blacksmoke16> also assuming that the main `#serialize` method handles setting the properties to ignore, their serialized name, etc so thats all format agnostic
<FromGitter>
<Blacksmoke16> im not missing anything obvious am i?