<mikdusan>
also that issue you mentioned a day (days?) back re: alpine and `zig cc` with a shared library... I feel that's a bug with zig right now.
marijnfs_ has quit [Quit: Lost terminal]
klltkr has quit [Ping timeout: 260 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 256 seconds]
ur5us has joined #zig
nephele_ has joined #zig
nephele has quit [Ping timeout: 272 seconds]
nephele_ is now known as nephele
aerona has joined #zig
shodan45 has quit [Quit: No Ping reply in 180 seconds.]
<fengb>
Is it weird that I'm enjoying manually converting LLVM voodoo into Javascript?
notjones has quit [Ping timeout: 256 seconds]
urluck has quit [Remote host closed the connection]
urluck_ has joined #zig
urluck_ is now known as urluck
xackus_ has joined #zig
xackus has quit [Ping timeout: 256 seconds]
hryx has quit [Ping timeout: 265 seconds]
wootehfoot has quit [Ping timeout: 264 seconds]
foobles has joined #zig
<foobles>
hey everyone
<mikdusan>
hey foobles
v64 has joined #zig
<foobles>
:D
<foobles>
ok i (re) implemented it at comptime and it's much better now
<foobles>
and also does what the proposal says :v
<mikdusan>
so being that there is only 2 possible actions (?T compare T) and (T compare ?T) where `T` is not literal null, then the only runtime work needed is branchless, and just issue an unwrap?
<foobles>
how is it not branchless?
<foobles>
if null => not equal
<foobles>
else => unwrap and comare
<mikdusan>
are you adding a runtime branch?
<mikdusan>
what I mean is... let's compare to runtime functionality today. that would be runtime(T compare T)
<mikdusan>
after implemented this feature, does it become (runtime(unwrap(exactly 1 operand), runtime(T compare T))
<mikdusan>
[this struff is tricky to word]
<daurnimator>
fengb: don't forget your asm.js derived optimizations
<daurnimator>
fengb: e.g. start your functions with `a = a|0` to declare it as type i32
<daurnimator>
and don't forget my favourite: `a = a <<< 0` -> cast to a u32
juliansniff has joined #zig
xackus_ has quit [Ping timeout: 256 seconds]
<fengb>
I thought most browsers gave up on asmjs annotations
<foobles>
mikdusan yes
<foobles>
andrew said `??T == T` should not compile
<daurnimator>
fengb: I don't think so? got a source on that?
<foobles>
only unwrap once
<daurnimator>
fengb: I recall some browser didn't care about the "use asm" statement and applied optimizations no matter where it saw `|0` etc.
<mikdusan>
foobles: yup that simplifies things
<foobles>
my code is pretty simple
<foobles>
wait
<foobles>
how do you do it without branching?
<mikdusan>
is your fork stil up?
<foobles>
i made a new one :p
<foobles>
let me send it
<foobles>
one thing I know I forgot to do was check if it's an error union
waleee-cl has quit [Quit: Connection closed for inactivity]
<foobles>
mikdusan uuuh "this is a bug in the zig compiler" hehe
<foobles>
i just made it unreachable ATM
<foobles>
so it is WIP
<foobles>
but not comptime
<mikdusan>
so for comptime impl, I see no longer using ir_analyze_optional_value_payload_value ?
<foobles>
yeah, i realized it was unnecessary
v64 has left #zig ["WeeChat 1.9.1"]
<foobles>
since the only reason I wasn't directly accessing x_optional was because it might be a pointer
<foobles>
*optional pointer
<foobles>
but I make sure that it isnt before the function is called
<foobles>
so i know that it is the correct place to look
<foobles>
although, like I said, I also need to check if it's an error union
<mikdusan>
when using ir_analyze_optional_value_payload_value did you need to check for error union?
<foobles>
it does that on its own :p
<foobles>
i believe
<mikdusan>
and it probably does more things you won't realize are needed until your tests are expanded
<mikdusan>
my point is, I think you had good instincts to use that fn
<mikdusan>
but the proof would be with more test cases
<foobles>
yeah, maybe
<foobles>
i guess i did that because I wanted a ZigValue
<foobles>
but i could just unwrap -> ir_resolve_const -> zigvalue
<foobles>
yeah, thank you! im not sure why i didn't do that :P
<foobles>
i use that emoji too much
<mikdusan>
right, so let's say that takes care of comptime business.
<mikdusan>
now onto runtime
<mikdusan>
let's see if this makes sense. I recall that just like in comptime, we can't use ir_analyze_optional_value_payload_value when it's a pointer. was that the gist if "attempt to use null" error?
<foobles>
I think the issue was that you werent checking for null at all
<foobles>
you need to insert a branch
<daurnimator>
fengb: I think that's for the "use asm" block having effect. the whole point of asm.js though is that its just JS if the browser doesn't support it
<foobles>
which isnt possible in phase 2 directly, so andrew said to make some kind of new node with a special ir_render function :D
<foobles>
fun fun fun
<mikdusan>
foobles: to clarify I was not checking for null literal in the runtime section
<fengb>
Yeah I know. But I’ve heard very little commitment from Chrome and even less from Safari
<mikdusan>
oh wait, so if it's null literal, that would make it a comptime operand.
<fengb>
I can’t find the post but the Chrome team wanting to focus on general use cases and not asmjs
<foobles>
null literals are handled by some of the special cases that already exist
<foobles>
but if its a runtime null
<foobles>
you werent checking
<fengb>
And then news went dark after everyone hopped on the wasm bandwagon
<mikdusan>
i was checking for _both_ to go into comptime section. but this was with the "erroneous assumption of feature bloat"
<foobles>
aah
<daurnimator>
fengb: when in doubt... benchmark :)
<foobles>
but yeah, in the runtime section, you just checked if it was an optional type, and if it was, you unwrapped it
<foobles>
i think we definitely need some new type of node
<daurnimator>
fengb: however, note that e.g. `<<< 0` is the only way to cast nicely to u32: it's not only an annotation like `|0` is.
<fengb>
I really wish I could try vectorizing
<foobles>
or at least a new type of IrBinOp to render differently
<mikdusan>
foobles: bear with me, and I could very well just be blind here,
<mikdusan>
foobles: let's assume case (?T == T) and LHS/RHS are runtime
<daurnimator>
fengb: avoid `const` in JS
<daurnimator>
it has a ~3% performance impact....
<fengb>
There’s no difference
<daurnimator>
your overheads may be elsewhere
<mikdusan>
foobles: so today (T == T) handles all the quirks. but what it doesn't handle is a runtime null value
<foobles>
yeah
<daurnimator>
fengb: also use hex literals for at least a little readbility :P
<fengb>
And I don’t mean the const line. The magic numbers are some random LLVM voodoo that I don’t understand
<fengb>
It might as well be Greek
<daurnimator>
fengb: oh also note that if you're using a minifier it might be undoing your optimisations
<mikdusan>
foobles: ok so let me just quickly review regular ir_analyze_bin_op_cmp
<fengb>
Hmm I benchmarked unminified but you might be right here
<daurnimator>
fengb: 255 == 0xff.... 31744 == 0x7C00... you might see why its not greek after al
<mikdusan>
foobles: yeah I agree, for case where an operand is runtime(?T) we need a runtime branch :(
<foobles>
horaaaay
<foobles>
i will try doing some of that tonight
juliansniff has quit [Remote host closed the connection]
<mikdusan>
I think a while ago I tried to add branches in analysis and all hell broke loose
<foobles>
heh, yeah
<foobles>
wait ok: so here is the issue with branches afaik:
<foobles>
-in phase 2 you cannot modify control flow. thats all in phase 1
aerona has quit [Quit: Leaving]
<foobles>
-types are only known in phase 2
<foobles>
-we are trying to add control flow based on types
<foobles>
maybe we can create temporary IrInstSrc-s?
<foobles>
and then analyze them on the spot
<daurnimator>
mikdusan: what do you mean a runtime null value?
<mikdusan>
daurnimator: if (?T == null) and ?T is runtime
<daurnimator>
mikdusan: the Null type only has a single possible value (null): how could the value not be runtime-known?
<daurnimator>
mikdusan: ah.
<foobles>
mikdusan is that feasable do you think?
<foobles>
im going to try it
<foobles>
ah wait a second, that isnt going to work :(
<foobles>
you can't get the IrInstSrc from an IrInstGen
<foobles>
so its impossible to do like `ir_build_bin_op`, since you need the IrInstSrc of op1 and op2
<mikdusan>
foobles: "cannot modify control flow" let's harden that definition; is it that we have to maintain a 1:1 basic_block relationship between pass1 and pass2 ?
<foobles>
ahh thanks
<mikdusan>
hey I'm asking, not telling :P
<foobles>
oh, i dont know
<foobles>
:d
<foobles>
i am not completely sure what a basic_block is actually
<mikdusan>
and then this Q. aren't there examples of pass2 eliding blocks because of comptime eval ?
<mikdusan>
so I hope I got this correct: if we maintain 1:1 relationship, then we have analysis to elide a block; thus one possible solution from the frontend (as opposed to the backend codegen),
<mikdusan>
is we insert a maybe-use block for the branch
<foobles>
when you say "analysis" is that phase 1?
<mikdusan>
analysis=2
<foobles>
that could be a solution
<foobles>
andrew has not been online on this chat in days O_O
<mikdusan>
so then analysis of the cmp instruction must guarantee to elide the basic_block if we're not doing ?T == T
<foobles>
yeah that might work
<mikdusan>
foobles: he's busy on a coding frenzy I bet
<foobles>
heh yeah
<mikdusan>
if what I'm thinking is possible, then should be able to find some code example of how to elide a branch in analysis. if not, I'm all hot-air
<mikdusan>
the other thing is like you were suggesting early on- create a temporary IrInstSrc. and THAT is what gets elided.
StateOff__ has quit [Remote host closed the connection]
<foobles>
ill look into how if-blocks are handled
<mikdusan>
summary: we're basically talking about inserting a new maybe-elide-cond-br for purposes of decaying T
Invader_Bork has joined #zig
<mikdusan>
and the home for that cond-br would be... what.. IrInstSrcBinOp ? new field `IrInstSrc *unwrap_operand`
<mikdusan>
the breakdown there is, to which operand
dddddd has quit [Ping timeout: 256 seconds]
squeek502 has joined #zig
squeek_ has quit [Ping timeout: 256 seconds]
cole-h has quit [Quit: Goodbye]
Invader_Bork has quit [Quit: Leaving]
ur5us has quit [Ping timeout: 272 seconds]
foobles has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
wootehfoot has joined #zig
TheLemonMan has joined #zig
dermetfan has joined #zig
marijnfs has joined #zig
fsx_ is now known as FSX
FSX has quit [Quit: WeeChat 2.7]
FSX has joined #zig
marijnfs1 has joined #zig
marijnfs has quit [Ping timeout: 265 seconds]
ur5us has quit [Ping timeout: 256 seconds]
ifreund has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 256 seconds]
_Vi has joined #zig
marijnfs_ has joined #zig
marijnfs1 has quit [Ping timeout: 256 seconds]
<ikskuh>
übrigens, lustige Sache mit C++Builder/RAD-Studi
<ikskuh>
*Studio
<ikskuh>
man kann per remote desktop nicht die scrollleisten verwenden
<BaroqueLarouche>
ikskuh: Je comprends rien! Je parle pas Allemand 😁
<ikskuh>
:D
<fengb>
Ich bin ein berliner
<BaroqueLarouche>
Wir sind die roboter
<ikskuh>
thanks for the earworm, BaroqueLarouche
<BaroqueLarouche>
Kraftwerk <3
mschwaig has quit [Ping timeout: 256 seconds]
xackus_ has joined #zig
<nephele>
is "zig run start.zig" expected to be semantically the same as "zig build-exe start.zig; ./start"? Asking since i expected it to be, and was printing std.fs.selfExePath but got a directory somewhere in my cache in my homedir
<ikskuh>
nephele: the idea is that zig run foo doesn't create an executable
<ikskuh>
but as you require an executable, it's stored in the zig-cache
<nephele>
ah Okay, that doesn't quite match my expectation of what a run command would do :)
<ikskuh>
how so?
<ikskuh>
it runs the content of the zig file
<nephele>
I would expect it to create the executable and run it
<ikskuh>
you didn't say you want an executable file, but you said yu want to run it ;)
<nephele>
That to me means "create the executable file AND run it", seeing as how you said, i do require an executable
<ikskuh>
yeah, but i would also expect a "run source" to delete the exe afterwards
<nephele>
I suppose both choices work in certain usecases, i'm just used to another one
<nephele>
even if that was the case it doesn't do that
<ikskuh>
yeah, as zig caches everything else atm
<nephele>
maybe it needs a build-exe-run target :P
<fengb>
We should just comptime evaluate it and bypass the executable altogether >_>
<nephele>
That atleast won't help my expectations :P
riba has joined #zig
svipal has joined #zig
<svipal>
hello.
<companion_cube>
world!
<svipal>
trying to use zig on windows, using glfw as a c lib. I get this message when compiling with ` zig build-exe test.zig --library c -I/d/dev/glfw/include -L/d/Dev/glfw -lglfw3` :
<companion_cube>
there's a `/d/Dev` in the -L, is that wanted?
<BaroqueLarouche>
looks like you need a special define in GLFW to change the DLL export macro
<svipal>
it's wanted, I'm specifying where the .lib file is.
<svipal>
ok, I'm not too c-savvy
<svipal>
how would that work ?
<BaroqueLarouche>
@cDefine("GLFW_DLL", ""); before your @cImport
Biolunar has joined #zig
<BaroqueLarouche>
in your
<BaroqueLarouche>
@cImport before @cInclude sorry
dermetfan has quit [Ping timeout: 272 seconds]
riba has quit [Ping timeout: 265 seconds]
<svipal>
how so ?
<svipal>
I've been using @cImport(@cInclude("GLFW/glfw3.h"));
<svipal>
how do I stuff it in ? :')
<svipal>
ok found it in the doc
<svipal>
tried a few times, didn't get the right syntax from instinct
<svipal>
still get the same error
cole-h has joined #zig
<svipal>
I can try from anotehr angle, is there any way to tell zig to look for .a mingw64 files instead of .lib ?
<svipal>
I have a healthy mingw64 installation
<BaroqueLarouche>
ohhh you're using mingw64 not msvc
<BaroqueLarouche>
try passing -target native-windows-gnu to build-exe
<BaroqueLarouche>
dunno if it will work
<BaroqueLarouche>
but at least it will use the same libc
<svipal>
yeah works
<svipal>
nice and labi
<svipal>
thanks
FireFox317 has joined #zig
<svipal>
Okay, very cool
<svipal>
haha guess I was too fast now it builds it
<svipal>
and then at the end of the build gives me the error
<svipal>
will try building zig from source
sanaris has joined #zig
waleee-cl has joined #zig
wootehfoot has quit [Quit: Leaving]
Biolunar has quit [Quit: leaving]
<yrashk>
is there any way to define functions on structures that make their definitions effectively mutually-dependent? https://zig.godbolt.org/z/vhey52 am I missing something obvious?
<yrashk>
the only way I found so far is to do something like this https://zig.godbolt.org/z/R9sBZA -- but not sure if it is a particularly good way to do so
<nephele>
does a Z after a function in std just mean that it accepts a null terminated string slice?
<nephele>
or should it also return one?
<ikskuh>
nephele: it usually has a only a Z paramter
<ikskuh>
returning something mit Z would require mutation or allocation
<nephele>
Okay, so i should do that myself afterwards?
shodan45 has joined #zig
<ikskuh>
yeah probably
<ikskuh>
or you just look what the functions return
<ikskuh>
using std source is usually better than using te online docs
<nephele>
Well, the online docs for std don't work anyway in links2 :P, so i've been using the std source anyway... just not that knowledgeable about zig yet
Akuli has joined #zig
<watzon>
When trying to target WASM I'm getting this error: `error: option '-atomics,-bulk-memory,-exception-handling,-multivalue,-mutable-globals,-nontrapping-fptoint,-sign-ext,-simd128,-tail-call,-unimplemented-simd128' cannot be
svipal has quit [Remote host closed the connection]
donaldallen has joined #zig
<andrewrk>
hmm I thought fengb had a fix for that already
<donaldallen>
I have a zig variable, foo, of type [:0]const u8 that I need to pass to a (C) gtk routine. The type of the parameter in the zig translation of gtk.h is *c_void. So in the call, I pass that argument as &foo[0]. The zig compiler complains:error: cast discards const qualifier.
<donaldallen>
In C, this would be a warning, not an error, and I could fix it with a cast. Any suggestions for how to deal with this in zig?
<donaldallen>
In this situation, the gtk routine is not going to scribble on my string, but the function definition doesn't say that. A bit of sloppiness common in C.
<donaldallen>
I do have a C file as part of this application that has a few utility function that I need to do in C, e.g., setting up gtk callbacks. I *could* define an intermediate function that calls the gtk routine and call that from my zig code. The intermediate would not discard the const and and I could fix the problem in C with a cast.
<donaldallen>
This would be at the expense of an extra function call, but if there's no better way .....
<fengb>
There should be a way to convince Zig to stop passing target features, but you’ll run into other issues like linking with C
<TheLemonMan>
donaldallen, you can drop the const with @intToPtr(*c_void, @ptrToInt(&my_ptr))
<TheLemonMan>
it's not elegant but that's what you get for trying to break the rules
FireFox317 has quit [Quit: Leaving]
<donaldallen>
The word 'elegant' never entered my mind when reading your suggestion :-) But I will try it. Thanks.
<donaldallen>
And I would point out to you that I'm not breaking the rules. gtk is. They defined a function for adding a string to a hashtable. The string will not be written by their stuff, but they don't say it in their function definition.
<andrewrk>
apparently for this one backend, it wants separate -target-feature parameters rather than comma separated
<TheLemonMan>
yeah const in C is a mild suggestion at best
<fengb>
andrewrk: the bigger problem is that we don’t have a wasm libc
<andrewrk>
ah
<andrewrk>
that's what emscripten provides
<fengb>
How difficult would it be to start fleshing out our Zig version?
<andrewrk>
not very difficult. we already have wasm32-freestanding-musl with some string functions
<andrewrk>
you can just add functions that are missing
<fengb>
Ah cool. I might take some time to implement more
<andrewrk>
if it tries to do file system operations, then there's a question of... what did you expect it to do?
<fengb>
At some point, we should have our own ABI right?
<andrewrk>
nah, no need for that
<andrewrk>
at some point, we replace the libc implementations with our own zig code, but keep the ABI the same
<fengb>
I think file ops should not be defined. Only WASI provides a concept of syscalls
<andrewrk>
I think you can probably flesh out the wasm32 libc pretty quickly for your use case
<andrewrk>
chances are it's only using a handful of functions
<fengb>
Wouldn’t that be true of any freestanding though?
<donaldallen>
@TheLemonMan Your suggestion appears to work. At least it compiles. I do feel that I need to take a shower after writing that :-) But thanks again.
<andrewrk>
yes
<ikskuh>
andrewrk: how do i link against the zig-implemented libc?
<andrewrk>
you have been doing it the whole time
<FireFox317>
donaldallen, or convince gtk devs that they should have proper c function definitions
<andrewrk>
ikskuh, it's a matter of how much implementations are shared between the libcs we bundle and the zig impl. right now that amount is not very much
<FireFox317>
declaration*
<ikskuh>
andrewrk: Zig is unable to provide a libc for the chosen target 'arm-freestanding-musl'.
wootehfoot has joined #zig
<ikskuh>
i know that i brought up this topic a day before to 0.6.0 release :D
<TheLemonMan>
donaldallen, hah that's the spirit
<andrewrk>
ikskuh, ok there does need to be an issue for providing c header files for all freestanding targets
<ikskuh>
do we have one already? I'd like to contribute to this
<TheLemonMan>
a libc for freestanding targets?
<andrewrk>
TheLemonMan, yeah all it really needs is mainly the string manipulation functions, and it unlocks the ability to include .c files in freestanding projects
<TheLemonMan>
we already have special/c.zig ?
<andrewrk>
headers
<TheLemonMan>
I'm not sure freestanding targets want headers
<TheLemonMan>
I mean, you don't even have a libc most of the times
<andrewrk>
don't they want to use int32_t etc?
<andrewrk>
oh that's language headers, not libc huh
<andrewrk>
ikskuh, what happens if you don't pass -lc ?
<TheLemonMan>
no, you usually typedef all the intNN_t yourself
<TheLemonMan>
you can always fallback on the c.zig mini-libc if you need some string/math functions
<ikskuh>
andrewrk: It's a build script, but i call linkLibC
<andrewrk>
yeah what happens if you remove linkLibC
<andrewrk>
anyway we're well-positioned to compile c code for freestanding targets. it's just a matter of working out a few of these details
<ikskuh>
well, the C headers won't be found
<andrewrk>
which ones?
* ikskuh
tries to compile a C/C++ project
<ikskuh>
stdlib.h
<andrewrk>
what stdlib.h functions does it depend on
<ikskuh>
/home/felix/software/zig-linux-x86_64-0.6.0+986aa42d3/lib/zig/libcxx/include/math.h includes stdlib
<andrewrk>
TheLemonMan, ^ so here's a use case. we could provide freestanding stdlib.h for all targets no problem and it is implemented by zig's c.zig mini-libc
<andrewrk>
math is a good example
<TheLemonMan>
if only --gen-h worked heh
<andrewrk>
heh yeah
<andrewrk>
that's a good solution once self-hosted is ready
kristoff_it has joined #zig
<andrewrk>
ikskuh, I think you would have success if you hacked up some stuff into the zig compiler. after you get it to work, it will become clear how to organize it
<ikskuh>
context for my project: It's an arm-freestanding demo for an embedded platform that uses glm (OpenGL mathematics library) and other header-only c++ stuff
<ikskuh>
do you have me an entry point or something?
<andrewrk>
start with finding that error message that you're getting and delete the check so that it doesn't trigger
<shakesoda>
using glm on embedded arm seems a bit mad
<andrewrk>
TheLemonMan, speaking of, did you see https://github.com/ziglang/zig/pull/5130 ? I'm working on direct-to-ELF generation now so we can get some test coverage, then hoping to work with you on an SSAT form & maybe figure out how result locations will work
<ikskuh>
haha okay
<ikskuh>
shakesoda: why? It has a lot of wonderful functions and features
<shakesoda>
like renting a bus to transport your backpack
<ikskuh>
and i'm using it with a custom fixed-point arith instead of float :)
<ikskuh>
so i have vec<3, fixed<16,16>>
<shakesoda>
don't get me wrong, glm is useful
<ikskuh>
which yields damn fast, constexpr-valid code
<TheLemonMan>
andrewrk, yeah I had a quick look, no design docs for the IR?
<shakesoda>
i mostly quit using things like that for how punishing the compile times are though
<shakesoda>
glm isn't the worst offender though, this is an across the board thing
<andrewrk>
TheLemonMan, I could make a design doc if you see that as the next step
<ikskuh>
hey, compile times are totally irellevant when flashing takes 20 minutes :D
<shakesoda>
yuck
<andrewrk>
TheLemonMan, but I do want to play with an SSAT form to understand how it works before knowing what I would put in the design doc regarding control flow
<andrewrk>
my plan was to get something working that felt right, then do the design doc
<shakesoda>
i don't personally live in a world where compile times are ever irrelevant, they are a primary bottleneck to getting things done :(
<shakesoda>
especially since I don't use a fast workstation
<andrewrk>
shakesoda, sounds relevant to the direct-to-elf compilation that I am working on :)
<shakesoda>
andrewrk: absolutely
<ikskuh>
shakesoda: yeah, my laptop is pretty stronk for a mobile workstation
<andrewrk>
anyway, zir design doc is planned, it's just a question of the order of doing things
<TheLemonMan>
andrewrk, my only objection is that a single doc is easier to read than a huge PR :P but some code will work just fine
<ikskuh>
\o/
<TheLemonMan>
going straight from IR to machine code is an interesting decision
<shakesoda>
isn't that a fairly intuitive one?
<andrewrk>
this is for "debug" builds. every symbol is PIC, and there will be a mapping of decl -> set of decls that depend on it
<andrewrk>
every decl will map to a symbol
<andrewrk>
the idea is to figure out only the set of decls to regenerate, and only update those symbols in the elf file. incremental compilation
<ikskuh>
oh crazy
<TheLemonMan>
shakesoda, the intuitive one IMO is to chop the high-level IR into machine-specific block and then pass that low-level IR to the machine-instruction selection pass
<TheLemonMan>
of course you can even go straight from the textual ast to machine code
<ikskuh>
huh. zig doesn't build on arch linux?
<andrewrk>
TheLemonMan, I'm doing the former thing
<TheLemonMan>
but you lose some degrees of flexibility wrt how much analysis you can do on the IR
<ikskuh>
i get linker errors: undefined reference to `clang::driver::getDriverOptTable()'
<ikskuh>
known problem/solution?
<andrewrk>
textual ir -> semantically analyzed ir form -> (optional additional passes, currently none) -> machine code
<TheLemonMan>
andrewrk, so the plan is to transform ZIR to LLVM IR at some point?
<andrewrk>
yes
<FireFox317>
and also regarding multiple targets (x86 - arm) is it an good idea to directly go from semancitcally analyzed ir form -> machine code?
<andrewrk>
eventual plan is that llvm/clang/lld are optional dependencies, which unlock more backends and CLI features (ability to compile C code, @cImport etc)
<companion_cube>
how is ZIR different from, say, QBE?
<andrewrk>
ZIR competes with QBE. ZIR is more bespoke, it's whatever the zig language needs it to be
<shakesoda>
easy: qbe isn't written in zig :D
<companion_cube>
could be a port, that's why I ask
* shakesoda
was just looking at qbe the other hour
<TheLemonMan>
maybe ZIR is a higher-level representation than QBE?
<companion_cube>
I imagine async does have impact on the IR
Xavi92 has joined #zig
<TheLemonMan>
after all we're going to use it during the semantic analisys phase
<andrewrk>
the types and values of ZIR are the types and values of zig
<andrewrk>
oh async is a good point. ZIR is async-function-aware. LLVM IR and QBE are not
<companion_cube>
fair enough, I imagine you have plenty of inspiration from llvm anyway
<andrewrk>
LLVM analysis passes sometimes get stumped by async functions due to limitations of LLVM IR. ZIR analysis passes are not limited by this, and treat async functions the same as functions (as appropriate)
dermetfan has joined #zig
<FireFox317>
TheLemonMan, currently checking how many test fixes pass with D78011 on mips-linux, because without that one quite a lot tests don't pass
<andrewrk>
FireFox317, we can still merge your PR, with those tests disabled (with a link to the zig issue corresponding to D78011)
<TheLemonMan>
FireFox317, cool, I tested with ppc32 and afair the stdlib tests were all fine
<andrewrk>
regarding ZIR, let me iterate on it a bit more and figure out some of these basic questions, such as control flow, multiple architectures, etc and then everybody can look at the design and pick it apart
mattmurr has quit [Ping timeout: 258 seconds]
<andrewrk>
I'm going to have to put it down for a week or two to do these redisconf talks tho
<companion_cube>
waaaa, you go to redisconf?
<andrewrk>
I'm signed up for 2 talks this year
<andrewrk>
unfortunately it's virtual, but at least it means I have full control over the talk video
<andrewrk>
so I can put in sound effects and music! (j/k don't worry kristoff_it)
<companion_cube>
special voice effects? oh boy
<companion_cube>
so basically it'll just be one big twitch session
<andrewrk>
planned, practiced, and edited though. those 3 things make a big difference in quality. my twitch streams are improv
<ifreund>
"Zig & Sharko" are still beating us on duck duck go :(
<fengb>
I don't understand what a block is
<marler8997>
it's what an allocator uses to track it's allocations
<fengb>
But every allocator tends to do it differently
<marler8997>
right
<marler8997>
each allocator defines it's own Block type
<fengb>
I guess I don't understand why there's an abstraction
<marler8997>
the only requirement is that it contains a ptr field
<marler8997>
It allows composability and code reuse
<marler8997>
You can compose any number of block allocator, you can wrap them with a logger, wrapper them with an "aligning" allocator, wrap multiple allocators with a fallback
dermetfan has joined #zig
Jenz has quit [Ping timeout: 265 seconds]
<fengb>
But how is that different from using the current allocator interface?
<fengb>
I don't really get what blocks buy us compared with just slices
<marler8997>
yeah that's a good question to ask
<marler8997>
the first big difference is that this is a compile-time interface rather than a runtime functio pointer interface
mattmurr has joined #zig
<marler8997>
the second is that not all allocators need the same thing
<marler8997>
they all have different memory requirement, they all support different operations, they all have different semantics
<marler8997>
the "block allocator" attempts to capture all the operations an allocator can implement, which allows you to implement efficient abstractions that know exactly how the allocator behaves and how to use it properly
<marler8997>
I've taken some of his ideas, but the actualy implementation I've made is pretty different
tgschultz has joined #zig
<companion_cube>
but surely passing allocators at runtime is even more flexible
<marler8997>
runtime allocators is a subset of compile-time allocators
<marler8997>
I can implement any runtime allocator interface with my compile-time allocator interface under-the-hood
<marler8997>
which is exactly what I did in my PR. I implemented the current allocator interface by composing a few block allocators
<marler8997>
i.e. makeSliceAllocator(makeAligneAllocator(makeMmapAllocator()))
<companion_cube>
I'm not sure I understand why comptime is a superset of runtime
<companion_cube>
what if the choice of allocator is made at runtime?
<marler8997>
instantiating a compile-time allocator is creating a runtime allocator
<fengb>
🤷 I don't really follow what the goal is. I see more operations, but that's more complexity to the implementation
<ikskuh>
marler8997: i don't understand exactly what you're trying to do with the separation of block- and slice allocators
<marler8997>
the "block" level is the low-level view from the allocator's perspective
<ikskuh>
but then i need two layers of mangement
<ikskuh>
one for the blocks
<ikskuh>
and one for the slices
<ikskuh>
→ more memory
<marler8997>
You can use that level to know what the block allocator does, does it track the length? does it support resize in place? Can it deallocate everything at once? etc
tgschultz has quit [Ping timeout: 256 seconds]
<marler8997>
Does it need any extra data per allocation, that's the big one
<fengb>
But... I don't care about most of those, except resize which has a separate proposal / implementation
<marler8997>
This is the information you want to know if you have allocators interacting with each other
<fengb>
I mean, I do but the documentation level seems like a good enough place
<marler8997>
But if you're just an app that wants to use slices, then you don't care about these details
<ikskuh>
marler8997: i still don't see the necessity for two layers of allocation management
<ikskuh>
it's an overhead i don't want to have
<marler8997>
There's no overhead because it's all done at compile time
<ikskuh>
huh?
<marler8997>
That's the beauty of met-programming
<ikskuh>
okay, how i can i comptime-allocate blocks?
<ikskuh>
so
<ikskuh>
all allocBlocks are run at comptime?
<marler8997>
What I mean by comptime is that it's a compile-time defined interface
<marler8997>
it's dynamic at compile-time
tgschultz has joined #zig
<ikskuh>
yes
<marler8997>
sorry did that answer your question?
<ikskuh>
no
<ikskuh>
my problem: for this i need two layers of mangement structures
<ikskuh>
one for blocks
<ikskuh>
one for slices
<marler8997>
actually no
<ikskuh>
why?
<ikskuh>
how does it work then?
<marler8997>
if you're block allocator only needs pointers and lengths, then the SliceAllocator becomes a no-op
<ikskuh>
what do you mean by "needs"?
<ikskuh>
what is a block then?
<companion_cube>
I think it's all in the talk they linked
<marler8997>
"needs" == Block
<companion_cube>
D people do know about comptime :)
<fengb>
Why should I need more than pointer+len?
<marler8997>
The Block type defins what every block allocator needs to track every individual allocation
<marler8997>
For example
<marler8997>
Say you have an allocator that doesn't support alignment
<marler8997>
You can wrap it in an AlignAllocator, which will track both the underlying Block type, and an extra variable to track the length requested by the caller
<marler8997>
Or the SliceAllocator
<marler8997>
which takes a block allocator, but exposes slices
<ikskuh>
are blocks fixed size?
<marler8997>
no
<marler8997>
each allocator defines it's own block
<marler8997>
it can be any size
<ikskuh>
hm
<marler8997>
how this interface came to be was I started with the slice interface, and kept thinking of things that different allocators would need to know about each other
<marler8997>
but this interface was very different from the interface the application cares about
wootehfoot has quit [Ping timeout: 265 seconds]
<ikskuh>
i always think in "i don't have enough memory for everything", so i wonder if this all will use any more memory than a trivial alloc/free interface"
<marler8997>
Nope
<marler8997>
The CAllocator is one of the allocators
<marler8997>
It uses less memory than a runtime allocator
<marler8997>
It has no function pointer to track
<marler8997>
It uses less memory than a runtime interface
<marler8997>
You'll want to start using a runtime interface if you have alot of different allocators and want to avoid generic/template bloat
<marler8997>
var callocator = makeSliceAllocator(CAllocator { })
<marler8997>
with optimization that should literally compile to raw calls to malloc/free with no runtime overhead
<marler8997>
and if you want alignment, you would do: var callocator = makeSliceAllocator(makeAlignAllocator(CAllocator { }))
<ikskuh>
hm
<ikskuh>
this still screams for super-generic functions
<marler8997>
keep in mind, this isn't replacing mem.Allocator
<marler8997>
It would allow us to remove most of the code in "heap.zig" with compile time allocator expressions
<companion_cube>
it better be compatible with Allocator tho
<marler8997>
it is
<companion_cube>
otherwise no one will be able to use it
<marler8997>
I already have it working with mem.Allocator
<marler8997>
and applications can choose whether to use a runtime allocator, or use an allocator directly
<marler8997>
I would expect most applications to create an allocator and use it directly, and for functions to continue to use the runtime allocator interface
<ikskuh>
i'm not happy with the current iostream stuff as well
<TheLemonMan>
andrewrk, wrt #5146 are sentinels on any pointer type but [*] forbidden?
Cynthia has joined #zig
donaldallen has quit [Remote host closed the connection]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<fengb>
Listening to the talk... it's pretty handwavey when it comes to composition. Most allocators that I can think of cannot compose most of these behaviors because there's a lot of subtle edge cases that they need to account for
<marler8997>
yeah definitely
<marler8997>
my interface is much different from him
<marler8997>
I'm working through all the use cases and trying to come up with the best interface, I find that using the "single-responsibility" principle is key, but it's still hard
<fengb>
I'm not sold on standardizing an interface for these details, especially since it's a lot bigger than what we have currently
<marler8997>
We do the best we can, but we also don't need to implement everything
<fengb>
For instance, zee_alloc cannot be broken up at all. I purposely mixed a bunch of operations together and all of them are subtly aware of the internal details
<marler8997>
When I was going through heap.zig, I saw the same functionality implemented over and over again
<companion_cube>
but it's designed to be tiny, right?
<marler8997>
and many implementation had subtle difference and I'm sure I found some bugs
<fengb>
Tiny binary yeah. I had to make concessions somewhere :P
<marler8997>
but rather than having to re-implement the same things over and over, this library allows the same logic to be re-used over and over because everything is composable
<marler8997>
but what's great about this is you can use as much or as little of it as you want
<companion_cube>
comptime composition does sound great
<marler8997>
you pay for what you use
<fengb>
I don't necessarily believe reusing logic should be a goal in itself
<companion_cube>
(same for channels, actually…)
<fengb>
I'm more concerned in the interface complexity
<marler8997>
I find both to be important
<marler8997>
But your interface can be a simple or as complex as you want
<marler8997>
The fail allocator only implements 1 function
<marler8997>
I should say, your implementation can use as much or as little of the interface
<companion_cube>
fengb: writing an allocator can be at least slightly complicated, right?
<companion_cube>
as long as the user has the same simple interface
<yrashk>
not to pull attention away from composable allocators (I think it might be interesting in some cases!), I wanted to show an early preview of a reference-counted shared pointer I did as a toy project. It's not validated yet (I am am working on that)
<fengb>
Yeah I just mean the current interface seems decently enough to do everything I want
<yrashk>
(maybe there's something like this already around? I only found something from 2018)
<fengb>
And I don't really see the need of more composability
<ifreund>
what idioms are people currently using to do multiple returns?
<ifreund>
currently as in zig 0.6.0
<fengb>
Return a struct, or use result pointers
<fengb>
Returning tuples will be here soon™
<marler8997>
fengb: I think you need to take a look at heap.zig, and compare it to alloc.zig
<ifreund>
yeah i'm doing result pointers like I would in C, but am wishing for a more ziggy way
<ifreund>
can't wait for tuple returns
<marler8997>
the mmap allocator in heap.zig is 250 lines of complex runaround code, using a composable interface, the MmapAllocator in alloc.zig is probably 10 lines of code with a handful of functions
<fengb>
I see it but that's not compelling to me
<marler8997>
becaue you don't value code reuse?
<fengb>
It's smaller, but there's this other block allocator thing that I don't really understand now
<marler8997>
did you read the updated doc where I explain?
<fengb>
I don't think code reuse is a goal by itself
<marler8997>
the reason for having a custom Block type is so the storage can be decided by the caller
<marler8997>
for example, maybe you want to use a BlockAllocator directly, you could choose to store the Block on the stack if you want
<fengb>
Oh so it's introducing a different interface style as well?
<marler8997>
The more common reason being that you create an allocator that wraps another allocator, and the wrapping allocator can decide where to store the underlying bloc, making it apart of it's own block or putting it somewhere helse
<marler8997>
interface style?
<fengb>
Yeah, heap.Allocator is an "interface". OutStream is an "interface". This block thing is a different type of "interface"
<marler8997>
yes
<marler8997>
passing blocks back and forth is a different interface than passing slices back and forth
<fengb>
Yes I know that. It's just different from doing @fieldParentPtr that I'm used to
<marler8997>
self: @This()
<fengb>
I think there's a few different concepts you're trying to introduce at once :P
<marler8997>
True
<marler8997>
Coming from a decade of D metaprogramming, this is par for the course :)
<marler8997>
But would seem very weird if you haven't done alot of metaprogramming
<marler8997>
Policy-based metaprogramming, now that's something to learn!
<fengb>
I don't mind having something better. I'm not the biggest fan of @fieldParentPtr but I also don't want to have multiple ways of doing the same thing >_>
<marler8997>
well like I said this is not a replacement
<marler8997>
The runtime allocator interface is still useful, especially if your a function that accepts an allocator
<fengb>
So... SliceAllocator is glue that converts BlockAllocator to mem.Allocator?
<marler8997>
Almost :)
<marler8997>
SliceAllocator is glue for a "slice-based" api
<marler8997>
MemSliceAllocator is glue for converting a SliceAllocator to mem.Allocator
<fengb>
I'm also curious how these apis will look with just the resizeFn change
<marler8997>
it's orthogonal
<marler8997>
related, but this can work with or without the resizeFn change
<marler8997>
the only change would be the MemSliceAllocator implementation
<marler8997>
small change
<marler8997>
because all the allocators re-use the same code to implement the runtime interface, I think this speaks to why a composable interface works so well
<marler8997>
today, all the allocators have to change to support that, with alloc.zig, you only have to change one function
<marler8997>
this means the standard library could change the runtime interface, and all BlockAllocators will continue to work, even application defined ones
<marler8997>
although, if you change the blockallocator interface, then you're still in the same boat....so maybe not a fair critique :)
ur5us has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
layneson has joined #zig
dimenus has joined #zig
<dimenus>
why would zig stick 'std.target.Arch.isWasm' in the binary for a freestanding aarch64 target?
<dimenus>
however, it is stripped out with release-fast
Akuli has quit [Quit: Leaving]
dingenskirchen has quit [Quit: dingenskirchen]
<fengb>
We should rename that to isNotWasm to stop people from asking 🙃
<fengb>
I'm joking. It comes up fairly regularly :P
dermetfan has joined #zig
Xavi92 has quit [Remote host closed the connection]
dingenskirchen has joined #zig
dermetfan has quit [Ping timeout: 256 seconds]
_Vi has quit [Ping timeout: 272 seconds]
FireFox317 has quit [Ping timeout: 264 seconds]
ifreund has quit [Ping timeout: 256 seconds]
marijnfs_ has joined #zig
marijnfs1 has quit [Ping timeout: 260 seconds]
kristoff_it has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 256 seconds]
betawaffle has quit [Ping timeout: 264 seconds]
<foobles>
andrewrk I posted this on github, but i thought I would ask here too: in the `?T == T` proposal, should it be expanded to `?T == U` if T and U are comparable?
<foobles>
like say you had an optional tagged union, and you wanted to comapre it with an enum literal
<foobles>
that doesnt fall under `?T ==/!= T`
ur5us has joined #zig
<Snektron>
You could also choose to split it up into seperate pull requests
<foobles>
ah good point
<foobles>
something cool i did notice though: if you allow comparison of `?T and U` where T and U are comparible, then that naturally allows comparison between ?T and ?T
<foobles>
because then, it breaks it down: I have optional T and a ?T
<foobles>
is T comparable with ?T
<foobles>
?? yes it is
<foobles>
it recurses twice, but its a really nice side-effect
foobles has quit [Remote host closed the connection]
daurnimator has quit [Quit: WeeChat 2.8]
foobles has joined #zig
daurnimator has joined #zig
dimenus|home has joined #zig
dimenus has quit [Read error: Connection reset by peer]