<FireFox317_>
andrewrk, #8348 is ready for review. basically the big boi optional test case in the llvm backend works. expect for one line, which i think has something to do with `.alloc_inferred_mut`
<andrewrk>
thanks! taking a look shortly
dimenus has joined #zig
<ifreund>
you know what would be nice, a single std.mem function that did mem.bytesAsSlice(u32, mem.sliceAsBytes(args.param_types))
<ifreund>
and with that I'm going to sleep, will rebase and hopefully finish up my refactor in the morning
<andrewrk>
good night! looking forward to that sweet, sweet type safety
<dimenus>
so what was the decision? non-exhaustive enum?
<andrewrk>
yeah sounds like ifreund came up with something reasonable with a non-exhaustive enum
<dimenus>
andrewrk: a couple years ago I remember thinking, man Zig really needed the arbitrary AST modification of JAI - but I was wrong
<dimenus>
Zig has ended up in the sweet spot with enough functionality and still a simple enough language
<andrewrk>
:)
brzg has joined #zig
powerofzero has joined #zig
<powerofzero>
Does anyone know of a conveinient way to recursivly iterate through a directory?
<g-w1>
std.fs.Walker
<andrewrk>
note also std.fs.walkPath
<andrewrk>
looks like there is some usage examples in std/fs/test.zig
<powerofzero>
Thanks! missed that.
a_chou has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
gazler_ has joined #zig
jumpnbrownweasel has joined #zig
gazler has quit [Ping timeout: 256 seconds]
FireFox317_ has quit [Ping timeout: 240 seconds]
paulgrmn__ has joined #zig
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
skuzzymiglet has quit [Remote host closed the connection]
brzg has quit [Quit: leaving]
a_chou has quit [Ping timeout: 245 seconds]
earnestly has quit [Ping timeout: 260 seconds]
paulgrmn__ has quit [Ping timeout: 256 seconds]
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
notzmv has quit [Ping timeout: 258 seconds]
powerofzero has quit [Ping timeout: 260 seconds]
dimenus has quit [Ping timeout: 260 seconds]
notzmv has joined #zig
fputs has joined #zig
ur5us_ has quit [Ping timeout: 258 seconds]
jjido has quit [Quit: Connection closed for inactivity]
rohb has quit [Ping timeout: 264 seconds]
rowbee has joined #zig
xackus has joined #zig
leon-p has joined #zig
xackus_ has joined #zig
kbd has joined #zig
xackus has quit [Ping timeout: 245 seconds]
<kbd>
Here are the things I'd been working on to learn Zig. Figured I'd share, since I just finished the readme, and say thanks for the help I received here.
<kbd>
https://github.com/kbd/prompt is a portable shell prompt, which also uses 'repo_status' (also in Zig, linked in prompt's readme) to print git status info in your prompt. The code in the latter esp. needs a little work still.
<kbd>
Also, I don't free memory properly anywhere. Since this is a run-and-exit thing it doesn't matter if I drop memory on the floor. I'd like to fix, but it wasn't important to getting it working.
<txdv>
Just like php!
<kbd>
:)
<andrewrk>
ifreund, g-w1, dimenus, FireFox: I commented out all the failing test cases, so we can run `./zig build test-stage2` now in the zir-memory-layout branch
<txdv>
did you just work 5 hours straight on that?
<txdv>
Wow the 1mil line memory usage drop is impressive
<txdv>
Can you maybe benchmark compilation of the entire zig std?
sord937 has joined #zig
dfacto7 has joined #zig
dfacto has quit [Ping timeout: 245 seconds]
dfacto7 is now known as dfacto
kbd has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
RadekCh has joined #zig
<andrewrk>
I wish
<andrewrk>
the self-hosted compiler does not support that many language features yet
<txdv>
O stupid me, you are rewriting like everything :D
yeti has quit [Ping timeout: 240 seconds]
eddyb[legacy] has quit [Ping timeout: 240 seconds]
yeti has joined #zig
FireFox317_ has joined #zig
skuzzymiglet has joined #zig
dyeplexer has joined #zig
yyp has joined #zig
xackus has quit [Remote host closed the connection]
xackus has joined #zig
<FireFox317_>
andrewrk, are you still online?
<FireFox317_>
i think the change of putting .store_to_inferred_ptr in the outer scope is actually not correct
_whitelogger has joined #zig
<FireFox317_>
hmm maybe not, still investigating
sundbp has joined #zig
earnestly has joined #zig
ur5us_ has joined #zig
cole-h has quit [Ping timeout: 264 seconds]
FireFox317 has joined #zig
FireFox317_ has quit [Ping timeout: 244 seconds]
dddddd_ has joined #zig
ur5us_ has quit [Ping timeout: 264 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
dbohdan has joined #zig
<dbohdan>
How small can you make a "Hello, world!" x86 Linux ELF file written in Zig? Has anyone performed an experiment like http://timelessname.com/elfbin/ with Zig? (That person got the size down to ~3K with C and 142 bytes with assembly.)
<ikskuh>
dbohdan: https://zigbin.io/237c1c takes up 5408 with "zig build-exe -O ReleaseSmall --strip hello.zig"
<Nypsie>
That's still bigger than from the article I linked :P
<ifreund>
ikskuh: did you use the strip command from binutils as well?
<ifreund>
I got ~3K with an idiomatic hello world just now
<ikskuh>
Nypsie: i only took a minute to do so :D
<ikskuh>
that article probably took longer
<dbohdan>
I got it down to 1424 bytes with `./zig build-obj -O ReleaseSmall --strip hello.zig; ld -n -s -o hello hello.o`
<ikskuh>
*installs elfkickers*
<ikskuh>
sstrip → 4096 :D
<dbohdan>
But, wow, 277 bytes is pretty small
<dbohdan>
Though I am not sure that kind of high-level code is easier to write than assembly :-)
<earnestly>
It's not assembly that gets it that low
<dbohdan>
I guess it may pay for itself if you start building on in a program more complex than a "Hello, world!"
<earnestly>
It's taking advantage of kernel level features and assumptions
cryptocode has joined #zig
<cryptocode>
https://zigbin.io/3b2c7d Anyone seen that compiler bug before (I'm on master)? Not much in the way of hints towards what in my code causes it. Also surprised to see mingw in there, this is mac. Most likely causes by a move move from StringArrayHashMap to ArrayHashMap in my code.
<noam>
ha, I just stumbled on andrewrk's libsoundio while tracking down an issue involving S24_3LE audio in a completely unrelated application. Small world!
Snetry has quit [Read error: Connection reset by peer]
<forgot-password>
Is it possible to get call site information at comptime? I have some custom wrapper to automatically check for OpenGL errors and it would be awesome if it could automatically point to where the error was generated
<forgot-password>
Instead of just saying call "xy" generated an error, which is ambiguous
Rudde has joined #zig
<Rudde>
Hey
<forgot-password>
Hi
<Rudde>
didn't expect this channel to have so many members
<ifreund>
zig is pretty sweet
<Rudde>
So I've heard
<ifreund>
forgot-password: no, there's not a way to do that aside frome passing @src() as an argument at all callsites
<Rudde>
Got stuck in very-high level languages after uni.
<Rudde>
And trygint to get back to systems programming languages just seem to tidious
<noam>
ifreund: ?
<noam>
ahhh
<noam>
huh, looks neat
<ifreund>
it's also what lead to zig :D
<noam>
whoaaaaa
<noam>
really?!
<noam>
..actually no that makes sense
<noam>
There's a lot of things that I find annoying in C, I can see how Andrew would get fedup and decide "okay new language time."
<noam>
The only function that needs to know the type is ensure_capacity
<noam>
Aside from that, all accesses are explicitly typed
<noam>
ensure_capacity, then `list[0] = (struct foo){};` for instance
<noam>
With some convenience functions here and there
<noam>
e.g. `push_u32(&u32_list, u32)` ensures capacity, pushes, and increases count
<noam>
but ensure_capacity is the *only* function that cares
<noam>
and even then, if you change to a bigger type it'll work but waste RAM :P
<noam>
ifreund: I didn't say that Zig didn't improve it
<noam>
I was disagreeing that this is a big deal
<noam>
for more complex types, that might not be true, though
<ifreund>
noam: link to the code? I still think this is a pretty big deal
<noam>
git.sr.ht/~pixelherodev/zyg
<noam>
stb.{h,c}
<noam>
pick any random c file and it
<noam>
's probably using it
<noam>
it's *not* actually from stb; I *was* using the stb one but it was macro abusive
paulgrmn__ has joined #zig
<FireFox317>
andrewrk, nvm, it was a mistake in my code :) #8348 is ready
dbohdan has left #zig [#zig]
<ifreund>
noam: ok, so you need a new push() function for every type in order to have relative type safety with a resonable API, and you don't currently have type safety for any of the non-specialized functions
<noam>
ifreund: no, wrong
<noam>
push is a convenience function.
<noam>
Ahhhh, wait, I see what you're saying
<noam>
No, the issue is fundamentally that ensure_capacity needs to know size
<noam>
Everything else uses typed accesses
<noam>
There's nothing *to* be safe about for non-push functions
<ifreund>
and that if you change the type of the variable in which your stb array is stored, your code still compiles
<ifreund>
cause void pointers
<noam>
no, it won't
<noam>
the arrays aren't void*
<noam>
they're e.g. int*
<noam>
or struct scope*
<noam>
(scope.c)
<noam>
changing that to to int* *will* cause 99% of uses to compile error
<noam>
because it's *accessed as a scope-pointer*
<ifreund>
you can still pass literally any pointer as the first argument of the first 5 functions in stb.h and not get a compile error
<ifreund>
that's what I'm talking about
<noam>
So?
<noam>
It's basically realloc
<ifreund>
yeah, and that sucks too
<noam>
It's not any different from being able to do int* foo; foo=realloc(foo, sizeof(int)...)`
<noam>
ifreund: no it doesn't... again, the *only thing* that *won't* give you a compile error is the actual allocation!
<noam>
if you change foo to, say, `struct bigint*` there, it *will* cause numerous compile errors
<noam>
unlike in C++, where a constructor might implicitly convert it in ways you don't want
<ifreund>
I really don't see where the compile error comes from in that example, realloc takes and returns a void*
<noam>
realloc won't
<noam>
but EVERYTHING ELSE will
<noam>
`foo[0] = 0;` <- invalid
<noam>
or in my case, `ctx.list[0].subscopes[i]`
<noam>
that's only valid if list is a `scope*`
<noam>
change the type and the code won't compile
<ifreund>
noam: the fact that realloc won't is exactly what I'm talking about
<noam>
But it doesn't *matter* that realloc won't
<noam>
because everything immediately next to it will
<ifreund>
the point is that when refactoring, the compiler won't remind you to update that realloc or stb_foo() call if you update the rest of the code
<noam>
Sure, one line
<noam>
`grep ensure_capacity *`
<ifreund>
and don't tell me you'll just remember cause it's obvious
<noam>
Of course not
<noam>
but I could easily e.g. add a git hook
<ifreund>
or that you can expect every contributor to run a grep
<noam>
sure
RadekCh has quit [Quit: Ping timeout (120 seconds)]
<noam>
ifreund: I *would* expect that I'd review any contributions and I'd have on the patch review script "is this a refactor"
<ifreund>
that sounds like a good idea, but it's still possible to forget that and have broken code compile without error
<ifreund>
my point is mostly that C's type system is not powerful enough to support this use-case in a satisfying and robust way
<noam>
ifreund: sure /shrug
<noam>
I don't particualrly care
<noam>
I can understand why you would, but it's not something I see as a big deal
<ifreund>
you can certainly put practices into place to ease the pain, but it doesn't 100% fix things
<noam>
If that *did* happen, it'd be *trivial* tofigure out with a debugger
<ifreund>
to be fair, your stb thing is one of the nicer abstractions for this I've seen for C
<noam>
"this allocation is sized wrong" - valgrind would be good for that - is pretty easy to track down
fputs has quit [Quit: WeeChat 3.1]
fputs has joined #zig
m4r35n357 has quit [Quit: Ex-Chat]
Cadey has quit [Quit: WeeChat 3.0]
Xe has joined #zig
Rum has joined #zig
<noam>
ifreund: Thanks, I tried :P
<noam>
I've seen horrible ones, so I knew what not to do
<noam>
:P
<dimenus>
ifreund: i don't imagine you need a PR to bring zig-wayland up to master?
<dimenus>
also i really like how these bindings turned out
bitmapper has joined #zig
lanodan has quit [Quit: WeeChat 3.0]
<ifreund>
dimenus: zig-wayland tracks the lastest release like river. If you want to use it with master please do submit a PR with your changes, would save me some time when 0.8.0 releases
<ifreund>
and if you have more questions I usually direct excessive zig+wayland related chatter to #river :)
<dimenus>
ifreund: understood
<cryptocode>
If I pass a hash function (by mistake) returning u64 instead of u32 to ArrayHashMap, the compiler bugs out with https://zigbin.io/3b2c7d So it's not at all obvious what the problem is from that trace. Is the root cause already reported/knows, or should I make an issue?
<cryptocode>
known*
<noam>
"it's a stage1 bug, wait for stage2"
<cryptocode>
hehe
<cryptocode>
I suppose I can wait for that
<noam>
...
<cryptocode>
!!!
<noam>
I wasn't serious, you should probably report that
<cryptocode>
Well, your joke reply is probably a valid reply
<g-w1>
(it probably wont get fixed until stage2 tho unless someone wants to dig around in stage1)
<cryptocode>
right
<noam>
(which is nobody)
<cryptocode>
(looks like it)
<noam>
(nobody loves stage1)
<g-w1>
whenever i fix something in stage1, i break something else
<cryptocode>
Like... as for reporting, how likely is it that these kinds of bugs gets ported to stage2? :)
<g-w1>
very unlikely
<noam>
0%
<g-w1>
the code is ***much*** cleaner
<noam>
There's a chancce of a similar bug popping up
<cryptocode>
g-w1: wen stage2 :D
<Nypsie>
soon (tm)
<ikskuh>
cryptocode: good thing is that stage-2 is not a *port*
<g-w1>
probably in 2-3 release cycles
<cryptocode>
ikskuh: yeah, that was badly phrased haha
<g-w1>
so around a year
<cryptocode>
i see
<cryptocode>
I suspect stage1 reports are just an annoyance
<g-w1>
i dont lol, half the time, by changing something else i cant repro them anymore
Rum has quit [Read error: Connection reset by peer]
<cryptocode>
damn, zig c++ -target is so friggin useful, use it all the time now so I can keep touching windoze to a minimum
<noam>
hm
<noam>
Honestly, I'm not sure anyone's realistically intending to care about stage1
<noam>
Realistically, it'd probably be easier to update my compiler than to fix stage1 bugs, and that's if I die today and don't continue rushing through it :P
bbuccianti has joined #zig
<noam>
writing a zig compiler isn't really that hard
<noam>
...well. for me, who has years of obsessive experience with systems work, emulation, and the intracicies of computers :P
<cryptocode>
you do it for fun or other reasons?
<noam>
yes
<cryptocode>
:D
<noam>
fun, but also so I can work on a bootloader for the Rock64
<cryptocode>
awesome
<g-w1>
the only time people care about stage1 is when it uses too much memory for the ci and you have to fix it
<noam>
^
<FireFox317>
noam, you should be able to write a bootloader for Rock64 with stage1 :P
<noam>
FireFox317: Nope
<FireFox317>
noam, why not?
<cryptocode>
g-w1: i noticed someone onced fixed that with Boehm :D
<noam>
FireFox317: you're forgetting my OS ;)
<noam>
And the system intended to self-host
<FireFox317>
noam, ahh, okay well yeah then stage1 is not gonna work xd
<g-w1>
stage1 doesn't support plan9 linker format
<noam>
and is written in C++
<noam>
and uses LLVM and Clang
<noam>
So you'd have to port literally 5 million lines of (awful) C++
<noam>
or remove stage1's minor C++ feature usage and replace the backend
waleee-cl has joined #zig
cryptocode has quit [Quit: leaving]
jumpnbrownweasel has quit [Quit: Connection closed]
olabaz has joined #zig
<olabaz>
Hi, I was writing a wrapper around a c library but then I realized this might be pointless since it is so easy to interface with c. What are your thoughts on this?
<noam>
Wrappers can be useful in zig
<noam>
They're not *necessary*, but they can make the C bits feel like Zig
<noam>
Working directly with imported C can feel kludgy
<olabaz>
I guess you can also add nicer error handling
<olabaz>
I was trying to wrap a numerical algorithm library, but I wasn't sure how adding an error would affect performance?
<noam>
Shouldn't
<noam>
Negligible at worst
lanodan has joined #zig
forgot-password has quit [Ping timeout: 260 seconds]
philtor has joined #zig
ifreund has quit [Ping timeout: 246 seconds]
kbd has joined #zig
ifreund has joined #zig
tnorth has quit [Quit: Konversation terminated!]
skuzzymiglet1 has joined #zig
M-ou-se has quit [Ping timeout: 258 seconds]
M-ou-se has joined #zig
skuzzymiglet1 has left #zig [#zig]
notzmv has quit [Ping timeout: 264 seconds]
jaens[m] has quit [Ping timeout: 268 seconds]
ugla has quit [Ping timeout: 260 seconds]
Snektron has quit [Ping timeout: 260 seconds]
kshlm has quit [Ping timeout: 260 seconds]
jaens[m] has joined #zig
jicksaw has quit [Ping timeout: 264 seconds]
ugla has joined #zig
vegai has quit [Quit: leaving]
Snektron has joined #zig
jicksaw has joined #zig
cryptocode has joined #zig
<cryptocode>
was there a way to determine if I'm running in test mode, or do I just negate a flag myself in main?
<andrewrk>
inefficient compilation speed for directEnumArray with non-exhaustive enums
<andrewrk>
never mind! clarified with SpexGuy that zig guarantees memory layout on enums if you specify the tag type
Akuli has quit [Quit: Leaving]
jumpnbrownweasel has quit [Quit: Connection closed]
<dimenus>
ifreund's zig-wayland bindings make the protocol so easy to work with
sundbp has quit [Ping timeout: 245 seconds]
mokafolio has quit [Quit: Bye Bye!]
<noam>
andrewrk: speed problem fixed? :)
<andrewrk>
yeah it had to do with the fact that extern enums can have duplicate tag names
<andrewrk>
but we don't need an extern enum here
ed_t has quit [Quit: Leaving]
<andrewrk>
memory leak fixed. just needed to free the previous function when replacing it with a new one during incremental compilation
<andrewrk>
1 liner
notzmv has joined #zig
<andrewrk>
it's nice getting memory leak errors immediately in the development cycle. they're so easy to fix when you freshly wrote the code that caused it
mokafolio has joined #zig
<marler8997>
even better when they're caught at comptime? possible?
<noam>
With a comptime allocator, maybe
<marler8997>
how would a comptime allocator catch memory leaks done by a runtime allocator?
<noam>
Partially comptime functions?
<noam>
Have the context contain comptime information