<pixelherodev>
Efficient codegen here might actually require a larger rework
<pixelherodev>
Not certain yet
<pixelherodev>
Woot, getting some frontend stuff done too
<pixelherodev>
`a.zig:5:5: error: TODO implement astGenExpr for While`
stripedpajamas has quit [Quit: sleeping...]
frmdstryr has joined #zig
stripedpajamas has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
marijnfs_ has joined #zig
stripedpajamas has quit [Quit: sleeping...]
marijnfs has quit [Ping timeout: 264 seconds]
frmdstryr has quit [Ping timeout: 258 seconds]
<pixelherodev>
Hmm, I wonder if I can actually implement a while loop currently, using condbr
<shakesoda>
attempt #'s 1-3 at scheduling lots of threads: utter failure, much worse than running it single threaded
<shakesoda>
removed the complicated attempts and went back to the stupidest approach and it's equivalent, so i need to go think about ways to do better
stripedpajamas has joined #zig
adamkowalski has joined #zig
<adamkowalski>
How do I create a [][]const u8 literal?
<adamkowalski>
My first thought was &[_][]const u8{"hello"}
bastienleonard has left #zig ["ERC (IRC client for Emacs 26.3)"]
craigo has quit [Ping timeout: 265 seconds]
adamkowalski has quit [Remote host closed the connection]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<stripedpajamas>
adamkowalski [_][]const u8 { "hello", "world" } works
<fraktor>
hey uh, I'm looking through the zig repo and I glanced at the tools and uh
<pixelherodev>
Things tend to be named according to what they do
<pixelherodev>
At a glance, it parses multiple JSON files, merges them, and dumps the result
<pixelherodev>
andrewrk: why don't we want incremental C compilation, again?
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 258 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 258 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
stripedpajamas has quit [Quit: sleeping...]
Mulugruntz has joined #zig
stripedpajamas has joined #zig
wilsonk has quit [Ping timeout: 264 seconds]
ilmu has quit [Ping timeout: 260 seconds]
Amun_Ra has quit [Ping timeout: 256 seconds]
guan has quit [Ping timeout: 256 seconds]
lqd has quit [Ping timeout: 256 seconds]
cole-h has quit [Quit: Goodbye]
Amun_Ra has joined #zig
lqd has joined #zig
guan has joined #zig
_whitelogger has joined #zig
wilsonk has joined #zig
<andrewrk>
pixelherodev, it would be fine to have, just not necessary
<andrewrk>
I think you asked if it was required and I said no
<andrewrk>
btw I realized the correct way to model the C backend
<andrewrk>
it's an object format.
<andrewrk>
ELF, PE, COFF, MACHO, .c
<daurnimator>
andrewrk: howso?
<daurnimator>
andrewrk: you can pack the same object code into either an ELF or a PE file. ==> its the same machine code. a .c file isn't the same machine code in a different container
<andrewrk>
never mind PE
<andrewrk>
you would only ever pick one from the above enum. each item excludes all the others
<andrewrk>
C source fits in there perfectly
stripedpajamas has quit [Quit: sleeping...]
<daurnimator>
I feel like its closer to an architecture
<daurnimator>
an architecture with subarchitectures (yes I know that we got rid of them) for each C target
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
frett27_ has quit [Ping timeout: 246 seconds]
frett27 has joined #zig
_whitelogger has joined #zig
frett27_ has joined #zig
frett27 has quit [Ping timeout: 240 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 272 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 256 seconds]
craigo has joined #zig
haliucinas has quit [Ping timeout: 256 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
nikita` has joined #zig
dermetfan has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 264 seconds]
wjlroe has joined #zig
frett27 has joined #zig
xackus has joined #zig
frett27_ has quit [Ping timeout: 265 seconds]
ur5us has joined #zig
haliucinas has joined #zig
haliucinas has quit [Read error: Connection reset by peer]
Ekho has quit [Ping timeout: 244 seconds]
haliucinas has joined #zig
haliucinas has quit [Remote host closed the connection]
haliucinas has joined #zig
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
ur5us has quit [Ping timeout: 256 seconds]
Ekho has joined #zig
haliucin1s has joined #zig
haliucinas has quit [Ping timeout: 256 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 258 seconds]
xackus has quit [Ping timeout: 264 seconds]
jaredmm has quit [Quit: Bouncin']
jaredmm has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 264 seconds]
jaredmm has quit [Quit: Bouncin']
jaredmm has joined #zig
_Vi has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
layneson has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 264 seconds]
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 256 seconds]
<frett27>
hi, digging into std, i cant' find a way to open a dir by absolute name ?
<frett27>
where are Dir type factories (i've only found the cwd()) ?
<lemmi>
frett27: i think you need to go through cwd()
<frett27>
seems a dummy question ?
<frett27>
ah ?
<frett27>
so kind of cwd().opendDir("/proc") ?
<lemmi>
i dug through the code and the underlying syscall accepts absolut paths IIRC
<frett27>
lemmi, thank's, let's try, or perhaps passing by fd ?
<lemmi>
and what fd would you use?
<frett27>
openFile -> get the fd then create a Dir struct, using it ?
<frett27>
fd is a file handle from system ?
<lemmi>
sec, need to look this up again
<lemmi>
frett27: yep, you can go through cwd. it's using openat under the hood, so absolute paths are ok
<frett27>
yep, that works, thank's lemmi
<frett27>
i'm able to iterate on /prov
<frett27>
s/v/c/
KoljaKube has joined #zig
frett27_ has joined #zig
frett27 has quit [Ping timeout: 272 seconds]
Patrice_ has joined #zig
frett27_ has quit [Ping timeout: 256 seconds]
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 256 seconds]
Sphax has quit [Read error: Connection reset by peer]
cole-h has joined #zig
<pixelherodev>
andrewrk: isn't that what we're already doing?
<pixelherodev>
I put it next to Elf in link.File on purpose
<pixelherodev>
Ah wait, that's what we're doing *conceptually*
<pixelherodev>
I need to fix up 16-bit ELF support a bit more, then I'll fix that up
marijnfs has joined #zig
cren has joined #zig
marijnfs_ has quit [Ping timeout: 246 seconds]
xackus has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 272 seconds]
dermetfan has quit [Ping timeout: 256 seconds]
cren has quit [Remote host closed the connection]
dingenskirchen has quit [Quit: dingenskirchen]
layneson has quit [Ping timeout: 246 seconds]
dingenskirchen has joined #zig
dingenskirchen has quit [Client Quit]
bastienleonard has joined #zig
dingenskirchen has joined #zig
riba has joined #zig
<pixelherodev>
ZSF announcement is at ~6PM EST, right?
washbear is now known as racoon
<pixelherodev>
Ah wait, time zones are listed on there :)
<leeward>
I think you mean EDT.
<shcv>
how do I cast a slice of u32 to a slice of u8?
<shcv>
I can cast array pointers with ptrCast...
<fengb>
std.mem.sliceAsBytes
layneson has joined #zig
bastienleonard has left #zig ["ERC (IRC client for Emacs 26.3)"]
Mulugruntz has quit [Quit: ZZZzzz…]
<pixelherodev>
leeward: ... does it matter?
<pixelherodev>
Unrelated: how do I access std.log output?
<pixelherodev>
Rather, how do I change the logging level?
<pixelherodev>
I don't see the option
<pixelherodev>
Wait, log level has to be set at comptime???
<pixelherodev>
That's... a serious mistake, IMO.
<shakesoda>
verbose logging can be kind of expensive and bloaty, so i can see why one might do that
<pixelherodev>
Yes but... there's *no method* to allow it to be decided at runtiem
<pixelherodev>
runtime*
<shakesoda>
i usually outright remove verbose logging the instant i don't need what it was spitting out because it can cost so much
<shakesoda>
but i also always write my own loggers
<pixelherodev>
There's *plenty* of situations where I'd want to override the level for a single run
<shakesoda>
i'm a little surprised there even is one in std
<pixelherodev>
and the cost should be negligible, if it's just a single branch
<pixelherodev>
`if (level < current) return`
<shakesoda>
you would be disgusted at the real cost of a single branch sometimes :D
<shakesoda>
but generally one doesn't put logging statements anywhere /that/ sensitive
<pixelherodev>
I seriously hope we eventually find a different style of pipeline which doesn't rely on branch predictions...
<pixelherodev>
Hmm, this is a tangent anyways; the log level should be debug, but I'm not seeing the output
<andrewrk>
pixelherodev, look at the recent changes to test_runner.zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 256 seconds]
<shakesoda>
ugh, this will be better than my previous approach of just spawning way too many threads, but this design for task scheduling is going to have a lot of fighting over locks
<shakesoda>
need to do better
<shakesoda>
at least for now, just doing one better than the previous attempt is good enough
layneson has quit [Ping timeout: 256 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
andrewrk: sure thing, will do soon
<pixelherodev>
Turns out stage2's main was comptime ignoring linking logging
<pixelherodev>
andrewrk: if you have two minutes, how do you want to handle linker scripts?
<pixelherodev>
Going to need to work on supporting them for SPU II (since there's specific ranges of ROM and RAM and not all of the address space is usable)
<pixelherodev>
Ahh, I see
<pixelherodev>
You were referring to logging :P
dermetfan has joined #zig
<pixelherodev>
THis isn't from test_runner though, and I found the issue :)
<pixelherodev>
s/H/h
<pixelherodev>
shakesoda: why do you need threads for this?
<pixelherodev>
Seems like you're putting in a lot of effort for it...
<pixelherodev>
What are you working on?
<shakesoda>
pixelherodev: because i'm solving problems which are suited to such things (rendering, simulations...)
<pixelherodev>
Specific project, or?
drewr has joined #zig
<shakesoda>
prototyping this for my game, yeah
<fengb>
The "fix" for branch prediction is speculative execution. That's getting rolled back due to spectre so we're back to square one
<shakesoda>
threading will be a clear win if i can get the task groups scheduled in a way that works well
<pixelherodev>
fengb: that's *a* fix
<pixelherodev>
Heck, no it's not
<pixelherodev>
SpecEx is a *part* of branch prediction which is being rolled back
<pixelherodev>
I'm talking about a more fundamental shift, not changing implementation details
<shakesoda>
there's also the possibility that this scheduling approach/concept will always suck, and i'll need to do it differently, but that's what experiments are to determine
<fengb>
Itanium tried to push stronger parallel execution for branches
<fengb>
But nobody else cared
<pixelherodev>
hmm
<fengb>
Basically the same idea as speculative execution but at a software level
<shakesoda>
intel didn't seemingly even attempt to bring itanium into regular workstations at any point
<pixelherodev>
andrewrk: the problem with making C a link file format (ELF, COFF, etc) instead of the current solution is that the test cases don't track that
<shakesoda>
a shame, that is
<fengb>
And it does work but... nobody wanted Itaniums so
<pixelherodev>
fengb: you mean predicated execution?
<pixelherodev>
They've brought that to x86 though
<pixelherodev>
So it's not a *total* waste
<pixelherodev>
There's predicated moves, for instance
<fengb>
Yeah but more strict. Like only selecting a single result
<fengb>
So it's guaranteed to run fast
<pixelherodev>
That's... what predicated execution *is*
<pixelherodev>
Predicated execution is basically executing both branchs in tandem
<fengb>
No branching at all
<pixelherodev>
x86 has it, to an extent
<pixelherodev>
Yeah, exactly.
<fengb>
I'm saying the architecture allowed "branching" without jumps
<shakesoda>
oh, gpus also do that
<pixelherodev>
fengb: *so does x86*
<fengb>
That doesn't really exist in x86
<pixelherodev>
Yes, it does
<fengb>
I mean it does but it's slow
<pixelherodev>
It's just far more limited
<pixelherodev>
I don't think it's slow
<pixelherodev>
It's just less useful, because there's fewer predicatable instructions
<fengb>
cmov is really slow compared to trusting the branch predicter
<pixelherodev>
Ah, true
<pixelherodev>
Wait, is it?
<pixelherodev>
Hm
<fengb>
I dunno about others but it's recommended to avoid it unless you need it
<fengb>
Yeah cmov was created for Pentium 4. But architectures since then it's generally considered slower unless you know the predictor sucks
<pixelherodev>
NOt anymore
<fengb>
Anyway... Itanium was built around this concept. Every execution unit was like 3? or so instructions in parallel
<pixelherodev>
cmov is generally fast now, it's just not *as fast* as branch predictions for branches which will be predicted accurately
<pixelherodev>
fengb: SPU Mark II is like this, too ;)
<pixelherodev>
Every single instruction is predicated
dermetfan has quit [Ping timeout: 256 seconds]
<pixelherodev>
I think the problem with Itanium was that it was technically better
<pixelherodev>
and nobody wanted that lol
<pixelherodev>
It was *objectively* better, but AMD came out with x86-64 before Intel really took off with Itanium
<pixelherodev>
And people preferred x64 because it meant Backwards CompatibilityTM
<fengb>
It was probably 10 years too early
<pixelherodev>
Honestly, i would buy Itanium if they sold it
<fengb>
People still expected brute forcing x86 to work. And they were right
<pixelherodev>
I don't particularly like Intel, at all
<fengb>
We can't do that anymore
<pixelherodev>
But I'd take Itanium over nearly any current ISA, with the possible exception of RISC-V
<fengb>
Even ARM? :(
<pixelherodev>
Without hesitation lol
<shakesoda>
arm has its priorities mostly where mine are
<pixelherodev>
I don't particularly like ARM TBH
<shakesoda>
so i'm all for moving that way
<pixelherodev>
Such as?
<pixelherodev>
What priorities are those?
<shakesoda>
mostly power/battery efficiency
<shakesoda>
particularly for less hungry machines
<pixelherodev>
Gotcha, I'm in full support of those
<pixelherodev>
fengb: the real problem with predication on x86 is the microarchs
<pixelherodev>
I wouldn't be surprised if future x86 microarchs made predicated instructions cheaper than branch prediction
<shakesoda>
i'm not especially interested in the specifics of the isa or how it works, just that it has explicit goals here that align with my interests
<fengb>
Yeah it does exist. It's just magically in the microcode and totally opaque
<pixelherodev>
What is?
<fengb>
Predication
<pixelherodev>
No it's not.
<pixelherodev>
Predicated instructions are advantageous because they don't stall the pipeline
<pixelherodev>
They take more time to execute *individually*, but they eradicate branches *entirely*
<pixelherodev>
The problem is, we already have branch predictors
<pixelherodev>
and the current pipelines are optimized for those, and not for predication
<pixelherodev>
So in many situations, relying on the branch predictor is cheaper
<pixelherodev>
But it has nothing to do with the microcode
<shakesoda>
my understanding is that it's a pretty wacky world down in microcode land
<pixelherodev>
If every x86 instruction was predicated, and people used them, you could remove the branch predictor and be *faster*
<pixelherodev>
But that won't ever happen, because legacy software doesn't predicate, and will therefore rely on a branch predictor forever
<pixelherodev>
Unless someone writes e.g. an x86 post-compilation predicator or something lol
<pixelherodev>
Automated replacement of branches with predication would be sick though
Akuli has joined #zig
<pixelherodev>
Heck, if someone *did* devise a more predicated x86 microarchitecure, I wouldn't be too surprised if they did that in hardware for short branches that fit in the pipeline, in the same way there's micro-op fusion
<leeward>
pixelherodev: Yes, EDT and EST are different time zones.
<pixelherodev>
leeward: huh, good ot know
<shakesoda>
incidentally, the legacy software problem is one of the things i like about workstations finally pushing out of x86. arch changes are a good opportunity to update ancient bad decisions (even if the old arch still gets emulated)
<pixelherodev>
to*
<pixelherodev>
That was the goal of Itanium lol
<shakesoda>
how much of that will happen in reality is to be seen, but i'll take the opportunities
<pixelherodev>
They wanted hardware emulation of x86 or something like that
<pixelherodev>
With new stuff being totally freed of the trappings of x86
<shakesoda>
as such, i also very much wanted itanium
st4ll1 has joined #zig
<shakesoda>
but it never really arrived for workstation purposes
<shakesoda>
:(
<leeward>
It's really too bad AMD made the smart business move to make x86_64.
<shakesoda>
good for business, bad for technology?
<leeward>
yep
<leeward>
If Intel had had a real monopoly there wouldn't have been anyone keeping us from switching to Itanium, but they had failed to completely crush their competition.
<leeward>
I mean, they killed Cyrix but AMD hung on just long enough to keep x86 alive.
<shakesoda>
turns out it's good we've still got amd, but we also still have x86 (damn, foiled)
<leeward>
I just wish we still had Sun.
<leeward>
Apparently they almost made an x86 clone in 2008.
<shakesoda>
i think i would also accept if power machines were a bit more affordable
<shakesoda>
those talos workstations are nice, but cost a fortune :(
<shakesoda>
i am far more interested in jumping to arm, though
<leeward>
These days I don't see much future in power.
<shakesoda>
the only x86 holdout here is my workstation
<shakesoda>
+ a laptop
stripedpajamas has joined #zig
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 is now known as dingenskirchen
dingenskirchen has quit [Client Quit]
dingenskirchen has joined #zig
aerona has joined #zig
dingenskirchen has quit [Read error: Connection reset by peer]
<shachaf>
ifreund: I mean, I'd apply the usual debugging strategy here. Do bits of the fork/exec and see what bit causes it to happen, write a minimal program that just does the fork/exec, etc.
<shachaf>
Right now the problem is probably not where you think it is.
Shucks has joined #zig
<Shucks>
Heya
<ifreund>
o7
<leeward>
\o
dermetfan has quit [Ping timeout: 272 seconds]
Akuli has quit [Quit: Leaving]
dermetfan has joined #zig
marijnfs_ has joined #zig
<_Vi>
Is there some Zig changelog that covers changes past the latest released version (0.6.0)?
<leeward>
There's the Git log, but I don't think there's a written up changelog.
marijnfs has quit [Ping timeout: 258 seconds]
<shakesoda>
usually the changelog is written when release is coming up
<leeward>
You probably don't want to go through all the commits since 0.6.0.
<shakesoda>
i think andrewrk said the last one took like two weeks to write
<shakesoda>
a major effort lol
<leeward>
It doesn't look like the commit messages are consistent about marking breaking changes, either.
<andrewrk>
at this point in development we still need the luxury of being a bit "sloppy" with regards to breaking changes. there will be a time when it becomes a lot more of a process
<andrewrk>
that comes after language stabilization
<andrewrk>
official debut of the zig software foundation
<fengb>
Zig Software Foundation announcement
<ikskuh>
pixelherodev: looks good
dermetfan has quit [Ping timeout: 246 seconds]
kristoff_it has quit [Read error: Connection reset by peer]
<_Vi>
Is there some [official] roadmap for future Zig development?
<pixelherodev>
I think ther'es one on the 0.6 release notes?
<pixelherodev>
Anything interesting in the preshow?
<pixelherodev>
andrewrk: while you're here, any objection to me improvising a temporary two-command linker script format until we decide on a proper one?
<andrewrk>
yeah, linker scripts are a hack, we should come up with a better solution
<pixelherodev>
andrewrk: maybe define a specific model, and use `--model`?
<pixelherodev>
That would mean defining every possible target internally, but I think we were already planning on that :P
<shakesoda>
another iteration of my task scheduler is working... too many locks, but now it's only ~5x slower than it should be, which is a pretty big improvement
<shakesoda>
i should be able to make it lock free
bastienleonard has joined #zig
marijnfs has joined #zig
marijnfs_ has quit [Ping timeout: 240 seconds]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
stripedpajamas has quit [Quit: sleeping...]
<ifreund>
_Vi: there's also the list of accepted proposals among the github issues
<_Vi>
Which Zig build is recommended to toy around mini-projects of trying Zig here and there? 0.6.0 or master? About a year ago recommendation was to use master (as bug reports against 0.5.0 was mostly unapplicable due to fast development).
<ifreund>
i'm sticking with 0.6.0 for my somewhat larger scale project so I don't have to keep pace with master
<Shucks>
I might be a bit spoiled but is there any editor which gives code suggestions for zig?
<ikskuh>
_Vi: I usually work on master. You have to update regularly and adapt your code, but "master" is just improved 0.6.0, as 0.6.0 is just a defined snapshot, not much special properties
<pixelherodev>
ZLS is literally perfection incarnate
<ikskuh>
yep
<oats>
*phwip*, straight to the top of hacker news
<oats>
nice lol
frett27_ has joined #zig
THFKA4 has joined #zig
frmdstryr has joined #zig
Patrice_ has quit [Ping timeout: 246 seconds]
<_Vi>
Is minimal ziglang donation amount is 25USD per month?
<ikskuh>
i think so
KoljaKube has quit [Ping timeout: 272 seconds]
<_Vi>
Are donations towards andrewrk still considered as donations towards Zig language or they are not considered as donations towads other Github projects?
<ikskuh>
_Vi, they're directed to andrew as a developer and not to the zig language
<ikskuh>
but for now it's probably the same :D
<_Vi>
Is that 25USD minimum a temporary "marketing ploy" while video is going on to catch those emotional donations (and usual 5USD tier is going to be opened in a while after the show ends)?
<Shucks>
God zls is perfect. Why is it not included in the release build
<ikskuh>
zls is not official :D
<ikskuh>
it's by aurame and alexnask
<BaroqueLarouche>
and it gets updated almost daily also
<Shucks>
Well zig can be happy to have zls. For a newcomer it's really hard to jump over if there aren't code suggestions ;D
<ikskuh>
yeah ZLS is just helping a lot
<Shucks>
So with that said, I saw some unofficial package managers for zig aswell. But zig itself doesn't has a package manager yet right?
<ikskuh>
it doesn't have one yet
<ikskuh>
my "package manager" is more or less just a search tool for github :D
<Shucks>
Thats not bad at all. Got a link for me?
<ikskuh>
github.com/zigtools/zpm
<ikskuh>
but it's not really maintained :D
<_Vi>
How much do Zig and Rust communities intersect? Both languages seek to make system programming better and safer.
<ikskuh>
_Vi, i think the surface is actually pretty small
<ikskuh>
i know some people doing rust, but i'm aware of more web programmers that got here :D
<ikskuh>
but: that's just my view :D
<_Vi>
Is it safe to assume that all (most) Zig programmers also know C?
<Sahnvour>
_Vi: I think many people see rust as an evolution from C++, whereas Zig is seen as an evolution from C, agreeing with ikskuh there isn't _that much_ overlap
<Shucks>
Coming from nim, zig was the only language that aroused my curiosity
<Shucks>
for a long time now
<fengb>
Rust also attracts some functional programmers. It’s type system is based off ML/Haskell
<ikskuh>
Sahnvour: true. i've come from C++17 and i'm happy that i found all the stuff i like in Zig and i don#t find the stuff i hated in C++ :D
<_Vi>
"evolution from C" => Will (or does) Zig define it's own stable ABI (in Zig terms, not in C terms), so other programming languages can talk Zig to each other (instead of using "C" function call convention and structure layout as lowest common denominator)?
<THFKA4>
yes, Zig has an ABI, but you can also export/consume C abi with a keyword
<pixelherodev>
Zig's ABI isn't really defined yet
<Sahnvour>
ikskuh: I also find everything I need from (modern) C++ in Zig, and more, and better :) even though it's a bit closer to C in its philospohy
<_Vi>
Will "Zig 1.0" have frozen stable ABI that can be relied on by non-Zig things?
<ikskuh>
_Vi: Zig doesn't actually have a ABI
<ikskuh>
and with comptime it's not possible to actually export all functions to a binary file
<pixelherodev>
Yes
<ikskuh>
but zig can export to a lot of ABIs
<pixelherodev>
Zig 1.0 will be nearly 100% frozen
<Shucks>
So one last question before I finally start to write some lines: Since zig is able to compile c code, I'm not even forced to write a wrapper for glfw (for example). I include the header files and im just able to call that stuff from zig?
<pixelherodev>
If we end up with our own ABI (which I *think* is on the table), it'll be frozen at 1.0
<_Vi>
ikskuh, C ABI and C calling convention is one of things that makes C programming language special. If Zig wants to be on par with C, it should commit on memory layouts, symbol naming and function calling concentions.
<ikskuh>
_Vi: that's possible
<ikskuh>
if you want to interface C, it's no problem to do that
<ikskuh>
but Zig is more than C
<ikskuh>
it's not "C with another syntax"
<pixelherodev>
ikskuh: yes, but there's an open issue to define our ABI
<ikskuh>
i still think it's not possible
<ikskuh>
because then zig would lose a lot of it's power
<ikskuh>
for example, for release-fast (well aligned) zig can chose different struct layouts than for release-small (packed)
<ikskuh>
as soon as you define an ABI, you freeze struct layouts → not possible anymore
<ikskuh>
can you link me the issue? i may comment some thoughts
<_Vi>
ikskuh, Does this layout depend on Zig version or there are some official rules and struct layout can be predicted without any Zig compiler?
<ikskuh>
i will write a nice comment there after the stream
* pixelherodev
nods
<pixelherodev>
I think there should be one, but only for exports / imports
<pixelherodev>
That allows e.g. dynamic libraries, without damaging any other use case
<ikskuh>
well, "export" enforces ABI already ;)
<_Vi>
I see "Zig competes with C instead of depending on it" on the website, but without [plans to] make a stable ABI on various archs it is not a real competition.
<pixelherodev>
Yes, but I mean for e.g. slices
<pixelherodev>
_Vi: you can get a stable ABI rn
<ikskuh>
_Vi: why? if you want stable ABI, chose an existing ABI ;)
<pixelherodev>
That's part of our C compatibility
<pixelherodev>
You can use e.g. callconv(.C)
<ikskuh>
zig allows you to chose from several ABIs
<ikskuh>
but not for zig-internal features (right now)
<_Vi>
Which callconvs (apart from ".C") are aimed to be usable from non-Zig things (while providing relatively ergonomical access to Zig features)
<ikskuh>
it depends on what you need them for
<ikskuh>
signal(OS) and interrupt(HW), thiscall(c++)
<_Vi>
I don't have any specific point (not learned Zig enough), but "C" is often being considered as a main system programming languages because of it's ABI is used to communicate even between things that are not implemented in C (e.g. between Java and C++). Rules of how C lays out data and calls functions is like a continuation of the rules of how processor works. This may lead to a world when many things are implemented in Zig, but still communicates each other
<_Vi>
in C terms. I may revisit this question when I have a more concrete sample of something.
<ikskuh>
_Vi, and it will probably keep that way forever
<ikskuh>
but it's not a really problematic thing
<ikskuh>
C is the lowest common denominator of feature sets between all languages with a FFI
<_Vi>
ikskuh, Asserting that does not look like "competes with C instead of depending on it".
<ikskuh>
wait!
<ikskuh>
we're competing with the C programming language
<ikskuh>
not the C ABI
<ikskuh>
C ABI is just describing memory layout of structures and calling conventions
<ikskuh>
and not much more
<ikskuh>
it's not even specific to the C language
<_Vi>
What about defining good ABIs for more advanced data structures? For optimized function calls (trickier rules, but still there are rules)?
<ikskuh>
but it's just "the ABI C defaults to on $PLATFORM"
<ikskuh>
i don't see reason in that
<_Vi>
So that when new processor and new operation system gets created, they'll think "How Zig libraries will talk to each other?" instead of "Let's define C calling convention for this platform".
<ikskuh>
daurnimator: PING
<daurnimator>
ikskuh: ah. there you is
<ikskuh>
_Vi: this would rule out C for those platforms ;)
<ikskuh>
which isn't good either
<daurnimator>
I forget that you are the same person
<ikskuh>
:D
<ikskuh>
sorry for confusion here as well :(
<daurnimator>
ikskuh: I'm having a look through h11 now
<daurnimator>
ikskuh: the receive_bytes style seems like it requires buffering?
<_Vi>
For example, how well would Zig feel when targeting a new platform for which C ABI is not yet defined?
<ikskuh>
daurnimator: they changed API completly since i wrote ZPM
<_Vi>
Would dynamic libraries work?
<daurnimator>
_Vi: there are other ABIs; e.g. nakedcc
<ikskuh>
_Vi: that's hard to say ;)
<ikskuh>
someone has to define an ABI
<daurnimator>
and another struct layout: `packed`
<_Vi>
daurnimator, Do those other ABIs work as a way to get dynamic linking work?
<ikskuh>
and if there's only one ABI (see ARM), everything is that ABI
<ikskuh>
if it's C or Zig isn't relevant
<daurnimator>
_Vi: I doubt a platform would have dynamic linking before it had a C AB defined; so its a bit of a hypothetical question
<ikskuh>
"C ABI" is pretty much just relevant on x86, all other platforms have a pretty specific ABIs
<_Vi>
If Zig-as-a-C-competitor gets really big, then why not?
<daurnimator>
_Vi: new architectures generally get a "C" ABI defined as part of the architecture design
<ikskuh>
_Vi: because you mess up "language" and "ABI"here
<daurnimator>
though its not really a "C" ABI; as the native architecture design
<_Vi>
Then maybe at least "Zig competes with C instead of depending on it" should be revised to "Zig competes with C _language_ instead of depending on it" and a phrase about not competing with C ABI added?
<ikskuh>
i think you#re doing a lot of hairsplitting atm
<ikskuh>
C ABI is pretty much just "someone said that is the official interop between programs" and put the label "C ABI" on that
<ikskuh>
just read that as "Common ABI" instead of "C Language ABI"
<ikskuh>
and your "problem" is solved
<_Vi>
I though "competing with C" is imagining Zig was created before C (and B and friend), imagining how other things would change (for the better?) and trying to change the world to that.
<ikskuh>
i don't think there would've changed much
<ikskuh>
except for probably an ABI for slices
<_Vi>
So "C ABI" may be a bit of misnomer as of now?
<ikskuh>
the rest would be still the same
<ikskuh>
yes
<_Vi>
OK. Thanks for the answers.
<daurnimator>
ikskuh: your BearSSL lib needs updating to writer instead of OutStream
<ikskuh>
oh true
<ikskuh>
i need vacation
<Sahnvour>
getting late here, the stream was great, gnight everyone