<scientes>
uint32_t host_int_bytes; // size of host integer. 0 means no host integer; this field is aligned
<scientes>
I still have no idea what this means
<scientes>
what the frig is a "host integer"
<scientes>
its part of the align() keyword
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
scientes, it's for packed structs with sub-byte integers
<andrewrk>
"host integer" is the byte-aligned integer that contains the little ones. you have to bit mask & shift the host integer
<scientes>
ahh i see
<scientes>
so there is "extern packed" and "packed"
<scientes>
which are distinct?
kristoff_it has joined #zig
mipri has left #zig [#zig]
kristoff_it has quit [Ping timeout: 244 seconds]
<daurnimator>
andrewrk: congrats on the merge :)
<scientes>
sweet!
laaron has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 268 seconds]
diltsman has joined #zig
<diltsman>
VS Code's debugger automagically worked with Zig. That was pretty awesome.
<fengb>
Oh? I should try it
<scientes>
diltsman, that is because of tiehuis
<diltsman>
Yeah? I just pointed the debug configuration at the generated .exe and started debugging. I assumed it was because of the .pdb file.
* scientes
doesn't know windows
<scientes>
but yeah, that too
<diltsman>
Just realized that the Zig plugin will do builds. Looking at that.
andrewrk has quit [Ping timeout: 268 seconds]
andrewrk has joined #zig
kristoff_it has joined #zig
NI33_ has quit [Ping timeout: 245 seconds]
kristoff_it has quit [Ping timeout: 248 seconds]
<daurnimator>
fengb: cool example of the generator :)
<fengb>
Thanks!
<diltsman>
Any idea on how to use the VS Code Zig plugin to build the project using build.zig?
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
<daurnimator>
andrewrk: should there be a @Frame variant that takes arguments for the function (incase it has varying behaviour based on comptime variables?)
<andrewrk>
ah. that's an unsolved problem.
<andrewrk>
theoretically we could use @typeOf(func(foo, bar, dummy_value)) but I think that incorrectly has side effects
<daurnimator>
andrewrk: hmmm. I think this goes back to an older thing I brought up. what if `async foo(bar)` didn't *start* the function, but just returned a frame for it? and `resume` actually started it?
<andrewrk>
before you suggest any changes, I for sure want to understand what is the use case / problem with status quo
<andrewrk>
oh, I'm sorry. my mind blanked out. the context is right there from minutes ago
<daurnimator>
note that the current state of that file triggers the kernel bug: the test program hangs and can't be killed. if you run it 5 times your computer will need to be rebooted.
<daurnimator>
so; uh; if you want to play for long; comment out the part of the test case that writes to /dev/null
<karrick>
I’ll give it a proper read when not on my phone tomorrow. Are you positive it’s a kernel bug?
<karrick>
Just playing devil’s advocate
<daurnimator>
I'm pretty sure an unkillable process is a kernel bug no matter what else is happening
<karrick>
Oh yeah. 5 times and boom. Makes sense.
<karrick>
I wonder whether there is a five element queue or buffer in uring that gets filled up, but that seems excruciatingly small
<karrick>
Especially if it’s a circular queue
<karrick>
But still. 5 is small
<daurnimator>
karrick: you're welcome to try and replicate. I only tried on one of my computers so far
<karrick>
Yeah I’ll play with it after I digest the code
<karrick>
I don’t know your local time but I saw you talking recently and said hello. Thanks for the link. This is very interesting work, and I’d be happy at least to give it a look over. Another set of eyes if you will
<karrick>
Also is it *always* every 5 runs, repeatable?
<daurnimator>
I tried 3 times and same result
<daurnimator>
considering it takes a reboot to recover I didn't try more :P
<karrick>
Ok. I also see the code is reading values without atomic, and that is bad. If a value is meant to be accessed atomically, then it must always be atomic. I will also read the uring code for how it accesses the head and tail pointers
<karrick>
Line 23, specifically
<daurnimator>
karrick: ktail is only written by the current process; so no need to protect it
<karrick>
But I’m not sure whether `getTail` is there for development purposes or actually used yet, because I have not read the entire 600 lines yet
<karrick>
But would not the kernel reads it out of band to the current process?
<daurnimator>
huh?
<daurnimator>
getTail will only return your own setTail
<karrick>
Hm. I owe this code a more thorough reading. But I always always always guard every access to atomic variables if ever more than a single thread are accessing the same address in memory, regardless of whether it reads or writes, to prevent split read or split write problems.
<daurnimator>
karrick: if you're coming from the .pdf I linked last time; then start from the top of the file. but if not, you may want to start from the test case(s) at the bottom
<karrick>
Although because those variables are aligned, i admit it is less of a concern
<daurnimator>
the general API is: .queueSomeOperation(unique_token); .submit(); .getCompleted().user_data // will be your unique token back.
<daurnimator>
--> and that you can queue as many operations as you want (well; actually up to number of entries to ask for in creation)
<karrick>
I did read and digest the pdf you sent. But my brain has unfortunately been in other problems as of recently where as your brain is fresh. So I will reread it
<FireFox317>
I'm getting build errors in zig_llvm.ccp when building master: https://pastebin.com/mpYngXbF The following cmake command is run: `cmake .. -DCMAKE_PREFIX_PATH=$HOME/dev/zig/local`
<FireFox317>
Hmm I think it is because I updated my Arch system, which resulted in GCC being updated to version 9.1.0 and I think that is causing the build issue. Let me try to use clang
<FireFox317>
Confirmed it is related to GCC 9.1.0, building with clang works fine
<FireFox317>
How do I grab a copy of LLVM 9? Is it the 'release_90' branch of the llvm git repo?
FireFox317 has quit [Ping timeout: 258 seconds]
utzig has joined #zig
Pursche01 has quit [Quit: Connection closed for inactivity]
<samtebbs>
FireFox317: I had similar issues too (they seemed to have magically disappeared since, perhaps someone fixed it)
<samtebbs>
You could pull the latest llvm git and checkout a release candidate branch
keith52 has joined #zig
<keith52>
Hey guys, sorry if this is a question that's been addressed before but I'm wondering is there a way you can use a C++ library in zig without having to port it? I just started a project with Dear ImGui and was thinking of rewriting it in zig.
<fengb>
Zig only interopts with C. What you could do is write a thin C layer that maps the C++
<fengb>
to C
<keith52>
Ah ok. Thanks :)
<mq32>
you *could* import the functions by mangled name
<scientes>
if you are crazy...
<mq32>
for dear imgui that *should* work as the library doesn't use c++ magic other than overloading
<scientes>
mq32, have you ever tried to create a symbol file for a C++ library?
drazan has quit [Remote host closed the connection]
bheads has quit [Ping timeout: 248 seconds]
bheads_ is now known as bheads
kristoff_it has quit [Ping timeout: 272 seconds]
drazan has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
Tetralux has joined #zig
<Tetralux>
Does @setRuntimeSafety(false) only disable runtime safety for the current function scope, or does it ALSO disable it for every function call down the call stack?
<mikdusan>
Tetralux: only for the current lexical scope
<Tetralux>
That's what I though.
<Tetralux>
thought*
<Tetralux>
Good.
<Tetralux>
Not going senile yet.
ky1ko is now known as ky0ko
FireFox317 has joined #zig
<FireFox317>
andrewrk, In the example in issue #3076 which you have just created, It suspends but I don't see a `resume`. Shouldn't there be a resume?
kristoff_it has joined #zig
<andrewrk>
FireFox317, good catch. I updated the test
<andrewrk>
(the previous test was still enough to catch the invalid LLVM generated, but you're right it needed to be updated in order to pass)
<andrewrk>
fengb, wow. they're on the path to zig's revelation about inferring whether a function is async or not
kristoff_it has joined #zig
<andrewrk>
it's the logical next step...
<dimenus>
i like how zig allows me to build "systems", eg I can build a pool allocator that returns an opaque handle. You can assign it to a var/const but you can't create your own
<dimenus>
it's like C++ but without constructors :P
<Tetralux>
What kind of handle do you mean exactly?
<dimenus>
basically an index where the bottom 4 bytes are the index itself and the top 4 is a unique id
<dimenus>
to protect against double free / dangling usage
<fengb>
I'm just surprised it's right after our big async milestone. And it looks like a clunky change
kristoff_it has quit [Ping timeout: 258 seconds]
<Tetralux>
dimenus: That sounds like a good use of @distinct ;)
<nrdmn>
calling a function declared as `fn foo() foo() { return struct {}; }` crashes the compiler
<dimenus>
Tetralux: don't need it. If you don't 'pub const' the opaque type you can't create one yourself
<dimenus>
and there's no way to cast a ptr to a type you can't use :P
<fengb>
"Between tokio, romio, runtime, and async-std (and probably others), I think it can be a little overwhelming for users which ecosystem they should pick."
<Tetralux>
You mean like `const Index = struct{idx: u32, id: u32}` => now can't Index{} outside file?
<fengb>
With a decentralized package system, how do we prod towards a unified library ecosystem?
<Tetralux>
dimenus: ahhhh - I see.
<Tetralux>
So you're creating an alias for a ptr to an opaque type, using a usize or whatever internally, and then casting to this opaque ptr before returning it.
<dimenus>
yep
<dimenus>
an error union with an OpaqueType actually triggers an assert in the compiler
<dimenus>
which sort of makes sense, since an OpaqueType is supposed to have "unknown but not zero size"
<Tetralux>
You mean if you do `const PI = @OpaqueType();` and then try to return `!PI`?
<dimenus>
yep
<Tetralux>
Yeah, I think I've come across that too.
<Tetralux>
It took me a minute to figure out what it was xD
<fengb>
You can't use opaque directly. It has to be pointers
<fengb>
It's like void*
<Tetralux>
My usecase was a native socket handle.
<fengb>
But better typed
<Tetralux>
I ended up doing `const NativeSocket = *@OpaqueType()`
<dimenus>
indeed that it makes sense, but it should be a compiler error rather than an assert :P
<Tetralux>
Except that means that whereever I'm storing a NativeSocket, I'm actually just storing a ptr to one...
<dimenus>
*agreed
<dimenus>
not really
<Tetralux>
Which is intended, but I'd rather *NativeSocket. xD
<Tetralux>
.. and have it compile error if I tried to deref.
<dimenus>
because you can just @intToPtr
<dimenus>
it's 8 bytes of whatever you want it to be
<fengb>
Yeah there's quite a few OS APIs that are much nicer with @OpaqueType because you can assign a proper name with actual compiler help
<Tetralux>
`const Index = *@OpaqueType(); ... return @intToPtr(Index, calculated_index);` ?
<dimenus>
yep
<Tetralux>
It feels kinda dirty to lie about how it's a pointer xd
wootehfoot has joined #zig
<dimenus>
It has to be a pointer though because it has 'unknown size'
<dimenus>
the caller has no idea what it's actually referencing
<dimenus>
so 8 bytes is 8 bytes
<Tetralux>
Maybe some sort of `const Index = @opaque(usize);`, but that's basically distinct at that point - though it is different; you know it's a usize, but other people do not.
<Tetralux>
Whereas with @distinct, you both know.
waleee-cl has joined #zig
dimenus has quit [Quit: Leaving]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
Akuli has quit [Quit: Leaving]
halosghost has quit [Quit: WeeChat 2.5]
wootehfoot has quit [Read error: Connection reset by peer]
porky11 has quit [Quit: Leaving]
<Tetralux>
What do people think of the following suggestion
<Tetralux>
Being able to declare that an error has the same value as another, different error?
<Tetralux>
The idea being that you want several errors to be handled the same way by default, because they essentially mean the same thing - except that they _are_ different and could be handled differently if the user wanted to.
<Tetralux>
But also
<Tetralux>
It would help error diagnosis.
<Tetralux>
The example I thought of is if you have a ring buffer.
<Tetralux>
Rather than returning error.OutOfMemory, you'd:
<Tetralux>
But because it's the same as OOM, code that checks against OutOfMemory, would match it.
<Tetralux>
But if they had a branch that checked specifically for RingFull, it could do that one instead.
<Tetralux>
The origin of the idea was just that it could make it easier to visualise the problem if you were able to get more information about the context of the error.
<Tetralux>
Especially in the stack trace when it fails.
<Tetralux>
Also, despite the fact that it's equal to OOM, if you returned it from main, it'd still print the name as RingFull.
<Tetralux>
The idea is basically just that you could declare a different error from the one you should return, and return it, but it'd work because it is actually a more specific version _of the same error.)
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 244 seconds]
<fengb>
My rudimentary understanding is that the errorset is a lookup table, and the data passed around is just the int
<andrewrk>
all errors are ints at runtime. error sets are type information only
<fengb>
There's a proposal to extend error unions to have extra context info
<andrewrk>
yeah. I'm willing to experiment with that to see if it can work before closing it
<scientes>
the simd PR was rebased
<andrewrk>
noted
<shachaf>
Is there a common idiom for error handling with additional information right now?