<shritesh>
I still don't understand async/await in Zig (I tried), but this sounds REALLLY EXCITING :D
<andrewrk>
shritesh, I think you were away when the new async/await stuff landed. I'm still planning on doing another pass to the docs, but the new semantics are much simpler and easier to understand
<andrewrk>
in summary: async functions are just functions! the difference is that you can start the function call, without waiting for it to finish
<shritesh>
I think everything will be much easier to grok once the event loop is in place
<andrewrk>
agreed
<fengb>
I’ve been meaning to blog on creating generators using async
<fengb>
But the code I’ve been writing isn’t very reusable
<shritesh>
Like I followed through you explaining it in your stream and I felt like I understood it. Now when I see the clbin, I have no clue what or why anything is being done.
<andrewrk>
yeah the example is admittedly contrived
<mikdusan>
random thought: i'd like to see an OS kernel give up SMT scheduling and only schedule cores and punt SMT scheduling to userspace. imagine async with 2 to 4 SMT available and this is decent cache locality, decent security locality.
<andrewrk>
I would be interested in that too
mmx870 has quit [Read error: Connection reset by peer]
<andrewrk>
shritesh, the point of this example is, the fib function has safe recursion and it expresses parallelism, yet it doesn't care whether it's used in an application with an event loop, or a blocking one
mmx870 has joined #zig
<andrewrk>
for number crunching, this is silly. but if the (indirect) recursive calls are to, for example, fetchUrl() or fetchFileFromDisk(), the ability of a library to express this parallelism without forcing threads or an event loop lets you write zig packages that are maximally reusable and optimal
<shritesh>
Yeah. As I said, I understand how it works and really do appreciate how it's different from all the other languages that I've dealt with. But, until the event loop is in place, I don't see myself being able to use it (and that's okay).
<andrewrk>
yep, that makes sense. the beauty of this, is that normal blocking code will *just work* if you enable an event loop
<andrewrk>
so that's kinda the whole point, is that you can ignore it
<andrewrk>
I'm still working towards an actual proof of concept & demo
<andrewrk>
one example of this would be `zig fmt` - being able to toggle whether it uses an event loop (and how many threads to use) with a single pub const declaration next to pub fn main
<andrewrk>
and then looking at the strace output and performance characteristics of each setting
<shritesh>
I don't know how this can be implemented but handling interrupts
<shritesh>
...will be great use for this somehow
<shritesh>
More details: I had to build something like an event loop with the ESP8266 for a class project to handle deep sleep, reading a temperature sensor and posting to an HTTP endpoint. I think async/await functions would have been a better abstractions.
<andrewrk>
yeah. it lets you write code in a synchronous manner, even if that code has to "wait" for things to happen
<andrewrk>
you can even implement constant time mem compare with it. var time = async sleep(1); const is_eql = std.mem.eql(u8, a, b); await time;
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
<shachaf>
That's not for cryptographic use, I hope.
<fengb>
"Instruction does not dominate all uses!"
<andrewrk>
shachaf, nah, I wouldn't use that. it's not sound to guess the maximum time. Also it's not optimal, it could be much faster if it's done with constant-time assembly instructions
<shachaf>
And also I wouldn't be surprised if that approach leaked some timing information anyway?
<andrewrk>
fengb, sounds like 3077 if you're playing with async/await
<fengb>
Oi
<andrewrk>
you can work around it by putting await on its own line
<knebulae>
@daurnimator: potentially; but I am not using anything in std
<daurnimator>
knebulae: why?
<knebulae>
@daurnimator: os work
<daurnimator>
?
<knebulae>
@daurnimator: I don't want to rely on any standard library
<knebulae>
@daurnimator: although with zig, I'm not sure that's a big deal
<daurnimator>
knebulae: you can use zig's std in making your own OS. Just avoid std.os...
<knebulae>
No hidden dependencies anywhere?
<daurnimator>
correct
<knebulae>
It's been awhile, but I thought there was a lingering dependency somewhere on libc++. I may have been completely off base. Hmm.
<daurnimator>
knebulae: libc is optionally used by some bits of it; by default it doesn't though (unless targetting e.g. OSX where the system ABI *is* libc)
<andrewrk>
yeah libc is only used when that's what you want to do
<knebulae>
@daurnimator: I guess that changes things a bit; I have always avoided all standard libraries when doing osdev. I guess I never really thought it was an option until now. :/
<andrewrk>
you'll know if something drags in an os dependency. you'll get a compile error
<daurnimator>
andrewrk: not yet. just caught up on irc backlog
shritesh has quit [Quit: Leaving...]
<knebulae>
Ok, very cool. Thanks daurnimator for the heads up that Isaac64 was already there. It was actually helpful to read the implementation. Much more "Zig Way" than C guy trying to write C in Zig.
<knebulae>
I think this is the first time I've ever looked at the standard library in Zig.
<andrewrk>
hopefully it should be readable, even to a C programmer who has not read the zig documentation
<knebulae>
@andrewrk: The irony is that I have read quite a bit of the documentation. I just never stumbled upon anything really about std until I went looking specifically for it.
<daurnimator>
knebulae: yeah std docs are missing right now
<andrewrk>
I close it before streaming so people can't see the URL
<knebulae>
@andrewrk: that link brings back memories of a Korg T1, a Roland 808 and Cubase VST in my dorm room. Lol.
<andrewrk>
:)
<knebulae>
@daurnimator: honestly, not yet; there's just not much code there in Zig yet. This just makes things much easier, and the code is better than mine :)
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 264 seconds]
uranther has joined #zig
<bgiannan>
how come a big f64 wont fit into a u64...
<andrewrk>
bgiannan, have you tried @bitCast?
<daurnimator>
bgiannan: are you trying to convert the number? or the memory?
dbandstra has joined #zig
<bgiannan>
bitCast
<bgiannan>
works
<bgiannan>
but i don't get the result i want yet. i'm trying to rewrite a lua snippet and i think in some wrapping is happening
<bgiannan>
i've swapping types around for a while now
<daurnimator>
bgiannan: lua doesn't really have a way to do the equivalent of bitCast... so I'm not sure what you're converting
<bgiannan>
yes that's what i'm saying i should not do a bitCast but some wrapping on a i32?
<curtisf>
Is there any way I can ask the zig compiler for the AST of a source file?
<curtisf>
advanced: with types and comptime info?
<daurnimator>
curtisf: std.parse?
<daurnimator>
uh, std.zig.parse?
<curtisf>
ah, so a library, but not exposed by the compiler
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<daurnimator>
curtisf: yeah. though that's the library that will be used by the stage1/stage2 compiler
<daurnimator>
(and what drives `zig fmt` today)
<curtisf>
yea, I guess the unfortunate thing is that I would have to write serialization code for all of the AST. But it's probably too early to commit the compiler itself to a AST serialization format anyway...
<daurnimator>
curtisf: I mean... with enough introspection you should be able to serialize almost any struct to e.g. JSON
<curtisf>
That's true! I'll probably try it out.
<daurnimator>
If you write a JSON serialiser like what I've been planning... you might just be able to pass it an ast node and get it :)
<curtisf>
hmm any guesses why ansi colors are coming out as special characters in command prompt after I updated to current head?
<alexander92>
this sounds interesting daurnimator, but it requires manual instrumentation
<alexander92>
which is not really feasible in many cases: where you'd like to just compile a big project with auto-instrumenting it in a certain way
<alexander92>
(at least if i understand the issue)
<Sahnvour>
alexander92: I don't know if there is an issue but this is taken into consideration, probably a userland thing though
marijnfs has joined #zig
<alexander92>
sounds great! (i am not sure what you mean by userland in this case tho)
<Sahnvour>
iirc one thing that was considered is patching functions to call a user-provided function that can do whatever you want to log/instrument them
<alexander92>
Sahnvour exactly, the first thing "patching to call a user-provided function" is very useful
<alexander92>
e.g. in my job i work on some debugging tools that do similar kind of instrumentation and languages that support that are way easier to work with
<alexander92>
(otherwise we just have to patch a limited set of vm/compiler versions)
<alexander92>
this issue is also important, but it's useful for a different niche: logging libs
<alexander92>
(which is *very* useful: i started using log libs which annotate the location of each outputted line (even doing it in python using frame api) and it helps print debugging *a lot*)
<Sahnvour>
yep
<alexander92>
especially when you generate 100-s of lines in a longer running async project
Ichorio_ has quit [Ping timeout: 264 seconds]
kristoff_it has quit [Ping timeout: 244 seconds]
SimonN has quit [Ping timeout: 258 seconds]
SimonN has joined #zig
SimonNaa has joined #zig
ky1ko has joined #zig
ky0ko has quit [Ping timeout: 245 seconds]
SimonN has quit [Ping timeout: 245 seconds]
marijnfs has quit [Quit: WeeChat 2.4]
DutchGh0st has joined #zig
<DutchGh0st>
Hi
<DutchGh0st>
I hit a "TODO buf_write_value_bytes union type" compile error?
DutchGh0st has quit [Ping timeout: 258 seconds]
FireFox317 has joined #zig
FireFox317 has quit [Remote host closed the connection]
mmx870 has quit [Ping timeout: 245 seconds]
mmx870 has joined #zig
Tetralux_ has joined #zig
laaron has quit [Remote host closed the connection]
fsateler has quit [Ping timeout: 268 seconds]
laaron has joined #zig
fsateler has joined #zig
kristoff_it has joined #zig
fsateler has quit [Ping timeout: 258 seconds]
fsateler has joined #zig
ntgg has joined #zig
<marler8997>
is there a way to write a test that makes sure a peice of code fails to compile?
ntgg has quit [Ping timeout: 244 seconds]
<kristoff_it>
marler8997: I think this is not yet possible. You can momentarily prepare a test in a separate file and check manually that it fails with the right error message. I think some way to do this more cleanly will be added in the future.
<marler8997>
thanks for the info
<mikdusan>
zig standard tests create a harness for that. see test/compile_errors.zig and `test.tests.CompileErrorContext`
<mikdusan>
basically it forks the zig compiler, executes a compile, captures output, groks for expected errors (minus the long part of pathname)
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
wootehfoot has joined #zig
cgag has joined #zig
rohlem has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
daurnimator has quit [Ping timeout: 276 seconds]
<rohlem>
andrewrk: Hi; I left 2 maybe-not-so-helpful comments on #1291 (comptime allocators) two days ago (sorry). Today I got a working prototype, but updating to master I think the recent lazy value mechanic threw a wrench in some comptime operations.
<rohlem>
Would you be interested in details, or do you want me to file an issue or something? Or is this already actively under construction and I should just come back to it in a couple of weeks?
<andrewrk>
I'm interested to know what regressed from the lazy value changes
cgag has quit [Ping timeout: 246 seconds]
<andrewrk>
if anything I would expect it to help the comptime allocator use case
<rohlem>
Well, my approach was to start with std.heap.FixedBufferAllocator, and simplify that until it all worked in comptime. That was probably less work than anticipated.
<rohlem>
However, now on master the line in mem.zig that `@memset` a new allocation to undefined emits "error: unable to evaluate constant expression"; specifically the subexpression "byte_slice.len - old_byte_slice.len".
<rohlem>
I just checked, and that line was in there before, so I'm pretty sure it "just worked" before and now it "just doesn't".
casaca has quit [Ping timeout: 246 seconds]
casaca has joined #zig
<rohlem>
actually, maybe control flow changed around there; I'm not so sure anymore
<rohlem>
Okay, a `@compileLog` gets triggered, which means the memset line is definitely comptime-executed
<andrewrk>
that's not what @compileLog means
<rohlem>
Does `@compileLog` trigger in dead code branches?
<andrewrk>
not in comptime dead code branches but yes in runtime dead code branches
<andrewrk>
if @compileLog gets triggered then it means the line is analysed, but not necessarily in a comptime context
<rohlem>
Right; `if(isComptime()) @compileLog();` (using the type trick from #868) is analyzed on the memset line during comptime evaluation. I'm not sure if there's a better way to check.
<rohlem>
Actually, I'll just reduce a test case around the memset, that'll be quicker.
<rohlem>
andrewrk: FINALLY found it; it was due to the change in Allocator.alignedAlloc from 6ab8b2a , but the comptime-known-ness only manifested later in alignedRealloc . So lazy values didn't have directly to do with it.
<rohlem>
Question: Is there a reason mem.zig:237 does `@intToPtr([*]u8,@ptrToInt(ptr))` instead of `@ptrCast([*]u8,ptr)`?
<rohlem>
Also, is there a semantic difference between `@ptrCast([*]T, bytes.ptr)[0..bytes.len]` and `@bytesToSlice(T, bytes)`? Only the former works during comptime.
marijnfs has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
shritesh has quit [Quit: Leaving...]
cgag has quit [Ping timeout: 246 seconds]
Ichorio_ has joined #zig
wootehfoot has joined #zig
avoidr_ has joined #zig
avoidr has quit [Ping timeout: 245 seconds]
daurnimator has joined #zig
shritesh has joined #zig
companion_cube has quit [Ping timeout: 268 seconds]
shritesh has quit [Remote host closed the connection]
shritesh has joined #zig
bastienleonard has joined #zig
cgag has joined #zig
daurnimator has quit [Ping timeout: 252 seconds]
doctorm has joined #zig
<doctorm>
On Windows with vcpkg, is there a way to get zig to play nicely with the include dirs it sets up?
<andrewrk>
you can manually add library search paths. I would also accept a PR to integrate linkSystemLibrary with vcpkg
<doctorm>
ok, thanks! new to zig and Windows dev, I may dig into vcpkg a bit and see what it's actually doing
<andrewrk>
have a look at the --help menu if you're using the CLI interface. for build.zig, I believe there are some community members here who have integrated with vcpkg with open source projects that you could look at
<doctorm>
Yeah, I've been looking at a few examples from reddit/github but they seem to have gotten further than I did. Using direct include paths, I managed to get to the point where the files were found, but got a linking error (lld couldn't find libglfw3.a). Tried a different approach using vcpkg export --raw to get a folder, but now GLFW can't find GL/gl
<doctorm>
.h, so don't know if that's problem with the package not declaring its dependencies in a way vcpkg likes, or what.
shritesh has quit [Remote host closed the connection]
<andrewrk>
doctorm, did you try --library-path?
<andrewrk>
oh, if it's a .a file you should just put a full path to it on the build line, with --object
<doctorm>
I don't see that the .a file exists, I think it may have been because I was targeting windows-gnu instead of msvc
<doctorm>
I've found the build.zig addLibPath which I assume is equivalent to library-path
<doctorm>
error changed at least when I switched to msvc
<andrewrk>
yes, but if you have a .lib or .a file, that would just be addObjectFile
<doctorm>
ok cool, I'll try and figure out where vcpkg wants me to include gl.h, then use addObjectFile if I can get the linker to complain again
<andrewrk>
it is planned to have a zig package manager. glfw would be a good candidate, because zig could compile it from source without any system dependencies
<andrewrk>
in this case there would be no setup required, you install it as a dependency, wait a minute for it to build, and you're good to go
<andrewrk>
but then the important thing would be that anyone else trying to build your project, would also not have to do anything else besides `zig build`, even if they were on a different OS and wanted to cross compile
<andrewrk>
when you depend on vcpkg you're sort of locked in to a native build
<andrewrk>
but that's not available yet. one thing at a time
<doctorm>
Would love that, cargo was the thing that really helped me start getting into systems programming coming from a scripting language background. Seems like I get stuck on this kind of stuff each time I take a weekend foray in otherwise
<andrewrk>
yeah. dependencies are the trickiest thing in C/C++
<andrewrk>
(and zig until the plans can be realized)
<doctorm>
Yeah, and a better understanding on my part would definitely go a long way, but it's a lot easier to get the motivation to sit down and play with some graphics in a neat new language than it is to sit down and really figure out how to untangle how C/C++ linking works and how it differs between platforms. I was able to at least get zig compiled real
<doctorm>
ly easily with the Wiki entry, so +1 for that.
<andrewrk>
thanks, yeah I meticulously keep that up to date
shritesh has joined #zig
<andrewrk>
there are downloads of master branch btw though
<andrewrk>
building from source is more when you want to contribute to the std lib or the compiler itself
<doctorm>
Ah yeah, I was actually getting an error on the master branch download from "zig targets". Available glibc versions: Assertion failed.This is a bug in the Zig compiler.Unable to dump stack trace: Unable to open debug info: InvalidPEMagic
<doctorm>
I was figuring out the libc story at the time, and compiling my own made that go away
<andrewrk>
hmm that's good to know
<rohlem>
andrewrk: I'll stop with comptime allocators for today. The basics work now, but a couple of comptime limitations (imo bugs) keep it from being fully usable (for more than integer types).
<rohlem>
One commit is the file with working test cases (the last one is commented out because it fails to compile), the other contains 3 small patches for std.mem that break the rest of the std but make this work.
<rohlem>
I had to do some workarounds that resulted in really arcane behaviour (slicing in one place working, but not in another). It might be easier for you to just enhance/fix the builtins I had to work around though.
<rohlem>
But the basic ides of initializing and returning a fixed buffer from a comptime block seems to work already, without requiring a new `@comptimeRealloc`.
<andrewrk>
the main point of a new builtin would be releasing memory
<rohlem>
Right. But all the comptime block's "stack" memory is released anyway, right?
<rohlem>
The only thing that "stays behind", when assigned to a global variable, is the block's result value.
<andrewrk>
yes unless it is referenced. with a fixed buffer allocator, let's say it was 10 MiB. 9.9 MiB of it is used at comptime and only a reference to 24 bytes is left over. the entire 10 MiB chunk would end up in the binary
shritesh has quit [Remote host closed the connection]
<rohlem>
Worst case we could run the comptime code twice: First with a result buffer "big enough", to determine how much memory we'll end up with, and then with the correct buffer size.
<andrewrk>
but yes if the result is copied, then only the result will end up in the binary
<rohlem>
I was under the impression that returning a struct would trigger copy elision, and use the buffer constructed in-place.
<rohlem>
Or does that not apply during comptime, because the linking-address isn't known yet anyway?
Akuli has quit [Quit: Leaving]
<rohlem>
The buffer size is part of the struct type. The type is implicitly defined by the return statement within the comptime block. So the comptime block could use the first run's "required buffer size" to specify the buffer the returned struct will have... correct?
<marijnfs>
was there no livestream?
shritesh has joined #zig
<andrewrk>
rohlem, the way it's supposed to work is that the variable's memory is the result location of the block. if you're talking about a global variable initialization
shritesh has quit [Remote host closed the connection]
<andrewrk>
marijnfs, not this week. I'm thinking about doing one monday - I hit a milestone last night that I was shooting for
avoidr_ has quit [Quit: leaving]
avoidr has joined #zig
cgag has quit [Ping timeout: 245 seconds]
<Sahnvour>
andrewrk: did you think about build.zig files depending on packages already ?
<andrewrk>
yes
<andrewrk>
build.zig is declarative; current plan is there is a build step which is the one that is what the package exports
shritesh has joined #zig
shritesh_ has joined #zig
shritesh has quit [Client Quit]
<marijnfs>
andrewrk: what was it?
<marijnfs>
still some finetuning of async?
<andrewrk>
Sahnvour, current plan is also that there is a separate file, which is not code, it's data, which specifies all the dependencies - with a separate list for unconditional and conditional dependencies - and a field that specifies whether build.zig even needs to execute or whether this is a "simple" package and it's just this one zig file
<rohlem>
Granted, it's just a single block of memory. But if on the first pass-through you could record which allocations end up being relevant, then you could give that information to the allocator the second time around
<rohlem>
so your allocations in pass 2 could end up exactly so that the relevant ones are put into the result location's buffer, and the others are left behind on the comptime-stack.
<rohlem>
(as long as what you're doing is deterministic enough - which, during comptime, should be arrangeable)
<Sahnvour>
andrewrk: I mean what if your project is complex and the build.zig itself needs to depend on packages, not for the project code but to build it
<andrewrk>
Sahnvour, those will go in a build dependencies section in the declarative file, guaranteed to be mapped into place when build.zig runs
<rohlem>
The only scenario I could see being problem were if your operation _semantically required_ a big, contiguous buffer that needs to be truncated after-the-fact. You'd have to rewrite it so that what is relevant can be a per-allocation decision.
<Sahnvour>
okay, so that will be possible, cool
<andrewrk>
rohlem, this all sounds like a bunch of useful stuff that will be relevant when trying to solve #1291. I don't think it's going to be a personal priority for me for a few months
<rohlem>
Okay - your commenting recently made me think it would be within the sooner roadmap. No problem, I'll edit my comment on the issue to include the link to my branch, and hopefully by the time you want to return to it my notes are still decipherable.
<andrewrk>
yeah, fair enough. I just wanted to check in and see what was the new status quo, since I hadn't checked in a while
daurnimator has joined #zig
shritesh_ has quit [Ping timeout: 276 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
<Sahnvour>
andrewrk: since creating an object file/library generates a C header by default, it should emit an error if an exported function or type contains zig-specific type that cannot be expressed in C, right? cf https://github.com/ziglang/zig/issues/3040
doctorm has quit [Ping timeout: 260 seconds]
<andrewrk>
Sahnvour, right. for extern structs that check already exists
cgag has joined #zig
<Sahnvour>
andrewrk: can you point me where ?
daurnimator has quit [Ping timeout: 252 seconds]
<andrewrk>
Sahnvour: look for type_allowed_in_extern or similar
<Sahnvour>
thanks
shritesh has joined #zig
<Sahnvour>
so, from the documentation, packed union should follow the same rules as packed struct in that they cannot contain an AutoLayout struct (for example)
<Sahnvour>
in this case, the check is simply missing for unions