<marler8997>
5151 is still more meant to be exploratory/experimental
<marler8997>
I think we should probably decide on issue 4431 before we look at 5151
<marler8997>
but they're really separate things
<marler8997>
it's "related" in that it also deals with allocation
<marler8997>
I don't like that the change requires changes to every single allocator, I would prefer smaller changes but I wasn't sure how to break it up
<andrewrk>
marler8997, ah yes. I'll take a look today and try to help make progress on it
<marler8997>
andrewrk: I'd like to make some progress on https://github.com/ziglang/zig/issues/4431 I've had this PR open for over a month: https://github.com/ziglang/zig/pull/5064 I'm not saying we should merge it but I'd like to work on this so if you have anything I can do to make progress, maybe implement a different solution/idea then let me know
<marler8997>
I still don't understand though, I'm on linux, autocrlf is not enabled
<marler8997>
this is linux by the way
<marler8997>
it's not enabled on my machine anywhere
<marler8997>
I'm familair with autocrlf
<marler8997>
even deleting them and checking them out again, it still said they were modified
<marler8997>
git checkout, git reset, and git restore all didn't work
<ikskuh>
marler8997: read something about autocrlf ;)
<marler8997>
but how does that mess up git?
<marler8997>
what they heck was going on there?
<marler8997>
adding/committing worked
<marler8997>
I can't update to master because it says I need to handle those changes first :)
<marler8997>
git says they have changed, but whenever I revert the changes, they still say they have changed
<marler8997>
anyone else see some weird behavior with deps/SoftFloat-32/COPYING.txt and README.txt?
2020-05-31
<marler8997>
this change allows name lookups to work on windows now. Now my ziget tool works on windows
<marler8997>
in any case, we could integrate this now and remove it later once we get that API
<marler8997>
if we have a platform-independent api on top of it, then there's less reason to support it
<marler8997>
I think you could go either way
<marler8997>
I'm not sure whether or not we should support Windows via the posix interface when it doesn't conform completely to it
<marler8997>
daurnimator: ok
<daurnimator>
marler8997: I'm leaning towards yes; but that's not my decision to make.... I think you might need to wait for andrew?
<marler8997>
hello?
<marler8997>
again, I don't care, I just want it to work and I'm willing to do it, please just tell me what you want
<marler8997>
should I also just remove windows support in std.os (aka std.posix) altogether and just get started on std.net?
<marler8997>
so to be clear, I should remove the dummy flags I just added
<marler8997>
that's what I was asking you
<marler8997>
that issue never says we shouldn't support windows in std.posix when it can be supported
<marler8997>
You can support windows in both std.net, and you could also support it in std.posix
<marler8997>
but that's not what I'm asking about
<daurnimator>
marler8997: that's what the issue 5019 that I linked says
<marler8997>
should we support that for windows as well?
<marler8997>
the socket function only has the 3 parameters, and clients can pass SOCK_NOEXEC and SOCK_NONBLOCK to the socket type
<marler8997>
if we support windows in os.zig
<marler8997>
but the question was
<daurnimator>
marler8997: ah right. on other OSes AF_ should be an enum too; and then we would @enumToInt and bitwise OR it
<marler8997>
you pass the flags in another argument
<marler8997>
on windows, WSASocketW doesn't recognize the socket type as a set of flags, but an enum of individual values
<marler8997>
on posix, you can specify SOCK_CLOEXEC and SOCK_NONBLOCK along with the socket type (i.e. SOCK_STREAM and SOCK_DGRAM)
<marler8997>
and the other questions I asked?
<marler8997>
so please just tell me when you want
<daurnimator>
marler8997: I think we should end up with implementations in std/net.zig
<marler8997>
I don't care much, I just want something that works
<marler8997>
I think you can do it either way, or both if you want to
<marler8997>
abandon my change to add windows support in os.zig and start implementing the network api in net.zig?
<marler8997>
daurnimator: what do you think?
<marler8997>
oh, net.zig would be the common networking api
<marler8997>
so if we didn't support windows in os.zig (i.e. posix.zig), would you think we'd create a common networking api that works for both posix and windows?
<marler8997>
but we could take those flags in os.zig, and translate them to the analagous flags for windows
<marler8997>
that's why I'm asking
<marler8997>
they aren't
<marler8997>
even though those flags aren't supported on the socket type when you call WSASocket or windows' socket function directly
<marler8997>
but what I'm asking is, should we support the SOCK_NONBLOCK/SOCK_CLOEXEC socket type flags for windows in os.zig
<marler8997>
oh right, ioctlsocket instead of setsockopt
<marler8997>
and the socket_type on windows is an enum rather than a set of flags, but I'm guessing we want it to treat it as a flag set in os.zig
<marler8997>
looks like windows doesn't have a way to make a socket non-blocking in WSASocketW...so should we still handle that flag in os.zig by a subsequent call to setsockopt? So it's the same interface for posix/windows?
<marler8997>
or better yet, just create the allocator primitives such as @comptimeRealloc(..) and @comptimeShrink(...), then we can create an Allocator type that calls them, so then the details of mem.Allocator don't get into the language
<marler8997>
@ctAllocator() or something
<marler8997>
I wonder if we could make join work at compile-time by having some sort of comptime allocator?
<marler8997>
And the one in std.fs.path requires an allocator
<marler8997>
I wrote my own that puts "comptime" as a parameter modifier on the "paths" array, but that means it can't be used at runtime
<marler8997>
I'd like to be able to use std.fs.path.join to create a pathname that needs to be available at comptime
<marler8997>
ah yes, that works
<marler8997>
no, I'll check
<marler8997>
how would I convert an int to an enum, but detect if it is not a valid value of that enum and take a different codepath?
2020-05-29
<marler8997>
ah
<marler8997>
or libsystem.so
<marler8997>
osx system.dll though?
<marler8997>
I think I recall seeing a thread on rust complaining about the msvcrt dlls
<marler8997>
yeah I've found the same, I thought it was going to be some quick easy changes to get the libc route working but didn't turn out that way
<marler8997>
I don't use mingw so I don't care about it's support
<marler8997>
yeah, I'm switching to that
<marler8997>
I think I might abandon the windows libc support, go straight to the ws2_32 direct support
<marler8997>
goodness what a mess
<marler8997>
those really bad ones that you need to install separately, the versioned runtime packages, and then there's that unversioned one that can change!
<marler8997>
is it those msvc...dll s?
<marler8997>
I suppose it has to have a libc doesn' it
<marler8997>
what happens differently on windows when libc is enabled?
<marler8997>
what a minute what am I doing...windows doesn't even have libc
<marler8997>
the enum that will never be returned?
<marler8997>
what value do I set it to?
<andrewrk>
marler8997, the enum of the cross platform abstraction? yes the cross platform abstraction error set is a union of all possible errors on all platforms
<marler8997>
so I should just add it to the enum anyway, even if windows will never return it
<marler8997>
right, but the windows implementation doesn't return one of the error codes
<andrewrk>
marler8997, it's planned to rename std.os to std.posix
<marler8997>
net.zig is calling os.system.getaddrinfo...is that supposed to be an abstracted wrapper around the platform specific getaddrinfo?
<andrewrk>
marler8997, hmm I don't think I understand your question
<marler8997>
it's not abstracted
<marler8997>
I'm working on getaddrinfo
<andrewrk>
marler8997, and then if you know you are in a code path where some error codes do not apply, => unreachable
<andrewrk>
marler8997, the pattern we have for this in std is: functions that abstract across platforms have a union of error sets
<marler8997>
not sure what the clean/right solution is here
<marler8997>
and dns is switching on that value....is there a way to make switch cases platform specific?
<marler8997>
there's an error code ADDRFAMILY that is supported on non-windows platforms, but not on windows
<marler8997>
hey, working on getting DNS to work on windows
2020-05-28
<marler8997>
With optimizations, Alloc.c() should be binary identical to calling malloc/free directly
<marler8997>
yeah that would be great
<marler8997>
so far not alot of discussion though
<marler8997>
but I knew this would be a bigger project and warranted it's own repo while I work on it and people discuss it
<marler8997>
well no, I didn't mention it in the PR
<alexnask>
marler8997, Hi, is there any way you can make a separate repo for #5151 while it's under consideration for std? I would like to start writing some extra parts but I dont want to copy paste your whole code into another repo for obvious reasons :P
<marler8997>
looks like according to the spec, header order matters if the headers have the same name
<marler8997>
I just saw you said "header order matters"...I didn't know of any headers where order mattered, which ones matter?
<marler8997>
I don't need to store a name/value for any header that I don't know how to handle
<marler8997>
Each header I need is known at compile-time
<marler8997>
I don't need to dynamically allocate space for all the known headers
<marler8997>
I know all the headers I need at compile-time
<marler8997>
hmmm, seems unnecessary to create arrays for all the headers
<marler8997>
oh wait, std.http.headers? that's in std lib?
<marler8997>
but I didn't need to do it to get it working...so it's put off :)
<marler8997>
yeah
<daurnimator>
marler8997: you should be parsing into a std.http.headers object
<marler8997>
blueberrypie: thanks for the tip, will do
<blueberrypie>
marler8997 look at ZigGBA for an example of raw
<marler8997>
thanks for the direction, I'll see what I can find out
<daurnimator>
marler8997: there is a raw output; but only from build.zig. and it's *weird*
<marler8997>
does zig support changing the output format? i.e. elf/coff/raw?
2020-05-14
<marler8997>
last thing in my binary is std.target.Arch.isWasm
<marler8997>
gotcha
<marler8997>
what do you mean provide my own root?
<marler8997>
is there a way to disable zigs panic handler?
<marler8997>
yeah, and I remember it couldn't mov into the PC, so he had to run the entire program in a disabled mode to jump backwards...lol
<daurnimator>
marler8997: riscv32 is at least easily synthesizable
<marler8997>
lol, reminds me of a youtube video I saw a few years ago of a guy who implemented a full-compiler that only generated MOV instructions
<marler8997>
don't see subleq either
<marler8997>
don't see mano
<marler8997>
smallest instruction set
<marler8997>
what's the simplest cpu arch that zig can compile to?
2020-05-11
<marler8997>
is this a new pattern? an old pattern? when should tests be put in the source file or pulled out into another?
<marler8997>
Looking at lib/net.zig, I see that tests are pulled out into another file, net/test.zig
<samtebbs>
fengb. marler8997 I'm seeing that with StackIterator.next as well
<marler8997>
23 seconds to build zig now...so glad I got this new machine
<marler8997>
thanks fengb
<marler8997>
oh!!
<marler8997>
so given a *Address, how am I supposed to call bind without the length?
<marler8997>
I'm confused, I'm suddenly getting this error that Address.getOsSockLen is private, but I doin't see any recent changes around it ???
2020-05-10
<marler8997>
plumm: I listed the main components up above, if you want more detail let me know. Machine will run you about $1000 for the bare bones. I run headless as well so no GPU. About $500 for the CPU and $500 for the other parts.
<plumm>
marler8997 and what supercomputer did you just buy O_O
<oats>
marler8997: thanks!
<marler8997>
oats: there should be only 1 instance
<marler8997>
wilsonk: Yeah it was taking me several hours till I got my new machine. New machine has a Ryzen 9 3900x, RAM speed is 3200MHz, Storage is a 500GB nvme drive. LLVM build time: 6min 24s, Clang build time: 3min 45s, LLD build time: 27s. And all that is with "make -j24"
<wilsonk>
marler8997: sorry I didn't notice your next question. If your distro has something as new as llvm-7, or newer, then I wouldn't see a problem with just installing that and then building llvm/clang-10 from source. I recently built llvm-10 with clang-7 and it worked fine. Source builds can take a VERY long time (like several hours with a slow-ish quad core... and expect to use about 2GB ram per core!). I think it takes about 1.11 hours with m
<andrewrk>
marler8997, I used to use the nixos package for llvm and clang but lately I've been using a source build
<marler8997>
so I should start with clang from my package-manager?
<wilsonk>
marler8997: I always just build clang/llvm with the previous release (never had that fail), then rebuild it with itself afterwards again to take advantage of new optimizations. That way you also have the latest llvm to build zig. I was on gcc-5.4 until just recently because I pretty much use clang for everything at this point
<marler8997>
figured it out, need gcc 9.2 not 8.3
<marler8997>
having issues building zig on my new machine. Using NixOS, anyone know what toolchain I should use to build llvm/zig? I'm getting compile errors like strict-aliasing violations and unused variable errors
2020-05-04
<marler8997>
"Let's make a new language"...said no sane person ever
<marler8997>
It can also be quite frustrating as a maintainer to waste time reviewing/dealing with poor quality pull requests
<marler8997>
I find appreciation to be based on change quality. Does it explain what problem it's solving? Is it focused on a single issue? Has it been tested?
<marler8997>
which makes it clear why it makes no sense on sockets
<marler8997>
actually, offset is supposed to be from "start of file", so pread with a 0 offset would be different than a read
<marler8997>
yeah to be clear, I was wrong, you cannot call pread on a socket
<marler8997>
it specifically excludes pread from ETIMEDOUT and a few others
<marler8997>
k, well I'm off to bed, will have to come back to this tomorrow
<mikdusan>
marler8997: building now
<marler8997>
build/test finished, appears to be working
<marler8997>
looking at a diff of a diff file is pretty weird by the way
<marler8997>
kinda cool
<marler8997>
oh weird, I manually edited the diff file with emacs and it automatically modified the line counts for me
<marler8997>
ah
<marler8997>
I just upgraded my old linux PC from 4 to 8...building LLVM/Clang/ZIG with only 4 GB is not fun
<marler8997>
32 GB
<marler8997>
spent $435 on the CPU, and around $400 for the rest (memory, motherboard, SSD, power supply), but it's completely headless, no gpu, just raw cpu power to build things :)
<marler8997>
yeah I've been overdue for a new linux PC, took forever to find a good motherboard for it though
<marler8997>
Ordered the new ryzen 3900x pc though :)
<marler8997>
probably take another 20 to 30 minutes to build/test
<marler8997>
yeah building it now
<mikdusan>
marler8997: makes sense; can you make a PR to qemu-static
<marler8997>
It is calling memory_reserve, on the memory that was just freed
<marler8997>
ok I've replied on #5245, I think I understand what's going on now. I think LemonBoy's original patch was correct. It was counterintuitive, which is probably why the bug happened in the first place
<marler8997>
that's what I suggested to LemonBoy but he said it wasn't necessary in the next comment
<mikdusan>
marler8997: see comment in #5245 . i think you need a conditional to handle both cases
<marler8997>
mikdusan: when will the new qemu be uploaded and available in the CI tester?
<marler8997>
context sounds good
<marler8997>
but this repo is for the docker
<marler8997>
so: docker/build/Dockerfile
<marler8997>
at my job we usually have a "docker" directory and I build the Dockerfile in a subdirectory called "build"
<marler8997>
not really
<mikdusan>
marler8997: are you seeing any consistent naming for the subdir to hand to docker build ?
<mikdusan>
marler8997: I think I'll experiment with pushing those dirs to a subdir. might as well.
<marler8997>
perfect
<mikdusan>
marler8997: yup I alway PR the qemu bumps to zig ci
<marler8997>
is there a way we could run zig's CI without first before we integrate it?
<mikdusan>
marler8997: 👍
<marler8997>
but I haven't done any substantial testing with my patch
<marler8997>
looks like it fixed my issue
<marler8997>
build finished, let me check it real quick
<mikdusan>
marler8997: did your build finish and patch does what is needed?
<marler8997>
any excuse to buy new shiny hardware right?
<marler8997>
ryzen 9 3900x?
<marler8997>
my qemu-static build been going for like 20 minutes and still no end in sight, might be time to upgrade my 10 year old linux box
<marler8997>
goodness the qemu-static build takes a while
<marler8997>
but I find nix does just as well :)
<marler8997>
we mount a host directoy and build directly in the host-mounted volume
<marler8997>
actually we do the same, we just use docker to create a stable dev environment
<marler8997>
the real reason is to prevent other people from accidently adding files to the docker build
<marler8997>
yeah, that's what I end up doing
<marler8997>
IMO you shouldn't have to rebuild all the things in your image just because you made a change in the middle. I understand why you have to, because linux packages can be installed anywhere, which is why a nix-container would solve that problem
<marler8997>
yeah, it doesn't bug me too much because I can't really get behind docker anyway. The "layer" approach doesn't seem right to me. I'd rather having something like Nix where you just pull in all the packages you need into your container, you could even share the memory with the host because they are all named from hashing their contents
<marler8997>
they are copied for the build, but not copied to the image unless you explicitly copy them
<marler8997>
true
<marler8997>
so typically I put the Dockerfile in a subdirectory, so I can limit what files it copies to the build image
<marler8997>
docker is weird, when you perform a build, it recursively copies all files and directories in the Dockerfile's containing directory to the virtual build image
<marler8997>
I don't think the docker build needs access to README.md and LICENSE for example right?
<marler8997>
you've given access to the entire repo to the docker build, was that on purpose?
<marler8997>
I've put together a patch for a qemu issue. I've built it and tried it out. Where can I find the configuration to build qemu for ziglang.org/deps/qemu...? And then how would I upload it?
2020-05-01
<marler8997_>
here's the linker output, looks like it can't find symbols that would probably come from LLVM: https://pastebin.com/ADsg4yz5
<marler8997_>
if I install "gcc_multi" on my nixos box then I can no longer build Zig, it fails with undefined symbols while "Linking CXX executable zig0". Does this sound like an issue or do you think there's nothing Zig can do?
<marler8997_>
how would you put a compile-time integer into a @compilerError message?
2020-04-25
<marler8997>
where does andrew livestream, twitch? and what's is username?
<marler8997>
found a cool way to initialize my new allocators, instead of makeSliceAllocator(makeAlignAllocator(makeLogAllocator(MmapAllocator { }))), you can do Alloc.mmap.log().align().slice().init
2020-04-23
<marler8997>
although, if you change the blockallocator interface, then you're still in the same boat....so maybe not a fair critique :)
<marler8997>
this means the standard library could change the runtime interface, and all BlockAllocators will continue to work, even application defined ones