ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
isd has quit [Quit: Leaving.]
<MajorLag>
man, llvm takes freaking forever to compile.
<hoppetosse>
is there a way to get the compiler to only emit code in the root source file?
<hoppetosse>
MajorLag: it's particularly painful when it fails
<tiehuis>
the docker image used to do the entire llvm/clang/zig compile in one step which was really bad if you forgot a cmake flag for zig or something at the end
<hoppetosse>
more specifically, I know overriding the default panic function can get rid of the cruft in the --verbose-* things
<hoppetosse>
are there any other ways to reduce the amount of output to only user defined, non-std code
<tiehuis>
what is the purpose of this by the way? i had some similar troubles when trying to get okay output for zig on compiler-explorer
<tiehuis>
i ended up just exporting via the c-abi, although that still pulled in other code so not exactly the same
<MajorLag>
hoppetosse, that reminds me, I should double check there's enough space on this vm disk
<hoppetosse>
I was about to say I once ran out of space on my vm
<hoppetosse>
I think I had a 16 GB disk
<hoppetosse>
so... yeah
<hoppetosse>
tiehuis: I'm actually trying to solve #838
<MajorLag>
this one is 32GB, so far build hasn't put it over 1GB yet, but there's still 77% of llvm and clang to go.
<hoppetosse>
It's a bug that's bugged me before
<hoppetosse>
I just trying to compare the output of a few similar structs to see where the problem could be
steveno_ has quit [Remote host closed the connection]
<andrewrk>
yeah those don't look like valid syntax to me
<Hejsil>
Alright. They don't parse in the current compiler, so just making sure they're not suppose to
<Hejsil>
Then I'll just store Token instead of NodeStringLiteral where an expression is not expected
<andrewrk>
Hejsil, ohh, sorry, actually I think that should work
<Hejsil>
Uuuh
<andrewrk>
for example you should be able to do `const lib_name = "kernel32";`
<Hejsil>
Alright
<andrewrk>
`extern lib_name fn foo() void`
<Hejsil>
Then that's a bug in the c++ compiler
<andrewrk>
oh
<andrewrk>
for test, let's make it a string literal - not an expression
<andrewrk>
maybe we do the same for extern right now and we can revisit if the use case comes up
<Hejsil>
But my test text_prefix ++ " test name" {} :)
<Hejsil>
Alright. I'll store NodeStringLiteral then, in the case that we change it later
<andrewrk>
ah. hmm. let me think about that
<Hejsil>
:)
<andrewrk>
Hejsil, your zig fmt: zig fmt test is quite interesting. It turns violations of the formatting conventions into test failures
<Hejsil>
Oooh ye. I didn't actually think that far lol
<MajorLag>
andrewrk, have an interesting compiler bug. seems to require multiple conditions, causes segfault. This is as minimal as I've been able to get it so far: https://paste.ubuntu.com/p/jszQv4N2fb/
<MajorLag>
I was going to make an issue, but I'm honestly not sure what to call it.
<andrewrk>
MajorLag, how delightful
<andrewrk>
I'll have a look
<MajorLag>
Thanks. no rush or anything, it isn't blocking me.
<andrewrk>
MajorLag, did you see that I'm about to make zig find libc at runtime?
<andrewrk>
I think this + fully static build is going to make getting up to date zig installations on linux really easy
zesterer has quit [Ping timeout: 256 seconds]
<GitHub98>
[zig] raulgrell opened pull request #877: Fix some errors in std.io (master...stdlib) https://git.io/vxKnb
<andrewrk>
MajorLag, in your paste, I think zig is (incorrectly) attempting to generate an errdefer for the `return error.Fail` even though the errdefer is in the outer scope
<MajorLag>
andrewrk, yeah I did. That + static Zig is really great. Updating should be a matter of wget + untar.
<MajorLag>
Considering that you can incorrectly reference vars from the outer scope that adds up.
<andrewrk>
MajorLag, you should be able to reference comptime vars though, right?
<MajorLag>
yeah definitely. I use that occasionally for "comptime closures", but it lets you get away with referencing mutables, which usually segfaults.
davr0s has quit [Ping timeout: 255 seconds]
Hejsil has quit [Ping timeout: 260 seconds]
<GitHub149>
[zig] andrewrk closed pull request #872: find libc and zig std lib at runtime (master...runtime-libc) https://git.io/vxo6A
<GitHub132>
zig/master eb6ff79 Raul Leal: Fix undeclared identifier error in readUntilDelimiterBuffer and incorrect number of parameters in readUntilDelimiterAlloc (#877)
zesterer has joined #zig
<MajorLag>
Found a bug in hash_map.
Hejsil has joined #zig
<MajorLag>
err... maybe not...
<MajorLag>
ok, no, there's definitely a bug in either HashMap or BufMap
<hoppetosse>
What's trigerring it?
<MajorLag>
I posted an issue. It is triggered by overwriting a value for a key
<MajorLag>
but only under certain conditions. It wouldn't even show up in a simple linux test.
zesterer has quit [Quit: zesterer]
return0e has quit [Ping timeout: 240 seconds]
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
curtisf has joined #zig
return0e has joined #zig
<MajorLag>
On that operator overloading thread: it occurs that one could probably write a comptime formula parser such that `var p = ctMath("2*x*y + 3*z + 5y - 8*x", x, y, z);` would work. I'm tempted to try.
<Hejsil>
MajorLag, and you could probably use std.zig.parser to parse the expression :)
<MajorLag>
I was thinking that. I haven't dug around in it all, I'd have to take some time to find the relevant code. This seems worthwhile as a demonstration of a way to support DSL without going crazy.
<Hejsil>
But then again. std.zig.parser does not expose the expression parsing code directly
<MajorLag>
That's ok, I can always just copy it.
<Hejsil>
So you would have to wrap the expression in "const res = <expr>"
<andrewrk>
one thing we need to solve is having an allocator at comptime that is allocating static memory
<andrewrk>
actually I think this may already work
<andrewrk>
holy crap, yes you could initialize a hash map at comptime
<andrewrk>
I think
<Hejsil>
Oooh, really
<Hejsil>
Cause I really need that in some randomizer code
<andrewrk>
maybe. note that you would not be able to add items to it at runtime
<andrewrk>
it should work in theory. if something prevents it from working I'll look into it
<andrewrk>
it might make sense for a comptime computed hash to be a different type anyway, because you would want to do something such as compute a perfect hash function
<Hejsil>
Np. I don't need to add values at runtime
<Hejsil>
Or, well
<Hejsil>
I don't require it
<Hejsil>
A comptime hashtable that is
jjido has joined #zig
<Hejsil>
andrewrk, in the self-hosted ast, we have structs like IntLiteral, FloatLiteral, StringLiteral and so on. All these literals are just "struct { base: Node, token: Token, }". Would it be reasonable to just have a NodeSingleTokenLiteral or something, that all literals (except NodeMultilineStringLiteral) use
<andrewrk>
Hejsil, I'm fine with it either way. I think it will be easy to change later if we change our minds
<Hejsil>
Alright
<Hejsil>
Also, I've been woundering. The ast use tokens to point back to the source string for these literals (and other things). Do we not want people to be able to contruct an ast programmaticly?
<andrewrk>
you mean within the self hosted compiler?
<Hejsil>
Well, let's say people wonna use std.zig.parser to write a tool that introments your code
<Hejsil>
Aka, parse source -> add extra nodes -> output to text
<andrewrk>
ahh
<andrewrk>
and right now the tokenizer has the handle to the source code buffer
<Hejsil>
Yes
<andrewrk>
well, the tokens point to indexes, not pointers. so we could append to the tokenizer's buffer pretty safely
<Hejsil>
I guess that's true
<Hejsil>
Alright, no more questions for now!
<Hejsil>
Back to writing parser code!
<andrewrk>
ha
<andrewrk>
I'll keep this question in mind
<andrewrk>
Hejsil, I'm curious how you would solve the async fn call syntax. it was tricky when I was looking at it
<Hejsil>
I have no idea!
<Hejsil>
Yet
<andrewrk>
the recursive descent parser parses the next thing after `async` as an expression, and then gives a parse error if it ends up not being a fn call
<andrewrk>
I don't know how that translates to the expression stack thing
<Hejsil>
Hmmm... I could probably have an State.AsyncEnd that is hit after the expression is parsed. And then that state checks for the fn call
<andrewrk>
oh! of course
<Hejsil>
The state machine is really interesting to work with
<Hejsil>
I've not written parser like this before
<andrewrk>
you start to see the bijection with the recursive descent
<Hejsil>
Indeed :)
<andrewrk>
the expression stack thing is new though
<Hejsil>
I'll never have to write a recursive function ever again >:)
<Hejsil>
Ye, I read that when looking up the precedence of the Zig operators
<Hejsil>
I think I'll keep all the Literal nodes btw. It's just a little friendlier if we wonna refactor the tree, and we can always merge them later
<andrewrk>
sounds good
curtisf has quit [Ping timeout: 260 seconds]
<Hejsil>
andrewrk, back to the async passing. Isn't it the job of the type checker, not the parser, to check async is actually being applied to a function call?
<Hejsil>
I mean, it has to check if it's type is an async function either way :)
<andrewrk>
Hejsil, if we did it that way, we would have to figure out what this means: @typeOf(async foo)
<Hejsil>
I'm not sure I see the problem. The typechecker will have to check that the type of foo in "async foo()" is "async fn(<args>) <return>" anyways, right?
<andrewrk>
in the expression `(async foo)()`, the expression `async foo` will need its own type
<andrewrk>
e.g. a new entry in the TypeId enum
<andrewrk>
parsing it as `async (foo())` does not make sense; it would be a compile error for calling an async function without async
<Hejsil>
Aaah, alright. The paren example made it click