<andrewrk>
what is the relationship between ARM / NVIDIA / RISC-V ?
<andrewrk>
I'm realizing how little I know about it
<fengb>
Indirect. People might migrate to RISCV now that a company who’s traditionally hostile to open source is in charge
<leeward>
Yeah, I saw that.
<leeward>
I don't think it's likely that ARM will take any steps hostile to open source. They know how they make their money.
<leeward>
It's not like if Microsoft bought GitHub or anyth...oh.
xackus has quit [Ping timeout: 260 seconds]
<andrewrk>
less competition is worse
<pixelherodev>
^
<pixelherodev>
This kind of consolidation is terrible for everyone.
nvmd has quit [Quit: Later nerds.]
<andrewrk>
it's the premise of capitalism
<Snektron>
<andrewrk "less competition is worse"> Do nvidia gpus compete with arm cpus?
<andrewrk>
yes
dermetfan has quit [Ping timeout: 240 seconds]
<companion_cube>
in what sense? that seems counter intuitive to me
<pixelherodev>
companion_cube: companies use ARM CPUs with ARM GPUs
<pixelherodev>
e.g. Mali IIRC
<andrewrk>
but also just the fact that previously we had 2 independent companies using their power to tug on the market in non-parallel directions, and now we have 1 mega corp with more tugging power
<companion_cube>
there are ARM GPUs? :o
<companion_cube>
TIL
<pixelherodev>
companion_cube: not to the same level as AMD / NV of course
<companion_cube>
I guess it's like intel GPUs, heh… should have thought of it
<pixelherodev>
But what did you think were in LineageOS phones?
<pixelherodev>
and, fine, Android ones too if you want to be pedantic.
<companion_cube>
I have no idea :D
<companion_cube>
I mean, are these really GPUs? :) I don't know what this covers
<pixelherodev>
I don't know if they're designed by ARM as well
<pixelherodev>
They might be third-party for all I know
<Snektron>
Personally im still waiting for the mill architecture
<Snektron>
<pixelherodev "companion_cube: companies use AR"> I could see nvidia trying to lock in their gpus in arm chips yea
<pixelherodev>
Ugh
<pixelherodev>
This kind of crap is why I dislike it when people pretend America is capitalist. We're not.
<pixelherodev>
Things like modern CPUs can't really be capitalist though, by design
<companion_cube>
Snektron: augmented reality? makes sense
<pixelherodev>
The barriers to entry are measured in, what, thirteen digits now?
<companion_cube>
nvidia has already pretty locked the deep learning market, afaik
<pixelherodev>
Or has it gone up since the last time I looked?
<pixelherodev>
I'm only slightly exaggerating, but you get the point
<pixelherodev>
I heard someone say that if Moore's Law ever dies, it won't be because of technical reasons, but financial ones
<pixelherodev>
I'm not sure I disagree
<Snektron>
Financial reasons are the driving factor as to why it doesnt die
<pixelherodev>
For now, yes
<pixelherodev>
But the cost of manufacturing is going up at the same rate as the transistor count
<pixelherodev>
The only reason it's "affordable" is the sheer size of the market
<pixelherodev>
Massive fixed costs with relatively small per-unit costs, effectively
<Snektron>
> Snektron: augmented reality? makes sense
<Snektron>
I mean also just generic. Mobile games require decent processing power too nowadays.
<pixelherodev>
Hell, companies like Intel would probably be the worst affected by economic downturns
<pixelherodev>
If the number of people who can afford to get new, fresh-off-the-factory chips goes down, they might not be able to recoup the costs of building the foundry in the first place
<pixelherodev>
Well, if individual consumers were their biggest customers :P
<pixelherodev>
But it also means less money to other businesses, which then can't afford to spend money on new CPUs, so it's the same anyways
<Snektron>
I read that google is prepared to replace their entire hardware for a 10% efficiency improvement in computing power
<pixelherodev>
I wonder what they'll do with the old stuff lol
<Snektron>
Dump in an ocean most likely
<pixelherodev>
I sincerely hope not.
<andrewrk>
that's the danger of optimizing for profit rather than public benefit
<pixelherodev>
Heck, not really.
<pixelherodev>
andrewrk: I daresay this would be neither.
<pixelherodev>
Optimizing for profit would be selling them off.
<pixelherodev>
Even if they sold them at half the price they paid for them, it's still better for them.
<pixelherodev>
They make some money instead of none, they gain in terms of PR, etc
<pixelherodev>
There is literally no benefit to them in destroying it
<andrewrk>
I'm considering moving std.cache_hash into stage2. it's becoming a pretty bespoke API
<pixelherodev>
Is it useful outside stage2>
<pixelherodev>
?
<andrewrk>
bespoke means useful in only specific circumstances
<andrewrk>
so I'm saying that it's becoming less useful outside stage2
_whitelogger has joined #zig
nephele_ has joined #zig
nephele has quit [Ping timeout: 244 seconds]
nephele_ is now known as nephele
<pixelherodev>
Ahh, gotcha
<andrewrk>
I love makeOpenDir
<andrewrk>
oops I mean makeOpenPath
<andrewrk>
on windows it's only 1 syscall
a_chou has joined #zig
<pixelherodev>
Syscall fusing is neat
<pixelherodev>
Would be neater if there was... huh.
<pixelherodev>
That's an idea
<pixelherodev>
A generic multi-syscall interface or something
<pixelherodev>
so e.g. make + open + write + flush + close could require a single context switch
<shachaf>
io_uring is heading in that direction.
marnix has joined #zig
marnix has quit [Ping timeout: 258 seconds]
a_chou has quit [Quit: a_chou]
traviss has quit [Remote host closed the connection]
<daurnimator>
already is...
<companion_cube>
isn't bpf going even further?
marnix has joined #zig
_whitelogger has joined #zig
<jjsullivan1>
would it be fair to say `anytype` is pretty stable at this point in time?
cole-h has joined #zig
<jjsullivan1>
I ran into a bug that's forcing me to nightly, and it would be convinient for a couple of things I'm trying to do
traviss has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
ur5us has quit [Ping timeout: 244 seconds]
xackus has joined #zig
marnix has quit [Ping timeout: 240 seconds]
marnix has joined #zig
cole-h has quit [Quit: Goodbye]
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
xackus has quit [Ping timeout: 240 seconds]
oxymoron93 has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
ur5us has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
Xavi92 has joined #zig
Xavi92 has left #zig [#zig]
klltkr has joined #zig
nocontent has joined #zig
nocontent was banned on #zig by ChanServ [*!*@103.25.248.234]
nocontent was kicked from #zig by ChanServ [Banned: you are not being constructive]
st4ll1 has quit [Quit: WeeChat 2.9]
<andrewrk>
jjsullivan1, yes, but it's been available for a long time. in 0.6.0 I believe it is `var`
oxymoron93 has quit [Quit: Ping timeout (120 seconds)]
marnix has joined #zig
tracernz has quit [Ping timeout: 240 seconds]
marnix has quit [Read error: Connection reset by peer]
ur5us has quit [Read error: Connection reset by peer]
ur5us has joined #zig
tracernz has joined #zig
ur5us has quit [Ping timeout: 244 seconds]
oxymoron93 has joined #zig
dermetfan has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
xd1le 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
xd1le has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
marnix has quit [Read error: Connection reset by peer]
mokafolio has quit [Quit: Bye Bye!]
forgot-password has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
mokafolio has joined #zig
<jjsullivan1>
oh, so it's mostly a syntax change? thanks for the tip andrewk :^)
<jjsullivan1>
**andrewrk
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
Trastos has joined #zig
supercoven has joined #zig
xd1le has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
xd1le has joined #zig
waleee-cl has joined #zig
Trastos has quit [Ping timeout: 258 seconds]
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
mokafolio has quit [Client Quit]
mokafolio has joined #zig
xd1le has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
xd1le has joined #zig
justin_smith has joined #zig
<justin_smith>
I've been interested in all the stuff I read about zig, and I'm translating the simple jack audio client example to zig - pretty cool how "weird" errors in C are plainly explained by the zig compiler
<justin_smith>
bigger goal is to make a demo multi thread async client, using await to communicate between the RT audio thread (no allocation or syscalls allowed) and a helper thread (likely including a GUI, allocation allowed, syscalls allowed, showing status of audio thread and letting the user control parameters)
<justin_smith>
I'm laid off, so maybe I'll make it a tutorial :D
<ifreund>
that sounds like it would be super neat
<justin_smith>
it's fun so far, and with no day job to worry about the road is clear :D
<justin_smith>
I'll keep the channel updated if someone could help with review before I publicise - I'd rather not make an instructional document with bad examples for people to copy
<justin_smith>
but for (hopefully obvious) personal and pedagogical reasons do want to do the work myself
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
<ifreund>
i'd be happy to give it a read before publication
e^x has joined #zig
<justin_smith>
awesome, thanks
dermetfan has quit [Ping timeout: 240 seconds]
<pixelherodev>
Seconded!
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
<mkchan>
hey guys, gotta love Zig. Having finished the first part of porting my old C chess engine to Zig, I have to say Zig is really nice to code with. I have the repo up here if anyone's interested: https://github.com/Mk-Chan/WyldZig
<mkchan>
though it's of little use at the moment, only being able to do performance tests
<mkchan>
it's already at performance parity with my old codebase and I haven't even implemented the latest and greatest yet. Not sure if it's the language or better coding in general (or both!)
<pixelherodev>
Both, probably ;)
<mkchan>
interesting part was that i ran into this error: `evaluation exceeded 1000 backwards branches` though i was able to use @setEvalBranchQuota() because I knew roughly how many iterations it was going to be, is there a hard limit to it? I kind of want to experiment making a completely compile-time program just for fun
<pixelherodev>
mkchan: that's basically a hack to avoid the halting problem
<pixelherodev>
You can set it as high as you want
<mkchan>
ok nice
<pixelherodev>
mkchan: I'd point out there can be problems with doing so - primarily (only?), performance
<pixelherodev>
I had a program where marking something comptime increased compile-time from ~5s to ~90
<pixelherodev>
Runtime was maybe 0.5% faster lol
<ifreund>
I wonder how many times faster stage2 will be at comptime stuff than stage1
<pixelherodev>
ifreund: Once we have the basic infrastructure in place, you *know* what I intend to try
<pixelherodev>
;)
<ifreund>
I'm not quite clear how JITing comptime is gonna work
<ifreund>
I guess you need to do some kind of search to determine what code is comptime, and then JIT/run that?
<pixelherodev>
ifreund: same way interpreter works.
<pixelherodev>
That's why I've been emphasizing waiting for now
<pixelherodev>
I have no intent to work on it before there's an interpreter
<ifreund>
makes sense
<pixelherodev>
Any initial JIT would likely generate calls *to the interpreter*
<pixelherodev>
Which would be a minor boost, but still a boost.
<ifreund>
and yeah there are certainly higher priority tasks for the moment
<pixelherodev>
I still need to finish that CBE patch, and the SPU-2 C ABI
<pixelherodev>
There's some major CBE work that needs doing
<mkchan>
pixelherodev: what i'm planning is to basically offload all the work to the compiler
<pixelherodev>
I'm also considering getting more familiar with astgen and working on struct support
<mkchan>
so essentially runtime is just print(<comptime-calc'd number>)
<pixelherodev>
mkchan: how complex are the calculations?
<ifreund>
didn't vexu already do that? or am I misremembreing
<pixelherodev>
ifreund: ... I need to double-check.
<pixelherodev>
It's not impossible.
<mkchan>
not very, it's a chess game, it increases with how deep you want to go, but a few ply isn't bad at all
<pixelherodev>
ifreund: Vexu's definitely done a ton, but I don't see structs
<ikskuh>
pixelherodev: btw, i patched my cert again, shifting another 3 month cycle. standard calling convention for spu 2 is now cert-safe again :D
<pixelherodev>
lol
<pixelherodev>
nice :P
<pixelherodev>
ikskuh: you saw my comment about kristall?
<ifreund>
pixelherodev: indeed, I think seeing vexu's open PR for @import() confused me
<pixelherodev>
Ah yeah, you're actually right
<pixelherodev>
It's part of that PR IIRC
<pixelherodev>
That's why I didn't see it in commit logs
<pixelherodev>
It's basic struct support, which is critical for imports
<ikskuh>
pixelherodev: where? :D
<pixelherodev>
here, probably
<ikskuh>
then: no
<pixelherodev>
ikskuh: kristall is the only browser I have left on my laptop :P
<pixelherodev>
I wiped my glibc partition lol
<pixelherodev>
It is still technically the second-most-complex browser, but only because I have w3m still IIRC
<ikskuh>
:O
<ikskuh>
crazy
<pixelherodev>
Hey! It wasn't intentional!
<pixelherodev>
Or, well. It was, but it was poorly thought out
<pixelherodev>
I hadn't realized it would happen! :P
<ikskuh>
btw, would be happy to receive PRs when you find/fix stuff ;)
<pixelherodev>
ikskuh: I'm more likely to start competing with you, TBH
<pixelherodev>
I like the UX of kristall, but I dislike QT intensely :P
<ikskuh>
haha
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pixelherodev>
Not to mention *shudders* C++ ew ;P
<ikskuh>
hey, that's quite conservative c++ _D
<fengb>
So GTK then?
<ikskuh>
hehe
<pixelherodev>
ikskuh: I know :P
<pixelherodev>
fengb: ... that's not exactly better
<ikskuh>
pixelherodev does trade qt for power consumption probably :D
<fengb>
It’s not C++ ;)
marnix has joined #zig
<pixelherodev>
fengb: oh yay, congrats on solving what is obviously my single biggest problem with any package. The *language*. ;)
marnix has quit [Read error: Connection reset by peer]
<pixelherodev>
ikskuh: ?
<pixelherodev>
Wdym?
<ikskuh>
using anything like sokol/sdl/… eats up CPU
<ikskuh>
those toolkits aren't meant for normal UI stuff
<ifreund>
hmm, I wonder if netsurf's engine can be used as a library
<pixelherodev>
ikskuh: I wasn't planning on it
<ikskuh>
good
<ikskuh>
and it's super annoying, we definitly need zig-window better now :D
<pixelherodev>
We already discussed why it'd be a bad fit, remember?
<pixelherodev>
I like Sokol, but that doesn't mean I'm going to use it where it's a bad fit
<ikskuh>
this was even another argument base :D
<ikskuh>
but yeah
<ikskuh>
we need a native ui library for zig soon… :(
<fengb>
I’m assuming because they’re game based, they’re intended to run every frame?
<pixelherodev>
ikskuh: do you know of any genuinely lightweight UI libraries?
<pixelherodev>
fengb: yeah
<pixelherodev>
Sokol can probably be configured to change that, but it's still fundamentally the same
<pixelherodev>
it's not optimized for it
<pixelherodev>
anyways, work to do and all that
* pixelherodev
busy busy busy
<ikskuh>
fengb: yeah, you can't suspend either sokol or SDL, they just do busy-polling events and burn your CPU while doing so
<ikskuh>
pixelherodev: no, sadly not. they are all either based on "do your own drawing" or are shit :D
<ifreund>
and then you have the issue that you need to pass the libwayland stucts to mesa if you want to use opengl
<ikskuh>
> In principle, any system capable of creating buffers and drawing into them should be usable. At present, Wayland only supports a system called EGL. It does so by the four functions
<ikskuh>
dang
layneson has joined #zig
<pixelherodev>
Wonder why that is
<JimRM>
Hi, so I am wondering if there is a good way to expose struct offsets to assembly files?
<ifreund>
you can also software render of course
<daurnimator>
JimRM: @byteOffsetOf ?
klltkr has joined #zig
<pixelherodev>
ifreund: without OSMesa?!
<pixelherodev>
;)
<ikskuh>
ifreund: i have dunstblick atm with software rendering
<ikskuh>
would be a option :D
<ikskuh>
software rendering and OpenGL would be enough anyways :D
<justin_smith>
JimRM: more detailed, I'd imagine a table from index to struct offset and pointer to name? maybe that's more than your assembly needs to implement machine side
<JimRM>
@daurnimator thanks - do you know how I could make the values returned from @byteOffsetOf available inside ASM files?
<ifreund>
pixelherodev: yes, you can just mmap a buffer, put pixels in it, and pass it to the compositor
<ifreund>
my screenlocker in rust doesn't link libwayland
<pixelherodev>
ifreund: I was being sarcastic lol
<ifreund>
whoosh
<justin_smith>
JimRM: @byteOffsetOf is compile time, so the values should be available while creating a data structure, you can pass the data structure to the assembly code, that's how I'd do it
<justin_smith>
more fine grained you can probably template the indexes into an assembly snippet, that sounds harder to me not easier, as an assembly writer
<JimRM>
@justin_smith - that sounds close to what I am looking for, except it sounds like I would need to pass the offset as a parameter? (Instead of being able use static values at compile time)
<pixelherodev>
JimRM: You could make it a build.zig extension
<JimRM>
I wondered if there was a way to do some sort of code gen? I currently use a .h file with a bunch of defines in (which the .S file includes)
<pixelherodev>
Have it generated an asm file at comptime
<pixelherodev>
s/rated/rate
<justin_smith>
JimRM: the full zig language is available at compile time, pre-calculate whatever you want, but I'd rather debug assembly that uses a table than debug a template that injects magic offsets into assembly snippets
<justin_smith>
ymmbv
<JimRM>
so if there was an easy way to generate that during compile time, that would be great.
<justin_smith>
if zig lang can calculate it without using external resources, it can do it at compile time
<pixelherodev>
JimRM: build.zig can produce arbitrary files
<justin_smith>
oh so it can do it using external recources too, cool :D
<JimRM>
OK, that is cool. The only thing then is to ensure that the Header file is generated before the assembly files are assembled
<justin_smith>
sounds like a job for a build tool
<JimRM>
Awesome! Is there a sample that I can use as reference for generating code files during a build?
<justin_smith>
JimRM: btw I am just learning myself, so a link to what ends up working would be really cool IMHO
mokafolio has quit [Quit: Bye Bye!]
layneson has quit [Ping timeout: 244 seconds]
<ifreund>
well, the build system itself does this to implement build options
waleee-cl has quit [Quit: Connection closed for inactivity]
<ifreund>
I don't know of any other example off of the top of my head though
<JimRM>
Also, is there a way to forward declare structs? Like in C - you can have an opaque pointer declared in a struct without needing to know the full declaration of what it is pointing at?
<ifreund>
zig has @OpaqueType() for this use case, though it's usually only used in C bindings
e^x has left #zig ["WeeChat 2.8"]
<JimRM>
Is it not idiomatic to do that in Zig?
<ifreund>
oh I think it's now @Type(.Opaque) on master though
mokafolio has joined #zig
<fengb>
Zig typically has full source available
<klltkr>
ikskuh ifreund: I believe OpenGL without libwayland is possible using dmabufs
<fengb>
And statically linked instead of dynamically linked, so there's not a strong need
<ifreund>
klltkr: yes that's right
<justin_smith>
it seems like it would simplify things a lot to require the struct be compiled before the code using it, within the same build
<ifreund>
see the various branchs for opengl examples
marnix has quit [Read error: Connection reset by peer]
<ikskuh>
checking it out
layneson has joined #zig
<ikskuh>
okay, i have now a cat
<ifreund>
nice
<ikskuh>
yeah
<ikskuh>
and a opengl loop
<ikskuh>
i wonder how much work it is to create a partial update/rendering loop
<ifreund>
no idea, everything I've done client side has been very basic
<ikskuh>
ah okay
<companion_cube>
pixelherodev: are you back into C because of wayland, or by preference>
<companion_cube>
?
<ikskuh>
hm *thinking*
<ikskuh>
it might be a good idea to do zig-window incrementally, and first depending on external libs, replacing the required functions one by one with a zig impl
<ifreund>
i agree
<ikskuh>
for windows, we already have window creation fully self hosted i think
<JimRM>
OK, so as mentioned above - in my build.zig file I would like to import a .zig file from my src folder which contains a struct I would like the inspect during build. Is it possible to @import a source file in the build.zig file? (Currently I get a error stating: 'error: unable to find 'src/module')
<ifreund>
i actually started work on idiomatic zig wayland bindings last night, but haven't got very far yet
<ikskuh>
:O
<ikskuh>
uuuh, nice
<ikskuh>
ping me when it works!
<ikskuh>
i want to do a version of dunstblick without SDL
marnix has joined #zig
<ifreund>
JimRM: I feel like that should work, the path you gave to @import() is relative to the build.zig file right?
<JimRM>
@ifreund - Yes, I just got it working. Didn't have the .zig extension in file module name
<ifreund>
nice!
<JimRM>
Still not sure when and when no you need the extension
<ifreund>
you don't need the extension for "packages"
<ifreund>
e.g. std is a package separate from your project so you do @import("std")
marnix has quit [Read error: Connection reset by peer]
<justin_smith>
a package is a level of abstraction up from a source file surely
<justin_smith>
it's probably already pre-processed by the time I see it
<justin_smith>
(just working from first principles here, I'm a NEWB)
<justin_smith>
but it looks like packages are used as structs (perhaps are simply structs)
<ifreund>
yeah packages are structs, files are structs too
<justin_smith>
where the members of a file would be... characters, or pre-parsed?
marnix has joined #zig
<ifreund>
just normal source code
<justin_smith>
so an array of u8 / whatever encoding on top
<fengb>
`@import(file)` will convert the file into a Zig struct. You can do `@embedFile()` to have raw bytes
<justin_smith>
fengb: that helps a lot, thanks
<ifreund>
packages aren't a very fleshed out concept yet as we don't yet have a package manager
<justin_smith>
ifreund: one appeal to me is that they don't need to be fleshed out much and most package managers make terrible counterproductive assumptions
<ifreund>
aside from the "std" and "build_options" packages, you can create your own with Builder.addPackage()
<ifreund>
I agree with you in general, though I have realatively high hopes for the future zig package manager
<ifreund>
assuming the same philosophy that has been applied to the language design is applied to it
<justin_smith>
one of the reasons I decided to go "all in" on learning zig was seeing that a package was used the same way a struct is, so much pointless wheel spinning in other languages (and stupid over-complicated features and guard rails) come from making packages and structs arbitrarily distinct
<justin_smith>
these "features" waste so much developer time
<justin_smith>
see also all assumptions of "installing" (global? local? magic via env? oh my god you're killing me)
<ifreund>
I'd be surprised if packages were to change on a language level, they will likely remain normal structs just like files
<justin_smith>
ifreund: yes, if package management shows the same good taste as the rest of the language I'll be all in :D
<ifreund>
what needs some fleshing out is the the build system handling of packages
<justin_smith>
that makes sense, and my preference of the simplicity of the core language guiding how the build system is used trumps my irate rage at the many terrible build systems I've had to use
<jjsullivan1>
have a technical question: do anonymous structs force all their members to be const?
<jjsullivan1>
I've been getting type errors that suggest as much, wondering why that is?
<justin_smith>
jjsullivan1: what about explicitly deriving a new anonymous struct and using that?
<ifreund>
jjsullivan1: not to my knowledge, could you paste the error message/code somewhere?
<jjsullivan1>
I'll paste up a quick example in godbolt, one sec
<pixelherodev>
I haven't touched Wayland as a developer
<pixelherodev>
Only as a user :P
<fengb>
There's weird hacks to make it runtime fields... but realistically, we either need to change these semantics or recommend not using anon literals here
<companion_cube>
pixelherodev: so what pushed you back into the black arts? :p
<fengb>
Or even `var my_anon: struct{ num: u8 = 44 } = .{};` if you want that 44 initialized
<jjsullivan1>
yeah, I think that might work for what I need
<pixelherodev>
companion_cube: TBH, I'm probably not going to use Zig for a serious project until stage2 is done at the earliest
<jjsullivan1>
I wanted to compute a type based on a passed anon argument, and then add more fields to it
<pixelherodev>
It's one reason I'm moving Tricarbon 0.2 into C
<pixelherodev>
Zig is just, realistically, not production-ready.
<ifreund>
eh, it works well enough
<pixelherodev>
At the moment, I'd need LLVM + Clang + Zig just to build small applications.
<ifreund>
I've been running river as my daily driver for months
<pixelherodev>
There's no parallelization in stage1
<pixelherodev>
ifreund: I don't mean code quality.
<pixelherodev>
I mean that comparing GCC to Zig stage1 from a user's perspective, GCC is clearly better.
<ifreund>
that's fair
<ifreund>
for me it's worth it for the nicer language though
<pixelherodev>
No need to constantly update code as the language changes, it performs *significantly* better (make -j is *possible*, for instance), no occasional compiler bugs...
<pixelherodev>
ifreund: which is why I still use it for small, private stuff
<companion_cube>
ah, silly you for writing production code
<pixelherodev>
"Production" is a poor term here lol
<pixelherodev>
I'm the only one who uses it currently, so that's really not accurate
<pixelherodev>
It's more about the eventual "might"
<fengb>
That's why I only write noobduction code
<companion_cube>
ahah damn
<companion_cube>
for that I do rust right now
<ifreund>
pixelherodev: and do you plan another rewrite into zig when stage2 is done? :P
<pixelherodev>
ifreund: noper
<pixelherodev>
nope*
<pixelherodev>
Tricarbon was always intended to operate over the C ABI, not Zig's.
<pixelherodev>
As long as it works with Zig, there's literally no reason to rewrite it
<pixelherodev>
Worst case, I'd @cImport the .c code if that's possible
<justin_smith>
fengb: re: const in anon structs, as a functional programmer in my other life, I don't see the drawback of the idiom of making a new anonymous struct with the modifications you want
<justin_smith>
it's not ideal for memory or perf, but this is compile time
<companion_cube>
pixelherodev: still… C… :/
AlbinoDrought has joined #zig
<justin_smith>
nice idioms to make it clean and recognizable are nice of course
<companion_cube>
today on HN there's a repost of a post on "C's biggest mistake" (in this case, arrays)
<companion_cube>
always a fun read…
<ifreund>
companion_cube: C is pretty much the only alternative to zig for writing perfect software
* companion_cube
looks at his rust side project
<jjsullivan1>
justin_smith: yes to the compile-time thing. I was only using it to add stuff to existing types programmatically
<pixelherodev>
Honestly, I don't dislike C, at all.
<ifreund>
rust doesn't handle allocation failure for one
<companion_cube>
but to be fair, I think I know one "perfect" C program: sqlite.
<ifreund>
that's not perfect software
<pixelherodev>
C99 is probably my fourth- or fifth- favorite language
<companion_cube>
ifreund: irrelevant for my use case.
<pixelherodev>
At least, theoretically
<pixelherodev>
In practical use, it's still #1
<pixelherodev>
Zig as a *language* beats it.
<justin_smith>
fengb: to be able to mutate anonymous structs at compile time, I think you'd get into a potential can of worms of back tracking in the compiler to make sure you used the final final final version, just making a new anonymous struct is much simpler to me
<pixelherodev>
Zig the stage1 compiler does not.
<companion_cube>
that makes sense, pixelherodev.
<justin_smith>
jjsullivan1: right, in that case I think it's simpler to make a new struct and use that one
<justin_smith>
but I think I've made my argument, and all the expertise I'm going on comes from other inferiour languages, so I'll let others speak
<fengb>
I mean more that converting everything into comptime feels weird. .{ .a = @as(u8, 0) } looks like I want a u8 field, but it's not
<pixelherodev>
Honestly, there's a few languages I like better than C that are absolutely devastated by their ecosystems.
<jjsullivan1>
also I wasn't meaning to language-lawyer, what I'm actually trying to do might not be the best way
<pixelherodev>
I like Python, but I loathe pip
<fengb>
But then again... anon literals weren't really intended to capture structure like this
<jjsullivan1>
sorry everyone :^)
<pixelherodev>
I absolutely hate language-specific package repositories
<justin_smith>
jjsullivan1: I don't think an apology is called for (unless you're apologizing for triggering some unuseful bs from me)
<ifreund>
exploring the extent of what a language can do is never a bad thing, even if the code is a weird way to do things
<jjsullivan1>
nono, it's all helpful, I just wasn't meaning to say how things should be or if they're wrong
<jjsullivan1>
I started zig like 3 days ago
<jjsullivan1>
lol
<fengb>
It's great for a new person to experiment with things. Helps find holes in documentation and/or design
<jjsullivan1>
my actual program is encumbered by a lot of misunderstanding atm so I couldn't paste it, I'll probably come back here once I have a better idea of what to do
forgot-password has quit [Ping timeout: 265 seconds]
dtz has quit [Quit: Idle for 30+ days]
metheflea has quit [Quit: Idle for 30+ days]
Akuli has joined #zig
marnix has quit [Read error: Connection reset by peer]
<leeward>
companion_cube: sqlite is a great example of how test coverage does not equal goodness.
<companion_cube>
as far as I know, sqlite has incredibly good coverage… and is also incredibly good
<ifreund>
nice!
<gonz_>
sqlite is indeed extremely good
<gonz_>
Underrated even while it's used in virtually everything
<ikskuh>
yeah, sqlite is really impressive. The API is also really well-made
<companion_cube>
I learnt that its testing is done a lot via Tcl
<companion_cube>
there's an interesting sub-culture of people who like C and Tcl; at least the sqlite and redis authors
<leeward>
I have a friend who does database things, and he has found bugs, differences between spec and implementation (which I guess are bugs), and performance issues. It's better than average, but not perfect.
<gonz_>
sqlite is heaps better than custom file formats, etc., which is what it's competing against.
<gonz_>
It's not supposed to be "Deploy this on a server, scale like you would everything else"
<companion_cube>
leeward: I hope he published that.
<gonz_>
But it's an objectively better choice when one doesn't need a database
<companion_cube>
but otherwise, leeward, what's your example of "perfect" software then? cause I certainly know none.
<leeward>
companion_cube: I do not claim that perfect software exists.
<justin_smith>
JimRM: thanks for sharing, that "write_struct" definition looks reusable enough that I wouldn't be surprised if a) it was already hiding in build.zig somewhere or b) it got included in some form in build.zig in the future
<companion_cube>
ah!
<justin_smith>
at first glance
<leeward>
Also, he did file bug reports. And this was several years ago, so maybe it's been fixed since.
<justin_smith>
JimRM: ahh! arm64, that's the assembly language I'm learning right now as well
<JimRM>
@justin_smith - yeah, that write_struct def is definitely very rough (ignoring errors etc) - I will rewrite it later when I better know what I am doing with Zig
<JimRM>
Quite an interesting challenge writing zig code - as you and up doing a lot of code spelunking to figure out the way to do something (for example, it took me a while to figure out the proper way to create a new file + writing formatted strings to it)
<companion_cube>
leeward: my candidate for "perfect code", if anything… is compcert.inria.fr/
<justin_smith>
but still seems like something we would want to use frequently (and #define rather than a full jump table is probably the right level of exposure, better than my idea for sure)
<companion_cube>
but it's not perfect in other ways (memory allocs and such)
<justin_smith>
companion_cube: I was trying to recall where I saw your nick - inria.fr - you are/were active with OCaml right?
<pixelherodev>
I second leeward's point
<pixelherodev>
There is no "perfect software"
<pixelherodev>
And I doubt there ever will be
<companion_cube>
justin_smith: I am indeed
<companion_cube>
yeah, you can just get into such or such percentile of "bug free"
<ikskuh>
pixelherodev: `true` and `false` are bug-free i think :D
<pixelherodev>
ikskuh: absence of evidence of a bug is not evidence of absence of bugs
<pixelherodev>
:P
<ikskuh>
i can read the complete assembler source for a program that does exactly a single syscall :D
<pixelherodev>
lol, yeah
<pixelherodev>
I was joking obviously ;0
<ikskuh>
we can verify that the source is valid, but maybe the CPOU is not (but that would be faulty hardware)
<pixelherodev>
It also, arguably, requires validating the assembler
<pixelherodev>
and linker
<pixelherodev>
and while you could disassemble it, that requires validating the disassembler ;)
<justin_smith>
ikskuh: or the alignment in the generated binary is off
<justin_smith>
bus error
<ikskuh>
heh :D
<pixelherodev>
or the entry point is listed incorrectly due to a faulty linker optimization
<pixelherodev>
The worst part is that's probably actually possible
<companion_cube>
and updates to the CPU's microcode…
<pixelherodev>
That's HW.
<pixelherodev>
Technically.
<pixelherodev>
... maybe?
<companion_cube>
fuzzy, I guess
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<justin_smith>
if it was hardware, your kernel couldn't update it via software surely
<pixelherodev>
Sure it can
<pixelherodev>
The MMU is hardware
<pixelherodev>
And updating it is arguably one of the kernel's most important jobs
<companion_cube>
does the kernel update the micro code at each boot? or is there ROM in there?
<pixelherodev>
Former, I think
<pixelherodev>
Both, rather
<pixelherodev>
companion_cube: it can be flashed if necessary, but typically an older one is loaded by the BIOS, and the kernel updates it
<companion_cube>
what's the definition of 'software', at this point, is really the question
<pixelherodev>
I'd say everything above the microcode
<pixelherodev>
Anything which passes through the instruction decoder
<companion_cube>
that's a pretty concrete view!
<pixelherodev>
Well, yeah
<pixelherodev>
I don't see any other good definition
<companion_cube>
"anything you can change without a soldering iron" ? :)
<pixelherodev>
Halp, I accidentally wrote a schroedinger program!
<pixelherodev>
:(
<pixelherodev>
It works completely correctly under Valgrind
<pixelherodev>
standalone, or with GDB, it seems to infinite loop
<pixelherodev>
in X11 initialization code!
<pixelherodev>
That makes no sense!
<leeward>
companion_cube: That there is a good definition.
<leeward>
I heard today: "It's the part you can't kick."
<leeward>
pixelherodev: Most data doesn't go through an instruction decoder, and .bss is definitely part of the software.
<pixelherodev>
leeward: how about this? All data which goes through an instruction decoder, *or is loaded by said data*
<leeward>
FPGA images are part of the software package in stuff I've worked on. I mean, I guess it's loaded by software that runs on a different processor if that's included in your definition.
<leeward>
I would also include microcode though. Anything that can be changed without affecting the BOM, really.
<ikskuh>
leeward: i think of FPGAs as emulators for hardware which execute the HW description
ifreund has quit [Ping timeout: 240 seconds]
<ikskuh>
which means if it runs on a FPGA, it's software, but baked in an ASIC it gets hardware
<leeward>
ikskuh: Yes, agreed.
waleee-cl has joined #zig
<ikskuh>
i mean, software is the reason why we invented FPGAs in the first place
<leeward>
If you have to build it in lots of half a million, it's definitely hardware.
<ikskuh>
being able to change things without rebuilding new stuff
<leeward>
Hmm, DIP switch settings can be changed without affecting the BOM and they're not software. My definition needs revision.
<ikskuh>
hm
<pixelherodev>
leeward: "Anything intended to be software."
<ikskuh>
i think it's actually software
<leeward>
Circular definitions are the best kind of definitions.
<ikskuh>
but it's not a program, it's just a n-bit configuration where every switch is one bit
<pixelherodev>
leeward: It's not circular, and I'm partly serious
<pixelherodev>
Microcode isn't intended to be software; thus, it's not.
<pixelherodev>
Ditto to firmware
<leeward>
If you use the word being defined in its definition, it is circular.
<pixelherodev>
The distinctions are entirely based on intent.
<ikskuh>
so dipswitches may *contain* software?
<leeward>
hmm
<leeward>
Where's the distinction between software and configuration? A purely mechanical system might have some switches that change how it functions. Is their state software?
<ikskuh>
well, there were purely mechanical computers
<ikskuh>
so they definitly had software
<leeward>
Kinda mostly true.
<leeward>
Did they have software? Or were they hard coded?
<leeward>
I can build an adder out of relays, but it's not programmable.
<justin_smith>
pdp 10 had switches on the front you could use to bootload
<leeward>
punched tape, sounds like a programmable computer to me
<ikskuh>
leeward: you can build a programmable computer out of metal sheets (no electrical thing)
<ikskuh>
which is what the Z1 is
<justin_smith>
is the graduate student who follows a reference sheet and flips the switches to boot unix a programmer? a config author? a technician? a glorified monkey?
<leeward>
Yeah, I just didn't know people had done it. The window of time where machines were good enough to make mechanical computers but technology hadn't gotten to electronic computers was small.
<ikskuh>
probably just a computer that reads data and executes instructions ;)
<ikskuh>
leeward: Z1 was built by hand afaik
<leeward>
justin_smith: That's a whole different question, but a technician.
<justin_smith>
leeward: fair, thanks
<leeward>
ikskuh: jigsaws haven't always existed.
<justin_smith>
leeward: but still the switches on the front control the bootup, they may or may not be software
<ikskuh>
leeward: i think we have to do this: "{program,configuration} is element of {software}"
<leeward>
Lots of computers are programmed through switches. The software is the information conveyed through them.
<ikskuh>
files are software as well i think
<leeward>
and I think you're right about that ikskuh
<ikskuh>
be back later
<pixelherodev>
So I just rediscovered a joystick driver I wrote :P
<pixelherodev>
I'm 99.9% sure it'll work fine with cImport
_whitelogger has joined #zig
ifreund has joined #zig
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<jjsullivan1>
is there a way to print to the console in a compile-time procedure?
<pixelherodev>
jjsullivan1: no
sawzall has quit [Read error: Connection reset by peer]
<pixelherodev>
Deliberately.
<pixelherodev>
You can use compileLog, but that fails the compilation
sawzall has joined #zig
<jjsullivan1>
is there any kind of debug tooling for compile-time code other than compileLog? Just the test fixture?
<ikskuh>
jjsullivan1: just @compileLog and tests
<ifreund>
hmm, it would be neat if the compiler would let you step through it
<ifreund>
it's totally possible, wonder it there's already an open issue
<ikskuh>
i am confused
<ikskuh>
i get simd-code emitted by zig
<pixelherodev>
ikskuh: and?
<ikskuh>
i explicitly set the CPU as 486
<pixelherodev>
Ah.
<pixelherodev>
Yeah, that'd be a problem
<pixelherodev>
RetrOS, I assume? ;)
<ikskuh>
yeah
<pixelherodev>
I remember I had to submit a patch to disable SIMD correctly when I was working on LIMNOS
<andrewrk>
hmmmm are you sure that using -target x86_64-windows-gnu would be problematic there? what exactly would go wrong?
mokafolio has joined #zig
<andrewrk>
because it's ABI compatible with MSVC
<BaroqueLarouche>
I dunno what could go wrong but I still think keeping full MSVC compat should stay. Is MinGW compatible with the Windows 10 SDK ?
<BaroqueLarouche>
let say I install mingw then the Windows 10 SDK, can I use this toolchain to do Direct3D 12 ?
layneson has quit [Ping timeout: 246 seconds]
<BaroqueLarouche>
with no MSVC install
nullheroes has quit [Quit: WeeChat 2.9]
<andrewrk>
hmm I guess the question there is header file compatibility, which may be an issue
nullheroes has joined #zig
<andrewrk>
if there were zig bindings available then it would work fine
<andrewrk>
you could produce such bindings easily enough with `zig translate-c --libc libc.txt` if you knew where the libc header file paths were
<andrewrk>
that's a chore, but it may be worth it, to eliminate a default dependency on msvc
<BaroqueLarouche>
MSVC dependency should be optional and the code that find libc, include path for MSVC should stay IMO and enabled only when you want it
<andrewrk>
mingw-w64 provides headers for up to d3dx11_43
<andrewrk>
maybe someone could be willing to try to port that to zig
<BaroqueLarouche>
every COM header has a C version to it, with some comptime helpers it is way less painful.
<andrewrk>
that's good to know
<andrewrk>
ok what do you think about, mingw-w64 is the default libc for windows, but msvc is an option, with ability to detect paths
<BaroqueLarouche>
sounds good
<andrewrk>
so you would have to do `-target native-native-msvc` to get it to do msvc path detection
<andrewrk>
I think this is a good idea
<andrewrk>
thanks for the discussion BaroqueLarouche
<BaroqueLarouche>
yup
<andrewrk>
this will make the out-of-the-box experience for zig Just Work on Windows when you do not have MSVC installed. I do not think that is currently true
<BaroqueLarouche>
Some translated headers need to be corrected by hand
<ikskuh>
andrewrk: is there a reason why a call stack might be incomplete in a compiler error message?
<andrewrk>
ikskuh, I think it limits to some set number
<ikskuh>
hm
<ikskuh>
i'm getting a call stack of 2
<andrewrk>
the idea was that you could pass -fno-compile-error-stack-limit or something like that but afaik that's TODO
<andrewrk>
ok 2 is less than that number so never mind that
<ikskuh>
which isn't helpful atm because it's erroring inside std and i cannot find out where something is calling std.debug.warn
jmiven has quit [Quit: reboot]
jmiven has joined #zig
<ikskuh>
hm. giving up for today, bed is calling
<andrewrk>
good night
<andrewrk>
ikskuh, a trick you can do as a workaround, is to temporarily edit the std lib to delete the function
<andrewrk>
it's a bug for sure though, to be clear
<andrewrk>
that's not the intended compile error experience
vgmind has quit [Remote host closed the connection]
<justin_smith>
I'm writing a tutorial to document writing my first non-trivial zig program, is it better to link to the master docs as I go and count on links no rotting, or link to the docs for the specific version I'm using, which I'd assume are published and frozen?
<justin_smith>
I guess those match right now and I can edit easily enough later
<andrewrk>
justin_smith, I suggest to link to the 0.6.0 docs for your blog post
<justin_smith>
thanks
<justin_smith>
in other language communities we have had recurring problems with old / early tutorials having too much google juice, so people would try to use out-of-date techniques or libraries
<justin_smith>
so wanting to avoid those issues pre-emptively as much as I can
<andrewrk>
that's really thoughtful of you
<andrewrk>
we are definitely vulnerable to that here as well
dermetfan has quit [Ping timeout: 240 seconds]
<pixelherodev>
Sorry about the delay; CBE basic arithmetic is good to go