01:28 <gamester> Hmm. I'm doing "const Foo = builder.addStaticLibrary("Foo", null);", then "Foo.addCSourceFile", then "exe.linkLibrary(Foo)" but when running the executable it needs a libFoo.so shared library

01:28 <gamester> .so.0

01:55 <andrewrk> gamester, oh! I forgot about that.

01:56 <andrewrk> I can fix that soon. it's just a matter of sending some args to clang

01:56 <andrewrk> https://github.com/ziglang/zig/issues/2027

10:51 <gamester> No problem. Also in case you missed it: "const a: ?[*c]i32 = null" crashes the compiler.

15:47 <andrewrk> fixed

19:14 <oats> howdy! is it possible to utilize pointers that are defined in a C header library as macros?

19:15 <oats> as in, #define foo (uint32_t *)0xb1a4bla4

19:15 <andrewrk> hi oats. that may already work now. if it doesn't it's just a few improvements in translate-c.cpp away from working

19:16 <oats> sweet

19:16 <oats> I'm using the libopencm3 library

19:20 <oats> tangentally related, how's the self-hosted compiler coming along?

19:21 <oats> been a while since I've kept up with development

19:25 <andrewrk> it's on pause, blocking on a couple major language changes

19:26 <andrewrk> starting the self hosted compiler served an important purpose which was to try out using coroutines / event based programming. and indeed it needs a rewrite. so I'll do that and then pick the self hosted compiler back up

19:27 <andrewrk> the self hosted compiler is actually going to be a pretty good proof-of-concept for a server, since that's what it will be

19:29 <oats> a server?

19:29 <oats> that's interesting

19:34 <Akuli> is there an std library for dealing with paths? ideally something cross-platform

19:34 <Akuli> wooooooooot os.path.join

19:34 <Akuli> just like in python

19:40 <Sahnvour> hi, andrewrk, regarding your last comment on https://github.com/ziglang/zig/issues/2029, quote "So no matter how much the call to log gets inlined, still the return address would point to the correct thing." => how can we be sure that the next instruction isn't one resulting from the inlining of `caller_of_log` into `caller_of_caller_of_log` (for example a computation gets simplified), thus having "incorrect" debug info mapping for ou

19:42 <andrewrk> Sahnvour, I'm having trouble articulating it, but think about it like this: the machine code gets inlined, but the return address is still pointing to the same machine code

19:42 <andrewrk> the return address gets inlined too

19:48 <daurnimator> andrewrk: say you have: x = 1; add(&x, 1); warn(getLineInfo()); add(&x, 1);

19:48 <daurnimator> and `add` is inlined.

19:49 <daurnimator> and due to lack of side effects, the adds are coalesced

19:49 <daurnimator> does the warn still print the right line number?

19:49 <daurnimator> I think it does. but I'm not 100% sure.

19:49 <andrewrk> the return address is pointing to the "end" of the thing we are interested in. we don't care about what happens after getLineInfo(), we care about the source that getLineInfo() occurs in

19:50 <andrewrk> so you subtract 1 from the address before looking up the debug info

19:51 <andrewrk> this is what stack trace printing code does, since the stack contains return addresses

19:52 <daurnimator> k

19:52 <daurnimator> andrewrk: would you say https://github.com/ziglang/zig/issues/577#issuecomment-463851196 is correct then?

19:53 <Sahnvour> but as I understand it, there's no guarantee that the result of @returnAddress isn't an instruction that got inlined into the outer caller, and then debug info would give us the function one level higher than desired (in the call tree seen at compile time)

19:53 <andrewrk> daurnimator, read Sahnvour's comments in #2029

19:53 <daurnimator> andrewrk: i did.

19:54 <andrewrk> Sahnvour, I don't think that's possible. can you make a proof of concept? It should be just a dozen lines of code with std.debug.printSourceAtAddress

19:54 <Sahnvour> will try

