07:32 <FromGitter> <spuun> Macro issue. Dunno if it's a bug or if I'm doing something wrong. ⏎ https://play.crystal-lang.org/#/r/duam

07:37 <FromGitter> <erdnaxeli:cervoi.se> the macro is not the issue: https://play.crystal-lang.org/#/r/duan

07:37 <FromGitter> <erdnaxeli:cervoi.se> well, yes it is

07:38 <FromGitter> <erdnaxeli:cervoi.se> it looks like the `::` in front of `Log` are removed from the type in the ivar

07:54 <FromGitter> <spuun> Yeah.

07:55 <FromGitter> <spuun> And dunno if i can get around it? Maybe i must get the type vars and add the `::`? hm

07:59 <FromGitter> <spuun> https://play.crystal-lang.org/#/r/duap ⏎ Works.

09:39 <jrayhawk> https://github.com/obsproject/obs-websocket/blob/master/docs/generated/protocol.json I was thinking of macroing a protocol spec into crystal object definitions; are there good examples available of how to go about doing so?

11:46 <FromGitter> <moe:busyloop.net> hmm in this ancient codebase (0.34) i have a `rescue ex : Errno`. ⏎ anyone remember what this was replaced with in current crystal? 🤔

11:47 <FromGitter> <moe:busyloop.net> (apparently TCPSocket used to raise it)

11:49 <FromGitter> <spuun> `typeof({{ivar}}).new` even better!

12:00 <FromGitter> <moe:busyloop.net> > anyone remember what this was replaced with in current crystal? 🤔 ⏎ ⏎ aha, `Socket::Error` it seems. ⏎ that took a bit more digging than it should - crystal needs a better way to discover what exceptions can bubble up from where </mini-rant> [https://gitter.im/crystal-lang/crystal?at=633acef834982518bddf8a21]

14:21 <FromGitter> <moe:busyloop.net> and another question: ⏎ are there any working docker images around to compile to amd64 on an m1 mac? ⏎ ⏎ the official images have been broken on m1 for a long time ⏎ and now the 84codes images that used to work as a workaround ... [https://gitter.im/crystal-lang/crystal?at=633aefd92a06f4566b1c1f12]

14:28 <FromGitter> <djberg96> Does crystal have something that deals with this issue in Ruby? https://bugs.ruby-lang.org/issues/19024

14:33 <FromGitter> <Blacksmoke16> not that i can think of

14:33 <FromGitter> <Blacksmoke16> usually you'd have diff entrypoint files that require the needed files. E.g. how `spec_helper` requires the spec modules and your fixtures etc

16:38 <yxhuvud> djberg96: No. That proposal looks kinda neat.

16:42 <yxhuvud> though having a `package` construct to go with it instead of reusing modules would probably be necessary, as noted in that discussion.

16:46 <riza> yeah it's an interesting patch, but man would that drop a bomb

16:46 <riza> i dont think that can be done without a new top level construct

19:06 <FromGitter> <djberg96> definitely agree that if implemented would require a new construct

19:27 <FromGitter> <spuun> About the 84codes images, open an issue and we'll look into it.

20:06 <SamantazFox> Hello there!

20:06 <FromGitter> <Blacksmoke16> uh oh

20:07 <SamantazFox> I don't understand the difference between `@type.id` and `@type.name`

20:07 <SamantazFox> https://play.crystal-lang.org/#/r/dudf

20:07 <SamantazFox> Blacksmoke16: Why "uh oh"? xDD

20:07 <FromGitter> <Blacksmoke16> normally you saying hello means there's a problem :P

20:07 <SamantazFox> xDDD

20:09 <FromGitter> <Blacksmoke16> pretty sure they're essentially the same in this context

20:10 <SamantazFox> mmmhhh

20:10 <SamantazFox> How can I get `BarClass` alone then?

20:11 <FromGitter> <Blacksmoke16> https://github.com/crystal-lang/crystal/blob/master/src/compiler/crystal/macros/methods.cr#L339-L341 `#id` ends up also calling `to_s`

20:11 <FromGitter> <Blacksmoke16> for type nodes at least

20:12 <FromGitter> <Blacksmoke16> `@type.id.split("::").last`

20:14 <SamantazFox> Ok, thanks :)

20:15 <SamantazFox> I'm kinda disappointed that either `.name` or `.class_name` doesn't return the module/struct/class name alone :c

20:18 <FromGitter> <Blacksmoke16> there's also an undocumented method `identify`, idk what the point of it is tho. basically turns like `Test::BarClass` into `Test__BarClass` :shrug:

20:18 <FromGitter> <Blacksmoke16> `@type.id.identify`

20:19 <FromGitter> <Blacksmoke16> think the catch there is what would happen if there was two types with that name in diff namespaces?

20:21 <SamantazFox> My goal is to have a YAML config that is based on the class names

20:21 <FromGitter> <Blacksmoke16> should prob use the FQN then to be on the safe side

20:21 <SamantazFox> https://github.com/iv-org/invidious/blob/1580bab9a3cb46b080128df8d557f94830a0fcbb/src/invidious/jobs.cr#L4-L18

20:21 <SamantazFox> the problem is that the FQN won't be user friendly...

20:23 <FromGitter> <Blacksmoke16> if you can be assured there wont even be a case like like `MyApp::Admin::Jobs::Thing` and `MyApp::Core::Jobs::Thing`

20:23 <FromGitter> <Blacksmoke16> then its prob fine, otherwise wouldnt know which one to use?

20:27 <SamantazFox> the FQN is used to initialize the variable, so that won't be a problem on that part

20:27 <SamantazFox> the problem will be that there are two properties with the same name

20:27 <SamantazFox> but that shouldn't happen (and if it does, the compiler won't be happy, I guess?)

20:28 <FromGitter> <Blacksmoke16> the latter one would override the first

20:29 <SamantazFox> Ah, ok, good to know.

20:39 <SamantazFox> Hmm, problem of `.split("::")` is that I'm getting a StringLiteral

20:39 <FromGitter> <Blacksmoke16> then call `.id` on that

20:39 <SamantazFox> How do I convertBack to a MacroId?

20:39 <SamantazFox> Ah, ok

20:52 <SamantazFox> Blacksmoke16 thanks for your help, as always ^^

20:55 <FromGitter> <Blacksmoke16> np