<daurnimator>
You really have to de-zig-nate a good mascot
<sarna>
> rat dressed as a spacepilot
<sarna>
where did that come from?
<daurnimator>
"you're just being zignorant"
<daurnimator>
alzigator
DutchGh0st has joined #zig
<daurnimator>
This is a lot of zigmarole; time for a zigarette break
<daurnimator>
ziguratively...
<DutchGh0st>
Thats not zuggy
<daurnimator>
sorry it was a zignominius end my pun chain
<daurnimator>
*of
<DutchGh0st>
Will we reach Zigularity?
<daurnimator>
You will need to investzigate
<daurnimator>
I'm sure the result will be zignificant
<DutchGh0st>
We'll have to ziglify the problem
<daurnimator>
The root of the problem will need to be dezignated.
kristoff_it has quit [Ping timeout: 272 seconds]
<DutchGh0st>
Under the nice sound of the 'summer of zigxty nine'
<daurnimator>
I feel inzignant about that.
<DutchGh0st>
Its claszig
<DutchGh0st>
its good muzig
<daurnimator>
I'm not going to zignify those with an answer.
<DutchGh0st>
can we get back to the bazigs?
<daurnimator>
That would be zignoble
<sarna>
hi, how do I specify an int is /not/ comptime? I declared an index outside of a loop and I get "error: variable of type 'comptime_int' must be const or comptime"
<sarna>
: usize did the trick, whew
<nrdmn>
sarna: or any integer type that is not comptime_int
<sarna>
nrdmn: yeah, I didn't expect literals to be comptime by default
<DutchGh0st>
so whats the type of `comptime var x: usize = 0` ?
<DutchGh0st>
still comptime_int ?
<daurnimator>
sarna: `u32(0)`
<sarna>
think you meant to ping DutchGh0st :)
<daurnimator>
sarna: no. the way to get from comptime_int to anything else is by e.g. `u32(your_comptime_int_here)`
<sarna>
ohhh
<sarna>
thanks :)
<sarna>
DutchGh0st: I tried to print it, but compiler linked me to github issues a couple of times and I gave up
<nrdmn>
huh. Is there any difference between T(U) and @intCast(T, U) ?
<daurnimator>
DutchGh0st: its a usize known at comptime .
<daurnimator>
nrdmn: yes. `T(u)` will throw an error at comptime if u can't fit in T. `@intCast` will throw an error at runtime.
<nrdmn>
ahh okay
<daurnimator>
(and @truncate will throw an error at neither, and mask off the bits)
<DutchGh0st>
heh, I implemented transmute
<DutchGh0st>
it just doesnt work at compiletime, thats sad
<DutchGh0st>
but I use a packed enum, why does it complain that one field is set but I access the other?
<daurnimator>
?
<DutchGh0st>
the docs say a packed union doesnt have that check
<daurnimator>
DutchGh0st: are you looking for bitcast?
<DutchGh0st>
transmute works for all types
<DutchGh0st>
bitcast doesnt
<DutchGh0st>
aka, `Transmute(void, u32, {})` is okey
<daurnimator>
DutchGh0st: that would just be invoking undefined behaviour...
<DutchGh0st>
why? you crate the union, which has the size of the largest thing it holds, in this case a size of 4
<daurnimator>
DutchGh0st: when you set a u32 in a u64 union, the other 32bits have undefined contents
<DutchGh0st>
you create it with void, and then access the int. Im not saying you can rely on the value of the int, but its probably always 0
<daurnimator>
DutchGh0st: no. the value is undefined
<daurnimator>
and (in release-fast mode) once that value is undefined, the nasal demons are released
<daurnimator>
on that point. we should rename --release-fast to --release-nasal-demons
<DutchGh0st>
well then you just do like 'var x = Transmute(u32, u64, 10); x = 0`
<daurnimator>
DutchGh0st: huh?
<DutchGh0st>
you said `x` has undefined bits, then I say you just overwrite em
<daurnimator>
it doesn't work like that
<DutchGh0st>
then how does it work?
<daurnimator>
DutchGh0st: e.g. if I have a `foo = struct { x: u32, y: u32}{.x = 42, .y = 100}` and I send `Transmute(u32, u64, foo.y)` then you could end up with e.g. whatever `42 << 32 | y` is
wootehfoot has joined #zig
<daurnimator>
but really it could be anything. e.g. the compiler could be using the top bits of a 64bit register holding your 32bit value to hold onto some temporary
<DutchGh0st>
well then just overwrite it
<daurnimator>
overwrite what?
DutchGh0st has quit [Ping timeout: 276 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
sarna has quit [Quit: Leaving]
<SimonNa>
Hi, I'm on Arch 64-bit, trying to build Zig myself from its C++ source. (Packages zig and zig-git build and run fine, but I want to build myself.)
<daurnimator>
SimonNa: okay... did you run into an issue?
<SimonNa>
CMake didn't find some LLVM files, I added symlinks to get CMake to comply.
<daurnimator>
SimonNa: you shouldn't need to
<SimonNa>
Ah
<daurnimator>
SimonNa: `mkdir -p build; cd build; cmake ..; make install` should work
<SimonNa>
Hmm. Even after compilation, Zig (stage 1 compiler) didn't link, with lots of llvm undefined refs.
<daurnimator>
SimonNa: can you paste your terminal session?
<SimonNa>
Very good, I'll try that
<SimonNa>
Okay, I'll paste the linker output before trying your idea
<daurnimator>
SimonNa: do you have llvm installed?
<daurnimator>
pacman -S llvm
<SimonNa>
llvm-8.0.1-1 is up to date
<daurnimator>
SimonNa: to narrow things down, can you try without ninja?
<SimonNa>
I'll try vanilla 'cmake ..'
<SimonNa>
Yes, both CMake warnings re-happen
<daurnimator>
SimonNa: thats... weird. can you `ls ../cmake`?
<daurnimator>
(that is, the cmake directory inside of your zig clone)
<SimonNa>
No such directory
<SimonNa>
Wow
<daurnimator>
`git status`?
<SimonNa>
right, git status shows missing files
<SimonNa>
hold on, I'll get a clean checkout
laaron has quit [Remote host closed the connection]
<SimonNa>
Yes, that seems to have been it >_<
<SimonNa>
Apologies for not trying from 100 % fresh clone
laaron has joined #zig
<SimonNa>
daurnimator: I built Zig successfully; both its zig and zig0 build my examples and they run. Thanks, quality debugging, and apologies for the awkward setup.
<daurnimator>
SimonNa: now go tackle an open issue ;)
<SimonNa>
Yep, that's the plan :)
DutchGh0st has joined #zig
andersfr has joined #zig
laaron has quit [Remote host closed the connection]
andersfr has quit []
laaron has joined #zig
SimonNa has quit [Ping timeout: 245 seconds]
SimonNa has joined #zig
SimonN has joined #zig
SimonNa has quit [Ping timeout: 268 seconds]
SimonN is now known as SimonNa
DutchGh0st100 has joined #zig
<DutchGh0st100>
AHH DutchGh0st go away :3
DutchGh0st has quit [Ping timeout: 258 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
_whitelogger has joined #zig
DutchGh0st100 is now known as DutchGh0st
laaron has quit [Client Quit]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
firefox317 has joined #zig
laaron has quit [Remote host closed the connection]
wootehfoot has joined #zig
laaron has joined #zig
<SimonNa>
If I write "fn blub(arg: someUndefType1) someUndefType2 { return arg; }" but never call blub, this passes compilation (zig build, producing an executable) without errors. Only if I call blub, Zig complains about the missing type someUndefType1. Is it desired that it builds despite missing types?
<DutchGh0st>
yes and no in my opinion
<DutchGh0st>
it's cool when you write a prototype and just want see if other things are still compiling
<DutchGh0st>
its not cool when you write a bunch of stuff, and now you gotta test it *all* because who knows you messed up
<SimonNa>
Hmm
<SimonNa>
Yeah, I tend to write features bottom-up and would really like the typechecking
<SimonNa>
I'll see what tricks there are around this. Maybe unittest everything immediately.
<daurnimator>
SimonNa: zig has lazy compilation: a method isn't compiled unless it is referenced.
<daurnimator>
this allows us to write functions that e.g. only work on linux; without breaking the windows build
<SimonNa>
Hmm, even in debug mode, and it's a feature then.
<DutchGh0st>
mhh
<DutchGh0st>
I wonder
<DutchGh0st>
how do I as a called function know whether Im called at compile time or not?
<daurnimator>
DutchGh0st: you don't....
<daurnimator>
DutchGh0st: and infact you might be both
<DutchGh0st>
Well it'd be cool if you could
<daurnimator>
DutchGh0st: not really. a whole ethos is that all functions work at either comptime or runtime. if we allowed you to disambiguate, suddenly we're likely to see you prevent something working at either comptime or runtime
<daurnimator>
DutchGh0st: the only thing you *can* do is mark an argument or statement as `comptime`, which means that it *won't* be done at runtime.
<DutchGh0st>
and you get twice the code you have to maintain because now you're also including all the tests
<Tetralux_>
Not _just_ any old TDD in that sense.
<mq32>
Tetralux_, i can relate to you :)
<Tetralux_>
SimonNa: Yeah - that's a reasonable use of it.
<DutchGh0st>
and you're only half as fast because well you gotta write tests
<Tetralux_>
SimonNa: I'd call those regression tests though ;)
<Tetralux_>
Or integration tests.
<Tetralux_>
That works too.
<SimonNa>
yeah, that's what they are :)
<Tetralux_>
DutchGh0st: Precisely.
<SimonNa>
TDD, if it inspires one to write code that can be easily tested, it's done its job even if you don't write the myopic tests that TDD would really call for
<andrewrk>
imagine if zig didn't have tests
<SimonNa>
case at hand today is really to force Zig to check my function that isn't called yet
<Tetralux_>
I think I'd rather have a program that just exercised the code paths, and checked all the errors instead of writing a test for the API.
<Tetralux_>
Though, if I designed a user-facing interface, I'd want to think much more carefully about its design.
<DutchGh0st>
btw, `const testing: type = if (@import("builtin").is_test) @import("std").testing else void;`. Will that be `void` if not compiled with `zig test src/file.zig` ?
<mikdusan>
i don't know what "kind" of tests they would be... but Zig benefits from and needs tests that cover code. lazy nature of zig means swaths of code can get bugged without notice
<Tetralux_>
Oh we should absolutely have `zig check` and `zig build-exe/run file.zig --check-all
<andrewrk>
it doesn't even solve the problem. how does --check-all get your ArrayList code to be checked?
<andrewrk>
or any function with a comptime parameter
<DutchGh0st>
trough a generator that scans the programm for all types used in the ArrayList, and then it would just check all those
<andrewrk>
you're on the path to coming up with #3028 yourself
Tetralux_ has quit [Ping timeout: 268 seconds]
<DutchGh0st>
I donnow, maybe std.testing could be improved to help you cover most common types
<DutchGh0st>
so that at least you know those work, or dont
DutchGh0st has quit [Ping timeout: 268 seconds]
Akuli has joined #zig
shritesh has quit [Quit: Goodbye World!]
shritesh has joined #zig
shritesh has quit [Client Quit]
shritesh has joined #zig
voldyman has joined #zig
<voldyman>
andrewrk: i was watching the async-await stream and had this question. how do i know from a return value that the caller needs to free it?
* voldyman
is new to zig, there might be a way that i don't know of
<andrewrk>
voldyman, you don't. you have to read the documentation of the function you call
<voldyman>
ah, coming from C++ i thought there might be something like unique_ptr which means you own it and raw pointer that you don't own
<voldyman>
i don't know of a good solution, C++ or pony like type system or rust. is that a problem that zig will try to solve?
<andrewrk>
voldyman, this is the consequence of "manual memory management"
<voldyman>
andrewrk: for sure, i was thinking that if there was a way to attach a 'defer' to a scope of a variable then we'll have deterministic memory free's
<andrewrk>
there are some conventions to make it manageable. For example, typically a function which has "init", "create", or "alloc" in the name needs to be paired with a function which has "deinit", "destroy", or "free"
<gonz_>
The allocating function would be doing this?
<voldyman>
"could" do this
<gonz_>
That "could" is a bit of a problem itself in my book
<gonz_>
Some people would, some people wouldn't
<gonz_>
Some people use some part of the language, some people use more, etc.
<voldyman>
agreed, hence my first question. is there a way to differentiate between owned & unowned memory
<voldyman>
calling free twice won't cause a segfault right?
<voldyman>
if you want to be defensive, then attach a free'er to every object received from 3p libs
<companion_cube>
double free is generally a segfault?
<voldyman>
not in zig IIRC (or c++ for that matter)
<mq32>
in c++ double free is UB
<mq32>
and i assume that is for *any* sane language ;)
<voldyman>
i wanted to hack together an prototype but am not familiar with llvm and the zig codebase
<gonz_>
I think this kind of thing necessitates a proposal regardless
<mikdusan>
+1 gonz_
<gonz_>
Personally I think it's super unintuitive if I get something from a function and it's decided that it should be freed magically.
<gonz_>
Whereas without this I can work under the assumption that if something takes an allocator and returns something allocated for me it's my responsibility and my choice when to free it.
<companion_cube>
esp. if there is no free() in that allocator
<voldyman>
i think it simplifies the mental model, you don't have to ask "is this on the stack? or on the heap?" "who owns this?"
<voldyman>
the object you receive will be freed when it goes out of scope
<voldyman>
unless ... (received from new/alloc function, has a decorated type, etc.)
<gonz_>
Does it actually simplify anything, though?
<gonz_>
Isn't there just more behavior to take into account?
<mikdusan>
voldyman: to be honest, since Zig is a manual memory management language, it would have to be inverted. default is manual, decoration would indicate some auto end-of-scope hooking. which btw, is technically what defer/errdefer already is. just different sugar.
<gonz_>
`defer` and `errdefer` are obvious from which scope they're in, whereas this would affect other scopes
<voldyman>
mikdusan: true, my idea is attach a function/block to the end of life of the variable. how the rest of the language evolves around it is left open
<gonz_>
This seems a step towards something like RAII to me
<mq32>
voldyman: defer already does this
<fengb>
Like a destructor?
<voldyman>
yes, that is my intention
<gonz_>
And I think that's not something that's proven to simplify anything
<voldyman>
mq32: but for the current scope, not the scope of the variable
<voldyman>
(unless i am missing something)
<mq32>
same difference if you do defer directly after variable init ;)
<mq32>
var x = …; defer x.free();
<mq32>
point is: as soon as you want the same behaviour for non-local variables (so struct fields) you have full featured RAII with copy and move semantics
<voldyman>
if the variable isn't transferred to a difference scope, if it is then the current defer isn't useful
<voldyman>
mq32: aren't the current semantics move only?
<mq32>
if it is transferred to another scope, that scope has the job to delete the variable
<gonz_>
Attaching defers to variable lifetimes is very non-obvious and magic
<mq32>
voldyman: zig has neither move- nor copy-semantics
porky11 has joined #zig
<mikdusan>
voldyman: one thing to _really_ consider is that zig doesn't fret at all about verbosity if it adds to clarity and intention
<mq32>
also: what is "variable lifetime"?
<fengb>
Zig doesn’t have ownership semantics. There’d have to be a radical shift in the language
<mq32>
lifetime of the variable, the content or the content pointed to by a pointer variable?
<voldyman>
hmm, i allocate an object, return is from the current function means i am transferring the point to the caller right?
<gonz_>
mq32: That was my phrasing, not voldyman's.
<gonz_>
(I think?)
<fengb>
But zig has no concept of a resource
<voldyman>
i think defer right now would be as magical as defer(var)
<fengb>
So it’s just a variable / data copy
<gonz_>
voldyman: How so? It defers to the end of the exact scope you put it in.
<voldyman>
defer(var) is run when var is no longer in any scope
<gonz_>
It doesn't touch other scopes at all. It's very clear what's going to happen if you defer something.
<andrewrk>
if you put a defer directly after a variable declaration, that defer runs right before the end of the variable's lifetime
<andrewrk>
a new syntax for a "variable scoped defer" would be entirely redundant
<voldyman>
yes, what happens when we "return" a variable? is the one received by the caller a new entity pointing to the same memory?
<andrewrk>
it copies the return operand to the return result location
<DutchGh0st>
is that line true? is it generally better to call a function that takes `Self` rather than `*const Self`, and both return a field of the thing by value back the caller
<Tetralux>
I mean, you're returning a copy either way..
shritesh has quit [Quit: Goodbye World!]
<Tetralux>
Hmmm.
<Tetralux>
I'm not sure which would be better.
<Tetralux>
Is it possible for "does not support field access to tell you why it doesn't" ?
<Tetralux>
Only I really have no idea why I can't access a field of a returned struct...
<DutchGh0st>
hehe
<DutchGh0st>
pub vs private?
<DutchGh0st>
or, did you assign the struct to a const variable, and now try to write to it? something like that?
<Tetralux>
Ah! Figured it out...
<DutchGh0st>
what was it?>
<Tetralux>
I did `var x = f();` instead of `var x = try f();`
<Tetralux>
And the error was so wordy that I didn't notice.
<DutchGh0st>
ahhhaaa
<Tetralux>
That's one of those errors that I wish was clearer...
<Tetralux>
error: type '@typeof(X.Y.A.B.C).ReturnType.ErrorSet!ReturnValue' does not support field access"
<DutchGh0st>
can have .map(some_func_if_the_result_was_ok).and_then(some_func_converting_an_ok_result_to_another_result)
<Tetralux>
Ugh.
<Tetralux>
Why can't it just be "errorset!ResultType does not support field access."
<Tetralux>
DID YOU MEAN TO USE `try` HERE????
<Tetralux>
note: inferred error set is here: (location of function signature you are calling)
shritesh has joined #zig
emekankurumeh[m] has joined #zig
<Tetralux>
What I want generated docs to do is allow me to very quickly become familiar with a codebase... x'D
<Tetralux>
RandomThought.
<Tetralux>
If the zig codebase had that, I'd consider making those errors myself.
<Tetralux>
Maybe I even still will.
<Tetralux>
But regardless xD
dftxbs3e has joined #zig
<dftxbs3e>
hi, what facility does Zig have to allow performant I/O?
<fengb>
Zig is currently rewriting async function semantics
<fengb>
So once that’s done, we’ll have non-blocking IO with optional event loop or thread pool support
<dftxbs3e>
I'm wondering.. wouldnt there be a way to express I/O processing logic agnostic of the underlying facility, which would allow code to follow suit with improvements
<dftxbs3e>
I feel like we're in an endless route with these I/O facilities
<dftxbs3e>
Rust, Golang, now Zig, they each have their own code for this
<dftxbs3e>
Golang coroutines are suboptimal, Rust's async is currently not ready and confusing to use, Zig is replicating this work
<DutchGh0st>
how is rust's async confusing to use?
<DutchGh0st>
it uses futures under the hood, but you need an executor and reactor to drive the future to completion, and those are implemented mostly in terms of mio, but you could make your own if you wanted to
<andrewrk>
have a look at that issue and then come back and discuss
<dftxbs3e>
oh cool, I didnt meant to criticize Zig in any way, just emptying my ideas here
<andrewrk>
it's not accurate to say that zig is replicating rust's work
<andrewrk>
they're fundamentally different, as far as I understand
<andrewrk>
dftxbs3e, no worries, sorry if my tone of voice sounded hostile, I didn't mean it that way
<andrewrk>
for anyone who was watching that follow-up async/await stream from yesterday, I got that other example working
<DutchGh0st>
Zig is more verbose and lets you take a deeper look at whats really happening, thats how I view it
<dftxbs3e>
DutchGh0st: current state doesnt allow to write good code, just writeonly code
<andrewrk>
what was happening is `cancel` codegen didn't set the error return trace pointer to null, so it was trying to populate it when you did `cancel`. that's fixed now
<DutchGh0st>
'writeonly'?
<dftxbs3e>
that you can't read and understand
<dftxbs3e>
like 6 months later, or another person
<DutchGh0st>
its fairly readable by now
<dftxbs3e>
I write Rust since a year and that's not my experience, library support is very low too, when you're writing something more than just PoC projects, it's not pleasant
<dftxbs3e>
I'm hopeful on latest async/await improvements but a long road is ahead
<andrewrk>
there are 2 major things left to solve now in the async/await branch:
<andrewrk>
* "lazy values" so that async functions can defer destroying their own frames without zig thinking it is a circular dependency
<DutchGh0st>
They thought Futures was it (back in 2016, 2017), then they figured combinators where hard, and they needed `async fn`. They started with await!(future), but that now has become future.await,
<andrewrk>
* making async/await/cancel work on normal blocking functions
<DutchGh0st>
and the rest of the story is just like any other language does it, async fn's can be awaited, and you need some evenloop to resolve everything
<DutchGh0st>
andrewrk, what about `async streams` ?
<DutchGh0st>
where you have a continuous stream of data, but asynchronously
<fengb>
Like generators?
<DutchGh0st>
like a server listening on a port that is waiting for devices to connect with it
<andrewrk>
DutchGh0st, that works but it requires an async function pointer call, which has 2 limitations: your function pointer has to explicitly have the `async` type. and you have to provide a byte buffer that is big enough (runtime-checked) for the frame of whatever async function you call
<DutchGh0st>
async function pointer call?
<andrewrk>
look for @asyncCall in the rewrite-coroutines branch if you're curious
<dftxbs3e>
DutchGh0st: combinators specially are hard to use with the borrow checker and Send + Sync requirements in any performant setup
<DutchGh0st>
yeah well you dont have that anymore now dftxbs3e
<DutchGh0st>
@asyncCall, where can I find that?
andersfr has joined #zig
<DutchGh0st>
also, am I getting this right,
<DutchGh0st>
with async function you probably have 1 main function that handles the evenloop stuff, and from that function you 'spawn' other functions or something?
<dftxbs3e>
am I dreaming or has C++ failed to catch up with convenient abstractions for performant I/O?
<DutchGh0st>
they have this `futures` thing as well, right?
<dftxbs3e>
yes but IIRC you can't control the executor
<DutchGh0st>
but I dont know what it means to be a c++ future
<DutchGh0st>
how does this @Vector thing works?
Akuli has quit [Quit: Leaving]
DutchGh0st has quit [Remote host closed the connection]
tav has joined #zig
<tav>
great to see a project still using IRC :)
rjtobin has joined #zig
<andrewrk>
tav, thanks for the sponsorship :)
<tav>
thanks for the fantastic work!
<tav>
are there any community packages that I should check out to see what the established practices are in terms of writing Zig packages?
andersfr has quit []
<andrewrk>
tav, we're a few months away from having an MVP of a package manager available
<andrewrk>
so there isn't a great example of what a package will look like yet. But there are plenty of community projects to look at to see how they organize their build scripts and source
<tav>
re: the package manager, any chance, it would be more like Go, and less like Rust? Rust's insistence on a single global namespace for crates, and minimal support for monorepos with multiple packages makes it rather painful to work with at scale
<tav>
by contrast, in Go, it's just `go mod init host.com/path` and then you can have as many packages as you want just based on directory layout
<andrewrk>
zig's package manager will be decentralized
<andrewrk>
that's the main design constraint
<tav>
sweet!
<andrewrk>
currently I'm about 2/3 done with reworking async/await semantics, in preparation for adding networking to the std lib. And then package manager can take advantage of that networking
<andrewrk>
the package manager can be written in zig itself; even though the compiler is not yet self-hosted, it's capable of being linked with zig code
<andrewrk>
which is how, for example, `zig fmt` works
<tav>
nice. re: async/await, what does `try await try async` mean btw?
<tav>
sorry for asking questions you've no doubt answered already somewhere
<andrewrk>
with the new semantics, `try await try async foo()` can be rewritten as `try foo()`
<tav>
oh wow
<tav>
any current thoughts on cancellation too?
<andrewrk>
I have that all hooked up and working in the branch with tests. Any questions on how it works?
<Tetralux>
[sidenote] DutchGh0st, replied to your comment.
<Tetralux>
Do async fns, always run to the next suspend point, or to completion, when they are cancelled?
<andrewrk>
all functions, including async functions, run from beginning to the `return` statement. cancellation does not affect that.
<andrewrk>
however functions can check if a cancel is requested, and choose to have different control flow, such as returning early
<tav>
so, `cancel handle` marks a cancel as having been requested?
<tav>
how does a function know that cancel has been requested?
<Tetralux>
It either gets to the return statement and then discard it's result, running errdefers, or it checks if it's been cancelled part-way through and returns early.
<Tetralux>
I believe that's right, yeah?
<andrewrk>
tav, correct. it does 3 things: 1. marks the frame as being cancel-requested 2. stores its own frame pointer as wanting to be resumed 3. suspends
voldyman has quit [Quit: Connection closed for inactivity]
redj has joined #zig
mikdusan has quit [Ping timeout: 276 seconds]
mikdusan has joined #zig
<tav>
if it could be brought down to just `cancelpoint return error.Cancelled;` for the common case, that would be amazing
<tav>
I could well imagine some standard constructs being built to do async operations with deadlines/timeouts
wootehfoot has quit [Read error: Connection reset by peer]
Tetralux__ has joined #zig
Tetralux has quit [Ping timeout: 245 seconds]
Tetralux__ is now known as Tetralux
porky11 has quit [Ping timeout: 250 seconds]
SimonN has joined #zig
<daurnimator>
dftxbs3e: fwiw I'm working on performant I/O abstractions
SimonNa has quit [Ping timeout: 276 seconds]
<andrewrk>
daurnimator, where did you end up landing last night?
<daurnimator>
andrewrk: ran into a kernel bug that made it impossible to use urings any more without rebooting :P so switched gears and worked on external debug info.
<daurnimator>
andrewrk: I'm not quite sure about the whole "return is a cancellation point" thing.
<daurnimator>
tav: will be `zig translate-c`
<tav>
ah
<andrewrk>
daurnimator, objections to return as a cancellation point should come with a counter proposal of how to write this code: https://clbin.com/x3pCE
<andrewrk>
tav: `zig translate-c` and then manually updating some things
<tav>
is there something that can parse and render documentation from .zig files by any chance? if not, is there some way to parse zig from within zig?