<pixelherodev>
Oh it's been accepted for a year lol
ur5us has quit [Ping timeout: 240 seconds]
BaroqueLarouche has quit [Ping timeout: 244 seconds]
ur5us has joined #zig
BaroqueLarouche has joined #zig
doesntgolf has quit [Read error: Connection reset by peer]
waleee-cl has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #zig
hspak has joined #zig
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
B4s1l3 has joined #zig
B4s1l3 is now known as opDispatch
marnix has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 260 seconds]
marnix has joined #zig
daex has joined #zig
Nypsie has joined #zig
daex_ has joined #zig
daex has quit [Ping timeout: 240 seconds]
haliucinas has quit [Remote host closed the connection]
haliucinas has joined #zig
decentpenguin has quit [Read error: Connection reset by peer]
belse has joined #zig
decentpenguin has joined #zig
<belse>
HI, I was toying around with zig 0.6.0: Is it still possible to init a stack var buffer with a non zero terminated string? for example: var buffer: [16]u8 = "deadbeef" ++ [_]u8{0xa5} ** 8;
<andrewrk>
I would expect that to work
dermetfan has joined #zig
<andrewrk>
belse, in master branch it works if I surround the whole expression with ().*
<andrewrk>
that probably works in 0.6.0 too
<andrewrk>
it's less the problem of null termination and more going from pointer to array
<andrewrk>
hence the deref
<belse>
error: expected type '[16]u8', found '*const [16:0]u8' var text_buffer: [16]u8 = ("99 bottles" ++ ([_]u8{0xa5} ** 6)); this the error I got.
<belse>
yes the pointer conversion is the error
<belse>
so thanks for the deref hint now it compiles ;-)
belse has quit [Ping timeout: 245 seconds]
marnix has quit [Ping timeout: 264 seconds]
mokafolio has quit [Quit: Bye Bye!]
lanodan has quit [Quit: WeeChat 2.8]
dermetfan has quit [Ping timeout: 244 seconds]
marnix has joined #zig
nikita` has joined #zig
<ikskuh>
huh
<ikskuh>
i got a weird analysis bug(?)
<ikskuh>
self-dependency for a pointer in a callback
<leeward>
That depends. How willing are you to update regularly, and how likely are you to submit patches to Zig?
<zigusr>
I see :
<zigusr>
:)
<zigusr>
which are recommended vscode extensions to use ? "zig" ? "zls" ?
<BaroqueLarouche>
both
<zigusr>
leeward: I first want to see what I can do with the language as-is, not debug it's bugs
xackus has joined #zig
<leeward>
zigusr: Stay away from packed structs then. The language and standard library have changed a bit since 0.6.0, but it stays pretty usable. I've been tracking master and I occasionally find regressions, though they get fixed fast.
<leeward>
There are people doing real projects based on 0.6.0, and it's a stable target for learning the language. Any code written in Zig will have to get updated regularly to keep it working until 1.0. If you want to learn the language, I think learning the latest version of it is worth while. If you want to write something big, you're probably better off with 0.6 until 0.7 comes out.
bsrd has joined #zig
marnix has joined #zig
zigusr has quit [Remote host closed the connection]
<leeward>
I need to accept one as an argument to a Zig function.
<ikskuh>
leeward: standard function pointer, callconv(.C)
<ikskuh>
fn() callconv(.C) void
<ikskuh>
is void (*)(void)
<leeward>
So if I have to take an argument that's a function that returns a void pointer, `export fn doThing(callback: fn() callconv(.C) *c_void) void` would be a valid way to express it?
<zigusr>
is there a prebuilt ZLS server?
<leeward>
Ooh, zls is a good reason to track master.
marnix has joined #zig
<Nypsie>
andrewrk: Thanks for the merge! Glad to have contributed. I hope next pr's will be of higher quality :)
moo has joined #zig
wootehfoot has quit [Ping timeout: 240 seconds]
<pixelherodev>
oh lol
<pixelherodev>
`Remove hard tabs from C backend test cases. Shame on you Noam, you are grounded, you should know better, etc. Bad boy.`
<pixelherodev>
hahaha
<Nypsie>
I laughed at that :p
<Nypsie>
No offense xD
<pixelherodev>
None taken lol
<pixelherodev>
First time I've ever gotten called out by name in a commit message like that lol
<pixelherodev>
andrewrk: out of curiousity, what was the issue there?
<pixelherodev>
Stage2 explicitly supports hard tabs, doesn't it? I mean, the tests passed ;)
<leeward>
You don't run zig fmt on save?
<Nypsie>
The tests contain string literals
<leeward>
ohhhh
wootehfoot has joined #zig
<pixelherodev>
Yeah lol
<pixelherodev>
I was using hard tabs for some tests :P
<pixelherodev>
(deliberately :)
moo has quit [Ping timeout: 265 seconds]
<FireFox317>
:(
<FireFox317>
hard tabs are badddd :P
<leeward>
Are they though? I found the accessibility argument compelling.
<pixelherodev>
Same
<leeward>
On the other hand, people who think "indent 4 spaces" means "hit spacebar 4 times" make me angry.
<leeward>
My editor is older than Andrew, and the tab key indents the current line to whatever the correct level is.
marnix has quit [Ping timeout: 258 seconds]
wootehfoot has quit [Ping timeout: 264 seconds]
<fengb>
You make it sounds like he's ancient lol
<leeward>
I'm older.
<leeward>
I couldn't say it's older than I am, because it isn't.
dermetfan has quit [Ping timeout: 272 seconds]
<leeward>
And any piece of software that's old enough to be POTUS is ancient software.
<andrewrk>
pixelherodev, you accidentally incorrectly mixed tabs and spaces, just like everyone always does when hard tabs are involved. the accessibility argument is invalid, tabs are not inherently more accessible, and if they happen to be in practice today, that's not necessarily going to be true in 30 years. and finally, one way to do things. test cases that are not testing tokenization/parsing will be `zig fmt` applied
wootehfoot has joined #zig
<leeward>
I don't think "that's not necessarily going to be true in 30 years" is a strong case for invalidating an argument. Of course the whole argument (in the ticket I'm thinking of) was entirely irrelevant since they're allowed in the language.
<shakesoda>
hard tabs are better anyways
<shakesoda>
FINALLY, MY TIME HAS COME, WE GET TO ARGUE ABOUT THIS AGAIN!
<shakesoda>
:D
<companion_cube>
:ohno:
<shakesoda>
the adjustable width is reason enough that they are massively better, and it's also kind of ridiculous to even care what the indents are when they are of no relevance to the syntax
<shakesoda>
companion_cube: isn't it fun!
<shakesoda>
oh joyous day
<companion_cube>
the adjustable width is why it looks good for you and butt ugly for me
<shakesoda>
then adjust ya width
<companion_cube>
well what if it's in cat? or github? :p
<leeward>
So, the advantage is that you can adjust the width and other people can't?
<companion_cube>
and it has to be done per language, or even per project? ugh
<shakesoda>
for cat i guess you're screwed, github has settings for gist and i'm not going to value paste formatting in a browser in the language
<companion_cube>
well i read code on github sometimes
<companion_cube>
that just sucks if they're using tabs assuming tabwidth=2
<shakesoda>
me too. i barely even notice the indents when they are any value other than 8 (i use 3, myself)
<companion_cube>
I use 2 or 4 depending on the language
<shakesoda>
dunno why i'd change based on the language
<shakesoda>
zig is the only one where i have to do that, because it has a fit about my formatting if i don't.
Ashpool has quit [Quit: Leaving]
<companion_cube>
well some languages have naturally a lot more indentation than others
<companion_cube>
or just different conventions
Akuli has joined #zig
<leeward>
You could just write a sed script to replace "^( )+" with tabs after running zig fmt on file open.
<leeward>
Silly hacks for ridiculous problems.
<shakesoda>
i could, although i'd prefer greatly if it didn't give a shit lol
<shakesoda>
that's enough on it for me i'm really just sitting here dealing with this headache
<shakesoda>
i want to think about thread task scheduling stuff if it'll go away :(
<shakesoda>
the overhead of the lock in my current setup is way, way too much
<shakesoda>
i knew it'd have contention, but that contention is dominating the runtime when workers are >1
<Akuli>
i also know a blind programmer, i haven't asked about their opinion on tabs vs spaces
<companion_cube>
some people have said the opposite, but that's a good reason
<shakesoda>
that is a stronger reason than any of our bikeshedding will ever be
<andrewrk>
it's not real
<shakesoda>
i certainly hope you're not calling accessibility needs fake
<andrewrk>
certainly not. I'm calling tabs not an accessibility feature
<companion_cube>
seems to me like having a zigfmt that can be parametrized is better
<companion_cube>
cause you can also control vertical spacing
<companion_cube>
more line returns, etc
<shakesoda>
having adjustments for things is nearly always an accessibility feature in the end
<shakesoda>
even if you didn't know it
<andrewrk>
the fact that zig can be line-independently-tokenized contributes to accessibility because it makes it easier for an editor to display whatever kind of spacing it needs to for visually impaired users
<ifreund>
disagree, zig fmt has become my favorite code formatter I've ever used
<Akuli>
in a formatter-formatted project, teaching an editor to convert back and forth should be easy enough without introducing huge diffs, so maybe just let users specify number of spaces used for indentation when running 'zig fmt'?
<companion_cube>
shakesoda: you could take leading spaces and multiply them by 2, too
<companion_cube>
or 4
<ifreund>
config options would ruin it
<andrewrk>
same deal for screen readers. the fundamental difference this makes completely eclipses anything to do with indentation control charactors
<shakesoda>
screen readers certainly don't seem likely to give a crap about the control characters
<shakesoda>
(dunno why they would)
<ifreund>
the best part is that it doesn't know about line length, which keeps things so much simpler
<companion_cube>
ifreund: what's "it"?
<ifreund>
and it doesn't do dumb things like use spaces for alignment
<ifreund>
companion_cube: it is zig fmt
<companion_cube>
ah right
<fengb>
My favorite part is that adding trailing commas will force wrap
<shakesoda>
i've spent an inordinate amount of time fighting people to stop aligning their damned equals/vars
<Akuli>
alignment-spaces tend to be quite annoying, especially when people put them with like 60 spaces in front of each aligned line
<fengb>
So you can have shorter lines if you want to
<companion_cube>
alignment is a waste of time
<shakesoda>
because someone always comes in and tries to align after the indent with hard tabs
<shakesoda>
and this is the one case where you should unquestionably never use hard tabs, ever
<Akuli>
emacs (ew) does the align-with-hard-tabs by default, at least for c code
<shakesoda>
you also just shouldn't bother with the alignment
<shakesoda>
Akuli: that's disgusting
<Akuli>
at least i think it did last time i tried, same with gnu indent
<andrewrk>
just want to put it on the record that we had our first instance ever in the zig repo of incorrectly mixed tabs/spaces last week, and it's due to stage2 accepting hard tabs
<shakesoda>
does it error on mixing?
<andrewrk>
no, stage2 accepts but zig fmt corrects
<shakesoda>
so someone didn't zig fmt
<andrewrk>
right
<andrewrk>
status quo is: anything that zig fmt can correct, stage2 accepts
<fengb>
We should revoke their contribution rights
<andrewrk>
it's ok I already put them in time out
<shakesoda>
andrewrk: that's reasonable
<Akuli>
:D
<Akuli>
maybe recommend a pre-commit hook that checks whether files have been zig-fmted?
<leeward>
I think Emacs uses GNU style for C by default, which is awful and nobody ever uses it.
<shakesoda>
precommit hooks make me uneasy
<andrewrk>
this "tabs are for visually impaired accessibility" is nothing but "think of the children". of course accessibility is an important use case, but that doesn't mean to turn your brain off
<leeward>
The only worse thing I've ever seen is bluez's style guide.
<Akuli>
andrewrk, i agree, and i don't use tabs in programming languages that strongly recommend against it like python or zig
<shakesoda>
andrewrk: nor is writing it off as "think of the children" sufficient to totally ignore the claim
<Akuli>
that would just annoy so many more people than it would benefit
<shakesoda>
the brain should remain on either way
<andrewrk>
agreed
<leeward>
Akuli: Emacs's zig-mode runs zig fmt on save by default, fwiw.
<Akuli>
nice
<companion_cube>
shakesoda: it's also a strong argument against python, btw
<andrewrk>
the 4coder editor abstracts indentation entirely
<companion_cube>
whitespace sensitive must be hell if you're visually impaired
<leeward>
andrewrk: I like how that article provides context for what this Microsoft corporation is.
cmrs has joined #zig
<shakesoda>
andrewrk: the (particularly short-term) memory problems are actually exactly what drive me toward languages like zig to begin with, with the focus on clarity.
<shakesoda>
and, more broadly, toward simplicity in designs (and especially away from needless abstractions that force you into needing lots of context)
cmrs has quit [Client Quit]
<shakesoda>
designs that don't hide what's actually happening, and don't provide facilities to sweep everything under the rug (looking at you, inheritance), really help with the overhead of needing to pick up lost context frequently
cmrs has joined #zig
<andrewrk>
I guess we are the same in that regard
<andrewrk>
I feel like I forget things easily too
<leeward>
Where was that quote about debugging complexity...
<shakesoda>
maybe, i'm way off the deep end in the degree of it but it's not at all uncommon. it causes issues at work sometimes, though, when i've been tasked with working on some multiple-levels-inherited disaster
<leeward>
Oh yeah, Kernighan: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
<shakesoda>
and the only way i can work on it is by ripping that part of the system apart and building it directly, as it should've been to begin with :)
<pixelherodev>
andrewrk: do we have register shuffling in stage2 currently?
cmrs has joined #zig
<pixelherodev>
It's the one thing I had in #5411 that I thought was worth salvaging
<andrewrk>
not yet
<pixelherodev>
Gotcha
<pixelherodev>
Should I just close it?
<pixelherodev>
I decided to clean up my old ones to save you a bit of time
<andrewrk>
there, closed
<pixelherodev>
:P
<andrewrk>
I'm working up to a test case to implement the more complicated register allocation bits
<andrewrk>
there's plenty to do that doesn't depend on that
<pixelherodev>
I'm going to try getting #5514 fixed; that's the only other PR I have open rn (other than SPU II, which is active)
<shakesoda>
and as for the hearing stuff... it makes my life easier if any zsf related videos, should they start to exist, provide captioning :)
<shakesoda>
captioning is also great for memory stuff, a lot less repeated rewinding
<shakesoda>
little to do with the language itself, of course.
<fengb>
Well news to Mr. Kernighan, double 0 is still 0
<shakesoda>
?
<fengb>
Okay that came off as poorly done
<leeward>
Are you saying your max level of cleverness is 0, fengb?
<companion_cube>
that's because he overflowed when doubling
blinghound has joined #zig
<leeward>
Oh is cleverness signed now?
<shakesoda>
re: cleverness in programming. i'm always up for removing my prior arrogance (fka cleverness) upon later discovery
<fengb>
Yes that was what I attempted. But I failed pretty hard
<fengb>
I guess I'm not as clever as I thought
<companion_cube>
leeward: have you never met any moron? :p
<companion_cube>
(or seen them on tv, say)
<fengb>
I haven't watched the White House press in awhile no
<leeward>
companion_cube: I was making an undefined behavior joke. Apparently it worked as well as fengb's cleverness joke.
<companion_cube>
well it's because we're in a safe space
<companion_cube>
not a --release-fast one 🙃
<leeward>
/facepalm
* pixelherodev
rolls eyes
<andrewrk>
politics strictly off topic here
<leeward>
shakesoda: I find that clever people and simple code are positively correlated.
<leeward>
Anyone can brute force their way to something that works, but it takes smarts to make it comprehensible.
<Akuli>
i'm working on a thing and it started out as a huge and complicated script that auto-generated thousands of lines of code, now i don't have that script anymore at all :D
<companion_cube>
sometimes brute force won't even get you to something that works
doesntgolf has quit [Ping timeout: 258 seconds]
<leeward>
Sure, if you have time constraints.
<companion_cube>
or if the problem is just too hard
xackus_ has quit [Ping timeout: 246 seconds]
<pixelherodev>
lol
<leeward>
Right, time constraints. Like "must execute before the universe cools."
<pixelherodev>
Haha
<shakesoda>
leeward: yeah, i'm often impressed at the simplicity of code by people far more clever than i
<companion_cube>
"before my body cools" is sooner :s
<leeward>
companion_cube: We can hope.
<companion_cube>
not sure if it's an attack on me, or worry the universe will die very soon
<pixelherodev>
Just walk into an incinerator before you die, then your body will cease to exist before it has a chance to cool!
<pixelherodev>
Can't have a time constraint relative to your body cooling... *if you don't have a body!*
<shakesoda>
that said, cleverness isn't one dimensional and some people most certainly more powerful than i create some terrifying monsters pretty regularly too...
<leeward>
Nothing personal, companion_cube, but if the universe cools before your body does we're all screwed.
<companion_cube>
pixelherodev: I tend to be thrown into incinerators, not walked thereinto
<leeward>
That is an unfortunate tendency.
marnix has quit [Ping timeout: 240 seconds]
<pixelherodev>
Yeah
<leeward>
Is async/await in good enough shape to use these days? I've got a pthreads event loop that I'd like to reimplement in Zig.
<pixelherodev>
I believe so, but I don't use it mysefl
<pixelherodev>
myslef8
<pixelherodev>
myself*
<pixelherodev>
Damit
<pixelherodev>
Dammit*
<andrewrk>
leeward, it's good enough for proof of concept applications but I wouldn't call it production ready yet
<leeward>
andrewrk: Good enough. I wouldn't call Zig production ready :P
<fengb>
Just don't be surprised if LLVM tells you it doesn't dominate everything
<leeward>
I think we need an IRC client with a plugin that forces a 1-second delay between messages. Hit whatever the "send" button is too soon and you're forced to re-read the line you just wrote before actually sending it.
<leeward>
fengb: I don't get it.
<fengb>
It's andrewrk's favorite error message
<shakesoda>
i kinda feel like zig is more production ready than most languages actually in production. i don't know who this is a stronger statement about.
<ifreund>
shakesoda: maybe, but C is the competiton here
<ifreund>
not the javascript dialect of the month
<shakesoda>
ifreund: i rest my case ;)
<shakesoda>
...i say, as still very much a current c user
<leeward>
shakesoda: "production ready" means it implements the language spec with no known bugs, or at least none in commonly used areas. I've found maybe 4 bugs in production C compilers in the last 15 years.
<leeward>
Also that the language spec is complete.
<shakesoda>
leeward: that's a lot more specific than i feel the common usage of the phrase tends to be
<shakesoda>
and yeah, i can't remember the last actual bug i ran into with a c compiler. c++, on the other hand...
* shakesoda
grumbles something about needless complexity causing bugs everywhere
<leeward>
shakesoda: I've never worked on a project where working around a rapidly changing language was a thing we did. C++ is a hot mess, but I know people writing code for surgical robots in it.
<fengb>
Even JS the language doesn't change all that much. The ecosystem OTOH...
* pixelherodev
agrees with shakesoda
<companion_cube>
JS grows quite quickly, does it not?
<pixelherodev>
I've run into multiple LLVM bugs
<shakesoda>
leeward: it's not like i believe c++ to be unsuitable for serious work. i've just certainly run into more problems (actual bugs) than c
<pixelherodev>
^ yes, exactly
<fengb>
No, there's minor updates to the language every year (like 2-3 things)
<leeward>
I think Python is the most rapidly changing language I've actually used in production. We used a new feature that came out in 3.6 before 3.8 was released.
<fengb>
Up until 2015, there's been a total of 4ish versions
<leeward>
shakesoda: Oh, I do believe it's unsuitable; it's just that people use it anyway.
<shakesoda>
leeward: heh, fair enough
<leeward>
pixelherodev: How many of the LLVM bugs you've found caused it to emit incorrect machine code given valid C input?
<shakesoda>
leeward: the fastest changing thing i've used in production, by a long shot, is haxe
<shakesoda>
but it's a transpiler anyways, and what it actually builds to doesn't change *that* much.
<shakesoda>
i've run into a multitude of bugs in it but i quite happily have a lot of games built largely with it
<leeward>
That raises a big point about what "production" means. The gulf between "entertainment product that can be updated by users after launch" it's very different from "thing that lives inside a human being for 10-15 years and administers drugs."
<shakesoda>
yep, exactly
<andrewrk>
I wonder if we'll beat rust to a lang spec
<andrewrk>
we beat them to a non-profit org :)
<shakesoda>
andrewrk: aren't they run by mozilla still?
<leeward>
I don't know if I would be willing to bet a company I ran on Zig, but if the risk is that we have to rewrite everything in C for hundreds of thousands of dollars I probably wouldn't veto game developers who wanted to use it.
<shakesoda>
last i was aware mozilla is a nonprofit, it's just not a rust-dedicated one
<shakesoda>
leeward: that seems fair to me
<leeward>
There are people working on a language spec for a subset of Rust, but I would not be surprised if Zig had something before they did.
<shakesoda>
rust happens to have the language problem known as "being complicated"
<leeward>
Rust is the language people who like "modern C++" use, plus a borrow checker. It's incredibly complicated.
<shakesoda>
that's about consistent with my observation of it, too, although i'd certainly prefer encountering the rust to said modern c++
<shakesoda>
in the general case
<leeward>
Well, to be fair, minus some awful bits of modern C++.
<ifreund>
it has some nice things like fancy pattern matching to ease the pain brought on by complexity
<shakesoda>
it has some nice things like <complexity> to ease the pain brought on by complexity
<shakesoda>
:D
<shakesoda>
to be sure, i'm all for nice pattern matching.
<leeward>
Hey, pattern matching is awesome. Rust stole a lot of good ideas from the FP world.
<ifreund>
I'd take rust over c++ hands down if given the choice
<shakesoda>
it's fine, i just can't help but read it as addressing complexity with complexity.
<pixelherodev>
leeward: none
<shakesoda>
it's a useful complexity, though.
<ifreund>
but zig is even better
<leeward>
pixelherodev: none which?
<pixelherodev>
No bugs in LLVM caused incorrect output for me
<leeward>
oh
<pixelherodev>
They were more often infinite loops
<pixelherodev>
Which ate up RAMworse than other people's web browsers
<shakesoda>
i'd be willing to rewrite our product at work in zig if i could get my coworkers on board for the transition.
<shakesoda>
i have at least that level of confidence
<leeward>
Well, if it was triggered by valid C code I'd say it qualifies. No output can be incorrect output.
<pixelherodev>
leeward: valid Zig, actually
<pixelherodev>
Not C
<pixelherodev>
Never once had an issue with any C compiler
<pixelherodev>
Well, no x64 C compiler at least
<leeward>
Yeah, my thesis was about Zig not being production ready so that kinda supports it.
<leeward>
:P
<pixelherodev>
Not really
<pixelherodev>
leeward: it wasn't a Zig bug, Zig was 100% correct in all such cases
<pixelherodev>
They were LLVM bugs which would have affected similar C *or* C++ code
<leeward>
The fact that the only implementation of Zig had a bug?
<pixelherodev>
Optimizer bugs
<shakesoda>
there are a few potential complications though (for example, i don't know if zig would cause me problems for consoles - this is an unknown that would need to be addressed)
<andrewrk>
llvm bugs are zig bugs if llvm is the only backend
<pixelherodev>
True
<leeward>
^^
<pixelherodev>
That's one reason I don't want LLVM support :P
<leeward>
I don't think that's a good reason not to want LLVM support, but that's a separate issue. I'll be happy to concede that they're different as soon as there's a Zig implementation without the bugs.
<leeward>
Ecstatic, actually.
* pixelherodev
resumes work on stage2
<pixelherodev>
;)
<ifreund>
I don't think a self hosted optimizer to truely replace llvm would make any sense before 1.0, if ever
<pixelherodev>
I disagree
<leeward>
ifreund: Agreed.
<pixelherodev>
For stage2 it makes perfect sense
<pixelherodev>
Ah wait
<pixelherodev>
I don't think it would ever make sense to have that level of optimizations at all
<andrewrk>
I think there are 1 or 2 optimization passes we can do that would be simple, maintainable, and get us 50% of the way to matching llvm runtime perf
<pixelherodev>
But some basic stuff would make sense the instant we're good
<FireFox317>
leeward, is the thesis public?
<pixelherodev>
DCE + CSE elimination + constant propagation would probably be more than 50% of LLVM perf
<leeward>
Optimizing code is a hard problem, and zillions of developer hours have been spent on it. I don't see a reason to reinvent that particular wheel before we have "working" down.
<pixelherodev>
It's really not as difficult as a lot of people think. Basic optimization isn't that hard
<andrewrk>
agreed leeward
<leeward>
FireFox317: Umm, it's whatever I said in the chat history here: C is production ready; Zig isn't.
<andrewrk>
"working" is priority number one for me
<pixelherodev>
It's the really complex stuff - which we don't have any reason to do *anyways* - that gets tricky
<pixelherodev>
Basic optimizations are jus tthat
<shakesoda>
i just want faster debug turnaround and just enough optimization that it's tolerable
<leeward>
andrewrk: That's why we love you.
<pixelherodev>
I do agree that "working" is easily the priority though
<pixelherodev>
On that note, going to try figuring out why it's trying to target WASM64
<andrewrk>
I'm happy to report the result locations in stage2 are clean so far
<pixelherodev>
Awesome
<pixelherodev>
we're making really really good progress here :)
<shakesoda>
as it stands, debug turnaround is pretty bad, doesn't help that zig builder doesn't do concurrency
<andrewrk>
not fully implemented, and still need to add comptime into the mix. but looking good
<FireFox317>
nice andrewrk!
<shakesoda>
but concurrency in the build is already a workaround for slow builds :)
<andrewrk>
also not sure if anyone saw this the other night:
<andrewrk>
<andrewrk> it's not uncommon to see a successful test output this in stage2: [info] (compiler): Update completed in 0 ms
<andrewrk>
and that's a debug build of stage2
<Akuli>
:D
<leeward>
whoah
<shakesoda>
sounds like you need to make it report in micros
<andrewrk>
I'm sure it will get slower with more complicated test cases ;)
<Akuli>
is it actually that fast or is it just not doing anything?
<Sahnvour>
andrewrk: care to expand a bit on what it means ? recompiling a test case ?
<leeward>
Doing as little as possible is the key to being fast, right?
<shakesoda>
i usually have to report with better granularity than milliseconds, but again i work in games
<Sahnvour>
leeward: no code is faster than no code :)
<andrewrk>
Sahnvour, I believe it was this test case: https://clbin.com/p8V5r with build-exe
<andrewrk>
super trivial code
<andrewrk>
but that 0 ms includes tokenization, parsing, analysis, codegen, and writing the ELF file
<Sahnvour>
that's cool
<Akuli>
zig will be soo much faster than c++ compilers lol
<shakesoda>
Akuli: the bar is low...
<Akuli>
that bar is really low yeah
<fengb>
Faster than Rust too :P
<andrewrk>
let's see a couple more PRs and then I think I can justify getting back to work on stage2 :)
<shakesoda>
andrewrk: will stage2 be wired up with flags/info for build profiling? that kind of stuff is useful
<companion_cube>
t r a c y
<shakesoda>
cl has such things and it really comes in handy for finding build anomalies
<Sahnvour>
zig will probably do frontend way faster than C++ compilers, but the backend time (for optimized builds) will be similar due to LLVM
<andrewrk>
yeah we have pretty nice tracy integration already
<shakesoda>
works for me
<andrewrk>
I'll take another screenshot after I get some more features working, but here's an old one
<Sahnvour>
shakesoda: tried the new microsoft cl profiler on my code recently, it said that the code was too fast to bother measuring, and didn't output anything valuable
<shakesoda>
oh, the tracy stuff is in zig's build.zig
<shakesoda>
no wonder i wasn't seeing it
<andrewrk>
oh yeah, and we build the TracyClient.cpp as part of the build script. that was so so convenient. it's like these projects were made for each other
<Sahnvour>
couple hires, meaning Loris and full-time dev ?
<blinghound>
awesome to hear it's moving so fast :D
<ifreund>
Sahnvour: check the meeting minutes :D
<Nypsie>
^ worth it :P
<Sahnvour>
awesome
FireFox317 has quit [Ping timeout: 244 seconds]
<fengb>
Whoa there's some secret stuff in here
<companion_cube>
wooooooa what
<ifreund>
openness is pretty awesome
<companion_cube>
the name of the finite time contractor :o
<andrewrk>
next chore on my end is to set up a meeting with vexu :)
<fengb>
Wait he doesn't know yet? >_>
<Sahnvour>
andrew will make him an offer he can't refuse
<andrewrk>
well I had to get approval to make the offer
<andrewrk>
I did ask him if he was interested already and he said Very Yes
<fengb>
Are you the boss?? :P
<fengb>
Aren't
<andrewrk>
nope! the board members have legal power to kick me out if I misbehave
<shakesoda>
"benevolent dictator for the duration of the board's approval" may be accurate but it just doesn't have the same ring to it.
<Sahnvour>
I'm not familiar with US legislation: article III says "No members." does that mean the foundation will only be composed of board members ?
<scientes>
I have been convinced that zig does not need confusing strict aliasing. Because we can just make structs never alias (and strict aliasing is only cross-type---MLIR is doing all the cutting edge work on intra-type aliasing), as we can just say that zig stucts (which do not follow the C ABI) never alias
<andrewrk>
Sahnvour, I'm not sure what the alternative is
<fengb>
Benevolent dictator who can be deposed by a military coup :P
<andrewrk>
scientes, that's a nice observation, I hadn't thought of that
<leeward>
Boards hire people to run their corporations all the time. That's why president and CEO aren't always the same job.
<leeward>
My last company actually replaced the CEO as president, but he stayed on as CEO on the board.
<fengb>
I think members are synonymous with owners here. And a non-profit has no owners by definition
<scientes>
this does mean that single-element structs are NOT guaranteed to be the same as just the type
<Sahnvour>
one could imagine community members wanting to be part of the foundation, but I guess that's only relevant if they'd have some say over how the whole project is run
<fengb>
I think they can be elected to the board, but they still won't derive percentages from the foundation
<fengb>
They can also be hired as a contractor or employee
<andrewrk>
scientes, yes it's already true that memory layout of single field structs is not guaranteed
Akuli has quit [Quit: Leaving]
<andrewrk>
this is a nice realization, I think we can avoid some potentially buggy and confusing aliasing language features with this knowledge
<andrewrk>
I'll go live as soon as llvm 11 finishes building
<Sahnvour>
fengb: so this means that anyone can candidate to the board, with ne requirements ?
<Sahnvour>
s/ne/no/
<blinghound>
how long does llvm take to build these days?
<fengb>
"Each Director will have such qualifications as may be determined by the Board."
<fengb>
The cabal determines the cabal :P
<Sahnvour>
hmm
<Sahnvour>
foreign country legalese is not easy :)
<Sahnvour>
blinghound: mostly depends on your number of CPU cores
<Sahnvour>
last hardware upgrade got it down from ~2 hours to under 10 minutes for me
<blinghound>
jesus that's an insane upgrade
<ifreund>
ram is also quite important
<ifreund>
quantity and speed
<Sahnvour>
yep apparently it has so much to link that if your build system is efficient (as in, you use ninja) you can get oom quite easily
blinghound49 has joined #zig
blinghound49 has quit [Remote host closed the connection]
<pixelherodev>
LLVM is simply massive
<shakesoda>
sounds like i'd be waiting many hours then
<shakesoda>
with my near-decade old i7
<pixelherodev>
Building llvm-reduce alone took a ridiculous amount of time fo rme
cole-h has quit [Quit: Goodbye]
Nypsie has quit [Quit: WeeChat 2.8]
<torque>
llvm has simply followed the path of all good software projects, becoming an enormous, incomprehensible blob of millions of lines of code
* yeti
gets tears looking at stuff like esp32 today... far more capable than the early PCs but not autark... needing PCs as nanny... near to no compilers or OSes run natively on them
<yeti>
32bit, dualcore, 240MHz, 8½M RAM... IBM AT/03 was "smaller" and did not need a nanny
<yeti>
complexity will kill us
doesntgolf has joined #zig
nvmd has quit [Quit: Later nerds.]
<shakesoda>
yeti: i think about this every time i work on one of my rpis
<shakesoda>
they don't need a nanny, but software does really hold them back