<FromGitter>
<watzon> Since with reply you'd normally have to do `send_message(message.chat.id, "Hello world", reply_to_message_id: message.message_id)`
<FromGitter>
<Blacksmoke16> oh yea quite a bit less typing
<FromGitter>
<Blacksmoke16> figure out how to supply the bot i take it?
<FromGitter>
<watzon> Yeah I went with the `BotContainer` idea for now
<FromGitter>
<Blacksmoke16> 👍
<FromGitter>
<watzon> Also, obligatory "You know nothing, Jon Snow`
<FromGitter>
<Blacksmoke16> 😉
<FromGitter>
<Blacksmoke16> serializable has `after_initialize`
<FromGitter>
<Blacksmoke16> but cant do anything before
<FromGitter>
<Blacksmoke16> er sorry, thats for deserialization
<FromGitter>
<Blacksmoke16> it was `on_to_json` which happens after everything has already been serialized
<FromGitter>
<Blacksmoke16> what other features would be useful...
alex`` has quit [Quit: WeeChat 2.5]
<companion_cube>
so, I imagine code is linked into an executable only if it's in a C lib or if it's transitively used, right? Which would mean the stdlib can be big and not bloat executables
<FromGitter>
<Blacksmoke16> yea if you dont use a method its not included in the binary
<companion_cube>
and if I don't require a module, same, right?
<FromGitter>
<Blacksmoke16> prob
<companion_cube>
I hope this kind of semantics will be clarified before 1.0 ;-)
<companion_cube>
also, static dispatch vs dynamic dispatch
<FromGitter>
<Blacksmoke16> dunno
<companion_cube>
I mean, if some people are to use it as a replaement for C++… ;)
chemist69 has quit [Ping timeout: 276 seconds]
chemist69 has joined #crystal-lang
ht_ has joined #crystal-lang
hightower3 has quit [Ping timeout: 244 seconds]
rohitpaulk has joined #crystal-lang
rohitpaulk has quit [Remote host closed the connection]
sagax has quit [Read error: Connection reset by peer]
gangstacat has quit [Quit: Ĝis!]
absolutejam1 has joined #crystal-lang
absolutejam1 has quit [Ping timeout: 245 seconds]
<FromGitter>
<DanilaFe> Hi all! I've got a question about JSON decoding: the API I'm accessing encodes JSON as `{"type": "object type", ... fields specific to type}`. I'm trying to easily ⏎ decode this in my client code - but it seems like JSON.mapping generates code that always asks for an object, and thus I can't use the resulting code (after reading the "type" field, there will be no object before the other fields need to be
<FromGitter>
... read). Is there an easy way to implement a parser for this, or do I have to stay away from JSON.mapping?
<FromGitter>
<dscottboggs_gitlab> This is a question which has come up before and there are two options, and depending on the source of the data there is probably only one: ⏎ ⏎ 1) A custom overload of `self.new(JSON::PullParser) : self`. Here is an example (https://github.com/dscottboggs/pingas/blob/10000e631f54fbcd3410c52fd1878d43e73838bd/src/notifier.cr#L5-L32) from one of my projects. The disadvantage to this approach is it
<FromGitter>
... always requires the `"type"` or `"kind"` key to be assigned first, so that you can use it to determine which Union member you want to deserialize. ⏎ 2) Use JSON.parse. This incurs a somewhat significant hit to performance. [https://gitter.im/crystal-lang/crystal?at=5d7624ec54e7c649d4b3b176]
absolutejam1 has quit [Ping timeout: 268 seconds]
erdnaxeli has joined #crystal-lang
gangstacat has joined #crystal-lang
absolutejam1 has joined #crystal-lang
absolutejam1 has quit [Ping timeout: 246 seconds]
<FromGitter>
<Blacksmoke16> im hoping to revisit that again when i get the deserialization side of things,is something that would be *super* useful
<companion_cube>
I think sealed abstract struct would do it
<FromGitter>
<Blacksmoke16> had an idea for my assertion lib. I think it would be easy to support using the assertions outside of a property/annotation context
<FromGitter>
<wontruefree> it is just used because people are use to it?
<companion_cube>
generally speaking, if I write code in 0.30, is it going to be broken a lot by 1.0? or relatively minor changes only?
<companion_cube>
wontruefree: what else would you write docs with?
absolutejam1 has quit [Ping timeout: 244 seconds]
<FromGitter>
<Blacksmoke16> broken, most likely yes
<FromGitter>
<Blacksmoke16> by how much depends on what gets changed
<FromGitter>
<Blacksmoke16> kinda hard to say, maybe look at the breaking changes past few releases and go from there?
<companion_cube>
:s
teardown has quit [Read error: Connection reset by peer]
<FromGitter>
<Blacksmoke16> i can say lately its mostly been smaller stuff
teardown has joined #crystal-lang
<companion_cube>
nice.
<FromGitter>
<Blacksmoke16> be sure you compile/run specs with warnings
<FromGitter>
<Blacksmoke16> can give you a heads up if something will be changing in a later version so you can fix it
<companion_cube>
like, deprecation warnings?
<FromGitter>
<Blacksmoke16> yea
<FromGitter>
<Blacksmoke16> i usually lump them in with my specs, so it'll fail CI if there are warnings
<FromGitter>
<Blacksmoke16> `crystal spec --warnings all --error-on-warnings`
<FromGitter>
<paulcsmith> @asterite I'm with you on the Symbol -> Enum. I like it when it works, but when it doesn't it can be confusing. Lots of edge cases, especially for newcomers.
<FromGitter>
<paulcsmith> Or if you mistype a symbol it tells you that it expects an Enum and not a Symbol (would expect it to give a "Did you mean" or hint that you need a different Symbol) but that's kind of the problem with passing a Symbol in place of some other object. Can be a bit tricky
absolutejam1 has joined #crystal-lang
<FromGitter>
<kingsleyh> hey - what does this mean when I compile my Crystal program: `Program received and didn't handle signal ILL (4)`
<FromGitter>
<kingsleyh> I'm not doing any kind of spawn or anything like that
<FromGitter>
<bew> yeah I use it for a few "scripts", I don't really like the implementation (use of constants to read ARGV for example) but overall it works well, so I don't want to rewrite everything for now :P
<FromGitter>
<Blacksmoke16> still dont really see the benefit of like `crystal build --release script.cr -o ~/bin/script`
<FromGitter>
<Blacksmoke16> vs*
<companion_cube>
I'd rather put a small script into git, than a binary
<companion_cube>
(the kind of custom script in my dotfiles, I mean)
<FromGitter>
<bew> no separate step? / install step
<FromGitter>
<Blacksmoke16> but the source into git and build it on pull
<FromGitter>
<Blacksmoke16> put*
<companion_cube>
how is that more convenient than a shebang? :)
<FromGitter>
<Blacksmoke16> binary would still work if there is breaking change since its not dependent on the current version you have installed
<companion_cube>
otoh if you modify the script you have to recompile explicitely
<FromGitter>
<Blacksmoke16> right, would be assumed you use the binary once the script is done, if you edit it just rebuild it
<companion_cube>
the shebang version is convenient if you use crystal as a replacement to python/ruby, imho
<companion_cube>
for small cli utils
<FromGitter>
<Blacksmoke16> if that floats your boat
<FromGitter>
<bew> yes for cli utils, with almost no possible breaking change (or easily fixed) easier to use than having that separate build/install step
alex``` has quit [Quit: WeeChat 2.5]
ht_ has quit [Quit: ht_]
absolutejam3 has joined #crystal-lang
absolutejam2 has quit [Ping timeout: 246 seconds]
<FromGitter>
<DanilaFe> @dscottboggs_gitlab A custom overload of `self.new(JSON::PullParser) : self` sounds like the right idea; in fact, isn't that what `JSON.mapping` does? ⏎ The `type` field does always come first; once I read it, I will need the exact same code as `JSON.mapping` generates with the exception of the object parsing. Maybe this can be abstracted from the `JSON.mapping` macro by splitting it into two macros?
skryking has quit [Quit: WeeChat 2.4]
<FromGitter>
<wontruefree> @compainion_cube I guess I dont know
<FromGitter>
<wontruefree> I am sure there are some issues on github were people have discused it
<FromGitter>
<wontruefree> I like the minimalist doc formats
<FromGitter>
<wontruefree> but that would be more work to design and stuff
<companion_cube>
markdown is reasonable minimalistic imho, and a lot of people know it
<companion_cube>
(cmark, hopefully, not old ugly unspecified markdown)
absolutejam3 has quit [Ping timeout: 245 seconds]
<FromGitter>
<DanilaFe> wait, can Crystal macros only have 1 level of nesting? a macro can't invoke another macro?
<FromGitter>
<Daniel-Worrall> Nested Macros?
<FromGitter>
<DanilaFe> yeah, that's that I'm asking about
<FromGitter>
<DanilaFe> I was musing about breaking up `JSON.mapping` into reusable chunks, but if Crystal doesn't have nested macros...
<FromGitter>
<DanilaFe> actually that's not even necessary
absolutejam3 has joined #crystal-lang
<FromGitter>
<Blacksmoke16> `{% verbatim do %}`
<FromGitter>
<Blacksmoke16> macros within that you dont have to do the `\{%` thing
jhass has quit [Ping timeout: 264 seconds]
asterite_ has joined #crystal-lang
asterite has quit [Ping timeout: 252 seconds]
asterite_ is now known as asterite
DeBot has quit [Ping timeout: 252 seconds]
jhass has joined #crystal-lang
<FromGitter>
<DanilaFe> Oh, sweet! Though I think I'm over complicating it. In principle, can't there be an "object" parameter to the `mapping` macro that serves as a switch? If it's of, no read_begin_object? This would make implementing discriminated JSON unions pretty nice
<FromGitter>
<DanilaFe> Off*
absolutejam3 has quit [Ping timeout: 244 seconds]
<FromGitter>
<DanilaFe> Because hypothetically, you could then dispatch to an `.new` method generated by the `mapping` macro depending on the first json field you read
asterite has quit [Ping timeout: 245 seconds]
DeBot has joined #crystal-lang
asterite has joined #crystal-lang
jhass has quit [Ping timeout: 276 seconds]
jhass has joined #crystal-lang
<FromGitter>
<Blacksmoke16> i been thinking about this today
<FromGitter>
<Blacksmoke16> and came up with an idea
<FromGitter>
<Blacksmoke16> but let me see if it works first :S give me a while
<FromGitter>
<watzon> I've never learned what the `\%{` thing is with macros
<FromGitter>
<Blacksmoke16> it prevents the macro from executing if the macro is in another macro
<FromGitter>
<Blacksmoke16> i.e. macro included etc
<FromGitter>
<watzon> Ahhh interesting
<FromGitter>
<DanilaFe> @Blacksmoke16 great! I'd be interested in what you come up with. Discriminated unions are very common in this API
<FromGitter>
<Blacksmoke16> alright so, \cc @dscottboggs_gitlab will want in on this too
<FromGitter>
<Blacksmoke16> we've been thinking about this wrong i think
<FromGitter>
<Blacksmoke16> the main issue is you cant know what type to deserialize into until you're done serializing the data right?
<FromGitter>
<Blacksmoke16> deserializing*
<FromGitter>
<DanilaFe> until you're at least halfway through. In my case, the `type` key is first, but it's still too late
<FromGitter>
<Blacksmoke16> exactly, SO i remembered girng's thread about `JSON.parse` vs `.from_json`
<FromGitter>
<Blacksmoke16> essentially just as fast
<FromGitter>
<Blacksmoke16> so now if you let `JSON.parse` do the serialization, then new up your class based on the resulting `JSON::Any` you can do it