19:55 <andrewrk> try it in debug mode with forced inlining. our debug info code doesn't handle optimizations very well yet

19:58 <__Myst__> does zig have a language server?

19:59 <andrewrk> __Myst__, no but it's planned: https://github.com/ziglang/zig/issues/615

20:00 <__Myst__> andrewrk: that last comment worries me

20:00 <__Myst__> "custom protocol" -> unusable in most editors

20:00 <oats> what's the difference between --library-path and --object?

20:00 <oats> (I still don't have a great grasp on how the linker works)

20:01 <andrewrk> __Myst__, it'll be fine. same backend, multiple protocols

20:01 <daurnimator> __Myst__: see the other bit though: having a proxy of some type that translates to LSP

20:02 <__Myst__> daurnimator: that'll be double the work though

20:02 <__Myst__> pretty easy to drop it

20:02 <andrewrk> won't be double the work. the backend is the bulk of the work. the protocol is a tiny sliver of work

20:02 <daurnimator> __Myst__: *shrug*. if they think it's less work and are willing to do it then I have no problem with it

20:02 <andrewrk> oats, --library-path gives additional search paths to the linker for --library arguments

20:03 <andrewrk> --object is for passing .o files or .a files (.obj .lib on windows)

20:03 <andrewrk> I'll clean up the CLI names for these soon

20:03 <oats> ah, ok

20:03 <__Myst__> /shrug

20:03 <oats> so I want just want to use --object /....../libopencm3_stm32f0.a

20:03 <Akuli> what is setNoRoSegment() called nowadays? or has the valgrind bug been fixed?

20:04 <andrewrk> Akuli, it was fixed in valgrind

20:04 <Sahnvour> andrewrk: my worrying is that maybe @returnAddress() will give consistent results, but that these very results would be in "ranges" of instructions that are associated with the caller function (and not the inlined one)

20:04 <Akuli> andrewrk, umm... do i need a newer valgrind if i want to valgrind my zig code?

20:04 <andrewrk> I don't know what version it was fixed in, but I have 3.14.0

20:04 <Akuli> i have 3.12.0 from my package manager :(

20:05 <Akuli> and it sure gives lots of question marks without the setNoRoSegment

20:05 <__Myst__> Akuli: it is time to compile from source

20:05 <andrewrk> valgrind is pretty straightforward to compile from source. it doesn't depend on anything afaik

20:09 <daurnimator> Akuli: what distro do you use?

20:09 <Akuli> devuan

20:09 <Akuli> i just compiled valgrind

20:09 <Akuli> lets see if it works

20:11 <Akuli> works! :D

20:11 <Akuli> thanks :)

20:17 <oats> does @cInclude recursively resolve #includes?

20:18 <Sahnvour> andrewrk: https://gist.github.com/Sahnvour/abf000581b3958882d3f493012f030f9 you can see that the @returnAddress() from inside `log` is located, as far as debug info is concerned, inside `bar` and not `foo` (from the stack trace)

20:20 <daurnimator> Sahnvour: thanks for the example :)

20:21 <Sahnvour> (the warn in foo is most probably irrelevant)

23:04 <Sahnvour> andrewrk: I'm leaving, please answer on the issue if you find some time to look at my example :) bye everyone

23:22 <oats> https://ptpb.pw/0zkH

23:23 <oats> I'm trying to compile this little program for my little arm microcontroller, an STM32F0discovery

23:23 <oats> https://ptpb.pw/Z--n

23:23 <oats> that's the build command I'm using

23:24 <oats> https://ptpb.pw/q6Ue

23:24 <oats> and here's some errors I'm getting!

23:25 <oats> I'm especially confused about it not finding the definition of "puts"

23:36 <oats> hmm, I get a different set of errors if I include the object /usr/arm-none-eabi/lib/libc.a

23:37 <oats> I don't know if those are new errors or pre-existing errors covered up by the old errors

23:37 <oats> I'm punching way above my ability level here :(