<ianlilleyt>
I'm interested in using build.zig for a custom build system that doesn't use std's builder. Is there a way to remove the Builder param from the build function?
<ianlilleyt>
for reference, here's the error: /Users/ianlilley/Documents/Zig/lib/zig/std/special/build_runner.zig:147:42: error: expected 0 arguments, found 1 builtin.TypeId.Void => root.build(builder),
<ianlilleyt>
and the code: pub fn build() void {}
squiddlebit has quit [Quit: WeeChat 1.9.1]
<ianlilleyt>
similarly, is there a way to pass custom command line arguments to build.zig without going through the std builder?
<ianlilleyt>
basically, im trying to use build.zig as any other zig file, but instead executed at compile time
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 272 seconds]
ajhager has joined #zig
darithorn has joined #zig
st4ll1 has quit [Remote host closed the connection]
st4ll1 has joined #zig
_whitelogger has joined #zig
st4ll1 has quit [Ping timeout: 245 seconds]
st4ll1 has joined #zig
ajhager has quit [Ping timeout: 260 seconds]
hio has quit [Quit: Connection closed for inactivity]
<mikdusan>
no longer top. some shenanigans going on; comments were moved to a _newer_ post which effectively killed its rank
<hryx>
weird, what happened there?
avoidr has joined #zig
avoidr has quit [Quit: leaving]
ManDeJan has joined #zig
brakmic has joined #zig
marmotini_ has joined #zig
brakmic has quit [Ping timeout: 245 seconds]
brakmic has joined #zig
xentec has quit [Quit: memento mori]
fubd has joined #zig
<Sahnvour>
ManDeJan: thank you for doing the first :) helped a lot
ManDeJan has quit [Ping timeout: 272 seconds]
fubd has quit [Ping timeout: 260 seconds]
brakmic has quit [Ping timeout: 246 seconds]
brakmic has joined #zig
brakmic has quit [Ping timeout: 272 seconds]
FireFox317 has joined #zig
brakmic has joined #zig
brakmic_ has joined #zig
brakmic__ has joined #zig
brakmic has quit [Read error: Connection reset by peer]
<FireFox317>
Does someone know how we are going to solve `#define` in translate-c stage 2? Is it gonna be similar to `process_preprocessor_entities` in translate_c.cpp?
brakmic has joined #zig
brakmic_ has quit [Ping timeout: 268 seconds]
brakmic__ has quit [Ping timeout: 246 seconds]
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
st4ll1 has quit [Ping timeout: 272 seconds]
IntoxicatedHippo has joined #zig
<IntoxicatedHippo>
In C structs and unions can be nested like this, is there a way to do something similar in zig without declaring the struct outside of the union? https://hastebin.com/iraxukaxuq.c
st4ll1 has joined #zig
<BitPuffin>
IntoxicatedHippo: you could can nest struct declarations
<IntoxicatedHippo>
I can declare b as a const inside A, but there doesn't seem to be a way to reference B if I declare it like this: https://hastebin.com/qazacoyepe.zig
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 245 seconds]
<tgschultz>
IntoxicatedHippo, you can, it's just convoluted: @TypeOf(@field(A(undefined), "B")){ .x = 1, .y = 2, };
ManDeJan has joined #zig
<BitPuffin>
IntoxicatedHippo: it would probably just be easier to do const InnerStruct = struct { ... }; b: InnerStruct; in your union
<tgschultz>
yeah, that's definitely preferred
<tgschultz>
Oh way, it's a union? A tagged union? Then we have std.meta.TagPayloadType(A, A.B)
<tgschultz>
which could have a minor improvement now with enum literals but I haven't gotten around to fixing it.
brakmic_ has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
<BitPuffin>
does anyone know a good example of compiling just C code with build.zig
<BitPuffin>
I started doing a translation from C to zig but I want to have it built and working untouched first
brakmic_ has quit [Ping timeout: 248 seconds]
st4ll1 has quit [Ping timeout: 248 seconds]
<FireFox317>
BitPuffin: `addCSourceFile` maybe?
<BitPuffin>
yeah but what about for the file with main?
<BitPuffin>
when you create the exe
<BitPuffin>
like when you run addExecutable
<BitPuffin>
do you put a C file there?
<BitPuffin>
an empty zig file?
<FireFox317>
Ah only c files without any zig code?
<BitPuffin>
so judging by this you should just addExecutable and pass null
marmotini_ has joined #zig
kristoff_it has joined #zig
<samtebbs>
Sahnvour: Have you tried removing `inline`? I've seen that cause compiler problems before
<samtebbs>
BitPuffin: Ah ok, nice
<Sahnvour>
samtebbs: it has to be there, so not really (or maybe with uglier and slower code)
ianlilleyt has joined #zig
ajhager has joined #zig
wilsonk has quit [Ping timeout: 272 seconds]
nifker has joined #zig
wilsonk has joined #zig
ianlilleyt has quit [Ping timeout: 260 seconds]
marmotini_ has quit [Ping timeout: 246 seconds]
Akuli has joined #zig
marmotini_ has joined #zig
IntoxicatedHippo has quit [Quit: Leaving]
darithorn has joined #zig
bheads_ has joined #zig
bheads has quit [Ping timeout: 268 seconds]
bheads_ is now known as bheads
<samtebbs>
Sahnvour: Can you try removing it for testing purposes though? It may be the cause of the segfault
<darithorn>
does zig fmt use its own parser?
ManDeJan has quit [Ping timeout: 244 seconds]
<samtebbs>
darithorn: It does indeed: src/parser.cpp
<andrewrk>
samtebbs, zig fmt uses the self hosted parser
<andrewrk>
which is std/zig/parse.zig
<Sahnvour>
samtebbs: removing it leads to a compile error, but yes I suspect like you that it's involved in the crash
<Sahnvour>
what happens is zig ends up with the break instruction that points to a basic block without a llvm_block
<darithorn>
okay i thought i remembered it being the case i just wasn't sure
<Sahnvour>
didn't find yet why
<Sahnvour>
andrewrk: if you maybe have a minute to look at it
<samtebbs>
darithorn, andrewrk: Oh sorry, I didn't register that you wrote 'zig fmt'
<darithorn>
samtebbs np
<darithorn>
would using zig as a config format be viable? or at least using the same syntax?
<andrewrk>
Sahnvour, let me finish up this other thing I'm working on and then take a look
<andrewrk>
darithorn, I think a normal configuration format would be better
<darithorn>
i'm trying to use zig build to build a C project but it uses a combination of Makefiles and config files that generates a new Makefile that actually builds the project
<darithorn>
the config files turns on/off certain features
<andrewrk>
if you're already using make, you might consider using make to build your zig code too
<andrewrk>
oh, I see - that's less of a configuration format and more of simply generated code from config. that's reasonable
<darithorn>
yeah.
<darithorn>
and the reason i wanted to use zig build over make is just for ease of cross compiling and all that fun stuff
<darithorn>
and eventually i want to start porting it to zig but that's a topic for another time
<andrewrk>
yeah fair enough
<samtebbs>
Sahnvour: It's probably worth opening an issue for that if there isn't one already :)
<ltr->
do you think it would be woth to implement an stand-alone lsp for zig?, i was working on a rewrite of quake (ezquake to be more precise) , but im not productive yet on zig so, lsp would be a nice start to get used to the language.
<andrewrk>
my plan is to implement it only in the self hosted compiler
<emekankurumeh[m]>
i did a little bit of work implementing a dart analyzer-like lsp for zig
<ltr->
emekankurumeh[m]: using the c++ compiler?
<emekankurumeh[m]>
no, it was all in zig
wootehfoot has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<emekankurumeh[m]>
andrewrk: in your segfault handler are all the functions you call signal safe?
<andrewrk>
good point. there's a better way to solve this though, because we have 1 trick up our sleeves
<andrewrk>
which is that the segfault handler is going to crash
<andrewrk>
so we can simply mask all signals in the handler
<emekankurumeh[m]>
does it matter though because we abort?
<emekankurumeh[m]>
i see
<BitPuffin>
andrewrk: when you did the compile lua for webassembly with zig did you just compile the lua C code or did you do any porting?
<andrewrk>
BitPuffin, I chose a subset of the C files to build
<andrewrk>
I don't think I made any source modifications though
<BitPuffin>
alright, thanks for answering :)
mawaldne has joined #zig
<BitPuffin>
I'm a bit curious about the while loops in zig. Is there a specific reason why (unless we use a block) we can't really get a loop counter variable that doesn't outlive the loop
<BitPuffin>
I'm thinking maybe it's to discourage that kind of loop
<andrewrk>
it's the same problem as any local variable in a function
<andrewrk>
all local variables in zig have the problem that their scope won't end without explicitly putting them in a block
<BitPuffin>
yeah but other languages make it easy for you to just have it in the for loop or something
<andrewrk>
zig is either going to solve this problem for all local variables or none, but not just the loop iteration variable
<andrewrk>
anyway let's talk about it after generators are implemented (or rejected)
<BitPuffin>
I see
<BitPuffin>
didn't know generators were on the way (maybe), that's gonna make things easier
<emekankurumeh[m]>
generators through coroutines/continuations? is there a proposal open for that?
darithorn has quit [Quit: Leaving]
<via>
anyone used zig freestanding on a cortex-m4? possibly with libopencm3?
<via>
i'm playing around, and tried building a freestanding binary for target thumbv7em-freestanding, but i get an error 'TODO populate this table with stack pointer register name for this CPU architecture'
<andrewrk>
emekankurumeh[m], I don't think generators have their own issue yet
<andrewrk>
via, do you know what the stack pointer register name is for that CPU architecture?
<via>
there are two, msp and psp, depending on the mode, iirc
<andrewrk>
what mode?
<via>
i'll have to look, but there's a system mode and user mode, and for example i think interrupts will use msp by default. i'd need to check which settings are default
<andrewrk>
adding the register to that table in zig will make @newStackCall work. otherwise you can avoid the TODO by avoiding that builtin
<via>
i'm pretty used to having newlib on these, and it handles the initialization
<via>
okay, i can probably avoid the builtin
<via>
i think hardware initializes them to at least be usable
<andrewrk>
or we can improve zig by adding the register, if we know what it's called
squeek502 has quit [Ping timeout: 245 seconds]
<via>
i'm at work right now and can't really look, but i imagine having the two different stack pointers might make that more complicated?
<andrewrk>
yeah that's good to know about. the API of that builtin might need to get adjusted in lieu of this new information
<via>
i'm about 95% sure that by default psp is for normal code and msp is for interrupts, dependent on a flag in psr, i can check tonight
<andrewrk>
or maybe the code generated can be improved, to detect the mode
<andrewrk>
if it detected the psr flag, then everything can "just work"
<via>
cool, i'll double check that tonight
<via>
if i link with libopencm3, it owns the start functions and sets all that up anyway (calls main), so probably not an issue for me personally if i can get that to work
<via>
guessing its needed for something like coroutines to work though
<andrewrk>
I'm in the middle of reworking coroutines, but neither the status quo implementation or the new implementation depend on @newStackCall. they're much more lightweight than that
<andrewrk>
they're stackless. maybe better called "continuations" than "coroutines"
halosghost is now known as hg
<via>
cool, i hadn't actually looked at them, its just the only reason i know anything about msp/psp is last year i wrote a really crappy lightweight multithreading scheduler for that chip. stackfull.
<gonz_>
What does the current timeline for coroutines look like?
<andrewrk>
gonz_, so far, on schedule for the 0.5.0 release cycle
<emekankurumeh[m]>
not to be pushy, but when is the next round of PR review?
<andrewrk>
emekankurumeh[m], today! I just completed the oldest PR, moving on to next oldest
<emekankurumeh[m]>
nice
<gonz_>
andrewrk: Great to hear. :)
<emekankurumeh[m]>
with result location if i return a struct field from an initialization of the the struct would a @fieldParetntPtr be UB?
<andrewrk>
emekankurumeh[m], if you paste some code I'll walk you through how the result location semantics work
jjido has joined #zig
<emekankurumeh[m]>
hmm, it might be a while. looking closer at my code i'm kinda confused by what i'm trying to do
<andrewrk>
emekankurumeh[m], the way to think about it is from "left to right" or "outside to inside" expressions. e.g. with `var foo = ...;` start with "foo" as the "result location" and then trace the result location all the way to the innermost thing
<andrewrk>
each expression has a way that result locations propagate. array and struct initializations are able to propagate the result location to the fields/elements
<andrewrk>
`return` propagates the return value result location
<andrewrk>
however *parameters* to functions create new result locations (on the stack) for each parameter
<andrewrk>
each variable declaration is its own result location-
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
dimenus has joined #zig
Akuli has quit [Quit: Leaving]
Akuli has joined #zig
Akuli has quit [Remote host closed the connection]
<donpdonp>
im trying to populate that from string.len and string.ptr
<donpdonp>
but im getting hung up on how to deal with 'cast discards const qualifier'
<donpdonp>
i realize that string.ptr is const and mv_data is not const. i know the function using this struct does not modify the mv_data, so i want to force the situation
<donpdonp>
i thought "@ptrCast(*c_void, value.ptr)" would handle it but nope
<andrewrk>
where is this struct declared?
<donpdonp>
in a C .h file
<donpdonp>
what I pasted is the zig translation from zig-cache/
<donpdonp>
the lmdb database, to be specific
jjido has joined #zig
<andrewrk>
donpdonp, what's going on here is that it's not actually a mutable pointer. in the h file it's incorretly specified as `void *` when it should really be `uintptr_t`. given that you (I'm guessing) can't change the .h file you'll have to work around the type being incorrect
<andrewrk>
like this: @intToPtr(?*c_void, @ptrToInt(value.ptr))
<donpdonp>
hmm, ok thx.
<donpdonp>
some googling says 'uintptr doesn't represent a pointer to an unsigned integer, as *uint, but is a type to treat a pointer as an unsigned integer, to ease some specific arithmetic operations mostly.' TodayILearned
<andrewrk>
uintptr_t is equivalent to zig's usize
<companion_cube>
on all platforms‽
<andrewrk>
yes
<companion_cube>
ok, I thought sometimes the sizes actually differed
<andrewrk>
ok but at first I thought this was a `void * context` sort of situation, but looking again it looks more like a slice, as in mv_size is the amount of bytes
<andrewrk>
if that's the case then maybe it actually is supposed to be mutable? I'd have to look at the API
<donpdonp>
yes it looks like lmdb wishing it was written in zig :)
<donpdonp>
mdb.put(key,value); should just store the value in the db file without modifying it.
<andrewrk>
I think the API is missing a `const` on the type
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
I'm guessing they're using the same type whether or not mv_data is const. so that means sometimes having to hack around the type system.
fubd has quit [Remote host closed the connection]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
<dimenus>
andrewrk: does translate-c expand macros (eg for OpenGL function pointers)
<dimenus>
or rather, should it?
<andrewrk>
dimenus, yes libclang has full preprocessing support
<dimenus>
hmmm, no warnings
<andrewrk>
however that is easy to confuse with the fact that if the macro *is the API* then zig has to do the text processing and decide how to translate that
mawaldne has quit [Ping timeout: 260 seconds]
<andrewrk>
which is fundamentally heuristics based
ky0ko has joined #zig
<emekankurumeh[m]>
would the more zig approach to iterators be a rust-like iterator api or a generator based one?
fubd has joined #zig
marler8997 has joined #zig
brakmic has quit []
<andrewrk>
the rust language is iterator-aware. I don't have plans to make zig language iterator-aware
<companion_cube>
you can still have a standard abstraction for it, right?
<andrewrk>
sure
<companion_cube>
(afaict the only thing baked in rust is the for loop, which is convenient)
<marler8997>
pretty much the same thing in D, but I think andrewrk will respond with zig's idea of no hidden code/allocations
<marler8997>
since zig is already getting anonymous structs, maybe that could already be leveraged?
<emekankurumeh[m]>
yes, we still need that userland function. I was writing one but I ran into some errors when getting the typeInfo for a function
<andrewrk>
emekankurumeh[m], oh, you should be able to remove the "TODO make the compiler even more lazy. don't emit "use of undeclared identifier" errors"
<andrewrk>
I did the make it more lazy thing
<emekankurumeh[m]>
actually nevermind, it's fine for now. I'll open a new pr with that function
<emekankurumeh[m]>
it'll be a little bit before I can make that change
<andrewrk>
I'll wait for #2799 to be done so that #2787 can be improved
<Sahnvour>
andrewrk: what was the rationale behind using `inline` keyword in front of comptime while/for loops?
<andrewrk>
the other keyword I considered was `unroll` but that's an unusual keyword, and inlining a function / inlining a loop is analagous
<andrewrk>
note that `comptime` is not correct since the loop expression does not have to be comptime-known. just the iterator variable and branching
<Sahnvour>
yeah
<emekankurumeh[m]>
is unalias currently unimplemented?
<andrewrk>
`noalias` is implemented, is that what you're talking about?
<Sahnvour>
I was thinking `unroll` would better express the intent, as `inline` has (imo) a quite different meaning for functions
<andrewrk>
Sahnvour, I invite you to open a proposal for that. even if we don't end up doing it, then the rationale will be documented. I didn't find the rationale documented when I searched for it a minute ago when you asked
<Sahnvour>
granted that, in zig, inline is a strong directive at least, unlike inc/c++, so that uncertainty about its effect is a non-issue
<Sahnvour>
ok
<andrewrk>
Sahnvour, what was the issue you wanted me to look at?
<andrewrk>
donpdonp, zootdeck is ok since the result location branch merge?
<andrewrk>
emekankurumeh[m], there are no safety checks for noalias, but it does make it into llvm IR attributes
<Sahnvour>
it's nothing urgent, but I had the impression it might be simple to fix
<emekankurumeh[m]>
I saw a comment about implemented safety for it in memcpy in it.cpp so I wasn't sure
<andrewrk>
there are a couple research issues open for aliasing
kristoff_it has joined #zig
<donpdonp>
andrewrk: my zig is june-28, should i replace it with the current HEAD?
<donpdonp>
the june28 ver is building/working fine with zootdeck
Tetralux has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
<andrewrk>
donpdonp, result location was merged Jun 26 so I think you're good
st4ll1 has joined #zig
hafer is now known as oats
<hryx>
andrewrk: happy Monday 'n' good luck with all those PR reviews. curious what you'll think of the translate-c one when you get to it (no rush). some mysterious Windows failures that Sahnvour was helping me debug
<andrewrk>
hryx, thanks!
hg has quit [Quit: WeeChat 2.5]
<scientes>
yes, that you for everything
kristoff_it has joined #zig
<emekankurumeh[m]>
Monday?
kristoff_it has quit [Ping timeout: 258 seconds]
<hryx>
wow
<hryx>
what year is it even
fubd has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
marmotini_ has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
ltr- has quit [Quit: leaving]
kristoff_it has quit [Ping timeout: 245 seconds]
marijnfs has quit [Quit: WeeChat 2.4]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fubd>
using zig build-lib to make .wasm files via -target wasm32-freestanding is amazing!
<fubd>
a snag I ran into:
<fubd>
any code that panics sets the browser into an infinite loop
<fubd>
making it VERY hard to figure out where the problem is.
<andrewrk>
you can override that with your own panic function, or you can contribute a better default to the std lib
<andrewrk>
maybe @breakpoint() would be good?
<fubd>
ok, looks like i need to finally build from source
<andrewrk>
you don't need to build from source to provide your own panic handler
<fubd>
yes, especially in browsers which don't handle hung processes gracefully at all
<shachaf>
Browsers tend to handle infinite loops very badly.
<andrewrk>
just put `pub fn panic(msg: []const u8, error_return_trace: ?*builtin.StackTrace) noreturn {` in your root source file
<fubd>
ah, even if I'm just building a .wasm file?
<fubd>
gotcha
<shachaf>
I think emscripten throws a JavaScript exception which is probably reasonable?
<shachaf>
What does @breakpoint() do?
<andrewrk>
I haven't tested it with wasm in the browser, but ideally it would bring up the debugger
<andrewrk>
fubd, play around with some better panic behavior and let me know what you think would be a better default
<shachaf>
Oh, does WebAssembly have a breakpint instruction?
<fubd>
will do. looks like i need to do SOME kind of abort to keep the type checker happy with the "noreturn" part of the function's type
<shachaf>
Oh, 0x00, unreachable.
<shachaf>
That sounds reasonable.
<andrewrk>
I'd try while (true) { @breakpoint(); }
<fubd>
andrewrk: that works perfectly
<andrewrk>
fubd, noted, thanks, in that case I'll update the std lib right now
<fubd>
wasm-2231b9a6-1:15 Uncaught (in promise) RuntimeError: unreachable at panic (wasm-function[1]:31) at doSomethingThatPanics (wasm-function[2]:304) at http://localhost:8080/index2.html:9:34
<fubd>
although I'm confused about why the RuntimeError up in the javascript console says "unreachable"
fengb has joined #zig
<fubd>
i mean, i understand what unreachable is
<andrewrk>
based on what shachaf said, I believe @breakpoint() lowers to the "unreachable" instruction, which has that behavior when it gets run
<shachaf>
Oh, you go through LLVM, which has a way to emit breakpoints.
<andrewrk>
this is actually quite elegant when you think about it because if you were to use zig's `unreachable` statement, in debug mode that would call panic and end up literally outputting the unreachable wasm instruction
<fubd>
ah I see :)
<andrewrk>
I'm going to go ahead and make this the default on all freestanding targets, I think that should be OK
<andrewrk>
fubd, ok it's pushed. new build should clear the CI within 3-4 hours
<andrewrk>
thanks for the report :)
<fubd>
andrewrk yep! will keep you posted on any other thorny bits in this wasm/gamedev experiment. thx for the quick answer
<andrewrk>
np
kristoff_it has joined #zig
<fengb>
I'm having trouble exporting `?[*c]u8`
<fengb>
Oh... is [*c] automatically nullable?
kristoff_it has quit [Ping timeout: 272 seconds]
<andrewrk>
exporting? use a normal pointer
<fengb>
Shouldn't I mark it as null terminated?
<daurnimator>
fengb: we don't have null terminated yet