<marler8997>
the github repo says it's a mirror of the sourcehut repo, which tells me he would prefer patches there
<Nypsie>
Oh you're right, my bad. I should've read the description :)
notzmv has quit [Ping timeout: 245 seconds]
<ifreund>
how is the sr.ht web UI? I haven't seen that before
<marler8997>
a bit clunky, but seems to work, I'm trying to send a second patchset and I can't seem to find the page that does it again!
<marler8997>
ah, in the "summary" page, "Prepare a patchset" link
<ifreund>
I feel like with a few more years polish sr.ht will be pretty nice
<ifreund>
right now there are some serious UX issues, but I really love and appreciate the simplicity
<marler8997>
do you think they will add a pull-request model, where it hosts discussion and you can check the status of your change?
<ifreund>
marler8997: I think their mailing lists replace that
<marler8997>
the problem with sending an email via patchset is there's no feedback to know if my change has even been received
<ifreund>
yeah, that's an issue when sending to someone's personal email instead of a public list
<marler8997>
ah,
<marler8997>
oh I forgot to cc my own email as well, shoot
<ifreund>
they even have CI integration for public lists now
<marler8997>
correcting mistakes also seems to be problematic
<marler8997>
do I just send another patchset with my email cc'd?
<marler8997>
I suppose my email is in the commit
<marler8997>
so maybe ok
<marler8997>
it's interesting, it's half way between the old model and the new github PR model
<ifreund>
I think the goal is to have all the advantages of the old model with more modern UX
<ifreund>
as well as nice things like CI
<marler8997>
I'm unaware of the advantages the old model has
<ifreund>
correcting mistakes usually means just sending a v2 of the patchset as a whole
<ifreund>
decentralization for one
<marler8997>
yeah, I suppose that's a big one
<ifreund>
you also no longer need a browser to collaborate, just an email client
<leon-p>
sending a patch via email is something you do when your patch is pretty much done already. If you prefer to work on a public draft and get feedback along the way, like with githubs PRs, you can upload your changes to a public git repo and do a pull request via email.
<marler8997>
what's a "pull request via email" mean with sourcehut?
<leon-p>
you can do `git request-pull` and it sends an email which basically says "hey, i have changes in git@whatever.com:repo.git, please pull them".
<marler8997>
shoot, problem is I can't use the git email commands because they haven't fully implemented support behind proxies
<leon-p>
because git allows you to pull from remotes that are not your original origin
mpli has quit [Quit: Connection closed]
mpli has joined #zig
cole-h has joined #zig
notzmv has joined #zig
pretty_dumm_guy has joined #zig
<marler8997>
is it possible to get the address of the payload of an optional field?
<ikskuh>
marler8997: if you don't know a init value, you can init to @as(Payload, undefined)
<marler8997>
oh that's interesting
<ifreund>
ikskuh: that's UB, see the issue I just linked
<ifreund>
and the the one linked from it
notzmv has joined #zig
xackus_ has joined #zig
Stephanie has joined #zig
mikdusan1 has joined #zig
<ikskuh>
oh huh
squeek502_ has joined #zig
zenkuro has quit [Ping timeout: 246 seconds]
Stephie has quit [Quit: Fuck this shit, I'm out!]
knebulae has quit [Read error: Connection reset by peer]
xackus has quit [Read error: Connection reset by peer]
<ikskuh>
ifreund: then we need a var for workaround here? *thinkng*
zenkuro has joined #zig
cow-orker has quit [Ping timeout: 265 seconds]
mikdusan has quit [Ping timeout: 240 seconds]
<ifreund>
yes, you can do var x: Payload = undefined; then init x, then do const opt_x: ?Payload = x;
<ifreund>
but this is semantically a copy, so it won't work if you need pointer stability
<ifreund>
also not great if your type is large, hence #6992
squeek502 has quit [Ping timeout: 265 seconds]
Piraty has quit [Quit: ---]
Piraty has joined #zig
cole-h has quit [Ping timeout: 246 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
waleee-cl has joined #zig
Akuli has joined #zig
Piraty has quit [Quit: ---]
notzmv has quit [Ping timeout: 265 seconds]
Piraty has joined #zig
<mikdusan1>
hmm it seems running `zig build test` on linux x86_64 now requires multilib (lib32-glibc) to be installed
<mikdusan1>
I'm ok with it just note that if not installed all you get is "file not found" on a `zig test -lc -target i386-linux`
mikdusan1 is now known as mikdusan
<ifreund>
I think there are several places where that's the only error message stage2 spits out for a missing file :/ without the error return trace and poking around in the code they are pretty useless
<mikdusan>
it's such a low-level error. like a bash script with bad hash-bang path but in this case `ld-linux.so.2` is what's not found
vent has joined #zig
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
<g-w1>
is it the intended behavior that `zig cc` will need a `cc` in env?
<g-w1>
❯ zig cc test.c\n Zig attempted to find the path to native system libc headers by executing this command:\n cc -E -Wp,-v -xc /dev/null\n error: unable to create compilation: UnableToSpawnCCompiler
<TheLemonMan>
more or less, we have to detect where the system libc files are
<g-w1>
ok, i guess i can always use musl if i dont want that
notzmv- has joined #zig
<TheLemonMan>
koakuma, good news, I got lld to link a sparc64 elf linked against glibc
notzmv- has quit [Ping timeout: 265 seconds]
<mikdusan>
g-w1: is there no compiler installed, or is it that the alias `cc` doesn't exist?
<g-w1>
mikdusan: no compiler in PATH/env, and i want it that way (using nixos)
<g-w1>
honestly, it might be a good idea to fallback to musl if this happens
mpli has quit [Quit: Connection closed]
sord937 has quit [Quit: sord937]
[wtf] has joined #zig
<ifreund>
g-w1: it has been proposed to change the behavior to only link the system libc by default if linking other system libraries
<ifreund>
nobodies implemented it yet though
<TheLemonMan>
I'm not really a fan of tools silently switching behaviour like this
<ifreund>
adding a flag to toggle this would also be fine by me
<ifreund>
certianly would be more explicit
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<ifreund>
only issue: if this hypothetical flag defaulted to not linking the system libc we would still fail to link system libraries by default if the system glibc is newer
<ifreund>
(I hate glibc, I think I'm going to reformat my harddrive and install zfs and void musl)
riba has joined #zig
pretty_dumm_guy has joined #zig
pretty_dumm_guy has quit [Client Quit]
pretty_dumm_guy has joined #zig
pretty_dumm_guy has quit [Client Quit]
pretty_dumm_guy has joined #zig
Kingreil has quit [Remote host closed the connection]
[wtf] has quit [Quit: [wtf]]
dme2 has joined #zig
daex_ has joined #zig
daex has quit [Ping timeout: 252 seconds]
marler8997 has quit [Ping timeout: 240 seconds]
novakane has quit [Quit: WeeChat 3.1]
Guest82031 has joined #zig
Guest82031 has quit [Ping timeout: 240 seconds]
<andrewrk>
I'd be down for a switch. The default would be complete isolation from the system. And the switch would enable system integration
<ifreund>
ah, so you need to enable the switch to link system libs? I like that
<mikdusan>
why not make it part of target
<andrewrk>
mikdusan, what exactly are you proposing?
<mikdusan>
-target native-native-hosted
<ifreund>
I think the -target option only makes sense as a cross target currently, which only works if not depending on the system
<ifreund>
overloading that doesn't feel right
<andrewrk>
oh I see, make it one of the C ABI enum tags
<mikdusan>
I like the idea of zig doing it's thing... then we opt-out with a specific ABI
<ifreund>
I don't like how that would complicate e.g. Target.isMusl()
<mikdusan>
ifreund: if you install alpinelinux or void, I think you'll find isMuls() a bit... confusing
<mikdusan>
try runing `zig build test` on one of those :)
<ifreund>
i'm running glibc void, what happens on musl?
<mikdusan>
it will fail, iirc on not knowing whether musl means bundled musl or system musl
<ifreund>
is that newly broken?
<mikdusan>
might be an old pr for that; i'll try to find it
<mikdusan>
s/pr/issue/
<ifreund>
I had no issues building river on musl void around 0.7.1
<mikdusan>
I'll boot alpin to get a definitive answer
<ifreund>
do you see my point about how having "hosted" or "system" or whatever would complicate the std.Target implementation though?
<ifreund>
right now all the data necessary to answer questions like isMusl() or requiresLibC() is in the struct
<mikdusan>
I'd have to see all callsites of isMusl() to respond to that
riba has quit [Ping timeout: 260 seconds]
* mikdusan
will gladly check after doing this alpinelinux thing...
<ifreund>
mikdusan: the callsites are irrelevant, right now it's a simple switch
<mikdusan>
my point is how is isMusl() meaningful if I don't know whether it is a suitable answer for bundled or unbundled musl
<ifreund>
but having a "hosted" abi or similar would require std.Target to be aware of the system
<ifreund>
mikdusan: right now the native libc is only used if the os and abi fields of std.CrossTarget are null
<ifreund>
i.e. there is no Target.Abi to call isMusl() on
<ifreund>
which makes sense IMO
Akuli has quit [Quit: Leaving]
<andrewrk>
ifreund, I believe this would be in the CrossTarget / CLI parsing, and std.Target would be unchanged
<andrewrk>
so std.Target.Abi would not gain a new tag, however the -target CLI parsing and the std.zig.CrossTarget API would support the concept of "native" C ABI
<ifreund>
CrossTarget already does use os_tag == null and abi == null to mean "native" C ABI according to the doc comments
<ifreund>
what we'd need to introduce is a switch that tells zig whether or not to provide its own libc
<ifreund>
I wonder how this would integrate with a system cross toolchain
<andrewrk>
good question
<ifreund>
as far as I know, the classic C cross toolchain basically works through having an alternative sysroot with the /usr/lib and /usr/include of the target
<ifreund>
integrating with these is a use case I think zig should support, as it would make cross compiling zig programs which depend on system libraries possible
<ifreund>
which is how e.g. voidlinux does packaging for the multiple architectures it supports
<andrewrk>
yeah that's related to the libc.txt feature
<mikdusan>
on the alpinelinux issue: `zig build test-behavior` fails because it tries to run an exe linked with ld-linux-x86-64.so.2
<ifreund>
wouldn't be the awesome cross compilation experience zig can provide when not depending on system libs of course, but that's not a option due to being unable to statically link graphics libs
<mikdusan>
it could be exactly this issue: #7704
<andrewrk>
for the short term: I think 0.8.0 should only try to link system libc if there are system libraries being linked against
<andrewrk>
this will solve the use case of applications such as river, without breaking the use case of cross compilation & not depending unnecessarily on system C compiler installation, which is just a wildcard that can break anything mysteriously. after that we can clean up the CLI and model for how to communcate the target and system integration strategy
<g-w1>
thanks
<ifreund>
that sounds reasonable to me, I'll see if I can find time to implement that sometime this week
<andrewrk>
that would be sweet. no pressure; I'll take care of it if you don't find the time
tefter has joined #zig
<mikdusan>
ifreund: if I do not specify a target, what does `isMusl()` mean to you?
<ifreund>
if you don't specify a target abi, you can't call isMusl()
<ifreund>
isMusl() takes a Target.Abi
<mikdusan>
what I mean is the target is default
<ifreund>
default?
<mikdusan>
`zig build-exe hello.zig` <-- no target is specified
<ifreund>
then it's the native cpu/os/abi, so whatever the system's abi is
<ifreund>
but you still can't call isMusl() as CrossTarget.abi is nul
<ifreund>
s/nul/null/
notzmv- has joined #zig
<andrewrk>
there's a process to resolve a std.zig.CrossTarget into a std.Target
<andrewrk>
involving possibly poking around the OS and CPU
<ikskuh>
i have an aarch64 device for which i'd love to cross-compile a zig project referencing SDL2
<ikskuh>
what's the best way to do this?
<ikskuh>
just use extern "sdl2" foo(); ?
<ifreund>
ikskuh: cross compiling while linking system libraries is a largely unexplored use-case currently
<ikskuh>
okay, so there's no "way to go" :D
<ifreund>
in theory I think you need to install the relevant C cross toolchain from your distro and tell zig to use that libc/sysroot
* ikskuh
gets his machete and shovel
<ifreund>
but I haven't tried this myself
<ikskuh>
you mean "sshfs" the sysroot on my machine *rofl*
<daurnimator>
ifreund / ikskuh: if you have (x86_64) arch you could at least try installing `aarch64-linux-gnu-glibc` and linking against some piece of it?
<ikskuh>
daurnimator: that won't help when i want to link against SDL2 :D
<ikskuh>
i would still have to build the full dep tree
<daurnimator>
it won't.... but it at least lets you explore that unexplored ground
<ikskuh>
i mean, we already have a solution for windows
ur5us has joined #zig
<ikskuh>
andrewrk: would it be possible to create def files for linux libraries as well?
Bernstein has quit [Remote host closed the connection]
nullheroes has quit [Quit: WeeChat 3.0]
nullheroes has joined #zig
cole-h has joined #zig
wilsonk has quit [Quit: Leaving.]
wilsonk has joined #zig
wilsonk has quit [Client Quit]
wilsonk has joined #zig
wilsonk has quit [Ping timeout: 240 seconds]
wilsonk has joined #zig
wilsonk has quit [Ping timeout: 240 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wilsonk has joined #zig
nathanael has quit [Remote host closed the connection]