<andrewrk>
BaroqueLarouche, I need a way to test for lib/std/build/emit_raw.zig so I can update it for #4710
<daurnimator>
andrewrk: might be nice to merge 4665 before 4710?
<andrewrk>
4665 is not ready to be merged
<daurnimator>
oh; doh. I'll fix it
slowtype1 has quit [Ping timeout: 268 seconds]
mahmudov has quit [Ping timeout: 265 seconds]
mahmudov has joined #zig
<daurnimator>
andrewrk: oh damn; in stage2.cpp we actually rely on the zero-termination, and ignore the length fields (like include_dir_len). misleading :(
salotz has joined #zig
mahmudov has quit [Remote host closed the connection]
salotz has quit [Ping timeout: 255 seconds]
salotz has joined #zig
salotz has quit [Read error: Connection reset by peer]
follymath has joined #zig
ur5us has quit [Ping timeout: 256 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 255 seconds]
ur5us has joined #zig
<fengb>
So because new OutStreams are comptime, they can automatically become async when needed?
<andrewrk>
yes
<andrewrk>
I'm now able to build the std lib tests in evented mode, and it's hitting a bug in the event loop implementation
<andrewrk>
so that's progress
ur5us has quit [Ping timeout: 256 seconds]
<daurnimator>
so why do we have a .outStream() method instead of a comptime .outStream field?
waleee-cl has quit [Quit: Connection closed for inactivity]
follymath has quit [Remote host closed the connection]
<mikdusan>
it saves 6 * @sizeOf(usize)
<daurnimator>
mikdusan: huh?
<mikdusan>
for comptime I'm not sure. but vtable for in/out/seekable
<daurnimator>
with them being comptime they should take 0 bits
<andrewrk>
daurnimator, it returns a struct with a runtime known context field
<andrewrk>
comptime struct fields can't have runtime values
dingenskirchen has quit [Ping timeout: 240 seconds]
<daurnimator>
andrewrk: hmmm. is there any circumstance where the context wouldn't be a pointer to `self`?
<andrewrk>
not in this branch. but "self" is a convention, not a language concept
<daurnimator>
andrewrk: well yes... but I suppose my point is more: `stream = &file.outStream; stream.write(...)` -> could that work if outStream was 0-bit (comptime) field?
<daurnimator>
and it could also be written as: `file.outStream.write(...)`
<andrewrk>
it can't be a comptime field since it has a runtime value
ur5us has joined #zig
frett27_ has joined #zig
ur5us has quit [Ping timeout: 256 seconds]
ur5us has joined #zig
frett27_ has quit [Ping timeout: 265 seconds]
<daurnimator>
andrewrk: ah right.... so not comptime then; but it could have a virtual offset within `file`?
return0e has joined #zig
_whitelogger has joined #zig
gunnarahlberg has joined #zig
gunnarahlberg has left #zig [#zig]
gunnarahlberg has joined #zig
alexnask has joined #zig
dddddd has quit [Ping timeout: 265 seconds]
alexnask_ has joined #zig
watzon has quit [Quit: Ping timeout (120 seconds)]
watzon has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
alexnask__ has joined #zig
alexnask has quit [Ping timeout: 256 seconds]
alexnask_ has quit [Ping timeout: 255 seconds]
alexnask__ is now known as alexnask
return0__ has joined #zig
squeek502_ has quit [Read error: Connection reset by peer]
squeek502_ has joined #zig
return0e_ has quit [Ping timeout: 256 seconds]
<mq32>
<fengb> @MasterQ32 I think the new OutStream rewrite solves the always-async problem
gunnarahlberg has quit [Remote host closed the connection]
AndroidKK is now known as AndroidKitKat
<fengb>
Probably be helpful if I linked the pr >_>
dddddd has joined #zig
_Vi has quit [Ping timeout: 240 seconds]
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
marmotini_ has joined #zig
metaleap has joined #zig
marmotini_ has quit [Remote host closed the connection]
r4pr0n has joined #zig
<r4pr0n>
is it possible to make a var volatile?
<r4pr0n>
i.e. that the var doesn't get optimized out if i don't use it anywhere
<mq32>
volatile var foo: u32 = 0;
<r4pr0n>
then i get "error: expected token '}', found 'volatile'"
<mq32>
ah wait
<mq32>
only pointers can be volatile
<mq32>
why do you need a volatile var?
waleee-cl has joined #zig
<r4pr0n>
for testing purposes
<r4pr0n>
not in any real application
<mq32>
hm, good question
<mq32>
ah wait
<mq32>
_ = foo; // makes "foO" used
<r4pr0n>
wait it's "_ = foo", not "var _ = foo"?
<r4pr0n>
is that a special operator
<mq32>
_ is a special variable in zig
<mq32>
you can assign anything you want, but you are not allowed to read from _
<mq32>
you can use it to discard values or mark values as "used"
<mq32>
it also brings stuff into existance:
<mq32>
comptime { _ = myFunction; } // makes sure that myFunction will be compiled and analyzed
<r4pr0n>
oh that's nice, thanks
<r4pr0n>
but it isn't really helping at this, the variable assignments gets still removed
<mq32>
hm
<mq32>
why do you want to do that? for debugging?
<r4pr0n>
yeah
TheLemonMan has joined #zig
<TheLemonMan>
andrewrk, preadAll is quite dangerous as it never checks if the amount of bytes read is zero
<TheLemonMan>
I've managed to turn it into a nice endless loop once or twice heh
<andrewrk>
TheLemonMan, hmmm, I think the *All functions should probably return an EOF error if all the bytes were not read
<TheLemonMan>
yeah, that's much better than spinning indefinitely
<andrewrk>
weird, idk what I was thinking
<andrewrk>
good thing zig is open source so that you and others can point out all the flaws
<TheLemonMan>
take that closed-source software, keep sucking behind closed doors!
<andrewrk>
TheLemonMan, I'm running tests for 4709 now locally
<TheLemonMan>
that's Azure being weird as fuck, yesterday build finished and then got stuck for 6h somewhere
<mikdusan>
that 6h hammer is the only thing that prevents complete azure outages
<andrewrk>
¯\_(ツ)_/¯
<TheLemonMan>
mikdusan, did you figure out what caused that (caching?) problem with compile flags
return0e has quit [Remote host closed the connection]
<mikdusan>
not yet. I see 3 distinct issues related to -target/-mcpu and want to dig some more
<andrewrk>
it's narrowed down to not a cache problem, right? you can observe the issue with `zig builtin`
<TheLemonMan>
`zig builtin` works fine for me now that I fixed the kernel version detection
o_O has joined #zig
<TheLemonMan>
and `zig targets` seems to ignore mcpu
<mikdusan>
andrewrk: i might backtrack on that claim, turns out `-mcpu native-off+on` is _ONLY_ an issue when using "native" and thus excludes TheLemonMan's "cortex_a8" use case
o_O is now known as Guest85152
<andrewrk>
I'll take a look after fixing the issues with #4710
metaleap has quit [Ping timeout: 265 seconds]
<mikdusan>
andrewrk: the other issue was bogus features were not checked if -target not used. I don't know if this is the correct fix, all I did was flatten block and subst null triple with "native":
<andrewrk>
mikdusan, yeah that's good, CrossTarget.parse should be called unconditionally\
pixelherodev has quit [Quit: ZNC 1.6.2 - http://znc.in]
_Vi has joined #zig
Akuli has joined #zig
Joey152 has quit [Remote host closed the connection]
<mikdusan>
andrewrk: re: CrossTarget stuff, have some progress. will open PR shortly
CommunistWolf has quit [Remote host closed the connection]
CommunistWolf has joined #zig
Guest85152 has quit [Quit: Leaving]
_whitelogger has joined #zig
CommunistWolf has quit [Ping timeout: 256 seconds]
_Vi has quit [Ping timeout: 240 seconds]
dddddd has quit [Ping timeout: 260 seconds]
dddddd has joined #zig
dingenskirchen has joined #zig
alichay has quit [Quit: Konversation terminated!]
mahmudov has joined #zig
<mikdusan>
whups; Stage2Target.cache_hash is stuffed with cpu features as bytes and eventually processed by cache_hash.cpp/cache_str which expects a null-term string. so any features coming after a null-byte are never blake2b'd
<andrewrk>
oooooh
<andrewrk>
bitten by null term strings, damn
<fengb>
Base64 encode it? Tis the JS solution to binary data 🙃
<mikdusan>
heh human string version is avail but I think andrew would prefer we feed blake2b the bytes instead of human str
<andrewrk>
the solution is simply to use the length
<andrewrk>
the implementation of cache_str calls strlen anyway
return0e has joined #zig
<TheLemonMan>
death to all the null-terminated strings
return0e has quit [Ping timeout: 255 seconds]
alichay has joined #zig
<TheLemonMan>
andrewrk, double check if your FixedBufferStream changes break the stage1 stack traces on your nixos box
<andrewrk>
ok
<andrewrk>
TheLemonMan, you're referring to removing the EndOfStream error from the set, right?
<andrewrk>
I realized that I had previously observed the preadAll problem you mentioned before, and "fixed" it in fixed_buffer_stream.zig by adding that error, but that was the incorrect place to fix it
<TheLemonMan>
yep, the seeking behaviour should be consistent with the file streams
<andrewrk>
agreed - the recent commit to the branch I made is in efforts to do that
<TheLemonMan>
iirc the traces got broken because I was doing getPos/setPos on the very last byte
follymath has joined #zig
<TheLemonMan>
shouldn't self.pos be clamped to the buffer size too?
<andrewrk>
according to my understanding, it is allowed to lseek a file past the end: "lseek() allows the file offset to be set beyond the end of the file
<andrewrk>
(but this does not change the size of the file)"
<andrewrk>
stack traces are still working nicely
<TheLemonMan>
yeah, but if you ftell the stream it'll return the file size
<andrewrk>
hmm I see
<andrewrk>
ok yes then pos should be clamped
_Vi has joined #zig
<andrewrk>
done. alright let's see how badly I screwed up this elf parsing implementation
ur5us has joined #zig
<pmwhite>
Back on the C++ question. I realized the library I am using has a C api in an h file. However, now I'm getting a linker error for __gxx_personality_v0. I tried linking with stdc++ per an SO question, but my Nix shell is having trouble finding the library.
waleee-cl has quit [Quit: Connection closed for inactivity]
<andrewrk>
TheLemonMan, hmm, i just realized that when I thought I was running your branch, actually I was running master. because my git checkout was in a different dir and i didn't notice the error
Joey152 has joined #zig
waleee-cl has joined #zig
<TheLemonMan>
lol
Joey152 has quit [Remote host closed the connection]
<mikdusan>
Azure, Azure, why hast thou forsaken me? (windows CI for #4717... hang @ same spot as TheLemonMan's 51c6bb9)
lqd has quit [Remote host closed the connection]
waleee-cl has quit [Remote host closed the connection]
cbarrett has quit [Remote host closed the connection]
euantor has quit [Remote host closed the connection]
<andrewrk>
I can reproduce locally
<TheLemonMan>
does it hang somewhere?
euantor has joined #zig
cbarrett has joined #zig
<andrewrk>
yeah it hangs in `zig build test-runtime-safety`
<TheLemonMan>
can you attach a debugger?
alexnask has quit [Ping timeout: 256 seconds]
backwhack has quit [Remote host closed the connection]
shakesoda has quit [Remote host closed the connection]
gonz_ has quit [Remote host closed the connection]
lqd has joined #zig
terinjokes has quit [Ping timeout: 240 seconds]
<andrewrk>
build.exe is stuck on windows.WaitForSingleObjectEx(self.handle, windows.INFINITE, false) in child_process.zig, presumably for the "shift left by huge amount" program
waleee-cl has joined #zig
<TheLemonMan>
hmm, I've accidentally left a std.debug.warn in the panic handler
gonz_ has joined #zig
<TheLemonMan>
does removing that solve the problem? *fingers crossed*
terinjokes has joined #zig
<andrewrk>
I have a stack trace on the child process too
<andrewrk>
yeah it's a deadlock inside std.debug.warn calling itself
shakesoda has joined #zig
<andrewrk>
wow this attach-to-process thing in msvc that I just discovered is really useful
<andrewrk>
nice catch, I didn't even notice that warn() there until now
<andrewrk>
it's fixed now, pushing to master
<TheLemonMan>
I wonder what's triggering the warn() loop
backwhack has joined #zig
lukeholder has quit [Remote host closed the connection]
tracernz has quit [Remote host closed the connection]
procnto has quit [Remote host closed the connection]
jcharbon has quit [Remote host closed the connection]
karrick has quit [Remote host closed the connection]
<pmwhite>
more precisely, I have a [*c]const mystruct, and I want a [:0]const mystruct.
<andrewrk>
std.mem.span
<andrewrk>
fengb, if you were doing any @ptrCasting with anyerror streams, that was undefined behavior, but you should be able to update your code in a straightforward manner with std.io.StreamSource
<andrewrk>
see the linked example from the PR
<fengb>
I've been doing mostly ducktype streams to work around errorsets
<andrewrk>
in that case these changes should provide some welcome code cleanups
<pmwhite>
Wait, but a [*c] has no sentinal in the type, so how word std.mem.span know what to do with it?
<pmwhite>
error: length of pointer with no sentinel
<andrewrk>
pmwhite, you should use @as to cast your c pointer into the pointer that it actually is, and then use normal zig API on it
<pmwhite>
oh wait, I see. I need a sentinal value for this struct, instead of 0.
ur5us has quit [Ping timeout: 240 seconds]
<fengb>
Hmm, wrapping streams are now parallel functions that are basically the new init function?
<andrewrk>
I read that question a couple times but I don't understand
<andrewrk>
hmmm, (both!) my redis conf talks got accepted, but the conference is now "remote"
<andrewrk>
I suppose it's not so bad, the video recordings of the talks are always more useful than the live audience anyway
follymath has quit [Remote host closed the connection]
<fengb>
CountingOutStream's new init is countingOutStream()
<fengb>
So most init will be fn(var, args) instead of the old Stream(Error).init(args)
<daurnimator>
andrewrk: aw. :( I probably would never attend a "remote" conference
<daurnimator>
I mainly go to conferences for the hallway conversations
<daurnimator>
otherwise you might as well watch youtube...
<pmwhite>
Is there a way to make a sentinel-terminated slice of structs, where the sentinel is just completely zeroed out? I mean, I could construct the value like this, but I feel like there could be an easier way.
<daurnimator>
pmwhite: you'd have to create that zeroed out value yourself.
<daurnimator>
pmwhite: use `std.mem.zeroes`.
<mikdusan>
it must be comptime value right?
<andrewrk>
pmwhite, or don't try to be so clever about it. just use [*]S and deal with it
<daurnimator>
andrewrk: I thought they were trying to create a: `[*:std.mem.zeroes(S)]S` and then use `mem.span` on some pointer given to them from C
<pmwhite>
andrewrk, but I don't know how many items are in the [*]. There is no way to figure that out with some out-of-band info.
<pmwhite>
daurnimator: righto.
<pmwhite>
std.mem.zeroes errors with and out of bounds pointer access.
<daurnimator>
pmwhite: I actually expected you to hit an error because `mem.indexOfSentinel` doesn't use `std.meta.eql`, it uses just `==`
<andrewrk>
why don't you just do what you would do in C in this case? you're using a C API
ur5us has joined #zig
<daurnimator>
pmwhite: perhaps you could share the C code that uses this structure and we can help you translate it to zig?