<gruebite>
easy way to inspect memory (bytes) of a struct?
<fengb>
You can print a human readable version by passing it into fmt (e.g. std.debug.warn)
<daurnimator>
gruebite: std.mem.asBytes ?
Snetry has quit [Ping timeout: 272 seconds]
Snetry has joined #zig
tobbez has quit [Quit: Lost terminal]
Snetry has quit [Ping timeout: 265 seconds]
<BaroqueLarouche>
Has someone made a highlight.js jightlighter for Zig?
<BaroqueLarouche>
I want to use it for a presentation that Iām making with reveal.js
Snetry has joined #zig
Snetry has quit [Ping timeout: 268 seconds]
Snetry has joined #zig
<daurnimator>
BaroqueLarouche: no; but I had that as a request here the other day :)
<daurnimator>
there was someone that seemed sort of interested...
<daurnimator>
lukeholder: ^
<BaroqueLarouche>
Good
tdeo has quit [Remote host closed the connection]
tdeo has joined #zig
jcharbon has quit [Quit: Connection closed for inactivity]
Snetry has quit [Ping timeout: 268 seconds]
Snetry has joined #zig
Snetry- has joined #zig
Snetry has quit [Ping timeout: 268 seconds]
seoushi has quit [Ping timeout: 240 seconds]
Snetry- has quit [Ping timeout: 268 seconds]
<dimenus>
daurnimator: nope, my whole professional career has been in this kind of software
<dimenus>
it's just so awful
<dimenus>
lol
leeward has joined #zig
<leeward>
Fun fact: I just hacked up a Zig wrapper around some bits of libsodium that I wanted to use, and it's so much cleaner than the C version.
<leeward>
I had to write basically the same thing in C for work today, and really wish I could just do it in Zig.
<leeward>
</end whine>
<leeward>
wow, </end> I'm good at xml.
<fengb>
</end-whine>
<pixelherodev>
I'll do you one better
<pixelherodev>
</xml>
Snetry has joined #zig
<fengb>
}
<pixelherodev>
No no no...
<pixelherodev>
I was indicating an end to XML itself.
<pixelherodev>
Not a specific file.
<fengb>
)))))))))
<pixelherodev>
Noooo, s-exprs are good!
<pixelherodev>
Relatively, anyways
<pixelherodev>
On a completely different note, how do Zig stack traces work?
Snetry has quit [Ping timeout: 240 seconds]
seoushi has joined #zig
<pixelherodev>
Oh wait, that's all in the stdlib probably, so I can just look there
Snetry has joined #zig
Snetry has quit [Ping timeout: 268 seconds]
<leeward>
I usually just `gdb zigprogram`
<fengb>
llvm_value = 0x0000000000000000
<pixelherodev>
Right, should have clarified
<fengb>
That's a null pointer right?
<pixelherodev>
How the builtin.stack_trace type functions
<pixelherodev>
I think so?
<pixelherodev>
Wait
<pixelherodev>
Depends on the type of `llvm_value`
<pixelherodev>
And whether it's a Zig optional; I think Zig optional pointers have an extra bit for null instead
<leeward>
Only allownull pointers do.
rappet has quit [Ping timeout: 252 seconds]
<leeward>
Otherwise they use address 0 to represent null.
rappet has joined #zig
<fengb>
Oh yeah it's ?usize so null makes sense
<pixelherodev>
If it's `?usize`, I assume it has the extra bit
<pixelherodev>
So whether it's null is unknown
BaroqueLarouche has quit [Quit: Connection closed for inactivity]
bheads has quit [Ping timeout: 268 seconds]
<leeward>
This code keeps passing tests on the first try. I'm suspicious.
Snetry has joined #zig
<pixelherodev>
Of the code, or the tests?
<pixelherodev>
Ooh! Maybe someone did a trusting trust attack on GCC that targets the Zig compiler to make it look like tests pass when they don't, wasting resources greater than the GDP of a small nation on a prank!
dimenus has quit [Ping timeout: 268 seconds]
Snetry has quit [Ping timeout: 268 seconds]
Snetry has joined #zig
<leeward>
That seems more likely than that I'm writing code that works on the first try.
Snetry has quit [Ping timeout: 260 seconds]
<pixelherodev>
Or maybe you're not giving yourself enough credit?
<leeward>
No, I've been doing this a long time. I'm pretty sure I don't not make mistakes.
Snetry has joined #zig
<pixelherodev>
I think those two statements are in opposition to each other
<pixelherodev>
Been doing this a long time -> gotten better at it -> make fewer mistakes
<pixelherodev>
I recently wrote a full C library with *zero* memory leaks and *one* memory error caused by forgetting to null-terminate a string. If I test out my older code, there would dozens of mistakes.
<pixelherodev>
I wrote the whole thing, and didn't do any memory tests until a week ago or so, and not *one* memory leak :)
<pixelherodev>
And since the universe doesn't revolve around me, I suspect most people get better with more experience (even if some people seem determined to prove me wrong :P)
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 268 seconds]
mahmudov has quit [Ping timeout: 260 seconds]
<daurnimator>
Are tracebacks meant to work on windows?
<andrewrk>
yes. is there a regression?
<gruebite>
can i format arguments in different ways? padding, hex, rounding to decimals, binary, hex
<gruebite>
said hex twice :D
<daurnimator>
andrewrk: I just get "Unable to dump stack trace: Unable to open debug info: FileNotFound"
Snetry has joined #zig
<gruebite>
found the src, nvm
seoushi has quit [Ping timeout: 260 seconds]
<daurnimator>
(and yes I did copy across the .pdb file)
dddddd has quit [Remote host closed the connection]
return0e has joined #zig
<gruebite>
okay, i have a weird bug. i'm passing a c struct (extern) to a c function. on zig side i see 3 fields exactly how i set them, on the C/C++ side (C ABI to a C++ function), it's completely different and null fields have stuff in them.
<gruebite>
i feel like it's something simple, but haven't found it
<gruebite>
i've checked size of the struct on both sides: C side 24 bytes, zig side 24 bytes.
<gruebite>
only thing left i can think of is if sysv_abi means something
<gruebite>
for this case
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
Snetry has quit [Ping timeout: 260 seconds]
<gruebite>
i feel like this is a calling convention error, gut feeling
Snetry has joined #zig
seoushi has joined #zig
_Vi has joined #zig
<mikdusan>
andrewrk: 32 files changed, 1681 insertions(+), 862 deletions(-) gets to this (still WIP) and more; including mem::Allocator interface, and all code shifted to use mem::c_allocator:
return0__ has quit [Read error: Connection reset by peer]
return0e_ has joined #zig
Snetry- has quit [Ping timeout: 272 seconds]
decentpenguin has joined #zig
metaleap has joined #zig
Snetry has joined #zig
BaroqueLarouche has joined #zig
phillyiscool has joined #zig
<phillyiscool>
I think I'm having trouble understanding defer and its timing. I am creating a std.SinglyLinkedList in a function, and passing that into another function. If I call `defer list.destroyNode(node)` then there will be a segfault.
<phillyiscool>
Does defer not run after the current function exits?
<mq32>
okay, i think i found fundamental a problem with translate-c
<phillyiscool>
Oh, end of current "scope"
<BaroqueLarouche>
mq32: which is ?
<phillyiscool>
So my issue is not related to defer I think, because even if I call list.destroyNode() *after* the function where the LinkedList was passed into, it still segfaults.
<mq32>
BaroqueLarouche: something tries to translate function pointers to c-pointers to functions
<mq32>
so
<mq32>
[*c]extern fn () void
<phillyiscool>
So the passing into a function part isn't the problem, calling destroyNode() at all, anywhere seemingly, causes a segfault
<mq32>
yeah, my current test is actually translating it into an optional
<mq32>
but more complex stuff seems to be translated wrong
<mq32>
and wants pointers-to-function-pointers
naltun has joined #zig
<fengb>
phillyiscool: it looks like you're using the more raw API. `ListOfTransitions.init()` should have captured the allocator. My guess is that `destroyNode()` is trying to use the uninitialized "allocator" variable
<phillyiscool>
SinglyLinkedList(type).init() doesn't take an allocator
<phillyiscool>
Which is unfortunately because it means there's not a list.destroy() to destroy them all, hence my need to iterate
<fengb>
Oh sorry, I was thinking of ArrayList
<phillyiscool>
If there's a better data structure to filter an array, which is what I'm doing, I'm open to that
return0e_ has quit [Ping timeout: 268 seconds]
<mq32>
fengb: oh, 17 hours
<fengb>
Oh result location footgun
<mq32>
i should update
<mikdusan>
phillyiscool: try taking (it = node.next) out of sub-parens, and put it at end of loop block.
<mikdusan>
and put node into a tmp var
<fengb>
You also need to make a copy
<fengb>
Yeah this has been a problem >_>
<betawaffle>
that copy is weird
<fengb>
`|node|` represents the original memory location, so it's use-after-free if you destroy it in the block
<phillyiscool>
ah
<phillyiscool>
let me try this...
<fengb>
It's a design flaw :(
<mikdusan>
meh personally I like it; consistent with result location semantics
<phillyiscool>
Ok, this works:
<phillyiscool>
while (it) |node| { var n = node.next; candidates.destroyNode(node, allocator); it = n; }
<phillyiscool>
woops
<phillyiscool>
Well you get the idea
<betawaffle>
mikdusan: it just needs to be communicated better
<phillyiscool>
Thank you all very much
<fengb>
Eh, `|*node|` makes it explicitly in memory. I sorta feel like `|node|` should hoist it out as a copy by default, and reuse memory only as an optimization
<mq32>
fengb, BaroqueLarouche: i found the culprit
<frmdstryr>
the tft.zig cannot use @import("stm32")
<BaroqueLarouche>
build tft as a static library ?
<metaleap>
still.. i would have expected the above to work. why make a static lib here? thought all the packages would still be pulled in into the "big everything-joined internal single .zig source file" (whatever the moniker is for this concept) here
<fengb>
Weāve mostly punted on making libraries shareable until package manager is a real thing
<metaleap>
aka becoming equal compilation units with access to all the named-package-paths
<fengb>
So itās pretty raw atm and will most likely change soon
<metaleap>
so is this just a missing feature that one could PR in? build system should remain and continue to be top notch regardless of whatever pkg-mgr stories come and go over time =)
<fengb>
Iām pretty sure there exists an incantation that works but Iām not too familiar with it either
return0e has quit [Remote host closed the connection]
<fengb>
Also build docs could use some love :p
<metaleap>
(aka independent of any pkg-mgr superstructure, as now it is self-contained, fully-programmable, and independent of some-or-other "package" super notion, package.jsons or yamls or .locks and all that blergh =)
<metaleap>
well i'll run into the same issue as frmdstryr in ~a few days according to my schedule so i'll report back then
bheads_ has joined #zig
<metaleap>
by the by! i've taken such a liking to zig's informal ident-casings (snake / pascal / camel) philosophy that im now startled everytime seeing another `error.PascalCasedEnumerant`
<betawaffle>
metaleap: i thought pascal-case was the right one for errors?
bheads has quit [Ping timeout: 265 seconds]
bheads_ is now known as bheads
<metaleap>
dunno it's certainly everywhere in zig code but i mean the "types are PascalCased, funcs are camelCased, everything else snake_cased". taking it too literally i reckon. fine if convention for error enumerants is like it is
<metaleap>
just got so used to "parsing by case" already =) anyway
<betawaffle>
i'm used to camel/pascal case from Go, but for some reason i feel like zig functions should be snake case... maybe it's be cause of all the c code i'm interfacing with
<betawaffle>
because*
<seoushi>
I'm assuming there has been discussion on multiple return values in zig? Is it something that might make it in or is just creating a struct with multiple values to return just the way to go?
<companion_cube>
I think tuples are the way to go
<seoushi>
oh. I will read up on those then.
<betawaffle>
there are no docs on tuples yet, right?
<pixelherodev>
`I usually do `zig run file.zig || poweroff` so that I'm forced to get it right the very first time :P` wait, you run `zig` as root?
<metaleap>
companion_cube: the difference between current-zig's anonymous structs (as passed to std.debug.warn etc) and "tuples" is still eluding me
<fengb>
Those are tuples
<seoushi>
I've also been using the latest stable of zig from brew on mac and whatever is in arch's repos. Is that the best way to go or is using master generaly safe? The pace of this project makes me want to use master plus then I can file bug reports without feeling they have already been fixed
<fengb>
Tuples are `.{ 1, 2 }` (unnamed arguments)
<metaleap>
oh i can see now in your linked thread fengb --- all good then
<fengb>
`.{ .a = 1, .b = 2 }` is anon struct
<metaleap>
understood, in my head i called them "anon structs with anon fields" but also at the same time "tuples"
<metaleap>
if `tuple{` is just sugar for the same under-the-hood-mechanisms thats cool by me
<fengb>
seoushi: master is pretty stable. The CI catches a lot of the errors. There's been a lot of breaking changes past 0.5.0 so you probably don't want to use that anymore
<seoushi>
thanks. I'll work on getting the lastest on my systems then before I devel too far into my project.
<fengb>
metaleap: yeah I think right now all it needs to do is give tuples a declared type. I have some deeper questions but they don't have to be done yet
<fengb>
lol that was my exact followup
<metaleap>
heh. paste it in there for record / history
<seoushi>
just that documentation alone for master is worth the upgrade hah. so nice to have the TOC on the left side
<seoushi>
ah damn Assertion failed at /Users/sean/Projects/zig/src/codegen.cpp:9484 in gen_root_source. This is a bug in the Zig compiler. I'll try and track down what is causing this tonight
<seoushi>
ah nm. seems to be my fault. I just copied the zig from bin to replace what was in /usr/local/bin and that causes issues. running from the build folder works as expected
<gruebite>
mq32: i am also hanging out in gdnative on godot's discord
<metaleap>
desire: a top-level `pub comptime var ...`
<metaleap>
scenario: importer of a .zig can override certain logics (perhaps related to field-names -> logics injected/overridable by importer, if so offered by importee)
<metaleap>
is there an Issue for that? haven't found when searching. dont wanna spam there, so asking beforehand
<metaleap>
(incidentally the `var`s I'm talking about would be `fn`-typed)
<metaleap>
wait i seem to remember top-level decls are "intrinsically comptime", will try if that works setting some `fn`-typed `pub var` from the outside to some `fn` with comptime args in it
Snetry has quit [Ping timeout: 248 seconds]
<metaleap>
"unable to evaluate constant expression", so use-case not currently addressable. so the question remains
Snetry has joined #zig
<betawaffle>
what's the closest zig equivalent to Go's `copy` (where it returns the number of elements copied)?
<shakesoda>
if anonymous structs and tuples/lists use the same syntax anyway, would it not be possible to do both at the same time (giving you an anonymous struct with an array part)? i haven't thought this through in any kind of detail, i'm just thinking of how useful that ability is in lua
<shakesoda>
i guess it's easy enough to debate if it's any better than just embedding said array, just thinking out loud about it
<shakesoda>
betawaffle: @memcpy? you'd need to divide the size of the type by the byte length yourself, though
<shakesoda>
there's mem.copy, too
mahmudov has quit [Remote host closed the connection]
<metaleap>
i cannot pass around at comptime `fn`-typed values, right? i try all kinds of shenanigans for this but it always compile-errs
<metaleap>
now sure an arg or a field of type `fn (....) ..` is generally a function-pointer hence a runtime value
<metaleap>
but thought whether through some hackery i can "pass comptime-logic around (from one .zig to another .zig) while staying at comptime"
<pixelherodev>
Pretty sure you can pass comptime function pointers...
<pixelherodev>
s/pointers/`fn ()void` at least
<metaleap>
well it's just that in my latest attempt to do so, i couldnt possibly make sense of this compiler-error, given that "all top-level decls are order-independent": https://paste.pics/93f9e35b7251c9648ae3eaabd255f91e
<metaleap>
aaaargh my bad
<metaleap>
ignore
<fengb>
shakesoda: I think there's competing ideas of whether we should treat tuples as just structs or split them conceptually
<fengb>
I'm not sure either way, and my proposal was intended only to expose a real type to the compiler
<shakesoda>
fengb: i'm generally in favor of them being the same concept, gets me a little closer to having my beloved lua tables :)
<fengb>
daurnimator mentioned it's weird that we have foo[0] == foo.@"0"
<gruebite>
i like them being the same
<gruebite>
is there a way to dynamically get a tuple's nth member?
<gruebite>
foo.@0 or, `var i = 0; foo.@i`
<metaleap>
gruebite: it would certainly involve a lot of compiler smarts to turn into the appropriate ptr-arith based on the sizeof.
<fengb>
Yeah I'd doubt it because the tuple has heterogeneous types
<gruebite>
well even inlining
<gruebite>
like an inline loop is hard, yeah?
<fengb>
Oh I mean it won't be possible at runtime. You might be able to do comptime magic
<gruebite>
yeah runtime would be more of a bonus
<metaleap>
well that you can already do, just a bit noisy looking with the @"0" etc
<gruebite>
i meant being able to iterate at comptime
<fengb>
You can access it with `@field(struct, comptime string)`
<fengb>
So you should be able to do an inline for loop of sorts
<metaleap>
yeah together with @memberName .. it gets a bit wordy
<metaleap>
but works
<metaleap>
(if you loop with index)
<fengb>
Anyway, this discussion is getting too complicated lol. I just wanted to declare a tuple type in the function :(
<sirnaysayer>
translate-c gives me (__acrt_iob_func(@bitCast(c_uint, @as(c_int, 1)))) as the argument to the function, but it doesn't recognize the identifier for the builtin
dddddd has joined #zig
<pixelherodev>
You could just use Zig's stdout functionality?
TheLemonMan has joined #zig
<pixelherodev>
`std.io.getStdOut().outStream().stream` returns a writable stream IIRC
robinsoncollado has joined #zig
marijnfs_ has joined #zig
robinsoncollado has quit [Remote host closed the connection]
dimenus has joined #zig
<dimenus>
is [*:0][*:0]const u8 a valid type
<dimenus>
*?
<TheLemonMan>
every time I try to use translate-c to save some time I get a damn segfault
<dimenus>
hmm, i have not had that experience. It worked for vulkan, vulkan memory allocator, libmpg, and libsoundio (thanks andrewrk!)
<TheLemonMan>
don't count too much on your luck, you'll slam face-first into a segfault sooner or later
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
<pixelherodev>
It works fine for me
<pixelherodev>
ACPICA is the only big thing I've used it on though
<fengb>
dimenus: no but you can do `[*:null]?[*:0]const u8`
<pixelherodev>
`[*:0]T` requires T to be terminatable by zero; 0 is not a valid `[*:0]T`
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
dimenus has quit [Ping timeout: 265 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
<traviss>
tuple indexing?!? mind slightly blown that this works: `const tup = .{ 0, 1, 2 }; inline for (tup) |val, i| warn("val {} {}\n", .{ val, tup[i] });`
<traviss>
i didn't realize that tup.@"0" == tup[0]. cool. go tuples! :)
<marijnfs_>
yeah just code running during compilation
sirnaysayer has quit [Quit: Lost terminal]
<andrewrk>
TheLemonMan, I fixed an incorrect enum in clang.zig in the llvm10 branch
<andrewrk>
I should probably backport that to master
<andrewrk>
fengb, so.....
<andrewrk>
I just got off a plane, laptop is dead. But I tried just making the "output" function of std.fmt.format comptime, and it totally fixed the async issue
<andrewrk>
Also I think the generator approach is inherently flawed because it doesn't catch errors at compile time
<andrewrk>
So I'm blazing along with better async I/O support in std
<fengb>
Sure sounds good
<metaleap>
this compiles: `var should = if (comptime (field_type_id == .Optional)) (field_value != null) else true; if (should) {...}`
<fengb>
I had this commit message waiting, but you deserve it more :P
<andrewrk>
Yeah sorry. You put so much effort into that
<andrewrk>
Turns out there was a low effort solution all along
<fengb>
Not a problem. I ran into a bunch of snags too
<fengb>
And it's free learning
<metaleap>
the error given for the above is "control flow attempts to use compile-time variable at runtime". but again, just expressions being re-positioned
<metaleap>
interestingly: change the `var` into a `const` and same compiler error
dimenus has joined #zig
lunamn has quit [Quit: leaving]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
<daurnimator>
andrewrk: why wouldn't windows participate in "BYO OS"?
marijnfs_ has joined #zig
<daurnimator>
like..... if microcontrollers have an `openat`; why wouldn't windows
marijnfs has quit [Ping timeout: 265 seconds]
jayschwa has quit [Remote host closed the connection]