<FromGitter>
<dscottboggs_gitlab> Ok so here's an actual use case that will get me to switch to CRSerializer right now. ⏎ ⏎ I want to have a YAML config file like ⏎ ⏎ ``` code paste, see link``` ... [https://gitter.im/crystal-lang/crystal?at=5cb911d4a4ef097471c045b5]
<FromGitter>
<Blacksmoke16> you can have spaces in yaml keys?
<FromGitter>
<dscottboggs_gitlab> yup
<FromGitter>
<dscottboggs_gitlab> (I think)??
<FromGitter>
<Blacksmoke16> well i mean do realize CrSerializer is basic just stdlib++
<FromGitter>
<Blacksmoke16> just adds some features, not really its own thing
<FromGitter>
<dscottboggs_gitlab> yeah... so no way to specify a type based on another key?
<FromGitter>
<Blacksmoke16> so you would want ⏎ ⏎ ``` kind: telegram ⏎ options: ⏎ chat id: asdlfkn ⏎ api key: ljopijwne``` ⏎ ⏎ to new up a like `Telegram` class, while the `email` kind would new up a `Email` class? [https://gitter.im/crystal-lang/crystal?at=5cb91263e416b84519a17800]
<FromGitter>
<Blacksmoke16> dependent on what they key is?
<FromGitter>
<dscottboggs_gitlab> yes exactlyu
<FromGitter>
<Blacksmoke16> let me try something
* FromGitter
* dscottboggs_gitlab is tentatively excited to not have to deal with `YAML::Node`/`YAML::Context`
<FromGitter>
<Blacksmoke16> :S
<FromGitter>
<Blacksmoke16> the options are also dependent on the kind?
<FromGitter>
<Blacksmoke16> are all of the kinds known?
<FromGitter>
<dscottboggs_gitlab> the `options` key is known and all potential values of `kind` will be known at compile time
<FromGitter>
<Blacksmoke16> perfect
<FromGitter>
<dscottboggs_gitlab> it's meant to be extensible at compile time but not runtime, for efficiency's sake
<FromGitter>
<Blacksmoke16> are there any options that are shared between kinds?
<FromGitter>
<dscottboggs_gitlab> it's just the stuff *under* the `options` key that isn't known.
<FromGitter>
<dscottboggs_gitlab> I don't think that will necessarily be the case
<FromGitter>
<dscottboggs_gitlab> but again, all keys are known at compile time
<FromGitter>
<Blacksmoke16> oh know key/values under `options` are dynamic?
<FromGitter>
<Blacksmoke16> and not known at compile time?
<FromGitter>
<dscottboggs_gitlab> no they're known at compile time but I want to make them able to be anything, so that extensions can easily be written for other notifiers
<FromGitter>
<dscottboggs_gitlab> the notifier just has to implement the `kind` and `options` properties (deserializing etc) and two other methods, but the current implementation of the `options` key is much less than ideal and I don't even know how to do it in YAML+crystal
<FromGitter>
<Blacksmoke16> but if the keys of `options` are known, you could create classes for each one like
<FromGitter>
<dscottboggs_gitlab> yeah I thought about just making `options` a hash, but I wanted to allow it to be any struct.
<FromGitter>
<dscottboggs_gitlab> yes, all the keys of options are known at compile time -- to add more types you'd need to recompile
<FromGitter>
<Blacksmoke16> rgr
<FromGitter>
<dscottboggs_gitlab> you don't have to solve all my problems for me ;) I was just wondering if your library already had a solution
<FromGitter>
<Blacksmoke16> its an interesting challenge
<FromGitter>
<Blacksmoke16> you could get close i think
<FromGitter>
<dscottboggs_gitlab> yup. it's not too hard in JSON if you just throw an exception if `kind` isn't first in the file... but YAML::PullParser is a bit lacking...
<FromGitter>
<dscottboggs_gitlab> specifically the `#read_mapping` overload with a block that yields the key...
<FromGitter>
<Blacksmoke16> yea im hitting some compiler bug
<FromGitter>
<Blacksmoke16> is the main thing you care about is each kind has its own `options` object vs a hash?
<FromGitter>
<dscottboggs_gitlab> that's the idea. I might just have to go with a hash though
<FromGitter>
<Blacksmoke16> that might be more doable
<FromGitter>
<dscottboggs_gitlab> but like even a hash wouldn't be ideal, because then it has to be a specifically-typed hash, and what if one of the options needs a nested option or an array?
<FromGitter>
<dscottboggs_gitlab> then you've got people parsing URL-encoded JSON out of a YAML-encoded string and it's just a mess
<FromGitter>
<dscottboggs_gitlab> that's a very good idea, I'm excited to give the MT scheduler a try too...just a matter of finding the time amidst everything else.
<FromGitter>
<dscottboggs_gitlab> I'm off to bed though ✌️
<FromGitter>
<Blacksmoke16> see you
f1refly has quit [Ping timeout: 264 seconds]
alexherbo21 has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 244 seconds]
f1refly has joined #crystal-lang
alexherbo21 has quit [Ping timeout: 250 seconds]
DTZUZO has joined #crystal-lang
<FromGitter>
<m-o-e> congrats to the new release! love how crystal continues to shape up
<FromGitter>
<m-o-e> just one thing i don't love: the needless deviations from ruby syntax. (includes vs include, and now foo[1..] instead of foo[1..-1]) why do we keep doing that? :(
<FromGitter>
<tenebrousedge> Crystal is not Ruby
<FromGitter>
<m-o-e> and for that reason we make it extra hard for the people who go back and forth between them on a daily basis?
<FromGitter>
<tenebrousedge> no, but for that reason the Crystal developers don't need to constrain themselves to only making a Ruby clone
<FromGitter>
<m-o-e> i'm not talking about constraints. i'm just asking why we vary the syntax there, when the familiar ruby synax would work just as well.
<FromGitter>
<m-o-e> oh, i indeed didn't know that! (looks like it was added fairly recently?). ok, then my point is moot. :)
<FromGitter>
<tenebrousedge> I would tend to assume that just about everything in Crystal is evaluated against Ruby's functionality, and that there is an explanation for any differences in the Issues list.
<FromGitter>
<m-o-e> that's great! i was just coming from the blog post and didn't know that ruby had added the same syntax recently. mea culpa :)
<FromGitter>
<tenebrousedge> yes, I learned about that from the Crystal Github issue #7170 just now, so it's news to me too.
<FromGitter>
<tenebrousedge> I use SpaceVim, which has a Crystal plugin for syntax highlighting and some degree of linting
sz0 has joined #crystal-lang
<FromGitter>
<bew> There is a vim plugin called vim-crystal (note: you don't necessarily need SpaceVim)
<FromGitter>
<mavu> I use vim and vim-crystal, and it works well, altough it is occasionally possible to confuse it with c-bindings. Nor really a problem though
DTZUZO has joined #crystal-lang
ashirase has quit [Ping timeout: 255 seconds]
ashirase has joined #crystal-lang
rohitpaulk has joined #crystal-lang
alexherbo2 has joined #crystal-lang
rohitpaulk has quit [Remote host closed the connection]
DmitryBochkarev has quit [Quit: Leaving]
Yxhuvud has quit [Remote host closed the connection]
Yxhuvud has joined #crystal-lang
<FromGitter>
<drum445> Nice work with the release all!
japanoise has joined #crystal-lang
<FromGitter>
<TheOnlyArtz> Hey, `mutex.synchronize` will lock and then unlock right away?
<FromGitter>
<dscottboggs_gitlab> I use vim-crystal, and would recommend setting the `let g:crystal_auto_format = 1` option in your `.vimrc` -- it's not set by default and makes things much nicer.
<wuehlmaus>
dscottboggs_gitlab: what exactly does it add to the default way?
<FromGitter>
<dscottboggs_gitlab> it runs `crystal tool format` on the open file
<wuehlmaus>
ah, thanks
<wuehlmaus>
because indentation works in the default version, so i wasn't sure about the difference
<FromGitter>
<dscottboggs_gitlab> yeah, it'll kinda do auto-indenting, but it doesn't format things as neatly as the format tool does.
<livcd>
there is no crystal talk on rubykaigi right?
<livcd>
nothing i can find ...
misaki_m has joined #crystal-lang
dunpeal has joined #crystal-lang
<dunpeal>
How much industry use does Crystal see right now?
<FromGitter>
<dscottboggs_gitlab> shit...crystal doesn't offer any way to do multiple inheritance...does it? I need to represent a class which implements two abstract classes...
<FromGitter>
<dscottboggs_gitlab> @dunpeal, there are several companies which run crystal as a server-side platform, either with the Lucky or the Amber libraries. I think there's an AI company and a blockchain company who use Crystal.
<z64>
@dscottboggs_gitlab you can include multiple modules that contain `abstract def`s