<tdeo>
just double-checking i'm not missing anything
<andrewrk>
great! no task on our end then :)
<tdeo>
sounds good
mikdusan has joined #zig
leon-p has quit [Quit: leaving]
reductum has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
allan0 has quit [Ping timeout: 256 seconds]
allan0 has joined #zig
a_chou has joined #zig
earnestly has quit [Ping timeout: 264 seconds]
xackus__ has joined #zig
drawkula has joined #zig
yeti has quit [Ping timeout: 265 seconds]
drawkula is now known as yeti
a_chou has quit [Remote host closed the connection]
a_chou has joined #zig
<tdeo>
the nth time i only realize i should add tests after i open the pr...
<andrewrk>
it's all good, thanks for following up with a test case
earnestly has joined #zig
reductum has quit [Quit: WeeChat 3.0]
gazler_ has joined #zig
gazler has quit [Ping timeout: 272 seconds]
xackus has joined #zig
xackus__ has quit [Ping timeout: 264 seconds]
xackus has quit [Ping timeout: 272 seconds]
xackus has joined #zig
xackus_ has joined #zig
xackus__ has joined #zig
xackus has quit [Ping timeout: 256 seconds]
xackus_ has quit [Ping timeout: 272 seconds]
ur5us_ has joined #zig
ur5us_ has quit [Remote host closed the connection]
ur5us_ has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
g-w1 has quit [Ping timeout: 256 seconds]
g-w1 has joined #zig
ur5us_ has joined #zig
plumm has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
ky0ko has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
ur5us_ has quit [Ping timeout: 264 seconds]
a_chou has quit [Remote host closed the connection]
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
plumm has joined #zig
wilsonk_ has quit [Read error: Connection reset by peer]
jukan_ has quit [Ping timeout: 272 seconds]
plumm has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
SimonNa has quit [Ping timeout: 240 seconds]
SimonNa has joined #zig
sord937 has joined #zig
tnorth_ has joined #zig
notzmv has quit [Read error: Connection reset by peer]
dyeplexer has joined #zig
jukan has joined #zig
jukan has quit [Ping timeout: 246 seconds]
leon-p has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
cole-h has quit [Ping timeout: 240 seconds]
dyeplexer has quit [Read error: Connection reset by peer]
dyeplexer has joined #zig
craigo has joined #zig
zags has joined #zig
geemili has quit [Ping timeout: 272 seconds]
dyeplexer has quit [Ping timeout: 240 seconds]
dyeplexer has joined #zig
wilsonk has joined #zig
caolanm has joined #zig
<caolanm>
I seem to remember seeing an easy way to turn C error codes from a .h file into zig errors but now I can't find it and I'm starting to think I imagined it.
<caolanm>
Does anything like that exist? or do I just make a switch block to convert those codes to zig errors?
zags has quit [Ping timeout: 272 seconds]
zags has joined #zig
<ifreund>
caolanm: I don't know of anything like that, though you may be able to implement something with comptime reflection
<ifreund>
I'd just go with a switch myself, much simpler
<ifreund>
mikdusan: oh, builtin.StackTrace has a fomat() function defined of course
<mikdusan>
ugh ! black magic I tell ya
<mikdusan>
thanks
<ifreund>
no problem!
<marler8997>
ifreund, interesting, the 2-float struct works if I define the function in Zig, even with callconv(.Stdcall), so Zig current implementation actually works, it's just different from the C specifiction right now...lol
<ifreund>
marler8997: interesting indeed, it should be a compiler error though tbh since doing the wrong thing silently is worse
<marler8997>
yeah that would definitely be an improvement on the status quo
kchambers has joined #zig
<mikdusan>
error trace behavior I'm seeing is this: the error stack is _reset_ only after the return of a fn which does not return error-union, otherwise it is accumulated
<mikdusan>
but this can't be right
<mikdusan>
if it were, a worker queue that catches errors would grow infinitely
<ifreund>
i'm pretty sure that's accurate :/
donniewest1 has joined #zig
jaens[m] has quit [Quit: Idle for 30+ days]
halbeno_ has quit [Remote host closed the connection]
halbeno has joined #zig
zags_ has joined #zig
jukan has joined #zig
zags has quit [Ping timeout: 246 seconds]
cole-h has joined #zig
xackus__ has quit [Read error: Connection reset by peer]
<mikdusan>
main changes: notry -> catch, continue -> try, and added ability to inspect an error without modifying error-stack before propagation (`raise;`)
<mikdusan>
i'm a bit on the fence about partial #1923-like behavior. the alternative can be to remain explicit. and allow `raise <error-union>`
<mikdusan>
ie: same as `try <error-union>` except that instead of merge/propagate it becomes reset/propagate with `raise <error-union>`
geemili has joined #zig
<ifreund>
mikdusan: interesting proposal, I wonder if the features propsed in #5610 could be worked into it, it kind seems to go in the opposite direction
<ifreund>
or at least if the use-case could be supported, doesn't matter to me exactly how
<mikdusan>
oh i haven't seen that one. reading.
wilsonk has quit [Ping timeout: 256 seconds]
<ifreund>
also I'm assuming that in your proposal errdefers no longer get run on `return error.Foo` only on `try error.Foo`?
<mikdusan>
correct. return is no longer anything to do with error-handling.
<mikdusan>
that was my primary motivation -- get rid of that ambiguity
<ifreund>
yeah it looks like your proposed changes would make error stack traces much cleaner
<mikdusan>
ifreund: if you `break :blk err;` do we need capture? `} catch |err| {`
<mikdusan>
hmm I guess not. it's consistent today that catch is unambiguous and can choose not to capture
<ifreund>
yeah, assuming the current error semantics, the block would evaluate to an error union, which is a valid lhs for catch
<ifreund>
there would be no difference between using catch on a block and using it on a function returning an error union
<mikdusan>
so back to orig question... looks like proposals are orthogonal; and #5610's try overload does not interfere with my pending proposal, and new reset error-stack semantics doesn't interfere with 5612
<ifreund>
yeah after looking at yours more I agree
<ifreund>
I think the big downside to your proposal (which isn't listed) is that it introduces new semantics. (for example, `try foo` is not longer simple sugar for `foo catch |e| return e`
<mikdusan>
yeah in the latest rev, `try <errorset>` is new. but `try <error-union>` is unchanged
<ifreund>
it's no longer sugar for return though right? it's something else
<mikdusan>
by unchanged I mean the new sugar is `foo catch |e| try e;` but it's still the same thing
<ifreund>
ah I see
<mikdusan>
i know it does look odd. hey `try` is sugar for `something something try` looks recursive
<mikdusan>
it's either that or new keyword?
<fengb>
Why raise and not throw? 🙃
<fengb>
Lets reinvent C++/Java exceptions :P
<mikdusan>
fail/raise/throw blah
<ifreund>
also it feels inconsistent that `raise` with no operand leaves the stack unchanged while `raise` with an operand resets it
<mikdusan>
ifreund: true; I have to put something in that is parsable for the compiler. I would not be opposed to new keywords vs these overloads
<mikdusan>
as an aside, `raise;` is something I would expect to be pretty rare.
<ifreund>
more keywords is better than excessive overloading/inconsistency IMO
<fengb>
I'm confused by the difference between `try err` and `raise err`
<fengb>
Oh reset == reset the stack, so it looks like a new error?
<mikdusan>
yes, when raise has an arg, it is reset,push,propagate error-stack.
<mikdusan>
try is today's behavior of.. keep pushing on the error-stack and propagate
<fengb>
I'm not a fan of raise [noargs] behaving differently. imo, it's just easier to remove it and force you to `try err`
<mikdusan>
but `try err` adds to the error-stack.
<fengb>
Oh
<mikdusan>
i know it's a small case. edge case. but it would be slick if we can just... inspect, log, and re-propagate
<fengb>
Yeah I get it, but it feels weird that raise [noarg] is radically different from raise err
<mikdusan>
reraise
<ifreund>
pass
<mikdusan>
or change to `fail` and `refail` respectively.
<mikdusan>
oh pass. interesting.
<fengb>
I like this direction. Clarifies a bunch of error cases and forces some self documentation. I had a much smaller scope proposal: https://github.com/ziglang/zig/issues/2562
<mikdusan>
yes I'll add references to both these proposals
<mikdusan>
and what you sight as motivation in #2562 is indeed the same motivation I had
pixelherodev is now known as noam
sord937 has quit [Quit: sord937]
<mikdusan>
though thinking more, 2562 addresses something else too -- `return try...` which sounds reasonable.
<mikdusan>
in my prop... hot take... would the equiv would need to be either `return catch author.getUser();` or `const rv = try author.getUser(); return rv;`
<mikdusan>
hmm.. no .. scratch taht. my prop doesn't want that.
<fengb>
Hmm why? `return try foo();` would unwrap the value if it's successful, and if not it'll auto raise
<mikdusan>
ah yes you are right. gawd, I panic'd there for a sec thought my whole prop would bite it.
<mikdusan>
nice. so 2562 is orthogonal to mine too. me likes.
<fengb>
Well your proposal would obviate the need for mine
<fengb>
Since it captures everything I wanted (no implicit returning of errors)
<mikdusan>
oh yeah, except I didn't include that syntax which you 2562 has. I'll incorporate it.
<mikdusan>
s/syntax/sample code/
nycex- has joined #zig
nycex has quit [Ping timeout: 268 seconds]
<zags_>
nice proposal, but raise is so short and sweet it's an invitation for people to start doing bad error handling (namely losing information about entry path to source of raise), where better option exists. Since it's for rare edge cases, it should maybe be called something truly ugly like reset_and_throw.
<fengb>
`tryhard`
<zags_>
and diehard to exit with the error? :D
<mikdusan>
tryharder
<mikdusan>
lol
<mikdusan>
so we have `usingnamespace` as a deterrent for abuse. so maybe just `raiseagain`
<mikdusan>
gut reaction: anyone like `fail` more than `raise` ?
<mikdusan>
(we all know `throw` is just no)
<fengb>
`throwup`
<ifreund>
I like fail more
<ifreund>
sounds less like "raise an exception"
<mikdusan>
yeah sounds thin.. like a primitive... not an object
<mikdusan>
I'm gonna swap it out and see how it looks
<tane>
isn't it strange to throw away fine buffer space or do I have a misconception about calling realloc with a smaller size than the pointer already points to?
<ifreund>
Yeah I think that sould keep the capacity
<fengb>
I think it wasn't obvious before so nobody paid attention until after the rename
dyeplexer has quit [Remote host closed the connection]
<marler8997>
mikdusan changes look great
<zags>
is there a way to convince godbolt to only include assembly for the pasted program, i.e. strip away stdlib stuff and such?
<marler8997>
the only way I know of is to remove references to stdlib stuff
<marler8997>
-strip might help as well, and -Orelease-small
<zags>
ReleaseSmall helps, but then it probably disables some of the very optimizations I wanna look at if they're happening :D
<zags>
it doesn't like -strip
<zags>
ah --strip
<g-w1>
add a panic handler
<zags>
-O ReleaseFast --strip gives the desired result
<zags>
g-w1: wdym? that will make the assembly output smaller?
<mikdusan>
pending #7812 update. now using `fail` instead of `raise`. and added code samples `f2(), f3(), f4()` to show correct `return` usage for error-union, error-union as value, and error-union with nested error-union as value
<g-w1>
zags: right now it needs code to handle a stack trace on panic. overriding the default panic handler will make the output smaller. pub fn panic(message: []const u8, stack_trace: ?*@import("builtin").StackTrace) noreturn { while (true) {}}
plumm has joined #zig
<ifreund>
dch: that is for defining varargs functions in zig, not for calling such functions defined in zig
<ifreund>
*C
<zags>
g-w1: cool tip, thanks
<dch>
ifreund: yay, so I can use variadic functions freely without offending the compiler gods? \o/
<dch>
its the reverse that doesn't yet work, then
<ifreund>
dch: yeah, though iirc type checking of variadic parameters is either broken or not complete so be careful
<dch>
ifreund: I'm writing some very noob blog posts on using zig to talk to c, i'm somewhat new to this level of programming
<zags>
g-w1: so I'm supposed to put there anywhere top-level? Doesn't seem to compile, godbolt says "note: previous definition is here" but nothing else
<zags>
put that*
<g-w1>
oh, godbolt probably already does it :D
<zags>
aha
<zags>
i'm down to 431 assembly lines now, that's "fine" :D
<zags>
explains why it mysteriously put the red marker at the end of the document :D
<zags>
good to know about, thanks mate
nvmd has joined #zig
<ifreund>
dch: nice, always cool to see more stuff written about zig :)
<ifreund>
I've done quite a lot of Zig/C interop for my wayland compositor so if you have any other questions hit me up
<zags>
ifreund: both ways, so also exposing zig to C?
<zags>
what's the general pattern for making a .h file given a Zig file? Do I need to write wrappers or just annotate with extern?
SebastianM has joined #zig
<ifreund>
zags: All I've done has been using C from Zig not the other way around
plumm_ has joined #zig
<ifreund>
zig will eventually generate .h files for you, which I think is at least partially implmenent in stage2
<zags>
noice
<ifreund>
oh shit it totally works
<ifreund>
it's just kinda hidden
<ifreund>
zig build-lib -femit-h -fno-LLVM
<zags>
(exploding head emoji)
plumm has quit [Ping timeout: 246 seconds]
<ifreund>
well, I haven't tested it on anything other than a simple add function
tnorth_ has quit [Ping timeout: 264 seconds]
<noam>
Muahaha. ifreund: *now* I can actually state that my design uses less memory than even the AST rework :)
<tane>
ifreund, any hints on how to attack that `shrinkAndFree` => `shrinkRetainingCapacity` thing, should I post an issue or add a PR (for single line..)? :)
<noam>
Static 8+4n bytes per node, where n is the number of children
waleee-cl has joined #zig
<ifreund>
tane: just open a PR
<tane>
ok, thanks
<ifreund>
noam: how many nodes though?
<noam>
ifreund: same number
<noam>
I think... I'll have to check
<ifreund>
what did you change then?
<noam>
I dropped the extra_data, lhs, and rhs, and replaced it with nargs + arg_indexes
<noam>
Metadata is now included as a child node instead of being shown in a separate tree, but that might be a bad idea
<noam>
That's the last thing I still need to work out, really
<noam>
By keeping u32 alignment, I can just store nodes as a u32[], and any index is either a tag+nargs, a token_index, or the index of a kid
cole-h has quit [Ping timeout: 240 seconds]
<marler8997>
mikdusam this line needs corrected " // NEW: keyword `catch`, type is error-union"
zags has quit [Ping timeout: 256 seconds]
<marler8997>
since we switched to "catch", not a new keyword anymore
<marler8997>
I spelled your name wrong, mikdusan
<mikdusan>
updated
<marler8997>
in "Related proposals", you could mention that this proposal could be used to solve #2647
<marler8997>
well it doesn't solve, maybe say it would provide a syntax to solve #2647?
<marler8997>
so with "return catch doit()" does that mean errdefers won't execute?
<mikdusan>
tbh I haven't explored all the defer/errdefer permutations (which I should now do), but hot take is prefix-catch doesn't want error handling and no error is propagated. so if not propagated, then errdefer does not trigger
<marler8997>
so I'm a bit perplexed at what happens with return catch doit()
<marler8997>
maybe it should be an error to return an error union from a function?
<marler8997>
as a value
<marler8997>
like, if you catch the error union, you'd have to do something like fail catch doit()
<mikdusan>
there may not be a motivating case for it but if one can do this: `const x = catch doit();` then one is always free to do `return x;` and making `return (catch doit())` (parens added for clarity of expr) compile-error seems weird to me
SebastianM has quit [Quit: -a- IRC for Android 2.1.59]
<marler8997>
if you did return x, and x is an error, and errdefers don't run (your hot take), then what happens on the caller? Does their catch trigger?
<mikdusan>
error is gone
<marler8997>
how is it gone?
<marler8997>
it's an error-union value that is in an error state
<marler8997>
so what state is it in now?
<mikdusan>
the value exists. but isn't the question "are we error-handling" or "did we eat the error handling"?
<marler8997>
well I'm have a few questions now since you said that "the error is gone"
<marler8997>
say, doit returns error.Overflow
<marler8997>
and we return catch doit()
<marler8997>
but you're saying "return catch doit()" won't be returning error.Overflow?
<marler8997>
then what is it returning?
<marler8997>
if we make returning error unions a compile error, then it means that a function will only return an error if an only-if error handling has been triggered
<mikdusan>
yes. `const x = catch doit(); // x is union { error, u32 } without error handling/treatment
<marler8997>
otherwise, a function could return an error-union value in a error state, but error handling hasn't been triggered
<marler8997>
right I understand that part
<marler8997>
I'm talking about "return x" after that
<mikdusan>
bare with me. I'm slower than you.
<mikdusan>
ok so f3(). `return x;` and the callsite is `const foo = f3();` . it's allowed. it's not an error.
<marler8997>
one thing it could mean is "return catch doit()" would return an error up to the caller, but it wouldn't add an error on the error stack and errdefers won't run, so it would be a way to return an error without putting your function on the stack
<mikdusan>
notice f3() is what statically (lexically) decides if there is to be error-treatment.
<mikdusan>
there is no `!` thus no error treatment
<mikdusan>
thus we allow returning value because that's all it is.
<marler8997>
is f3() the same signature as in your proposal?
<marler8997>
is it's return type u32?
<marler8997>
would be nice to jump on a discord call and discuss? you have that ability?
<mikdusan>
yeah I've got discord. mic should work but never tried.
<marler8997>
cool let's give it a try
xackus__ has quit [Ping timeout: 264 seconds]
xackus__ has joined #zig
<tane>
the compiler sure takes a lot of memory, impressive :)
<ifreund>
yeah, stage1 is very much not optimal
jukan_ has joined #zig
swills has joined #zig
sebonirc has joined #zig
jukan has quit [Ping timeout: 256 seconds]
ed_t has joined #zig
<ed_t>
with var x:usize = ??? you can use std.math.log2(x) but not std.math.exp2(x), what should I be using ( 1 << x does not work since x is not comptime known)
<ed_t>
neither powi(2,x) or shl(1,x) work as zig complains: error: expected type 'type', found 'comptime_int'
<Gliptic>
look at the signature of those
<ed_t>
I understand the error, I am just looking for the inverse of log2(usize) and, so far, have not found it.
<Gliptic>
then you know they take three parameters?
<ed_t>
Gliptic sorry, you are correct. thanks
<ed_t>
sometimes you see what you expect, not what is actually there
<ed_t>
so ...shl(usize,1,x) does what i need
xackus__ has quit [Ping timeout: 256 seconds]
xackus__ has joined #zig
swills has quit [Quit: swills]
swills has joined #zig
zags has joined #zig
<zags>
what's the easy way to reset an ArrayList? I want to clear all elements and start adding things again. Like vector::clear, i.e no need to reallocate.
<zags>
ominous name, but looks like it updates .items length etc, thanks"
<zags>
translating to setItemLength in my head :D
<andrewrk>
setItemLength would imply you could grow it
<andrewrk>
there is also shrinkAndFree
craigo has quit [Ping timeout: 264 seconds]
<zags>
well, item length can be 0, so not sure the implication holds, and shrinkRetainingCapacity says nothing about items and lenghts so it wasn't obvious - but it's just about learning what the names mean
<zags>
tbh i looked for clear, but that's just because that's what c++ use :)
<zags>
oh i see what you mean, setItemLength would be a bad name
<andrewrk>
adding clear would be nice, it would be clearRetainingCapacity and clearAndFree
<zags>
nice. I have an struct with its own arena allocator, and an ArrayList using that arena as a backing allocator. I think my struct's deinit() can simply deinit the arena. But it feels correct to still call arraylist.deinit() as well. I mean, that's the right pattern right? If there's a deinit() function, I call since it may do other things.
<zags>
Probably wasteful in this case, but in general seems like a good principle as you can't expect people to look inside deinit's on everything.
<andrewrk>
the pattern I have landed on is to almost always use a general purpose allocator to back ArrayLists, with `defer list.deinit();`, and then once the size is finalized, copy it into the arena with `arena.dupe(T, list.items)`
<andrewrk>
empirically this improved performance, presumably because of less wasted memory and better cache friendliness of the arena memory