<tundrax>
Hi. I'm new to zig and was curious about the syntax, particularly leading "dot" notation.
<tundrax>
In async tutorial there is a line for switching io mode `pub const io_mode = .evented`. I found `@ifDecl(root.io_mode)` check inside std/io.
<tundrax>
As "Feature Highlights" documentation stated "There is no hidden control flow" as a convention, this code above seems unconventional, because it is unclear where `.evented` is coming from. First I thought it was a symbol kind of something.
layneson has quit [Ping timeout: 256 seconds]
<tundrax>
Should io mode switching be tied to a constant/variable name?
<waleee-cl>
is eg. the rust way with a separate async std-lib better?
<andrewrk>
nah
<tundrax>
I think zig is better in this matter, but the syntax could be something like `std.io.setMode(.evented)` more obvious.
<tundrax>
If we can not change io mode throughout the program eg. set only once in main.
<andrewrk>
that would not work because it must be set at compile time not at runtime
<andrewrk>
the standard library needs to perform conditional compilation based on this value
<fgenesis>
so this .evented is probably defined somewhere global
<andrewrk>
the pattern of accessing the root source file like this should be used carefully - as you noted it can be surprising
<tundrax>
I felt a little confused how constant binding is accessing the `io.Mode` enum value `.evented` in the root scope.
<andrewrk>
the other places this @import("root") pattern is used is for std.log and the default panic handler
<tundrax>
Also in the `std/io` code there is `@ifDecl` check for `root.event_loop`, which can cause unexpected behavior if user names one of his variables `event_loop` not wishing to switch io mode.
<andrewrk>
you would have to make it `pub` in your root source file (next to main())
<andrewrk>
that would hardly be an accident
<andrewrk>
plus the type would have to match
<andrewrk>
I really don't think that is a concern
<fgenesis>
does anything aside from main() and those magic config vars need to be public in the root src? i don't think so
<tundrax>
I see. Just starting learning zig, these root declarations were not explained in the documentation.
<tundrax>
Thank you for clarifying.
<andrewrk>
docs are going to be rough until the language & std lib stabilize
<ifreund>
there's gotta be a better way to do this though
ur5us has quit [Ping timeout: 240 seconds]
tundrax has joined #zig
xackus_ has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mq32 has joined #zig
marnix has joined #zig
mokafolio has joined #zig
marnix has quit [Read error: Connection reset by peer]
waleee-cl has joined #zig
neceve has joined #zig
marnix has joined #zig
mokafolio has quit [Quit: Bye Bye!]
marnix has quit [Read error: Connection reset by peer]
mokafolio has joined #zig
tundrax has quit [Ping timeout: 245 seconds]
earnestly has quit [Ping timeout: 246 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
tundrax has joined #zig
earnestly has joined #zig
<tdeo>
ifreund: what is it trying to do?
<tdeo>
handle enums? check for enums and use @TagType
<ifreund>
convert from the array of wl_arguments to a struct
<tdeo>
what would/would not be UB specifically?
<ifreund>
it's the @bitCast() and @ptrCast() on maybe not the active extern union fields that are kind sketchy
<ifreund>
but I think they're sound
<tdeo>
i think extern unions can be used to reinterpret memory
<ifreund>
yeah they can
<ifreund>
but it feels like there should be a cleaner way to do this
<ifreund>
still though, it's a lot more concise than the C version :)
<tdeo>
that's for sure
<ifreund>
I guess all that's left for the client bindings is to make the scanner output the code now that I've figured out roughly what it should look like
<ifreund>
oh and hope that opaque{} gets merged :D
<tdeo>
if you want the build script to not depend on c
<tdeo>
the parser is not very clean but it's short and works on non-complex xml
<ifreund>
hmm, it would be very nice if the scanner was just part of the build.zig instead of an external program
<ifreund>
I'll probably stick with the expat impl for now as it already works and was minimally painful, but that's definitely something to consider for the future
<tdeo>
yeah
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
kristoff_it has joined #zig
omglasers2 has joined #zig
albertito has joined #zig
marijnfs has joined #zig
tundrax has quit [Remote host closed the connection]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
sawzall has joined #zig
LanceThePants has quit [Ping timeout: 258 seconds]
LanceThePants has joined #zig
sawzall has quit [Ping timeout: 246 seconds]
deXtoRious has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
kristoff_it has quit [Ping timeout: 260 seconds]
marnix has joined #zig
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
Akuli has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
r0bby has quit [Ping timeout: 272 seconds]
mmohammadi9812 has joined #zig
r0bby has joined #zig
cole-h has joined #zig
marnix has quit [Read error: Connection reset by peer]
soedirgo has joined #zig
marnix has joined #zig
LanceThePants has quit [Read error: Connection reset by peer]
tomku has joined #zig
LanceThePants has joined #zig
a_chou has joined #zig
wootehfoot has joined #zig
mokafolio has quit [Quit: Bye Bye!]
cahoots has joined #zig
<cahoots>
does zig have an incremental linker/binary patcher for mach-o?
<ifreund>
cahoots: it's very WIP, but work has been started on it
mokafolio has joined #zig
<ifreund>
Elf is the most developed at the momment
m4r35n357 has joined #zig
<m4r35n357>
can't find syntax in docs for specifying an array return value from a function (which creates the array). new to zig, any pointers?
<ifreund>
fn foo() [5]u8 { ... }
<ifreund>
this will return an array of 5 u8s by value
<ifreund>
if you want to return a pointer to a heap allocated array, you probably want to use a slice: []u8
<m4r35n357>
ifreund, I need it to be variable size (size is the parameter to the function), but []f128 and [_]f128 both fail
<ifreund>
oh then make it [size]u8
<ifreund>
though then the size passed to the function would need to be comptime known
<m4r35n357>
error: use of undeclared identifier 'n'
<m4r35n357>
no suprise there ;)
<m4r35n357>
I am trying to port some existing c code, that mallocs thee array and returns a pointer
<ifreund>
you want a slice then
<m4r35n357>
so I am looking to make a function that takes the size, and does 'return [_]f128{0} ** n;'
<ifreund>
a slice is like a struct { ptr: [*]u8, len: usize };
<m4r35n357>
ok i'll look at slices . . .
<m4r35n357>
I have used both arrays and structs at various times for this, so I think I can fit in with whatever
<ifreund>
you can make a function that returns an array of the right size by value too, but then the size argument of the function must be comptime-known
<ifreund>
if you want to create an array with runtime known size, you need to allocate it on the heap
<m4r35n357>
that is unfortunately not how it needs to work :( the size is a command line parameter
<m4r35n357>
OK is that what slices do?
<ifreund>
slices are just a pointer and a length
<ifreund>
they can point to dynamically allocated memory
<m4r35n357>
OK cheers I'll investigate . . .
<ifreund>
i think you probably want to use std.heap.GeneralPurposeAllocator and call alloc() which will return a slice
<m4r35n357>
ifreund, cheers, still investigating . . .
<m4r35n357>
hmm can't find that one in the std docs, just Arena... FixedBuffer.. and ThreadSafe...
<m4r35n357>
perhaps I am being a bit premature with this . . . but I am so tempted by the 128-bit floats!
<m4r35n357>
they must be native, so no MPFR/libquadmath, so I think it must be zig or Fortran
<ifreund>
the online std docs aren't up to date unfortuneately
<Nypsie[m]>
GeneralPurposeAllocated was introduced after 0.6.0,and since the master docs are a bit broken it doesn't show up there.
marnix has quit [Ping timeout: 260 seconds]
<m4r35n357>
ah, I "only" have 0.6.0 ;)
a_chou has quit [Ping timeout: 246 seconds]
<ifreund>
on 0.6.0 they easiest way to get started is to just use std.heap.page_allocator
<ifreund>
it's not efficient but it works :P
<m4r35n357>
working is good ;)
Rounin has joined #zig
<m4r35n357>
hmm, that one isn't there either . . . . :(
marnix has joined #zig
<Rounin>
Say... Has anyone else tried to compile bzflag v2.4.18 with zig c++? I tried that today, but the game segfaults upon startup
ky0ko has quit [Quit: killed]
<Rounin>
Not that I'm in dire need of a C++ compiler, but it seemed like an interesting thing to try
<justin_smith>
m4r35n357: you can check what's in lib/std/heap/
<alexnask[m]>
Does it segfault with Illegal instruction Rounin ?
<Rounin>
alexnask[m]: Good question... I was just about to run a debugger on it, but I realize I deleted it... I'll build it again and see if I can find out
<ifreund>
Rounin: that's likely due to zig enabling UBSan by default
<Rounin>
ifreund: Ah... A C++ application that's probably a couple of decades old... I wonder if there might be UB in there, hehe
<Rounin>
Sounds like a great feature, though
<ifreund>
if you'd like to disable it pass -fno-sanitize=undefined
<ifreund>
and yeah, would not be surpried if there's UB there
<ifreund>
m4r35n357: Its at the bottom of that page you linked
<Rounin>
The complaints from Valgrind are mostly different ones now as well
mmohammadi9812 has quit [Ping timeout: 246 seconds]
<alexnask[m]>
(the failure on #6441, that is)
a_chou has quit [Remote host closed the connection]
LanceThePants has quit [Read error: Connection reset by peer]
LanceThePants has joined #zig
layneson has quit [Ping timeout: 240 seconds]
<andrewrk>
alexnask[m], thanks for looking into this
<andrewrk>
maybe valgrind can give us some tips
<andrewrk>
alexnask[m], is your native development machine windows?
<alexnask[m]>
Yes >.> (Not for long though)
joey152 has joined #zig
<andrewrk>
alexnask[m], oh, I was going to say, that's great, we need more core devs who call windows home
<alexnask[m]>
lol
ur5us has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
layneson has joined #zig
LanceThePants has quit [Quit: Leaving]
ur5us has quit [Quit: Leaving]
sawzall has joined #zig
ur5us has joined #zig
bekwnn has joined #zig
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
wootehfoot has joined #zig
_whitelogger has joined #zig
layneson has quit [Ping timeout: 256 seconds]
marnix has quit [Ping timeout: 260 seconds]
Akuli has quit [Quit: Leaving]
deXtoRious has quit [Remote host closed the connection]
omglasers2 has quit [Read error: Connection reset by peer]
wootehfoot has quit [Read error: Connection reset by peer]
lucus16 has joined #zig
<bekwnn>
anyone got any 3d model loading libs they'd recommend?
<bekwnn>
(fbx would be best but obj would probably work for a bit as well)
<justin_smith>
with this inline if I'm getting a segv because between the if and the lookup "live" becomes null - I'm surely doing this wrong: if (self.root) |live| live.next else null
tdeo has quit [Ping timeout: 244 seconds]
tdeo has joined #zig
<justin_smith>
maybe this is a better question for the same problem: it surprises me that this second line can be an NPE, is there some other construction that would ensure the value wouldn't be nulled out in another thread? I suspect I'm using pointers wrong here http://ix.io/2z5I
<justin_smith>
is there a way to make "top_item" be a pointer to the same location as self.root, instead of being literally the same pointer, so that a change to self.root in another thread doesn't blow this up?
<fengb>
I think the optimizer tried to inline this if you’re getting thread errors
<fengb>
Might need an atomic operation?
<justin_smith>
I naiively thought that I was doing this already, but this error makes me doubt that http://ix.io/2z5L
<justin_smith>
fengb: cool I looked at atomic ops and didn't find the right one, just being able to force the optimizer not to inline would be great
<justin_smith>
like "no really I need a separate pointer and not an inline operation" type annotation
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<pixelherodev>
I wonder how hard it'd be to redo the C header generation to use the CBE
sawzall has quit [Read error: Connection reset by peer]
<andrewrk>
btw I don't know if anyone noticed this in the tracy demo of https://www.youtube.com/watch?v=R5FKgi9BYyU but those two sections - analysis and writing to the ELF file - are parallelizable
sawzall has joined #zig
<pixelherodev>
Though I suppose fixing generation of e.g. `struct struct:28:12` would be enough for me lol
<andrewrk>
at 2:17 you can see, (1) AST parsing (2) semantic analysis and (3) linking is done one after another, but those 3 things can happen at the same time
<pixelherodev>
How much locking would there be?
<pixelherodev>
I mean, probably none, now that I think about it
<pixelherodev>
Some bits of AST parsing would need to be finished before other pieces of sema could begin, but they simply wouldn't be queued, I assume...
<pixelherodev>
Yeah, I think I can see how that'd work
<pixelherodev>
That's pretty neat
<andrewrk>
there are some contention points
<pixelherodev>
Right, but not too many
* andrewrk
nods
<pixelherodev>
Where is the current .h emission done? I'd look, but i don't want to have to dig through the CLI parsing again :P
<justin_smith>
fengb: doing an @atomicLoad in that if fixed it, thanks - I have another more rare race condition now but that one was hitting me on 7/8 of test runs :D
<pixelherodev>
Is it self-hosted yet, at the least?
<justin_smith>
now to make the next race condition happen more often too..
nullheroes has joined #zig
<andrewrk>
pixelherodev, it will fully regress into non existence with the merge of 6250 and will need to be implemented from scratch in self-hosted
<pixelherodev>
Ahh okay
<pixelherodev>
That'll be my first post-6250 task then
<pixelherodev>
Dibs
<pixelherodev>
:P
<andrewrk>
nice
<pixelherodev>
I need it anyways, and I think I can use existing CBE stuff for it
<pixelherodev>
And this helps with our prior discussion
<andrewrk>
you'll have to take a slightly different strategy because it will have to cooperate with incremental updates, unlike the work on CBE so far
<pixelherodev>
If we're using the same logic for headers and CBE, then it'll show whether or not it'll be easy to integrate with the standard pipeline
<pixelherodev>
Then we'll just have to make CBE incremental
<pixelherodev>
It won't have to actually be used incrementally for normal CBE work, but as long as it's *internally* incremental, it can be used that way for headers even if we don't expose it generally
<andrewrk>
ha, sounds fun. ascii art comments ftw
<pixelherodev>
Not necessarily
<pixelherodev>
One option is to do it incrementally in memory, and rewrite the file on disk
<pixelherodev>
That'll be a single buffered write, effectively
<pixelherodev>
It could also rewrite only changed portions
<andrewrk>
that's fine but keep in mind the goal of low memory footprint
<pixelherodev>
Yep
<pixelherodev>
It'd probably still be lower than what's needed for the other linkers
<pixelherodev>
All it'd really be tracking is position and len
<pixelherodev>
That's two usizes per decl
<andrewrk>
that's fine
<pixelherodev>
The "easy" option is to just rewrite the file from the first changed token onwards
<pixelherodev>
I think it's reasonable to expect headers to be small, generally
<pixelherodev>
Not small enough to keep them fully in memory, though...
<pixelherodev>
It rewriting from the first changed token, it could just fully regenerate them and then do a single flush, I suppose?
<pixelherodev>
The much worse option would be to read the file into memory, but at that point we might as well keep it there full time
<pixelherodev>
Hmm, one other thing to note is prefixing
<pixelherodev>
I'd want to be able to specify a per-package prefix for functions
<pixelherodev>
So I don't need to do e.g. `export fn thor_deinit(self: *@This()) void { self.deinit(); }`
<pixelherodev>
Hmm, but that'd mean renaming them in the binary, too.
tundrax has joined #zig
<pixelherodev>
So... many... stupid... wrappers.
<pixelherodev>
Hmm. Currently, writing Zig code for use with C feels fundamentally different from writing Zig code for use with Zig.
<pixelherodev>
Fortunately, that's not an issue in reverse, but still...
<justin_smith>
pixelherodev: that's inherent when we have features (eg. namespacing) that C lacks I would thin
<justin_smith>
*think
<justin_smith>
I'd rather explicitly put prefixes on things I export, rather than remembering implicit prefix rules
ur5us has quit [Ping timeout: 240 seconds]
<lunamn>
also errors, i guess?
<justin_smith>
I guess a package level setting for prefix to apply to exported functions (that's opt in), isn't so bad
<fengb>
lol ix.io favicon
<pixelherodev>
justin_smith: I'm actually thinking struct-level might be good, too
<pixelherodev>
e.g. `const a = extern struct { export fn b() void {} }` it'd make sense for b to be exported as `void a_b(void);`
<justin_smith>
pixelherodev: yeah, as long as it's configurable and opt in, the fewer special cases the better
<justin_smith>
so make packages and structs have the same features, if the features exist, +1
<pixelherodev>
For sure
<pixelherodev>
That could be a nested struct thing instead of a package one, maybe?
<pixelherodev>
The alternative option is to just require each Zig package to have e.g. a exports.zig file defining the wrapper explicitly
<justin_smith>
why not make the mapping an optional config, with current behavior if it isn't defined?
<justin_smith>
or, equivalently, a default prefix of ""
<justin_smith>
in guile scheme, you can provide a function that takes the name of an exported function, and returns the replacement name to use instead, if comp-time string allocations aren't too tricky even that could work
<pixelherodev>
what's the correct way to say "c string" in Zig?
<pixelherodev>
Neither `[*:0]const u8` or the same with `i8` are making C happy.
<companion_cube>
[*:0] const u8 or sth?
<companion_cube>
erf
<pixelherodev>
That works for Zig side, yeah
<justin_smith>
companion_cube: yeah that looks right to me
<justin_smith>
pixelherodev: on the c side it's just a pointer to a char, the rest is just user convention with no compiler enforcement
<pixelherodev>
but the generated header then produces a func taking `const uint8_t *` / `const int8_t *`, *neither* of which are apparently implicitly castable from `char[]`
<pixelherodev>
justin_smith: compiler rejects it.
<justin_smith>
hmm...
<pixelherodev>
`initializing 'const int8_t *' (aka 'const signed char *') with an expression of type 'char [2]' converts between pointers to integer types with different sign`
<pixelherodev>
Weirdly, that's the case *regardless* of which sign is set