ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
Kingsquee has quit []
ky0ko has joined #zig
Daimanta has joined #zig
<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
<daurnimator> can someone with a debug build of zig handy post a stack trace to
<g-w1> daurnimator:
<daurnimator> g-w1: thanks. added to issue :)
<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: 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
ky0ko has quit [Quit: - Chat comfortably. Anywhere.]
ky0ko has joined #zig
<pixelherodev> Personally, I prefer (1) there
kbd has quit [Remote host closed the connection]
<pixelherodev> But some of my past PRs didn't do a good job at that, and (2) is definitely better than some I've seen [and some I've made]
<g-w1> is the way to achieve 1 (or 2) rebasing a lot?
<g-w1> or just being neat?
<pixelherodev> Mostly the latter, partly the former
<pixelherodev> g-w1: see `git add -p`
<pixelherodev> It lets you interactively choose which bits go into which commit
<g-w1> yep, ik abt it. its nice
<pixelherodev> (but you *need* to then test each commit individually!)
<pixelherodev> I've made a habit of splitting commits via `git reset HEAD^ && git add -p && git commit &&...`
<andrewrk> g-w1, it helps if you come up with the smallest testable checkpoint
<andrewrk> it's reaaaally nice when each commit has 1 new test case and the corresponding code to make it pass
<andrewrk> not always achievable tho of course
<andrewrk> but those PRs tend to get merged really fast
leon-p has quit [Remote host closed the connection]
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
ur5us__ has joined #zig
JacobSandlund has quit [Ping timeout: 245 seconds]
ur5us_ has quit [Ping timeout: 260 seconds]
raggi has quit [Remote host closed the connection]
<daurnimator> pixelherodev: g-w1: I use this too:
ur5us__ has quit [Quit: Leaving]
benjif has quit [Quit: Leaving]
cole-h has quit [Ping timeout: 240 seconds]
Kingsquee has joined #zig
<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
<ifreund> 1 << (@bitSizeOf(@TypeOf(x)) - @clz(x) + 1)
<ifreund> maybe
<daurnimator> betawaffle: yes. math.ceilPowerOfTwo and friends
<ifreund> which is indeed using @clz(), but with a nice API
<scientes> and your example doesn't work if it already is a power of two
<ifreund> indeed, it probably needs an @intCast() as well
<ifreund> zig's pretty anal about the types when shifting
<scientes> there could be a nice extend that just adds zeros
<scientes> i.e. a big-endian zero-extend
<scientes> (not big-endian byte order, but big-endian bit order)
<scientes> ...which is one of the reasons I proposed to remove the concept of bytes
sord937 has quit [Quit: sord937]
cole-h has quit [Ping timeout: 256 seconds]
Akuli has joined #zig
nyaa8 has quit [Quit: byeee~]
nyaa8 has joined #zig
Cadey is now known as Guest57365
Guest57365 has quit [Killed ( (Nickname regained by services))]
jsb has joined #zig
a_chou has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
FireFox317 has joined #zig
rowbee has quit [Quit: ZNC -]
rowbee has joined #zig
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
<FireFox317> andrewrk, created #7659
craigo has quit [Ping timeout: 256 seconds]
notzmv has joined #zig
<andrewrk> ifreund, did you see
<andrewrk> FireFox317, hmm I thought I fixed that recently
<andrewrk> FireFox317, oh, the same thing that commit noted in #7596 has to be done to the test harness
<andrewrk> (or we need to implement #7596)
<andrewrk> in summary destroy the Compilation before executing `zig run`
<andrewrk> but then that workaround can be reverted if we do the 7596 idea
<FireFox317> andrewrk, ah yes it is exactly 7596, but then for another case. I will do the workaround i think
<andrewrk> ifreund, daurnimator: I will reconsider the zig build system thing
hnOsmium0001 has joined #zig
mkchan has quit [Quit: WeeChat 2.6]
<g-w1> andrewrk: here you say that you will introduce lazy values is this still the goal? because if so, this would fit in very nicely with inferred error sets
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:
<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…]
benjif has joined #zig