ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<daurnimator> huh. how does deferring in a loop work?
<daurnimator> Where does the deferred list of actions live?
<daurnimator> On the stack I assume..... but then if it's in a loop how do you know how much stack space you need
<suirad> i was told the other day that defer statements happen at each iteration. If i were to guess about the stack, the compiler knows ahead of time how many defer statements are in a scope, so it could probably preallocate them
<benjikun> you could inline it (unroll the loop) if you want
<benjikun> I'm not sure how much of a difference it'll make
<daurnimator> suirad: yeah I was building on your question.... but knowing how many loop iterations happen would be akin to solving the halting problem.
<daurnimator> unless we limit it to comptime loops
<daurnimator> in which case the answer to your question is a bit different....
errpr has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
_whitelogger has joined #zig
qazo has quit [Read error: Connection reset by peer]
suirad has quit [Ping timeout: 256 seconds]
qazo has joined #zig
suirad has joined #zig
Hejsil has joined #zig
<Hejsil> daurnimator, defers are executed at the exit of a block, and each iteration of a loop, enters the loop block, executes the statements in the block, exits the block, repeat
<daurnimator> Hejsil: ah okay, that makes sense then!
Zaab1t has joined #zig
errpr has quit [Ping timeout: 250 seconds]
Zaab1t has quit [Quit: bye bye friends]
redj has quit [Read error: Connection reset by peer]
SimonNa has quit [Remote host closed the connection]
davr0s has joined #zig
fsateler_ is now known as fsateler
return0e has quit [Ping timeout: 268 seconds]
return0e has joined #zig
MajorLag has quit [Read error: Connection reset by peer]
MajorLag has joined #zig
shollrollah951 has joined #zig
errpr has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Hejsil has quit [Ping timeout: 256 seconds]
redj has joined #zig
errpr has quit [Read error: Connection reset by peer]
porky11 has joined #zig
<andrewrk> MajorLag, nice, got your PR. I'll work on getting this merged over the next few days
<andrewrk> got some others in the merge queue as well
davr0s has joined #zig
errpr has joined #zig
return0e has quit [Ping timeout: 245 seconds]
return0e has joined #zig
bodie_ has quit [Ping timeout: 252 seconds]
bodie_ has joined #zig
scriptnull has joined #zig
scriptnull has quit []
ducktype has joined #zig
<ducktype> hi
<ducktype> error: expected type 'usize', found '*[0]u8'
<ducktype> i need to pass an empty asciiz string to the last argoument of mount
<ducktype> ret = std.os.linux.mount(&"none",&"/",&"none",std.os.linux.MS_REC|std.os.linux.MS_PRIVATE,&"");
<andrewrk> hi ducktype
<ducktype> i'm out of luck, sorry for being lazy and asking here
<andrewrk> I believe you want @ptrToInt
<andrewrk> an empty string though?
<andrewrk> why not just pass 0 or undefined to the data argument, since you're not going to use it?
<ducktype> make sense trying
<andrewrk> or is that data that the kernel reads? let me look at the man page
<ducktype> thank you, my first time with zig
<andrewrk> "The data argument is interpreted by the different filesystems. "
<ducktype> golang want an empty string
<andrewrk> I think you want @ptrToInt(c"")
<andrewrk> the c"" makes it an asciiz string (null terminated).
<ducktype> very good super useful and to the point
<ducktype> ty
<andrewrk> ducktype, I'm happy to help. If you want to read more about how strings such as this might change in the future of zig, see this issue: https://github.com/ziglang/zig/issues/265
<ducktype> i'm trying some unshare/mount overlay/mount bind container like in zig
<ducktype> i've found that issue page but i've not uderstood all correctly
<ducktype> i've switched to zig because golang can't call unshare()
<ducktype> unshare needs that the calling process is single threaded
<andrewrk> I see
<ducktype> zig is cool i like the crosscompile just-works
<ducktype> so cool
<andrewrk> thank you
<andrewrk> it is still immature but I am working hard on changing that
<ducktype> i see some similarity with jay
<ducktype> but i don't think Jonathan Blow have released it already
ducktype has quit [Quit: Page closed]
<hryx> some extremely WIP stage1-generated docs:
<hryx> still mostly a prototype
<andrewrk> hryx, neat!
<hryx> *hat tip*
<andrewrk> what's going to be really exciting to me, is when each function lists all the possible errors, with the doc comments for the errors intact
<hryx> ugh, so awesommmmme
<andrewrk> this is already exciting though, nice demo
<hryx> thanks a bunch!
<hryx> next is to get imports resolved and populate the file tree on the left
<andrewrk> btw it's ok to use javascript in the generated docs (no dependencies / http requests though), to implement, e.g. a search feature
<hryx> great, I'll keep that in mind
<andrewrk> hryx, your html page ends with </div</body>
<hryx> good catch
<hryx> it might be nice to take advantage of some kind of templating like there is in the existing zig manual generator
<hryx> for now it has a lot of ugly buf_append_str(buf, "<span>") and so on
<hryx> Are there only ever three packages? root (the actual project), builtin, and std?
<hryx> trying to grasp the difference between "package" and "import" as far as the compiler is concerned
<andrewrk> hryx, a package is a mapping of a name to an import. an import alias, if you will
<andrewrk> to make "std" map to std/index.zig we create a package
<andrewrk> a package is a tuple: (pkg_name, path_to_main_import_file)
<hryx> Ahh, I see. What confused me a bit is that PackageTableEntry just contains a map of names to more PackageTableEntrys
<benjikun> hryx: doc stuff looks great so far :)
<andrewrk> hryx, ah, that's because every source file exists within a package, so we know which aliases are available to import
<andrewrk> consider, if you are library A, and you @import("B"). now someone uses your library, so they @import("A") but they don't have "B" in scope
<andrewrk> in fact for them "B" might be aliased to a completely different dependency than it is for you!
<hryx> ahh gotcha
<hryx> thanks benjikun!
<hryx> Basically where I am now the root source is parsed, and I think (?) the IR passes should have resolved the imports, so I'm trying to iterate the imports that were found
<hryx> I've been focusing my attention on the CodeGen->root_import
<hryx> or CodeGen->import_table
<andrewrk> hryx, there's one concept you should be aware of, even if you don't handle it right now. I'm looking for the issue
<andrewrk> hmm I don't think I typed it up
<andrewrk> in summary: when building we currently assume one target, one build mode, etc
<andrewrk> however code exists for multiple targets, multiple build modes
<andrewrk> when building documentation, and also for some kinds of compile errors, it would make sense to do a "multibuild" that does analysis for a complete set of supported targets and build options
<andrewrk> e.g. if (builtin.os == builtin.Os.windows) foo() else bar()
<hryx> Totally, that's a good idea. You can see I totally dodged this situation for now here: https://www.hryx.net/tmp/debug.zig.html#runtime_safety
<andrewrk> we would actually explore both branches of this even though it's a static if
<andrewrk> yeah, I think that's a good approach for now. this is going to be a very difficult and interesting problem to solve
<hryx> agreed :>
<andrewrk> I'm guessing it will come down to providing a "set" of build options to build at the same time
<hryx> a possible minimum viable approach could be to render an entirely separate copy of docs for a specific platform/triple
<andrewrk> agreed
<andrewrk> I think that's the first step
<andrewrk> I think this approach will be harmonious with the idea of generating docs for your entire project at once including all dependencies
<andrewrk> rather than looking at docs on a website, you'll be looking at the docs you specifically generate, because they will be for the target, build mode, threading model, build options, etc that you specifically selected
<andrewrk> I like the idea of searchable docs that are comprehensive to one's entire project, including dependencies
<hryx> that is a really cool vision
<andrewrk> I see it as not only docs but a code exploration tool
<hryx> yeah!
<andrewrk> example code, with clickable function names, etc
<hryx> One thing I was thinking about was linking to the tests in these docs
<hryx> examples for free
<andrewrk> yeah that's nice
<andrewrk> I haven't looked at your implementation yet, but another thing to consider, is you could have stage1 output some kind of format, and then build from source zig code that parses it and does the rest of the work, and then execute that as a child process, in the same way zig test and zig build work
<andrewrk> this would potentially save us from having to redo a lot of stuff later in stage2, as well as avoid implementing things like html templating in c++
<andrewrk> the less C++ code we have to maintain, the better
<andrewrk> and it's ok to pay some performance cost for it in stage1; we'll reclaim it when self hosted is done
<hryx> that's actually a great idea, that saves from having to write all this uggo HTML in C++
<andrewrk> great, yeah look at std/special/test_runner.zig and std/special/build_runner.zig, and the corresponding code in main.cpp
<hryx> my implementation so far is a bit jenky as I'm still getting to know the code base, but those examples you saw were in fact generated by c++ I promise :>
<hryx> I'll get it to a reasonable point and push it to a fork
<hryx> so ye can see it
<andrewrk> fun :)
<benjikun> How can I force @bytesToSlice() to use big endian reading
<andrewrk> benjikun, have you seen the std.mem.readInt* functions?
<benjikun> I haven't, I'll take a look :)
<benjikun> this is perfect ty
wootehfoot has joined #zig
porky11 has quit [Remote host closed the connection]
shollrollah951 has quit [Quit: Leaving]