01:22 <FromGitter> <naqvis> @j8r yeah, for usage purposes, I reviewed the samples and api documentation of lzma. Used wonderful `crystal_lib` for generating the bindings, did some cleanup, wrapped API calls to crystal IO. Pretty stratight-forward due to presence of `crystal_lib` as that does all of the heavy-lifting of generating C to Crystal bindings, we just need to tweak things afterwards.

01:58 <FromGitter> <naqvis> https://github.com/crystal-lang/crystal_lib

07:05 <FromGitter> <xqyww123> Does anyone find version `0.31.0` breaks some C binding caused by `invalid memory access` at runtime, while the same code works nicely in `0.30.0` (Maybe later I submit an issue if I find out the reason

07:22 <FromGitter> <naqvis> @xqyww123 by any means are you using `GC.alloc` and/or `GC.free` in your binding code?

07:22 <FromGitter> <naqvis> I had similar issues and got that removed and had lib used C `malloc` and/or `free`

07:24 <FromGitter> <xqyww123> yeah, some buffer allocated from Crystal is sent to C code. I will try it later

07:25 <FromGitter> <naqvis> that's something different. I'm talking about some libraries allowed passing `allocator` and/or `deallocator` which are used by library for allocating/freeing mem

07:27 <FromGitter> <naqvis> just an example https://github.com/naqvis/xz.cr/blob/2e54dc00f20aef6e7ddaea0e8bb98e944937f7b5/src/xz/writer.cr#L42 to line 46. Enabling this causes segfault on OSX, but things works good on Linux

07:32 <FromGitter> <xqyww123> Ummm, it sounds too advanced. No, I haven't used such cool things.

07:33 <FromGitter> <naqvis> then that might be different issue you are encountering.

07:33 <FromGitter> <xqyww123> Actually I haven't begun to dive into the bug (I simply downgraded crystal version temporarily :-)

07:34 <FromGitter> <naqvis> i would suggest to pin-point the code which is causing that error

07:34 <FromGitter> <naqvis> might be something hidden which got figured out by higher version of language

07:35 <FromGitter> <xqyww123> Yeah, I will, after my current work

07:37 <FromGitter> <naqvis> great

07:37 <FromGitter> <naqvis> do share your findings in this channel

07:41 <FromGitter> <xqyww123> (while every Chinese programmer is exploited by their boss :D , Of course, I will share :D

07:44 <FromGitter> <naqvis> hahaha 😆

07:44 <FromGitter> <naqvis> in OSS world you are your own boss 😆

07:47 <FromGitter> <xqyww123> (after today the DDL for me to submit the weekly report :D

07:50 <FromGitter> <naqvis> apologies for any offense if any caused. All I meant was to request your sharing after you find the issue and root-cause, as that is definitely going to help all others in this community 👏

07:55 <FromGitter> <xqyww123> take it easy and I know. I'm enthusiastic to contribute to the community :-)

07:56 <FromGitter> <naqvis> 👏

07:56 <FromGitter> <xqyww123> (If my language skill was better I'll even better :D

07:58 <FromGitter> <naqvis> practice makes perfect, we all learn from each other, that's the beauty of OSS and sharing

07:59 <FromGitter> <xqyww123> (ง •̀_•́)ง

08:07 <FromGitter> <xqyww123> (Actually, my current project will be open-sourced after it finished with already acquired permission from company :)

08:10 <FromGitter> <naqvis> great work

09:20 <FromGitter> <kingsleyh> Hi - does anyone know if it's possible to get crystal to emit LLVM IR bitcode that would work when passed to the `lli` tool to run it JIT style

09:20 <FromGitter> <kingsleyh> I did this: `crystal build b.cr --emit llvm-ir`

09:20 <FromGitter> <kingsleyh> but the `lli b.ll` complained:

09:21 <FromGitter> <kingsleyh> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5d90777f66c8b45122395048]

09:22 <FromGitter> <xqyww123> try `crystal build b.cr --emit llvm-ir --no-debug`

09:22 <FromGitter> <xqyww123> I'm not sure but `DISubprogram` seems related to debug info

09:23 <FromGitter> <kingsleyh> ha that resulted in:

09:23 <FromGitter> <kingsleyh> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5d9077fbd97d8e3549d17ecf]

09:23 <FromGitter> <kingsleyh> b.cr - has only `puts "hello"`

09:24 <FromGitter> <kingsleyh> maybe I need to pass some flags to lli as well to help

09:25 <FromGitter> <xqyww123> Does your way work for other languages like `clang`?

09:28 <FromGitter> <kingsleyh> yeah I can convert c file to llvm ir and execute it with lli

09:28 <FromGitter> <kingsleyh> I found this as well : https://github.com/Virtual-Machine/ir-examples

09:29 <FromGitter> <kingsleyh> it doesn't mention that the ll code can be executed by lli though - or if any dependent shared objects would be required to run it

09:31 <FromGitter> <kingsleyh> the ll code on that github does seem to run though

09:31 <FromGitter> <kingsleyh> I guess it does not include the prelude tho

09:37 <FromGitter> <kingsleyh> I guess it can't print to stout for some reason - I don't know enough about it to understand why though

09:38 <FromGitter> <kingsleyh> the C file example does print out to the console though

09:49 <FromGitter> <asterite> it's probable that lli's version is from a different LLVM version. The version must match the one in the compiler. LLVM introduces breaking changes by the minute

09:49 <FromGitter> <asterite> (well, we are not so different)

10:42 <FromGitter> <r00ster91> How do I get a https://crystal-lang.org/api/0.31.0/Crystal/Macros/Macro.html object? I don't see any way to receive the class from anything. No method returns it. Is it just there for the compiler's internals?

11:03 <FromGitter> <kingsleyh> Thanks @asterite

11:32 <FromGitter> <j8r> @naqvis but snappy is a pure Crystal implementation?

11:33 <FromGitter> <j8r> I hope the bindings will work on aarch64 musl, I will check it in the following weeks

12:16 <FromGitter> <naqvis> yeah Snappy is pure Crystal. XZ is bindings, as long as you have xz installed, it should work

12:17 <FromGitter> <naqvis> xz-utils comes with installation of lzma

12:36 <FromGitter> <j8r> In alpine it will be `xz-dev`, yes it should work :)

12:37 <FromGitter> <j8r> I like this format, very efficient for archives and quite widepread

12:39 <FromGitter> <j8r> I see no point nowadays using `bz2`

12:39 <FromGitter> <kaukas_gitlab> Hi! I need support of `before :all` (specific to a particular `describe`) kind of spec setup. In Crystal 0.28 (?) I achieved that by doing this: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ However, on the current release (0.31) all of my setup (`do_setup` and `do_other_setup`) runs before all specs, and then the specs run. So something seems to have changed at some point. How can I achieve `before

12:39 <FromGitter> ... :all` now? [https://gitter.im/crystal-lang/crystal?at=5d90a5eebf625112c0003e94]

12:41 <FromGitter> <j8r> You can use a block

12:42 <FromGitter> <j8r> `do_setup { it "does something" ... }`

12:44 <FromGitter> <j8r> There is also this PR for 0.31.1 https://github.com/crystal-lang/crystal/pull/8238

13:01 <oprypin> kaukas_gitlab, so might be worth ignoring 0.31.0 and going for 0.31.1 when it's out

13:19 <FromGitter> <Blacksmoke16> That won't really help since that pr just adds methods that run before or after all specs run

13:19 <FromGitter> <Blacksmoke16> Not just that specific describe block

13:31 <FromGitter> <naqvis> @j8r you shouldn't be required to have `xz-dev` installed, as dev packages are only required when you are building something, like looking into header files or generating bindings.

13:32 <FromGitter> <naqvis> that part is done, so you will require to have `lzma` library installed which is required during linking and runtime

14:28 <FromGitter> <Val> Is it possible to try Crystal program with arguments (ARGV) in carc.in ?

14:31 <FromGitter> <tenebrousedge> why?

14:32 <FromGitter> <Val> why not asking?

14:34 <FromGitter> <tenebrousedge> answer the question, please

14:36 <FromGitter> <Val> to test a program with arguments in carc.in

14:36 <FromGitter> <tenebrousedge> why?

14:36 <FromGitter> <Val> ...

14:37 <FromGitter> <tenebrousedge> what are you trying to test?

14:37 <FromGitter> <tenebrousedge> because it clearly does not support that, and because you shouldn't need to test option handling

14:38 <FromGitter> <tenebrousedge> and if you do need to test option handling, there are likely better ways

14:38 <FromGitter> <Val> Ok thx

14:38 <FromGitter> <tenebrousedge> @Val so what are you trying to test?

14:41 <FromGitter> <tenebrousedge> 🙄

16:28 <oprypin> Val, just overwrite ARGV at first :D `ARGV.replace(["a", "b"])`

16:28 <FromGitter> <Val> :-D

16:30 <FromGitter> <Val> Is it normal that `at_exit` is called before the end of the process when running specs since Crystal 0.31.0 ? See https://carc.in/#/r/7nx1 (Crystal 0.30.1) versus https://carc.in/#/r/7nwz (Crystal 0.31.0)

16:33 <FromGitter> <Blacksmoke16> yes

16:33 <FromGitter> <Blacksmoke16> see https://github.com/crystal-lang/crystal/pull/8238

16:34 <FromGitter> <Val> 👍

16:34 <FromGitter> <Val> Thanks

16:49 <FromGitter> <Val> In fact this is this commit : https://github.com/asterite/crystal-1/commit/4235af5d67000e5a77c7b050e2f575ec39ae1faa#diff-af52f0e7fc49d76624ee805c303b1f6c

16:50 <FromGitter> <Blacksmoke16> im not super up to date on the PR, but afaik its so that you can gather all the specs, filter them, then executes the ones that match

16:50 <FromGitter> <Blacksmoke16> for the implementation of `focus: true`

16:57 <FromGitter> <Val> Well it breaks my spec trick... https://github.com/Val/crun/blob/master/spec/spec_helper.cr#L14

16:58 <FromGitter> <Blacksmoke16> just wait till `0.31.1` comes out and use the after_suite method

16:58 <FromGitter> <Val> Yup...

17:02 <FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=5d90e3a373dd29627ed4081d]

17:02 <FromGitter> <Blacksmoke16> is what i landed on for now, need to add in the context tho

17:09 <FromGitter> <Blacksmoke16> some of the logic is still tied to the format, namely how to read the value from the deserialized data, rest is handled in another method

17:09 <FromGitter> <Blacksmoke16> like the exclusion strategies, and callbacks