<ifreund>
there are also links with comments on the front pages of hacker news/lobsters
<marler8997>
hey, when I build on my 64-bit linux NixOS linux machine, the elf interpreter is set to the correct one in the nix store, but when I set an x86-64-linux-gnu target, I get an absolute path interpreter that doesn't exist on NixOS?
<leeward>
WTF?
<marler8997>
yeah anyone heard of this?
<leeward>
Non-compete clauses in employment contracts are...controversial. Depending on jurisdiction, also sometimes illegal.
<leeward>
Sorry marler8997, I was responding to the Zen thing. I don't know anything about NixOS.
<marler8997>
oh ok, well I'll creating a reproducible issue
SimonNa has quit [Remote host closed the connection]
<marler8997>
As I'm filling out this issue, I have a feeling that there is no solution to this
<marler8997>
I think the linker is setting the interpreter to /lib64/ld-linux-x86-64.so.2, because that is the most common one it can set...
SimonNa has joined #zig
<leeward>
I have noticed some hard coded paths in llvm. I wonder if you're bumping up against one of those.
<andrewrk>
marler8997, I can explain this
<marler8997>
...
<andrewrk>
there's no bug here, this is an advanced feature of zig working well for you
<andrewrk>
when you compile for the native OS, zig figures out what your dynamic linker is, even if it's a weird one like on nixos
<andrewrk>
when you cross compile, zig has to pick by default the "standard" dynamic linker path. if you want it to work on nixos then you have to override with the --dynamic-linker option
<marler8997>
> I understand that a fix for this issue might prove difficult. There's no way to set an absolute path to a loader that will work on all distributions. The only fix I can think of is to never use an ELF interpreter. We we need dynamic libraries, we could compile the loader into the final executable...or maybe a better solution would be to include startup code that looks for the system loader that works on as many distributions as we
<marler8997>
can support.
<andrewrk>
ah I see you're trying to come up with an innovative solution to this. cool!
<andrewrk>
I just wanted to make it clear that the behavior is working as designed so far
<marler8997>
well I'm glad you confirmed what I thought it was
<marler8997>
I did have to think about it for a bit before I realized that's what it was
<andrewrk>
it is pretty neat how zig figures out the native dynamic linker path though right? that's a "just works" experience on nixos
<marler8997>
yeah...how does it do that?
<andrewrk>
zig actually looks at its own dynamic linker to figure it out :D and if zig itself is statically linked then it looks at /usr/bin/env (which is highly portable because it's commonly used in shebang lines)
<marler8997>
off the top of my head, I would try to go up my process tree and find the first ELF that uses it
<andrewrk>
ooh going up the process tree is a neat idea
<marler8997>
ooo, gotta run, thanks for the explanations though
<andrewrk>
I think this issue is related to the one for video games that work on multiple distributions
<marler8997>
I'm running into issues with illegal instructino because of unaligned access
<andrewrk>
e.g. loading graphs drivers
<marler8997>
I was thinking of using the generic target to see if that would make the final exe more lenient on unaligned access
<marler8997>
(compiling the doom source code, thinking about porting it to Zig for fun)
yorickpeterse has joined #zig
a_chou has quit [Ping timeout: 264 seconds]
supercoven has quit [Ping timeout: 256 seconds]
wootehfoot has joined #zig
Barabas has joined #zig
<andrewrk>
it would be interesting to try to get `zig translate-c` able to do it :)
<andrewrk>
I think it's mostly there
<marler8997>
would be a cool test case, of course, I'd still do the port by hand for educational purposes
a_chou has joined #zig
marnix has quit [Ping timeout: 240 seconds]
mwgkgk has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
a_chou has quit [Ping timeout: 272 seconds]
<Barabas>
Why does `struct{ usingnamespace OtherStruct }` not 'use'/transplant the fields of `OtherStruct` in the new struct?
<ifreund>
why should it? fields are not decls
<ifreund>
usingnamespace only "transplants" public decls
<Barabas>
Ok, yeah that makes sense. Too bad.
<ifreund>
not sure i agree on the "too bad," that sounds like it would get very confusing
<Barabas>
Well, too bad that my idea didn't work out.
<ifreund>
if you want to include all the fields of another struct in your struct just add it as a field
<Barabas>
I thought I could inherit the fields that way.
<Barabas>
Yes, but that struct is passed to another class which does a struct -> structure of arrays conversion and that only happens for the top level fields.
<Barabas>
(I wanted to build a hashmap which can have more than one value tied to the key on top of that)
Akuli has quit [Quit: Leaving]
Trastos has joined #zig
ur5us has joined #zig
vramana has quit [Ping timeout: 256 seconds]
Trastos has quit [Ping timeout: 240 seconds]
xackus has quit [Ping timeout: 258 seconds]
<Barabas>
I rolled my own solution and it works. I'm actually surprised. It both feels very hacky and kinda cool that it's relatively easy in Zig to do these things.
<andrewrk>
:)
a_chou has joined #zig
wootehfoot has quit [Quit: Leaving]
dermetfan has quit [Ping timeout: 240 seconds]
dermetfan has joined #zig
dermetfan has quit [Ping timeout: 272 seconds]
<yorickpeterse>
andrewrk: what are you using for presenting the Zig API docs? Is it something custom built?
<yorickpeterse>
In all seriousness, did you ever consider Sphinx? I'm considering using it myself for generating some API docs, but it's been like 10 years since I last used it
<yorickpeterse>
Ah thanks
<andrewrk>
for our case I think a custom made code is the right tool for the job
<yorickpeterse>
Ah gotcha, thanks :)
<andrewrk>
part of the role that zig plays is to help your toolchain have fewer dependencies so that your projects are more portable
<andrewrk>
so it helps when zig itself doesn't depend on too many third party projects
<yorickpeterse>
Yeah that makes sense, which is why I'm a bit unsure about Sphinx: it's a bit of a beast
<yorickpeterse>
This is a recurring issue with basically any modern documentation generator, sadly
<yorickpeterse>
I thought about integration my documentation into the corresponding website (which is already about as vanilla as it gets), but that makes the docs less portable (e.g. no PDF output)
ccube has joined #zig
<ccube>
In the 0.6.0 documentation, tuples are not documented, var_args is still referred to, and the form tuples take in function calls is not as indicated in the issue discussion or stack overflow.
<daurnimator>
ccube: I don't think tuples existed in 0.6.0
<daurnimator>
they've been added since.
<ccube>
Well that's the only way print works!
<ccube>
And 0.6.0 is the most recent pre-built release
<torque>
the master branch documentation also does not appear to document tuples
<torque>
the only place "tuple" appears in that document is in the description of the "for" keyword
<ccube>
Yep
<ccube>
Kept trying print("{}: {}\n", [i, arg]) and got error: expected token ']' and found ',' --- finally guessed that you folks had silently changed the syntax.
<ccube>
And changed it to .{i, arg} which worked.
<ccube>
By the way, does this use of "." with no identfier on the left hand side have a defined meaning, an implied context perhaps?
<ifreund>
it's the syntax used for anon struct literals and tuples
Barabas has quit [Ping timeout: 245 seconds]
<ccube>
OK, what about "_" used as a variable on the left hand side have an explicit meaning, or just a convention for dummy variables?
<ifreund>
it just discards the value yeah, though it is language level and not just a convention
<ccube>
Is it documented somewhere?
<ifreund>
zig doesn't let you ignore return values so this is needed
<ifreund>
not sure :/
traviss_ has joined #zig
<ifreund>
I mean it's certainly used in the examples in the docs, and it's pretty intuitive syntax imo