<daurnimator>
union { ptr: *align(64) foo, data: packed struct { dummy: @IntType(false, usize.bit_count-6), foo: bool, bar: u4 } }
laaron has joined #zig
<daurnimator>
^ I guess this is trying to find a workaround until #2652 is done
kristoff_it has joined #zig
<via>
can addresses of c vars be taken at comptime?
<via>
trying to use &my_imported_c_thing.some_data_section_var in a comptime expression doesn't seem to work, complains about it being unable to evaluate constant expression
kristoff_it has quit [Ping timeout: 244 seconds]
ltriant has joined #zig
kristoff_it has joined #zig
<daurnimator>
via: you can take the address; but you can only use it at comptime I believe
kristoff_it has quit [Ping timeout: 246 seconds]
<andrewrk>
there's nothing special about c global variables
brakmic has joined #zig
brakmic_ has joined #zig
brakmic has quit [Ping timeout: 258 seconds]
brakmic_ has quit []
kristoff_it has joined #zig
rjtobin has quit [Quit: Leaving]
kristoff_it has quit [Ping timeout: 258 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
marijnfs__ has joined #zig
_whitelogger has joined #zig
ltriant has quit [Quit: leaving]
kristoff_it has joined #zig
marijnfs__ has quit [Quit: WeeChat 2.4]
kristoff_it has quit [Ping timeout: 268 seconds]
ffddr has joined #zig
torque has quit [*.net *.split]
mattisme has quit [*.net *.split]
tracernz has quit [*.net *.split]
affinespaces has quit [*.net *.split]
BitPuffin has quit [*.net *.split]
edr has quit [*.net *.split]
mq32 has quit [*.net *.split]
kristoff_it has joined #zig
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
<daurnimator>
emekankurumeh[m]: I feel like your .steal return type is weird
<emekankurumeh[m]>
how so?
<daurnimator>
emekankurumeh[m]: also: `return Stolen(T){ .Empty = {} };` vs `return Stolen(T).Retry` is the latter valid ?
<daurnimator>
emekankurumeh[m]: I would return `null` for Empty. For retry... should you not retry *for* the user? or else how do they know when to retry?
<daurnimator>
`self.top.cmpSwap(top, top +% 1, .SeqCst) == top` <-- I'm actually unsure if the `== top` is pre or post increment....
edr has joined #zig
BitPuffin has joined #zig
mq32 has joined #zig
affinespaces has joined #zig
tracernz has joined #zig
mattisme has joined #zig
torque has joined #zig
<emekankurumeh[m]>
i'm fairly certain that cmpSwap is correct, i could be wrong though
<daurnimator>
emekankurumeh[m]: but does the `==` happen before or after the `+%`?
<emekankurumeh[m]>
i would assume after, because `+%` is just a overflowing add, not an increment, so that would be evaluated first
<daurnimator>
oh right. lol.
<daurnimator>
My brain read it as +=
<emekankurumeh[m]>
i was wondering what you meant by increment...
brakmic_ has quit [Remote host closed the connection]
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
DuClare has left #zig [#zig]
fjellfras has quit [Quit: Leaving]
noonien has quit [Quit: Connection closed for inactivity]
gamester has joined #zig
<gamester>
Is whitequark aware that his SSL certificate is invalid? No logs :(
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<gamester>
andrewrk: Currently I think the way you do cimports are by translating the C code to Zig code, but did you consider having C AST nodes instead?
<gamester>
I haven't given this a thought, I'm just curious
ffddr has joined #zig
<ffddr>
Is there any workaround for https://github.com/ziglang/zig/issues/2115? Maybe some way to override generated function definition using this enum with hand-writen one with `usize` instead of enum?
<[[]]>
ffddr: Title "extern enum should allow multiple enumerations with the same value · Issue #2115 · ziglang/zig · GitHub" Shortened < https://is.gd/h3FIZM >
tgschultz has quit [Read error: Connection reset by peer]
fengb has quit [Ping timeout: 260 seconds]
tgschultz has joined #zig
<johnLate>
I've played around with zig a few weeks ago for the first time. Is there a place were I can quickly read up on recent changes? Like a work-in-progress release notes document for the master branch?
fengb has joined #zig
tgschultz has quit [Ping timeout: 272 seconds]
<Tetralux_>
git log XD
bheads_ has joined #zig
bheads has quit [Ping timeout: 268 seconds]
bheads_ is now known as bheads
<johnLate>
I'm already using things like «git log --pickaxe-regex -S '\{\.[0-9]' -p» to figure out how string formatting has changed ;)
<Tetralux_>
That... is unreadable xD
<Tetralux_>
It's things like that that make me glad I don't use regex any more.
<johnLate>
it's just "{." + a number
<Tetralux_>
So it is.
<Tetralux_>
*smiles* It took more than the amount of effort I'd expect to put towards such things xD
brakmic has quit []
<fengb>
It looks like we included all the headers for Windows libc?
<fengb>
So I can do the same for Mac? Don't need to strip down to just libc
porky11 has quit [Ping timeout: 250 seconds]
fengb has quit [Remote host closed the connection]
Tetralux_ is now known as Tetralux
fengb has joined #zig
Akuli has joined #zig
<ntgg>
How do i put a number into a string
<bheads>
checkout std.fmt
<ntgg>
something like "foo " ++ num ++ " bar"
<ntgg>
can you call format on a string?
<ntgg>
It looks like it needs a fuction
<bheads>
no, you format a string into memory. You will want an allocator
<ffddr>
I guess `std.fmt.allocPrint` is the closest to `"foo" ++ num`
<ntgg>
why does `switch (val) { .A => return 'a', .B => return 'b', }` but `return switch (val) { .A => 'a', .B => 'b' };` not work?
<ntgg>
it isn't a compile error
<ntgg>
it just doesn't return the right thing
<Tetralux>
You'd expect them to be the same, but the second returns........?
<fgenesis>
is a switch expression defined to return a value?
<Tetralux>
fgenesis: You can certainly use it like it does.
<fgenesis>
or does it count as a statement without return
<Tetralux>
OH
<Tetralux>
I didn't notice that before.
<Tetralux>
The 'returns' in the first one return from the enclosing function.
<Tetralux>
The lack of them in the second means that the switch itself evaluates to the values; i.e: so you could do 'const val = switch ...'
<Tetralux>
'return' in Zig _always_ means "return from the function".
<fgenesis>
c-style vs functional style, but if one of them doesn't work that looks like a bug
<fgenesis>
pretty sure that's how 'return' was intended here
<Tetralux>
I'm not sure where the 'style' thing is coming from..
<Tetralux>
It's not a style thing here.
<fgenesis>
my brain calls it like that, blame my brain
<Tetralux>
It's a control flow thing here.
<Tetralux>
Either you want to return a value from the function depending on the switch value, or you want to set a variable to a value depending on the switched value.
<Tetralux>
Those are two very different things.
<ntgg>
The actual context I was using it in had it call a fuction that returned an optional value, and an else branch that returned null, and it always returned null
<ntgg>
just move the return outside and it no longer works
<andrewrk>
ntgg, return switch is supposed to work just fine. the next step towards solving the problem is coming up with a reduced test case that is easier to debug in the compiler
<fgenesis>
heh, godbolt.org directly jumps to zig_panic() :D
<Tetralux>
ntgg: I believe so.
<Tetralux>
That looks like it should work as you expect.
<ntgg>
if you replace the else with a .No you get a compile error saying that it expected type u32
darithorn has joined #zig
fengb has quit [Remote host closed the connection]
ltr- has quit [Remote host closed the connection]
porky11 has joined #zig
ffddr has quit [Ping timeout: 260 seconds]
<andrewrk>
thanks for the bug report ntgg
very-mediocre has joined #zig
<Tetralux>
It's a bit of a bummer that you can reach 4 indents quite easily when building datatypes.
<Tetralux>
And 4 indents are like 25% of the page width.
<Tetralux>
I'd honestly prefer to either be strictly procedural (no methods, but that's unreasonable cause of no overloads), or the receiver pattern. I didn't really like that in Go... I think I prefer procedural, but still.
<Tetralux>
It would mean that every fn has a body that's one or two indents in.
<Tetralux>
Which I'd personally find easier to read, and less chlostrophobic.
<Tetralux>
I would use 2-width-tabs, but they're quite a bit harder to read.
<Tetralux>
(.. 'least they were when I tried it.)
<Tetralux>
And for clarity, by 'receiver', I mean this:
<bheads>
? 25% of the page width? screens are bigger then 80 chars now a days
<andrewrk>
emekankurumeh[m], thanks I'll try that too
<emekankurumeh[m]>
at a cursory glance procmon seems better for development, i just use processhacker as a replacement for the stock windows task manager
laaron has quit [Remote host closed the connection]
very-mediocre has quit [Read error: Connection reset by peer]
<ntgg>
I'm trying to compile on windows, and I am getting an error about an invalid carriage return, but there is no carriage return there
very-mediocre has joined #zig
brakmic has quit [Ping timeout: 244 seconds]
<dimenus>
run your code through zig fmt
brakmic has joined #zig
<dimenus>
andrewrk: zig build is a definite improvement for building on Windows :)
<ntgg>
zig fmt is failing on `const std = @import("std");`
knebulae has quit [Ping timeout: 272 seconds]
<Sahnvour>
zig fmt also errors on carriage returns
<gonz_>
ntgg: And what's the line ending set to on the file?
<gonz_>
msdos or unix?
<andrewrk>
Sahnvour, `zig fmt` fixes carriage returns & tabs as of last week
brakmic_ has quit [Ping timeout: 244 seconds]
<Sahnvour>
andrewrk: nice, missed that
<gonz_>
Wut, you mean I don't have to set my line endings anymore?
<ntgg>
it should be unix, I wrote all the code on linux, just cloned the repo to windows
<gonz_>
Windows clones by default with CRLF
<gonz_>
And commits with LF
<ntgg>
how do I turn that off?
<Sahnvour>
in this case you may want to configure git to always use unix style, for example
<gonz_>
You probably shouldn't
<gonz_>
to be honest
<gonz_>
There's no real use
<andrewrk>
git should be configured to not mangle anything
<gonz_>
You can set certain file types to always be LF, however
<andrewrk>
it's a real shame that they made mangling the default, it was a poor choice
knebulae has joined #zig
<gonz_>
It's a non-issue in the vast majority of cases
<gonz_>
When doing transitions between systems it might matter, but that's a special case. Trying to copy over CRLF files to a docker container without converting first, etc.
<nrdmn>
andrewrk: I've been playing with zig and uefi recently. Are there any plans for uefi support in zig's standard library?
<gonz_>
Doesn't that seem like more of a userland thing?
<andrewrk>
nrdmn, such changes are in scope but it's not a project I personally plan to work on. so it can happen but will require contributions from the community
<andrewrk>
a good start would be improving the default panic handler
<ltr->
any gotchas on using sqlite with zig?
<andrewrk>
I'm not aware of anyone who has tried that yet
<nrdmn>
andrewrk: what is it supposed to do?
<andrewrk>
some kind of diagnostic to help the programmer troubleshoot why it happened, and then not return
<emekankurumeh[m]>
is there any guarantee in the order of writes from the assignment of a struct initializer?
<Sahnvour>
andrewrk: do you have a moment to discuss a practical issue ?
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
Akuli has quit [Quit: Leaving]
<andrewrk>
Sahnvour, let me grab some lunch and then I can
porky11 has quit [Quit: Leaving]
darithorn has quit [Quit: Leaving]
jjido_ has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic_ has joined #zig
brakmic_ has quit [Client Quit]
brakmic has joined #zig
very-mediocre has left #zig [#zig]
<emekankurumeh[m]>
trying to store a function pointer to a function that takes a var parameter seems to mess zig up
avoidr has quit [Quit: leaving]
jjido_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined #zig
very-mediocre has left #zig [#zig]
<Sahnvour>
andrewrk: sure. I'm thinking about the implementation of wyhash for the stdlib. A part of it (handling the remaining bytes after eating them by packs of 32) is basically a big switch covering 32 cases with slightly different behaviour, that can be expressed in other, more generic ways. See the patch here https://github.com/ziglang/zig/pull/2797#issuecomment-507479634 for example. My issue is that while a big
<Sahnvour>
switch is hard to read and maintain, it's much easier on the optimizer.
<Sahnvour>
For example consider when we're hashing a u64: casted as a slice of u8, we know its size at comptime and can easily ignore the loop on 32byte packs, and directly select the good switch case that will handle perfectly the data's size. The optimizer can see through this pretty easily and generate efficient machine code.
<Sahnvour>
But the generic version contains more control flow and branches, and incurs a big overhead for small data sizes. It's generic at the cost of having runtime control flow. I'd like to get rid of it. Since the behaviour of each case of the switch depends on the value (0-31), I would like to be able to use it at comptime, in a similar way to inline while. That's what the original switch is doing, but manually. It's
<Sahnvour>
ok to generate 32 code paths in this case, if this helps performance by dropping a few branches.
andrewrk has quit [Ping timeout: 248 seconds]
omglasers2 has joined #zig
brakmic has quit [Ping timeout: 246 seconds]
andrewrk has joined #zig
brakmic has joined #zig
brakmic has quit [Read error: Connection reset by peer]
brakmic_ has joined #zig
andrewrk has quit [Ping timeout: 244 seconds]
marijnfs has joined #zig
<nrdmn>
the documentation for std.debug.assert says "In Debug and ReleaseSafe modes, calls to this function are always generated, and the `unreachable` statement triggers a panic.", but also "this function may not detect a test failure in ReleaseFast and ReleaseSafe mode."
<nrdmn>
so why may a test failure not be detected if the code is not optimized away in ReleaseSafe mode?
<nrdmn>
is the second quoted sentence meant to say "in ReleaseFast and ReleaseSmall mode" ?
andrewrk has joined #zig
<andrewrk>
Sahnvour, is this sort of like duff's device?
<Sahnvour>
nope, we execute through the switch one time for each call
<Sahnvour>
and it does not influence the next one
<andrewrk>
the switch looks fine to me, tbh
<andrewrk>
it seems easier to read than the programmatic code
<Sahnvour>
I believe the programmatic approach could be simpler with more expressive powers, but it's not satisfactory to me either as it is
<nrdmn>
seems like functions supportin
<nrdmn>
g a variable number of arguents are not documented
<emekankurumeh[m]>
zig varags are going to be removed
<Tetralux>
Suppose you've written a BucketArray(comptime T: type, comptime bucket_size: usize)
<Tetralux>
And you want to store a lot of several types.
<Tetralux>
So you have a struct that essentially is
<Tetralux>
or rather has
<Tetralux>
A field of type BucketArray(T, n) for every type you want to store.
<Tetralux>
But you don't know what exact Ts you're gonna use.
<Tetralux>
Or, put more simply
<Tetralux>
Or - not simply - a different way
<Tetralux>
You want data: ArrayList(BucketArray)
<Tetralux>
But BucketArray is polymorphic.
<Tetralux>
Essentially, you want somewhere to keep your instance of T, U, etc.
<Tetralux>
You have a BucketArray for each one.
<Tetralux>
But you don't want to list them out and access the one you want.
<Tetralux>
You want a struct that you ask for a T, and it makes a BucketArray for Ts and gives you one.
<Tetralux>
But how do you store the BucketArrays.
<Sahnvour>
Tetralux: what you want is a container of heterogeneous types ?
<Tetralux>
Not quite.
<Tetralux>
See it's not an array of 'any'...
<Tetralux>
It's an array containing BucketArrays for each type you want to store.
<Tetralux>
But BucketArray is polymorphic.
fengb has joined #zig
<Tetralux>
You essentially want to do .get(T) and it makes a BucketArray for T if there isn't one, and gives you a T from that array.
<Tetralux>
But how do you store that new BucketArray?
<Tetralux>
If it wasn't poly, you could maybe have a HashMap(T, BucketArray) for that T.
<Tetralux>
HashMap(type, BucketArray)
<Tetralux>
*
<Sahnvour>
is listing all the Ts used to create BucketArray(T) an option ?
<Tetralux>
I'm interested in both if you do and don't.
<Tetralux>
If so, then it'd be because you'd have .get(T)
<Tetralux>
(.. for example.)
<Sahnvour>
I think usually for this, you want to either create something containing all your BucketArray(T)s ahead of time, or associating each type T with an id that's used to fetch the correct BucketArray(T) at runtime (similar to the hashmap idea)
<Tetralux>
.. like it's TypeId :)
<Tetralux>
But
<Sahnvour>
for example
<Tetralux>
How do you have a HashMap that maps a TypeId to BucketArray(T)?
<Tetralux>
Like - it won't let you store multiple BucketArray(T)s in a map where T is different for each key.
<Sahnvour>
at this point the thing is you have to hide the genericity (BucketArray can contain any T) behind something, and do some casting
avoidr has joined #zig
<Tetralux>
I guess I'm not entirely sure how you'd hide it here.
<Tetralux>
Like
<Tetralux>
I could have *void values in the map but..
<Sahnvour>
yeah that's not really elegant, but it works
<Sahnvour>
I mostly did this kind of design in C++ where you can get away with abstract classes and inheritance to make it less ugly
<Tetralux>
See - it would be better to reimplement the BucketArray inline.
<Tetralux>
But that's against reuse :)
<Tetralux>
The BucketArray contains [N]T which is why it needs the type parameter.
<Tetralux>
I essentially want to hide the T from the equation for the purposes of storing them in the array.
<Tetralux>
I'm not sure how best to solve that without resorting to another pointer indirection and *void.
<fengb>
I don't think you can do that since that's not comptime known
<fengb>
Without the [N]T known to the compiler, the memory layout isn't guaranteed
<fengb>
So you'd be stuck doing a void pointer hack
<Tetralux>
The [N]T in BucketArray _is_ comptime though.
<Tetralux>
But even if not,
<Tetralux>
Is "use *void" the best solution here?
<Tetralux>
Like - is there something Zig could have that would make this much cleaner?
<fengb>
Yes but that needs to be a hard reference variable
<fengb>
The compiler needs to know at a given time which specific BucketArray to use
<fengb>
I suppose you can kludge it with pointers. Then the memory layout of all BucketArrays will be identical
<Sahnvour>
if you know ahead of time the complete list of T you will use, you can create your specialized BucketArrays and access them in a type-safe way
Tetralux__ has joined #zig
<Sahnvour>
otherwise, I think you're good for void pointers
Tetralux has quit [Ping timeout: 244 seconds]
Tetralux__ is now known as Tetralux
brakmic_ has quit []
fengb has quit [Ping timeout: 260 seconds]
omglasers2 has quit [Quit: Leaving]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ffddr has joined #zig
rsdimenus has joined #zig
ffddr has quit [Ping timeout: 260 seconds]
ntgg has quit [Ping timeout: 248 seconds]
<Tetralux>
One way you could solve this is to have a builtin Any type
<Tetralux>
Which is packed struct { info: *TypeInfo, value: *void }
<Tetralux>
But with buitin support for things like: const s = "Hello, World"; const a: Any = s;
<Tetralux>
Or, perhaps more likely, const s: Any = "Hello World"
<Tetralux>
Essentially, you could cast any type to Any implicitly.
<Tetralux>
You could then store ArrayList(Any) and an array of TypeId and use the latter to look up which one corresponds to the former.
<via>
i am running into an issue where i would really like to have a type like that too, which is leading me to my whole nested structs and tagged unions thing from last night
<Tetralux>
Honestly, I think I'd make my own Any than doing any fancy with nested structs xD
<Tetralux>
That doesn't sound fun
<Tetralux>
We have the 'static'/comptime version of it already: fn f(p: var)
<Tetralux>
(.. The var causes f to be specialized for every type passed for it.)
<Tetralux>
But you could also use fn f(p: Any) and then anything you pass would be auto-converted into an Any.
avoidr has quit [Quit: leaving]
<Tetralux>
(.. If you did `const s = 42; f(s);`, the Any would contain `&s` and `@typeInfo(s)`
<Tetralux>
You'd then switch on the typeInfo.
<Tetralux>
I'm not familiar with how typeInfo in Zig works yet.
<Tetralux>
But if there's one instance of TypeInfo for every type in the program, then you'd store *TypeInfo and essentially check for `p.info == @typeInfo(U)`
<Tetralux>
Alternatively, you might also be able to use TypeId.
<Tetralux>
Odin has Any IIRC.
<Tetralux>
There was an interesting thing about passing Anys across the DLL boundary though.
<Tetralux>
But yes - It could prob be userland, but the implicit casting could not of course.
<companion_cube>
Tetralux: ocaml uses a crypto hash of the signatures when linking
<companion_cube>
so if you dynlink something that uses a bunch of types, it could compare the hash of these types with the linker's?
<Tetralux>
im not sure a hash is a good idea precisely because it isnt perfect and you may randomly get things being considered equal when they are not.
<companion_cube>
a crypto hash? no way
<Tetralux>
for something like that, i would not accept anything less than a perfect hash.
<companion_cube>
really? you don't use git either?
<Tetralux>
i do not want that kind of bug in my program.
<Tetralux>
full stop.
tgschultz has joined #zig
<Tetralux>
having that kind of bug in the runtime of a langauge is unacceptable if you are serious about your langauge.
<companion_cube>
do you also distrust pgp signatures?
<Tetralux>
you may be misrepreenting crypto hashing there
<Tetralux>
they are not meant to be perfect
<Tetralux>
just "good enough" for security
<Tetralux>
i dont want good enough for langauge runtime basic stuff
<Tetralux>
i want "isnt gonna f*** me over"
<companion_cube>
hmmm, for me something like sha256 is not just "good enough"
<companion_cube>
the probability of a collision is so astronomically low that it'll never happen
<companion_cube>
(ofc if you link untrusted code and rely on the hash only… you're f*cked anyway)
<Tetralux>
id honestly prefer just testing for ptr equality over a non perfect matching method
<companion_cube>
I'm not really following, isn't the issue that you're linking a .so which cannot share pointers with your program?
<Tetralux>
if that means passing between dlls is not possible then so be it.
<Tetralux>
(.. using ti ofc)
<companion_cube>
(but seriously, how often have you met collisions in crypto hashes? 😅)
<Tetralux>
I can't really claim to have tested enough possibilities :p
<Tetralux>
But no - your point is valid.
<Tetralux>
I'd probably use BLAKE2 which produces a 1024b hash IIRC.
<Tetralux>
_Just_ because I do _NOT_ want that particular thing to be a problem that badly.
<Tetralux>
For me, the problem is very simple: I want it to be foolproof and reliable no matter what I throw at it.
<Tetralux>
We have enough random crashes and bugs without introducing one into Zig that you cannot control.
<Tetralux>
(.. Enough crashes in software in general today.)
<Tetralux>
You could even have `ti1.eql(ti2)` compute the hashes more than once to make extra-damn-extra-sure xD
<Tetralux>
That's maybe getting a little silly at that point though.
<Tetralux>
One thing I can say though, is that ptr comparision is the most transparent thing you can do.
<Tetralux>
And for that reason, I would rather have something along in that same vein.
<Tetralux>
You also don't want to have a super slow hash either.
<Tetralux>
If anything you want a superfast one.
<Tetralux>
But then you have collision problems.
<Tetralux>
It just kinda... I dunno... 'Has the sense of overcomplication about it a bit. :D
<companion_cube>
I mean, the hash would be computed during compilation anyway?