<pixelherodev>
so 8,16,32 are guaranteed to be there?
<pixelherodev>
Going to add a quick note to 875 about this
<alexnask[m]>
Let me double check the standard, this was from some website with no paragraph citations
tundrax has quit [Ping timeout: 245 seconds]
<alexnask[m]>
These types are optional. However, if an implementation provides integer types with
<alexnask[m]>
two’s complement representation, it shall define the corresponding typedef names.
<alexnask[m]>
widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a
<alexnask[m]>
Okay, this is more reasonable than I remembered
<pixelherodev>
I think my ideal solution here for 875 was laid out by andrewrk in the early PR: `c_char is exactly the same as u8, except for the purposes of generating .h files, in which case it generates char instead of unsigned char`
<fengb>
Wait so char signedness is implementation defined?
<alexnask[m]>
yes
<tdeo>
char is actually unsigned on arm
<pixelherodev>
Hmm, this is interesting
<pixelherodev>
Both `{un,}signed char ... = 'a'` work
<pixelherodev>
But not for pointers
<pixelherodev>
char implicit-casts to both signed char and unsigned char, but char * doesn't cast to either {un,}signed char*
<alexnask[m]>
pixelherodev: characters not in the extended character set can always be stored in char
<pixelherodev>
?
<pixelherodev>
Regardless of the value, a character literal's type should be `char`
<pixelherodev>
Perhaps a better example: `char a = 'l';unsigned char b = a; signed char c = a;`
<alexnask[m]>
An object declared as type char is large enough to store any member of the basic
<alexnask[m]>
execution character set. If a member of the basic execution character set is stored in a
<alexnask[m]>
char object, its value is guaranteed to be nonnegative.
<pixelherodev>
daurnimator: does that patchset work, if I apply it locally?
<pixelherodev>
:P
<pixelherodev>
I'd probably be willing to deal with all the issues therein if it means not having to wait for it
<pixelherodev>
The alternative is to restructure the library to use some sort of value stack
<pixelherodev>
e.g. a dynamic array; instead of `a(a1,a2,a3...aN)` it'd be `push(a1);push(a2);...push(aN);a();`
<pixelherodev>
tdeo: ping
<pixelherodev>
I think I'll deal with value stack for now :(
<pixelherodev>
Ooh, or, arrays?
<pixelherodev>
I've been using *tuples* Zig-side, but I suppose if I pass the array with explicit length, I can construct a slice which should work with the anytype-based impl anyways
<pixelherodev>
The real problem then is figuring out the target function's type - since I can't pass that in the way I do with Zig :(
<pixelherodev>
I can just remove safety :(
<pixelherodev>
The only reason the type is needed is to assert that the given inputs match what the function expects
ur5us has quit [Ping timeout: 240 seconds]
mmohammadi9812 has joined #zig
a_chou has quit [Remote host closed the connection]
ur5us has joined #zig
ave_7 has joined #zig
ave_ has quit [Ping timeout: 264 seconds]
ave_7 is now known as ave_
flokli has quit [Ping timeout: 260 seconds]
flokli has joined #zig
bgiannan has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
Miaourt has joined #zig
ur5us has joined #zig
mmohammadi9812 has quit [Quit: I quit (╯°□°）╯︵ ┻━┻]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
xackus_ has quit [Quit: Leaving]
xackus has joined #zig
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
<andrewrk>
I'm finally done with #6250. It's just fixing regressions and getting the CI passing now
<bfredl>
the binary patch thing is intensively crazy (and useful for debug reiterate : )
<bfredl>
I would like to rewrite parts of neovim into zig "one day"
<andrewrk>
once the language & std lib has stabilized a bit I think it would be very practical to do that a little bit at a time
<bfredl>
and patch the editor in which i edit the editors current source code in real time
<bfredl>
(just to try it, and see how it feels)
<andrewrk>
woah
<andrewrk>
that's hardcore haha
<bfredl>
probably not for "real work"
<bfredl>
but i want to experience the experience, like once or twice
<andrewrk>
I definitely need to take a few days off after this lands but I'm looking forward to a fun stream soon where we try to implement hot code swapping :D
<bfredl>
mm. When I'm "done" with all the things i have promised to write in c for neovim already, i will engage "project zig-nvim"
<mq32>
andrewrk: looking forward for the stream already! :D
<mq32>
this is gonna be great
<andrewrk>
mq32, one thing I haven't figured out yet, is how will you trigger the hot swap?
<andrewrk>
e.g. if it's `zig run --watch foo.zig` then the foo program is controlling the terminal
<andrewrk>
we could do it automatically on file system changes, but (1) don't have that std lib code yet, and (2) I don't think that's the best way to do it, you might get into a weird state that you never intended to
<andrewrk>
e.g. maybe you wanted to hot swap 2 edits to 2 different files at the same time
<mq32>
andrewrk: what about signals/ipc?
<andrewrk>
that's not very cross platform
<mq32>
true
<mq32>
or a socket
<andrewrk>
one idea I had was a simple tcp protocol, yeah
<andrewrk>
even a web page interface to the compiler, heh
<mq32>
i would've just used UDP
<mq32>
as it's local anyway
<andrewrk>
idk maybe it could be useful to display some kind of graphical information of the running program
<bfredl>
I would like an API function
<bfredl>
the program itself can call
<andrewrk>
that makes sense too
<bfredl>
like, I love how ASAN exports an _asan* API
<bfredl>
that we can use in debug code
<andrewrk>
so we'd have a comptime bool that is whether you're running in hot swap mode
<bfredl>
to do cool debug stuff
<mq32>
std.builtin.is_hotswap_enabled
<andrewrk>
@hotSwapNow()
<bfredl>
like "asan plz don't crash my program, but describe this address for me"
<mq32>
"press f5 to recompile the game engine"
<bfredl>
f4 to enter zig REPL
<bfredl>
(one can dream right)
<andrewrk>
it should be pretty straightforward to have a comptime repl
<andrewrk>
a runtime repl is basically gdb
<bfredl>
yea i know
<bfredl>
i keep forgetting sometimes that zig is a "simple" language in the good senses of the word
<bfredl>
like how any c debugger can be a c repl
<bfredl>
(but not every c++ debugger is a c++ repl)
mokafolio has quit [Quit: Bye Bye!]
mmohammadi9812 has joined #zig
mokafolio has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
mokafolio has quit [Quit: Bye Bye!]
xackus has quit [Ping timeout: 264 seconds]
ur5us has joined #zig
marnix has quit [Remote host closed the connection]
marnix has joined #zig
Michcioperz has quit [Quit: No Ping reply in 180 seconds.]
Michcioperz has joined #zig
omglasers2 has joined #zig
mokafolio has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
dddddd has quit [Ping timeout: 256 seconds]
dddddd has joined #zig
marnix has quit [Ping timeout: 258 seconds]
marnix has joined #zig
jjsullivan has quit [Ping timeout: 240 seconds]
mmohammadi9812 has quit [Quit: I quit (╯°□°）╯︵ ┻━┻]
<WilhelmVonWeiner>
Is the multiline string syntax ever going to change?
<WilhelmVonWeiner>
prefixing everything with // is inane, kind of.
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
<mq32>
heya
<mq32>
WilhelmVonWeiner: which editor are you using? i find it quite convenient with vscode and i assume vi/emacs people also can prefix multiple lines easily
<WilhelmVonWeiner>
I can "do it" easy (I use vis) but it's harder to read and notable extra work
<WilhelmVonWeiner>
notable being, you really notice it
<mkchan>
imo it's easier by far (vim user opinion)
<WilhelmVonWeiner>
easier than not prefixing lines with anything?
<WilhelmVonWeiner>
I can see why it is like that, looking at the source though, now
<mkchan>
/* */ is very bad if you just happen to not have code highlighting, if you're trying to grep or if you're trying to parse
<WilhelmVonWeiner>
I don't have syntax highlighting either but that's got to be exceedingly rare
<mkchan>
oh yeah, but it's rooted in the same problem => needing more context about the code
<mq32>
WilhelmVonWeiner: yeah, the prefix is required to make zig line-tokenizable
<mq32>
which is a very good property for all tooling
<earnestly>
It also prevents the accidents which have happened due to block comments and why Ada was designed without them, primarily so
<m4r35n357>
I already have arbitrary precision via MPFR in my program, so I don't think soft float will be any improvement. Oh well
<mq32>
f128 is only comptime-supported atm as well i think
<m4r35n357>
mq32, thanks again, looks like the best I can do HW-wise is still 80 bit long doubles in c on x86
<pixelherodev>
daurnimator: good job with the naming for fifo.pump - I used something stupid like Fused Append-extract (FAE) when I was doing my kernel work lol.
<pixelherodev>
Is the LLVM dependency comptime optional for stage2 now?
<pixelherodev>
Wait, don't answer that; it's about time I look through that branch anyways
ifreund has quit [Ping timeout: 260 seconds]
ifreund has joined #zig
<pixelherodev>
Woot, we don't need to build stage1 in-repo to work on stage2 anymore!!
<pixelherodev>
To be fair, I cheated my way around that too :P
<pixelherodev>
but now I just needed a one-line build.zig change :D
layneson has joined #zig
ifreund has quit [Ping timeout: 240 seconds]
FireFox317 has joined #zig
layneson has quit [Ping timeout: 258 seconds]
FireFox317 has quit [Client Quit]
FireFox317 has joined #zig
<justin_smith>
re: "a runtime repl is basically gdb", I think this means that we could write extensions (in guile? maybe other languages can hook in?) to compile expressions via zig in program context and send them to gdb (eg. to use zig pointer / printing ops in the debugger)
<justin_smith>
my experience with gdb most recently is it's a great repl for assembly, until I need to worry about weird c-isms that my assembly code doesn't care about
<justin_smith>
also I know nothing about lldb, but maybe that offers features / flexibility for a language using llvm that are better than gdb?
a_chou has joined #zig
ifreund has joined #zig
<justin_smith>
bfredl: my experience with editing low level elisp in emacs was that it was exciting at first, but I quickly ended up running emacs in two profiles, one stable one using none of my uncommitted code, and an unstable one reflecting the latest changes to the repo
<justin_smith>
I've switched to nvim since then which is an improvement IMHO, but I think the "turning your own editor into dogfood as you use it" issue is universal
GrooveStomp has quit [Quit: Quit]
a_chou has quit [Ping timeout: 265 seconds]
cole-h has joined #zig
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
leah2 has joined #zig
a_chou has joined #zig
Akuli has joined #zig
a_chou has quit [Remote host closed the connection]
a_chou has joined #zig
daurnimator has quit [Ping timeout: 260 seconds]
tines9 has quit [Ping timeout: 260 seconds]
ncon has quit [Ping timeout: 272 seconds]
m4r35n357 has quit [Quit: Ex-Chat]
karrick has quit [Ping timeout: 240 seconds]
r0bby has quit [Ping timeout: 240 seconds]
tracernz has quit [Ping timeout: 240 seconds]
nikita` has quit [Ping timeout: 240 seconds]
procnto has quit [Ping timeout: 240 seconds]
rzezeski has quit [Ping timeout: 260 seconds]
euantorano has quit [Ping timeout: 256 seconds]
betawaffle has quit [Ping timeout: 260 seconds]
yrashk has quit [Ping timeout: 272 seconds]
JimRM has quit [Ping timeout: 260 seconds]
lqd has quit [Ping timeout: 240 seconds]
eddyb[legacy] has quit [Ping timeout: 246 seconds]
jzelinskie has quit [Ping timeout: 240 seconds]
guan has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Ping timeout: 246 seconds]
gonz_ has quit [Ping timeout: 258 seconds]
wjlroe has quit [Ping timeout: 240 seconds]
ovf has quit [Ping timeout: 260 seconds]
Cynthia has quit [Ping timeout: 260 seconds]
kwilczynski has quit [Ping timeout: 260 seconds]
daurnimator has joined #zig
ncon has joined #zig
tines9 has joined #zig
euantorano has joined #zig
tracernz has joined #zig
nikita` has joined #zig
waleee-cl has joined #zig
kwilczynski has joined #zig
jzelinskie has joined #zig
r0bby has joined #zig
wjlroe has joined #zig
yrashk has joined #zig
eddyb[legacy] has joined #zig
karrick has joined #zig
guan has joined #zig
Cynthia has joined #zig
lqd has joined #zig
JimRM has joined #zig
gonz_ has joined #zig
rzezeski has joined #zig
betawaffle has joined #zig
ovf has joined #zig
procnto has joined #zig
<bfredl>
justin_smith: tell me about it
<bfredl>
i'm trying to dogfood a neovim master crash r n
<bfredl>
but I cannot cause the crash
<justin_smith>
bfredl: I wonder if there's a way to attach nvim to a lua program that exercises the app programmatically?
<justin_smith>
that should at least simplify testing that isn't UI layer
<bfredl>
Welll our test suite is exactly that
<bfredl>
Pretty much
<bfredl>
look into unittests if you need to call c functions directly from lua
<bfredl>
(via luajit ffi)
<WilhelmVonWeiner>
So I have slices of the type `*const [n]u8`, how can I define an array to hold these variable length slices? I've tried `[32]*const [*]u8` and `[32]*const [_]u8` but that's basically all my rational actions exhausted
<ifreund>
*const [n]u8 is not a slice, but a pointer to a comptime known number of items
<ifreund>
this number is part of the type and is static
<ifreund>
i.e. it is not present at runtime
<ifreund>
a slice would be a []const u8 which is like a struct with .ptr ant .len fields
<ifreund>
what you want is a [32][]const u8
<ifreund>
[32]*const [*]u8 would be fine too if you don't want to store how long each slice is
<ifreund>
but no, that would be [32][*]const u8
<justin_smith>
bfredl: oh, cool
DarkUranium has quit [Read error: Connection reset by peer]
SimonNa has quit [Remote host closed the connection]
<bfredl>
(didn't know it was for you when i made it tho, but i know now)
<andrewrk>
FireFox317, nice find on the -r stuff. I was hoping to make the optimization later to avoid redundantly linking an object file into an object file but it seems stage1 was relying on that to work correctly
<Nypsie[m]>
In this case it means an anonymous array literal
<Nypsie[m]>
I swear I was lagging!
<cdrubin>
Fanks!
tines9 has joined #zig
daurnimator has joined #zig
<FireFox317>
andrewrk, thanks! I probably forgot to add the most important thing to the PR and that was that the CI was failing because there was a '-SUBSYSTEM' missing on the linker line. But then I found out that LLD was executed with the same object file and i was like, something is not correct here.
<pixelherodev>
... does errorName return a `[:0]u8` or a `[]u8` ?
<pixelherodev>
@errorName*
ncon has joined #zig
<pixelherodev>
Probably best *not* to return an errorName value's pointer to C code
<andrewrk>
FireFox317, for ELF it is possible to "link" object files together into one. the way the cache is organized we are relying on this behavior to potentially copy an object file from the cache to the cwd, for example in the case of `zig build-obj foo.zig`. so it's a bit tricky - do we try to special case single object files, or make the link code detect the situation and do a file copy?
<andrewrk>
I have a note here to open an issue for this. For now I will make it copy the file
<andrewrk>
nikki93, cool demo!
<nikki93>
thx ^_^
mq32 has left #zig ["Leaving"]
mq32 has joined #zig
a_chou has quit [Quit: a_chou]
cCCCCcccccCCc has joined #zig
<FireFox317>
andrewrk, I yeah I see. And since we are just copying files between zig-cache's its not a big problem to just copy
cdrubin has quit [Ping timeout: 245 seconds]
<Nypsie[m]>
nikki93: Cool! Looking forward to further updates :) What's the performance like? I never tried anything like that before so I'm quite curious.
<andrewrk>
FireFox317, thanks for looking into it while I was sleeping 😁
<nikki93>
Nypsie[m]: i have yet to do some benchmarks for zig wasm stuff, but i've done a lot of testing of wasm graphics stuff in c vs. the same in js before, and also vs. the same in native
<nikki93>
ultimately right now, to call to the 'system' like webgl or dom, you have to go through JS, so if your codepath is mostly those kinds of calls you don't gain much
<Nypsie[m]>
Makes sense
<FireFox317>
andrewrk, haha no problem, it was fun to have a tour through the code. Really wanted the fix the CI, but it wasn't clear to me what the best solution would be xd
<nikki93>
the main gains you get are -- you get control over data layout and can avoid GC stuff, if most of your logic is in wasm
<andrewrk>
nikki93, how much of a penalty is there for the js engine being able to optimize across the boundary between js and wasm?
<andrewrk>
e.g. is the jit able to figure out your wasm functions should directly interact with the gl functions, or do you think there is still a detour through js?
<nikki93>
andrewrk: that's a good q. right now a lot of the gl calls have to do stuff like wrap in a Uint8Array, because the webgl api is very js-oriented
<nikki93>
and idk the extent to which that gets inlined when it's jited, would have to look it up
<andrewrk>
I want to see more browser API exposed to wasm!
<andrewrk>
I feel like status quo is very half-assed
<companion_cube>
it is, even though it's amazing that it even got that far
<nikki93>
yeah. i wonder if they'll bring some graphics stuff into 'wasi' or whether webgpu would have direct wasm bindings etc.
<pixelherodev>
... I mean, TBH, I want to see *less* of it :P
<pixelherodev>
WASM is neat, but I'd rather *remove* pieces from browsers than add *more* to them
* pixelherodev
doesn't have a web browser installed currently and would like to keep it that way
<nikki93>
i think wasm isn't necessarily just about browsers too. eg.; it could be a good way to introduced a sandboxed env into a native app where you load code remotely, whether to update your own logic or to provide users the ability to customize parts of the app
<cCCCCcccccCCc>
nikki93: Exactly what I use it for at work. RE: sandboxing scripts in a native app.
<andrewrk>
pixelherodev, I see wasm as an opportunity to remove complexity from browsers
<andrewrk>
I was writing a browser from scratch, I'd rather only support wasm than support js
<pixelherodev>
andrewrk: I would *love* to believe that Google would accept that :P
<pixelherodev>
I completely agree
<pixelherodev>
I just don't think either is feasible anyways
<andrewrk>
yeah I don't think that will actually happen in practice though, we'll just get more cruft on top of cruft
<pixelherodev>
That's exactly my point :P
<andrewrk>
shame though, there is a missed opportunity there
<companion_cube>
I mean, you can always write bare-metal frontend apps
<companion_cube>
as in, vanilla JS
<companion_cube>
so fast!
<pixelherodev>
If I thought for a second that they (Google, and thus Mozilla) would ever actually do it, I would love it
<pixelherodev>
But, it'll *never* happen
<pixelherodev>
Google won't do that, and Mozilla doesn't do anything that would upset Google because Mozilla seems to think their only way to survive is to bow to Google's every whim
<andrewrk>
I think it's important to keep the amount of effort/labor it would take to create a browser from scratch low. otherwise we will end up with some orgs such as Google with too much power
<pixelherodev>
Sure, but it's kinda too late for that
<andrewrk>
with the recent Mozilla layoffs we are more in danger than ever
<pixelherodev>
*Microsoft* gave up.
<pixelherodev>
*Microsoft*.
<andrewrk>
I have an idea to save the web
<pixelherodev>
I'll just not bother with a web browser anymore. I'll stick to the Geminispace :P
<pixelherodev>
andrewrk: let's hear it!
<nikki93>
i think mobile is an opportunity to make new environments for interactions. i don't think we've done as much as we can with touch and media stuff in web
<andrewrk>
it's a redesigning of www that goes in the completely opposite direction of "semantic web" and more in the direction of "a browser is a thin layer to manage untrusted apps and give them selective permissions to do things on your computer"
<andrewrk>
it would be well designed enough to actually run AAA games on your computer. but the user would be in more control of what perms the app had
<andrewrk>
no html, no js, no css. that's all in userland
<companion_cube>
just a wasm VM
<companion_cube>
to run chrome inside
<companion_cube>
;)
layneson has joined #zig
<andrewrk>
yeah you would actually be able to run a traditional web browser inside this system
<pixelherodev>
andrewrk: maybe once Zig hits 1.0, that can be the ZSF's next big project: saving the web!
<pixelherodev>
... LLVM still makes me nervous, to change the topic entirely
<andrewrk>
this is what I wrote yesterday: WTF!!! I am debugging a deadlock and it is caused by llvm intercepting std.ChildProcess calling exit(1) in the fork child after failing to execve
<andrewrk>
I feel violated. I did not give consent for LLVM to fondle my exit() code
<pixelherodev>
"LLVM emit output..." Me: Oh god it's in another infinite loop
<pixelherodev>
Woot! Got tricarbon working with C code :D
<pixelherodev>
and, now that I'm not using stdio for debugging, a stripped build is *130KiB*
SimonNa has joined #zig
ur5us has joined #zig
eddyb[legacy]_ has joined #zig
eddyb[legacy] has quit [Ping timeout: 260 seconds]
eddyb[legacy]_ is now known as eddyb[legacy]
FireFox317 has quit [Ping timeout: 240 seconds]
<nikki93>
if i use zig's reflective features to auto-generate UI to edit instances of a struct, what would be a good place to attach 'metadata' to members? for example if i wanted to add a 'min' and 'max' for some member that uses a slider control
<companion_cube>
I'm not sure, but maybe `const` fields in the struct?
<companion_cube>
(although, right, how do you attach to a particular member…)
<andrewrk>
I can't remember did we add syntax for this yet? struct { a: i32, comptime b: i32 = 123, }
<andrewrk>
that's the type you get for .{.a = runtime_i32_value, .b = 123}
<nikki93>
companion_cube: maybe i'd just name it the same as the field with some suffix or prefix and i could check if such a "meta" field exists?
<nikki93>
would such const / comptime fields add to the size of struct instances?
<andrewrk>
no
<nikki93>
cool
<andrewrk>
and you can't change the value
<companion_cube>
there's an argument to be made for attributes, though, they're quite clean
<companion_cube>
(typically one also turns docstrings into an attribute)
<mq32>
i'm not sure if i want to allow docstring introspection in comptime
<mq32>
would have some nice applications (attributes, automatic documentation generation, …), but i can see the wilderness spreading
<companion_cube>
why not, if one can introspect types and expressions?
<companion_cube>
comptime is already the hammer tool
<andrewrk>
mq32, I'm pretty sure to not allow it, so that when you read code, you never have to have that little thought worm in the back of your head, wondering if someone did something crazy
<mq32>
yeah, exactly that's my argument against it as well
<andrewrk>
or worse, wondering if yourself did something crazy a long time ago :D
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
or worrying that adding a doc string will possibly break something
<andrewrk>
part of the features of zig is what is *not* possible
<companion_cube>
you'd still have to explicitely call some comptime code, right?
* pixelherodev
yanks out ethernet cord because I need to grab food but I'm not 100% sure I'll be able to get back in the building afterwards so I need to have my stuff :P
<mq32>
huh
<mq32>
i get a process.h not found, but i'm linking libc and it's included in include/any-windows-any/process.h
<andrewrk>
mq32, --verbose-cc will show the flags
<mq32>
what on earth is zig doing?! :D
<mq32>
linkSystemLibrary does not what i thought it does when crosscompiling
<mq32>
is pkg-config supposed to run for cross-builds?
layneson has quit [Ping timeout: 265 seconds]
<justin_smith>
bfredl: hah, fun, I almost get what's going on there
<bfredl>
Mm I will clean it up
<bfredl>
Add some docs
<mq32>
andrewrk: maybe i'm just horribly stupid and didn't set the target on the libexeobjstep *facepalm*
<andrewrk>
mq32, it just means we need better introspection & debugging tools when such errors occur :)
<mq32>
hmm *thinking*
<mq32>
well, i found out with --verbose-cc
<mq32>
and i wondered why -target was x86_64-linux-gnu and not x86_64-windows-gnu :D
<andrewrk>
in this case, when "file not found" errors come from C compilation, a helpful diagnostic would be to print the C header include search path, in order
<mq32>
true
wootehfoot has joined #zig
<mq32>
btw: can you explain why the cache for c files will only succeed to cache everything when the build succeeded once?
<mq32>
it's a weird behaviour
<justin_smith>
mq32: is it related to the granularity of build.zig target definitions?
<mq32>
no, this should also happen when using zig build-exe
<mq32>
maybe … it will just not happen anymore tomorrow or this week
<mq32>
:D
<mq32>
#6250… sooon
mmohammadi9812 has quit [Quit: I quit (╯°□°）╯︵ ┻━┻]
<mq32>
it's compiling!
Akuli has quit [Quit: Leaving]
mq32 is now known as iksku
iksku is now known as ikskuh
marnix has quit [Ping timeout: 260 seconds]
Biolunar has quit [Quit: leaving]
Biolunar has joined #zig
<ky0ko_>
is the c++ based compiler still going to be supported after the self-hosting compiler is mature?
<ky0ko_>
one of the biggest issues i have with languages like rust is that it's impossible to bootstrap them on e.g. netbsd/macppc without external assistance
<ky0ko_>
and i don't want to end up having the same issues with zig
<ifreund>
ky0ko_: the current plan for long term bootstrapping is to use the C backend of the self hosted compiler to compile the complier to C
<ifreund>
before 1.0 this generated code will be cleaned up and made maintainable
<ky0ko>
is the c++ based zig compiler going to remain supported even after the self hosting compiler is mature
<ifreund>
(as generated source doesn't count for bootstrapping)
<andrewrk>
mq32 6250 improves that behavior with regards to finer grained caching
<ky0ko_>
oops, looks like the message from my matrix bridge actually sent lol
<andrewrk>
ky0ko, building zig directly from c++ code will continue to be supported forever. there is a proposal to temporarily make that c++ code generated rather than hand-maintained for a period of time in between now and 1.0
<ikskuh>
andrewrk: good to hear. i'm currently in a process where i have to wait through 52 files getting successfully compiled to see linker errors
<andrewrk>
ah yes that is exactly the situation this addresses
<ky0ko_>
okay, thanks for assuaging my fears andrewrk. as long as there's always a route from having only gcc to having zig i'm happy
<ikskuh>
and i don't really understand why it happens
<ky0ko_>
i haven't, no
<andrewrk>
ah yeah microsoft's dllimport name mangling scheme is really confusing
<ikskuh>
any idea how to work around that?
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
I don't remember enough details, sorry
<ikskuh>
no worries
<andrewrk>
I'm not sure I ever fully understood
<ikskuh>
making lib names lowercase seems okay
<ikskuh>
*facepalm* :D
<andrewrk>
o.O
<ikskuh>
yep
<nikki93>
among the wasm experiments i want to just do a thin wrapper around http://google.github.io/incremental-dom/ -- then if you call these per frame you essentially get an immediate mode ui api over dom (i already do this in c++ and it works fine :o )
<ikskuh>
uuuuh neat
<nikki93>
you just need to bind elementOpenStart, attr, elementOpenEnd, elementClose and text
<andrewrk>
nikki93, that seems convenient from writing code perspective, but I worry that it will be slow, do you have any knowledge on this?
<nikki93>
i actually use this basically from c++/wasm for an editor tool for a game engine right now. i benchmarked like 1000 counters and buttons and it was fine.
<andrewrk>
asking for my music player project which has a dom element per artist/album/song which can be quite a few
<nikki93>
in profiles the bottleneck was actual DOM calls when diffs occur, rather than the diffing code and wasm code itsel fhaha
<andrewrk>
neat!
<andrewrk>
oh I see
<nikki93>
what that ^ lib does is, compares what you're telling it right now to the existing DOM, and if something changed, updates the DOM. if nothing changed it's quite fast. it also doesn't generate much/any JS objects / garbage i believe
<ikskuh>
andrewrk: it linked!
<nikki93>
the next step above that is to completely keep a buffer in zig that you keep diffing against and only call out to JS/DOM when things change from there
<andrewrk>
makes sense
<nikki93>
andrewrk: can only really say by trying it out and benchmarking, i'll post here when if/when i get to that in zig :)
<andrewrk>
I think what I have now is at the theoretical best possible perf, but it's written in js not zig
<nikki93>
cool! would be cool to do a benchmark that does something like that with mock data
<andrewrk>
I think this is provably the best possible perf, because it's essentially what the dom diff thing will end up doing, but without the diffing step
<andrewrk>
it's not very maintainable tho, that's the downside
FireFox317 has joined #zig
<FireFox317>
andrewrk, anything i can help you on with #6250? I have a linux and a windows box with zig
<nikki93>
yeah pretty much. i think it's possible to work with an approach where you code with such an immediate mode / diff style thing generally but then once you notice where the bottlenecks are, just write that stuff manually in this style
<andrewrk>
FireFox317, yeah! let me push a commit I just finished and let's see what's left
<FireFox317>
okay neat!
<FireFox317>
actually building zig was as easy as before, so great that process did not change :D
<FireFox317>
in the #6250 branch i mean
<andrewrk>
FireFox317, pushed! I'm not aware of any more issues, let's find out what breaks!
eddyb[legacy] has quit [Ping timeout: 240 seconds]
<FireFox317>
andrewrk, great! Will run the tests locally too
dch has quit [Ping timeout: 240 seconds]
tracernz has quit [Ping timeout: 240 seconds]
JimRM has quit [Ping timeout: 240 seconds]
nikita` has quit [Ping timeout: 260 seconds]
euantorano has quit [Ping timeout: 240 seconds]
<andrewrk>
oh looks like I need to do a master branch merge too
ovf has quit [Ping timeout: 260 seconds]
gonz_ has quit [Ping timeout: 260 seconds]
rzezeski has quit [Ping timeout: 260 seconds]
procnto has quit [Ping timeout: 260 seconds]
yrashk has quit [Ping timeout: 272 seconds]
<andrewrk>
oh, no conflicts. I'm not sure what's up with github
ur5us has quit [Ping timeout: 260 seconds]
betawaffle has quit [Ping timeout: 260 seconds]
jzelinskie has quit [Ping timeout: 240 seconds]
<FireFox317>
andrewrk, and then disable the windows test that failed i think?
r0bby has quit [Ping timeout: 260 seconds]
<andrewrk>
which one? I'm not familiar with what you're talking about
<FireFox317>
#6452
JimRM has joined #zig
procnto has joined #zig
r0bby has joined #zig
gonz_ has joined #zig
<andrewrk>
oh! that's a master branch issue. I was hoping to resolve that right now
tracernz has joined #zig
dch has joined #zig
yrashk has joined #zig
ovf has joined #zig
jzelinskie has joined #zig
rzezeski has joined #zig
nikita` has joined #zig
euantorano has joined #zig
<FireFox317>
andrewrk, ah great! yeah so merging master into the stage2 branch will stall on #6452
eddyb[legacy] has joined #zig
<FireFox317>
eventually
betawaffle has joined #zig
<andrewrk>
if we can get it down to just windows with this run I will be ecstatic
<andrewrk>
I'm setting up to run the tests locally on windows & macos as well
<andrewrk>
it's pretty amazing how far I could get with testing using only cross compiling
<FireFox317>
yeah that's really amazing! i think this CI pass will get us quite close
xackus has quit [Ping timeout: 256 seconds]
<FireFox317>
andrewrk, well on my linux box `test-behavior` run fine cross-compiling everything :P just gonna check test-std now, but that will probably be fine too. Great work man! So awesome
<andrewrk>
thanks :)
<andrewrk>
just so other people who aren't paying as much attention are aware, this is not zig being fully self-hosted yet. but it is reducing the amount of c++ we depend on by 16,000 lines
<FireFox317>
I have a good feeling today is gonna be your day :)
jjsullivan has joined #zig
<FireFox317>
Unfortunately it is getting pretty late in europe, hopefully will be a nice wakeup tomorrow :P goodnight!
<andrewrk>
good night! thanks for the help
<FireFox317>
std tests passed to btw
<andrewrk>
\o/
<FireFox317>
yw!
xackus has joined #zig
<nikki93>
does the new toolchain with in-place binary patching factor into wasm too or will wasm still be just llvm?
<andrewrk>
yep, wasm too thanks to ifreund
<nikki93>
<3
<ifreund>
wasm's not technically in place since the object format is much more restrictive than elf
<ifreund>
instead we store incrementally compiled code in memory and rewrite the whole output file from the in-memory buffers
<pixelherodev>
Ah wait, I'm expecting sane decisions from it :P
<andrewrk>
I think that would have been a reasonable decision
<ifreund>
it is possible to do it in place for wasm, and this is what I did at first, but it grew very complex with even a very incomplete implementation
<andrewrk>
yeah I think the strategy you landed on is quite reasonable
<pixelherodev>
I think wasm itself is a good idea done poorly, which will only make the browser situation *worse*
<ifreund>
I've just finished my last exam of the summer semester today, so now I can get back to my zig projects
<ifreund>
including the wasm backend, I need to learn how to to codegen
<andrewrk>
good timing, hopefully today is the day I merge 6250
<ifreund>
also going to take a course on compiler theory this semester so that should be fun
<nikki93>
the compilers class in college when i took it happened to use llvm :o
<nikki93>
they had used ML for all semesters till the one when i took it
<fengb>
wasm was designed for streaming and incremental parsing
<fengb>
I'm not sure how important the latter part is since the bottleneck is IO
ur5us has joined #zig
omglasers2 has quit [Read error: Connection reset by peer]
xackus has quit [Ping timeout: 264 seconds]
ur5us has quit [Ping timeout: 260 seconds]
jjsullivan has quit [Remote host closed the connection]
jjsullivan has joined #zig
FireFox317 has quit [Ping timeout: 258 seconds]
<andrewrk>
ifreund, it would be really convenient with the way I have the caching system set up if wasm "objects" had different file extension from "executables"
<andrewrk>
I'm thinking about doing ".o.wasm" for objects
<andrewrk>
does that seem ok?
<andrewrk>
same Q to fengb
<andrewrk>
oh shit, green check for freebsd on 6250
<andrewrk>
and arm
<ifreund>
hmm, I feel like what would make the most sense would be to use just .wasm for objects and drop the extension for executeables
<ifreund>
I'm not sure what the conventions are though
<andrewrk>
do web developers expect to fetch("foo.wasm") ?
<fengb>
Convention is to have extension of wasm
<ifreund>
the only reall wasm executables are the wasi stuff run by wasmtime
<fengb>
I think wabt compiles .wat files into .wasm
<ifreund>
yes that's right
<fengb>
Oh I dunno about wasi
<andrewrk>
if you saw "foo.o.wasm" would you be like, "that's reasonable for zig to do that"
<andrewrk>
?
<fengb>
I’m also not sure what a wasm object file is
<ifreund>
i think it's just a wasm file?
<andrewrk>
it's a relocatable one though
<andrewrk>
there is a difference
<andrewrk>
wasm-ld: error: zig-cache/o/88f7371333119da331487a0d4ba5701a/test.wasm: not a relocatable wasm file
<andrewrk>
just got this error because test.wasm (object) got linked into test.wasm (executable) overwriting the cache
<andrewrk>
so the next run tried to link the test.wasm (executable) and received that error
<fengb>
Since it’s non standard, I’d be fine with having .o.wasm
<andrewrk>
" In order to distinguish object files from executable WebAssembly modules the linker can check for the presence of the "linking" custom section which must exist in all object files."
<andrewrk>
yeah so my idea would (1) still have the .wasm extension (2) also provide the extra info that it is relocatable without having to read the file data