<FromGitter>
<watzon> @jrei:matrix.org you might be able to get away with doing this https://carc.in/#/r/ab5q
<Andriamanitra>
i've never seen this "uninitialized" magic before, very cool
_ht has joined #crystal-lang
jrayhawk has quit [Remote host closed the connection]
jrayhawk has joined #crystal-lang
f1reflyylmao is now known as f1refly
<repo>
Blacksmoke16: hey! I have a project I need mongodb for and I used the shard "moongoose" as ODM. Fields are simply defined as properties/instance vars. If i then include ASR::Serializer it kind of breaks some of the initializers coming from Moongoose. Would you happen to know why? I'd like to make a PR to moongoose so it'd play nice with Athena serializer.
<FromGitter>
... NamedTuple or named arguments aka NamedTuple. These three options give me sense. I wrote some tests (see my commit) in hash spec which itself is passed but the full specs fail on: ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ It makes sense when `NamedTuple#fetch` can receive as a key only `String` or `Symbol`. Unfortunately, I'm ... [https://gitter.im/crystal-lang/crystal?at=60100d076b20cf7730dbc4bb]
deavmi has quit [Ping timeout: 272 seconds]
deavmi has joined #crystal-lang
<FromGitter>
<asterite> `if mapping.is_a?(NamedTuple)` should work to special case that
<FromGitter>
<asterite> Oh, nevermind...
<FromGitter>
<asterite> I guess you can do `if key.is_a?(String) || key.is_a?(Symbol)`
<FromGitter>
<Blacksmoke16> repo: whats the error?
<FromGitter>
<Blacksmoke16> alternative solution is to have a DTO
<FromGitter>
<Blacksmoke16> i.e. create some other object you create from the actual mongo document type that you can serialize
<FromGitter>
<jrei:matrix.org> 1) 36.0 expected for today 🎉
<FromGitter>
<erdnaxeli:cervoi.se> omg
<FromGitter>
<Daniel-Worrall> Seems so, yeah
<FromGitter>
<jrei:matrix.org> But of course it will be globally available in 1-3 days
<FromGitter>
<Blacksmoke16> if you use snap it'll be ready soon as the build is done 😉
<FromGitter>
<jrei:matrix.org> Yes, that's what I meant
<FromGitter>
<jrei:matrix.org> All the docker, snap, apt, rpm and so on builds
<FromGitter>
<jrei:matrix.org> Honestly I don't mind waiting even 1 week
<FromGitter>
<Blacksmoke16> at this point whats another week :p
<FromGitter>
<Daniel-Worrall> What are the big changes anyway
<FromGitter>
<mattrberry> Oh right, I forgot about this issue with 0.36.0... I define ⏎ ⏎ ``` code paste, see link``` ⏎ ⏎ Looks like just removing the return type from the abstract def works, although I don't need to remove it from the extending classes.. Seems odd, or at the very least, it seems like the error message could be improved [https://gitter.im/crystal-lang/crystal?at=60106f95cf8b82773456dccf]
<FromGitter>
<RespiteSage> Couldn't you also add the type restriction to the implementing types?
<FromGitter>
<mattrberry> On the classes that extend SoundChannel? They have the type restriction
<FromGitter>
<mattrberry> And the way to get the compiler to be happy is just to remove it from the abstract class, but I don't need to remove it from the classes that extend that one
<FromGitter>
<RespiteSage> Oh. Weird. I didn't read that it says that `Object` is overriding it.
<FromGitter>
<mattrberry> @straight-shoota I know you looked into this the last time I mentioned it, but I don't remember what the conclusion was?
<FromGitter>
<RespiteSage> Did you monkey patch object?
<FromGitter>
<Blacksmoke16> to be clear pretty sure the issue is that your class implicitly inherits from `Object` which doesnt have the restriction
<FromGitter>
<Blacksmoke16> which defines `abstract def ===(other)`
<FromGitter>
<Blacksmoke16> so technically your class isnt compatible with `Object`
<FromGitter>
<Blacksmoke16> imo solution should be to add some more explicit type restrictions to `Object`'s abstract methods
<FromGitter>
<Blacksmoke16> or for now, just remove the type restriction on your class
<FromGitter>
<mattrberry> Right, 100% agree with everything you said
<FromGitter>
<Blacksmoke16> id maybe file an issue/PR for it
<FromGitter>
<mattrberry> I know Johannes was looking into it before, so I'm curious what the conclusion was on that before I open an issue
<FromGitter>
<mattrberry> Ty for the link, I remember that now
<FromGitter>
<mattrberry> Oh one other thing that's gonna kill me now on my emulator haha. This is no longer valid ⏎ ⏎ ```puts -1_i8.to_u32``` ⏎ ⏎ The problem is that I have these in random places all over the codebase, and the only easy way to find them is to let the emulator run and catch it when the error occurs. But when running in release, the stack trace points to the wrong line/file completely. So the only way to
<FromGitter>
<Blacksmoke16> iirc cant you do like `.to_u32!`?
<FromGitter>
<mattrberry> Yeah I can, but I don't know all the places in which I do this..
<FromGitter>
<mattrberry> And the stack trace doesn't point me to the correct place when it overflows
<FromGitter>
<Blacksmoke16> cant just find replace?
<straight-shoota>
s/to_u32/to_u32!/g
<FromGitter>
<Blacksmoke16> yea :P
<straight-shoota>
this way you get the same behaviour as before
<FromGitter>
<mattrberry> Sure, but the problem there is that there are places where I still might want the overflow to raise an exception
<FromGitter>
<mattrberry> Like where I don't actually expect it to happen
<FromGitter>
<mattrberry> I guess I just need to go through them 1 by 1..
<FromGitter>
<Blacksmoke16> time to write some unit tests
<straight-shoota>
that ^
<straight-shoota>
but yeah, stack traces are a problem
<FromGitter>
<Daniel-Worrall> Is there any way to get the stack trace but also compile in release?
<FromGitter>
<mattrberry> Yeah, that'd be nice to have at some point. Typically when making an emulator, the more useful tests are the test programs that you actually run through the emulator rather than unit tests for each instruction. With 32-bit instructions and endless possible states that those can be run on, it's tricky to think of every possible edge-case to test in unit tests..
<FromGitter>
<mattrberry> That's why people make fuzzers to test the emulator implementation
<FromGitter>
<Blacksmoke16> dont need to go from 0% to 100% coverage, just main flow then always can add in more if/when bugs are discovered fixed
<FromGitter>
<mattrberry> And if I could trust the stack trace, then I could use those to debug :/
<straight-shoota>
you could try to temporarily inject a delegate method
<FromGitter>
<Blacksmoke16> :bigbrain:
<straight-shoota>
s/to_u32/to_u32_temp/g
<FromGitter>
<Blacksmoke16> theres also the `caller` macro
<FromGitter>
<mattrberry> Honestly, I think that's the approach I'll take now. Thanks for the idea
<FromGitter>
<mattrberry> Is `caller` accurate if the Exception stack trace isn't?
<FromGitter>
<Blacksmoke16> prob not given its just doing like `Exception::CallStack.new.printable_backtrace` so prob would be the same?
<FromGitter>
<Daniel-Worrall> Oh, has there been any discussion on using github packages btw instead of or as well as docker hosting?
<FromGitter>
<Daniel-Worrall> via ghcr.io
<straight-shoota>
Daniel-Worrall isn't that just a docker registry?
<FromGitter>
<Daniel-Worrall> essentially, yeah
<straight-shoota>
Blacksmoke16 `caller` is not a macro but yeah, it retrieves the call stack exactly like an exception
<FromGitter>
<RespiteSage> I narrowed down the behavior some. It only seems to happen when the included module's generic type contains the abstract struct type.