<shachaf>
andrewrk: One good tip for reading x86 is to use octal rather than hexadecimal.
knebulae has joined #zig
<shachaf>
(Since there are eight base registers, so the modrm byte and other things use groups of three bits.)
Srekel has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
Cucumbas has quit [Remote host closed the connection]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
Cucumbas has joined #zig
Cucumbas has quit [Client Quit]
kristoff_it has quit [Ping timeout: 245 seconds]
return0e_ has joined #zig
return0e has quit [Ping timeout: 276 seconds]
reubend has joined #zig
<reubend>
Is there a convenient way to step by 2 in for loops?
Ichorio_ has joined #zig
<daurnimator>
reubend: its just as awkward as stepping by 1...
<reubend>
The syntax for stepping by 1 is:
<daurnimator>
`var i: usize = 0; while (i < len) : (i += 1) { ...... }` just swap `+= 1` for `+= 2` :P
<reubend>
for (array) |item| {}
<daurnimator>
reubend: that's the syntax for iterating over members of a slice
<reubend>
ok I see
<reubend>
thanks!
Ichorio has quit [Ping timeout: 250 seconds]
lunamn has quit [Quit: Lost terminal]
mla has quit [Quit: WeeChat 2.2]
Cucumbas has joined #zig
<Cucumbas>
I built a zig file as a static c library and when i compile c code that uses the library I get undefined symbols __zig_probe_stack, std.sort.sort, etc.. what could this mean?
<andrewrk>
Cucumbas, can I see the full output?
<Cucumbas>
gcc -std=c89 test.c libvec_api.a -o test
<Cucumbas>
Undefined symbols for architecture x86_64:
<Cucumbas>
"___zig_probe_stack", referenced from:
<Cucumbas>
_std.sort.sort in vec_api.o)
<Cucumbas>
_std.debug.printLineFromFileAnyOs in vec_api.o)
<Cucumbas>
ld: symbol(s) not found for architecture x86_64
<Cucumbas>
clang: error: linker command failed with exit code 1 (use -v to see invocation)
<andrewrk>
Cucumbas, note that std.sort.sort is not an undefined symbol - that's where it is referenced from
<andrewrk>
try using the --bundle-compiler-rt option
<Cucumbas>
andrewrk: right, my bad. Alrighty brb
<andrewrk>
Cucumbas, no worries, I wasn't trying to rebuke you
<daurnimator>
andrewrk: I think I might close one of those as a dupe
reductum has quit [Quit: WeeChat 2.6]
Ichorio_ has quit [Ping timeout: 250 seconds]
<Cucumbas>
daurnimator: gotcha, thanks a bunch!
_whitelogger has joined #zig
chemist69 has quit [Ping timeout: 252 seconds]
chemist69 has joined #zig
adamkowalski has joined #zig
<adamkowalski>
andrewrk: sorry if this is a common question or if it's answered somewhere else, but can you discuss why you use nixos? I'm intruiged by it when watching your streams. Is there a reason you don't go with a more conventional os like ubuntu/mint/debian whatever
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
<pixelherodev>
... whoa, just checked out nixos, looks pretty neat
<THFKA4>
it solves dependency hell and lets you spawn shells with the exact dependency versions that you want
<THFKA4>
so you can be compiling zig with llvm 6 in one terminal and 9 in another
<adamkowalski>
what advantages is there over something like docker?
_whitelogger has joined #zig
adamkowalski has quit [Ping timeout: 240 seconds]
<pixelherodev>
Proposal: a mechanism for specifying what libc features are needed
<pixelherodev>
That way, if - like me - you're only using the allocator, you don't need to compile the full libc
<daurnimator>
pixelherodev: you only need to compile it once and then it should be cached.... takes like 2-3 seconds the first time ever
<shakesoda>
kinda sounds like a workaround for build performance not being good enough uncached
<shakesoda>
in this case
<pixelherodev>
daurnimator, first time takes minutes
<shakesoda>
low power cpu?
<pixelherodev>
i5
<pixelherodev>
So not really
<pixelherodev>
Plus, I've tweaked the kernel to optimize for performance (even disabling security patches that affect performance)
<shakesoda>
is it only this slow for optimized builds?
<pixelherodev>
It was pretty slow for debug build too
<shakesoda>
regular/debug builds aren't anywhere near that slow on my hardware, which is... very old
<mikdusan>
spinning disk?
<pixelherodev>
Part of it is that it seems to be running single-threaded
<pixelherodev>
SSD
<pixelherodev>
My computer is, relatively speaking, very fast
<pixelherodev>
This is the only task that's slow.
* shakesoda
hasn't had too much trouble using zig with an old cpu (second gen i7) and spinning disk
<pixelherodev>
Have you tried with `-target x86_64-linux-musl -lc`?
<shakesoda>
i have not
<pixelherodev>
Because this is also the only time I've had trouble
<daurnimator>
pixelherodev: what exactly are you compiling here?
<pixelherodev>
Now that it's built it's fine though, but that took ~6-7 minutes
* daurnimator
wants to test locally
<shakesoda>
i've been doing native builds, that would explain the difference
<pixelherodev>
Haven't done any date/time stuff in probably ever
<pixelherodev>
At least, nothing more complex than "Yo RTC, what's the current date/time?"
<pixelherodev>
Which is much simpler than actually doing the work yourself
<adamkowalski>
haha yeah I never realized how much goes into it
<adamkowalski>
but honestly it's been really fun. all day at work i'm in high level land in Python or Julia or JavaScript. So on nights and weekends I get to work on Zig and do everything from scratch
<daurnimator>
pixelherodev: you need to update to newer zig :)
<daurnimator>
pixelherodev: should I be trying with 0.5.0 release instead?
<pixelherodev>
Probably :P
<pixelherodev>
SHould be able to test on a hello world thought
<pixelherodev>
s/thought/though
<pixelherodev>
It's the libc build that was slow, not the build of my code
<pixelherodev>
On a different note, small binaries = <3
<pixelherodev>
A 100KB ELF, of which ~64KB is actual binary (the .text section), ~20KB of data (the .rodata section), with a bit more thrown in here and there (.init, .fini, .bss, etc)
<pixelherodev>
Actually, probably closer to ~70KB of .text
<mikdusan>
pixelherodev: do you have env variable "XPG_CACHE_HOME" set?
<pixelherodev>
`env |grep CACHE` turns up no results, so probably not
<pixelherodev>
No zig folder in `~/.cache` though, which I assume is where it'd be with no env variable set...
<shakesoda>
isn't the default location without an xdg dir in .
<shakesoda>
./.zig-cache or something
<mikdusan>
it should be ~/.cache/zig if you are running no older than 3-weeks master
adamkowalski has quit [Quit: leaving]
<pixelherodev>
That's probably it then - current build is from October 26
<pixelherodev>
Rebuilding now.
<mikdusan>
ok so then it would be in... ~/.local/share/zig <-- and this should be ok. i was just making sure it wasn't writing to a slow filesystem for your cache
<pixelherodev>
Ah, yeah, that folder exists
<pixelherodev>
Only about 211MB, so writing *all* of that would probably take seconds.
<pixelherodev>
Literally less than five seconds to write all of that to the SSD, and that's *with* an explicit `sync` call
<daurnimator>
3644 rebased again.
<mikdusan>
daurnimator: may I pick your brain re: std.fifo ?
<daurnimator>
mikdusan: certainly
<mikdusan>
fifo maintains a single "buffer" allocation at any given time?
<daurnimator>
mikdusan: yes
<mikdusan>
and let's say we init a buffer and .head = 0, .count = 0,
<daurnimator>
okay
<mikdusan>
head is where the next write happens?
<daurnimator>
no, head+count is
<daurnimator>
read happens at head; write happens at head+count
reubend has quit [Remote host closed the connection]
<mikdusan>
ok and one may use realign() to make it so head=0 again? ie. memcpy `[head..head+count]` to `[0..count]` ?
<daurnimator>
yep
<mikdusan>
ok. thanks that clears things up a bit for me. thanks
return0e has quit [Read error: Connection reset by peer]
return0e_ has joined #zig
<mikdusan>
in doc comment for `fn rewind()` -> /// Make `count` bytes available before the current read location
<mikdusan>
should that be: Make `size` bytes ...
<daurnimator>
mikdusan: nope; I need to rename the arg; and say "items" instead of bytes in the comment
<daurnimator>
thanks :)
<daurnimator>
mikdusan: let me know if you find anything else; ideally I'll just have to do one force push after your review...
Cucumbas has quit [Remote host closed the connection]
achaninja has joined #zig
<achaninja>
andrewrk , watching your stream on youtube, a few comments. An ISA like risc v or mips are much more regular and nicer to learning than x86. Also, worth learning about is assembly relaxation
<mq32>
this all works with my bugfix, but breaks on master in *some* cases
<daurnimator>
mq32: yeah someone needs to sit down for an hour and figure out all the offset code
frmdstryr has joined #zig
<mq32>
it only fails when you are on even-sized byte offsets
<mq32>
* full byte offsets
<mq32>
and then explodes because the code _now_ inserts ABI alignment into packed structs
wootehfoot has joined #zig
lunamn has joined #zig
jonathon has joined #zig
<jonathon>
Can someone point me to an example of concatenating runtime strings? The examples in the docs all seem to be for compile time-known strings (unless I'm misunderstanding, which is quite possible).
<mq32>
daurnimator: my CPU burns right now, running the test suite
jokoon has joined #zig
reubend has joined #zig
<mq32>
okay, my change only breaks two tests :D
<jonathon>
I've trying to use C interop to write a basic MQTT client but can't seem to pass a string to the C library with the expected type, https://godbolt.org/z/xeDP8p, `expected type '[*c]const u8', found '[]const u8' ` . I _think_ this is because the string is a slice instead of an array, but it needs to be runtime-generated...
deesix has joined #zig
<mq32>
try c"hello, world" for string literals
<mq32>
and use std.Buffer for creating zero-terminated strings
<jonathon>
(reading)
FireFox317 has quit [Ping timeout: 240 seconds]
<mq32>
i feel betrayed
<mq32>
Code Generation [1/2643] Assertion failed at /home/felix/projects/zig/src/analyze.cpp:9051 in get_llvm_type. This is a bug in the Zig compiler.
<mq32>
the function is right... but that was before my change
nomadgamma has joined #zig
vexu has joined #zig
FireFox317 has joined #zig
riba has joined #zig
waleee-cl has joined #zig
<jonathon>
Hmm. Any change I make (using std.Buffer, std.cstr.addNullByte, applying https://github.com/ziglang/zig/compare/null-terminated-pointers) all lead back to the same error of incompatible types. Using @ptrCast([*c]const u8, var); doesn't result in an error, though I don't really know what it's actually doing, and the library call fails.
<jonathon>
This probably means I'm fundamentally misunderstanding how slices work.
ForLoveOfCats has joined #zig
<jonathon>
Yes indeed. A slice has a pointer, so I needed to pass `var.ptr` rather than `var` or `&var`.
Akuli has joined #zig
reubend has quit [Remote host closed the connection]
<mikdusan>
mq32: wouldn't it be clearer to have _packed_ computation use a new function instead of get_abi_size_bytes() ? eg. get_abi_size_bytes_packed()
return0e has joined #zig
return0e_ has quit [Ping timeout: 246 seconds]
<andrewrk>
jonathon, the tests aren't even passing in #3728, it doesn't make sense to use that branch yet
<andrewrk>
`'[*c]const u8', found '[]const u8'` -> use the `ptr` property of slices. slice.ptr
rjtobin has joined #zig
jokoon has quit [Quit: jokoon]
reductum has joined #zig
FireFox317 has quit [Ping timeout: 240 seconds]
ForLoveOfCats has quit [Quit: Konversation terminated!]
Ichorio has joined #zig
<jonathon>
andrewrk: Yup, I got there in the end. Using the null-terminated-pointers branch was just part of me narrowing down what I was doing wrong.
<jonathon>
On another note, how does Zig handle OS signals, e.g. SIGINT? I can see std.os.SIGINT but can't find any way to detect and handle an interrupt.
reductum has quit [Quit: WeeChat 2.6]
traviss has joined #zig
<andrewrk>
jonathon, zig doesn't do much on your behalf - you might be interested in reading the code that runs before main()
<traviss>
thanks andrewrk. i removed my build/lib directory and it works now. :)
<andrewrk>
traviss, if you reconfigure with that -D option then you won't have to remove that dir in the future
<andrewrk>
(or you can remember to `make install`)
<andrewrk>
unfortunately cmake doesn't let us run an arbitrary command with the install target, otherwise this would Just Work
<traviss>
yeah, i used `cmake .. -DZIG_SKIP_INSTALL_LIB_FILES=on` and `make -j3 install`. maybe it was an old lib directory?
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
Gah. Updating all code to use @as is a pain, and there's apparently other breakages too...
<pixelherodev>
I guess that's the downside of using the git build
<andrewrk>
if there are other regressions, I recommend to stick with the working version of zig for now; these recent regressions are a priority
<andrewrk>
I can't remember, is your project open source?
<pixelherodev>
The biggest thing is that I still haven't gotten around to adding in support for custom OSes to the stdlib
<pixelherodev>
Yeah
<pixelherodev>
And I can't do that because it'll take time away from this, and there's only one week left to work on it ;P
<pixelherodev>
So for now, I'll probably try to remember what commit was working and use that
<andrewrk>
I was planning on trying a bunch of folks' projects before merging #3728. I wouldn't mind throwing some regression fixes in there before merging\
vexu has quit [Quit: WeeChat 2.6]
<andrewrk>
thanks for putting up with the instability :)
<pixelherodev>
It's worth it :)
<pixelherodev>
Once I get around to fixing up the upstream standard library so I don't need the forked copy, it'll be completely minor to me
<andrewrk>
ahh that's why you have so much @as work to do, merge conflicts in std/
<pixelherodev>
Yeah
<pixelherodev>
And since my project intimately depends on a working standard library, I can't just ignore it :(
<andrewrk>
yeah this "bring your own OS layer" thing is going to be really nice for your use case
Akuli has quit [Quit: Leaving]
<pixelherodev>
Which is why I plan on implementing it the instant this game jam is over :)
<andrewrk>
you know... it might be as simple as a 1 line change in std/std.zig
<pixelherodev>
Eh, I'll see if I can quickly do it tonight
<pixelherodev>
If I can, it'll take no more effort than switching back the Zig compiler version :P
<andrewrk>
it's probably a bit more involved than that
<pixelherodev>
Yeah, there's also the os/bits stuff, though that can *possibly* be embedded in root.os
<andrewrk>
but maybe not! you could copy paste what you need in your pub const os = struct { ... };
<andrewrk>
only the stuff that is depended on will be looked for
<jonathon>
Just in case anyone is interested, current state of my MQTT client with SIGINT handling: https://godbolt.org/z/CzZAuG
<pixelherodev>
andrewrk, I think it makes more sense to instead tweak std/os.zig to import a different system instead of replacing os.zig entirely
<andrewrk>
jonathon, evented I/O seems relevant to that use case
<andrewrk>
pixelherodev, that sounds reasonable
<pixelherodev>
Yeah, there's more to do - need to decide how debug info should be handled by default...
<pixelherodev>
Freestanding currently errors out with std.debug as "unsupported OS." The easiest option is to make it use DWARF info there also, but that's not necessarily correct
<jonathon>
andrewrk: I'll look at that next, thx.
Ichorio has quit [Ping timeout: 245 seconds]
<andrewrk>
jonathon, just a heads up, zig's evented I/O support is very promising but still at the "proof-of-concept" stage
<jonathon>
Ah, then I might stick to this "loop" approach for now. In any event, this turned out to be a nice project for learning some Zig.
<andrewrk>
fengb, was that you asking about default field values in @typeInfo?
<andrewrk>
it was the same problem with the `sentinel` field of @typeInfo for pointers. so I went ahead and solved it
<daurnimator>
oooo, var as struct field type
<andrewrk>
just like a field of type `type`, it forces the struct to always have a comptime-known value
<daurnimator>
yeah that makes sense
<andrewrk>
it was either this or multiple special builtins specifically for dealing with this field and the default value field, etc
<fengb>
Neat
<fengb>
I’m really liking arbitrary sentinels. Feels a lot more natural than just 0/null
<pixelherodev>
One major annoyance is with disabling evented I/O
<daurnimator>
pixelherodev: huh?
<pixelherodev>
For the "Bring your own OS layer" thingy
<daurnimator>
Why is disabling evented io annoying there?
<pixelherodev>
Evented I/O causes a number of issues, least of which is with std.Thread throwing an Unsupported OS compiler error
<pixelherodev>
Seems to be trying to use the event loop even with blocking I/O enabled
<daurnimator>
that sounds odd...
<pixelherodev>
Which I think might be because std/os.zig has an `if (std.event.Loop.instance) |loop| `
<pixelherodev>
Which indirectly causes the field `extra_threads: []*Thread,` to be validated...
Ichorio has joined #zig
<pixelherodev>
It's not that it's trying to use the event loop, it's that just checking if the event loop exists causes problems if threading isn't supported
<daurnimator>
ah interesting
<daurnimator>
shouldn't we be able to have a `*Thread` without evaluating the definition of Thread?
<daurnimator>
or I guess not: we need to know if its a 0-bit type or not
<daurnimator>
(is that true?)
<andrewrk>
pixelherodev, does your OS even support evented I/O? it would be reasonable to simply say that is unsupported
<andrewrk>
isn't a compile error if the application chooses evented I/O appropriate for your OS?
<andrewrk>
one of the main benefits of zig code being agnostic to evented I/O or not is that it will work on OS's that don't support it
<pixelherodev>
andrewrk, the point is that it's crashing even without evented I/O
<pixelherodev>
<pixelherodev> Which I think might be because std/os.zig has an `if (std.event.Loop.instance) |loop| `
<andrewrk>
std.event.Loop.instance should be comptime known to be null when evented I/O is disabled
<pixelherodev>
That results in it trying to validate a []*std.Thread field
<pixelherodev>
Right, but it's still validating the std.event.Loop type
<pixelherodev>
Which causes a compile error of Threading Unsupported
<andrewrk>
pixelherodev, I see. I can reproduce this in master branch with choosing evented I/O and --single-threaded
<andrewrk>
or maybe that's a different issue
<pixelherodev>
Probably a slightly different issue
<pixelherodev>
Here, the problem is that the types themselves are invalild
<pixelherodev>
s/invalild/invalid
<pixelherodev>
There's a compiler error just parsing std.Thread
<pixelherodev>
The real fix is to modify std/os.zig so that EAGAIN doesn't even check the loop in blocking I/O mode
<andrewrk>
what's the compiler error parsing std.Thread?
<pixelherodev>
Though I suppose a more fundamental fix would be to patch the compiler to not analyze the full type of an optional pointer whose value is known at comptime to be null
<daurnimator>
andrewrk: hits the @compileError unsupported OS
<pixelherodev>
^
<pixelherodev>
Relatively simple workaround though
<andrewrk>
pixelherodev, are you sure you're giving comptime null for event.Loop.instance? I don't see why it would be looking at the fields of the event loop. why is it even looking at Thread?
<pixelherodev>
Changing the if by EAGAIN in std/os.zig to `if (std.io.mode == .evented and std.event.Loop.instance != null) {` fixes the problem
<pixelherodev>
So 99% sure
<daurnimator>
andrewrk: because event.Loop has a ` extra_threads: []*Thread,`
<pixelherodev>
IIUC it's validating the struct
<pixelherodev>
And a comptime block validates that I/O is in blocking mode
<andrewrk>
it seems like it shouldn't be looking at the fields of Loop
<pixelherodev>
`comptime std.debug.assert(std.event.Loop.instance == null);` gives the same error
<pixelherodev>
" /home/noam/Documents/Development/indomitable/src/zig/std/event/loop.zig:21:5: note: while checking this field"
<pixelherodev>
Indirectly caused by that assertion
<pixelherodev>
Anyway, just four errors left to fix (and just four lines!)
<daurnimator>
andrewrk: as Loop.instance is a `?*Loop`, doesn't it need to know what a Loop is?
<daurnimator>
(nevermind that its inside of the Loop definition)
<pixelherodev>
In theory, since it's null, it shouldn't need to...
<pixelherodev>
Lazy analysis shouldn't care since the type isn't ever actually used
<andrewrk>
daurnimator, that's probably why it's happening but it's not theoretically required
<pixelherodev>
An argument could be made that it's a compiler bug since it's analyzing a struct that it doesn't need to, which is a violation of lazy semantics
<andrewrk>
yeah, I'd call this a bug.
<pixelherodev>
Should I open an issue?
<andrewrk>
yes if you're willing to take the time to make a nice small test case. which I wouldn't expect you to do
<andrewrk>
this is the kind of thing that would certainly regress without a test case
<pixelherodev>
Will do once I finish this up
<daurnimator>
pixelherodev: did you have an easy way to replicate?
<pixelherodev>
Next weird problem is that something in the stdlib seems to be using the direct allocator
<pixelherodev>
daurnimator, can probably whip one up really easily
<pixelherodev>
Just make a struct that always throws a compileError when evaluated, have an optional pointer set to null, `comptime std.debug.assert()` will throw a compiler error
<daurnimator>
I'm curious if this would help: `pub const instance: if (std.io.mode == .blocking) void else ?*Loop = if (std.io.mode == .blocking) {} else if (@hasDecl(root, "event_loop")) root.event_loop else default_instance;`
<pixelherodev>
It might, but that's just a different workaround
<andrewrk>
that's also not compatible with if (std.event.Loop.instance) |loop|
<daurnimator>
andrewrk: oh, `?void` then?
<daurnimator>
pixelherodev: but it would be in one place, rather than the many EAGAIN checks and other things../
<andrewrk>
daurnimator, I'm not recommending to do this, but it would be @as(?void, {})
<pixelherodev>
It's already in one place
<pixelherodev>
There's only a single EAGAIN where it occurs
<andrewrk>
it's planned to be in nearly all of them
<daurnimator>
pixelherodev: probably because you're only using one of the functions in std.os.
<mikdusan>
pixelherodev: "something in the stdlib seems to be using the direct allocator" --> event/loop.zig `initThreadPool()` --> // TODO: https://github.com/ziglang/zig/issues/3539
<pixelherodev>
daurnimator, ... yeah that's a fair point.
<andrewrk>
evented I/O integration into std.os is only done with read() right now, but it's planned to integrate with all the I/O
<daurnimator>
mikdusan: or std.debug.getDebugInfoAllocator: debug_info_arena_allocator = std.heap.ArenaAllocator.init(std.heap.direct_allocator);
<pixelherodev>
So, in blocking I/O mode, replace event/loop.zig with a struct containing a null pointer to void? That's probably a deeper fix to both issues
<pixelherodev>
daurnimator, shouldn't be th... no wait it's probably that thanks
<pixelherodev>
Forgot I replaced debug.zig with the upstream copy :P
<pixelherodev>
Yep, two bugs left
<daurnimator>
andrewrk: FWIW I'm still of the opinion that the ultimate interface for I/O needs to be more than the evented style you're going for here in std.os
<pixelherodev>
Though this still will probably leave large parts of the standard library usable, it shouldn't *break* anything, so it's not a bad start