ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<t5c>
andrewrk: its been a while, but zig is now running on openbsd-current on my machine
<t5c>
its a huge patchset and the tests are failing atm
<t5c>
but a simple hello world works
xtreak has joined #zig
JinShil has quit [Quit: Leaving]
abique has quit [Ping timeout: 256 seconds]
abique has joined #zig
davr0s has joined #zig
xtreak has quit [Remote host closed the connection]
xtreak has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
abique has quit [Quit: abique]
xtreak has quit [Ping timeout: 248 seconds]
xtreak has joined #zig
xtreak has quit []
davr0s has joined #zig
qazo has joined #zig
xtreak has joined #zig
xtreak has quit [Client Quit]
bheads__ has quit [Quit: Leaving]
bheads has joined #zig
<MajorLag2>
andrewrk, that reminds me, any idea how we can get some kind of allocator working at comptime? Right now I embed assets using a two-stage process to convert them from BMP to raw data and then insert that with @embedFile, but I could skip a step if I could use an allocator at comptime. Even if it is just FixedBufferAllocator.
qazo has quit [Ping timeout: 252 seconds]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
MajorLag2 has quit [Ping timeout: 265 seconds]
bheads_ has joined #zig
bheads has quit [Ping timeout: 256 seconds]
MajorLag1 has joined #zig
<andrewrk>
t5c, nice!
<andrewrk>
MajorLag1, what's stopping FixedBufferAllocator from working at comptime?
<andrewrk>
oh is it the alignment code?
<MajorLag1>
I don't recall, pointer casting? been a while since I tried.
<andrewrk>
I have an idea, let me try something
bheads__ has joined #zig
<MajorLag1>
so FBA specifically fails w/ @ptrToInt: `const addr = @ptrToInt(self.buffer.ptr) + self.end_index;` `error: cannot store runtime value in compile time variable`
bheads_ has quit [Ping timeout: 256 seconds]
<andrewrk>
yeah, I think it's the alignment code that chokes at comptime
<t5c>
andrewrk: right now I'm stuck at the assertion on line 423 in analyze.cpp. Can you tell me what it is about in general? or when it will trigger?
<t5c>
I don't really get when a type can become invalid...
<andrewrk>
t5c, sure thing. in addition, if you can trigger it with gdb I can show you what to do to map it back to soucre
<t5c>
i can run it with gdb --args $test here, no problem. any particular command that you recommend?
<andrewrk>
are you in an interactive shell where I can ask you to run commands? or would it take a long time to try stuff?
<t5c>
I got everythin on this machine where I'm typing from
<andrewrk>
go up one stack frame, now where are we?
<t5c>
from start: gdb --args bin/zig build --build-file ../build.zig test
<t5c>
right?
<andrewrk>
zig build is going to spawn zig in child processes, which might be the actual failure. if you run the command without gdb, after it asserts, it should print the command that it tried to run that ended up asserting
<andrewrk>
and that's what you would run gdb against
<t5c>
ok, running with that line
<t5c>
breakpoint at the function that will fail?
<andrewrk>
just let gdb hit the assert
<andrewrk>
then use `up` until you get to the assert, and then go up once more
<t5c>
ok,
<t5c>
ir.cpp line 18994
<andrewrk>
perfect, let me see...
<andrewrk>
I already think I know a fix, but let me show you something
<andrewrk>
(gdb) p instruction.base.source_node.owner.path[0]
<andrewrk>
(gdb) p instruction.base.source_node.line + 1
<andrewrk>
that will show you the file and line number that this was analyzing when it hit the assert
<t5c>
zig/src-self-hosted/main.zig line 549
<andrewrk>
t5c, let me give you a diff to try
<t5c>
it will call my openbsd functions, so the error could also be at my new code
<andrewrk>
I didn't succeed in coming up with a test case, but this should fix it
<andrewrk>
an example of a type being invalid, is if one of the fields failed semantic analysis
<andrewrk>
const S = struct {a: i32, b: noreturn}; // if you use S somewhere it'll probably be "invalid" at some point during analysis
<andrewrk>
in summary, after adding a compile error, zig didn't handle the situation well enough to report the compile error without crashing
<t5c>
works so far. now I've got to fix stuff again :)
<t5c>
the diff is already 1000+ lines, that'll be fun to put on github
<andrewrk>
t5c, I think we need buildbot + openbsd worker to add openbsd support
<andrewrk>
if we support something, we absolutely must have CI tests running for that platform
davr0s has joined #zig
<t5c>
andrewrk: makes sense, yes
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<andrewrk>
amazing, @fieldParentPtr works at comptime
<andrewrk>
I think my idea might work
<andrewrk>
ah, the problem is going to be @bytesToSlice
Ichorio has joined #zig
<MajorLag1>
Well if you manage to get it working, I for one will appreciate it.
<winksaville>
andrewrk: I rebased "Add formatted printing of pointers" #1285" on to latest master and Travis CI passed but appveyor failed. Here is the end of the log file, http://bit.ly/2uQWr5n, no real information on what happened.
<andrewrk>
I didn't solve it, but it's certainly a use case that is in scope
<andrewrk>
some day
<winksaville>
andrewrk: I removed wink_log, rebased and squashed. The std.fmt tests passed locally. I'm now running the full test locally and the CI builds are grinding away.
<andrewrk>
winksaville, thanks! I'm looking at the code locally and I'm going to merge it
<winksaville>
FYI: my local tests of #1285 completed successfully
wilsonk has quit [Read error: Connection reset by peer]
davr0s has joined #zig
hooo has joined #zig
<t5c>
andrewrk: is there a more verbose output option for bin/zig build --build-file ../build.zig test ? I fixed all openbsd quirks (as far as the compiler complains), but now its just exiting with error code 1.
<andrewrk>
t5c, hm. it's not supposed to do that. looks like you're on linux?
<andrewrk>
err, no you're building natively for openbsd?
<andrewrk>
if it exits with error code 1, it should print the command that it tried to run and exited uncleanly
<andrewrk>
otherwise it's the actual `zig build` that is doing that, and we should use gdb with a breakpoint on the exit function to see where it's incorrectly exiting from
<t5c>
no, I'm not cross building.
<t5c>
I'm working on OpenBSD. Will have a look with gdb
<t5c>
it also clears my screen. is that intentional?
<t5c>
it seems the build is causing the problem, its happening even without the "test" at the end
<t5c>
any hint where I can set that breakpoint?
<andrewrk>
t5c, on the exit function
<andrewrk>
(gdb) break exit
<andrewrk>
there is no screen clearing code in any of zig, so I don't know why that would happen
<t5c>
link.cpp line 1039
<t5c>
also: /usr/src/lib/libc/stdlib/exit.c: No such file or directory.
<t5c>
what ever that means...
<andrewrk>
what commit are you on? master branch link.cpp only has 1024 lines
<andrewrk>
that means gdb can't show source code for libc. that's fine
<t5c>
oh, sry. yesterday evening but I had to change code in there
<andrewrk>
anyway it looks like it's hitting the exit(1) inside the if(zig_lld_link(...)) right?
<t5c>
yes
<andrewrk>
so it should have printed something to stderr
<andrewrk>
see the line above
<andrewrk>
in gdb can you print the value of `diag`?
<andrewrk>
this is starting to look like an LLD bug
mahmudov has joined #zig
<t5c>
no I cant
<andrewrk>
t5c, can you try linking manually with LLD?
<andrewrk>
I'll give you a command, it will produce some .o files and tell you the link args
<andrewrk>
and then we'll call LLD directly with those args
<andrewrk>
it should output something like: lld --gc-sections -m elf_x86_64 -o build_runner -dynamic-linker /nix/store/84h2zni7h805k0i1ys2bba3dsp1cqnhh-glibc-2.26-131/lib/ld-linux-x86-64.so.2 ./zig-cache/build_runner.o ./zig-cache/builtin.o ./zig-cache/compiler_rt.o
<andrewrk>
just run that verbatim (perhaps you need to specify a different path to LLD rather than `lld`)
<t5c>
yes it does
<andrewrk>
if LLD prints nothing and exits with an error code, then we've found an LLD bug
<t5c>
well, that worked
<andrewrk>
so you can run ./build_runner now?
<t5c>
it errors out though
<t5c>
but yes
<andrewrk>
I don't see how it's possible - the same logic in LLD that chooses an exit code is the logic that chooses whether that if statement in zig calls exit(1)
<andrewrk>
perhaps the LLD versions are different or there are openbsd patches
<t5c>
I bet there are patches
<andrewrk>
we should get those patches 1) upstreamed and 2) into zig's fork
<t5c>
ok, now that build runner is comiled I'd like to do the rest of the tests
<t5c>
lld is a problem I will just stamp as openbsd stuff for now
<MajorLag1>
well, I suppose one solution to this comptime allocation issue would be to take `var` instead of `std.mem.Allocator`, then I could pass an allocator or just something that provides the same functions. Of course that only works for my own code.
<MajorLag1>
But it is the solution you used for async<>.
<andrewrk>
MajorLag1, indeed. perhaps this is one of those things that would be addressed by interfaces
<MajorLag1>
I was just thinking that. As a comptime-interface/trait/whatever, it would support this sort of thing and you could still pass a runtime-interface struct if you wanted to determine the allocator at runtime.
<andrewrk>
let's make sure that we keep this use case in mind when working on the interface design proposals
<MajorLag1>
And if we start doing that as a standard implementation pattern in the std lib, might be worth having language-level features around it.
<MajorLag1>
I wonder... there still isn't a way to return `var` is there? Even as a type?
<MajorLag1>
IIRC there's an open issue for inferred return type, but is it possible to return `var` as a type? I'm not even sure that's necessary or useful, I jsut have a user-level trait implementation idea.
<winksaville>
Is it correct that a custom "format" routine in a struct could be an interface?
<andrewrk>
MajorLag1, var isn't a type, it's syntax that marks parameters/return type as being inferred
<MajorLag1>
right, that makes sense.
<andrewrk>
winksaville, I'm not sure how to interpret your question
<winksaville>
In structs we can add a "format" routine that right now is "magically" handled in the std/fmt/index (where my bug is) and it would seem that magical code would be necessary if there were interfaces.
<MajorLag1>
winksaville: current implementation is such that if I can call `YoutType.format(...)` then it will work, so... yes? You could pass some kind of runtime-interface struct with a `format` fn to std.fmt.format, so like `warn("{}\n", my_type_instance.formatter);` should work... I think?
<andrewrk>
t5c, this looks like LLD not being able to link against libLLVM and libclang
<MajorLag1>
Which is actually pretty useful, come to think of it, if you want to do internationalization.
<andrewrk>
t5c, something to try: throw a `-lstdc++` on that build line at the bottom
<andrewrk>
sorry, `--library stdc++`
<MajorLag1>
As I recall i also had issues with silently failing llvm when I was missing --library c.
<andrewrk>
looks like we have OS-specific logic for adding stdc++ to the linker line
<andrewrk>
so we probably need openbsd logic here
<andrewrk>
I would try it manually first by modifying that build-exe line at the bottom of your paste, followed by getting it to work in build.zig
<t5c>
ha, I missed that completely. will try the line
<andrewrk>
you could try that linux logic, it might work
<andrewrk>
c++ -print-file-name=libstdc++.a
<t5c>
yep that works
<andrewrk>
brilliant. so we can modify build.zig to say "if linux or openbsd"
<andrewrk>
t5c, what did you do to get LLD to produce error messages when it wasn't before?
<andrewrk>
oh, it was printing a bunch of empty lines for no reason that tricked you into thinking it cleared the screen?
<t5c>
it did. just rewrote the output, because for some reason it clears my screen
<andrewrk>
I have no idea why it does that
<t5c>
yeah...
bheads__ has joined #zig
<andrewrk>
I hate it when the bug is in my dependency's code base
<andrewrk>
if it's my own bug I can just fix it
<andrewrk>
maybe zig should parse LLD output
<andrewrk>
and ignore blank lines
bheads_ has quit [Ping timeout: 244 seconds]
<t5c>
hm, it doesn't help. still the same errors
<t5c>
does it need a particular stdc++ version?
zolk3ri has quit [Quit: Lost terminal]
<andrewrk>
t5c, all of them the same? it didn't resolve any of them?
<andrewrk>
I think the "size mismatch, relink your program" is a problem between using the system linker to create zig_cpp.a and then trying to use it when linking with LLD
<t5c>
can I tell zig which linker to use?
<t5c>
oh well, I can tell cmake
<andrewrk>
oops, I mean system compiler, not system linker.
<andrewrk>
ok, so a workaround would be using clang - the same version as zig is linking against - to build stage1
<andrewrk>
and if that has linker errors, then we have to build libllvm and libclang from source using that same clang instead of the system compiler
<andrewrk>
does that make sense?
<t5c>
I have clang 6.0.0 and 6.0.1 in /usr/bin/clang and /usr/local/bin/clang
<andrewrk>
basically C++ compilers aren't compatible with each other
<t5c>
LLD 6.0.0
<andrewrk>
you're saying that clang *is* the system compiler?
<t5c>
yes
<andrewrk>
hmmmm
<t5c>
on openbsd and freebsd it is
<andrewrk>
but patched
<andrewrk>
this is a conundrum
<andrewrk>
wait what is the difference between the /usr/local/bin and /usr/bin versions?
<andrewrk>
we need the same clang/llvm/lld to be used for everything, no mixing and matching
<t5c>
ok, by default its always the one on /usr/bin
<t5c>
and I can use lld which is also the same 6.0.0 version
<andrewrk>
zig has a fork of lld 6.0.0 that it builds
<MajorLag1>
ah, ok. So @IntType shouldn't come up as often anymore. Hopefully I can get Npp's UDL to cooperate
<andrewrk>
ahh
<andrewrk>
I didn't update the vim syntax either
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<hooo>
does anybody know how to define an anonymous struct? I try it here but no success: https://tio.run/##NY2xDoMwDET3fMWVBZAQc0VVqRITn5ECbTPEQZCg0CjfnhpQPdhnne/5q94p9YYWi8UOuOOh9GRmW2S8ZuVNCOC0Oztq9h0pQ8VITpcIbJ7VNhyfXW8R4Bu4a4VtH4jHSWSOmNwTL4KWiooSl9Wo4U9Y5QzJ8ONHQN2yDrXnnn/yCvW2K59H5kSR0g8
<MajorLag1>
Would it be crazy to allow arbitrary float types too, I wonder? We already go so far as to have f16 and f128. Obviously many of them would be useless, or even meaningless like f1...
<andrewrk>
hooo, I highly recommend master branch rather than 0.2.0
<andrewrk>
at this point 0.2.0 is 847 commits behind
<andrewrk>
I think I might remove the Try It Online link until 0.3.0 is released
<andrewrk>
MajorLag1, the difference here is that LLVM recognizes f32, f64, f128, and a couple more, but not arbitrary ones, and LLVM recognizes all int types
<andrewrk>
plus, YAGNI
<MajorLag1>
true
<MajorLag1>
it scratches the part of my brain that likes symetry though.
<hooo>
I downloaded the master branch release build but it probably is broken because I noticed that it's still the same as the zip that I downloaded from july 12
<andrewrk>
hooo, anonymous structs work but aren't that useful because the struct literal syntax requires the struct name
<MajorLag1>
interesting note:`var x: u1024 = 0;` is valid according to the compiler but LLVM complains. `LLVM ERROR: Unsupported library call operation!`
<MajorLag1>
well, it complains if you try to do things with it anyway, like print it.
<GitHub89>
zig/master fd575fe Andrew Kelley: add compile error for missing parameter name of generic function
<andrewrk>
ofelas, fixed ^
<andrewrk>
MajorLag1, yeah. I think this is a limitation of LLVM. it should generate a library call that we can implement. I'll send a code patch to LLVM at some point to implement this
<ofelas>
thanks, again
<MajorLag1>
darn. sadly, even if you use `var` to try and implement comptime allocation, weird things happen in any code called at comptime that tries to manipulate pointers and slices. For instance, I have a utility function to create a struct instance initialized to 0s in my BMP lib, which works fine at runtime and throws an "out of bounds slice" error at comptime. The struct it is initializing is identical in both cases.
<andrewrk>
are you doing &slice[0]?
<andrewrk>
try slice.ptr instead
<andrewrk>
&slice[0] asserts that there is a 0th element whereas slice.ptr does not
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rayman22201 has joined #zig
davr0s has joined #zig
<MajorLag1>
I don't think so, but let me see what happens if I change it a bit.
wilsonk has joined #zig
<MajorLag1>
`return @ptrCast([*]u8, aligned)[0..@sizeOf(PtrType.Child)];` works fine at runtime, but at comptime the compiler seems to think that it can only slice as [0..1]
hooo has quit [Ping timeout: 252 seconds]
<andrewrk>
hmmm
<andrewrk>
this is starting to sound like a bug
<MajorLag1>
it is a single object, but that object is 152 bytes.
<MajorLag1>
I'll see if I can minimize it for a test case.