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
<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
<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:
<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?
<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
<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>
`std.io.writeFile("/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>
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