<Daimanta>
While I'm here anyway: I couldn't find a function to transform a "string" into an integer. Is there any such function?
<fengb>
std.fmt.parseInt
<Daimanta>
Ah, thanks. Now I can remove my own abomination ;)
Jeanne-Kamikaze has joined #zig
Jeanne-Kamikaze has quit [Ping timeout: 240 seconds]
<fraktor>
Has anyone used Zig with single-header libraries before? I'm having trouble how to define something like NUKLEAR_IMPLEMENTATION for example when I include the header.
alexpana has quit [Quit: WeeChat 1.9.1]
<andrewrk>
fraktor, -DNUKLEAR_IMPLEMENTATION=1
Daimanta has quit [Remote host closed the connection]
<companion_cube>
isn't nuklear unmaintained?
<companion_cube>
hmmm, or is it just the old repo that is archived
<fraktor>
andrewrk: It needs to be defined in a particular file; other places just reference the header-only version.
<fraktor>
Maybe I shouldn't go for a header-only library...
<andrewrk>
fraktor, are you using build.zig?
<andrewrk>
addCSource lets you add c flags for that specific file
<fraktor>
Oh I misunderstood, thanks.
<daurnimator>
andrewrk: re: https://github.com/ziglang/zig/issues/7635. I'm not sure it *is* a bug after your statement: `(@as(u8, undefined) & 0xf0) | 0x0f` => is defined to equal `0`?
<andrewrk>
first we evaluate (undefined & 0xf0) which results in undefined
<andrewrk>
then we evaluate (undefined | 0x0f) which results in undefined
<andrewrk>
`(@as(u8, undefined) & 0xf0) | 0x0f` will be constant-folded into `@as(u8, undefined)`
<daurnimator>
so then there is no stage1 bug in #7635: its a bug (and design flaw) in PackedIntArray.
<andrewrk>
I see
<andrewrk>
well it's still a stage1 bug because you are allowed to do &= on an undefined value
<andrewrk>
"use of undefined value here causes undefined behavior" pointing to `target &= mask` is incorrect
<daurnimator>
okay; should we split the issue?
<andrewrk>
sure
<daurnimator>
I'm not sure how we should solve the design flaw in PackedIntArray.... I think it would need to ban passing `undefined` to .set ?
<daurnimator>
but that's not easy or detectable
<daurnimator>
it also raises the question for what to use for undefined values instead of undefined
<daurnimator>
0 i guess?
<daurnimator>
hmmmm. if PackedIntArray worked on `packed struct { a: u1, b: u1, c: u1, d: u1, e: u1, f: u1, g: u1, h: u1}` then it be fine I guess
<daurnimator>
though the fact that you have to resort to that suggests a language flaw :P
<g-w1>
andrewrk: it seems like you are astgening the func body in the comptime function call. if it is called at runtime also it will be astgened again. should this be cached?
<andrewrk>
daurnimator, the dissonance comes from simultaneously trying to treat an integer as a mathematical integer and as a bag of bits
<andrewrk>
there are other places where this dissonance shows up too and I agree it is something to consider
<andrewrk>
g-w1, good question
<andrewrk>
definitely seems worth looking into
<g-w1>
we should probably do some benchmarks. I suspect astgen doesn't take much time
<andrewrk>
I want to get to a point where we can run a fairly complex algorithm in zig stage2 comptime and compare its perf and memory usage to an equivalent python3 script
<daurnimator>
andrewrk: huh. maybe #7512 has some merit after all
<andrewrk>
g-w1, lots of fun stuff to work on in stage2 :) I'll try to get you some code review action before bed tonight
<g-w1>
thx, if you are debating which one 7092 is gonna be the root of all my error stuff going forwards so its probably best to get merged first. it needs a rebase tho
<andrewrk>
ok you got it
<andrewrk>
hmm this is failing the CI tests
<g-w1>
that was happening a few days ago when I last touched it
<g-w1>
test-stage2 -Denable-qemu works fine on my machine tho. its in the docgen code
<andrewrk>
I see
<andrewrk>
when you rebase it would you mind cleaning up some of those commits? for example I don't think there needs to be revert commits right? could just remove both the revert commit and the original commit from the PR
<g-w1>
yes. looking at the diff there are a few things that I left in by accident too Module.zig:2777, so ill clean those up too
<andrewrk>
much appreciated
<andrewrk>
here's my rule of thumb: choose one: (1) organize the PR into distinct commits that will make sense for the reviewer to review separately from each other, or (2) make the entire PR 1 commit
<g-w1>
ah thx
JacobSandlund has joined #zig
<g-w1>
hmm, looking at my code revealed a few weird things. guess thats what happens when you start to work on code that you left for 1.5 months. I left a review on my own pr! next time ill do this beforehand so i dont waste your time
<andrewrk>
no worries
ur5us_ has joined #zig
<daurnimator>
I put up a PR with EnumSet. I wrote it for the pattern: `pub const StandardOptionsConfig = struct { release_mode: EnumSet(builtin.Mode) = EnumSet(builtin.Mode).Full};` but I realised that its useful in a whole lot of places.
<daurnimator>
It might even be useful for OS bitflag interfaces
kbd has joined #zig
<g-w1>
ok, now all the obvious (to me) bugs are marked :P
<Kingsquee>
is there anything like a hashset in the std?
<daurnimator>
Kingsquee: HashMap with void value type
<daurnimator>
Kingsquee: there's also BufSet for sets of strings.
<Kingsquee>
as in AutoHashMap(T, .{}) ?
<daurnimator>
Kingsquee: I also put up a PR for EnumSet
<daurnimator>
Kingsquee: so I guess it all depends on what you want a set *of*
<Kingsquee>
a dumb struct
<daurnimator>
Kingsquee: `AutoHashMap(T, void)`
<Kingsquee>
ah, didn't realize void was a type
waleee-cl has quit [Quit: Connection closed for inactivity]
decentpenguin has quit [Quit: ZNC crashed or something]
decentpenguin has joined #zig
lucid_0x80 has joined #zig
nycex- has quit [Ping timeout: 240 seconds]
nycex has joined #zig
<Kingsquee>
do we have an operator for computing div and rem simultaneously?
<Kingsquee>
a-la div, ldiv, lldiv
<daurnimator>
Kingsquee: no. just do them and the optimiser tends to figure it out
tomku has quit [Ping timeout: 272 seconds]
<daurnimator>
is there a known failure on master right now? not sure why #7649 failed
lucid_0x80 has quit [Ping timeout: 264 seconds]
tomku has joined #zig
craigo has joined #zig
tomku has quit [Client Quit]
tomku has joined #zig
<andrewrk>
yeah we're hitting OOM on windows
<andrewrk>
on the std lib tests
<daurnimator>
andrewrk: okay; is there anything i should do about it?
<andrewrk>
no; I'll have to figure out how to mitigate problem tomorrow to make the CI green again
<daurnimator>
--test-filter=a, --test-filter=b, etc. :P
<pixelherodev>
On separate CI jobs ;P
<pixelherodev>
or, accept that CI is inpractical for now, and locally merge PRs in batches, testing them in full?
<pixelherodev>
Or, set up a bespoke CI with more RAM
<pixelherodev>
buf45
<pixelherodev>
oops
<daurnimator>
andrewrk: should .standardOptions() also subsume .standardTargetOptions() ?
<andrewrk>
yes I think so
<daurnimator>
currently `.standardTargetOptions`/`.standardReleaseOptions`/etc save away their value in the builder context. do you want to keep that pattern?
<daurnimator>
the fact they did was why I was thinking it made more sense for steps to automatically inherit
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
Kingsquee has quit []
sord937 has joined #zig
<daurnimator>
hmmm. going through everything in the repo... we're inconsistent about if we set build mode and target on test steps
st3r4g has joined #zig
<ifreund>
Yeah, I really think automatically inheriting by default would be better
<ifreund>
I honestly can't think of a use case when you'd need to do something more complex
waleee-cl has joined #zig
cole-h has joined #zig
<g-w1>
ok thx for the feedback
<betawaffle>
is there some magic bit-shifty way to round a number up to the next power of two?
<ifreund>
betawaffle: something with @clz() should work
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
wootehfoot has joined #zig
oats has quit [Quit: until later, my friends]
oats has joined #zig
leon-p has joined #zig
<FireFox317>
andrewrk, the c code testing of stage2 that you added, causes a deadlock when linking the test-stage2 with libc (and all LLVM stuff). When I comment out the c tests it doesn't deadlock. Also when I directly run the test binary (not through `zig test`) it also doesn't deadlock.
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
<FireFox317>
andrewrk, okay i managed to find the problem
rowbee has quit [Remote host closed the connection]
rowbee has joined #zig
kbd has joined #zig
kbd has quit [Remote host closed the connection]
SebastianKeller has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
kbd has joined #zig
<kbd>
What's the right way to share one allocator in a program containing multiple modules? Must I pass it in everywhere or is there something easier?
<ifreund>
well if it's a gpa you could just make it a global
<ifreund>
if you're doing arenas or something else you probably do want to pass it everywhere
a_chou has quit [Quit: a_chou]
<andrewrk>
don't you typically initialize a module? you could pass it in there and then store it
kbd has quit [Ping timeout: 240 seconds]
kbd has joined #zig
ehaas has joined #zig
<kbd>
ifreund: yeah it's a gpa, I'm just writing a "do its thing and exit" command line program. It worked fine as a global when everything was in one file. Then I did the goofy "put functions in another file and reflect on it to build a hash table of its public functions" we talked about yesterday, but some of those need an allocator (along with other globals). So I tried importing "main.zig" from "funcs.zig" and get
<kbd>
a lot of "cannot store runtime value in compile time variable" when I try to do that.
<kbd>
It's not just the allocator, really, but "how do I share globals in my whole progarm".
<kbd>
I guess create a globals.zig with a bunch of things set to undefined and then initialize them all in main.
<ifreund>
importing main.zig should work fine in general, something unusual is happening in your case
cole-h has joined #zig
<kbd>
hmm, good to know that it's "ok" to import your main back from a another file.
<kbd>
it's actually when I do the reflection that I start getting errors. If I comment that out the program builds.
<ifreund>
your reflection is probably seeing your import then. I thought the @typeInfo() would only show public decls but that could be wrong
<kbd>
as soon as I put in the `inline for (decls) |d| {}` I start getting "cannot store runtime value in compile time variable" on 'var A = mymain.A;'
ehaas has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sebonirc has joined #zig
<kbd>
Yeah, I moved all globals over to globals.zig to see if that made a difference and I still get "cannot store runtime value in compile time variable" if I try to iterate over the decls in that module.
<ifreund>
kbd: probably need to see the code to be of much help
<kbd>
It'd probably work if I only referred in code to the *functions*, but since all "decls" includes the module-level variables it doesn't work at compile-time.
<kbd>
I'll pastebin a minimal example in a bit.
<ifreund>
you can skip the non-decl functions in your loop
<ifreund>
*non-function decls
<kbd>
yeah in the loop you can skip them, but all members are still unrolled at compile time I guess? Anyway, here's the gist, I should have narrowed it down to this for you in the first place: https://gist.github.com/kbd/83193ef65e8d3416e20a111b4a4d9624
<kbd>
added the compile error in a comment
<ifreund>
hrm
<ifreund>
ok as a work around you could do `const foo = struct { usingnamespace @import("funcs.zig"); }` and then do your inline for on the decls of foo
<ifreund>
usingnamespace will only grab the pub decls
<ifreund>
I'm not sure if @typeInfo() is supposed to contain non-pub decls or not
<kbd>
it contains all, but you can filter them with `is_pub`
<kbd>
but in my case that doesn't help
<kbd>
trying your code
<mikdusan>
kbd, why not just `const main = @import("main.zig");` and access via `main.dummy_allocator` ?
<mikdusan>
if you _really_ want `funcs.dummy_allocator` then in funcs.zig --> `usingnamespace @import("main.zig");` but eww
<ifreund>
pretty sure that wouldn't change anything here
tsujp has quit [Ping timeout: 272 seconds]
<ifreund>
cleaner than the usingnamespace hack I suggested would be putting the function decls you want to iterate in a sub struct instead of leaving them in the top level of the file
leon-p has quit [Read error: Connection reset by peer]
<kbd>
I'm wrong btw, the decls doesn't contain non-public functions.
st3r4g has quit [Ping timeout: 240 seconds]
kbd has quit [Quit: leaving]
<mikdusan>
kbd added to gist
kbd has joined #zig
leon-p has joined #zig
Akuli has quit [Quit: Leaving]
a92 has joined #zig
FireFox317 has quit [Ping timeout: 246 seconds]
DarkUranium has quit [Read error: Connection reset by peer]
DarkUranium has joined #zig
<andrewrk>
mikdusan, I bet you'd have a nice chat with kubkon about the macos stuff - he's been diving deep into it lately
<andrewrk>
I think he prefers discord
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]