<cepheus>
the only other uses i've seen for it is in code where you want to link against standard win32 system libraries without needing to manually add them to the linker command line
<cepheus>
oh i was scrolled up, heh
<cepheus>
but doing a bit of digging in the compiler code the lib name after extern seems to be a nilop unless the compiler is targeting windows, in which case it is added to the list of libraries to be linked and nothing else
<cepheus>
it doesn't seem to affect where symbol resolution is done or the calling convention of the function itself that i can see
leon-p has quit [Quit: leaving]
tnorth has quit [Ping timeout: 245 seconds]
gazler_ has joined #zig
gazler__ has quit [Ping timeout: 265 seconds]
jjido has quit [Quit: Connection closed for inactivity]
artem1 has quit [Ping timeout: 258 seconds]
artem1 has joined #zig
notzmv has quit [Ping timeout: 260 seconds]
aerona has joined #zig
artem1 has quit [Ping timeout: 258 seconds]
artem1 has joined #zig
daex has quit [Ping timeout: 240 seconds]
lanodan has quit [Ping timeout: 250 seconds]
daex has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
daex has quit [Ping timeout: 246 seconds]
brzg has joined #zig
notzmv has joined #zig
artem1 has quit [Ping timeout: 246 seconds]
qbit has quit [Quit: leaving]
brzg has quit [Quit: leaving]
wilsonk has quit [Quit: Leaving]
daex has joined #zig
artem1 has joined #zig
artem1 has quit [Ping timeout: 258 seconds]
notzmv has quit [Ping timeout: 240 seconds]
<mikdusan>
do we have any policy/guidance for tests that hardcode timing assumptions? There is an io_uring test that fails for me running in a vm because too slow; it has a tolerance margin of 5ms:
<spacelove>
So the basic idea behind this program (and this is a scratch version right now) is to find the set of all possible shortest-chains between words and then find the longest-shortest-chain
<spacelove>
That's not important though
<spacelove>
But I just wanted you to be able to feel part of history
<spacelove>
word_chains.zig is pretty well written, but longest_word_chain.zig I started like 1hr ago so it's not like super optimal... just a WIP
yyp has quit [Remote host closed the connection]
<spacelove>
so don't judge me
<spacelove>
So far the longest path I found was: i
<spacelove>
in
<spacelove>
fin
<spacelove>
fine
<spacelove>
finer
<spacelove>
finder
<spacelove>
fender
<spacelove>
render
<spacelove>
renter
<spacelove>
rented
<spacelove>
dented
<spacelove>
denied
<spacelove>
defied
<spacelove>
defined
<spacelove>
define
<spacelove>
refine
<spacelove>
And to not spam, that'll be the last one I post
<spacelove>
longest-shortest-path*
<spacelove>
But I think my prog might be leaking memory and I don't want to melt my RAM disk
<spacelove>
;-)
yyp has joined #zig
<spacelove>
andrewrk checking out valgrind now
<andrewrk>
spacelove, plz avoid pasting more than 2 lines
<spacelove>
kk
<andrewrk>
pretty sweet though, seems like a fun problem
yyp has quit [Quit: now it's safe to turn off your computer]
<spacelove>
generates a lot of amusement on a per-bit basis
yyp has joined #zig
aerona has joined #zig
yyp has quit [Client Quit]
yyp has joined #zig
<cepheus>
spacelove: i found the issue, if you want me to point it out
<spacelove>
Not necessarily, I mean, you can give me a hint
yyp has quit [Client Quit]
<cepheus>
look carefully at where you've initialised heap allocated storage
yyp has joined #zig
<cepheus>
the other hint is: look carefully at the line numbers mentioned in your code when you do bt in gdb
<cepheus>
it (unsurprisingly) gives you a good idea where the actual issue could be (typically at or before one of the mentioned lines)
<spacelove>
You are a genius. I don't see the error yet but.... maybe I have an idea
<spacelove>
I thought it might be in BufSet... but didn't manage to find the erro. But let's see if I can grind it down
<cepheus>
it's definitely a mistake I've made before and I'm sure many others have too
<spacelove>
Seems like the issue is BufSet is trying to reach a key that isn't there... or something. Is that what you're seeing?
artem1 has joined #zig
<cepheus>
yes, but there's a very good reason why that is
<spacelove>
lmao
<cepheus>
read where the bufset is init'ed carefully :)
<spacelove>
dude that was a type smdh
<spacelove>
typo
<andrewrk>
marler8997, I'm around if you wanna chat about '..' on windows
<andrewrk>
finally took the time to dig in to your PR, sorry for the wait
<spacelove>
dude :-( forgot defer
<spacelove>
lmao
<spacelove>
you are a genius
<marler8997>
sure
<spacelove>
I had that in word_chains... idk how it slipped out
<spacelove>
anyway. you have taught me a valuable lesson. type "bt" in gdb
<spacelove>
that changed my life
<andrewrk>
windows has the worst possible symlink situation... they exist, so you have to account for them. but they only work if the proc has admin privileges, so you can't rely on using them
<g-w1>
can you read them if you are not admin?
<andrewrk>
yeah just can't make them
fputs has quit [Ping timeout: 246 seconds]
fputs has joined #zig
<marler8997>
andrewrk correct, avoid symlinks on windows :)
<andrewrk>
are you suggesting to pretend they do not exist though?
<marler8997>
I would suggest not relying on them
<marler8997>
for functionality
<marler8997>
you have to account for the fact that they might work in some situations
<andrewrk>
yeah I agree. so unfortunately that means we can't utilize them in the cache system (I tried and found out the hard way about admin mode) but we do have to account for them with std.fs functions to open a file or dir
<andrewrk>
(with respect to '..')
<marler8997>
right
<marler8997>
andrew
<marler8997>
on windows, paths are resolved before symlinks
<marler8997>
maybe you forgot :)
<andrewrk>
oh really! so that's how .. is expected to work on windows?
<marler8997>
yes
<marler8997>
I discovered this when I looked at the implementation in ReactOS
<marler8997>
and then confirmed it with some tests
<andrewrk>
brilliant, thank you for doing that research
<marler8997>
we had a whole discussion about this months ago :)
<marler8997>
I have an issue open about it as well
<andrewrk>
I'm sorry I do not remember it at all
<andrewrk>
hmmm. so the only reason to do the physical parent directory thing would be to define the std.fs APIs to have more consistent behavior across operating systems
<andrewrk>
however we could define '..' to work in an os-dependant manner and it would be completely fine
<marler8997>
if you change the behavior of symlinks on windows, then paths will get resolved differently when you pass paths to kernel32 functions
<andrewrk>
good point so we definitely want it to be os-dependant
<marler8997>
CreateFile will always resolve symlinks the windows way
<andrewrk>
this is great news for the simplicity of this implementation
<andrewrk>
ok I will merge this straight away then :)
<marler8997>
yeah, this last point is one I hadn't thought of the last time we discussed
<marler8997>
well hold on
<marler8997>
there's a problem in my PR
<marler8997>
it only works with absolute paths, I need to modify it to convert all relative paths to absolute paths before resolving ".."
<andrewrk>
can you also write in comments about these facts about symlinks on Windows? I imagine someone else will make the same mistake as me reading the code
<marler8997>
but I didn't want to work on it until we were on the same page
<marler8997>
yes I will definitely do that
<andrewrk>
what only works with absolute paths?
<marler8997>
I'll fix the absolute path issue, and document this behavior in the comments and then let you know when it's ready
<marler8997>
if you pass something like ..\a
<marler8997>
then the ".." has nothing to remove from the path
<marler8997>
a\..\b would become b
<marler8997>
..\a would just be an error (too many .. paths)
<andrewrk>
let's just leave those lines alone then, yeah? including the @panic("TODO")
<andrewrk>
is it safe to convert relative paths to absolute paths on windows? on posix it's not safe to do that
Akuli_ has joined #zig
<marler8997>
it's been a while, but that's what I remember the reactos implementation doing
<marler8997>
I can go back and confirm
<andrewrk>
because PATH_MAX is only the max for the number of bytes you can send in 1 syscall, but an actual fully resolved absolute path may be longer than that
Akuli has quit [Disconnected by services]
Akuli_ is now known as Akuli
<marler8997>
hmmm
<marler8997>
maybe NT_PATH_MAX is larger
<marler8997>
like 4096
<marler8997>
that seems familair
<marler8997>
still trying to refamiliarize myself with all this
bitmapper has joined #zig
<marler8997>
I have a branch in ReactOS where I pulled out all the path logic, let me go find that
<andrewrk>
my intuition tells me we would want to use NtQueryObject to resolve all the ".." for opening a file
<andrewrk>
I think that can be a separate PR if you want tho
<marler8997>
NtQueryObject?
<marler8997>
the function that all the kernel32 methods used required the heap, so my PR that used it was rejected by you because of that
<marler8997>
so I think the choice is either use this, or come up with a non-heap implementation
<marler8997>
the way I kinda look at it is windows is messed up in all sorts of ways
<marler8997>
trying to avoid using the heap kinda seems like we're trying to polish a turd :)
<andrewrk>
marler8997, ok. yeah. having broken down the pieces, it seems inevitable to rely on heap allocation for opening a file path. thanks for indulging me on this rabbit hole. I agree, we can't do better than RtlDosPathNameToNtPathName_U_WithStatus
yyp has quit [Quit: now it's safe to turn off your computer]
<marler8997>
I mean, maybe we can, but I don't see alot of benefit
<andrewrk>
maybe we can avoid it if the file path does not contain ".."
<marler8997>
I do see alot of work and potential maintenance for a small upside
<andrewrk>
yeah, agreed unfortunately
jokoon has quit [Quit: Leaving]
yyp has joined #zig
<marler8997>
should I resurrect the old PR and we go with that, at least for now?
<andrewrk>
how about this compromise: the documentation comment for open() will say, "if the path contains any '..' components, this function can fail with error.OutOfMemory"
<andrewrk>
I do like your second PR
<marler8997>
hmmm
<andrewrk>
I think the common case is no '..' components in relative paths
<marler8997>
ok, I'll look into this more and get back to you on the second PR then
LewisGaul has joined #zig
yyp has quit [Client Quit]
<LewisGaul>
Does anyone have any suggestions for achieving what I'm trying to do in https://zigbin.io/8d9d18 ? I think you might describe this as union polymorphism, possibly.. :)
yyp has joined #zig
yyp has quit [Client Quit]
yyp has joined #zig
<andrewrk>
LewisGaul, move other_field to be part of the tag. Baz_true, Baz_false. then use the same type for Bar, Baz_false, Baz_true, and you can capture the value like this: .Bar, .Baz_false, .Baz_true => |payload| print(payload.data)
<andrewrk>
as a bonus this will make your union @sizeOf() be 8 fewer bytes
<andrewrk>
(on 64 bit platforms)
<LewisGaul>
hmm yeah, this was a simplified version though, and that approach doesn't scale for more differences in fields?
<LewisGaul>
but useful to know of the general approach you'd take
<andrewrk>
pub fn getData(adt: MyADT) ?[]const u8 { // put the switch here and return data or null
<LewisGaul>
yeah that's what I was thinking of doing :)
<andrewrk>
if (adt.getData()) |data| print(data)
<marler8997>
wow no merge conflicts after 4 months
<andrewrk>
you're the only one who has touched windows paths in 4 months :)
<marler8997>
lol, everyone else gets to use linux :) No one wants to touch this turd
<LewisGaul>
I'm currently using WSL1 over Windows despite the zig build caching mechanism seeming to not work properly on the pseudo-linux filesystem aha
<g-w1>
what happens if you try to symlink on /mnt/c/whatever from wsl?
<marler8997>
wsl is linux
<marler8997>
well, wsl1 or 2?
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #zig
<g-w1>
yea, but windows doesn't allow symlinks, so what happens if you try to symlink on a windows fs from linux?
<marler8997>
with wsl1, if you made a symlink on an NTFS filesystem from WSL, then it created this weird file that windows didn't know what to do with
<LewisGaul>
generally linux symlinks seem to work ok under /mnt/c/ (that's where I store all my files), but obviously aren't understood in windows land
<g-w1>
ah, interesting
<marler8997>
I'm not familair with how the NTFS vfs driver works for WSL2
yyp has quit [Client Quit]
yyp has joined #zig
<marler8997>
but on linux, a symlink is just a normal file whose contents is the path to the target and has a special bit set in the mode
<marler8997>
but WSL1 didn't create symlinks that way, whatever it did the file was all messed up when you went back to windows
yyp has quit [Client Quit]
yyp has joined #zig
<andrewrk>
LewisGaul, what's the issue with the cache system on WSL?
<LewisGaul>
I haven't dug into it, but I noticed sometimes changes weren't being picked up. I first noticed it when working on zig fmt - when running the tests it wasn't picking up changes to the main zig code
yyp has quit [Client Quit]
yyp has joined #zig
<LewisGaul>
I could try to put together a minimal reproduction if there's interest, but I thought there probably isn't much given the assumption it's just WSL1
<andrewrk>
it should work fine on WSL
yyp has quit [Client Quit]
yyp has joined #zig
<ifreund>
andrewrk: I looked into this briefly and WSL1 still uses the windows filesystem
<ifreund>
so I'm guessing since zig thinks its running on linux some assumptions don't hold
<ifreund>
WSL2 uses ext4
<marler8997>
yeah that could definitely be the case
<andrewrk>
which assumptions would that be?
<marler8997>
it's been a while, but things like chmod may not work
<andrewrk>
caching system has no dependency on chmod
<LewisGaul>
ah that's definitely true, chmod does not work
<marler8997>
timestamps might behave differently too
<marler8997>
the chmod one caused us issues because we had a tool that was looking for the EXECUTABLE bit and windows just gives everything the executable bit
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #zig
yyp has quit [Client Quit]
yyp has joined #zig
Anzh has joined #zig
<Anzh>
Hello, IRC!
<ifreund>
o7
<g-w1>
hi
cole-h has quit [Ping timeout: 260 seconds]
spacelove has quit [Ping timeout: 240 seconds]
<txdv>
doesn't zig have world class support for windows? why wsl?
<marler8997>
are you suggesting zig shouldn't work in wsl?
<marler8997>
andrewrk, it looks like the reactos implementation only supports paths up to 260 chars :(
<marler8997>
looks like that was the limit for everything before Windows 10
<marler8997>
looks like the max path is 32767, we could allocate that on the stack couldn't we?
<marler8997>
andrewrk let me know how you want us to deal with potentially long paths where ".." goes past the current relative path name
<marler8997>
I have some ideas, let me know when you'd like to discuss
marijnfs has joined #zig
<andrewrk>
marler8997, yo I'm back
<andrewrk>
is 32767 the max *absolute* path?
<marijnfs>
that would be a pretty insane path
<andrewrk>
linux has no limit on absolute path length, only sub-components
<marijnfs>
In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters
<marijnfs>
it's insanely low, we have run into this issue at work many times
<marler8997>
well, it looks like that might be the maximum path if it isn't already an NT path
SimonNa has left #zig ["Leaving"]
<marler8997>
but I suppose with our own implementation we wouldn't be subject to that
<marler8997>
> The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.
<andrewrk>
seems like we can get away with no heap allocation then
<marler8997>
so, we create the path on the stack, then call the nt function with that stack memory reserved?
<LewisGaul>
I noticed std.json uses `StringHashMap` which I think is unordered, so does this mean there's no way to round-trip JSON with std.json?
<LewisGaul>
I noticed this when looking for an ordered hash map
<marler8997>
lol, I spent a bunch of time trying to get a round-trip json parser in Dlang :)
<marler8997>
I ended up having to implement my own parser rather than using the one in std
<LewisGaul>
I'm actually writing a parser for simplified yaml, and found I wanted the JSON to be ordered when writing tests with expected output!
sord937 has quit [Quit: sord937]
<marler8997>
yeah that's exactly what I needed it for in Dlang as well
<marler8997>
you might be able to leverage the parser logic in std.json and create your own object
<LewisGaul>
the actual requirement is just having an (insertion-)ordered hashmap right?
<marler8997>
yes
<g-w1>
i *think* std.ArrayHashMap is that? not sure though
<marler8997>
yes, ArrayHashMap is insertion order
<LewisGaul>
oh good point, although there's still the problem that it's not the one std.json uses aha
<andrewrk>
marler8997, yeah I like that strategy. we already have a dependency on allocating that size on the stack on windows
<marler8997>
ok
<g-w1>
LewisGaul: maybe you could switch it out and see how it performs. it seems like a symetric json would be nice for tests
<LewisGaul>
yeah, although technically json objects are unordered I think? But having the option to maintain order would be nice
<g-w1>
maybe just even a bool to swap out the impl in the config would be nice
<LewisGaul>
that's what I was thinking, possibly
<g-w1>
the magic of comptime :P 🧙
yyp has quit [Quit: now it's safe to turn off your computer]
yyp has joined #zig
yyp has quit [Client Quit]
yyp has joined #zig
yyp has quit [Client Quit]
yyp has joined #zig
Akuli has quit [Quit: Leaving]
yyp has quit [Quit: now it's safe to turn off your computer]
skuzzymiglet has joined #zig
<g-w1>
andrewrk: are you going to regress the new llvm pm based on performance?
<g-w1>
i saw that, but it was not clear to me, thanks
<andrewrk>
there's also the fact that it introduced regressions
<g-w1>
its so weird that it only segfaults on that one test that *I* added lol
<g-w1>
i think its just a weird stack-overflow
<g-w1>
but i feel a responsibility to test
<andrewrk>
I think the new optimizations failed to promote enough stack to registers
<g-w1>
so it overflowed?
<andrewrk>
that's my guess
<andrewrk>
I could test the hypothesis by building self-hosted with -Drelease and trying the test case again
<g-w1>
ok
<g-w1>
im debating if I should build llvm12 release overnight
<andrewrk>
seems like it's not an improvement if it takes 2x as long to produce a less optimized build
<g-w1>
yeah interesting
<g-w1>
also in relation to 363, musl has some TODOs. will those be a release blocker for 1.0?
<andrewrk>
yes
<andrewrk>
wait you mean in src/musl.zig or in lib/* ?
<g-w1>
lib/*
<andrewrk>
#363 only applies to lib/std/*
<g-w1>
ok, thanks
marijnfs has quit [Quit: WeeChat 2.8]
<LewisGaul>
g-w1 I've had a look at the ordered json hashmap - replacing StringHashMap with StringArrayHashMap does what I want, but perhaps undesirable due to performance. I can't see how you'd make it comptime configurable, as the `ObjectMap` is public at the class level, and similar for the `Value` union, i.e. not strictly tied to the `parse()` function
<andrewrk>
StringArrayHashMap is still really efficient
<andrewrk>
it's roughly the same impl as python3 dicts
<andrewrk>
I didn't read the context, not sure what you're trying to do. but if StringArrayHashMap is the right tool for the job, use it
<LewisGaul>
What are your thoughts on switching out StringHashMap with StringArrayHashMap in std.json? That's the context :)
<andrewrk>
ah I see. seems reasonable given that in fact json does communicate order, even if that's not how you're "supposed" to use it
<andrewrk>
I would be in favor
<LewisGaul>
My use-case is: I have a simplified yaml parser, and I want to make use of jsonStringify() in tests after converting to json structs for checking the output
<LewisGaul>
Well I can raise a PR with the 2-line change (plus tests I guess!) and maybe that can start discussion if nothing else
<andrewrk>
sounds good
<andrewrk>
will give the relevant parties a chance to object (I'm not the main maintainer of std.json)
<LewisGaul>
yep I can't claim to have much insight into this stuff so I'm keen to get the relevant input, happy to hear it could be acceptable anyway
<LewisGaul>
"./zig test ../lib/std/json/test.zig" is giving me "error: import of file outside package path: '../std.zig'", am I doing something wrong?
<andrewrk>
LewisGaul, --main-pkg-path ../lib/std
<LewisGaul>
thanks
<andrewrk>
you need that if you try to use `zig test` in a subdir that wants to import stuff with ..
<LewisGaul40>
`./zig build test-std` just gave me BSOD with KERNEL_SECURITY_CHECK_FAILURE xD let's just blame WSL again haha
artem1 has quit [Ping timeout: 250 seconds]
LewisGaul40 has quit [Quit: Connection closed]
LewisGaul has joined #zig
LewisGaul has quit [Ping timeout: 240 seconds]
artem1 has joined #zig
LewisGaul has joined #zig
<andrewrk>
ok yeah pretty sure that's not zig's fault :)
artem1 has quit [Ping timeout: 245 seconds]
<v0idify>
zig BSODd my PC therefore zig suckas
<g-w1>
were you running in admin or reg mode?
<g-w1>
ok didn't see context lol
LewisGaul has quit [Ping timeout: 240 seconds]
LewisGaul has joined #zig
<LewisGaul>
to be clear I wasn't blaming zig, but it's definitely caused by that command somehow (happened twice). Might have to start using a Linux VM or something
<mikdusan>
so uhm what is mem limit for a wsl process?
<LewisGaul>
I think it has access to all RAM, it's not a proper VM
<andrewrk>
LewisGaul, why not run the windows build of zig? it works great
<andrewrk>
zig supports windows
<LewisGaul>
yeh that's probably the next port of call tbh. Just familiar with the linux terminal, that's all
<andrewrk>
I like to use the msys terminal for that