00:29 <FromGitter> <Blacksmoke16> ```arr.replace [1, 2, 3] ⏎ ⏎ # versus ⏎ ⏎ arr = [1, 2, 3]``` ⏎ ⏎ I [https://gitter.im/crystal-lang/crystal?at=603840e7e0d7284c735c20b2]

00:29 <FromGitter> <Blacksmoke16> is there any actual difference between these?

00:33 <FromGitter> <Blacksmoke16> i guess `replace` would retain the same array so would be a bit more performant?

00:33 <FromGitter> <jrei:matrix.org> The reference

00:33 <straight-shoota> yeah

00:34 <FromGitter> <jrei:matrix.org> `arr.replace other` vs `arr = other`

00:34 <FromGitter> <Blacksmoke16> makes sense, thanks

00:34 <FromGitter> <jrei:matrix.org> in the first case `arr.object_id != other.object_id`, and the second `arr.object_id == other.object_id`

00:37 <FromGitter> <jrei:matrix.org> same for `#dup` - keep the reference and reuse the buffer

01:14 <FromGitter> <Blacksmoke16> @alexherbo2 I think you were asking for this. https://github.com/Blacksmoke16/oq/pull/73 if you wanted to test it out. Will get it released soon

01:35 <FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=603850636c077b203578c680]

01:35 <FromGitter> <Blacksmoke16> example usage

09:11 <FromGitter> <alexherbo2> how to parse a recursive `Array(Argument).from_json(STDIN)`?, with `Argument` being an alias to `Nil | Bool | Int32 | String | Array(Argument)`

09:12 <FromGitter> <alexherbo2> I tried with a recursive alias, but it does not work, because the JSON parser cannot do `Argument.class`

09:14 <FromGitter> <alexherbo2> I tried with a struct with a value property, and include `JSON::Serializable` but then my json string has to be `[{"value": 2}]` instead of `[2]` for example

09:15 <FromGitter> <alexherbo2> my struct was like

09:15 <FromGitter> <alexherbo2> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=6038bc2ce8267a46f2d9c3b6]

09:18 <FromGitter> <alexherbo2> @Blacksmoke16 thanks for the snippets

12:57 <straight-shoota> probably best to define a custom json converter

12:57 <straight-shoota> i.e. a `from_json` method that looks at the parser token and decides what type to parse

13:39 <FromGitter> <Blacksmoke16> at this point wouldnt `JSON.parse STDIN` be better

13:39 <FromGitter> <Blacksmoke16> given it sounds like there is not structure to the data

19:22 <FromGitter> <Blacksmoke16> ```5...10.times do |i| ⏎ puts i ⏎ end``` ⏎ ⏎ I feel like this should be a syntax error... [https://gitter.im/crystal-lang/crystal?at=60394a65e562cf54ac8629fe]

19:29 <FromGitter> <lodenos> Hey Guy’s I note a wierd behavior with BigDecimal ⏎ if divise ⏎ ⏎ `````` [https://gitter.im/crystal-lang/crystal?at=60394bfd95e23446e4fc11d2]

19:31 <FromGitter> <lodenos> Hey Guy’s I note a wierd behavior with BigDecimal ⏎ if I divise a / b ⏎ ⏎ ```a = BigDecimal.new 3.00000001 ⏎ b = BigDecimal.new 1.1111111 ⏎ ⏎ puts a / b``` ⏎ ... [https://gitter.im/crystal-lang/crystal?at=60394c97e8267a46f2db7dc2]

19:35 <FromGitter> <lodenos> How solve this issue ?

19:35 <FromGitter> <Blacksmoke16> did you try just doing `3.0`?

19:36 <FromGitter> <lodenos> Yes doesn’t work

19:37 <FromGitter> <Blacksmoke16> rip

19:39 <FromGitter> <Blacksmoke16> seems like some issue with the `@scale` ivar, as it's `UInt64`

19:39 <FromGitter> <Blacksmoke16> i.e. `0_u64 - 1` underflow

19:40 <FromGitter> <oprypin:matrix.org> @lodenos: please just report a bug then :>

19:40 <FromGitter> <Blacksmoke16> ^

19:41 <FromGitter> <lodenos> It’s work if I put @scale

19:41 <FromGitter> <lodenos> @oprypin:matrix.org yes I go to write this issue on github

22:43 <straight-shoota> yeah `scale = @scale - other.scale` is a classic example why doing math with unsigned integers is harmful

22:47 <straight-shoota> the worst about it: the Rust implementation that our's is based on uses a signed i64 for scale :(

23:46 <FromGitter> <asterite> I wonder how we'll fix that uint32 bug... Maybe it was a bug all a long but llvm 11 made it always trigger

23:49 <straight-shoota> does it only happen with uint32? No other type?

23:50 <straight-shoota> I can't reproduce your reduced example with LLVM 9 but I suppose that's expected

23:51 <FromGitter> <asterite> Yes, it only happens on llvm 10 or later

23:52 <FromGitter> <asterite> I'm almost sure it has to do with union types being assigned to larger union types, but it's strange that it's not always reproducible

23:53 <FromGitter> <asterite> Or maybe string parsing is unsafe and does something bad... But so far I couldn't find anything

23:53 <FromGitter> <asterite> Also I had an example that fails, but also runs fine with prelude empty

23:54 <FromGitter> <asterite> I guess with time we'll find the answer... Too bad it blocks 1.0. Though maybe we can introduce a workaround just so that the compiler can work fine for these cases, and just consider this a bug with int unions, which isn't used that often

23:55 <straight-shoota> hm, maybe it's really an LLVM bug in the end... :/

23:57 <straight-shoota> but to confirm that we'd still need to figure out what exactly is going wrong

23:59 <FromGitter> <Blacksmoke16> Would it be easier to fix llvm12 support and try with that