notzmv- has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
notzmv has quit [Ping timeout: 240 seconds]
ur5us_ has joined #zig
brzg has joined #zig
fputs has joined #zig
cole-h has quit [Ping timeout: 240 seconds]
daurnimator has joined #zig
remby has left #zig ["Good Bye"]
gazler_ has joined #zig
gazler__ has quit [Ping timeout: 260 seconds]
dimenus has joined #zig
<andrewrk>
ifreund, it's really nice that your distinct type patch also made the ZIR printing show the @ names
<andrewrk>
in retrospect it seems obvious that Ref should have been an enum :)
<sh4rm4^bnc_>
andrewrk, the x86_64-windows-gnu zig-cc target is cygwin ?
<andrewrk>
sh4rm4^bnc_, the libc that it provides is based on mingw-w64
<andrewrk>
however it is ABI compatible with MSVC (but not always .h file compatible)
<sh4rm4^bnc_>
based on, means it's like an improved fork of ?
<g-w1>
with the std.zig.ast api, how can I get the length of a token? I want tree.source[tree.firstToken(node) .. tree.lastToken(node) + len] to get the full source of a node. is this possible?
<sh4rm4^bnc_>
because last time i checkout mingw-w64 it was utterly broken...
<sh4rm4^bnc_>
like declaring int mkdir(char*)
<g-w1>
ah figured out, just use the last token, but + 1 so its the start of the next token
<sh4rm4^bnc_>
yeah, that looks like what my mkdir-using program choked on
<sh4rm4^bnc_>
it lacks the mode parameter
<noam>
Since stage2 doesn't yet support this so I can't steal^W*take inspiration* from it regarding field allocation: does it make sense to treat each field as its own variable in terms of e.g. regalloc?
<andrewrk>
sh4rm4^bnc_, it looks deprecated, are you sure it's ok to call it?
<sh4rm4^bnc_>
man 3p mkdir says nothing about deprecated (posix 2013 manpages)
<andrewrk>
g-w1, have a look at ast.Tree.tokenSlice if you haven't seen it yet
<g-w1>
thats only for one token, I want a whole node, but I figured it out
<andrewrk>
oh I see you want a whole node
<g-w1>
i just did lastToken + 1
<andrewrk>
that works because we terminate with an EOF so you can always do +1 from a non-EOF token
<g-w1>
ok cool
<andrewrk>
you might get unwanted line comments tho
<g-w1>
its mostly for fields of structs and global variables
<waleee-cl>
sh4rm4^bnc_: file modes doesn't exist on windows? Or have I missed something
<andrewrk>
sh4rm4^bnc_, might be worth having a chat with the #mingw-w64 folks (on OFTC). they might have a good reason for the way it is
marler8997 has joined #zig
<sh4rm4^bnc_>
waleee-cl, i dunno, but mingw is supposed to provide a posix compat layer
<andrewrk>
also I haven't double checked that msvc libc does it differently, have you?
brzg has quit [Quit: leaving]
<sh4rm4^bnc_>
i just tried to compile my posix compatible program with mingw, and found it wasnt compatible at all
<sh4rm4^bnc_>
it == mingw
<andrewrk>
mingw is not a posix compatibility layer
<andrewrk>
it's trying to match msvc
Miaourt has quit [Quit: Ping timeout (120 seconds)]
<andrewrk>
put an #ifdef windows in your code
Miaourt has joined #zig
<andrewrk>
IMO posix compatibility layer is misguided. better to have conditional compilation and use appropriate windows APIs on windows
<daurnimator>
as andrewrk said, mingw is not meant to be posix compatible...
<daurnimator>
IIRC they only added enough posix to get autoconf to work out of the box
<sh4rm4^bnc_>
lol
<daurnimator>
andrewrk: mingw isn't trying to match MSVC directly, IIRC they add plenty more on top
<andrewrk>
anyway it's a completely reasonable libc, and I agree with the decision to not try to be a posix compatibility layer
<sh4rm4^bnc_>
alright, i was just curious whether the version used by zig is somehow improved or uses midipix, or cygwin, or whatever
sm2n_ has joined #zig
sm2n has quit [Ping timeout: 252 seconds]
<andrewrk>
zig's is unpatched mingw-w64
<sh4rm4^bnc_>
unrelated: i recently found https://www.gnu.org/software/lightning/ and i immediately figured this would make like a perfect multi-arch backend for a compiler (was thinking about cproc)
<sh4rm4^bnc_>
what's the backend approach for the new llvm-less zig compiler ?
<sh4rm4^bnc_>
ah cool, so it should be faster than gcc -O0
<andrewrk>
there is a liveness analysis too so it can re-use dead registers
<andrewrk>
that is surprising to me. I thought the cpu cache would make register allocation not very important
<sh4rm4^bnc_>
the guy who wrote that article is vladimir makarov, who does the really hard work on GCC, he also wrote a scripting lang called dino that's a lot faster than even lua
fireglow has quit [Quit: Gnothi seauton; Veritas vos liberabit]
<mikdusan>
if I grok correct, dino switched to "direct threaded code" (labels as values) because > 256 instructions
<andrewrk>
right now in stage2 we got < 256 instructions, and already have that proper switch setup, so looks like we can just sit tight
<andrewrk>
that's what I was showing off in the meeting today
osa1_ has joined #zig
osa1 has quit [Ping timeout: 248 seconds]
fireglow has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
forgot-password has quit [Ping timeout: 245 seconds]
xackus_ has joined #zig
xackus has quit [Ping timeout: 276 seconds]
notzmv has joined #zig
wootehfoot has quit [Quit: Leaving]
adsr has joined #zig
earnestly has quit [Ping timeout: 258 seconds]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<andrewrk>
g-w1, check it out, the stage2 test case for compile logs had the wrong source location in master branch but with this branch now it's fixed (see latest commit, the changes to the test case)
<g-w1>
i saw that :)
<g-w1>
oh even more?
<andrewrk>
yeah I don't think we noticed this one before but the source location was bogus
<g-w1>
nice
<g-w1>
i think my next thing will be @intToError and @errorToInt, because those require some special casing in the cbe that will cause subtle bugs. those are safe to work on with lazy analysis right?
Biolunar has quit [Ping timeout: 240 seconds]
Biolunar has joined #zig
<andrewrk>
g-w1, what about this strategy? have `#define zig_error_int_<name> <number>` for every error, and the C backend simply populates this on flush()
<andrewrk>
so every incremental compilation it would have to write the whole list of error names / numbers with #defines, but it means the other code could stay unmodified even if error numbers get changed
squeek502 has joined #zig
sm2n_ is now known as sm2n
<andrewrk>
some fun code I just added to rvalue for the `ty` enum value: https://zigbin.io/f43853
waleee-cl has quit [Quit: Connection closed for inactivity]
tefter has quit [Quit: WeeChat 3.1]
zuyoutoki has joined #zig
cole-h has joined #zig
leon-p has joined #zig
zuyoutoki has quit [Ping timeout: 240 seconds]
RadekCh has joined #zig
frett27 has joined #zig
tnorth_ has joined #zig
sord937 has joined #zig
Rum has quit [Quit: Leaving]
l1x has quit [Ping timeout: 240 seconds]
dputtick has quit [Ping timeout: 258 seconds]
l1x has joined #zig
dputtick has joined #zig
earnestly has joined #zig
yyp has joined #zig
osa1_ is now known as osa1
lemmi has joined #zig
frett27 has quit [Ping timeout: 240 seconds]
sord937 has quit [Remote host closed the connection]
sord937 has joined #zig
notzmv has quit [Read error: Connection reset by peer]
sundbp has joined #zig
ksynwa has left #zig [#zig]
semarie has joined #zig
dyeplexer has joined #zig
cole-h has quit [Ping timeout: 240 seconds]
<ifreund>
andrewrk: yeah, it really did turn out to be a strict improvement in the end I think :)
<ifreund>
andrewrk: I thought slices don't have a well defined memory layout, is @bitCast([]Inst.Ref, raw_slice) really safe?
<ifreund>
I think a pointer cast would be more correct
notzmv has joined #zig
<ifreund>
I'm working on astgen for slicing by the way
WilhelmVonWeiner has joined #zig
forgot-password has joined #zig
RadekCh has quit [Quit: Connection closed]
tadzik has joined #zig
<tadzik>
hello #zig!
<tadzik>
I've tried building https://github.com/andrewrk/tetris on Linux, using zig 0.7.1. The `zig build` fails with `ld.lld: error: unable to find library -lglfw` (same for epoxy)`. The libraries are present in my system, and my C programs linking with glfw compile and run just fine. How can I investigate what I'm missing?
<g-w1>
andrewrk │ [23:53:04] g-w1, what about this strategy? have `#define zig_error_int_<name> <number>` for every error, and the C backend simply populates this on flush() andrewrk: see https://github.com/ziglang/zig/pull/7934#discussion_r585047632. there is a subtle off by one error if you are not careful
dyeplexer has quit [Ping timeout: 260 seconds]
<cepheus>
tadzik: I have toy examples that work successfully against GLFW in my case, but i'm linking against GLFW3 in my case
<cepheus>
can't comment on epoxy though
<tadzik>
cepheus: yeah, it's glfw3 for me too, but for the linker it seems to be -glfw anyway
<cepheus>
if you specifically do GLFW3 i think it should be able to find it via pkg-config which resolve the issues (if that's set up correctly)
<tadzik>
I'm not sure if epoxy is relevant here, it just seems like my zig can't quite link to the C stuff that clang does just fine
<cepheus>
(it's case sensitive I think)
<tadzik>
pkg-config --libs glfw3 gives me -lglfw as expected
<cepheus>
hmm
<cepheus>
I'm also building these under nix which is probably not representative of the typical case
<tadzik>
possibly
<cepheus>
I'll see how this builds under my env just to check
<tadzik>
I could try linking something more trivial in a more minimal case, like `-lm` for cmath, if I knew how to write and build any zig myself :P But I thought I'd start by looking at comparing's someone's Zig and comparing it to my C
<tadzik>
ugh, english had. s/comparing's//
<cepheus>
yeah it's weird
<cepheus>
asides changing that glfw to glfw3 for my system it works fine and runs on my system
<cepheus>
sorry that's not very helpful
<tadzik>
no worries, thanks anyway :)
<tadzik>
interestingly (or maybe not), even if I change glfw to glfw3 in build.zig, it still tries to link against -lglfw
Snaffu has joined #zig
zuyoutoki has joined #zig
WilhelmVonWeiner has quit [Quit: leaving]
WilhelmVonWeiner has joined #zig
zuyoutok1 has joined #zig
<v0idify>
tadzik, that's because it's just the pkg-config name
<v0idify>
andrew uses nix so it should work
zuyoutok1 has left #zig [#zig]
<tadzik>
nodnod
v0idify has quit [Ping timeout: 240 seconds]
v0idify has joined #zig
euantorano has joined #zig
stromberg has joined #zig
<gracefu>
what's the status on safe recursion? issue 1006 says the accepted proposal is to use async calls, but isn't async already a thing? why is issue 1006 still open?
<andrewrk>
ifreund, I think we actually uncovered a design flaw here - a pointer cast will assert the pointer is not 0, but in the case of a slice with .ptr = undefined, len = 0, this will trip. but we don't want a pointless len check
<andrewrk>
so my reasoning here is (and I apologize for not putting this in a comment) this bitcast does generate correct llvm code with stage1, and as the language finalizes it either needs to keep being a valid construct or start being a compile error, so we should be ok until either of those things happen
<andrewrk>
does that make sense? (regarding the ptr cast / bitcast on slice)
<ifreund>
andrewrk: sounds reasonable, I'd vote to make @ptrCast() work on slices and do the right thing
<ifreund>
(from a language design standpoint)
<ifreund>
or well, I guess we can implement that in userland no?
<g-w1>
yeah, but then the errors are different at comptime and non-comptime
<g-w1>
comptime is 0, non-compitme is 1
<g-w1>
so we have to account for that
<andrewrk>
I don't follow
<g-w1>
comptime @errorToInt(e) -> 0 (stored in module), runtime @errorToInt(e) -> 0, but now it is off because 0 is the value for no error so we get ub
<g-w1>
so we have to add 1 if its runtime in the cbe right?
<andrewrk>
you can never get 0 from @errorToInt on an error set type
<g-w1>
hmm, why?
<andrewrk>
because 0 is reserved for "not an error"
<g-w1>
is there docs for that?
<ifreund>
each error name across the entire compilation gets assigned an unsigned integer greater than 0
<ifreund>
(from the langref)
<g-w1>
ohhhh thanks
<g-w1>
sorry for the invoncvience
<andrewrk>
no prob
<andrewrk>
did that answer the question? because I'm still confused
<g-w1>
it answered it. then there is a small cbe bug that i introduced :(. I will fix it when I do errorToInt and intToError
<andrewrk>
ahh ok no worries
<g-w1>
there should be no +1 there right?
<andrewrk>
yeah probably global_error_set should have the u16 value match exactly right? so there will be no 0 value in global_error_set
<g-w1>
yeah
<g-w1>
that confused me, not sure if it starts at 1 or 0
<andrewrk>
we just skip 0 so that you can convert from an error set type to an error union type with a no-op
<g-w1>
yeah
<g-w1>
ok cool, thanks
<andrewrk>
in machine code, anyerror!void is represented the same as anyerror
fputs has quit [Quit: WeeChat 3.1]
leon-p has quit [Quit: leaving]
semarie has quit [Quit: WeeChat 3.0.1]
semarie has joined #zig
<g-w1>
is the only way to store an int in a Value a bigint, u64 or i64?
yyp has quit [Quit: now it's safe to turn off your computer]
bitmapper has joined #zig
<ifreund>
g-w1: yup
<g-w1>
ok
<dimenus>
is it expected that stage-2 doesn't require @as(usize, 42) to coerce to a usize?
<dimenus>
where as stage-1 does
<g-w1>
depends the context
<dimenus>
inline asm in this case
<g-w1>
in in the inline asm syntax specifically?
<g-w1>
not sure, but generally stage2 is better with this type of stuff
<dimenus>
i would assume that's intended
<dimenus>
assuming comptime_int fits
waleee-cl has joined #zig
<ifreund>
dimenus: yep that's right
<g-w1>
no, i think stage2 inline asm syntax is just not complete
<ifreund>
line 3020
<g-w1>
for (inputs) |*name| {name.* = sema.code.nullTerminatedString(sema.code.extra[extra_i]); extra_i += 1;} this is how it handles inputs
<ifreund>
the result location has type usize, so the @as(usize, foo) is implicit
<g-w1>
is a BigInt as simple as a slice of usizes?
<ifreund>
stage2 is just better than stage1 at this stuff already
<g-w1>
like to make one is it just &.{1}?
<g-w1>
or is it way more complicated :P
<ifreund>
if you want to make 1, use the i64/u64
<g-w1>
what about a u16 (doing errorToInt)?
<g-w1>
i assume still u64
<ifreund>
and yeah, i'm pretty sure it's more complicated
<g-w1>
ok lol
<ifreund>
see std/math/big/int.zig
<marijnfs>
is it fine to remove from an arraylist in a loop?
<ifreund>
marijnfs: the remove operations don't reallocate so I don't see why not... are you seeing a crash or something?
<g-w1>
do you mean while looping over with `for (arr.items) |item|`?
<marijnfs>
g-w1: indeed like that
<marijnfs>
ifreund: i wonder if the for loop in that case jumps over the last item perhaps and crashes
<marijnfs>
say you are at the last item, and delete it. The 'end' of the array is behind you which is a problem if you say use c++ like iterators
<ifreund>
marijnfs: oh if you're doing that not it's not "safe"
<ifreund>
a for loop will only terminate naturally after iterating the full length the slice was when iteration started
<ifreund>
use a while loop here
frett27 has quit [Ping timeout: 240 seconds]
notzmv has quit [Ping timeout: 240 seconds]
sundbp has quit [Ping timeout: 240 seconds]
aerona has joined #zig
<g-w1>
hmm, for @intToError, it needs to reverse-index a hashmap. it has the number, but needs the string which is in a string -> number hashmap. what is the best way to deal with this?
<ifreund>
well you can have a parallel number-> string hashmap if you need lookups to be fast in both directions
<ifreund>
or you can just iterate the first hashmap if you dont
riba has joined #zig
paulgrmn has quit [Ping timeout: 252 seconds]
<g-w1>
do you think it warrants a parralell hash map?
<g-w1>
the only case I can think of is @intToError at comptime
<ifreund>
I'd say no unless profiling shows that its an issue
<g-w1>
ok, ill put in a TODO
marijnfs has quit [Ping timeout: 240 seconds]
<ifreund>
I don't think it warrants a TODO, I doubt anyone will use @intToError enough for it to become an issue
<g-w1>
ok
sord937 has quit [Quit: sord937]
cole-h has quit [Ping timeout: 265 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
<noam>
Is it too late to try to sway #678 away from acceptance?
<noam>
IMO, neither example in the OP should be allowed
skuzzymiglet has quit [Read error: Connection reset by peer]
squeek502 has quit [Remote host closed the connection]
reductum has joined #zig
<g-w1>
seems like it :P. but also you shouldn't return in a noreturn function :)
<g-w1>
probably a bug in Sema
<dimenus>
i know, i was expecting it to not compile :)
<dimenus>
it was a typo that I thought i'd report
<g-w1>
nice yeah
<g-w1>
seems to be a bug in Sema.analyzeRet
<noam>
Huh - that wouldn't even make it to sema in zyg :)
<noam>
... though upon testing it appears I forgot to even support operand-less returns lol
<ifreund>
noam: why would anything before sema be smart enough to catch a return in an noreturn function?
<dimenus>
ifreund: can you explain something to me re astgen.zig:438-472?
<dimenus>
why is the lhs a usize rl?
<dimenus>
ptr?
<noam>
ifreund: type analysis is separate from semantic analysis in zyg
<noam>
There's a dedicated pass to analyzing type information, validating that types are correct, and so on
<ifreund>
noam: that sounds like a strange choice for a language with first class types at comptime
<noam>
The type analysis can invoke the comptime engine where it needs to
<noam>
Which, in turn, can invoke semantic analysis :P
<ifreund>
dimenus: that would be because I was being stupid, will fix :D
<noam>
ifreund: the decision was made purely from a readability standpoint
<noam>
The compiler is designed to be as painless to maintain as possible, even if it comes at the expense of performance
<noam>
(of itself, not of generated code)
<ifreund>
noam: it seems to me you've just divided semantic analysis up into a few sub steps
<noam>
Sorta?
<noam>
Type analysis doesn't really understand *semantics*, just *types*
<noam>
It knows a tiny bit - e.g. the result of a call type is the rettype of the called function, which should be checked against the type of the parent expression (e.g. in an assignment, a var)
<noam>
ifreund: that's *technically* accurate, and it can be a decent way of thinking about it
<ifreund>
dimenus: fixed, thanks for catching that :)
<noam>
Maybe "type semantics analysis" is a good way of thinking about it
<ifreund>
noam: which is my point and why I took issue with "Huh - that wouldn't even make it to sema in zyg :)"
<noam>
whereas what i've been calling sema is more "executional semantic analysis"
* noam
nods in agreement
<noam>
I'll rename it later :P
<noam>
maybe sema/{types,insns,usage} or something like that
<noam>
Usage analysis depends on understanding of lazy analysis, which is a semantic feature of Zig, for instance
<dimenus>
ifreund: np, i'm working my way up to useful contributions in stage-2 :)
<dimenus>
that fix makes hello world work with slices
<dimenus>
fg
<ifreund>
oh I really should have added a test case
Akuli has quit [Quit: Leaving]
<ifreund>
dimenus: what hello world with slices did you get working? I hit a TODO in sema
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<dimenus>
ifreund: i'm dumb, it was a ptr to an array. len just auto-derefed so i got confused
<dimenus>
i incorrectly assumed that the string was a slice, not a pointer to an array
<dimenus>
when i sliced the array, i got through to codegen though instead of failling in sema
<dimenus>
fg
<dimenus>
damnit, sorry
<ifreund>
ah, no worries
<dimenus>
fg
<dimenus>
alright i'm done with irc for now
<dimenus>
hah
<noam>
You're never done with IRC. It's a matter of when IRC is done with *you*