<hryx>
still weird that it just dies for me even when stepping through. But I'll experiment with that
<andrewrk>
c.tree.root_node.decls.push seems to be causing a std.mem.Allocator.alloc which is clobbering c.tree.root_node.decls itself
<andrewrk>
it might have to do with the different libcs
<andrewrk>
different header files etc
<hryx>
that sounds nasty - not sure how I would debug that. should I look at what libc is being used when I do `make install`?
<andrewrk>
well we can test the hypothesis pretty easily by swapping out the arena allocator for a large fixed buffer allocator
return0e has quit [Ping timeout: 258 seconds]
<andrewrk>
hm it's not a simple swap. I'm going to keep looking into it
<andrewrk>
hryx, I see it. argh
<hryx>
ok, this is very fishy. I ported the tree no-copy "foot-shield" trick from the parser rewrite and rebuilt. now it says SIGSEGV at translate_c.zig:0:33
<hryx>
literally in a comment
<hryx>
oh??
<andrewrk>
yeah essentially we try to "move" arena on lines 174-175. but look, it gets copied in 3 places before that
<hryx>
Wheeeeeee
<andrewrk>
sorry, totally my fault
<hryx>
no no, I'm very grateful for the help debugging
<hryx>
in other news, lldb and gdb give me different results. Surprise! That's what I get for trying to be fancy
<andrewrk>
looks like you already opened an issue for it
<daurnimator>
andrewrk: already ahead of you on that one :P
<daurnimator>
andrewrk: I put inotify into a different category: it's really a linux-only API. whereas e.g. nanosleep is at least implementable everywhere.
<hryx>
mikdusan: I finally found the place where that recursion was happening. No more stack overflow, and we get some translated C. I'm elated. thank you & plz tune in next time to Stevie's personal code diary
<andrewrk>
if that was a podcast I would listen to it
<hryx>
coming soon to a ipod near you
<mikdusan>
hryx: did it have something to do with `inline` ?
<hryx>
nope, in this case I was not getting the expr->subExpr() at a point where recursion was possible
<hryx>
so it was just spinning in circles
<mikdusan>
well what else is a cpu going to do
<hryx>
great point
<daurnimator>
andrewrk: I've been considering streaming more
<daurnimator>
if you'd rather tune into "daurnimator's personal code diary"
<daurnimator>
:P
<mikdusan>
in case anyone cares, zig seems to build and run tests successfully for me w/ Visual Studio 16 2019, Windows 10.
<andrewrk>
thanks mikdusan
<mikdusan>
i have some notes on how to prep Windows 10 for msys2, ssh login, authorized keys, the usual. they're just a list of things to install. anyone need some help just ping.
<andrewrk>
yeah zig's test suite passes everything but there maybe some compile errors lurking in the untested areas of the std lib. I expect to get a few reports when people update their code to use latest master
<daurnimator>
andrewrk: I'm really happy about the new mmap signature. it's been bugging me since I started with zig
<scientes>
I think it would be useful in the compiler, but its not ready yet
<scientes>
the point is that malloc wouldn't just be cheap, it would be free
<andrewrk>
daurnimator, I hadn't considered writing the doc generator completely in userland
<andrewrk>
holy crap is this what it feels like to get incepted?
<andrewrk>
a reflection-based doc generator
<scientes>
^^^
<daurnimator>
yeah... what else were you going to do?
<emekankurumeh[m]>
i thought writing it in zig was the plan from the beginning
<daurnimator>
why would you *not* write it in zig
<andrewrk>
well yeah, write it in the self-hosted compiler
<andrewrk>
this is a different idea entirely
<mikdusan>
i thought something along lines of grabbing ast...
<scientes>
no, comptime should be able to introspect itsself
<daurnimator>
andrewrk: I saw this door open as soon as you starting moving 'zen'/'translate-c' to zig.
<emekankurumeh[m]>
as a separate program?
<scientes>
>
<scientes>
<andrewrk> a reflection-based doc generator
<scientes>
eventually this becomes the ability to call LLVM at comptime, on the program's AST
<andrewrk>
emekankurumeh[m], you could do it entirely in userland if reflection capabilities were improved. it would just be `zig run doc.zig --pkg-begin target the_thing_to_document.zig --pkg-end`
<andrewrk>
doc.zig does @typeInfo(@import("target"))
<hryx>
well hot dog. so wait, does this mean the doc generator crawls types instead of the ast.Tree?
<scientes>
you have to be careful with those imports, as the @import("root") idea was flawed, as it introduces a circular dependancy
<andrewrk>
scientes, zig doesn't have any circular dependency problems
<daurnimator>
hryx: that's what I'm suggesting, yes.
<hryx>
that's W.I.L.D.
<andrewrk>
scientes, everything can use everything and it all works fine
<scientes>
andrewrk, so it is OK to have root.std ?
<andrewrk>
yes
<hryx>
humor me for a minute, what would be the benefit(s) of this reflection-based approach over the AST-based approach?
<andrewrk>
I do wonder though, would people start abusing doc comments putting more metadata in them? of course they would. people love that shit
<hryx>
less direct integration with the compiler?
<daurnimator>
notably you could even do things like @compileLog(std.meta.docs(Mystruct.method))
<andrewrk>
but it would be worth it to get std lib docs, at least for now
<andrewrk>
that is notable indeed
<andrewrk>
it doesn't even need any comptime bugs to be fixed really, it's just simple reflection
<scientes>
well then @import() has to become more first-class than it is in the compiler
<daurnimator>
really useful for the eventual REPL
<scientes>
cause it currently isn't lazy
<andrewrk>
scientes, what do you mean?
<scientes>
builtin and std are implicitely added to the table of every program
<scientes>
*of every file
<daurnimator>
andrewrk: if you add the docComment field to @typeInfo data I'm sure one of us will pick up on the work to crawl the tree and output pretty docs
<andrewrk>
the only thing that gets implicitly added is the mapping of "std" => /some/path/std.zig
<scientes>
but the namespace is not lazy
<scientes>
its a simple fix
<scientes>
i should have realized it
<hryx>
daurnimator: could you explain your example of `@compileLog(std.meta.docs(Mystruct.method))`? I'm still trying to grasp the potential of this idea
<andrewrk>
hryx, the AST doesn't have any type information but zig's reflection has all the type information
<scientes>
andrewrk, that was still enough to be a loop though, as you had bootstrap.zig=>std=>std.zig=>root=>bootstrap.zig
<andrewrk>
hryx, that's why this is exciting
<daurnimator>
hryx: e.g. debugging in a tricky spot and trying to figure out how to use something? drop that statement in and you can see docs right there as you compile
<hryx>
oh crap
<hryx>
this is post-analysis
<scientes>
andrewrk, it becomes even more exciting when someone adds comptime LLVM bindings
<scientes>
i've seen this for a while now
<daurnimator>
lol. you guys are loving this idea :P
<andrewrk>
scientes, I'm not sure what loop you're referring to - also root refers to the file with pub main, not bootstrap.zig
<andrewrk>
I believe you that there's a bug somewhere
<andrewrk>
oh you're talking about the dependency loop compile error
<scientes>
no
<scientes>
i ran into a loop that i have to understand before import(root) is possible
<scientes>
that can be solved by making things lazy
<andrewrk>
scientes, what would you do with comptime LLVM bindings?
<andrewrk>
that would tie the language to LLVM, something that is purposefully not up to this point
<scientes>
you could write /f/ regular expression, and it could be optimized to a memchr('f').
<scientes>
there are many things that could be done
<scientes>
it would make it much easier to do auto-scaling types
<scientes>
like having error be a u8 or u16 or u32
<daurnimator>
Has anyone written a nano syntax highlighter?
<scientes>
i have a half-ass gedit syntax highlighter
<emekankurumeh[m]>
how root.root.root.root is root
merlyndmg has joined #zig
<emekankurumeh[m]>
nvm it makes sense because it's basically the same thing as @This() in any other struct
<daurnimator>
andrewrk: is there a place to file non-zig tasks? e.g. request for a nano syntax highlighter?
<daurnimator>
andrewrk: e.g. a ziglang top level github "projects" board?
<andrewrk>
I think the best option for that is to discuss it in the community. here, mailing lists, reddit
<andrewrk>
you could start an unofficial community projects board
<shritesh>
Is assert compiled away in release-fast?
<andrewrk>
shritesh, even better: it's an LLVM ir branch that has the `unreachable` instruction in it, which gives a hint to the optimizer (which probably just deletes the branch)
<scientes>
daurnimator, the biggest accoumplishment would be language server
<daurnimator>
scientes: nano can't use a language server
<scientes>
i believe that also provides very accurate syntax highlighting
<shritesh>
Gotcha. So it’s probably bad to assert on user inputs to maintain invariants.
<daurnimator>
shritesh: not at all
<daurnimator>
shritesh: in safe mode, that will give them nice feedback. in fast mode; it will allow zig to make assumptions that user input was valid
<andrewrk>
yes, asserting on bad user inputs is a security vulnerability, absolutely do not do it
<andrewrk>
asserting on programmer invariants is good
<andrewrk>
but if we're talking about adversarial inputs, assert means they win
<shritesh>
Thanks.
<andrewrk>
daurnimator is correct though, asserts *are* protected in release-safe mode. so choosing that mode when there exists adversarial input is wise
<andrewrk>
I think daurnimator took "user inputs" to mean that the user is another programmer using your API
<daurnimator>
^ ah, yes I meant that
<andrewrk>
yes in this case assert is perfect
<shritesh>
I’m working on Zig’s WASI std. Today the only defined preopened fd type is a dir. But it might be extended in the future and . Going to do more than just assert here.
<shritesh>
*and things might break.
<andrewrk>
@panic is like asserting but affects all build modes
<shritesh>
Does it still generate the trap instruction? I’ve been using unreachable to force traps in WASM.
<andrewrk>
it generates a call to the panic handler
<daurnimator>
shritesh: remember you can set your own panic function in the root
<andrewrk>
you can use @breakpoint() to force a trap, maybe you can update the default panic handler shritesh?
<mq32>
good morning (or whatever is the time appropiate greeting for your timezone)!
<daurnimator>
mq32: ha, I love it :P
<mq32>
i think that's actually a) expressive and b) well optimized
<mq32>
it's based on a "proposal" of mikdusan, but he used []usize{0}**len
<daurnimator>
mq32: btw, zig you usually don't put a space before ':'
<mq32>
yeah, the formatter does this for me :P
xentec has joined #zig
marijnfs has joined #zig
xentec has quit [Quit: memento mori]
xentec has joined #zig
xentec has quit [Ping timeout: 248 seconds]
xentec has joined #zig
FireFox317 has joined #zig
<mikdusan>
mq32: love the use of void :)
<mq32>
mikdusan: i've had the idea that zero-sized types are zero-overhead by concept
<mq32>
and we can do arrays of any types
<mikdusan>
another zig positive: `return void;` is a thing
<mq32>
mikdusan, yeah, that's nice
<mq32>
but i think i found a compiler error... :(
<mikdusan>
post your reduction
<mq32>
yeah, later, i'm at work right now
<FireFox317>
Hi guys! Is there someone here using Arch Linux? I'm building the compiler succesfully, but when trying the tetris example of andrewrk, I get an LLVM error. However, when using the linux binary on the website, I dont get this error.
<mikdusan>
no arch linux for me, but have an ubuntu vm. can u pastie error?
<FireFox317>
First I thought that this was because I was building the compilter with GCC instead of Clang, but after changing to Clang I still get the error. Btw the tests all pass fine in the compiler using bin/zig build etc
<mikdusan>
i don't think the script will run directly. i just cut-n-paste lines into a shell section by section.
<FireFox317>
Thanks for the script, I'm gonna try that!
<mikdusan>
then after that u can follow zig instructions to build zig. just don't set CC or CXX in your env, or with cmake. let it use the default on archlinux just as you'll do with building llvm+clang.
<mikdusan>
even though "clang" executable is built zig doesn't use it. zig.exe is linked against libclang from "llvm+clang"
<FireFox317>
Ah I see! So if I understand correctly libclang is used for the c compilation/translation in the zig compiler?
<mikdusan>
yup
very-mediocre has joined #zig
<very-mediocre>
do `const definitions` in structs contribute to struct size, or are they hoisted out?
<FireFox317>
Waiting for the compilation of llvm+clang, fortunately I can use 8 cores xD
<mikdusan>
defs do not change size of struct and they are lazy-evaluated
<very-mediocre>
awesome, thank you
<very-mediocre>
function defs take up the size of a pointer i am guessing
<very-mediocre>
kind of makes the namespacing use case have side effects if that's the case
<very-mediocre>
I find myself wanting to represent some data in a packed struct, but my high-level instinct tempts me to add helper functions to the struct as if it was a class.
<mikdusan>
very-mediocre: sure why not? the functions will not change @sizeOf(mystruct)
<very-mediocre>
hm, interesting
<mikdusan>
there is no OO but functions namespaced in a struct can be invoked `Foo.doit()` . if you had `var foo: Foo = ...` defined... and doit takes as first argument param type Foo,
<mikdusan>
then `foo.doit()` works the same as... `Foo.doit(foo)`
<very-mediocre>
I'm aware of that, I just wasn't sure if it was taking up struct space :)
<mikdusan>
ah ok
<very-mediocre>
But yea it shouldn't based on that
<very-mediocre>
makes sense, ty
heitzmann has quit [Quit: WeeChat 2.4]
heitzmann has joined #zig
<FireFox317>
mikdusan: Unfortuantely it didnt solve the issue. I completely build LLVM+Clang from source using GCC 8.3.0 and after that build zig with the command: cmake .. -DCMAKE_PREFIX_PATH=$HOME/local
<FireFox317>
But it still gives me the LLVM error
<mikdusan>
llvm installed to $HOME/local ?
<FireFox317>
jup using cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/local -DCMAKE_PREFIX_PATH=$HOME/local -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_LIBXML2=OFF
<FireFox317>
same for clang
<mikdusan>
zig source version is recent? (btw most recent master renames `os.getRandomBytes()` -> `os.getrandom()` so you will get build error from that)
<mikdusan>
if you are building zig from git repo, verify `zig version` matches git hash
<mikdusan>
that's about all i can think of. to check build/toolchain stuff.
allan0 has quit [Ping timeout: 244 seconds]
<FireFox317>
Jup i pulled the latest version of zig and indeed changed the getRandomBytes function in the source code of the tetris example.
<FireFox317>
I'm gonna try setting up a Arch Linux VM and see if I get the same error there
<mikdusan>
side question; does the binary download version of zig work for you?
<FireFox317>
Yes that one works
marijnfs has quit [Ping timeout: 268 seconds]
<mikdusan>
in your arch-linux vm, try to avoid pacman installing llvm, and just bare minimum like gcc/g++, git, cmake, ninja.
<mikdusan>
fyi on ubuntu i use gcc 8.3.0 so there should be no issue there
<tgschultz>
interesting, I'd have thought the doc generator wouldn't even need to know about the structure of zig code. It's all just comments and signatures, you could get by with a very simple string parser.
<FireFox317>
Well, on the VM I'm not gonna try to build the whole LLVM+Clang, because that already took like 1hour and on the VM that's gonna take even longer
<mikdusan>
ah.
<FireFox317>
Maybe I can see if I can get a smaller zig example that gives the same error
<mq32>
mikdusan, andrewrk: imho this code should compile and don't run into infinite recursion: https://pastebin.com/iu481NRh
<tgschultz>
also, andrewrk, I think to solution to not shoving metadata in there is to just allow users to arbitrarily shove metadata somewhere else. That would be related to #1099 I suppose. It would also be a way out of certain APIs using expected function names (.format(), .serialize(), .deserialize(), etc), that might collide, instead the metadata for a type could contain that information. However I worry, as I'm sure
<tgschultz>
you do, about how unclear code could be with such a system.
<mikdusan>
maybe eyeball the generated cimport.zig (use --verbose-cimport to disclose the path)
<FireFox317>
Hmm, well the crash/llvm error happends when the lld command is run (line 11)
<mikdusan>
is ldd in your env path
<mikdusan>
sorry i meant lld
<FireFox317>
Yes, if i run `lld` it shows this : "lld is a generic driver. Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld (WebAssembly) instead", do you get this same output?
utzig has joined #zig
<mikdusan>
hmm i don't have good understanding on the possibilities here, but presumably `lld` is by default statically linked into zig
very-mediocre has quit [Ping timeout: 256 seconds]
<mikdusan>
and i'm wondering now if somehow your zig is actually running an external lld. maybe that's not a possibility. i admit not being certain of possibility here.
<mikdusan>
--> option(ZIG_FORCE_EXTERNAL_LLD "If your system has the LLD patches use it instead of the embedded LLD" OFF)
<FireFox317>
Should I try to turn that ON?
<FireFox317>
and rebuild the compiler
<mikdusan>
verify you are NOT building with that by greppin'g your $BUILD_DIR/CMakeCache.txt for ZIG_FORCE
<FireFox317>
--> ZIG_FORCE_EXTERNAL_LLD:BOOL=OFF
<mikdusan>
that's what i have on ubuntu.
<FireFox317>
Hmm, so weird
scientes has quit [Remote host closed the connection]
<mikdusan>
i wonder if it is possible the wrong lld includes are being picked up during build of zig. and then linked against embedded lld.
<daurnimator>
FireFox317: 1. you can install zig from pacman. 2. you can download binaries from ziglang.org
<FireFox317>
daurnimator: yes, i know that. But I would like to work on the compiler itself too
<daurnimator>
FireFox317: 3. have a look at the official PKGBUILD for arch
<daurnimator>
FireFox317: 4. working on the compiler itself, you should be using the bundled LLVM
<FireFox317>
daurnimator: Thanks for the suggestion to look at the PKGBUILD, in there the cmake command adds DZIG_FORCE_EXTERNAL_LLD=ON, I think that is gonna fix my error
<daurnimator>
FireFox317: note that in the PKGBUILD we have to patch things out so that we link against system LLVM
<daurnimator>
FireFox317: also note that arch's LLVM is stripped. if you're working on the zig compiler you're really going to want full stack traces in LLVM :)
<mikdusan>
if that fixes it something still smells - ziglang.org doesn't do that and that bin works
<FireFox317>
daurnimator: That was indeed also a think: the stack straces I was getting were just empty
<FireFox317>
daurnimator: So I'm guessing you are also on Arch, how did you fix building the compiler then? instead of installing it through pacman
<daurnimator>
I just follow the instructions you see below 4. above
<daurnimator>
FireFox317: and yes I'm on Arch... Look at the first line of that PKGBUILD :P
marijnfs has joined #zig
<FireFox317>
daurnimator: Ahh hehe, nice. but that is still weird. I followed the instructions and completely build llvm+clang from source, but that still doesn't work
<FireFox317>
Hmm maybe I should also build LLD from source, since it is still using my system LLD libs
<daurnimator>
system LLD shouldn't matter; but a mismatched llvm/clang might? are you linking against system clang?
<FireFox317>
daurnimator: No, i'm linking against a local llvm/clang that I build from source
ki9a has joined #zig
<ki9a>
hi, I saw a note in the zig tracker for lld/llvm for MH_NO_REEXPORTED_DYLIBS
<ki9a>
anyone awake that's involved in that part of zig?
<ki9a>
(got a potential fix for lld for it)
very-mediocre has joined #zig
<dch>
I'm doing a FreeBSD port for 0.4.0,looking pretty good so far apart from this error:
<FireFox317>
Could it be a problem that the lld on my system is version 8.0.0-1 and llvm-libs is version 8.0.0-2?
<mikdusan>
dch: off hand i suspect the ports system has an RPATH policy and is trying to re-write RPATH upon staging. this usually means when creating the exe, you have to tell linker how large space for rpath string to allocate.
<dch>
ok, I vaguely know what this means but I'm not really a compiler / c person so this is a bit unclear. Should I ask on the freebsd ports channel for advice?
<dch>
daurnimator: I see you remote the zig_cpp parts too
<daurnimator>
dch: yep. that has been fixed in master so 0.4.0 is last release that is needed for
<dch>
worst thing is having my desktop compile llvm80 for 5 architectures & 2-3 OS versions :-(
<dch>
going to heat the whole house today
rivten has joined #zig
<FireFox317>
mikdusan: The option DZIG_FORCE_EXTERNAL_LLD=ON indeed does not fix the problem. Also by grepping the Makefile that is generated by cmake, it shows it is using the embedded lld.
<mikdusan>
sanity check: your shell doesn't have any env vars with prefix CC, CPP, CXX, LD, LIB, ?
<mikdusan>
also just because i'm paranoid: nuke zig-cache in your curdir, and ~/.local/share/zig, and let's factor out anything like ccache.
TheLemonMan has joined #zig
<daurnimator>
dch: huh? it takes my laptop about 3-4 minutes
<daurnimator>
and it's only a 2 core thing
fengb has joined #zig
<mikdusan>
u must be joking
<fengb>
error: expected type '*linked_list.Node', found '*align(1) linked_list.Node'
<dch>
daurnimator: we build a lot more of llvm on FreeBSD, and 5x3 = 15 builds, some running under qemu emulation, so ... thats a lot of time
<TheLemonMan>
ki9a, awesome news! Do you have a patch ready?
<ki9a>
TheLemonMan: not yet; i seem to have stumbled on another issue with lld that makes me unable to load a dylib I created (unrelated to this)
<ki9a>
so I can't test it yet.
<fengb>
Is that a real error? Not sure how to strip out the alignment
<daurnimator>
fengb: where did you get that pointer from?
<ki9a>
But it comes down to if ((_ctx.outputMachOType() == MH_DYLIB)) flags |= MH_NO_REEXPORTED_DYLIBS;
<fengb>
@bytesToSlice([]align(4096)u8)
<daurnimator>
fengb: it's saying that the pointer isn't aligned correctly. that might happen if you're e.g. using an intrusive linked list inside of a packed struct
<ki9a>
since it never actually seems to create a re-export command
<daurnimator>
fengb: "Can't do anything about it..." <-- lies :P
<fengb>
I suppose I can toss it into a free node of 4 bytes
<daurnimator>
fengb: never call reallocFn directly. use realloc
<fengb>
This is for testing
<daurnimator>
(or alignedRealloc as you probably want here)
<gamester>
daurnimator: yeah, I'm aware. I just didn't expect to see a commit of this sort that's so recent, in Valve's mature networking library.
<fengb>
I'm trying to gauge how much overhead the std allocator functions take up
<daurnimator>
fengb: alignedRealloc has the @alignCast in it that your code is missing
<fengb>
Ah
<dch>
time to knock off for the day, if anybody else wants to chime in, https://reviews.freebsd.org/D20437 has the current FreeBSD port diff and my ignorance displayed for all to see
<fengb>
I see it, thanks
<mikdusan>
dch: if the exe is statically linked, then the issue is: why is something telling CMAKE to muck with RPATH ?
<fengb>
I saved 95 bytes! lol
<dch>
mikdusan: right. I found in Mk/Uses/cmake.mk that this is set by default, but I don't know yet how to turn that off
<daurnimator>
fengb: you mean of executable size?
<fengb>
Yeah, trying to shrink my wasm size
<daurnimator>
fengb: are you stripping the binary?
<fengb>
Yep, I'm down to 3k
<fengb>
Just probing to see what I can save
<daurnimator>
fengb: made a custom (small) panic function?
<fengb>
wasm doesn't have panic
<daurnimator>
At least when looking at compiler output locally; 90% of the binary of a small test case is panic related functionality
<mikdusan>
dch: i'll leave you with this; CMakeCache.txt seems to have things like CMAKE_SKIP_INSTALL_RPATH and CMAKE_SKIP_RPATH . maybe setting =YES for one or both is the ticket.
<daurnimator>
FireFox317: what package is glfw3.h in?
<FireFox317>
daurnimator: glfw-x11
<daurnimator>
thanks..... weird that pkgfile didn't tell me that
<daurnimator>
FireFox317: okay yes I get the same error
<FireFox317>
Great, finally someone who has the same problem
<FireFox317>
So I found this when I was trying to build the tetris example from andrewrk, that is where the error showed up
<daurnimator>
FireFox317: I've never even seen an error like that from zig before...
<daurnimator>
file a bug I guess...
<mikdusan>
and daurnimator apparently the binary from ziglang.org doesn't produce the error
<FireFox317>
daurnimator: It is an error from the embedded linker i think
marijnfs has quit [Quit: WeeChat 2.4]
<daurnimator>
FWIW with the 0.4.0 release it fails with: lld: error: undefined symbol: glfwSetWindowUserPointer
<mikdusan>
probably just means u need to specify --library glfw
<daurnimator>
yeah probably
<TheLemonMan>
ki9a, hmm, does the dynlib produced by lld contain the MH_NO_REEXPORTED_DYLIBS flag?
<daurnimator>
yep. works fine with the 0.4.0 release
<TheLemonMan>
yeah, the mantainers gave up on it since AAPL decided to focus on ld64
<ki9a>
Yep
<andrewrk>
fengb, in release builds @memset and std.mem.set should be exactly the same code
FireFox317 has joined #zig
<andrewrk>
TheLemonMan, have any interest in writing a self-hosted linker? :D
<TheLemonMan>
nope, linkers are complex beasts that I don't want to tame (yet) :)
<TheLemonMan>
and lld is quite good if you don't mind the spurious mach-o problems
<andrewrk>
agreed
<TheLemonMan>
maybe we can write a sternly worded letter to Apple and have them switch to ELF
<andrewrk>
hahaha
<andrewrk>
the need for an incremental linker isn't really needed until the stage2 compiler is done
<andrewrk>
but I do predict it will become the bottleneck at some point
<TheLemonMan>
yeah, the linking phase has to shovel around a lot of stuff
<TheLemonMan>
fuckin' LLVM parallel linking takes a god-awful amount of RAM
allan0 has quit [Ping timeout: 272 seconds]
<ki9a>
How will you guys do incremental linking?
<ki9a>
I've been playing with the llcm linkers a bit already and gave up on lto
<ki9a>
Way too slow. Thinlto was also impractically slow
<ki9a>
So all I can depend on is llds built in features for incremental
<ki9a>
(not on Darwin ofc)
<TheLemonMan>
annd #2545 has been rebased on top of the huge std refactoring patch
<andrewrk>
ki9a, we're gonna have our own linker eventually ¯\_(ツ)_/¯
<TheLemonMan>
andrewrk, I had to fix the mprotect signature and fix a compile error there
<ki9a>
Ah
scientes has joined #zig
<ki9a>
I do understand that. I eventually wrote my own debugger too because lldb only caused trouble instead of solving it.
<ki9a>
Writing a linker is only annoyingly much work ;)
<andrewrk>
much smaller than LLVM though
<ki9a>
True
<ki9a>
It's the relocations, dwarf and fifteen thousand platform differences that will be annoying.
rivten has quit [Ping timeout: 256 seconds]
<andrewrk>
still, a nice, easily testable purely functional problem
<andrewrk>
and fun to work on, this draws contributors
<andrewrk>
everybody secretly hates the "don't reinvent the wheel" rhetoric, and wants and excuse to do it :)
<ki9a>
Haha zo true.
<ki9a>
I'd write my own codegen if I could beat llvm
<TheLemonMan>
llvm codegen is quite fast if you manage to stay in the FastISel path
<TheLemonMan>
at least when -O0 is involved, optimized builds are a completely different beast
<andrewrk>
TheLemonMan, is zig accidentally leaving the FastISel path in debug builds? LLVM accounts for ~75% of the time spent compiling, for example, the behavioral tests
<ki9a>
TheLemonMan: in my compiler most time is spent on llvm codegen even in debug.
<TheLemonMan>
andrewrk, yep, the FastISel is quite simple and doesn't seem to like non-canonic (eg. 8 16 32) integers
<andrewrk>
oh! that is very interesting indeed
<andrewrk>
so if we emitted only canonical integers to llvm we could stay in FastISel? that's worth exploring
<TheLemonMan>
yeah, returning OutOfMemory is a better choice there
<andrewrk>
I'll update the doc comment for OutOfMemory on that function
<TheLemonMan>
want me to update the PR or do you want to do it yourself post-merge?
<andrewrk>
TheLemonMan, other than that I'm ready to press the merge button. thanks for sharing that info about MAP_GROWSDOWN
<andrewrk>
I'll take care of it
<andrewrk>
merged
<tgschultz>
andrewrk, I can get line & column of a source file that crashed the compiler from an AstNode using GDB, but how do I get which file it was?
<andrewrk>
tgschultz, ok this got a little more annoying after the "files are structs" thing. (gdb) node.owner.data.structure.root_struct.path[0]
<andrewrk>
oops: (gdb) p node.owner.data.structure.root_struct.path[0]
<tgschultz>
cool, thanks.
<andrewrk>
if you're hitting an assert though you might be able to change it to the new assert thing so that it gives you this info
<andrewrk>
depending on where it is in the code
<FireFox317>
andrewrk: When I build the compiler on my Arch Linux machine with the current master, I get the LLVM error (shown in pastebin), but if I checkout to the latest release 0.4.0 and then build the compiler, I don't get the error and everthing works fine. https://pastebin.com/pWBwzQUg
<FireFox317>
Do you know any commit that could have broken this? Maybe has something to do with @ptrCast?
<tgschultz>
huh, turns out knowing the file and line is suprisingly unhelpful in this case anyway.
<andrewrk>
FireFox317, I'll look into this now
<FireFox317>
btw: the build command I used is not correct in the pastebin, should be this ` zig build-exe main.zig -isystem /usr/include --library c --library-path /usr/lib --library glfw
<andrewrk>
thanks
<FireFox317>
And the error only happends on Arch Linux, daurnimator had the same problem, but other users didn't have this erro
<tgschultz>
acutally andrewrk, this doesn't appear to be the right file at all. The column it references doesn't exist in the line it references (which is just a closing brace).
<andrewrk>
tgschultz, the thing I wrote will give you the path to the file that the ast node is in - I've never seen that be wrong before
<andrewrk>
hmm that is strange indeed
<tgschultz>
well it's possible I'm doing something wrong, but it's the source_node from ir_resolve_peer_types, has line 1305, col 71, and owner.data.structure.root_struct.path[0] points to compilation.zig, and in my branch that line is empty (its actually the line *after* the closing brace for generateDecl)
<andrewrk>
that suggests something is very wrong, if the parser doesn't even have correct line number / source files matching each other
<tgschultz>
maybe it's a cache thing. I run the integration tests without rming ./build for a quicker turn around
<andrewrk>
in my workflow I never delete cache stuff (unless I'm testing cache stuff)
<merlyndmg>
I was trying to debug a linker problem for that ticket I filed (that was already fixed) the other day. I had to repeatedly delete the cache to get the --verbose-link line to actually display. Wondering if there could be some way to get dry run info, even if the results are cached?
<merlyndmg>
I could just file a ticket and let you answer there heh
<TheLemonMan>
maybe --cache off ?
<TheLemonMan>
andrewrk, wrt the use of @hasDecl in linux.zig: doesn't the compiler analyze both the true and false branches anyway?
<andrewrk>
TheLemonMan, nope why would it do that?
<andrewrk>
@hasDecl returns a comptime bool
<TheLemonMan>
oh well, it's still giving me a 'undeclared identifier' error
<andrewrk>
on what target?
<andrewrk>
I know what's happening
<TheLemonMan>
x86_64, I'm rebuilding the compiler
<andrewrk>
huh that's weird why don't I get that error?
<andrewrk>
but anyway, the "undeclared identifier" error is in pass 1, but it should probably move to pass 2
<TheLemonMan>
oh, because I've added another syscall
<andrewrk>
that will have the unfortunate side effect of making zig not catch undeclared identifiers for branches not taken, but that's kind of already status quo with every other error
<andrewrk>
a more comprehensive solution is needed for this use case
<andrewrk>
I do think how it works now is inconsistent though
<merlyndmg>
I believe there's a way to skip caching in general, though I was getting problems with it because of including the local dir and not using the system-wide .lib file. Maybe fixing that will make the "dry run" thing unnecessary
<merlyndmg>
and there's already a ticket for fixing that
<andrewrk>
TheLemonMan, I think it should be a pretty straightforward fix, which I would be happy to do for you today if it's blocking you
<TheLemonMan>
that'd be sweet (if it doesn't take you too much time ofc)
<FireFox317>
andrewrk: As you can see on the current master the compiler completely skipped the @ptrCast and just passed in the Tetris pointer. In the 0.4.0 release, is is using `getelementptr` which it should do, i assume.
<tgschultz>
..which is supported by the actual problem: trying to access error_set.errors[0] when error_set.errors == null. which means that the error count is > 0, but there aren't any errors in the set? oy. how did I manage that...
marmotini_ has quit [Remote host closed the connection]
<andrewrk>
tgschultz, maybe valgrind has some warnings?
<tgschultz>
maybe, I didn't make any changes to the cpp source though. somehow did this with just zig source modifications.
<tgschultz>
I'm pretty sure it's going to have to do with std.event. It's in the self-hosted build and all std tests pass, but event isn't really covered by tests right now.
<andrewrk>
after this round of PR merges I'm going into a cave to work on copy elision
<FireFox317>
andrewrk: Yes, that indeed gives a similar error. Should I make a issue for this on github?
<andrewrk>
feel free to, but I'm about to solve it regardless
<mikdusan>
FireFox317: line 7 of your llvm-ir pastie. what is that `i8*` doing at begginning of the line?
<FireFox317>
mikdusan: That comes from the error message that LLVM outputs to stderr . So only the first two lines of the master are relevant
<mikdusan>
oh output mixing. grr.
<FireFox317>
my bad :)
<merlyndmg>
I've filed the dry run suggestion ticket. No offense taken if you decide to punt or reject it :) I could easily see it being hard to do or low priority at this time
<mq32>
okay, so i have to manually floor the value
<scientes>
mq32, if you are doing anything fancy you just want to use bitcast
<scientes>
mq32, and extract the significand and exponent
<mq32>
nah, not fancy :D
<scientes>
and sign bit
<mq32>
just casting a float to integer range and back
<tgschultz>
ok, new data: it might be right about the file, but it is still wrong about the line and column number. Other than that I've made no progress in determining what part of error inferrence I managed to break this time.
<scientes>
mq32, if you first do floor or ceil, then the significand IS the integer, unless it is too large.
<andrewrk>
ooh, I should update that to use vectors
<emekankurumeh[m]>
adding operations for vectors shouldn't be too hard right?
<andrewrk>
I mean SIMD\
<emekankurumeh[m]>
i might work on that issue if i have some time
<scientes>
emekankurumeh[m], many llvm operations just work on vectors
<emekankurumeh[m]>
so you don't have to emit a specific llvm "function" for each type?
<emekankurumeh[m]>
or does zig already take care of that?
<scientes>
it does
<scientes>
oh wait, you need my patch
<emekankurumeh[m]>
for what?
<scientes>
to gen the names of the vector functions right
<scientes>
when emiting the llvm functions
<andrewrk>
we need test coverage too
<scientes>
yes
<andrewrk>
and safety checks are a fun puzzle for vectors
<scientes>
and branching that works with vectors
<andrewrk>
ah yes I remember you bringing that up
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<tgschultz>
I can't even figure out what error set inference is breaking on. I made some progress by removing the error inference and letting it spam "expected x got y" because at least then it would report the actual error set mismatches and I could fix them, but even after dealing with that it still crashes trying to infer the error
<tgschultz>
and if I explicitly make it 'anyerror' it still crashes trying to infer the error. I have no idea what that's about.
<andrewrk>
donpdonp, while and if are nearly identical syntactically
<andrewrk>
the only difference is a hidden "goto the condition" branch at the end of the while body
<andrewrk>
well and the optional continue expression
<tgschultz>
it's more paralyzing than annoying. I can't eve brute force my way out of it. My next step is to just replace every errorset in the source tree with anyerror I guess
<andrewrk>
:(
<andrewrk>
what is this for?
<andrewrk>
I mean what are you working on?
<tgschultz>
I wasn't serious about that last part, it would defeat the purpose. This is the last of the interface reform exploration, the one in which interfaces do not use dynamic error sets.
<tgschultz>
Which may be dead in the water anyway because it would rely on @errSetCast, but it makes every other use of streams a lot nicer.
<donpdonp>
whats the way to say that? i want to accept a list of type T, and a single param of the same type
<andrewrk>
comptime T: type, list: std.LinkedList(T), item: T
<donpdonp>
awesome. thx. zig's type handling is amazing.
halosghost has quit [Quit: WeeChat 2.4]
<Aransentin>
Writing a little WebGPU demo in Zig+WebAssembly. Pretty fun, but It's a little concerning that you can dump arbitrary old GPU memory (e.g. from other desktop processes)... I can understand why it's still behind a Chrome flag 😃
<andrewrk>
TheLemonMan, how enthusiastic would you be about rewriting the scripts from 2509 in zig?
<andrewrk>
I'm pretty sure the std lib has APIs for everything you're doing in that python code
<TheLemonMan>
you must really hate python, heh
<TheLemonMan>
I'd say that's a nice contributor-friendly task
<andrewrk>
fair
<shritesh>
Aransentin: I couldn’t even find any docs for WebGPU last time I looked into it.
<andrewrk>
TheLemonMan, it's clear to me that we need to do versioned glibc, as you've demonstrated, but I'm sad that it's causing O(N) file size that we have to ship
<Aransentin>
shritesh: There's no docs, no. Just looking at the "hello world" demo and then the IDL is pretty much enough to grasp what's going on though.
<andrewrk>
also it looks like you did x86_64 and aarch64, but we'd have to ship even more files to match all the targets from `zig targets`
<TheLemonMan>
well, the map files are quite small, the huge part is just the stubs + versioning infos
<andrewrk>
yeah. I wonder if we could ship the .abilist files instead
<shritesh>
Aransentin: Ah. It’s not even listed in caniuse yet.
<andrewrk>
ugh these .abilist files are pretty big too and there is a unique set per arch
<TheLemonMan>
the abilist files are not understood by the linker and you still need some pre-processing to "pin" a version
<andrewrk>
right, if we shipped .abilist files then the compiler would need to have the functionality that currently exists in the scripts
<andrewrk>
if it was desired to choose a particular glibc version as part of the target, such a strategy would make sense
marijnfs has joined #zig
<Aransentin>
shritesh: Yeah, it's not even fully specced - e.g. they haven't decided on what shader language to use (Chrome takes Spir-V for now)
wootehfoot has quit [Read error: Connection reset by peer]
FireFox317 has quit [Ping timeout: 256 seconds]
<shritesh>
Looking at how unsupported WebGL2 is, I’d assume it’s gonna take a while
<Aransentin>
WebGL2 is only unsupported on macOS, no? Since apple already supports WebGPU it might actually be more supported than WebGL2 soon...
<donpdonp>
pub fn listSortedInsert(comptime T: type, list: std.LinkedList(T), item: T) void { list.append(item) => error: expected type '*std.linked_list.LinkedList ... found '*const std.linked_list.LinkedList...' (with the arrow pointing to 'l' in list.append
<andrewrk>
expected * found *const
<donpdonp>
yeah im just not sure what that means. the call is listSortedInsert(myType, myList, myItem) where myList is a std.LinkedList(myType)
<donpdonp>
ie its not a pointer to begin with, just a plain list
<shritesh>
WebGL2 is behind a feature flag on all Apple platforms and they renamed their “WebGPU” spec to “WebMetal” (again, behind a feature flag). It’s a mess.
<donpdonp>
ive tried changing the call signature to *const LinkedList but then it leads me down another path of errors.
<andrewrk>
donpdonp, your list is const but to append it needs to update the len property of the list, so the list cannot be const
gamester has joined #zig
* donpdonp
hmms.
<gamester>
donpdonp: "list: *std.LinkedList(T)"
<donpdonp>
what I dont get is why isnt the error at the callsite where it should say listSortedInsert(myType, myList, myItem) => error looking for *LinkedList and given LinkedList
<donpdonp>
the callsite is really saying listSortedInsert(type, struct.list, item) where struct { list: std.LinkedListmyType }
<donpdonp>
is struct.list a const variable in this case? would it need to be struct { list: *std.LinkedList(myType) }
<andrewrk>
donpdonp, then your struct is const but needs to be mutable because struct.list.len needs to get updated
<donpdonp>
ah
<andrewrk>
it depends on how you want memory to be laid out. the null hypothesis is no pointers
<andrewrk>
but if you have to make a pointer to make something work, so be it
<donpdonp>
i think i see now.
<andrewrk>
just change your variable from `const` to `var` which has type struct { list: TootList }
<gamester>
uhmm as far as I can see the function accepts the std.LinkedList by value, but you have to change it to *std.LinkedList to be able to operate on the linked list in the function
<donpdonp>
okay tried that. => Assertion failed. This is a bug in the Zig compiler.
<donpdonp>
heh.
<andrewrk>
gimme dat stack trace
<donpdonp>
how do i get the stact trace?
<donpdonp>
stack
<andrewrk>
wait for it to print the stack trace rather than pressing ctrl+C
<donpdonp>
its just a bunch of addresses, also this is zig HEAD from 2019-05-20
<andrewrk>
damn
<donpdonp>
does my zig need to be built differently to get a useful stack trace?
<TheLemonMan>
nope
<TheLemonMan>
that's just because the binary is PIE (iirc)
<andrewrk>
I thought it was because that's a release build and zig's dwarf parsing isn't that sophisticated yet
<TheLemonMan>
you must be really lucky to have such a long stack trace if that were the case :P
<TheLemonMan>
the frame pointer is intact
<TheLemonMan>
it's just the binary that's loaded at 0x559254xxxxxx
<andrewrk>
why is that a problem?
<andrewrk>
is std.process.getBaseAddress() wrong?
<TheLemonMan>
and the DWARF parser uses the ELF file from disk where no relocation has been made
<TheLemonMan>
so it's as if it was loaded at zero address
<andrewrk>
hmm I thought I took that into account
<gamester>
donpdonp: the function signature: "listSortedInsert(comptime T: type, list: *std.LinkedList(T), item: T) void", the callsite: "listSortedInsert(type, &struct.list, item)", where struct has to be non-const.
Ichorio has quit [Ping timeout: 252 seconds]
<TheLemonMan>
it's quite easy to fix, just run dl_iterate_phdr and pick the base address from the first entry
<TheLemonMan>
that's why I implemented it, I never got around to implement the other debugging niceties I had in mind
<andrewrk>
TheLemonMan, is dl_iterate_phdr even necessary? I thought the phdr from the aux vector could be used
<TheLemonMan>
yeah, but you want it anyway
<andrewrk>
yeah sure
<TheLemonMan>
if you look at the stack trace you'll see that the last address is always different from the other ones
<TheLemonMan>
that's because __libc_start_main comes from libc.so.6
<andrewrk>
TheLemonMan, I'm going to come back to 2509, I'll look at your other PRs now
<TheLemonMan>
and you actually have to (lazily) load all the debug infos from all the loaded libs to have complete stack traces
<andrewrk>
ah right good point
<gamester>
donpdonp: Anything passed in by value is const, but as an optimization the list is passed by *const instead. That initial error is simply saying that you're trying to modify a const list. The only way to modify the list inside the function is to pass it via a pointer explicitly.
<donpdonp>
gamester: yeah im working down that path. if func(myStruct) is a *const, then func(&myStruct) as * is ... interesting.
<donpdonp>
gamester: that works. thx.
<gamester>
donpdonp: I think the *const is just an internal detail that's leaking through the error message. The type via @typeOf is probably not *const
* donpdonp
nods
<gamester>
Just to correct myself here: "but as an optimization the list is passed by *const instead" - I think structs are just passed by default via *const. An optimization would be making small structs pass by value instead, which I don't think is done yet.
<mq32>
andrewrk, i resolved my problem with static member vs. field:
<mq32>
so i can write routines which work for each compiletime known bitmap sizes and runtime known bitmap sizes
<mq32>
(compile time known bitmaps don't need memory management except for stack)
<andrewrk>
ok this seems fine to me because you are trying to match a dynamic interface
<mq32>
yeah
<andrewrk>
carry on then :)
<mq32>
otherwise i would use "const bla = 10"
<emekankurumeh[m]>
where does zig handle whitespace in the parser?
<emekankurumeh[m]>
the self-hosted one
<scientes>
thats probably mostly the tokenizer
scientes has quit [Remote host closed the connection]
scientes has joined #zig
<andrewrk>
TheLemonMan, ok the undeclared identifier thing is pushed
<TheLemonMan>
awesome.bat
<shritesh>
So WASI’s rights/capability system for working with files is so convoluted that even Rust’s stdlib calls the reference C function and calls it a day.
<andrewrk>
shritesh, it's starting to sound to me like zig project should get involved in the WASI specification
<andrewrk>
one thing we could do is just make shit up, and have a more capable interpreter than e.g. wasmer
<andrewrk>
people would use zig's interpreter because it was more useful and could do more stuff and the spec was reasonable
<andrewrk>
the official WASI spec would then at least take zig's WASI spec proposals seriously, and once they solved e.g. networking/file systems, then we could change to meet the official spec
<andrewrk>
compatibility / stability doesn't matter because it's not even specc'd yet and not useful for any real purposes yet
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<andrewrk>
isn't crane station part of the rust project? why do they get to specify everything? :)
<shritesh>
Yeah. It’s just so hyped right now and all three runtimes are based on the same codebase
<shritesh>
There is literally one reference sdk
<andrewrk>
I think there's room for an experimental wasi interpreter that has a much more capable spec
<andrewrk>
people would use it as a point of reference for sure
fengb has quit [Ping timeout: 256 seconds]
<andrewrk>
to quote La Bamba: Yo no soy marinero / Yo no soy marinero, soy capitán
<shritesh>
As for the spec, the last meeting notes seem to indicate that they’ll just provide versioning and similar capabilities and everything else that’s useful will be decided later
<shritesh>
I like what warmer is doing in this regard: they literally implement syscalls
<shritesh>
Wasmer *
<scientes>
> First, it's a usable libc.
<scientes>
lots of hype for asm.js, rinse wash and repeat
<shritesh>
I’ve been learning and trying out simple problems first to get there. I do web/app stuff so this is all new to me.
<scientes>
why cant you just call a FFI?
<shritesh>
scientes: You need an execution environment first. It’s not elf
<shritesh>
The memory model is different, it’s a virtual ISA
<scientes>
yeah but this already doesn't have the whole js sandbox
<scientes>
so why not make it elf, but with a webasm interpreter?
<scientes>
the C functions do not require a specific memory model
<shritesh>
The wasm interpreter is exactly what I’m working on
<scientes>
ok, but i see no need for all this libc stuff, you can just use an existing libc via a ffi
<scientes>
or the zig libc
<shritesh>
WASI is just a “standardized” interface that’s POSIX-like on top of that
<scientes>
but why can't you just target C ABI compat, and then document the limitations
<shritesh>
Well, the reference sdk is literally a fork of musl with a capability system and everyone uses it
<scientes>
oh ok, so this is what everyone is already doing
<shritesh>
Yes. And that’s the problem
<scientes>
well the best GUI is going to be a web browser
<shritesh>
There is one implementation and C/Rust have the benefit of using it directly
<shritesh>
It’s not for GUI, it’s for servers and such
<wrl>
best GUI for wasm specifically?
<scientes>
so this is side-stepping nodejs
<scientes>
yeah zig certainly has a shot here
<scientes>
i'm not terribly interested, but I'll grab my popcorn
<shritesh>
Exactly
<scientes>
I guess I can even get some of my stuff to work with webasm SIMD
<shritesh>
LLVM already has support for the SIMD proposals
<shritesh>
So I’d assume yes
<scientes>
well there is a big opening for cross-platform SIMD
<scientes>
I want to work on a zig-libmvec
<scientes>
cause I was just paid to do ppc work on libmvec
<scientes>
but its the wrong way
<scientes>
and arm is doing the same
kristoff_it has joined #zig
<scientes>
anyways, I should stop vapor-wareing, i thought i wasn't going to talk about my idea...
<shritesh>
Same.
scientes has quit [Remote host closed the connection]