01:02 <FromGitter> <me:ky.rs> just a wild guess from glancing at their api + all the api madness ive seen out there: maybe put `formdata.field("type", "dtg")` as the first field?

01:34 <FromGitter> <mixflame> ok! i will try that

06:04 <Guest59> Hi

06:34 <FromGitter> <naqvis> Hi

13:37 <oz> v

13:37 <oz> oops, sorry. Wrong window.

17:16 <FromGitter> <mistergibson:matrix.org> is there a source build path for the arm64 arch?

17:17 <FromGitter> <mistergibson:matrix.org> I've got a Raspberry Pi 400 running Ubuntu and would like to add crystal

19:24 <straight-shoota> You can cross compile from a x86 system

19:26 <straight-shoota> https://danilafe.com/blog/crystal_on_arm/

19:26 <straight-shoota> @mistergibson ^

19:54 <FromGitter> <Daniel-Worrall> I've got a docker image of arm64 alpine https://hub.docker.com/r/danielworrall/crystal

19:55 <FromGitter> <Daniel-Worrall> Dockerfile in here https://github.com/Daniel-Worrall/crystal-build

20:03 <FromGitter> <Daniel-Worrall> Can either use it in rpi docker, or use it to build for ubuntu without cross compile

21:07 <FromGitter> <Daniel-Worrall> Okay, I don't have a Comp Sci background, so hopefully this isn't a dumb question. Would a binary cross compiled result in the same binary compiled locally assuming they're both static/release/etc/source version/target version

21:38 <FromGitter> <mistergibson:matrix.org> the arm procedure didn't work for me -- I'll keep trying. Any idea when an *official* arm64 build will be forthcoming?

21:43 <FromGitter> <Daniel-Worrall> If you check out the dockerfile, you can see the usual hardships with cross-compiling, specifically the compiler. libcrystal.a for example, which is being removed in future crystal builds

21:44 <FromGitter> <Daniel-Worrall> Also uses alpine to avoid problems with dynamic linking

22:09 <straight-shoota> > Would a binary cross compiled result in the same binary compiled locally assuming they're both static/release/etc/source version/target version

22:10 <straight-shoota> Yes, should have the same result AFAIK

22:11 <straight-shoota> Code is generated by LLVM and that should operate the same way, whether it's building for the native architecture or a different one

22:12 <FromGitter> <Daniel-Worrall> So, I had an answer in the crystal discord. Reproducability (byte-for-byte) is a complicated issue, but the programs will be "the same"

22:55 <FromGitter> <elorest> Is there a better way to do line 2 of this? A way to take advantage of the fact that the compiler already knows what type the value is supposed to be. ⏎ https://carc.in/#/r/bb91

23:09 <FromGitter> <wyhaines> @elorest: I don't know if this qualifies as "better".... ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ Or something kind of similar to that. [https://gitter.im/crystal-lang/crystal?at=60c29b91d20143617e3ac9f1]

23:10 <FromGitter> <wyhaines> Generally, reopening standard lib types to add things is risky business, especially when they depend on other implementation details.

23:16 <FromGitter> <elorest> @wyhaines Yeah I generally try to avoid that. I was hoping there was something more general with types and aliases. Thanks though.

23:19 <FromGitter> <sclee15> Will CrystalConf unvail videos on YouTube? I am a Crystal user from South Korea. Since the event time starts up at 12AM in my timezone. I cannot attend the live event.

23:20 <FromGitter> <wyhaines> I don't know of any standard method that gives you the type that an array stores, unless you go and create one yourself as above. ⏎ ⏎ You could finagle something with a macro and *typeof*, which might also be reasonable if you are repeating the above pattern A LOT, but it also won't be particularly *pretty* in implementation).