<mikdusan>
andrewrk: re memory error detector: 770631cc79a655bc5e21184ca15bdb6192e905de seems ok as I'm able to reproduce ir.cpp:14552 issue both with and without the meat of that commit
recombinant has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
<andrewrk>
that's good to know
hessammehr has quit [Ping timeout: 240 seconds]
r4pr0n has quit [Quit: r4pr0n]
ur5us has joined #zig
recombinant has quit [Quit: Leaving]
<andrewrk>
squeek502, fae6cf09619e7a8e64f61b84cca7d9fcd471262f should fix the issue you were having with zig cc. thanks for the report!
<squeek502>
nice, thanks for the quick fix!
<andrewrk>
mikdusan, valgrind clean (except for one known thing in llvm) after this: https://clbin.com/j5J60
<andrewrk>
the way bound functions work needs to be reworked anyway. ZigValue should not have any references to ir instructions like that
<andrewrk>
I don't know why I have to keep learning this same lesson the hard way so many times. test with valgrind!!
<mikdusan>
ah nice
<andrewrk>
it solved the drone ci issue too. big thanks to TheLemonMan for noticing the valgrind warnings
<andrewrk>
also just to be clear I'm pretty sure this was my fault :)
<mikdusan>
word is that zig is also your fault so ... you're forgiven :)
<mikdusan>
soon we're going to need a valgrind and benchmark CI of some sort
<andrewrk>
that's a really good point
<fengb>
Should there be CI based valgrind tests?
<andrewrk>
yes absolutely
<mikdusan>
it doesn't really need the high frequency but it'll be a good canary
<andrewrk>
yep
<Snektron>
<mikdusan "soon we're going to need a valgr"> Why not include that in the normal CI?
<andrewrk>
you know what's nice? not having ASLR
<mikdusan>
Snektron: performance
<andrewrk>
that's why the issue was repeatable
<andrewrk>
it makes sense that the same thing that can make software more difficult to exploit, also makes it more difficult to debug
<Snektron>
If its just leak checking, you might get away with custom functionality that has less performance overhead
<andrewrk>
we could run a job that only does a few tests with valgrind, not everything, and it'll finish before everything else so we can still use it to block the build if it fails
<mikdusan>
if (I_DUNNO) valgrind;
<andrewrk>
I really want to get a basic version of self-hosted going so that people can start contributing to it, but I need to focus on bugs & polish for the release
<Snektron>
<mikdusan "Snektron: performance"> My reasoning was that you'd wanna valgrind for every target anyway
dwdv has quit [Ping timeout: 265 seconds]
<mikdusan>
Snektron: I'm on board with as CI as practical
<mikdusan>
*as much
return0e has joined #zig
return0e_ has quit [Ping timeout: 264 seconds]
dermetfan has quit [Ping timeout: 246 seconds]
<andrewrk>
hmm lots more valgrind errors on the aarch64 build
<mikdusan>
andrewrk: how much RAM does that VM have?
<andrewrk>
I reproduced this on a machine with 128 GiB
<andrewrk>
it's some kind of corruption, def not running out
<mikdusan>
did you notice the break segment overflow error?
<mikdusan>
`brk segment overflow error`
<andrewrk>
yeah. I think valgrind is getting confused that libc is statically linked in this case
<mikdusan>
ok I just hope you're not seeing a bunch of errors as a side-effect of valgrind getting confused
marijnfs has joined #zig
<andrewrk>
the next thing I'm trying is using alpine:3.11 as a base image rather than alpine:edge
<andrewrk>
it will take several hours to complete this test
<mikdusan>
just to rule it out: have we confirmed shell `ulimit` sizes are not clamped down?
marijnfs_ has quit [Ping timeout: 264 seconds]
adamkowalski has quit [Quit: Lost terminal]
nephele has quit [Ping timeout: 246 seconds]
kevsmith has quit [Ping timeout: 240 seconds]
nephele_ has joined #zig
<andrewrk>
I'll check
kevsmith has joined #zig
<afontain_>
Hi, did someone try to compile a GTK program with `zig cc` already?
<andrewrk>
not that i'm aware of
<afontain_>
it works on native, but not with --target=x86_64-windows-gnu
<afontain_>
if I make binfmt work, I could see if --target=aarch64-linux-gnu and friends work
<afontain_>
it seems to fail badly because of several things. One is that long long int is 4 bytes instead of 8.
<andrewrk>
you think clang is giving long long int the wrong number of bytes for this target?
<afontain_>
I've got hope that it would be possible. If I've understood correctly, zig bundles a patched version of the glibc. Maybe I could find a way to use that one instead of the system ones
<afontain_>
*one
<afontain_>
*header files
<afontain_>
I'd say it's more likely that glibc expects the Linux standard sizes
<andrewrk>
there's no glibc in x86_64-windows-gnu, it's mingw-w64
<andrewrk>
if you want to cross compile a gtk app you first will have to cross compile gtk
<andrewrk>
I'm guessing this use case will be better off with a full cross compilation environment, at least until zig package manager can make these kind of dependency chains easier
<afontain_>
well, G_OS_WIN32 is not defined
<afontain_>
that's probably a good sign that it's the system headers' fault
<andrewrk>
are you sure you have managed to successfully override the compiler?
<afontain_>
well, I had to setup wine binfmt so that meson could accept to compile
<afontain_>
it would not compile anything with a compiler that build executables that "do not run"
<afontain_>
also, 4 bytes long long int is something windows has and linux doesn't have
<afontain_>
also, the default result of the compilation is "it works"
<andrewrk>
I mean this in a genuinely curious way- what's the point of using zig cc if you already have to do all this work? it sounds like you may be better off with a full cross compilation environment
<squeek502>
andrewrk, do you happen to remember the fix/workaround for Illegal instruction when compiling LuaJIT?
<andrewrk>
squeek502, hmm. I wonder why I didn't get the illegal instruction when I did it for the blog post
<mikdusan>
built on one host then executed on another?
<afontain_>
well, it's something I spent less than one hour on
<squeek502>
im running into Illegal instruction while trying to build LuaJIT via a custom cmake script and zig cc
<afontain_>
(worked for luajit in an example he gave)
<andrewrk>
afontain_, the build system should have a setting for "host compiler" and "target compiler". you would set the "host compiler" to simply "zig cc" and the "target compiler" to the one with the -target parameter
<squeek502>
i'll try the default luajit makefile to see if it happens there too
<afontain_>
I guess it works better for pure C with no dependencies
<andrewrk>
zig package manager will make it work for more complicated projects. but right now- yes it is somewhat limited in the dependency tree complexity
<andrewrk>
mikdusan, `ulimit -m` is `unlimited`
<squeek502>
andrewrk, nevermind, false alarm on the illegal instruction, i was failing to pass zig cc as the compiler
<afontain_>
well, the usual way to do cross-compilation with meson is to use mingw, but that's not packaged into Alpine
<afontain_>
I'm not sure I've got enough faith to package that, figure out how to cross compile with meson (yay lack of documentation) to discover I've got no idea how to handle shared libs on Windows
<afontain_>
yeah, well, another day maybe
knebulae has quit [Quit: Leaving]
<andrewrk>
yeah, I love the enthusiasm. it'll be worth trying this use case again later
<marijnfs_>
yeah that's what I was doing, but you will need an allocator for these types so I made another DeserializeAllocate
<marijnfs_>
but it looks ugly
<marijnfs_>
the code is only different in the .struct => part
<marijnfs_>
i think it's better if i put this code in a deserialize_allocate.zig file and call everything that way
dermetfan has joined #zig
slowtyper has joined #zig
kenaryn has left #zig ["WeeChat 2.3"]
ifreund has joined #zig
<jaredmm>
Having trouble binding a value in ASM. `"movq %%gs:%[offset], %[ret]" : [ret] "=r" (->u64) : [offset] "ir" (offset)`. What's the proper way to accomplish using a variable input as the offset value?
marijnfs1 has joined #zig
marijnfs_ has quit [Ping timeout: 260 seconds]
r4pr0n has joined #zig
<r4pr0n>
why doesnt zig inline a function that is called only once and is being inlined when i make it a inline fn?
<r4pr0n>
for context: it's std.fs.File.write
<r4pr0n>
and release-mode is small
r4pr0n has quit [Remote host closed the connection]
rappet has quit [Ping timeout: 246 seconds]
rappet has joined #zig
r4pr0n has joined #zig
TheLemonMan has joined #zig
<TheLemonMan>
r4pr0n, LLVM decided that it's not worth the code-size increase
<r4pr0n>
well it's actually a code-size decrease
<r4pr0n>
that's the thing
<TheLemonMan>
the inliner doesn't think so
<r4pr0n>
so it's a llvm bug
<r4pr0n>
?
<TheLemonMan>
the inlining decision is based on a few heuristic tecniques, sometimes it's not perfect
<r4pr0n>
but how could the code-size be even increased? i don't get how it comes to that conclusion
<r4pr0n>
it's just called once
<r4pr0n>
and the function also needs to be in the code
<TheLemonMan>
being called just once is not enough to mark that as inlineable
<r4pr0n>
why not?
<r4pr0n>
how could it even increase the size then?
<r4pr0n>
it's statically linked
<mq32>
r4pr0n: because when you inline a function, you lose the advantage of having your own stack segment
<mq32>
so inlining the function may explode the number of stack management instructions as registers aren't enough anymore
<r4pr0n>
oh that makes sense
<r4pr0n>
but still, the registers would be enough
<TheLemonMan>
just ask the inliner, none of us has a magic ball nor is an inliner by trade
<daurnimator>
TheLemonMan: you're probably my only hope for getting bit field support for extern structs into 0.6: any chance you feel like working on that?
<TheLemonMan>
eh, that's not under my radar atm :\
wootehfoot has quit [Ping timeout: 264 seconds]
ifreund has quit [Quit: WeeChat 2.7.1]
ifreund has joined #zig
<sammich>
Hey sorry, i have another casting question, I have a const void pointer, how would i make cast that into a zig array, currently i get a cast discards const qualifier error
<TheLemonMan>
do you need a non-const array?
<mq32>
@ptrCast(*const u32[8], your_ptr_here)
daex has quit [Ping timeout: 240 seconds]
<sammich>
I do not, I'll try this ^, thanks
daex has joined #zig
dddddd has joined #zig
<daurnimator>
TheLemonMan: aw :(
<fengb>
It’s `*const [32]u8`
<mq32>
fengb: 😱 i have used partially C syntax. I should go and shame myself
<eswtucka>
Hey I'm pretty new to zig, from what I understand is that zig ships with libc, but it tells me "Unable to link against libc: Unable to find libc installation: file not found"?
marijnfs_ has joined #zig
marijnfs1 has quit [Ping timeout: 264 seconds]
r4pr0n has quit [Ping timeout: 240 seconds]
jjido has quit [Quit: Connection closed for inactivity]
<Cadey>
eswtucka: how did you install zig?
<eswtucka>
scoop install ziglang
<eswtucka>
I change the target to x86_64-windows-gnu now it worked, I guess zig wants to use the native libc first
<forgot-password>
When I cross-compile for macOS from windows, how does the compiler handle frameworks? Would it be possible to track the required files in the VCS and refer the compiler to those?
<forgot-password>
And the other way around, of course ^^
<forgot-password>
Funny to see it creeping up the milestones, hehe
<andrewrk>
heh, yeah, schedule-based releases will do that :)
pixelherodev has joined #zig
<andrewrk>
TheLemonMan, here's valgrind output after my fixes from last night, inside the aarch64 docker image, but with musl dynamically linked so valgrind can have a better time
<andrewrk>
hopefully an assertions enabled build will catch something
<TheLemonMan>
yeah I was trying to get llvm to build
<TheLemonMan>
but llvm-config is being a massive cunt as usual
<TheLemonMan>
and the stack-trace tests are sooo brittle
forgot-password has quit [Quit: leaving]
<andrewrk>
yeah that's a bit annoying
junon has joined #zig
<junon>
I'm trying to wrap libuv as an exercise, trying to wrap my head around suspend/resume/async/await, getting an error `cannot resolve '@Frame(Loop.sleep)': function not fully analyzed yet`. Is there some trick to using @frame? code here: https://pastebin.com/KaFnMpE2 (line 138 is the function in question). `handle.data` is the C type `void*`, however that's expressed in Zig.
<andrewrk>
junon, can you show the full compile error output?
<TheLemonMan>
...the problem seems to be the qnan constants I've added to math.zig
<andrewrk>
wat
<junon>
andrewrk Docker does indeed use memory cgroups, yes. Dunno the context of your conversation, but there are a number of things you have to be aware of with docker: cgroups (kernel thing), as well as apparmor profiles.
<junon>
They affect the environment under which a program runs.
<andrewrk>
`cat /sys/fs/cgroup/memory/memory.limit_in_bytes` says 9223372036854771712 so I don't think that's the problem
dermetfan has quit [Ping timeout: 272 seconds]
<junon>
andrewrk: is there a good place I can read up on the conceptual end of suspend/resume/async/await?
dddddd has quit [Remote host closed the connection]
<andrewrk>
junon, I took a look at the code example, and here's the situation: `handle.data = @frame();` this is causing an implicit pointer cast to happen which is forcing the alignment of *@Frame(sleep) to be resolved, which is causing the compile error. There are two ways zig needs to be improved related to this:
<andrewrk>
(1) the compile error needs to communicate this better so that it is not necessary to step through the compiler in a debugger to find this out
<andrewrk>
(2) this kind of implicit pointer cast should not be forcing the alignment to be resolved. that will make the compile error go away
<andrewrk>
junon, there is not a comprehensive place I can link you to, but I can link you to several things that have related information
<andrewrk>
I'm long overdue for writing an async/await blog post
<andrewrk>
and docs
<junon>
Awesome, thanks. Does what I'm doing look "correct" to you, conceptually? From what I can gather, the async/await system is just stack frame storage/recovery, correct? It should be adaptable to any coroutine framework (in theory) if I understand it correctly.
<andrewrk>
that's right
<andrewrk>
let me look at the code more closely
<junon>
Okay. The part I'm unsure of is around the double frame creation - the real `main` is responsible for creating and ultimately running the main UV loop, so it creates the loop, then the `amain()` frame (which it never manually resumes, not sure how the `resume` stuff fits in), then runs the loop.
<junon>
also, the two lines for a single `await loop.sleep()` are a bit messy - is there a way to clean that up? I could just be mis-understanding it.
<andrewrk>
those two lines can be changed to `try loop.sleep(1000);`
<andrewrk>
no async/await needed there
<junon>
Oh neat, okay
<andrewrk>
where's the part where uv_timer calls you back and you do something with the handle?
<junon>
Haven't gotten that far yet, due to the @frame compilation error.
<andrewrk>
this looks like an easy fix (at least the (2) part, let me take a crack at it)
<junon>
Okay, sounds great :) Thanks
knebulae has quit [Quit: Leaving]
rzezeski has joined #zig
<andrewrk>
junon, if you have a source build of zig master branch you can pull and your code compiles nwo
<watzon>
andrewrk: does `zig cc` have a list of flags to ignore right now? I just ran into an error regarding `-fstack-clash-protection` because it's a default flag used by cc/gcc in redhat systems, but it's not supported by clang.
<junon>
andrewrk: I'll get on it, I don't have it set up yet but should be trivial. LLVM 10 right?
<watzon>
Yessir, newest zig build
<andrewrk>
yes, check the readme & wiki, they have updated instructions for every OS
<jaredmm>
Having trouble binding a value in ASM. `"movq %%gs:%[offset], %[ret]" : [ret] "=r" (->u64) : [offset] "ir" (offset)`. What's the proper way to accomplish using a variable input as the offset value?
<watzon>
Awesome work though, I've managed to use ti as a drop in for several builds so far
<junon>
I can easily build llvm10 by itself, that's already set up - I think I can just set the cmake module path to my llvm installation and then Zig's `find_package()` will pick it up. That'll save me a good hour or so.
<redj>
"<andrewrk> hmmmmmmmmmmmmm. libc++ is basically all stuff we already have in std, but in C++ instead of Zig. Is anyone thinking what I'm thinking?"
<redj>
andrewrk: what exactly are you thinking? ;-)
<andrewrk>
zig std lib powered libc++ of course
<andrewrk>
the libc++ we ship can just be a tiny C++ glue layer
<junon>
andrewrk: awesome, will test it out - thanks for the alignOf/alignCast example.
<andrewrk>
note also the [*c] pointer was not necessary
<andrewrk>
when you see [*c], think "the compiler does not know what kind of pointer that is, and will let me choose the correct one"
<junon>
ah okay, it was giving me a compilation error trying to coerce the function pointer type
<andrewrk>
you probably needed the `?`
<redj>
andrewrk: yeah I was thinking you would still need C++ layer for libc++
<andrewrk>
redj, right but, instead of shipping 40K new lines of c++ we could ship ~5K
<andrewrk>
and then the zig std lib would get more use too
<TheLemonMan>
so keep_bigger_alignment=false now allows to create misaligned pointers?
<redj>
right, pretty awesome
<andrewrk>
TheLemonMan, yeah, I was considering making that change anyway. it's pretty confusing that you can do @as(*align(1) u8, foo) and then get *align(2) u8 as a result
<andrewrk>
however @ptrCast will still keep the bigger alignment, in the same way that it refuses to change const
<andrewrk>
TheLemonMan, wait I think I did not understand your question. The point is that when you pointer cast, it will *respect the requested type* even when the alignment is lower
<TheLemonMan>
that's dangerous, I'd expect the compiler to catch that and scream
<andrewrk>
I think you misunderstand
<andrewrk>
the compiler was doing something questionable before
<andrewrk>
this situation is when the source type is *more* aligned than the dest type
<TheLemonMan>
oh, that makes sense
<TheLemonMan>
I think I found out why the aarch64 build crashes!
<junon>
andrewrk: not from what I can see - the compilation error I was getting was a function pointer type mismatch (the callback needed a [*c] pointer specifically, according to the error). Perhaps a better compilation error would have been that `?` needed to be added, which was not at all obvious from the error.
<andrewrk>
TheLemonMan, music to my ears
<andrewrk>
junon, did you get this? note: '[*c].cimport:5:11.struct_uv_timer_s' could have null values which are illegal in type '*.cimport:5:11.struct_uv_timer_s'
<r4pr0n>
i've seen the "var" type in many function signatures by now, but i can't find it in src-self-hosted/type.zig. what is it? is it just a hardcoded thing for to add in a function for a variadic function?
<fengb>
It’s “any type”
<andrewrk>
you know.. `anytype` would be a nice keyword for that
<fengb>
The compiler will check the actual usage so it’s like comptime duck typing
<junon>
`anytype` would be much more obvious than `var` imo.
<andrewrk>
if somebody proposes that I will accept it right now
<junon>
Sure.
<mq32>
junon: would you go for that? :D
<mq32>
you got my thumbsup
<mq32>
less double-use keywords!
<fengb>
Oh I can see why that’s super confusing
<fengb>
Should we split `const` as well? 🙃
<shakesoda>
i feel like "any" would be appropriate, too
<andrewrk>
junon, in your pastes you're using non-pointers
<junon>
you mean I use `cb_loop_sleep` as opposed to `&cb_loop_sleep`?
<andrewrk>
it says expected pointer, found not a pointer
<junon>
Oh for the handle.
<andrewrk>
TheLemonMan, I'm on the edge of my seat
<shakesoda>
this looks like a case the compiler could pretty easily make a suggestion for
<shakesoda>
sometimes i really could use those "did you mean?" suggestions, heh
<TheLemonMan>
andrewrk, just a sec, I may also have a patch
<shakesoda>
much easier to scan the output than for single character differences
<junon>
ah okay, andrewrk this brings me to my original error, which your code fixes: "type '?*.cimport:5:11.struct_uv_timer_s' does not support field access"
<junon>
that was the originally confusing part.
<shakesoda>
how are you using it? it's an optional, so you'll need to handle that
<shakesoda>
i.e. if (optional_thing) |value| { value.whatever = ...; }
<andrewrk>
junon, for what it's worth, the `.?` syntax is semantically identical to your `orelse unreachable`
<junon>
Ah okay
* shakesoda
forgot about .?
<junon>
but `orelse unreachable` isn't accepted semantically as proper null checking, though - that's the difference it seems.
<junon>
Okay great, now I'm to the alignment error, as expected.
<andrewrk>
it is
<andrewrk>
it desugars to the exact same thing
<junon>
`var frame = @ptrCast(*@Frame(Loop.sleep), handle.data orelse unreachable);` -> "<handle's type> does not support field access", whereas changing to the null-unwrap syntax does not error.
<junon>
but `.?` is good to know.
<junon>
(sorry for the incessant error messages here, I know I'm starting out with some lower-level stuff, hopefully it's not annoying)
<andrewrk>
btw mikdusan drone CI runs in a docker image, which you can inspect locally
<andrewrk>
oh but you'd need aarch64. send pubkey if you want access to that machine
r4pr0n has quit [Ping timeout: 240 seconds]
<mikdusan>
does drone run for PR or just master merges?
r4pr0n has joined #zig
<mikdusan>
ah just master merges
Akuli has joined #zig
<TheLemonMan>
andrewrk, long story short, the LLVM hashtable calls our __divtf3 that somehow fails spectacularly
<mikdusan>
but didn't you revert __divtf3 and still get issue?
<TheLemonMan>
the makefile needs some extra wiggling to rebuild all the pieces
<andrewrk>
mikdusan, I'll uncheck this box that says "Disable Forks"
<andrewrk>
done
<andrewrk>
TheLemonMan, hmm is it perhaps a bug in the divtf3 implementation? in theory it should just work
<TheLemonMan>
everything works fine if we force compiler_rt not to be compiled in release mode...
<andrewrk>
that's a great clue
<mikdusan>
andrewrk: no probs I was just going to force it to build 39589cffe0bfcfda8d4802cc14fc335f532a7a90 but that Lemon already found that a commit is culprit
<andrewrk>
junon, you're good. it's exciting that you're playing with libuv + async/await. I'd love for you to get to a point where it's a demo and can show it off outside the zig community :)
<junon>
That's the goal :)
<fengb>
I have nothing but dumb comments and nobody has kicked me out yet >_>
<mikdusan>
__yet__ :P
<mq32>
mikdusan: __yet__ is a reserved identifier!
<mikdusan>
mq32: I find myself almost agreeing :(
<mq32>
it could also be an IRC builtin
sammich_ has joined #zig
sammich_ has quit [Client Quit]
sammich_ has joined #zig
jjido has joined #zig
sammich_ has quit [Remote host closed the connection]
rappet has quit [Ping timeout: 272 seconds]
rappet has joined #zig
<marijnfs1>
anyone have issues with the deps/SoftFloat-3e/COPYING.txt file in git?
<marijnfs1>
it prevent me from rebasing because git wants to change the line endings i believe
<andrewrk>
marijnfs, you should configure git to not mangle source files on windows. some windows git installations incorrectly come with configuration to mangle source files
<marijnfs1>
andrewrk: ah, this is on linux though
<andrewrk>
not sure why you would get any problems with that file
<marijnfs1>
yeah its confusing, so for you its linux ending?
<fengb>
Was it checked in with \r somewhere?
<andrewrk>
it was copied verbatim from upstream
<marijnfs1>
I think i just need to build git myself, the version here is just old
<marijnfs1>
the file has dos endings though, but yeah that should be fine
<marijnfs1>
wait git is written in c right, should i try zig cc
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
<andrewrk>
worth a try
<marijnfs1>
well seems to work
<marijnfs1>
make CC='zig cc' CXX='zig cc' -j12 221.13s user 14.41s system 1009% cpu 23.339 total
<marijnfs1>
pretty fast too
<fengb>
It should be as fast as Clang right?
<mikdusan>
yup
<marijnfs1>
make CC='clang' CXX='clang++' -j12 209.47s user 11.62s system 1053% cpu 20.982 total
<marijnfs1>
yeah i guess, though the caching could be faster when developing
<r4pr0n>
why does the zig stdlib only allow handling ip addresses together with ports? it's e.g. kinda bad for the getAddressList, because i just want to get the address and no port
<andrewrk>
r4pr0n, all the std lib networking code is brand new, it probably just needs to get fleshed out more
<mq32>
junon, andrewrk: i wrote the anytype proposal before someone forgets it :D
<mikdusan>
marijnfs1: curious was your timed test `zig cc` with a Release build of zig?
<r4pr0n>
fengb: no, i don't even know who that is xD
<mikdusan>
marijnfs1: there's not much to be gained but I'm wondering if diff is visibile
<mikdusan>
btw if zig is being built for older OS versions, and we "released" zig with custom-rolled llvm-10 built against itself, then technically `zig cc` would have advantage of being clang compiler optimized with clang-10 vs. whatever system compiler provided llvm10
marijnfs1 has quit [Quit: Lost terminal]
marijnfs_ has joined #zig
mahmudov has quit [Remote host closed the connection]
<mikdusan>
andrewrk: do you recall if the drone docker image (Alpine Linux?) was modified sometime after `Tue Mar 24 11:51:13 2020 -0400` ? commit 39589cffe0bfcfda8d4802cc14fc335f532a7a90 passed drone build. and I just repeated the same commit with PR and it failed with bad std::alloc
mahmudov has joined #zig
<Cadey>
mikdusan: older OS versions?
<shakesoda>
it occurred to me that arraylist's addone api happily gives you null pointers for things that shouldn't be nullable
<shakesoda>
as a user you can avoid that if you already know, but that's certainly gonna bite someone
<andrewrk>
shakesoda, it doesn't give you null pointers, it gives you pointers to undefined memory. there's a big difference
<andrewrk>
that's the same thing Allocator.alloc() gives you
<Cadey>
does Allocator.alloc() calloc() or malloc()?
<shakesoda>
suppose that's true
<shakesoda>
I was just thinking that if I put in a *u8 or something in what i've got an array of, i've got bad data in there from how the addone api works
<shakesoda>
unless i go and make sure the only way it is ever used is as addOne().* = .{ stuff }
<mikdusan>
Cadey: more specifically older compilers. Let's say we build zig for netbsd. need llvm10. bootstrap llvm10 with gcc 7.4 or openbsd boostrap with clang 8.x; now the clang binaries in llvm10 are optimized at those compilers abilities. if we built llvm10 with clang-10 they'd have a slight advantage
<fengb>
r4pr0n: oops sorry, nvm >_>
marijnfs_ has quit [Quit: leaving]
recombinant has joined #zig
<Cadey>
mikdusan: ah for the bootstrap process, makes sense
<shakesoda>
which I can do, certainly, but this seems like not the best behavior when I think about it
marijnfs_ has joined #zig
<shakesoda>
oh - I see the real problem here. I didn't see that the append function exists.
<andrewrk>
Cadey, the std.heap.c_allocator implementation of Allocator exclusively calls `realloc`
<shakesoda>
that'll show me for reading the documentation
<junon>
Also, what is the naming convention used: I see three so far; CapitalCase for types, it seems (e.g. `FooBar`), camelCase for std methods (e.g. `getStdout()`) but then types have some snake-case identifiers (e.g. `@TypeOf(x).is_var_args`), not to mention `@TypeOf` kind of breaks this rule, too, since it itself is not a type but a builtin.
<fengb>
We could do away with concrete types altogether. Be an ML :P
<shakesoda>
junon: PascalCase is also used for things that *return* types
<junon>
Ah okay, clear
<fengb>
snake_case for fields
<fengb>
and variables
* shakesoda
is a rebel, and snake_cases the things standard library camelCases
<fengb>
I just arbitrarily case my vARiabLes
<junon>
Ah okay good to know
<junon>
Just making sure we weren't headed towards being PHP.
<junon>
:D
<mq32>
junon: @TypeOf(T) returns a Type, just like ArrayList(T)
<fengb>
std will be audited before 1.0 so any inconsistencies should be fixed before being stable
<fengb>
There's a styleguide change to make enums and unions also snake_cased... but I'm not sure I like that :P
<junon>
Whatever is decided is fine as long as it doesn't affect semantics, like Go or whatever languages treat `_` to mean private or something.
<mq32>
fengb: i'm a big fan of lower case enums :)
<junon>
that stuff drives me nuts, lol
<fengb>
Capital is public, lower is private. Obviously
<mq32>
junon: But `_` is special!
<mq32>
well, but only a single `_` as an identifier
<junon>
I meant `_` as a prefix (e.g. `_some_private_field_name`)
<fengb>
He means _ by itself, not as a prefix
<junon>
`_` by itself is just fine.
<junon>
Changing visibility or linkage should not penalize me by having to grep and hit 100 callsites D:
<shakesoda>
i've definitely used _whatever fields to indicate "probably don't mess with this"
<junon>
sure, though it doesn't change the meaning of it or change how you can interact with it, just by naming it with a `_` prefix.
<shakesoda>
yeah it's just a hint to the reader
<junon>
Purely cosmetic, as it should be. Convey intent however you'd like, but changing semantics based on the identifier's name is a super annoying thing in some languages.
<shakesoda>
for the most part I agree, although certain types of enforcement can be really useful
<junon>
I think Python's double underscore is the only really somewhat acceptable version of that, where prefixing with a __ in a class or module expands it to f"_{current_type_or_module_name}__{field_name}"
<shakesoda>
e.g. Haxe enforces first letter being capital on type names, because of the interaction with the module system
<junon>
Enforcement != semantic meaning.
<shakesoda>
this type of thing has no place in zig since it doesn't work fundamentally in a similar way though.
<shakesoda>
the only enforced meaning I want would be for lone _ = ignore
<shakesoda>
(as it does)
<junon>
Yeah, that's always been a 'want' of mine before Zig, too. Glad it's there.
<junon>
My knee-jerk reaction to having to use it with unused return values was a negative one, but then I realized the value it added pretty shortly thereafter. It does increase maintenance, though.
<shakesoda>
enforcing used or explicitly ignored returns is high value
<shakesoda>
although there's a proposal around for a "sloppy" mode that sounds like it'd relax that sort of check, which would be handy for hacking things together quickly
<junon>
It just means that all callsites have to be updated if the return value switches between void/non-void.
<shakesoda>
not behavior i'd want to have be normal
<shakesoda>
junon: as they need to be anyways in most all situations
<junon>
I wouldn't say so.
<shakesoda>
lest you code yourself in some new bugs
<shakesoda>
changing the return types is almost always done with reason, and ignoring returns can regularly be a really bad idea
<junon>
For example, my uv wrapper's `Loop.run` returns `!i32`, where the number of remaining handles (or 0 if none) denotes a successful exit; >0 indicates `uv_stop()` was called. >=0 are all successful returns in some use-cases of the library and can be safely ignored in a lot of cases.
<junon>
If I returned `!void` before but decided to return `!i32` to expose that to users, that means I'd break all existing users of the library.
<junon>
If `_ = try loop.run()` didn't need the `_ =` (as it seems to be enforced) then I could safely return `!i32` in a backwards-compatible manner.
<junon>
Thus, all previous `try loop.run()` could remain as-is.
<shakesoda>
maybe a good solution would be a way to specify "guaranteed safe to ignore" in the function signature
<shakesoda>
enforcing using them is sane behavior, though.
<junon>
well, I'd say all return values are safely ignorable, unless they're errors - which we already specify in the return types using `!`.
<shakesoda>
ignoring return values can very, very easily get you into hot water, and a lot of bugs in software are from exactly this
<shakesoda>
a trivial example here is something that returns memory to the user expecting it to be freed later
<shakesoda>
this is extremely common, a lot of memory leaks are caused in *exactly* this way
<fengb>
I've had more than a handful of bugs in Go because some functions just return an error
<junon>
Fair. Perhaps pointer return types cannot be ignored, but value return types can be.
<shakesoda>
the value types can very well contain pointers or other important information.
<shakesoda>
so again, that's not good enough
<shakesoda>
you'd really need the user to declare that it'd be safe
<junon>
integral/primitive values cannot unless you're doing pointer to integral conversion, which means you're already in "advanced"-land
<shakesoda>
those values can have any kind of important secondary meaning about them.
<junon>
I suppose.
<junon>
Integral handles I suppose, such as those returned by posix functions or e.g. most graphics libraries.
<shakesoda>
there are no situations I can come up with where the compiler can reliably determine, without the function declaring it, that nothing of meaning will come of ignoring a return
<shakesoda>
there are plenty of situations where you as the author can know this
<junon>
Sure, true.
<fengb>
andrewrk has a talk where he showed the perils of C file handling
<junon>
I don't need a talk to know the perils of C file handling.
<junon>
:D
<shakesoda>
fengb: is there anything about C file handling that *isn't* perilous?
<fengb>
Ignoring the return value was one of the bugs, along with using a null file instance
<junon>
I'd actually say c++'s file streams are worse.
<shakesoda>
nearly the entire c++ standard library is far beyond perilous
<fengb>
Lemme see if I can find it
<junon>
We wasted 4 hours on the classic windows textmode/line ending magic "feature" in our game engine over it.
<shakesoda>
but i won't give the perils of posix apis a free pass over it :D
<marijnfs_>
how do i run the tests for a specific file in the std lib
<shakesoda>
zig test file?
<fengb>
zig test [file] --override-lib-dir [stdlib]
<shakesoda>
junon: heh, ever run into the problem of files written out from powershell being utf-16, destroying everything by surprise?
FireFox317 has joined #zig
<shakesoda>
i think i saw an issue that was clearly caused by this on the zig tracker the other day
* shakesoda
grumbles about utf-16 being one of the worst things man has ever devised...
<junon>
No, my co-creator and I refuse to use powershell. Mingw shell for everything but building, and the Visual Studio build console for running `ninja`. :D
<junon>
So are byte order marks. Those things are annoying. UTF-8 is perfect as-is.
<shakesoda>
well, you'll avoid this particular pain in that case.
<shakesoda>
but if someone ever has a surprise utf-16 file, you know what to ask!
<marijnfs_>
fengb: --override-lib-dir sets the lib dir there? that would work indeed
slowtyper has quit [Ping timeout: 265 seconds]
<fengb>
Yeah, otherwise it uses your zig builtin library, which will get the test runner really confused
<shakesoda>
junon: utf-16 is just such a monumentally bad encoding :(
<junon>
Yes it is.
<shakesoda>
it has all the worst parts of utf-8 and utf-32 in one
<FireFox317>
andrewrk, i commented on my PR (windows async io). On linux opening a file can be async too? On windows, opening a file will alwasy be blocking, but then reading and writing from that file can be async (depending on a flag passed in when opening the file)
<shakesoda>
without the good parts of either
slowtyper has joined #zig
<andrewrk>
FireFox317, thanks for the info. 2 things - (1) the flag to force blocking is still relevant so that you can use `noasync` elsewhere in that stack trace dumping code right? and (2) std.fs has a cross platform abstraction, so if it can be async anywhere, then it is relevant for all OS's even ones that don't have async behavior there
<TheLemonMan>
well fuck this bug, I'm throwing in the towel
<andrewrk>
tag me in
<andrewrk>
any clues?
<TheLemonMan>
I've checked the result returned by __divtf3 and it looks just fine
<junon>
What is the memory guarantees of a suspend block? If I store the address of a stack-local inside a suspend{}, will it still exist in memory somewhere if referenced outside the frame, before the frame is resumed?
* mikdusan
thinks it is environmental
<andrewrk>
I agree with mikdusan - something changed in the environment
<TheLemonMan>
the code then calls __letf3 and that looks ok too
<TheLemonMan>
adding warn()s solves the problem
<andrewrk>
wat
<junon>
btw andrewrk your fixes to master work (just got zig built). Thank you for that.
<TheLemonMan>
I think it's a problem with the optimizer and/or the ABI wrt return values
<andrewrk>
junon, all variables are guaranteed to at least live as long as the scope they are in
<TheLemonMan>
if you want to check yourself just attach gdb to zig and add a breakpoint on __divtf3
<andrewrk>
in async functions, just like normal functions, a local variable's lifetime ends when the function returns
<TheLemonMan>
the first and only call is in the C++ stdlib's hashtable implementation
<TheLemonMan>
and that's where shit hits the fan
<marijnfs_>
do arrays always have a comptime length?
<junon>
Does the lifetime of a suspend{} block end before the frame is actually suspended, or after?
<andrewrk>
marijnfs, yes array length is part of the type
<marijnfs_>
thnks
<andrewrk>
junon, the function is considered to be suspended at the start of the suspend block, and resuming picks up *after* the suspend block. if resuming happens in a different thread, you could have your suspend block code running in one thread, while the function is resumed in another
<andrewrk>
the reason suspend takes a block is precisely so that you have more control over this possible race
dddddd has joined #zig
<andrewrk>
TheLemonMan, thanks for giving it a shot. tbh I'm pretty intimidated to try to solve this given that you are throwing in the towel. wish me luck
<mikdusan>
ok I have to ask, is this correct for drone: -I/drone/src/deps/SoftFloat-3e/source/8086
<andrewrk>
junon, libuv is always single threaded right? I think you can compile your zig code with --single-threaded, then
<TheLemonMan>
the trick is to check out the results of the code following __divtf3 with and without the optimizations enabled for compiler-rt
<andrewrk>
ok
<TheLemonMan>
and then check if there's any difference
<junon>
Ahhh I see, okay. And no andrewrk, not always. libuv supports (and even has an API for) multiple threads. It's most commonly used as a single threaded framework, though.
<FireFox317>
andrewrk, ah thanks, i get it :) now i have one more question. how do i get access to this `async_block_allowed` flag inside `windows.ReadFile`? It is not accessible anymore in `os.zig`. Because in `windows.ReadFile` i have to actually choose whether to suspend or not. Should this somehow be accessible from the handle?
jjido has joined #zig
<andrewrk>
std.fs code has access to this flag when it calls windows.ReadFile
<andrewrk>
so you should add a new parameter
<andrewrk>
os.zig can make an assumption based on std.io.mode, but std.fs has access to more information
<andrewrk>
mikdusan, hmmmm you may be onto something there
<mikdusan>
it's hardcoded in CMakeLists.txt
<andrewrk>
one of the folders in SoftFloat-3e is ARM-VFPv2-defaultNaN/ and another is ARM-VFPv2/
<TheLemonMan>
another check would be to apply the __divtf3 patch on the latest good LLVM9-based version
<andrewrk>
yeah
<andrewrk>
mikdusan, we also hard code 8086 .c files
<andrewrk>
I really think you might have found the problem mikdusan
<mikdusan>
with this bug I'm not betting until I see green-checkmark :)
<FireFox317>
the actually read and writes dont go through std.fs, read and writes are called on a `std.fs.File` and just calls the `os.read/write`.
<andrewrk>
FireFox317, do you see the part where it does ` if (need_async_thread and self.io_mode == .blocking and !self.async_block_allowed)`
decentpenguin has quit [Quit: decentpenguin]
<andrewrk>
here it can bypass std.os if necessary
<andrewrk>
mikdusan, how on earth did you think to look there?
<andrewrk>
TheLemonMan, do you know if we should be using ARM-VFPv2 or ARM-VFPv2-defaultNaN for aarch64?
<mikdusan>
I've been hacking at the linux_script. adding probes into env. then it dawned on me. why the fuck can't I see compiler args? so -DCMAKE_VERBOSE_MAKEFILE=1 to the rescue
<mikdusan>
*donned ?
<andrewrk>
I think it's dawn, like the sun coming up as a big idea over your head
<andrewrk>
or maybe you are donning an idea hat
* mikdusan
dons dunce cap
<junon>
Oh woah andrewrk I changed the `init()` to the pointer signature as you mentioned and the segfault was resolved, though I don't understand why.
<andrewrk>
junon, when you did `return res` it was copying the struct
<andrewrk>
and I guess libuv had were pointers in there pointing to fields
<junon>
Derp, okay, there's no magical move stuff. Idk why I expected Zig to do any of that.
<junon>
Makes sense.
<andrewrk>
argh why doesn't cmake let me if() on architecture
<junon>
specifically x86 vs x86_64, or between all architectures (e.g. mips, etc.)?
<FireFox317>
andrewrk, yes i see that. but how can i bypass std.os there then? Directly calling windows.readFile? instead of going through the os layer? I just dont see it for some reason
<andrewrk>
FireFox317, yes you could directly call windows.readFile
<andrewrk>
windows.ReadFileW does not have to match the dll function, and we can rename it if it starts diverging too much
<FireFox317>
andrewrk, hmm okay. I thought I had to go through the os layer
ur5us has joined #zig
<andrewrk>
FireFox317, hmm maybe it would help if I told you that it's possible that std.os will get renamed to std.posix
<FireFox317>
andrewrk, oh yeah then everything makes sense lol
<FireFox317>
thanks for the heads up :)
<andrewrk>
mikdusan, still bad_alloc() thrown
<andrewrk>
ok but that is still an important fix to make
dermetfan has joined #zig
<afontain_>
do someone know of a container with a checked max-size? Something like a [10]T, but where I could have less than 10 elements
<afontain_>
I could use an ArrayList and add checks on top of that if it doesn't exist
<marijnfs_>
how do I get an outstream with a growing buffer? a fixedbufferstream i assume doesn't grow?
<fengb>
You can get a stream from an ArrayList(u8)
<marijnfs_>
ah thanks
<marijnfs_>
also from a std.Buffer? which is preferred?
<andrewrk>
mikdusan, TheLemonMan: I think I have at least a reasonable workaround, which is to disable --bundle-compiler-rt for the drone builds (turning this into an open arm64 issue, rather than broken master builds)
<fengb>
Buffer is zero-terminated, so prefer ArrayList if you don't need that termination
<marijnfs_>
i still can't run a test on one file, zig test ~/software/zig/lib/std/io/serialization_allocate.zig --override-lib-dir ~/software/zig/lib
<marijnfs_>
that gives me use of undeclared identifier 'expect'
<TheLemonMan>
andrewrk, neither of them, those are for "classic" ARM
<TheLemonMan>
yeah whatever workaround is better than having that red cross pop up on every build
adamkowalski has quit [Ping timeout: 256 seconds]
<mikdusan>
andrewrk: what's the skinny on login access to drone? pubkey/account-name, and then I get a shell into what image?
_whitelogger has joined #zig
r4pr0n has quit [Quit: r4pr0n]
_whitelogger has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined #zig
r4pr0n has joined #zig
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<junon>
Why does e.g. the page_allocator have `fn create(comptime T: type) !*T` but not `fn free(p: *var) void` or something of the like?
<junon>
As-is, it returns a value that is not directly compatible with the corresponding `free()` function.
<fengb>
allocator.destroy
<junon>
Derp, thanks.
RoguePointer has joined #zig
FireFox317 has quit [Ping timeout: 260 seconds]
adamkowalski has joined #zig
ky0ko_ has joined #zig
adamkowalski has quit [Ping timeout: 264 seconds]
Akuli has quit [Quit: Leaving]
jjido has joined #zig
gpanders has joined #zig
slowtyper has quit [Quit: WeeChat 2.7.1]
donaldallen has joined #zig
frmdstryr has joined #zig
<donaldallen>
Back for another look at zig after a few months away. Trying to build a fairly simple program that does some printf-y things, but with format. I am getting the following error:
<donaldallen>
no member called 'Error') @TypeOf(out_stream).Error!void { ^/usr/local/lib/zig/std/fmt.zig:319:28: note: called from here) @TypeOf(out_stream).Error!void { ^./composite_register.zig:86:19: note: called from here fmt.format(stdout, "{}" ++ sep ++ "{}" ++ sep ++ "{}\n",
<donaldallen>
^./composite_register.zig:26:20: note: called from herepub fn main() void {
<donaldallen>
Not sure how to get this thing to format (pun intended) correctly. Hope you can read what I just posted.
<donaldallen>
Trying to help make this mess readable. The error is occurring here:
<donaldallen>
Semantic Analysis [701/1185] /usr/local/lib/zig/std/fmt.zig:319:22: error: container 'std.fs.file.File' has no member called 'Error') @TypeOf(out_stream).Error!void {
<donaldallen>
One level up:
<donaldallen>
I give up. I'll submit a bug report.
donaldallen has quit [Remote host closed the connection]
<fengb>
Looks like you’re passing a file into format() instead of file.outStream()
wootehfoot has quit [Ping timeout: 264 seconds]
slowtyper has joined #zig
FireFox317 has joined #zig
<FireFox317>
andrewrk, I updated the windows async io PR :)
yawniek has joined #zig
dermetfan has quit [Ping timeout: 256 seconds]
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
dwdv has quit [Ping timeout: 265 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
dwdv has joined #zig
FireFox317 has quit [Ping timeout: 250 seconds]
dwdv has quit [Ping timeout: 256 seconds]
<andrewrk>
thanks!
dwdv has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marijnfs_>
i added a file to std lib, but the test isn't run
<marijnfs_>
where is this controlled?
<marijnfs_>
i run zig build test-std in the zig root dir