<pmwhite>
I think I like that better anyway, since enum/union items are more or less the dual of strict fields.
<oats>
pmwhite: as in product/sum types?
<pmwhite>
Righto.
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
<andrewrk>
do we have self-hosted parsing of integer literals anywhere?
<andrewrk>
e.g. handling 0x prefixes
<andrewrk>
looks like it would be parsing the prefix followed by std.math.big.Int.Mutable.setString
stripedpajamas has joined #zig
<daurnimator>
at least in json
<daurnimator>
or not actually!
B4s1l3 has joined #zig
B4s1l3 is now known as opDispatch
aerona has quit [Quit: Leaving]
dddddd has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 260 seconds]
tracernz has quit [Read error: Connection reset by peer]
zenxhd has quit [Read error: Connection reset by peer]
tracernz has joined #zig
karrick has quit [Read error: Connection reset by peer]
hermier has joined #zig
karrick has joined #zig
zenxhd has joined #zig
stripedpajamas has quit [Quit: sleeping...]
waleee-cl has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #zig
cole-h has quit [Quit: Goodbye]
ur5us has joined #zig
wootehfoot has quit [Ping timeout: 246 seconds]
<scientes>
andrewrk, yeah, that is what I used
<daurnimator>
scientes: just use `SinglyLinkedList(void).Node`?
<daurnimator>
maybe add an options argument for null terminated vs circular?
<scientes>
no you always use circular
<scientes>
there is no reason not to
<scientes>
it is doing more than it needs to
greenfork has joined #zig
<daurnimator>
then why not change the existing to be circular
<scientes>
all of it's complexity is completely unneeded, but if you are going to fight me about it just reject the whole thing
<scientes>
you don't need generic for this
<daurnimator>
you don't need it; but some people like it as an extra feature....
ur5us has quit [Ping timeout: 256 seconds]
<mikdusan>
hmm isn't this basically an instrusive singly-linked list?
wootehfoot has joined #zig
alexnask has joined #zig
wootehfoot has quit [Quit: Leaving]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 264 seconds]
swills has quit [Ping timeout: 246 seconds]
<daurnimator>
mikdusan: yes (which we already have): main difference is circular vs null terminated.
<mikdusan>
another day yet again affirms I suck at algo :(
tdc has joined #zig
ur5us has joined #zig
recombinant has joined #zig
st4ll1 has quit [Quit: WeeChat 2.8]
FireFox317 has joined #zig
neceve_ has joined #zig
marijnfs_ has joined #zig
andrii has joined #zig
marijnfs has quit [Ping timeout: 246 seconds]
st4ll1 has joined #zig
ur5us has quit [Ping timeout: 256 seconds]
dermetfan has joined #zig
gazler_ has joined #zig
gazler has quit [Ping timeout: 272 seconds]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
marijnfs has joined #zig
FireFox317 has quit [Ping timeout: 256 seconds]
marijnfs_ has quit [Ping timeout: 256 seconds]
ifreund has joined #zig
kradnoel has joined #zig
kradnoel has quit [Read error: Connection reset by peer]
kradnoel has joined #zig
kradnoel has quit [Remote host closed the connection]
FireFox317 has joined #zig
karchnu has quit [Ping timeout: 240 seconds]
dddddd has joined #zig
swills has joined #zig
marnix has joined #zig
dermetfan has quit [Ping timeout: 260 seconds]
andrii has quit [Quit: Leaving]
babina has joined #zig
babina has quit [Client Quit]
drp has quit [Read error: Connection reset by peer]
drp has joined #zig
<FireFox317>
andrewrk, will you be streaming any time soon? :P
dermetfan has joined #zig
marijnfs_ has joined #zig
alexnask_ has joined #zig
waleee-cl has joined #zig
alexnask has quit [Ping timeout: 272 seconds]
marijnfs has quit [Ping timeout: 240 seconds]
alexnask_ is now known as alexnask
recombinant has quit [Read error: Connection reset by peer]
<companion_cube>
will there be a "lightweight" distribution of zig without anything from llvm? I'm thinking of stuff like compiling on a raspberry pi, or other very slow and small targets
<mq32>
companion_cube: i think that's planned with stage 2 to make LLVM an optional high-perf backend
<companion_cube>
sounds perfect
<scientes>
companion_cube, you want llvm for that
<companion_cube>
to target ARM, you mean?
<mq32>
target "slow and small" targets
<mq32>
because well-optimized code matters even more on them
<scientes>
yeah you still want an optimizing compiler
<companion_cube>
well depends on the program
<companion_cube>
and if you cross compile, or compile locally
<scientes>
no, you want an optimizing compiler with SSA optimizations
<scientes>
these are non-trivial projects
<companion_cube>
hm ok, I guess I need to remember that cross compilation is trivial :D
<scientes>
and also the rasberry pi is not that limited
<companion_cube>
sure, it's still a bit small for comfortably use OCaml
<scientes>
when I developed systemd I was on a ARM laptop
<companion_cube>
(which is my comfort zone)
<companion_cube>
when you what?
<scientes>
*contributed to
<companion_cube>
but surely an ARM laptop is less limited than an (old) raspi
<scientes>
yeah but its not a game boy
<companion_cube>
ah, sure
<companion_cube>
it's more about what's convenient than what's possible, since almost everything is possible (except for compiling firefox, lolol)
<scientes>
especially after the rust integration
<companion_cube>
is it really worse than C++? :)
<companion_cube>
what kills you is linking in both cases
<scientes>
companion_cube, but that cannot be fixed
<scientes>
that is just how linking works
<companion_cube>
yes, but templates (in all of c++, rust, and zig, I think?) tend to produce a lot of symbols :)
<scientes>
zig does not have that problem, as exported functions are all C abi functions
<companion_cube>
the day there are big Zig programs, this will also become a problem…
<companion_cube>
you could say the same for rust, if you use it to produce a .so it's all C ABI
<scientes>
no, zig does not have the symbol table problem, period
<scientes>
all exported symbols are explicit
<scientes>
just like C does not have this problem
<fengb>
Rust throws millions of IR at LLVM
<fengb>
And hopes that LLVM figures it out
<companion_cube>
just like C++ 🤷
<scientes>
fengb, rust and zig both excercised parts of LLVM that did not work :)
<companion_cube>
scientes: still not following. What rust exports is also all explicit, C-ABI stuff.
<companion_cube>
when used in a polyglot project, that is
<scientes>
well I haven't looked at rust's produced IR
<mq32>
<scientes> no, you want an optimizing compiler with SSA optimizations
<mq32>
note that zig uses SSAT which probably allows good optimizations as well
<oats>
fengb: heyo, I just saw your talk on emulators for the previous Showtime. Really cool stuff, the whole packed union thing was pretty enlightening :)
<fengb>
Thanks!
<scientes>
mq32, link? can't find anything about SSAT
<scientes>
fengb, my god
<mq32>
me neither, i think you have to ask andrewrk
<scientes>
cause the compiler seems to use SSA, but its only 2 phase, so it isn't round-trip, et cetera
<mq32>
rust creates horrible IR
<companion_cube>
have you tried with -O ?
<companion_cube>
it's a lot more reasonable :p
dermetfan has quit [Ping timeout: 256 seconds]
<scientes>
companion_cube, but without -O the codegen is horrible
<companion_cube>
no optimization is done, I think, so yes
<scientes>
companion_cube, it even converts to a multplication without a loop, which gcc can't do
<scientes>
companion_cube, (n-1)(n-2)/2 + n
<scientes>
the closed form of the loop
<mq32>
clang C output is still only 50% size with -O
<companion_cube>
yes yes, but rustc also does its own optimizations
<scientes>
companion_cube, it does not do the closed form thing however
<companion_cube>
mq32: I think rust emits a lot more non-aliasing statements?
<scientes>
it is not that type of compiler
<BaroqueLarouche>
how zig stage1 fare ?
<companion_cube>
I don't know much about llvm IR
<companion_cube>
but it's clearly tailored to C++
<scientes>
companion_cube, MLIR looks like the future
<scientes>
which is a llvm project
FireFox317 has quit [Ping timeout: 258 seconds]
<scientes>
swift and flang and tensorflow are using it
<fengb>
Wait, tensorflow is a compiler?
<fengb>
Apparently MLIR was invented in tensorflow too
<companion_cube>
is MLIR less… C++-y?
<companion_cube>
(in the semantics)
<scientes>
companion_cube, no, and that is my biggest problem in trying to grep it
<scientes>
it looks nice, and has a few gains over llvm
<scientes>
but still c++
<scientes>
and without a C ABI
<scientes>
and I don't understand what a tensor is
<scientes>
I need a better description of the *why*
<leeward>
scientes: tensors are like vectors in more dimensions.
<scientes>
yeah but they are a physics thing, so why are the computer people so into them suddenly
<leeward>
I don't have any idea. As far as I can tell, someone thought it made a good name.
doublex has quit [Read error: Connection reset by peer]
stripedpajamas has quit [Quit: sleeping...]
doublex has joined #zig
JimRM has quit [Ping timeout: 246 seconds]
cole-h has joined #zig
metaleap has joined #zig
dimenus has quit [Quit: WeeChat 2.8]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 246 seconds]
DrDeano has joined #zig
<DrDeano>
With my problem that I get a OOM when using ChildProcess, it works when it is in the init function for my RuntimeStep, but when moved to the make function, it throws the OOM, but can't work out why
<DrDeano>
(Context: I need to crease a build Step to run a process that doesn't return and need access to stdout)
<rooke>
Darn zig does not like `pub const StateFunction = fn (State) StateFunction;` which... I guess makes sense
<rooke>
functions are only good compile time values right?
<mq32>
that should work though
<mq32>
it's a function pointer
<rooke>
its complaining about a dependency loop
<mq32>
oh
<mq32>
yeah, true
<rooke>
I'm assuming it isn't ok with a function which returns its self
<rooke>
Which... makes sense, its just a pretty way to do finite state machines
<mq32>
yeah, true
waleee-cl has joined #zig
<andrewrk>
DrDeano, sometimes you can get OOM when you have memory corruption and so the integer that tells how many items to allocate is really big
<andrewrk>
DrDeano, have you checked your program running in valgrind?
<andrewrk>
FireFox317, I know I'm overdue for a stream :) let me see if my sister's internet service can handle it
<andrewrk>
I have some family stuff happening this weekend but potentially could show off some self-hosted progress early next week
<DrDeano>
@and
<DrDeano>
oops
<DrDeano>
andrewrk i shall try that
<gonz_>
andrewrk: Did you see the response on the LLVM mailing list?
<andrewrk>
DrDeano, to make valgrind even more effective, use std.heap.c_allocator and build with -lc
<gonz_>
Paraphrasing: Having different definitions of `_m_prefetchw` in Windows headers & LLVM headers shouldn't matter because only one should be used regardless.
<gonz_>
So, we end up using different ones when compiling with Zig. Any way not to?
<leeward>
Is there a mechanism for specifying different library paths for different targets? I have a thing I want to build for a few targets, but it depends on libraries written in C.
Biolunar has quit [Read error: Connection reset by peer]
<andrewrk>
leeward, if using build.zig, it's pretty straightforward to make different choices based on the target
<FireFox317>
andrewrk, ah thanks! Don't worry, its okay if you dont stream, but I just find them really interesting :D
<andrewrk>
gonz_, the line here might be interesting to look at: C:\Users\ricka\code\zig\sqlite-sandbox\dependencies\sqlite-amalgamation-3310100\sqlite3.c:26683
<leeward>
andrewrk: And I'd use different addLibPath calls for the different targets?
<andrewrk>
gonz_, based on this info we should be able to understand why this is happening, and then it should be clear where to go from there
<andrewrk>
leeward, right
<gonz_>
andrewrk: That line blanket includes `windows.h`
<leeward>
ok, thanks
<andrewrk>
gonz_, oh right of course, that's clear from the next line.
<gonz_>
Basically, when we finally reach `winnt.h:3324` we stumble on a redeclaration of `_m_prefetchw`
<andrewrk>
gonz_, ok well one thing to note is that clang is not finding mm3dnow.h from msvc. the conflict seems to be in winnt.h. I think it would be helpful to post this https://bpa.st/5PSA on to the llvm mailing list
<andrewrk>
my best guess is that clang headers are missing some #define that will make winnt.h not make a conflicting definition
<andrewrk>
gonz_, btw have you tried -target x86_64-windows-gnu instead of x86_64-windows-msvc?
_Vi has joined #zig
<gonz_>
As an argument to `zig build`?
<andrewrk>
there's a way to set it to use mingw-w64 instead of msvc for libc by default in your build.zig. but just as a test, yeah you could pass -Dtarget=native-native-gnu
<andrewrk>
it's possible that zig may do this by default in the future
<andrewrk>
the nice thing about using mingw-w64 for libc on windows is that zig ships with it so it works the same everywhere, microsoft doesn't mess with it, and you can cross compile for windows with it
<andrewrk>
if you get linker errors it's just some libraries that can easily be activated, let me know
<gonz_>
Is this a new option? It doesn't accept `-Dtarget=`.
<andrewrk>
I haven't seen your build.zig, are you using standardTargetOptions ?
<gonz_>
No, I had no idea that was a thing. I only have `standardReleaseOptions`
<gonz_>
I made it back in January from the basic init template
<gonz_>
Hmm, how are you supposed to use the `CrossTarget` that's returned from `Builder.standardTargetOptions`?
<alexnask>
`exe.setTarget(target);`
<gonz_>
Here's the paste with the target set to `native-native-gnu`
JimRM has joined #zig
<JimRM>
Hey so I have a question about linker scripts + assembly files!
<JimRM>
From a C project I have the following:
<JimRM>
.boot.text 0x0 : {
<JimRM>
KEEP (*(.traps))
<JimRM>
<JimRM>
. = 0x80000; /* Space for command line. */
<JimRM>
__start = .;
<JimRM>
__text_start = .;
<JimRM>
<JimRM>
KEEP(build/head.o (.text))
<JimRM>
KEEP(build/jtag.o (.text))
<JimRM>
}
<JimRM>
the problem I am having with zig, is the head.o file is not at a well known path for me to use in the linker script
<JimRM>
It's probably my lack of knowledge regarding linker scripts - but I thought I'd ask here in case anyone had a good solution?
<JimRM>
BTW head.o is compiled from head.S
<FireFox317>
JimRM, I think when just using the zig compiler (`zig build-exe` or equiv) the path will be relevant to cwd(), when using build.zig this might be from the zig-cache directory or something.
<JimRM>
Yeah, I probably shouldn't be arranging my binary using filenames but instead sections.
<JimRM>
The linker script was something I managed to get working a year ago.. and haven't dared touch since :)
stripedpajamas has joined #zig
<FireFox317>
yeah, i actually dont know if linker scripts support file names, sections it definitely does :P
DrDeano has quit [Remote host closed the connection]
metaleap has quit [Quit: Leaving]
<gonz_>
andrewrk: Setting the target to `native-native-gnu` worked, actually.
st4ll1 has quit [Quit: WeeChat 2.8]
<leeward>
Dammit stackoverflow.com, you're screwing up my search results when I'm trying to find information about actual stack overflows.
mmx8701 has joined #zig
tdc has quit [Ping timeout: 264 seconds]
mmx870 has quit [Ping timeout: 256 seconds]
mmx8701 is now known as mmx870
<gonz_>
andrewrk: Does `native-native-gnu` have some obvious downside otherwise? I would rather just rely on code shipped with Zig
FireFox317 has quit [Ping timeout: 264 seconds]
<gonz_>
It would also open up for having people you potentially teach in the future not having to install a bunch of stuff beyond the zig compiler, right?
ur5us has joined #zig
neceve_ has quit [Ping timeout: 246 seconds]
stripedpajamas has quit [Quit: sleeping...]
<andrewrk>
gonz_, nope there isn't really a downside. and yes it means you don't need msvc installed
<andrewrk>
that's why I'm considering removing msvc integration support entirely. however I'm sure some folks will bring up good things to consider when I make that proposal
<gonz_>
Do you think debugging will be affected? I finally feel like zig is very debuggable now on Windows
<gonz_>
With standard debuggers, even just normal VSCode (WinDbg?)
<andrewrk>
I don't see why that would be affected by this
<gonz_>
One of the good things that've come out of the bad is that if someone is actually doing C on Windows they probably already dislike MSVC
gazler_ has quit [Remote host closed the connection]
<gonz_>
AFAIK
<gonz_>
With the poor C99 support and all of that
stripedpajamas has joined #zig
<leeward>
I am very happy to be able to generate Windows binaries without having to install Windows myself. CI can tell me if it breaks.
Akuli has quit [Quit: Leaving]
<gonz_>
Right, I think the ability to target Windows when not on Windows is not in question
<gonz_>
It's whether or not to support MSVC as a compiler when on Windows, I guess?
<leeward>
Right, I know, I'm just fawning.
<gonz_>
My perception is that C programmers aren't fond of MSVC because historically it kind of didn't care about C
<leeward>
I have nothing to add to the MSVC debate. I'm pretty sure I've never actually used it.
<andrewrk>
gonz_, it's wether to support detecting and linking against MSVC's libc when using zig to compile C code
<gonz_>
Allright
<gonz_>
I'll probably be switching over to just specifying this target everywhere now
<gonz_>
If it means I get to just rely on stuff that's shipped with Zig
stripedpajamas has quit [Quit: sleeping...]
<gonz_>
and there are no obvious downsides outside of that
<gonz_>
In terms of defaults I think this makes a lot more sense to do, to be honest
<leeward>
Is native-native-musl not as good as native-native-gnu?
<andrewrk>
leeward, musl is a linux libc. in the discussion with gonz_ the context was windows
<andrewrk>
if you are building natively and linking libc, best to let zig auto detect your native C ABI and use that
<andrewrk>
however if you are cross compiling for linux, musl is a nice option if you want to create static binaries
<daurnimator>
a couple of things: 1. it should remain possible to write a library in zig to use from an msvc codebase (think e.g. game engine)
<leeward>
Oh, I didn't realize musl was Linux-only.
<andrewrk>
daurnimator, mingw-w64 is in fact ABI compatible with msvc
<daurnimator>
2. gnu vs musl makes a different choice for you currently: static vs dynamic linking. I think there's an issue open about dynamically linking to musl?
<gonz_>
andrewrk: What would be the long-term solution that solves this header type mismatch, by the way?
<andrewrk>
dynamic linked musl is a use case that I think has not been decided whether is in scope of zig or not
<daurnimator>
andrewrk: so then 'gnu' abi and 'msvc' abi are the same? I guess the abi is more than the abi....
<andrewrk>
gonz_, I think it's a bug in clang
<andrewrk>
I think they are missing a #define somewhere to make windows not duplicate the definition
<andrewrk>
daurnimator, yes that's right, the ABI part of the triple is more aptly named the libc part of the triple
<andrewrk>
note that we also have versions as part of it now as well
<andrewrk>
e.g. x86_64-linux-gnu.2.30
<daurnimator>
andrewrk: which is weird for pure zig code that doesn't use a libc....
<andrewrk>
The C ABI is relevant to pure zig for exported things
<daurnimator>
howso?
<andrewrk>
if you export a function, it follows the C ABI
<andrewrk>
there is not a standard C ABI, it is implementation defined. so it means encoding information about the particular libc being targeted
<andrewrk>
it's possible glibc changed its ABI over the course of its versions, although I do not have any examples on hand
<andrewrk>
anyway it's harmless to over-specify the target even if that information is unused
Biolunar has joined #zig
<daurnimator>
its sort of weird specifying e.g. gnu-2.30 when I'm writing a zig-only piece of freestanding code for a microcontroller....
<andrewrk>
use `none`
<andrewrk>
riscv64-freestanding-none
JimRM has quit [Ping timeout: 256 seconds]
slowtype1 has quit [Ping timeout: 260 seconds]
stripedpajamas has joined #zig
<gonz_>
andrewrk: How do you pass arguments to mingw via `zig build`? It turns out you need to specify the subsystem via `-Wl,-subsystem,windows`. Or is it that Zig is already supposed to but likely it's been neglected because the code path isn't very used?
<gonz_>
alternatively via `build.zig` (probably preferrably)
<gonz_>
Ah, I should specify the reason... mingw has a console window pop up regardless of whether or not you're making a win32 app
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 258 seconds]
<daurnimator>
gonz_: zig has a subsystem flag
<gonz_>
Is it available from `build.zig` & `zig build`?
<gonz_>
I assume the normal flow is that `WinMain` is detected and the subsystem set automatically
<gonz_>
If that's the case it's curious why it wouldn't for mingw
<daurnimator>
gonz_: yes. b.subsystem = ......
xackus has joined #zig
ifreund has quit [Ping timeout: 256 seconds]
<leeward>
Is there a comptime way to concatenate strings?
<leeward>
Or am I using fmt?
<leeward>
Or am I using comptime fmt?
marijnfs has joined #zig
<tgschultz>
used to be able to do it with "A" ++ "B"
<tgschultz>
pretty sure that still works actually or a lot of @compileError statemens I've written would have broken.