<FromGitter>
<watzon> Yeah it's unfortunate that open source doesn't really pay the bills
<FromGitter>
<Blacksmoke16> if your project gets popular enough it possibly could
<FromGitter>
<watzon> Yeah, but that's hard in a lesser known language like Crystal
<FromGitter>
<Blacksmoke16> true, depends what you mean
<FromGitter>
<Blacksmoke16> make*
<FromGitter>
<Blacksmoke16> kinda is what influenced my Athena design change. (not that im expecting any income from any of this) but rather than banking on coming up with the next Rails, focus on creating smaller reusable components that *other* projects could take advantage of
<FromGitter>
<bajro17> I working right now on regex router
<FromGitter>
<Blacksmoke16> then you could build a framework out of those, or other projects could take advantage of them in their frameworks; which, in the end, only benefits the ecosystem
<FromGitter>
<bajro17> I want see how it compare with radix
<FromGitter>
<bajro17> maybe we can be even faster with regex instead use radix tree
<FromGitter>
<Blacksmoke16> id be surprised if its faster, regex is kinda slow vs straight string parsing no?
<FromGitter>
<bajro17> it bothers me how can be syro faster then routercr
return0e has quit [Read error: Connection reset by peer]
return0e has joined #crystal-lang
<hightower3>
Let's say I have a struct with 6 Int16s, and I need to read them from an IO. Now, since I don't want these 6 variables to be nillable and assigned them one by one. Is there a way I can somehow do 6 times io.read_bytes(Int16, little_endian) and store these 6 vars at once?
<FromGitter>
<Blacksmoke16> what id do is define an initializer that accepts the IO
<nowhereFast>
Is there a way to close sockets opened with `HTTP::Client.get` sooner/quicker?
<nowhereFast>
I'm kicking some background work off and keep hitting `failed to create socket:: No file descriptors available` errors
<nowhereFast>
guessing that these connections are not disposed of quick enough?
nowhereFast has quit [Ping timeout: 240 seconds]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #crystal-lang
return0e_ has joined #crystal-lang
return0e has quit [Ping timeout: 240 seconds]
ht_ has joined #crystal-lang
return0e has joined #crystal-lang
return0e_ has quit [Ping timeout: 276 seconds]
ht_ has quit [Remote host closed the connection]
return0e has quit [Read error: Connection reset by peer]
return0e_ has joined #crystal-lang
<hightower3>
nowhereFast seems like you're creating connections anew while the old ones are using keep-alive and are still active
yukai has quit [Ping timeout: 240 seconds]
return0__ has joined #crystal-lang
return0e_ has quit [Read error: Connection reset by peer]
return0__ has quit [Read error: Connection reset by peer]
return0e has joined #crystal-lang
alexherbo2 has joined #crystal-lang
<FromGitter>
<ImAHopelessDev_gitlab> proper variable naming is SOOO important!!
<FromGitter>
<ImAHopelessDev_gitlab> Good variable naming helps me so much, wow!
<FromGitter>
<ImAHopelessDev_gitlab> @vladfaust welcome back
<FromGitter>
<ImAHopelessDev_gitlab> I think a problem is coming up with an actual good name for the property in the first place. Once you got that, it's like a golden ticket
<Yxhuvud>
Hmm. All the examples in that PR use a common superclass for the different choices. If that is necessary then that may be a bit limiting for how useful it is in practice.
<FromGitter>
<Blacksmoke16> thats the main usecase
<FromGitter>
<Daniel-Worrall> ooh!
<FromGitter>
<straight-shoota> Yxhuvud, that's an interesting point
<FromGitter>
<straight-shoota> But the implementation should really work without an inheritance relationship between the individual types
<FromGitter>
<straight-shoota> You just need *a* type to define the discriminator method on, the mapping types don't need to be related
<Yxhuvud>
Hmm, ok. That sounds rather useful. Especially as it seems you can define different discriminators for different contexts. (just because I want to be able to deserialize one way in one context doesn't mean it is ok to accept the same input in another).
<FromGitter>
<straight-shoota> Yeah, the only restriction currently is that you need a separate type for each context
<FromGitter>
<straight-shoota> This restriction shouldn't be strictly necessary, though.
<FromGitter>
<straight-shoota> Actually, I bet this should really be able to work completely in runtime without any macro
<Yxhuvud>
Being able to do `class Decoder; include JSON::Serializable; use_discriminator("type", {klass1: Klass1, klass2: Klass2 }); end` seems really nice to me, anyhow, if it works.
<Yxhuvud>
It could work runtime, but you would probably lose performance by relying on hash lookups, which I think you would end up being dependent on.
<FromGitter>
<nsuchy> is there a way to convert a String to an Integer
<FromGitter>
<nsuchy> E.g. "12345" becomes 12345
<Yxhuvud>
nsuchy: try "1234".to_i
<FromGitter>
<nsuchy> thanks
<FromGitter>
<straight-shoota> > *<Yxhuvud>* It could work runtime, but you would probably lose performance by relying on hash lookups, which I think you would end up being dependent on. ⏎ ⏎ Well, technically you could just iterate through the hash entries and compare them directly. That should be faster when it's only a few. This might still be a little bit slower than the macro approach, but that's hardly noticeable. It still
<FromGitter>
... needs to compare strings at runtime.
<Yxhuvud>
truue
<FromGitter>
<straight-shoota> Or just use a NamedTuple
<FromGitter>
<watzon> @straight-shoota so with it implemented at runtime it wouldn't require a Hash/NamedTuple literal right?
<FromGitter>
<straight-shoota> Nope, just a Hash or NamedTuple
<FromGitter>
<straight-shoota> Or whatever implements `#[]?`
<FromGitter>
<watzon> Awesome, that would be really nice for my usecase. Right now I have over 700 types that have to be assigned as a literal, and I need to reuse that lookup table in multiple places which means a lot of duplicated code right now
<FromGitter>
<straight-shoota> I know it gives a lot more flexibility. But I was wondering whether that would actually be that useful. Thanks for giving an example :D
<Yxhuvud>
What are you building that needs that many types? :)
<FromGitter>
<straight-shoota> It would still be a worthy improvement as it comes at almost no cost.
<FromGitter>
<watzon> TDLib bindings. Telegram defines a fuck ton of custom types.
<Yxhuvud>
Heh. I suppose I'm lucky when trying to do liburing bindings then. Not many types (instead there is fun things like static inline methods in .h files and fun macros that deal with volatile values)