<hryx>
and then the docs link to the spec and grammar
<companion_cube>
if you make a spec, someone will come and implement it and we'll have two implemtations 🙃
<hryx>
the more the merrier
<fengb>
You can make it impossibly complicated like OOXML :P
<andrewrk>
hryx, the spec is the canonical location; it's copied to the lang ref for convenience of people reading it
<rankao>
Question, is there a way to coerce a optional into a non-optional?
wootehfoot has quit [Read error: Connection reset by peer]
<pixelherodev>
`.?`
<pixelherodev>
e.g. if you have an optional called `a`, `a.?` gives you the non-optional form
<pixelherodev>
It also asserts that a isn't null, causing a runtime error if it is
<hryx>
andrewrk: do you think it would be redundant once the spec is written and hosted on the zig website? Doesn't bother me either way, I just noticed it's prone to getting out of sync as seen in that commit comment
<rankao>
It didn't click with me that `assert(x.? == 1234);` was coercing it into a non-optional
<hryx>
rankao: in this case it's typically called "unwrapping" rather than coercing
<rankao>
Yeah. It's what I'm used to from Rust.
<andrewrk>
hryx, eventually we could make docgen pull it from a canonical location. I also think this problem will solve itself once the language stabilizes
<andrewrk>
to make temp files with no path, and then "materialize" them into the file system atomically
<daurnimator>
I thought you could already do that with memfd
<andrewrk>
don't think so
<daurnimator>
or maybe I'm thinking of something else
<pixelherodev>
That - sounds really really useful
<mikdusan>
sounds like the inverse of unlink (refcount goes to 0) and file node exists only in memory ?
<daurnimator>
Can you link from /proc/self/fd/ ?
<andrewrk>
the important part about the patch is the part where it goes from being in memory only, atomically to the file system
<pixelherodev>
How's that different from `mv /tmp/file /somewherereal/file`?
<andrewrk>
renaming into place requires /tmp/file to exist
<andrewrk>
if the application loses power between creating /tmp/file and the rename() then there will be garbage /tmp/file
<daurnimator>
andrewrk: can you link from /proc/self/fd to the file system?
<pixelherodev>
No there won't; tmpfs exists only in memory
<pixelherodev>
If the device loses power, tmpfs gets cleared
<fengb>
Most people have /tmp mapped into the HDD
<mikdusan>
I'm looking at link() and linkat() manpage. I don't see how it can work without 2 paths; so what is path1 supposed to be if you only have fd1?
rankao has joined #zig
<daurnimator>
pixelherodev: huh?
<daurnimator>
pixelherodev: you can call open() with O_TMPFILE and then linkat it into place via /proc
<andrewrk>
mikdusan, you can have an fd that does not correspond to a path. but without AT_REPLACE for linkat (the flag introduced in the patch), there is no way to atomically make the fd gain a path on the file system
<daurnimator>
andrewrk: yes you can.....
<andrewrk>
prove it
<daurnimator>
andrewrk: there's even an example in the manpage open(2)
<andrewrk>
daurnimator, what syscall do you perform once you've written the data to the tmp file fd, in order to give it a path in the file system?
<daurnimator>
andrewrk: linkat
<andrewrk>
it will give EEXIST if the destination file exists
<andrewrk>
this patch adds AT_REPLACE so that linkat can replace the target
<daurnimator>
ah right
<daurnimator>
fengb: most people do *not* have /tmp mapped to a HDD. last I checked all distros use a tmpfs for /tmp
<daurnimator>
but in any case, for linkat to work you need to be on the correct file system/partition
<pixelherodev>
`Most people have /tmp mapped into the HDD` Wait really?
<pixelherodev>
Weird
<andrewrk>
(1) open directory fd which contains the destination file to overwrite. (2) O_TMPFILE to get an fd to write replacement file to. write replacement data. (3) linkat(AT_REPLACE) to atomically overwrite destination
<andrewrk>
this guarantees no trash left around after application crash or power loss, and atomic replacement of dest file
<daurnimator>
I'm in a RISCV session at the moment. Anything in particular we want to know?
<mikdusan>
path1 is the _existing_ file as `const char*` . we have an existing fd. without going to /proc, what is path1 arg suppose to be?
<daurnimator>
mikdusan: it's meant to be the one in proc.
<daurnimator>
mikdusan: see the man page (which I pasted above)
<andrewrk>
daurnimator, I think we're good on risc-v front. I'd be interested if there were any CI service
<daurnimator>
andrewrk: they say use qemu
<andrewrk>
yeah we do already, cool
<mikdusan>
daurnimator: ah ok. so /proc _is_ mandatory
<mikdusan>
they need a linkat2()
<daurnimator>
mikdusan: I think you can do that via AT_EMPTY_PATH today? though it requires CAP_DAC_READ_SEARCH
<daurnimator>
is it legal to cast that to a [4096]u8 ?
ltriant has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
ltriant has joined #zig
ltriant has quit [Ping timeout: 258 seconds]
marmotini_ has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 240 seconds]
<terinjokes>
i wrote some awful code today. :(
<rankao>
That is what refactoring is for
<terinjokes>
true. currently debating on if i want to commit, or wait until tomorrow night to do some refactoring and then do so
<rankao>
If the code works. Commit then refactor.
<rankao>
Especially if you got tests
<terinjokes>
yeah, that's next...
<terinjokes>
and then seeing how difficult it is to hook zig code up to afl
ltriant has joined #zig
<rankao>
I'm not very good with initialisms out of context. What is afl?
<terinjokes>
american fuzzy lop, a security fuzzer
ltriant has quit [Ping timeout: 258 seconds]
<terinjokes>
i forgot libFuzz is in llvm, so maybe easier than I initially thought
rankao has quit [Remote host closed the connection]
ltriant has joined #zig
ltriant has quit [Ping timeout: 240 seconds]
<andrewrk>
daurnimator, `packed` not `extern` for bit fields
ltriant has joined #zig
SimonNa has quit [Quit: Leaving]
ltriant has quit [Ping timeout: 268 seconds]
_Vi has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
<D3zmodos>
Are there any plans to support function overloading? If not, what's the justification? I understand the lack of operator overloading because it hides code but surely that alone doesn't quite cover function overloading (since different overloads are identifiable at the call site)?
<hryx>
D3zmodos: a GitHub issue search reveals several rejected proposals related to function overloading
<D3zmodos>
hryx: Ah, I checked the docs but didn't think to check github. Thanks!
<hryx>
D3zmodos: no problem! The github issue tracker has an absolute wealth of history regarding language changes
marmotini_ has quit [Remote host closed the connection]
ltriant has joined #zig
ltriant has quit [Ping timeout: 265 seconds]
_Vi has quit [Ping timeout: 260 seconds]
mforney has quit [Ping timeout: 260 seconds]
ltriant has joined #zig
hoppetosse has quit [Quit: No Ping reply in 180 seconds.]
ltriant has quit [Ping timeout: 268 seconds]
mforney has joined #zig
ltriant has joined #zig
ltriant has quit [Ping timeout: 268 seconds]
return0e has joined #zig
frmdstryr has quit [Ping timeout: 265 seconds]
neceve has joined #zig
Astronothing has joined #zig
metaleap has joined #zig
_Vi has joined #zig
ltriant has joined #zig
<daurnimator>
andrewrk: that's the issue I was on before: if you have a C struct it can have bitfields
<daurnimator>
andrewrk: if you want to translate it to a packed struct then you need to know details of the target (including width of things)
ltriant has quit [Ping timeout: 265 seconds]
<daurnimator>
If `extern struct` supported bitfields then it can be done at zig compile-time (vs at translate-c time)
Astronothing has quit [Ping timeout: 258 seconds]
dddddd has joined #zig
bheads has quit [Quit: bheads]
marijnfs has joined #zig
bheads has joined #zig
Astronothing has joined #zig
frmdstryr has joined #zig
<betawaffle>
is there somewhere i should be looking at for differences between current master and 0.5.0, besides the git diff?
<betawaffle>
something like in-progress release notes
<betawaffle>
as an example, it seems like @typeOf is now @TypeOf?
<betawaffle>
also totally unrelated question: is it safe to await a frame in two threads simultaneously?
Astronothing has quit [Ping timeout: 258 seconds]
<scientes>
betawaffle, i don't think so
<betawaffle>
is there some code i can read to see what await actually does under the hood?
ltriant has joined #zig
ltriant has quit [Ping timeout: 265 seconds]
Astronothing has joined #zig
dimenus has joined #zig
<fengb>
Async functions can only be awaited once
<betawaffle>
what's the interaction between await and resume/suspend?
Astronothing has quit [Ping timeout: 265 seconds]
<fengb>
Resume/suspend is a lot more low level. You need those to build primitives, like IO, but you consume existing async functions with await
metaleap has quit [Remote host closed the connection]
<fengb>
I believe await is equivalent to “suspend until the async function is complete and then get that return value”
<betawaffle>
is there a difference between [*]const u8 and [*:0]const u8 ? are they both pointers to null-terminated arrays?
<fengb>
Only the latter is null termination
<fengb>
The former might be but that’s only if you converted an existing null terminated array so it’s unreliable
<betawaffle>
so, how does one safely call this: pub fn openat(dirfd: i32, path: [*]const u8, flags: u32, mode: usize) usize
<fengb>
Hmm that signature might be old and forgot to annotate null terminated
<betawaffle>
it has a todo to that effect, yeah
<fengb>
It was recently introduced and we may have missed some sites
<betawaffle>
ok so the idea in that case is... it used to be "caller is expected to do the right thing" and the new way can help enforce that?
<fengb>
Yep
<fengb>
Passing in a null terminated string will auto coerce into the non-terminated pointer so it’s a typecheck issue but you can still use it
<betawaffle>
but it's not like you get any of that safety in C, anyway
<fengb>
Well we only set C as a bare minimum baseline. We can be better :P
<betawaffle>
so far i'm loving zig. just wish it had fewer compiler crashes
<fengb>
Yeah it’s been pretty unstable. Unfortunately that won’t be a very high priority until stage 2
<betawaffle>
what's holding up stage2?
<betawaffle>
or i guess, what's higher priority than stage2?
<fengb>
Lots of language changes. Old async was blocking a lot of functionality, and andrewrk didn’t want to work on it without more language stability
<betawaffle>
is there a tracking issue or something for what's blocking stage2?
<betawaffle>
*still blocking
BaroqueLarouche has joined #zig
<fengb>
I don’t think anything is directly blocking anymore
<fengb>
Based on a recent stream, the priority is: fix some result location bugs, async OutStream, then package manager or stage 2
<betawaffle>
i'd be interested to see someone write a zig kernel that supports SMP
<fengb>
Are you volunteering? 🙃
<betawaffle>
i want to learn how to do that, so yeah
<betawaffle>
i have a job, so it'll be slow-going, of course
HesamR has joined #zig
<fengb>
Is there a way to rm -rf the cmake build directory while also preserving original flags?
<mikdusan>
you mean remove adir recursively *except* for adir itself?
ltriant has joined #zig
<fengb>
I want to do something like `make distclean`. cmake recommends deleting the build folder, but I have some flags that I always want to use
ltriant has quit [Ping timeout: 245 seconds]
kristoff_it has joined #zig
mahmudov has joined #zig
<SyrupThinker>
> i'd be interested to see someone write a zig kernel that supports SMP
<SyrupThinker>
On it (: I won't promise anything though ;D
Astronothing has joined #zig
doublex has quit [Ping timeout: 260 seconds]
doublex has joined #zig
Akuli has joined #zig
metaleap has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
return0e has quit [Ping timeout: 265 seconds]
Astronothing has quit [Ping timeout: 258 seconds]
ltriant has joined #zig
doublex has quit [Ping timeout: 258 seconds]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
ltriant has quit [Ping timeout: 265 seconds]
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
<Snektron>
fengb, arent the flags stored in CMakeCache.txt?
<Snektron>
If so, you could probably delete everything but that
<Snektron>
maybe
<Snektron>
dont quote me on that
<Snektron>
Why do you want to remove the cmake build dir if i may ask? Shouldn't that update itself automatically?
<fengb>
Sometimes the cache is wrong, and there's no `make distclean` equivalent
<fengb>
The recommended approach is to delete the build folder entirely, but that means I gotta lookup those flags
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
rankao has joined #zig
doublex has quit [Read error: Connection reset by peer]
<andrewrk>
fengb, my solution to this is a long shell history file and ctrl+r search for cmake
doublex has joined #zig
<andrewrk>
I don't think cmake has a better answer to this question. you can remove the CMakeCache.txt file but I've run into times when removing the entire dir was necessary
<rankao>
So Andrew I watched your talk about how Zig came to be, and I've notice a bit more features like async tooling and such as `suspend` and `resume` added to the language. Why was that added into the language versus STDLib? Do you have a blog or a write up you talked about that?
<rankao>
I've also watched a few of your youtube videos on async stuff, but I haven't finish them all. So if that question is answered there I'll get to that eventually
<mikdusan>
fengb: are the flags you want to preserve well defined enough to put into a sep file?
<fengb>
andrewrk: any chance we can make "ZIG_SKIP_INSTALL_LIB_FILES" the default? 😇
<rankao>
Okay. After reading that I'm going to re-watch your Async youtube coding sessions. Though I'm kind of glad I watched them first since I think this makes it make more sense.
<fengb>
Yeah, it's just been bugging more now that I have 2 flags (ZIG_SKIP_INSTALL_LIB_FILES and CMAKE_PREFIX_PATH)
<mikdusan>
so I just tried this and seems to work:
<mikdusan>
create a foo.script file, put in things like:
<mikdusan>
set(ZIG_SKIP_INSTALL_LIB_FILES on CACHE BOOL "")
<mikdusan>
set(ZIG_ENABLE_MEM_PROFILE off CACHE BOOL "")
<rankao>
And after reading the single threaded mode code it makes sense why just have it part of the language. Because if I compile it for a micro controller each async function call will simply be blocking instead of whatever it was before.
<mikdusan>
then launch cmake with all usual args *except* those: cmake ... -C foo.script
<andrewrk>
fengb, I think there's a good case to be made to do that. It will mean requiring non-default settings for package maintainers, but they're used to that.
<andrewrk>
I'm annoyed at cmake because if they just allowed running a custom command on the install target, we wouldn't need a config setting at all
<fengb>
Oh I didn't realize it'd interfere with packaging. I was just confused that I always had a duplicated library that desyncs
<andrewrk>
if you think about it, making a duplicated library that desyncs is exactly what "installation" is
<fengb>
But I didn't ask for installation heh
<andrewrk>
yeah I agree your default choice makes more sense
<fengb>
I'm not sure why I added 'heh' there. That sounds weird
<andrewrk>
rankao, that's nearly correct. single threaded mode is related to async functions only in that `await` and `return` longer use atomic operations for synchronizing
<andrewrk>
the setting that controls whether various parts of the standard library are blocking or evented is a userland concept: std.io.mode
<rankao>
I see.
<andrewrk>
it can be specified in the root source file
<gonz_>
Does anyone have a solution for the watch windows on Windows not being able to actually bind to the actual values? They show up in "locals" but it seems impossible to do anything within the watch window.
<BaroqueLarouche>
gonz_: VS Code ?
<Snektron>
fengb the zig build root is not in ny path at all, so also installing lib files seems like the appropriate way?
<gonz_>
VS Code, VS, anywhere really.
<gonz_>
I haven't checked WinDbg lately but I assume it's the same.
<gonz_>
I seem to remember this working at some point, but I'm also curious what other peoples' experience is.
<fengb>
Snektron: I wired my build zig to my path, and it works with and without the lib copy. But with the lib copy, I need to run make every time I make a change to std
<gonz_>
Since we interact fine with locals, it seems super weird that we can't bind even to the same values in the watch window...
<fengb>
daurnimator pointed out that there's a flag to prevent the lib copy, which works really well but it's an extra step to remember
SimonNa has joined #zig
<BaroqueLarouche>
gonz: I was able to use the watch window in some case in VS Code, but it doesn't always work
Astronothing is now known as alexpana
Snetry has quit [Quit: left Freenode]
<fengb>
I'm actually impressed at how the zig executable works well no matter which path it's in
alexpana has quit [Quit: Leaving]
Snetry has joined #zig
<gonz_>
BaroqueLarouche: It's unfortunate; there doesn't seem to be much reason for zig to be such a "meh" debugging experience atm.
alexpana has joined #zig
<andrewrk>
gonz_, does it work with C code from a clang binary?
<gonz_>
andrewrk: Haven't checked, but I'll make sure to
kristoff_it has quit [Ping timeout: 258 seconds]
<Snektron>
When i work on zig i usually run `ninja` instead of `ninja install`
<Snektron>
afaik that stops copying
<Snektron>
or did you mean to the build directory? because i'm not sure about that
<Snektron>
but i don't notice any problems with it
<gonz_>
andrewrk: Is there any logic that might point to private functions not having the same debugging info as public ones?
<gonz_>
Actually, nevermind; it's not that.
nocko` has quit [Remote host closed the connection]
doublex has quit [Ping timeout: 240 seconds]
kristoff_it has joined #zig
doublex has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
<fengb>
Snektron: yeah, by default make (and I'd guess ninja) copies lib/ into build/ so if I'm actively working on lib then it desyncs until I run make again
<nocko`>
Any suggestions / comments highly appreciated.
HesamR has quit [Ping timeout: 240 seconds]
marmotini_ has joined #zig
<nocko`>
There's a few janky parts. I link libc basically just for a default allocator. I could just hard code a FixedBufferAllocator for this particular case... but that's weird too.
<nocko`>
Anyway. It's being used on mipsel. Tier-2; no arch issues came up during development. So, that's cool.
kristoff_it has quit [Ping timeout: 265 seconds]
<nocko`>
I think that's a pretty new thing (being tier-2). IDK how many users is has, but totally painless.
marmotini_ has quit [Ping timeout: 240 seconds]
<scientes>
cool
nocko` has quit [Read error: Connection reset by peer]
nocko`` has joined #zig
<metaleap>
question time: i'm new to non-GC / manual mem-mgmt. how can i best intuit when to `deinit()` something and when not to. especially when I don't know what Allocator is passed to my lib. consider this example: https://gist.github.com/metaleap/244268f50ab5b466809460ada68becaf --- clearly the first `deinit` ln3 is necessary, I passed my Allocator to some consumed lib's `.init` constructor-like func. the next `deinit` ln5 already less sure about but it doesnt
<metaleap>
cause any faults. the last one ln7 (commented-out) would segfault however. but here that `deinit` is just "inherited" from `array_list.AlignedArrayList` that `std.json.Array` aliases. having read lifetime-and-ownership section in zig's langref doc, I'm none the wiser. how would seasoned C (and/or Zig) devs illuminate the generally applicable path-of-reasoning here for otherwise-experienced devs coming from some GC stack like Go / C# / Java etc?
<metaleap>
note the segfault occurs exactly on the ln#7 deinit call, which from defer would be scheduled before the (potentially otherwise conflicting) others, and there would be no accesses-to-this-arraylist occurring afterwards anyway, tho it doesnt get to "afterwards"
<fengb>
You should deinit any resource that you used but aren’t exposing
<nocko``>
Not my area of expertise. Initial thought is that a slice always refers to a backing array... You're returning a reference to a slice from rootarr, but the memory for rootarr is destroyed at the end of the function.
alexpana has quit [Ping timeout: 268 seconds]
<fengb>
The last line indicates you are returning the memory so it’s up to the caller to own that space
alexpana has joined #zig
<betawaffle>
metaleap: have you run it in a debugger yet?
<betawaffle>
i think we need to see what `as` does in this case, if the segfault is really coming from rootarr.deinit()
<betawaffle>
that would indicate something about rootarr is invalid from the start
<metaleap>
fengb: no it doesnt, the call in the last line gets the Allocator but returns either error or some own created slice
<metaleap>
nocko``: i'm not returning a slice from rootarr, i'm passing it to a call whose return is returned
<fengb>
oh right, the mem variable name threw me off
<metaleap>
defer would (or should!) only occur after that final call
<nocko``>
hmm. Interesting.
<metaleap>
betawaffle: added the (tiny & trivial) `as` to the gist, doesn't really "do" anything other than tag/type-switch-or-err
<fengb>
Looks like you'd effectively be doing both jsontree.root.deinit() and jsontree.deinit()
<metaleap>
(can also note that the final call itself, that gets the `Allocator`, doesnt do any `deinit`s directly or indirectly, merely allocates new slices for the result structures)
<betawaffle>
ok, so the fromJson(...) is getting called, returning, and then the last defer is the first thing to run, and fails?
<metaleap>
fengb: yeah. that could be troublesome, will double-check the `std.json` code whether the latter already does the former. still surprised that the segfault is on the "first" (last in code positioning) of the 3 defer'd deinits
<fengb>
I'd expect toplevel deinit() also invokes all the children deinit(), which would cause a double free
<fengb>
We don't have good double free detection (yet)
<metaleap>
fengb: i get that but scratching my head (as a side-quest i guess) why it would fault on the inner ("first" aka last) deinit rather than a (later) "top-level" one
<gonz_>
BaroqueLarouche and anyone else who might be interested: RemedyBG has added better clang support and actually works with local values much more reliably in my limited testing than VS
<gonz_>
Arbitrary watch values seem to just work. Presumably this is just a clang thing, then.
<betawaffle>
metaleap: run it under gdb or lldb?
___ has joined #zig
<betawaffle>
i don't really understand that "address 0x3" part...
metaleap has quit [Remote host closed the connection]
<metaleap>
havent yet, will try
<BaroqueLarouche>
gonz_: Nice!
<betawaffle>
i mean, that would segfault, for sure. just not sure why it would try to deref that
<betawaffle>
unless that's some sort of bug in the segfault printing
<gonz_>
BaroqueLarouche: Granted, since I haven't really been able to use RemedyBG much before I have no idea what *other* issues it has.
<betawaffle>
hmm, did metaleap leave?
<mq32>
betawaffle, yep
<___>
betawaffle: had a disconnect but should be back on?
<betawaffle>
ok
ur5us has joined #zig
<___>
ooh i got a new nick, used to be metaleap. dangit
alexpana has quit [Ping timeout: 240 seconds]
___ has quit [Client Quit]
<betawaffle>
my crazy idea is that `self.allocator` is null
metaleap has joined #zig
<mq32>
/nick metaleap
<mq32>
helps
<metaleap>
betawaffle: am back, had a disconnect, trying with lldb
<betawaffle>
the 0x3 address and the `std.array_list.AlignedArrayList(std.json.Value,null).deinit` makes me think the allocator is null
<betawaffle>
oh i see, that second param is just alignment
<betawaffle>
heh, yeah it's just a null pointer deref
<metaleap>
so must be somewhere in array_list.AlignedArrayList.deinit so must be its self.allocator
<betawaffle>
metaleap: what version of zig are you using?
<metaleap>
2-3 days ago --- 0.5.0+84e98405d
<metaleap>
so if self.allocator is null the std.json package must have passed to the array_list's init a null allocator from what i can tell skimming the array_list src
<betawaffle>
can you set a breakpoint just before the deinit and step in?
<metaleap>
ok hang on
<betawaffle>
i mean, in theory that shouldn't be possible
<metaleap>
btw i just out-commented in (my local) std.array_list.zig the offending line in deinit and the segfault of course goes away, so you sure this is even the point to breakpoint? at that point the null is already fact
<betawaffle>
well... we don't know it's null
<betawaffle>
we want to confirm or deny that
<betawaffle>
basically we want to see if self.allocator is 0
<betawaffle>
(which shouldn't be possible)
<metaleap>
ok 1 more thing, did you notice in the gist of the segfault the "/home/_/a/zig/lib/zig/std/special/c.zig:81:0: 0x3 in std.target.Target.isDarwin (c)" reference. well i'll try breakpointing now. not used to lldb/gdb so gimme a sec there with the man page
<betawaffle>
and if it's not null... then i'm confused about what's going on
<betawaffle>
yeah, that's the panic function, called from the segfault handler, i assume
doublex has quit [Ping timeout: 265 seconds]
alexpana has joined #zig
<betawaffle>
actually... maybe that's just the stack trace bug?
<metaleap>
so for `break` needs absolute `.zig` path?
<betawaffle>
dunno, i'm not very familiar with lldb (nor gdb)
<betawaffle>
i think it supports multiple things, including addresses
doublex has joined #zig
<metaleap>
betawaffle: just stepped into the deinit! stay tuned =)
* betawaffle
doesn't touch that dial
<fengb>
You could lldb run the program, and it'll catch the seg fault and let you trace the stack
<betawaffle>
he already did that
<betawaffle>
we know the stack, we're trying to figure out the state of a variable
<fengb>
You can navigate the frame upward once it crashed
_Vi has joined #zig
<fengb>
And get to the function context with the null. No need to pre setup debugging points for that
<metaleap>
so here's what happens, it jumps into std.mem.Allocator.free line 233, goes on ok for 234-236, then at 237 the next `step` gives these 3 lines: `signal SIGSEGV: invalid address (fault address: 0x3)`, `frame #0: 0x0000000000000003`, `error: memory read failed for 0x0`. again thats line 237 in std.mem.Allocator.free
<fengb>
At the crash, can you print the backtrace? (lldb) bt
<fengb>
And navigate to the right frame — (lldb) up [n]
<metaleap>
now that would also mean the top-level deinit would *not* call the std.json.Array's deinit! else it would have occurred always
<metaleap>
(well, possibly)
<betawaffle>
also... it seems like we could improve the stack traces on segfaults some
<betawaffle>
it'
<betawaffle>
it's missing the last frame at least
<fengb>
Might be a red herring. Can you try `up 1` => `po *self` again?
<metaleap>
fengb: po or p?
<fengb>
ArenaAllocator.free() is a noop so this shouldn't be invoking anything
<fengb>
p, sorry
<metaleap>
so the up 1 jumped back to arraylist's deinit ln 54 and then p *self gives: indirection requires pointer operand ('std.array_list.AlignedArrayList(std.json.Value,null)' invalid)
<fengb>
Zig uses non-pointers when we don't need a ref. The compiler can optimize that into "pass by const ref" or "pass by pointer" depending on which optimizes better
<betawaffle>
so `p *self.allocator`
<betawaffle>
do*
leeward has quit [Ping timeout: 258 seconds]
<betawaffle>
just want to make completely sure...
<betawaffle>
i don't understand where those function addresses came from
<fengb>
Yeah 0x3 is a weird function pointer address. I don't think that's even valid sicne it's unaligned
<betawaffle>
it's not, and it's in the zero page
<andrewrk>
an address like 0x3 happens when you take the address of a struct field, based on a null struct pointer
<metaleap>
some tmp rubbish in the middle as i got the hang of zig things, never mind that
<betawaffle>
sure does look bog-standard
<fengb>
So uh... based on your code, you never have to call free() if you know it's in the arena
<fengb>
That doesn't exactly solve this problem, but it could simplify your strategy
<metaleap>
but the func called at the end of main, which i shared originally in the gist, is supposed to become a lib that wont know the nature of the allocator
<fengb>
So a trick that we can do is if you only have 1 entrypoint into your library, then it can create an arena at the beginning and that could be the only site that exposes the allocation
<fengb>
It doesn't really teach you about lifetimes though as it more or less works around them
<metaleap>
could do as a workaround, but then i can also keep the original offending deinit call commented as another workaround :D see I was just trying to learn if I did that part wrong and if so, why
<betawaffle>
metaleap: let's set a breakpoint before load.FromJson to see what's in the allocator
traviss has quit [Ping timeout: 260 seconds]
<andrewrk>
I'm not sure std.json.ValueTree is meant to be copied
<metaleap>
so we still have the question mark why the std.mem.Allocator $2 above is evidently null at least as indicated by the 0x3 / 0x8 etc addrs?
<betawaffle>
we'll it's the arena init that's setting those values
<betawaffle>
which makes basically no sense
<metaleap>
ok so I'll set a breakpoint just before load.FromJson 1 sec
<andrewrk>
`as(std.json.Value.Array, std.json.Array, jsontree.root)` would be better written `switch (jsontree.root) { .Array => |*array| { ... }, else => return error.BadJsonSrc }`
<andrewrk>
yes also rootarr.deinit() is invalid. Appears to be undocumented, but the owner of all the memory of the array lists is the arena which is freed by jsontree.deinit()
<betawaffle>
afaict, that's what should be in your allocator
<andrewrk>
arguably these should be slices rather than std.ArrayList since they don't manage their own memory, and aren't resizable
<andrewrk>
but maybe that's for writing json
<andrewrk>
anyway correct fix is to delete the commented out code
<betawaffle>
well, but there's also a bug elsewhere, isn't there?
<metaleap>
andrewrk: thx for chiming in and clarifying the "appears to be undocumented" bit =) good to know. so then if the valuetree's deinit takes care of all its inner alloc'd `json.Value`s its odd that the same fault didnt occur *there* --- but dunno, it's all still WIP i guess
<metaleap>
ah guess because it has an inner arena itself, ok
<metaleap>
betawaffle: so at that breakpoint i get "more normal i guess" addresses 0x0000000000225460 and 0x0000000000225630 for reallocFn and shrinkFn
<metaleap>
so that gets degraded at a later point. suppose i step and re-check per line in load.FromJson for giggles..
<andrewrk>
metaleap, do you know about hardware watch points?
<betawaffle>
yeah. also, it could be a different allocator at that point?
kristoff_it has joined #zig
<andrewrk>
if not this would be a good time to invest in learning how to use them, they're amazing
nocko`` has quit [Remote host closed the connection]
<metaleap>
i'll make a note for that. first line of load.fromJson the passed *Allocator still prints the same 2 addrs.. stepping further
ltriant has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
<metaleap>
well so the rootarr.allocator is a pointer to an address different to my own allocator, so some std.json internal circus. thx to all for bearing =)
<andrewrk>
oh look at that, apparently I already solved this but needed the async rewrite first
<metaleap>
ok i see. probably after my whole initial load stuff completes, i'll free / ditch my arena and make a new one for the rest of the run time then
_Vi has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
<metaleap>
last newcomer Q for the night: to clarify re andrewrk's earlier suggestion on my tag/type-`switch`ing: if I do say `switch (unionval) { ArrayListTag => |arrlist| fooSomeCodeHere(arrlist), else => unreachable }` unless I explicitly do pointer-notation as in |*arrlist| there'd be a copy made for the successful `switch` case?! ie whether struct or array or whatever, it doesnt operate directly on the union location but the |var| is a value copy, i mean
<metaleap>
within / inside the switch case (ignoring / excluding any passing-to / returning-from any calls)?
<metaleap>
I'd have expected whatever capture-name is given would refer to the same location as the union-val being scrutinized
<metaleap>
(as in, "same, just-now-properly-typed")
<daurnimator>
andrewrk: did my reply re: extern bitfields vs packed bitfields make sense?
<fengb>
Right now I think |val| is no copy due to result location changes. This has been a footgun so we might be migrating
<mikdusan>
`arena` is stack. transition() does stuff, creating Array for example that retains `&arena.allocator`
<metaleap>
mikdusan: but only Parser.stack gets deinit'd it's not like the whole inner arena gets cleared except in case of errdefer.. well i'm off, not seeing the forest for the trees anymore
<mikdusan>
if you remove all defers (other deinit) ...and put in a manual `root.deinit()` it faults
<daurnimator>
mikdusan: ah yes. looks like the old parser tree bug :)
metaleap has quit [Quit: Leaving]
<daurnimator>
metaleap: did you get a chance to try the autojson branch?
<daurnimator>
bah missed them by a second.
kristoff_it has joined #zig
alexpana has quit [Read error: Connection reset by peer]
kristoff_it has quit [Ping timeout: 260 seconds]
<Snektron>
irc moment
neceve has quit [Read error: Connection reset by peer]
<fengb>
We definitely need pointer to stack escape analysis >_>
<andrewrk>
agreed
<andrewrk>
also explicit allowing/disallowing of aggregate types will help with this
<andrewrk>
s/of/copying of/
ltriant has quit [Ping timeout: 268 seconds]
ltriant has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
kristoff_it has joined #zig
Snetry has joined #zig
dimenus has quit [Ping timeout: 260 seconds]
kristoff_it has quit [Ping timeout: 258 seconds]
ur5us has quit [Quit: Leaving]
<daurnimator>
Is riscv freestanding meant to work?
<Snektron>
I triggered a "put into full map" unreachable in HashMap, but im not quite sure what to make of it
<fengb>
andrewrk: do you get less money on donation if I use credit card vs bank?
* daurnimator
has never understood linker scripts; so I was trying to avoid them
<daurnimator>
fengb: via github? I think github eat all the fees
<andrewrk>
fengb, I don't think I can tell the difference; github is eating the fee for now afaik
<mikdusan>
this one: Test [1/10] test "optional pointer to size zero struct"...test failure ; running same test executable from cache, 50/50 chance; maybe I need ECC memory :P
<fengb>
Oh okay that works too
<andrewrk>
mikdusan, I'm getting all behavioral tests valgrind clean in 27755f1431e6df
<mikdusan>
ok I'll try on archlinux
<Snektron>
ah, found the problem
<andrewrk>
mikdusan, I've been force pushing to that branch fyi
<mikdusan>
yup i have 27755
<Snektron>
`const e = spec.enums.get(enum_name).?.value;`
<andrewrk>
mikdusan, oh - valgrind reports a problem with "optional pointer to size zero struct" when I run the behavioral tests
<mikdusan>
if I played bingo I'd yell something out right now
<andrewrk>
I forgot about runtime, oops :)
<andrewrk>
this warning is fun to see:
<andrewrk>
Test [488/786] behavior.new_stack_call.test "calling a function with a new stack...==14005== Warning: client switching stacks? SP change: 0x1ffeffc550 --> 0x339500
<andrewrk>
why yes valgrind, thank you
<mikdusan>
heh wow
urluck has quit [Remote host closed the connection]
urluck has joined #zig
<daurnimator>
andrewrk: do we need to emit some valgrind annotation to silence that warning?
<andrewrk>
not if that feature ends up getting scrapped before 1.0
<andrewrk>
this branch has been considerably easier to debug
<andrewrk>
I think it is an improvement
<andrewrk>
adding ZigValue::dump() helped a lot
ltriant has quit [Ping timeout: 265 seconds]
<andrewrk>
mikdusan, fixed with a force push, good catch, thanks
<andrewrk>
hopefully it's just this one test from misc.zig left + whatever is causing std lib tests to crash
<frmdstryr>
Is there any way to cast a bound function to a function that doesn't take arguments?
<frmdstryr>
Want to use a struct method as an IRQ handler and hoping to not have to use a lookup table
<daurnimator>
frmdstryr: bound functions tend to crash the compiler if you do much with them
<andrewrk>
you'll be better off pretending that zig doesn't have bound functions for now