wootehfoot has quit [Read error: Connection reset by peer]
selby has quit [Quit: My MacBook has gone to sleep.]
osa1_ has joined #zig
osa1 has quit [Ping timeout: 272 seconds]
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
<mikdusan>
is this the same thing? `mem.containsAtLeast(T, haystack, expected_count, needle)` vs `mem.count(T, haystack, needle) >= expected_count`
a_chou has quit [Quit: a_chou]
<mikdusan>
oh i see, it's an optimization. a short circuit.
xackus has quit [Ping timeout: 256 seconds]
jonase has joined #zig
jonase has quit [Ping timeout: 256 seconds]
xackus has joined #zig
selby has joined #zig
selby has quit [Quit: My MacBook has gone to sleep.]
<andrewrk>
yep
xackus_ has joined #zig
xackus has quit [Ping timeout: 246 seconds]
joey152 has joined #zig
mikdusan has quit [Quit: WeeChat 2.5]
bitmapper has quit [Quit: Connection closed for inactivity]
selby has joined #zig
leon-p has quit [Quit: leaving]
selby has quit [Quit: My MacBook has gone to sleep.]
joey152 has quit [Remote host closed the connection]
jonase has joined #zig
jonase has quit [Ping timeout: 265 seconds]
jonase has joined #zig
jonase has quit [Ping timeout: 264 seconds]
nvmd has quit [Ping timeout: 240 seconds]
nvmd has joined #zig
cole-h has joined #zig
mikdusan has joined #zig
xackus_ has quit [Ping timeout: 264 seconds]
jonase has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
jonase has quit [Ping timeout: 260 seconds]
selby has joined #zig
koakuma has quit [Quit: Leaving.]
jonase has joined #zig
_whitelogger has joined #zig
selby has quit [Quit: My MacBook has gone to sleep.]
xackus_ has joined #zig
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
IridescentRose13 has joined #zig
cole-h has quit [Quit: Goodbye]
IridescentRose13 has quit [Quit: Leaving]
osa1_ is now known as osa1
jonase has quit [Ping timeout: 260 seconds]
jonase has joined #zig
nycex has quit [Ping timeout: 240 seconds]
jonase has quit [Ping timeout: 240 seconds]
osa1 has quit [Quit: osa1]
nycex has joined #zig
jonase has joined #zig
osa1 has joined #zig
jonase has quit [Ping timeout: 246 seconds]
tyrion-mx has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
jonase has joined #zig
jonase has quit [Ping timeout: 264 seconds]
<mikdusan>
ping daurnimator
<daurnimator>
mikdusan: pong
<mikdusan>
"That took my development feedback cycle up to the scale of minutes" <-- this is on linux?
<mikdusan>
re: #7637
<daurnimator>
mikdusan: yes
<daurnimator>
mikdusan: trying to work on parts of the standard library ended up requiring a `make` invocation; which ended up recompiling+relinking all of stage 2; which takes minutes on my PC.
<mikdusan>
hmm... yes but technically it's not doing an install
<daurnimator>
`zig build` has no separation of build vs install.... but that wasn't the point: I wanted to be able to work on the standard library and build system without having to `make` along the way: introducing that flag again seemed to fix things.
<mikdusan>
what's happened is there are now 2 things combined into `make`: artifact stage1 and stage2. neither of which get installed.
<mikdusan>
i think what you want is a way to build just stage1 iteratively
<daurnimator>
no. I didn't want to build stage1 *or* stage2
ofelas has joined #zig
<daurnimator>
what I wanted is for stage2 to not use its "installed" (to the `build` folder) copy of the stdlib; but instead the one in my zig checkout
<mikdusan>
then something is wrong with stage2 if it doesn't do that
<daurnimator>
?
<mikdusan>
i dunno still confused. I'd have to see a minimal set of steps to understand exactly where it's forcing you to `make`.
<mikdusan>
is it as simple as tweaking lib/std/build.zig, and subsequent `zig build ...` doesn't see the changes?
<daurnimator>
mikdusan: apparently not. I just tried that now and it worked
<daurnimator>
oh wait
<daurnimator>
I have that SKIP thing applied locally :P
<daurnimator>
you might have to try yourself
belgin has quit [Quit: Leaving]
<mikdusan>
on master one edit to lib/std/build.zig (a std.debug.warn() statement) and subsequent "zig build ..." recompiled and picked up change.
<mikdusan>
so that's not it.
jonase has joined #zig
jonase has quit [Ping timeout: 240 seconds]
osa1 has quit [Ping timeout: 272 seconds]
sord937 has joined #zig
xackus_ has quit [Ping timeout: 264 seconds]
xackus_ has joined #zig
jonase has joined #zig
FireFox317 has joined #zig
jonase has quit [Ping timeout: 256 seconds]
osa1 has joined #zig
sord937 has quit [Quit: sord937]
ltr has joined #zig
Nypsie[m] has joined #zig
nycex- has joined #zig
nycex has quit [Quit: Quit]
waleee-cl has joined #zig
xackus_ has quit [Ping timeout: 240 seconds]
<Nypsie[m]>
ifreund: Any change you're here? :)
<Nypsie[m]>
s/change/chance
jonase has joined #zig
Akuli has joined #zig
cole-h has joined #zig
jonase has quit [Ping timeout: 265 seconds]
<FireFox317>
hi Nypsie[m] :)
<Nypsie[m]>
Hey FireFox317
<Nypsie[m]>
:)
TheLemonMan has joined #zig
leon-p has joined #zig
fputs has joined #zig
<FireFox317>
Can I depend another PR on a PR that has not been merged yet?
<Nypsie[m]>
Yeah, you can create a branch on top of the other branch, rather than master
<FireFox317>
yeah sure, but github doesnt like that
<FireFox317>
I cannot select that i want a PR that compares to my branch
<FireFox317>
well, andrewrk i have a commit ready that adds optional support to the LLVM backend :) it is currently blocked on #7725 and #7730
bitmapper has joined #zig
cole-h has quit [Ping timeout: 246 seconds]
ltr has quit [Ping timeout: 256 seconds]
<mikdusan>
ugh. CMakeLists.txt ZIG_STAGE2_SOURCES is... not very robust. Problem is generating that list is subject to zig lazy system,
<mikdusan>
if I run it on mac, many linux files don't get included, that kind of thing.
Stephie has quit [Read error: Connection reset by peer]
Stephie has joined #zig
<daurnimator>
mikdusan: we talked about this: the answer was to just include every .zig file
<daurnimator>
(non-test)
cow-orker has quit [Ping timeout: 256 seconds]
<mikdusan>
recursive src/*.zig and lib/*.zig I presume ?
<BaroqueLarouche>
Which commit chagne the behavior of std.fmt to require {s} for formatting strings ?
<BaroqueLarouche>
man event std.fmt.formatType has lots of `if (child_type == u8)`
<BaroqueLarouche>
what a mess
<tyrion-mx>
Hello, is there a plan to have a central repository for zig libraries? Something like pypi or npm?
<daurnimator>
tyrion-mx: unknown.
<TheLemonMan>
BaroqueLarouche, it's gonna get better/worse with #7676
<tyrion-mx>
daurnimator: Ok. Does it mean that it has not been considered yet since there are more important things to do? Or that there are some potential reasons not to do it?
<olabaz>
but I don't think that's the way to do it
<Nypsie[m]>
You need to provide a size to the buffer you provide i.e: `var buf: [100]u8 = undefined`
<olabaz>
I tried that but it gives the error: ./src/main.zig:10:51: error: expected type '[]u8', found '[100]u8'
<olabaz>
Nypsie[m]: ^
<Nypsie[m]>
olabaz: stdin.read(&buf);
<Nypsie[m]>
And then for example you can print the message with `std.debug.print("message: {s}\n", .{buf[0..bytes_read]});`
<olabaz>
Nypsie[m]: ah thank you. Ok that makes sense
<olabaz>
does it null terminate my buffer?
<Nypsie[m]>
Don't believe so. Slices and arrays have a `.len` field to determine the length
<olabaz>
ok. []T is a slice?
<Nypsie[m]>
Yes
<olabaz>
why does &buf pass in a slice instead of a pointer
<Nypsie[m]>
It coerces to a slice
a_chou has joined #zig
<mikdusan>
buf is an array. &array is slice of entire array. equivalent to array[0..] or array[0..array.len]
<mikdusan>
whups. &array is actually &[100]u8 which then coerces exactly like Nypsie[m] says
a_chou has quit [Client Quit]
<andrewrk>
marler8997, what's the difference between removeDotDirsSanitized and std.fs.path.resolveWindows?
<olabaz>
so unlike in C where &array is pointer to first element, here &array is pointer to array which coerces into slice?
<fengb>
Yes, arrays are values not pointers
<olabaz>
interesting thanks
<andrewrk>
marler8997, also doesn't this implementation perform incorrectly with respect to symlinks?
selby has quit [Quit: My MacBook has gone to sleep.]
olabaz has left #zig ["WeeChat 3.0"]
<marler8997>
andrewrk, that function doesn't touch the filesystem, so symlinks aren't relevant
<marler8997>
all it does is remove "." and ".." from the string
<andrewrk>
consider std.fs.openFile("a/../b")
<andrewrk>
if you resolve the path without getting the file system involved, this is equivalent to openFile("b")
<andrewrk>
but a could be a symlink to somewhere else, in which case it would be attempting to access the "b" file inside a different directory
nvmd has quit [Read error: Connection reset by peer]
<marler8997>
to be honest I don't know much about how symlinks are supposed to work on windows, they are a pretty new thing
<marler8997>
I pulled the implementation from reactos
mgxm has quit [Quit: ....]
<marler8997>
I could be missing a step where I'm supposed to resolve symlinks before removing "." and ".."
jonase has joined #zig
mgxm has joined #zig
<andrewrk>
I think it's worth solving symlinks here
<marler8997>
yeah definitely
<andrewrk>
if necessary we can have a "hot path" where you don't use any ".." or "." and not have to do it
<marler8997>
to be clear, the logic I added here is the same logic that ReactOS uses to normalize the final path
<marler8997>
however, for symlinks to work another step needs to be introduced
<andrewrk>
I wonder if reactos supports symlinks
<marler8997>
good question
jonase has quit [Ping timeout: 264 seconds]
<marler8997>
and the other question is what's supposed to happen first, symlink resolution or ".." resolution
<marler8997>
I see in linux they perform symlink resolution first
<marler8997>
looks like on windowse it's the opposite
<marler8997>
it performs ".." resolution before symlinks, so the behavior in my PR matches what windows does
<andrewrk>
oh interesting
<andrewrk>
in that case we're left with the question about whether the cross platform API (std.fs) should attempt to provide the same semantics across multiple OS's or whether it should do OS-specific behavior for this case
<andrewrk>
I think the precedent is to try to provide the same semantics where applicable
<andrewrk>
s/applicable/possible/
<marler8997>
which behavior do we want to choose, windows or linux behavior?
<andrewrk>
I think ".." in std.fs paths should support following symlinks
<marler8997>
why?
xackus_ has quit [Ping timeout: 260 seconds]
<andrewrk>
because symlinks are common in posix systems, and this is how they are expected to behave. on windows systems where they are more rarely used, having the posix semantics is not a big deal
<andrewrk>
but on posix systems, not respecting symlinks in file paths would be extremely problematic
<marler8997>
ok fair enough
<marler8997>
this might cause a fair amount of extra overhead on windows...hmmm
<andrewrk>
but only if you use ".." in a file path
<marler8997>
this means that for all filesystem calls, we're going to need to get the filesystem attributes for every directory in each path
<andrewrk>
and we only have to do 1 syscall per ".."
<andrewrk>
for the path directly preceeding it
<marler8997>
I suppose that's true
<marler8997>
and if the file doesn't exist, then we just default to removing it correct?
<andrewrk>
idk maybe the behavior should just be different on windows. I'm not completely sure we should try to handle this
<andrewrk>
what do you think?
<marler8997>
I think this is the sort of decision I would try to avoid having to make
<andrewrk>
ha fair enough
<marler8997>
by that I mean, is there a way Zig can avoid having to make the decision
<andrewrk>
no; we have to choose how to document the semantics of the std.fs functions
<andrewrk>
specifically with respect to how symlinks work
<andrewrk>
ok here's my proposal for right now:
<andrewrk>
1. document the functions to have the different symlink behavior on Windows (the fact that the "." and ".." are resolved with string manipulation)
<andrewrk>
2. we'll come back to this decision during the Great Standard Library Audit that is coming sometime in the future
<marler8997>
that sounds reasonable
<andrewrk>
in this case I think the only blocker on the PR is to investigate whether the logic is duplicated with std.fs.path.resolveWindows
<andrewrk>
oh, that one takes an Allocator tho, hmm
<andrewrk>
ok nvm I think the ball is in my court. thanks for the discussion
<andrewrk>
thanks btw, this issue has been a thorn in our side for some time now
<marler8997>
yeah thanks for looking into this, there are some subtleties here that are not very straightforward
selby has joined #zig
dkibi has joined #zig
<dkibi>
does thischannel accept learner questions?
nvmd has joined #zig
wootehfoot has quit [Quit: Leaving]
cole-h has joined #zig
<justin_smith>
dkibi: yes it does
selby has quit [Read error: Connection reset by peer]
<dkibi>
I just wondered why I can write var foo = .{3,4}; but not var bar = 3;
Akuli has quit [Quit: Leaving]
<marler8997>
var bar = 3; is nonsensical. var foo = .{3,4}; probably works because it's s tuple which CAN hold runtime values even though it actually doesn't. We could modify the lanaguge to make a tuple with no runtime values an error when assigned to a runtime variable.
wootehfoot has joined #zig
Bekwnn has joined #zig
<Bekwnn>
hey, just wanted to drop by and ask if anyone's had luck using stb_image with zig, I'm hitting what looks suspiciously like a translate-c error on a 7.0+xxxx build of zig
<Bekwnn>
just if anyone has a repo with it on github or anything like that I could use as reference
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
jonase has joined #zig
nycex has quit [Quit: Quit]
nycex has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
jonase has quit [Ping timeout: 240 seconds]
Cadey has quit [Quit: WeeChat 3.0]
<CommunistWolf>
thanks for the aarch64 binaries :D
wootehfoot has quit [Read error: Connection reset by peer]
olabaz has joined #zig
<Bekwnn>
ah well opened an issue. Looks like that header really trips up translate-c