ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
mahmudov has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
Ichorio_ has joined #zig
Ichorio has quit [Ping timeout: 250 seconds]
halbeno has quit [Quit: Leaving.]
chemist69 has quit [Ping timeout: 246 seconds]
chemist69 has joined #zig
halbeno has joined #zig
wilsonk has quit [Ping timeout: 265 seconds]
mgxm has quit [Ping timeout: 264 seconds]
mgxm has joined #zig
wilsonk has joined #zig
ltriant has quit [Quit: leaving]
<pixelherodev> Regarding the zig kernel I mentioned a few days ago, the latest crash I'm getting is "reached unreachable code" in parseAbbrevTable. This is very fun to debug. Very.
<pixelherodev> Debugging the debugging facilities is a *pain*
<mq32> pixelherodev, as long as you have something like printstring, everything will be fine
<pixelherodev> I have one better actually
<pixelherodev> I overrode std.os so that STDERR goes to the terminal :)
<mq32> std.debug.warn already works? ^^
<mq32> neat
<pixelherodev> Which means e.g. std.debug.warn outputs over VGA :)
<mq32> i recommend also outputting to a serial device
<pixelherodev> I plan on setting that up soon, and switching stderr to serial, then setting stdout to the terminal
<mq32> you can redirect serial output to a file with QEMU => you have log files of your OS
<pixelherodev> Anyone know what attr_id and form_id actually mean in the DWARF abbrev table?
<pixelherodev> Actually, it might be an array_list failure...
<pixelherodev> Yeah, append() seems to be crashing :(
<mq32> how are you allocating memory?
<pixelherodev> I set up a heap, and created a mem.Allocator using it
<pixelherodev> The problem isn't actually in array list though
<pixelherodev> Seems to be either in leb.readULEB128 or an error handler
<pixelherodev> I think it might be a bug in my allocator though
<pixelherodev> With the default global_allocator, it runs OOM but it parses the header w/o issue
<pixelherodev> Does end up hitting another unreachable code at a later point though
<pixelherodev> At least now it's dying in scanAllCompileUnits instead of scanAllFunctions, though this means I need to fix the allocator
mahmudov has joined #zig
<pixelherodev> Alright, got it to the point where it's printing addresses :) Now it's just claiming that the debug info is missing (unit_length == 0)
<pixelherodev> Got it working!
<pixelherodev> The offsets used by default are wrong due to the way the debug info is being included
<pixelherodev> (line_info_offset is the correct offset; adding di.debug_line.offset gives an invalid address)
<daurnimator> pixelherodev: you might find my PR refactoring that code useful to consult
<pixelherodev> I have it working now, I'm not breaking it :P
<pixelherodev> I did figure out my heap issue though - it's alignment issues. If allocated memory isn't going to be aligned, it's allocating extra memory and returning a slightly higher address, and it's passing that modified address to realloc instead of the original address
Ichorio_ has quit [Ping timeout: 245 seconds]
<mq32> hey again
* mq32 found a critical bug in zig fmt
<mq32> have to circle it in on a minimal example, but: it deletes code
<pixelherodev> Alrighty, got the heap fully working (passing the tests & actually working for the debug info dump)! Now for the actually fun stuff :O
<ceymard> quick question that I've been pondering : why keep a stage 1 C++ compiler ? If it is to ensure buildability on a fresh system, has it ever been considered to have C sources as a possible compiler output (like nim) ?
qazo has quit [Ping timeout: 276 seconds]
waleee-cl has joined #zig
<daurnimator> ceymard: because we use LLVM/clang... and they only have a C++ API
a_chou has joined #zig
a_chou has quit [Remote host closed the connection]
<mikdusan> what does nim use for codegen?
a_chou has joined #zig
<mikdusan> oh i c. it's backend is to emit C .
a_chou has quit [Client Quit]
<ceymard> daurnimator: aren't there some C wrappers for llvm ?
<daurnimator> ceymard: yes.... infact there's one in zig itself to get translate-c working :)
<daurnimator> but then you need a C++ compiler for the wrapper anyway
<daurnimator> so a C++ compiler is a necessity for bootstraping, as long as we continue to rely on LLVM (which isn't forever! but is for an extended period still)
<ceymard> why would zig move away from llvm ?
<ceymard> daurnimator: I don't mind having to use a C++ compiler, I'm just wondering about having to maintain not one, but two compilers
<ceymard> because in the end you have to duplicate efforts ?
<daurnimator> ceymard: because LLVM doesn't support every target we want. but also because zig as a language has no reason to be tied to a specific compiler
<mq32> ceymard: you will always need a bootstrap compiler
<fengb> Theoretically we could write a backend that compiles stage2 to C. Would that be a easier endeavor than maintaining the C++ compiler?
<daurnimator> ceymard: we have been reducing the duplication. e.g. `zig fmt` used to be written in C++. but now it's in zig
<mq32> fengb, that would actually be a sane(?) option as your bootstrap compiler will be in a source-form (so in theory could be adapted to any platform)
meheleventyone has joined #zig
meheleventyone has quit [Client Quit]
meheleventyone has joined #zig
<ceymard> mq32: sure, but what if the bootstrap was the zig compiler itself, turned into C/C++/whatever
<ceymard> then you ship that
<ceymard> it builds a first compiler
<ceymard> which then re-builds the compiler itself
<ceymard> or something.
<ceymard> that's like. compiler inception
<ceymard> ! :o
<daurnimator> ceymard: but then you need the zig compiler to build the zig compiler
<ceymard> fengb: this was what I was going to :)
<ceymard> yes !
<ceymard> inception !
<ceymard> daurnimator: it's not really a problem actually, it means the previous zig compiler "generation" builds the next
<ceymard> and only one compiler gets maintained
<ceymard> in lieu of two.
<daurnimator> ceymard: I assume you've seen ?
<daurnimator> ceymard: see comments there for why your approach wasn't taken
<ceymard> the backdoor problem ?
<daurnimator> yes
<ceymard> I had not seen the comments
<fengb> Ah yeah I remember this discussion
<ceymard> it does make sense
return0e_ has joined #zig
return0e has quit [Ping timeout: 240 seconds]
meheleventyone has quit [Quit: Textual IRC Client:]
<tgschultz> darn, fixing 3378 did not fix the mysterious issue with @ptrCast seeing the wrong alignment
<tgschultz> Also another bug: the presence of a doc comment caused a compile error because it expected a `}`
<tgschultz> `error: expected token '}', found 'DocComment'`, changing it to a normal comment fixes it. So is having a comment with three forward slaashes explicitly disallowed in certain contexts now?
<mq32> tgschultz, seems like it. afaik you may only comment declarations with a doc comment
<tgschultz> yeah, docs confirm it: `Doc comments are only allowed in certain places; eventually, it will become a compile error to have a doc comment in an unexpected place, such as in the middle of an expression, or just before a non-doc comment.`. Seems like "eventually" means "now"
<mq32> but it's really good to have doc comments as a language feature
<tgschultz> It's fine. It's a little jarring to suddenly have to distinguish between // and ///, but it's a rational choice
<daurnimator> FWIW, I think we need a 3rd type of comments
<daurnimator> at the moment we have // zig fmt: off
<daurnimator> but I think it should be some special comment instead. e.g. //! zig fmt: off
<mikdusan> i like that
<mikdusan> comm-sha-bang
mahmudov has quit [Ping timeout: 240 seconds]
<tgschultz> while doesn't seem to work properly on optionals anymore
<mikdusan> ?
<mq32> tgschultz: huh? i'm using it a lot in my current projects
<mq32> but maybe result location has changed some behaviour
<mq32> there were issues regarding mutability of captured elements
<tgschultz> I'm about to post a ticket, just want to define the circumstances.
<tgschultz> it uses a captured element, but it doesn't write to it
<mq32> var node : ?*LinkedListNode = …; while(node) |elem| { node =;; }
<mq32> this code will crash / not work
<mq32> as when changing "node", "elem" gets also changed
<mikdusan> which means in certain cases you will need to make copy yourself
<mq32> yeah the case i've stated is such a case
<tgschultz> sounds related as this is also iterating over a linked list
<mq32> which i think is a design/implementation problem, as it contradicts "Reduce the amount one must remember."
<tgschultz> only I don't touch anyting. it's `while(node) |next| : (node = next) { }` and it loops infinitely.
<tgschultz> oddly, in my actual case changing the continuation expression to the gnarly `(node = if(node != null) node.?.next else null)`works but in my minimized test case it still loops
<mq32> tgschultz, that could will always loop infinitly
<mq32> you assign "node" to itself
<mq32> node = node.?
<mq32> there's a ".next" missing
<tgschultz> ugh, you're right. hold on
<tgschultz> yeah, ok. nevermind
<tgschultz> I'm just an idiot today.
<tgschultz> trying to track down why some other code is failing and got caught up on this
<tgschultz> this is all because a linked list structure that worked in 0.4.0 suddenly doesn't in 0.5.0. I'm in the lucky position of having 0.5.0 break about half of my things.
<fengb> Oh that’s result location stuff ::
<fengb> The argument in the loop is now a “view” into the original variable instead of a separate data copy
<tgschultz> I think I got tripped up because in this case the linked list is a freelist, so it's an extern union wehre the value of node is the pointer to the next element.
<fengb> So you need to do `const copy = val`
<tgschultz> that may be what is ultimately wrong in the code
<mikdusan> here is (iirc) one of the 2 cases std was hit by the change. notice the explicit copy:
<tgschultz> that behavior seems wrong to me.
<mikdusan> andrew has mentioned it's not necessarily "final"
<fengb> It's a byproduct of result location. I don't think anyone was really happy with it
* mikdusan is the lone standout i guess
<tgschultz> but a capture group without a `*` means the capture value should be immuatble. you cant' assign to it so result location should be irrelevent.
<fengb> Anyone who matters? 🙃
<tgschultz> unfortunately I don't think that can explain the problem I'm seeing. Outside of the debug code I don't have any such iteration occurring.
<tgschultz> ah, however, I do have an if statement that uses a capture...
<tgschultz> and that was the culprit
<tgschultz> I consider this behavior a footgun
<fengb> Yeah so does andrew :P
<tgschultz> anyways, time to find the real problem: why @ptrCast thinks *Node is align(16)
<mq32> <tgschultz> I consider this behavior a footgun +1
<mq32> it's way too easy to shoot yourself in the foot with that
<mq32> reference capture should only happen with |*x|, not |x|
* mikdusan points out that function parameters without `*` lets the compiler decide if reference or not
<mq32> mikdusan, yeah i know that, but i'm not sure if i like that behaviour
<tgschultz> that's true, and I get the reasoning. Maybe we need a new operator that means "no seriously, explicitly copy this" or something.
<mikdusan> someone a while back brought up a use case. how to explicitly tell the compiler, yes, i want a copy of this pointer, because i'm going to modify the pointer.
<tgschultz> I dunno. It's less obviously wrong to me than it was 10 minutes ago. But it has clearly caused enough confusion to be something that needs addressing.
<tgschultz> Any way to implement a runtime safety check?
<mq32> i think for unwrapping it could be done mostly by static analysis
<mq32> some error like "write-back to currently unwrapped value" or similar
<mikdusan> the unwrap-source is known so that might be decent
<tgschultz> that might be good enough to prevent this.
<tgschultz> has anyone had any issue with it in other circumstances?
<mq32> hmm
<mq32> i have a design problem/question:
<fengb> I think it's only a major footgun in block capture
<mq32> var con = Connection.init(…);
<mq32> my connection handler needs to run a background thread that references the Connection
<fengb> Theoretically it can happen with function arguments (passing both a value and a pointer to the value, or multithreaded stuff) but those are really rare
<mq32> is there a good way to do that without having to care if the Connection will be copied/moved by someone?
<mq32> fengb, yeah but i'd rather not have a footgun that shoots me in the foot in one out of thousand cases than one that triggers always
<fengb> I'm not saying it's a good thing
<fengb> Andrew has pointed out that this is a bad footgun that should be addressed, but he was trying to move onto async at the time
<fengb> It also might not be addressed until stage2 :/
sossy has joined #zig
<tgschultz> ah, problem isn't @ptrrCast, it's @alignOf. It really is align(16) with the changes to struct alignment
<tgschultz> If it can be done with static analysis and emit a compiler error then that should be done sooner than later. The design decision can be delayed.
<tgschultz> Nope, I was wrong again. @alignOf isn't wrong, I asked the the alignment of the ptr instead of what it aligned to, which only worked before by coincidence.
<tgschultz> So count that as a bug found by the new changes instead of created by it
return0e_ has quit [Remote host closed the connection]
<nrdmn> how do I build the std lib documentation?
return0e has joined #zig
<mikdusan> something like this-> `zig -femit-docs --output-dir zig-cache test lib/std/std.zig`
<tgschultz> I'm down to one bug remaining until all the code I care about works again.
<tgschultz> Unfortunately it is not just me being dumb this time, it's definitely a bug in codegen.
<nrdmn> mikdusan: thanks!
<nrdmn> (in build/) ./zig -femit-docs --override-lib-dir ../lib/ --output-dir zig-cache test ../lib/std/std.zig
<tgschultz> andrewrk: I know you're busy with other things, but has there been any progress on working out the codegen bug triggered by that bmp code I sent you?
<andrewrk> tgschultz, no progress yet
<andrewrk> I took some time off the weekend but now I'm back at it
<fengb> Welcome back
<andrewrk> there are a few more std lib docs things which are almost done, that I want to push on. then I'll take some time for pull requests & bugs
<nrdmn> hmm.. why are some attributes shown in the documentation such as std.os.uefi.is_the_target but all other attributes in std.os.uefi not?
<andrewrk> nrdmn, multibuilds.
<andrewrk> this is one thing that I actually have almost solved, at least for generated docs
porky11 has joined #zig
mahmudov has joined #zig
<tgschultz> andrewrk: no biggie. I know I didn't exactly hand you a minimal test case or anything.
<andrewrk> tgschultz, what command to get the behavior, after unzipping img_pkg.7z?
<tgschultz> zig test bmp_test.zig
<mikdusan> (save you a few seconds... there is doc comment that makes error on master)
<andrewrk> thanks, yep, and now I can reproduce the issue
<andrewrk> tgschultz, we have @unionInit now btw, (just saw the TODO can't wait for @unionInit comment)
<andrewrk> oh, you're already using it
<tgschultz> I may not have replaced it everywhere I could
<tgschultz> Though IIRC that comment is still in std
<tgschultz> oh, is this in bmp? I think I actually made the change and didn't remove the comment in the PixelStream that wraps all other PixelStreams.
<nrdmn> so right now only functions, variables etc. are only added to the documentation if they're used in some tests, right?
<andrewrk> right. only referenced things make it into the docs
lunamn_ has joined #zig
Ichorio has joined #zig
lunamn has quit [Ping timeout: 265 seconds]
Ichorio has quit [Ping timeout: 245 seconds]
<pixelherodev> What's the correct way to declare an array of strings? I've gotten "inferred array size invalid", "internal compiler error," etc. with my attempts so far
<mikdusan> array of literals:
<pixelherodev> I take that back, I have a `[][]u8`w/o issue
<pixelherodev> The problem is it refuses to be `for`ed :(
<pixelherodev> I forgot to declare it `const` :P
<andrewrk> tgschultz, I have produced a minimal test case
sossy has quit [Remote host closed the connection]
Ichorio has joined #zig
<pixelherodev> I now have fully working backtracing on x86. I also fixed the heap (passes tests from std.mem) :D
<andrewrk> pixelherodev, nice, is this building off of #3388 ?
<pixelherodev> Nope, freestanding kernel
<andrewrk> ahh sweet
<pixelherodev> Yep - and as I mentioned earlier, I implemented stderr over the VGA terminal
<pixelherodev> I cleaned up the terminal you used in HellOS, and extended it a bit
<pixelherodev> `"/dev/stderr", "Hello!");` actually works :)
<andrewrk> neat
<daurnimator> andrewrk: welcome back :)
<andrewrk> thanks
porky11 has quit [Quit: Leaving]
<tgschultz> thanks andrewrk
<andrewrk> looks like the generated code is fine, it just needs to bitcast the parameter
<andrewrk> this might actually simply be a new assertion in llvm9 catching a missing bitcast, that accidentally worked before
doublex has quit [Ping timeout: 240 seconds]
doublex has joined #zig
wootehfoot has joined #zig
FireFox317 has joined #zig
<FireFox317> andrewrk: If I have a simple zig file with the only content being 'const std = @import("std");\n const json = std.json;' and I merged this into a dump of the std, how would I find the types and functions that are in std.json? The problem is that the declaration that has the @import("std") can be assigned to a different name, so I cannot assume that std always refers to the standard library I think.
<FireFox317> Asking this because I'm working on a LSP Server that uses the new dump-analysis.json files
<andrewrk> FireFox317, I'll have a better solution for you in the future, but for now, you'll need to reference json to get the info you want
<andrewrk> comptime { if (builtin.is_test) { _ = json; } }
<andrewrk> if you're working on this now, I recommend to work based on an existing std lib json dump. the work you do will translate to live edited applications with some minor adjustments
<FireFox317> Yeah, I generated a dump before starting the LSP and then merge the current file that is being edited into that dump. I think I should be able to get some information then.
<andrewrk> how did you merge it without the merge tool being complete?
<andrewrk> I'm about 30% done with it
<FireFox317> Hahah whoops, busted XD actually the thing I said was what I'm going to do, I thought I could already merge some stuff
<andrewrk> ahh ok
<andrewrk> the format of the merged dump is the same as pre-merged
<andrewrk> so any progress you make won't be wasted; it will just be enhanced
<FireFox317> Jup, I saw that, nice!
FireFox317 has quit [Ping timeout: 250 seconds]
<daurnimator> Anyone used leveldb from zig before?
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk> daurnimator, heh, I haven't yet but it's one of the major dependencies of groove basin, which I plan to start rewriting in zig soon
<andrewrk> leveldb will be a good candidate to make a zig package for and have zig built it from source
<daurnimator> andrewrk: isn't it written in C++ though?
<andrewrk> yeah. the zig implementation that links clang & llvm can build c++ code
<andrewrk> leveldb has a really simple API, and I'm pretty sure it comes with a C API layer
<daurnimator> It would be an interesting use case for a zig package because we can both build it; however its also available in most distros; and we should be able to build it or link to existing
<daurnimator> yeah it comes with a C API layer ( that covers 90% of things
<andrewrk> yes it will be an interesting case study
<andrewrk> tgschultz, the bmp issue is fixed
<tgschultz> cool. Thanks, I appreciate it.
<gruebite> what's the zig strategy for accept a type that has certain attributes/methods
<gruebite> traits, so to speak
<andrewrk> gruebite, there isn't really one, but you can try using std.meta.trait
ltriant has joined #zig
chemist69 has quit [Ping timeout: 276 seconds]
return0e has quit [Remote host closed the connection]