SimonNa has quit [Remote host closed the connection]
<ianlilleyt>
what is the best way to install debug symbols in build.zig?
<Tetralux>
.. Into the binary you're making with build.zig?
<ianlilleyt>
i was semi-expecting the pdb files to be copied over with exe
<ianlilleyt>
for debug builds at least
<Tetralux>
Oh right. Huh.
<Tetralux>
andrewrk, is this related to how you made installation the default build step recently?
<Tetralux>
Or is this expected behavior?
<ianlilleyt>
for now, im wondering what a decent workaround is. Any way to copy the pdb to the installation dir without a hardcoded path? i'm pretty new to the build system internals
<Tetralux>
I forget where the PDB ends up, but you should just be able to call std.fs.copyFile I think.
<Tetralux>
I've never tried to do that though, so it's possible I'm forgetting something.
<ianlilleyt>
it ends up in one of the zig-cache folders
<Tetralux>
I'm not 100% sure how you'd get it to run _after_ the build is complete... I have a feeling that nothing happens until the build fn returns.
<Tetralux>
In which case you couldn't just copy it yourself...
<Tetralux>
If not, I guess a batch/bash script that calls `zig build` and then copies it is what I've got right now.
<ianlilleyt>
that's difficult because i cant predict the zig-cache folder names
<ianlilleyt>
they are for my purposes just random characters
<Tetralux>
Oh yeah - damn xD
hio has quit [Quit: Connection closed for inactivity]
<Tetralux>
Maybe there should be a way to say "Hey Zig! Call this fn when this step is about-to-be-run/has-been-run.
<ianlilleyt>
it would be nice to have built-in support for debug symbols. Like in environments where you are allowed to embed them into exe vs not, move them to install dir optionally, etc
<Tetralux>
By "built-in" support, do you mean "support for embeddeding the symbols into the exe"
<Tetralux>
embedding*
<ianlilleyt>
no sorry, i just mean more explicit support for debug symbols inside the build system
<ianlilleyt>
and embedded symbols is one example of where explicit support would come in handy
<Tetralux>
Oh, you mean things like builder.enableDebugSymbols(false).
<Tetralux>
Or builder.setDebugSymbols(.Embedded)
<ianlilleyt>
something like that
<Tetralux>
I think the idea is that if you want debug symbols, you either use Debug or ReleaseSafe modes.
<Tetralux>
But that doesn't have the granularity of "put them in the exe" or not.
<Tetralux>
I forget if Zig puts the symbols into the exe on Windows anyway.
<Tetralux>
Or if it always reads them from the pdb or something.
<ianlilleyt>
pdb only afaik
<Tetralux>
I know that VS needs the pdb.
<ianlilleyt>
i think MS discourages embedded symbols
<Tetralux>
IIRC.
<Tetralux>
Does gdb works with them embedded on Windows?
<daurnimator>
hryx: re: closures: the answer is the same as "what happens if I return a pointer to a stack variable"
<daurnimator>
hryx: but that's why we have things like @newStackCall to make a differently-lived-stack. + the coroutine frame management things coming up....
<hryx>
yeah. "differently-lived stack" is a good way to summarize the concept. it's a little head-tweaky but I'm sure it will become clearer
<daurnimator>
hryx: for cases like a `y = map(x, fn(m:T) { return m^42; });` you don't need a differently-lived-stack though :) but that can just be an optimization. Probably not too different to copy ellision. "stack-ellision"?
<hryx>
I'm excited for anonymous functions. That example doesn't even necessitate a capture though, which is nice
<daurnimator>
hryx: I'm more excited for coroutines :)
<daurnimator>
or co-frames
<daurnimator>
or whatever they are now :P
<daurnimator>
--> I have plenty of ideas for things to do once they are in the language
<hryx>
hell yeah :)
dembones has joined #zig
kristoff_it has joined #zig
<daurnimator>
hryx: I dont' suppose I've managed to change your mind on do-while yet?
<andrewrk>
daurnimator, while (true) { ... if (foo) break; i += 1 }
<hryx>
hmm, why did you have to use usize instead of `var i: BF.Index`?
<daurnimator>
hryx: because BF.items is `maxInt(BF.Index)+1`
<hryx>
to be quite honest, I actually find the existing while easier to understand than the do-while version. That may be because I haven't used them much
<hryx>
I see
<daurnimator>
andrewrk: I guess you could still use the loop continuation? `while (true) : (i += 1) { ... if (foo) break; }`
<hryx>
can you not use `intFittingRange` to create a new type that fits BF.Index + 1?
<hryx>
oh wait, nfm
<daurnimator>
hryx: .getCell() takes a BF.Index. if you use anything larger you need an @intCast
<hryx>
you would still need the cast
<hryx>
yeah
<dimenus>
is it ok to pass a maybe ptr to a c func?
<daurnimator>
dimenus: yes. if null it will be NULL on the C side.
<daurnimator>
hryx: 1. you end up wasting the space of a pointer. 2. the size is variable at runtime: that solution requires a different struct per-size
<daurnimator>
3. you can't copy the struct around without breaking it
<hryx>
what do people actually use VLAs for?
ltriant has joined #zig
<daurnimator>
I use them all the time....
<daurnimator>
hryx: e.g. In my memory allocator
dimenus has quit [Ping timeout: 248 seconds]
ltriant has quit [Ping timeout: 258 seconds]
ltriant has joined #zig
ltriant has quit [Ping timeout: 258 seconds]
ltriant has joined #zig
rjtobin has quit [Quit: Leaving]
darithorn has quit [Quit: Leaving]
ltriant has quit [Ping timeout: 268 seconds]
<emekankurumeh[m]>
can we make the compiler output to stdout for things that aren't errors?
<daurnimator>
@compileLog ?
<emekankurumeh[m]>
no, i mean the --verbose-* options all output to stderr despite the fact they aren't errors
lqd has quit [Quit: Connection closed for inactivity]
ianlilleyt has quit [Ping timeout: 260 seconds]
brakmic has joined #zig
brakmic has quit [Remote host closed the connection]
brakmic has joined #zig
ltriant has quit [Quit: leaving]
avoidr has joined #zig
very-mediocre has joined #zig
ibutra has joined #zig
avoidr has quit [Quit: leaving]
brakmic has quit [Ping timeout: 272 seconds]
<ibutra>
Good morning, I see you already added the libC file option to the zig build system. Sry I got hold up yesterday.
<ibutra>
I was thinking about this and maybe it would also be a good idea to give an user the option to overwrite this path with his own vie the --libc command line argument.
<ibutra>
Because these path probably differ for different users it is maybe not optimal having them only setable in a file which is normally checked into version control?
<very-mediocre>
has CRIME ever been done in practice?
<daurnimator>
very-mediocre: why do you ask?
<daurnimator>
very-mediocre: note that entries in our http.headers structure have a never_index field which maps correctly into HPACK.
<very-mediocre>
because reading that HPACK spec has made me acutely aware of deflate being vulnerable
<very-mediocre>
i see
<very-mediocre>
let me see if i can get deflate working first :)
<very-mediocre>
I've got an unfortunate work project coming up so my time is about to get squashed
<daurnimator>
very-mediocre: I think HPACK might be more trivial if you need a test bed :)
<very-mediocre>
it is definitely much easier
<very-mediocre>
static huffman codes make everything so much easier
<daurnimator>
a very zig solution would be an implementation that generates huffman trees either at comptime *or* runtime -> use comptime for HPACK. runtime for DEFLATE
<very-mediocre>
in deflate, you have to build a huffman tree to encode a length+literal alphabet huffman tree and a distance alphabet huffman tree, in some obscenely short shorthand format (codelengths + ranges), i'm knee deep in thsi now
<very-mediocre>
for dynamic huffman tree support, the same code can't be used for comptime trees
<very-mediocre>
at least not my code. it allocates
<very-mediocre>
hrmm
<very-mediocre>
i guess you're right, i could have it all on the stack
<very-mediocre>
judgment call: say you have an alphabet that ends up as 288 nodes of a huffman tree, would you allocate that?
<very-mediocre>
I'm always afraid of using too much stack space
<very-mediocre>
#thinkingoutloud I should invest in a rubber duck
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre1 has joined #zig
<mq32>
hey
<mq32>
is it somehow possible to "allocate" memory at comptime in Zig?
<very-mediocre1>
not currently but there's an issue for that
<mq32>
i could just create an array large enough, right?
<very-mediocre>
shouldn't be too hard to rework to be fully stack based, the main annoyance is line 22 -> new nodes have to be created, and these nodes need to live somewhere
<very-mediocre>
the alphabet size is comptime known so we can codegen different variants, whereas I'm just using dynamic memory to accept any alphabet size
<very-mediocre>
you could simply be inefficient and provide a generously-sized buffer on the stack at the callsite that you can use for the "new" nodes
<very-mediocre>
tl;dr: in the calling scope (wherever we call HuffmanTree.fromFrequencies from), we need an array of nodes for the entire alphabet + enough buffer for creating new nodes
<very-mediocre>
and the resulting "tree" which is output is simply the root node, which when traversed, results in the desired tree.
<very-mediocre>
apologies for rambling, but tl;dr: it's actually non-trivial and I'd rather just do it separately for HPACK should I take that on
<very-mediocre>
or just use dynamic memory for HPACK anyway, in C++ i'd be using `new` like no tomorrow for this problem
dimenus has joined #zig
dimenus has quit [Ping timeout: 245 seconds]
<daurnimator>
very-mediocre: just got back to computer. will read your code
<very-mediocre>
no worries, i rambled on a _lot_ more than necessary.
<very-mediocre>
last 2 lines of that block of text is what you want. :)
<daurnimator>
very-mediocre: I don't quite understand how to write a good/fast/correct huffman decoder
<daurnimator>
very-mediocre: so what is the data structure you need?
<very-mediocre>
treenodes
<very-mediocre>
there's no getting around that for building the tree, but then for lookup it's obnoxious as you have to traverse it using depth-first search
<very-mediocre>
so at this point you add a lookup table with the final huffman codes, which is what I'm working on now
<daurnimator>
very-mediocre: do you need actual 'follow the pointer' trees? or could you just use a segmented list of the necessary depth?
<very-mediocre>
good question, I'm not familiar with segmented lists
<daurnimator>
the comment at the top of segmented_list.zig is quite a good explanation
<very-mediocre>
i'm reading that right now
<very-mediocre>
i don't think it'll work because there isn't always a power of 2 size increase
<daurnimator>
yeah I think much of the time the tree would be quite unbalanced
<very-mediocre>
rn im thinking of just doing a breadth-first traversal and document all final codes in a lookup table
<very-mediocre>
whatever's in the fringe goes into a table
<very-mediocre>
everything in the fringe, by definition, will have the same code prefix
<very-mediocre>
what's holding me back is super petty: just use std.ArrayList for the fringe (i.e. current "line" of the tree at a given depth)?
<very-mediocre>
but std.ArrayList over-provisions as it grows... I'm that petty.
<daurnimator>
very-mediocre: huh? just use appendAssumeCapacity
<daurnimator>
assuming you `ensureCapacity` first
<very-mediocre>
ensureCapacity overprovisions
<very-mediocre>
that's actually very normal and i should _want_ that to avoid repeated allocations
<very-mediocre>
i'm just petty.
<very-mediocre>
I'll get over it in a few minutes.
<daurnimator>
oh weird. I don't remember ensureCapacity doing that
<very-mediocre>
if we're gonna overprovision may as well use a sufficiently large buffer on the stack in the first place
<daurnimator>
I wonder if andrewrk would accept a PR to add a `setCapacity` function
<very-mediocre>
no wait, needs to be heap since we have to return a pointer to it.
<very-mediocre>
well it should overprovision as it grows, or else it'll realloac each time you add 1 item
<daurnimator>
very-mediocre: but your heap could be on the stack ;)
<very-mediocre>
seriously all of this is some kind of OCD I have
<very-mediocre>
i should just use std.ArrayList
<daurnimator>
very-mediocre: sure, we can have `ensureCapacity` do that; but `setCapacity` would be for those that know their exact max size.
<very-mediocre>
right
<very-mediocre>
but I don't even know that here, could be any huffman tree
<daurnimator>
Though really if I (or anyone else) ever gets around to it, we can replace it all with a maple tree :P
<very-mediocre>
"in general, there can only be log2n-1 n-bit codes" <-- maybe we can know the exact size in advance
very-mediocre has quit [Read error: Connection reset by peer]
<very-mediocre1>
n-bit codes -> if n is the depth, we _can_ know the maximum possible fringe size but it's still at runtime and I don't wanna compute a log2 each time, may as well just use ArrayList
<daurnimator>
oh. write the decoder first; it's more useful ;)
<very-mediocre>
it's easier
<daurnimator>
then its an even better place to start
<very-mediocre>
I prefer to start with the hardest things
<very-mediocre>
a little knowledge is worse than no knowledge
<very-mediocre>
doing the decoder would lead me to underestimate the encoding
<daurnimator>
I generally (in order): 1. do background research until I think I know everything there is. 2. do the obvious thing "why does everyone make it so complicated?" 3. fail: realise why no one did it that way. 4. do the next most obvious thing. 5. goto 3.
<very-mediocre>
haha, that sounds about right
<daurnimator>
sometimes you get lucky and 2. works. other times you wonder how anyone made this work, so you read other source code and find bugs, bugs everywhere.
<very-mediocre>
confession: I hate reading source code, especially C with macros
<very-mediocre>
your 1...5 points are spot on
<very-mediocre>
deflate is insanely convoluted and the RFC is deceptively simple
<daurnimator>
but in this case, I would start with the decoder, cause it *should* be easy: lets find out if that's true. If it is simple: great! and we have a roundtrip test case creator and a useful piece of code. If its difficult: well you need to learn more: and its probably going to spring up in the encoder too...
<very-mediocre>
eh, i guess. but the decoder takes for granted that certain pre-prepared data is coming in
<very-mediocre>
that pre-prepared data is where the true challenge lies
<daurnimator>
at least for hpack it comes with a few test cases: make them work :)
<very-mediocre>
i feel strongly that writing the decoder does not at all prepare you for writing the encoder
<very-mediocre>
anyway, different strokes and all that
<daurnimator>
In video/audio codecs *only* the decoder is specified. It's up to everyone to make the best encoder they can that can be decoded.
<very-mediocre>
I see
<daurnimator>
okay now I've nerd sniped myself and am trying to write a huffman decoder..
<very-mediocre>
haha
<very-mediocre>
look up puff.c which is the de-facto reference for inflate
<very-mediocre>
it's annotated for learning purposes
<very-mediocre>
if you play your cards right you could produce a working deflate/inflate before I do :]
<very-mediocre>
i'm slow
<very-mediocre>
for example I'm still hung up on the lookup table.
<daurnimator>
So I finally managed to reproduce my original issue in debug mode. #2850
<daurnimator>
As I kept reducing the test case in release-safe mode eventually it started triggering in debug mode too. which was lucky I guess
avoidr has joined #zig
fengb has quit [Remote host closed the connection]
<andrewrk>
thanks daurnimator
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
ffddr has quit [Ping timeout: 244 seconds]
SimonNa has quit [Remote host closed the connection]
Akuli has quit [Ping timeout: 245 seconds]
ffddr has joined #zig
<ffddr>
Hi! Is it appropriate place to ask beginner questions? If so - could anyone take a look on my very first zig code and give any advices on how to simplify it? https://pastebin.com/3fghTUEj
<andrewrk>
ffddr, absolutely
<andrewrk>
are there any parts in particular you feel could be simpler?
<andrewrk>
at first glance it all looks reasonable
<donpdonp>
so a return value of !T creates an "error union type", im just wondering is a union type generally available? eg. UnionType = T1 | T2;
<andrewrk>
ffddr, I see an `orelse unreachable` there. that can be directly simplified to `.?`
<ffddr>
The first thing I tried to simplify - explicit pointer aligments and using []u8 instead. Is it a good idea? I messed up all the casts for []u8 and just used *u8
<ffddr>
Thanks for ```.?```!
<donpdonp>
hmm i think that does fill what i would expect from a union type, especially with switch and union(enum).
<donpdonp>
in other langs it would be A = B | C, and the place holder names of union A = { someB: B, someC: C} seems a little different but still the same thing.
<donpdonp>
(by placeholder i mean field names of someB,someC)
<andrewrk>
donpdonp, unions in zig have safety checks, so if you access the wrong field in debug mode you'll get a panic
<andrewrk>
ffddr, you're sort of destroying the type information of the pointer intentionally for your data thing
<andrewrk>
in this case i would suggest just going with @ptrToInt and @intToPtr
<donpdonp>
after zig's type system, my fav thing is the "if (optType) |type| { }" syntax. such an easy-to-read way to handle null checking
<andrewrk>
hmm those docs should really have an example. but you can find plenty of examples in the std lib
<ffddr>
and store u64 instead of *u8? This make sense, thanks!
<andrewrk>
ffddr, usize is the integer type that is guaranteed to be the same size as a pointer
samtebbs has quit [Quit: leaving]
<andrewrk>
ffddr, and here's a related issue for the future: https://github.com/ziglang/zig/issues/2414 if this is implemented, then zig will actually be able to safety check your code when casting data back to a type
<andrewrk>
for now, you'll want to be careful with that, because it's an easy way to introduce memory unsafety
<ffddr>
andrewrk thanks, just tried with the usize, looks way better than `*align(4) u8` https://pastebin.com/5pJzzh99
<andrewrk>
ffddr, your inner @ptrCast is redundant on line 39
<andrewrk>
also the outer @ptrCast on line 47
<ffddr>
oh, I see, thanks!
darithorn has joined #zig
<ffddr>
maybe `allocator.create`(line 35) is somehow avoidable? I was looking for some kind of `std::move` alternative, maybe I missed something?
<andrewrk>
std::move is a c++ concept that only makes sense in the context of constructors and destructors, which zig does not have
<andrewrk>
it is to avoid inefficiencies that don't exist in zig
<ffddr>
I am totally fine with `allocator.create`, asked just to check that I did not miss some utility function that can help in that particular case. Like I missed `ptrToInt` and other things :)
<andrewrk>
oh no, tgschultz I finally got to your interface reform PR and the conflicts with master branch are quite intimidating
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
<tgschultz>
I'm sure. I can redo it when we know which direction we want to go with it
<tgschultz>
....but I may not be able to get to it for a while, so if you just want to close them I'm fine with that.
<andrewrk>
I'll have a look though, the diff is enough for me to see the idea that you discovered
<andrewrk>
and thanks for the writeup
mmx87 has quit [Read error: Connection reset by peer]
<donpdonp>
i ended up here because zig build has 3 lines of the error, then 15 lines of "the following command failed". I wanted to zig build 2>&1 | egrep those out, but then I lost color.
<andrewrk>
I see
<dimenus>
can you generate c headers from zig code?
<andrewrk>
that's good to know
andersfr has joined #zig
darithorn has quit [Quit: Leaving]
<dimenus>
can you have distinct integer types in zig?
<emekankurumeh[m]>
no, but there is a proposal for distinct types
<dimenus>
we could make extern enums distinct integer types instead
<dimenus>
that way we keep the type information but don't muck up the enum system
<emekankurumeh[m]>
and to answer your previous question zig can output header files from zig code but iirc the functionality isn't complete, for example you can't output function prototypes
very-mediocre has quit [Read error: Connection reset by peer]
very-mediocre has joined #zig
<dimenus>
@OpaqueHandle would cover a lot of cases
<dimenus>
except bitflags
<dimenus>
(which he notes later in the thread)
<emekankurumeh[m]>
@intToPtr(@OpaqueType(), ...)
ffddr has quit [Ping timeout: 248 seconds]
andersfr has quit []
fengb has joined #zig
ofelas has quit [Quit: shutdown -h now]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
laaron has joined #zig
_whitelogger has joined #zig
very-mediocre has left #zig [#zig]
darithorn has joined #zig
fubd has joined #zig
ntgg has joined #zig
fubd has quit [Ping timeout: 260 seconds]
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
marler8997 has quit [Ping timeout: 260 seconds]
brakmic has quit [Read error: Connection reset by peer]
brakmic has joined #zig
brakmic has quit []
SimonNa has joined #zig
FireFox317 has joined #zig
halosghost has quit [Quit: WeeChat 2.5]
<FireFox317>
andrewrk: The homepage of ziglang still mentioned the issue of the 'big' binaries, this can be removed because we have small binaries now :)
FireFox317 has quit [Remote host closed the connection]
HelloThere54321 has joined #zig
<andrewrk>
FireFox317, updated, thanks
<HelloThere54321>
For testing using the 'test "TEST" {}' syntax, is it possible to would be made possible to have the tests in one file and the code being tested in another and when running under 'zig test' the private const/vars/function would be made visible to the testing file
<andrewrk>
HelloThere54321, sounds like a good proposal
<HelloThere54321>
Shall i create a new issue for this
<andrewrk>
yes please
lunamn has quit [Ping timeout: 246 seconds]
lunamn has joined #zig
lunamn has quit [Quit: leaving]
rsdimenus has joined #zig
avoidr has quit [Quit: leaving]
fengb has quit [Ping timeout: 260 seconds]
HelloThere54321 has quit [Ping timeout: 260 seconds]