<emekankurumeh[m]>
if you are interacting with a c api that accepts null pointers do you use c pointers or nullable pointers?
scientes has quit [Remote host closed the connection]
scientes has joined #zig
voldyman has quit [Quit: Connection closed for inactivity]
lygaret has joined #zig
scientes has quit [Remote host closed the connection]
fengb has joined #zig
<fengb>
emekankurumeh[m]: I think those convert to the same thing underneath the covers https://pastebin.com/6S9wMZdZ
<fengb>
So preferably do zig nulls and toss it over to C as is
<emekankurumeh[m]>
nvm c pointers are null terminated not just "auto-nullable"
apoddubn has quit [Quit: Connection closed for inactivity]
fengb has quit [Ping timeout: 256 seconds]
marmotini_ has joined #zig
<daurnimator>
silly idea: what if we bundled *everything* into one executable. so that even all the .libc files were just embedded?
<daurnimator>
that way there's just a single file "zig.exe" and it doesn't need installing ... or ... well.... anything beyond running it
<emekankurumeh[m]>
wouldn't that make the zig compiler a massive binary?
<shritesh>
A few megs more at most
marmotini_ has quit [Ping timeout: 245 seconds]
<shritesh>
The lib directory that’s shipped compresses really well afaik
<daurnimator>
emekankurumeh[m]: maybe... but so what?
<shritesh>
It’s just 4K nvm
<emekankurumeh[m]>
i suppose that's not that much
<shritesh>
That was the inode size. I’m an idiot
<emekankurumeh[m]>
but some of zig's source files are quite large for just pure text
<daurnimator>
FWIW I'm not suggesting this as the "normal" way on linux; but would be good on windows; or embedded platforms where the concept of a filesystem is a bit more fuzzyb
<emekankurumeh[m]>
src/ir.cpp is 1.03MB
<shritesh>
3.3M compressed tarball
<shritesh>
We don’t need to ship the src, do we? Only the lib directory with the header files.
<daurnimator>
shritesh: we ship libc files and std/ .
<shritesh>
That’s what I meant
<shritesh>
We can extract and cache it on the first run like with musl
<shritesh>
But I don’t think package managers will like it
<daurnimator>
10:41:24 <daurnimator>FWIW I'm not suggesting this as the "normal" way on linux
<daurnimator>
fengb: nope. I mainly don't understand your diagrams :p
<fengb>
Boo
<daurnimator>
also not sure which comment you actually want me to review
<fengb>
Just the diagrams... but eh don't worry
<fengb>
I'll fail forwards :P
<fengb>
I've discovered where to store metadata and I'm trying to shove it alongside the allocated memory
<daurnimator>
fengb: okay so the first question you get to ask is: before or after?
<daurnimator>
(or both)
<daurnimator>
for classic C allocators, you must put it before: C's 'free' only gets the pointer to the start; not the length
<fengb>
Before for that reason lol
<fengb>
I ran into this issue because of C interop
<daurnimator>
now a problem is: dealing with alignment. if your base allocator gives out e.g. only align(4) blocks; and zig asks for a 16 aligned block: what do you do?
<daurnimator>
note that your metadata will need to move *with* the re-aligning
<fengb>
So my base data structure only supports align(8)
<daurnimator>
which also means that your metadata will probably want to store the "real" allocation size
<fengb>
And I'm thinking of using padding to get to 16
<fengb>
And just giving up after 16
<daurnimator>
fengb: and what if I want align(4096)
<fengb>
Well... I've no idea >_>
<fengb>
I have one idea to support up to page_size / 2 alignment, but it's quite complicated
<daurnimator>
fengb: and now you know why working on an allocator is a danger to your mind ;)
<tgschultz>
only if you insist on making it one size fits all
<daurnimator>
fengb: I can try and show you my allocator WIP tonight or tomorrow if you want
<fengb>
Gotta make improvements!
<daurnimator>
yours is tending in the same direction
<fengb>
I'm never getting back to my emulator
<daurnimator>
emekankurumeh[m]: just saw your PR #2598 ... could you split up the windows/OSX stuff up into a different commit? or at least mention it in the PR...
<emekankurumeh[m]>
np
<fengb>
Should I be passing structs as value most of the time?
<daurnimator>
fengb: yep.
<daurnimator>
fengb: only time to pass as pointer is if you want to modify it
<fengb>
Okay, so Zig is smart enough to choose the correct strategy? (Is C smart enough too and I've been being bad?)
<daurnimator>
andrewrk: I think you should do a release when you get copy elision done (possibly wait for coroutines): there's so much since 0.4.0 already!
<shachaf>
In C what happens when you pass struct arguments by value is specified by the calling convention, it's not up to the compiler.
<emekankurumeh[m]>
zig doesn't have a calling convention so it's free to do what's most efficient
<fengb>
Ah okay thanks
marijnfs has joined #zig
<daurnimator>
there's no system-wide zig-cache is there?
marijnfs__ has quit [Ping timeout: 272 seconds]
<daurnimator>
I would like to package the cache for `zig fmt` in the distro package. otherwise its slow everytime you run it from a new directory. also it ends up littering zig-cache directories all over the place
<daurnimator>
filed as an issue.
lunamn has quit [Quit: leaving]
lunamn has joined #zig
redj has quit [Read error: Connection reset by peer]
redj has joined #zig
_whitelogger has joined #zig
lygaret has quit [Read error: Connection reset by peer]
scientes has joined #zig
<scientes>
so what is the roadmap to lambdas and closures?
<scientes>
actually llvm might be able to do what i need without those
shawn_ has joined #zig
scientes has quit [Read error: Connection reset by peer]
noonien has quit [Quit: Connection closed for inactivity]
kristoff_it has joined #zig
<shawn_>
shit, I think I have something that can only be done with a macro....
shawn_ is now known as scientes
scientes has quit [Ping timeout: 258 seconds]
kristoff_it has quit [Ping timeout: 248 seconds]
marmotini_ has joined #zig
fengb has quit [Ping timeout: 256 seconds]
<andrewrk>
This third attempt at no copy semantics is working beautifully. Actually made substantial progress today
very-mediocre has joined #zig
<daurnimator>
andrewrk: yay :D
avoidr has quit [Quit: leaving]
kristoff_it has joined #zig
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
SamTebbs33 has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
<tralamazza>
euantor: do you know a good zig library example?
<euantor>
Depends on what you're wanting to do @tralamazza - is this just to look at an example Zig program?
<tralamazza>
how to organize multi arch code
<tralamazza>
in a zig library
<tralamazza>
to answer your question: yes
kristoff_it has quit [Ping timeout: 248 seconds]
<SamTebbs33>
I only just joined the channel so don't thave the full context of the conversation, but if you'd like to compile different code depending on the architecture, you can do so by using the std.builtin.arch variable, which is of type std.builtin.Arch
<shritesh>
I didn’t realize the run button was to be pressed multiple times. My bad lol.
<Xe>
eh it's more of a "you can do this" thing lol
<Xe>
i need to figure out some way to avoid it having to parse the wordlist every time
<Xe>
i would really like it if zig had something like go's func init() that ran with the start instruction in wasm
<Xe>
could just shove god into a "global" lol
<shritesh>
Go can do that because of the assumptions set by the go wasm runtime. But you can have an init function. And then something like a next() to get the actual values.
<shritesh>
xterm.css is not being loaded, you might want to look into that too.
<fengb>
lol... zee_alloc has a smaller export when using release-safe over release-small
<Xe>
shritesh: i think part of my problem is that i relied on a third party .js and .css file
<Xe>
i should have downloaded them locally
<Xe>
i just wanted to avoid the NPM and webpack skinsanity
mouldysammich is now known as sammich
<Xe>
now i know for next time :)
sammich is now known as mouldysammich
<shritesh>
fengb: release-small was the largest for zig-fmt-web
<shritesh>
Xe: any reason you’re using xterm.js?
<Xe>
shritesh: you know there's not really a good reason for it i guess
<Xe>
it made sense for another demo of mine, and i just copy-pasted the code from it because i wanted it to work
<Xe>
lol
<tralamazza>
fengb: ty
<shritesh>
It’s a really good terminal emulator but I didn’t get why it was here. Makes sense lol
<Xe>
shritesh: it's overkill for this case yeah
<Xe>
i'm going to obviate it in the future
<fengb>
shritesh: is that an LLVM backend issue?
<fengb>
I also feel like "release-safe" isn't the best language. It sounds like training wheels
<fengb>
s/language/vernacular
mouldysammich is now known as sammich
<shritesh>
fengb: I think it’s just the semantics of WebAssembly. Before a wasm module is loaded, it is validated by the runtime and maybe a lot of checks get compiled away.
<fengb>
But small should always be <= safe
<shritesh>
Probably.
<shritesh>
I also agree about the release modes. release-safe should just be called release. release-fast will then feel like an explicit opt-in to trading safety for speed.
avoidr has joined #zig
<kristoff_it>
I have a C allocator that gives me word-aligned memory, which I have to cast using @alignCast. What's a good way of saying "word-aligned"? I'm currently using @alignOf(usize), is this good enough?
marmotini has joined #zig
marmotini_ has quit [Ping timeout: 258 seconds]
jjido has joined #zig
marmotini has quit [Ping timeout: 272 seconds]
<tgschultz>
Assuming the traditional definition of "word" and not the MS API definition, I think so, yes.
Ichorio has joined #zig
<fengb>
til win32 WORD == 16 bits
<kristoff_it>
lol til too, thanks tgschultz
<merlyndmg>
apparently in the intel/amd docs "word" in their jargon = 16 bits since forever (or so says the person who wrote a correction on my ancient stack overflow answer a couple weeks ago)
<tgschultz>
considering their procs still boot into real mode that isn't super surprising
<merlyndmg>
but yeah, they still refer to them by those names, so WORD is jargon in their manuals (even if I'm joking about them trademarking those names)
<merlyndmg>
I guess that sort of kind of promotes better backwards compatibility on their own stuff...
apoddubn has quit [Quit: Connection closed for inactivity]
very-mediocre has quit [Ping timeout: 256 seconds]
very-mediocre has joined #zig
jjido has quit [Quit: Connection closed for inactivity]
Aransentin has quit [Ping timeout: 256 seconds]
kristoff_it has quit [Read error: Connection reset by peer]
THFKA4 has joined #zig
lygaret has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
scientes has quit [Quit: Leaving]
scientes has joined #zig
heitzmann has quit [Quit: WeeChat 2.4]
wilsonk has quit [Ping timeout: 248 seconds]
_whitelogger has joined #zig
halosghost has quit [Quit: WeeChat 2.4]
hio has quit [Quit: Connection closed for inactivity]
gamester has joined #zig
<gamester>
You know, I think I've had enough of Linux as a desktop OS. I've used it exclusively for 10 years and it just kinda changes but doesn't really get better. I've had an insane amount of issues every year for some reason. I'm done. Let's make a new OS at some point. Zig shows what's possible when you start fresh.
<gamester>
I mean at least every single system call has to be rethought. Yeah, those are my thoughts. I don't want to take things off topic though.
<tgschultz>
Those thoughts are a bit outdated, I have more ideas now for direction
<tgschultz>
But the most important thing I think is to keep it simple. No overcomplicated abstractions, no presumptive automation, etc. The problem with that is that hardware is absurdly complicated these days so you pretty much have to use an existing OS just to get a servicable amount of hardware support.
<tgschultz>
I'd be willing to abandon most of modern computing and use something like a Raspberry Pi, but only if there were such a thing as a completely open hardware platform. Which there isn't.
fengb has quit [Ping timeout: 256 seconds]
<tgschultz>
I should update that blog post, actually.
gamester has joined #zig
<gamester>
tgschultz: thanks for the link, I'll take a look. I'm just in the middle of windows installment (gonna try WSL so I can use vim), running to the store, etc
<nrdmn>
what an odd solution
kristoff_it has joined #zig
<gamester>
nrdmn: Oh yeah? If I hit the Windows/Super key on Gnome + Wayland + Nvidia it'll pick a random window and display that window for all the windows. That's one random example of the thousands of issues I come across
<gamester>
well it's not a random example, but yeah
<gamester>
nrdmn: oh maybe vim is supported on windows
<emekankurumeh[m]>
gvim
<emekankurumeh[m]>
or neovim, but you might run into issues if you use it in conjunction with msys2
<shritesh>
I switched to Windows because the audio playing through my (beefy) linux box would stutter when I was compiling zig
<scientes>
shritesh, you just have to use ionice and nice
<gamester>
heh, audio stutters for me and the audio driver hits an unreachable state and logs it to systemd. I talked to a developer and he guessed a hardware issue, which may be true but I don't see the issue on windows
<gamester>
I've had that issue for months
<shritesh>
I don’t want to use an OS on the desktop where I have to worry about those things :)
<scientes>
I can't really convince you, but on Linux you can just submit the patch upstream
<nrdmn>
all of this doesn't sound particularly linux related
<shritesh>
The music played fine on Mac and Windows lol
<scientes>
I had a Nexus 7 and high bit-rate mp3 ALWAYS studdered, because the device had a special cpu for doing low-power audio, but they only tested it with 128kbps mp3s
<mikdusan1>
gamester: you are installing windows as a vm?
<gamester>
mikdusan1: no
<mikdusan1>
are you wanting to use vim by ssh'ing into the machine? or from its graphics console
<gamester>
mikdusan1: gvim on windows is fine. I'm good.
* scientes
can't stand windows
<scientes>
I haven't used anything since windows xp either
<tgschultz>
yes well, some of us have serious complaints about the Linux Desktop "experience" too, we should try to avoid an OS flamewar here though