<shcv>
you might be able to get them to accept a patch
<shcv>
but an overlay would probably be better, since you could update it faster
<shcv>
I tried modifying the existing ebuild, but apparently there's more to it than just changing the llvm versions...
<shcv>
and I don't know much about cmake
<shcv>
well, downloading a functional binary was much more effective than my last few hours of trying to build with LLVM...
<shcv>
thanks for reminding me that was a possibility; I've gotten too accustomed to using a source-based distribution :P
<pixelherodev>
shcv: no such thing!
<pixelherodev>
I think you mean, too accustomed to things working properly lol
<pixelherodev>
This is on LLVM, not Gentoo ;)
ur5us has quit [Ping timeout: 260 seconds]
<leeward>
Hmm, -femit-docs does not seem to be working correctly.
<leeward>
Seems like it only spits out //! comments, not ///.
factormystic has quit [Read error: Connection reset by peer]
ur5us has joined #zig
<pixelherodev>
andrewrk: also, are patches fixing memory leaks rejected? Or will you *personally* not bother?
student069 has joined #zig
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 258 seconds]
aerona has joined #zig
<shcv>
pixelherodev: well, I meant I'm too accustomed to building things from source that I forgot about the possibility of a binary distribution...
<shcv>
(since I just spent hours trying to build it myself)
<shcv>
I don't blame gentoo for individual package issues anyway
gazler_ has joined #zig
gazler has quit [Ping timeout: 260 seconds]
nephele_ has joined #zig
nephele has quit [Ping timeout: 260 seconds]
nephele_ is now known as nephele
ur5us has quit [Ping timeout: 260 seconds]
stripedpajamas has joined #zig
ur5us has joined #zig
<leeward>
Who was it that was talking about iterators and reversing lists a little while ago?
<leeward>
I did some implementing and testing, and using an iterator is very very slightly faster in all the Release* modes, and takes about 4/3 as long in Debug.
<leeward>
At least, the implementation that seemed most obvious to me.
<pixelherodev>
Gah
<pixelherodev>
Going to have to rebase :P
<pixelherodev>
If I had to pick my favorite thing about the ast-to-zir branch, it's the refactoring
<pixelherodev>
old_inst -> src_decl
<pixelherodev>
(as an example)
<pixelherodev>
More useful naming schemes!
<pixelherodev>
... that's a bad example though :P
casaca has joined #zig
<pixelherodev>
`:4:13: error: TODO implement type coercion from fn() callconv(.Naked) noreturn to []const u8` Oops.
slowtyper has joined #zig
<pixelherodev>
So many changes gah :P
<andrewrk>
pixelherodev, by all means, please improve the memory utilization of stage1. there is even a configuration option you can enable to help troubleshoot
<andrewrk>
marler8997, oh man thank you so much for doing that, I was putting that off today
<marler8997>
don't thank me yet, we'll see if I can get it to work first :)
<marler8997>
looks like that pipelines xml you mentioned in the issue has the exact same issue
<andrewrk>
oh, bummer
<marler8997>
I think it's this, "dash" use to depend on "msys2-base", and "filesystem" provided "msys2-base". But the new version of "filesystem" does not provide "msys2-base" and the new version of "dash" does not depend on "msys2-base". But pacman tries to update "filesystem" before dash, so it fails because it breaks the "dash" dependency on "msys2-base"
<cren>
greenfork: I was trying to avoid that because so many new languages bill themselves as "better [language]" that I thought describing it as "better C" would make it sound cliche and a fad
<cren>
leeward: that's a good source, thanks
<ifreund>
a modern systems programming langauge that prioritizes simplicity and clarity and aims to beat C at its own game
<companion_cube>
weird, I haven't heard a lot of languages described this way
<leeward>
Fair warning: if you're trying to sell it for real use in real products, it's probably not ready. There are still bugs in the compiler and the language itself has more than 0 breaking changes in its future.
<fengb>
D even has -betterC flag
<companion_cube>
I mean, there's C++, D, rust… and that's about it?
<ifreund>
yup, the goal should not be to get people to use it for production software, but rather to put Zig on the radar of as many people as possible
<greenfork>
cren: people try to make up great ideas about ALL IS SAFE or ALL IS PURE but what we really need is a better language which uses the already established foundation and makes it better on the rough edges
<leeward>
companion_cube: Don't forget Objective C, and I would put Rust in the "better C++" category.
<companion_cube>
arguably rust can compete with C in many domains, even though some people might find it more complex a language
<leeward>
Heck, C is "Better BCPL"
<cren>
rust is good at concurrency, no?
<companion_cube>
should be, yes
<ifreund>
I definitely would as well, though they've definitely marketed rust as "better C" before
<companion_cube>
C++ is marketed as better C too :D
<companion_cube>
depending, again, on what your use case for C is
<leeward>
It's right in the name.
<companion_cube>
yep
<cren>
rust was developed for using in firefox iirc, and firefox was already written in C++, so it was written for a similar use case
<fengb>
Hell, even Go marketed as better C to some degree
<ifreund>
all depends on your use case really
<companion_cube>
well Go is misguided :
<companion_cube>
:p
<leeward>
cren: Rust is good at concurrency. So are Go and Erlang, for what it's worth.
<companion_cube>
cren: but a lot of C projects moved to C++, even gcc
<companion_cube>
(and a ton of videogames, of course)
<leeward>
I guess anything that calls itself a systems programming language is going to intersect C's use case some.
<greenfork>
experience shows that Better C is a very good marketing strategy, could as well use it
<ifreund>
do people write desktop software in erlang? it's mostly just for servers right?
<companion_cube>
I think so
<leeward>
ifreund: Servers and embedded stuff.
<leeward>
It got its start in switches.
<mq32>
<ifreund> a modern systems programming langauge that prioritizes simplicity and clarity and aims to beat C at its own game
<ifreund>
that makes sense
<mq32>
nice summery!
<fengb>
Well, Go wanted to replace C for things like nginx, which it does pretty well
<fengb>
There's erlang for embedded?
<companion_cube>
if you consider routers to be embedded, I imagine?
<leeward>
fengb: For certain values of embedded, definitely. If you have the RAM to run a BEAM VM, it's pretty well suited.
<leeward>
I would call network switches and routers embedded. Resource constrained isn't the only kind of embedded system.
<companion_cube>
embedded is stuff no one ever has a session on? :)
<leeward>
That depends. Is "embedded Linux" an oxymoron?
<companion_cube>
I don't think so
<leeward>
Maybe no customer ever has a session on it, but developers do all the time.
<mq32>
<companion_cube> embedded is stuff no one ever has a session on? :)
<mq32>
i think that fits pretty well
<mq32>
embedded systems are not meant for "user sessions", but mostly "machine session" (however this is used in the end)
emekoi has joined #zig
<leeward>
By that metric, yes. Erlang is definitely used in embedded systems.
<companion_cube>
I guess it makes my raspberry pi an embedded system-ish then :D
<leeward>
ish
<leeward>
depends on what you use it for
<companion_cube>
small server... so I guess not
riba has joined #zig
<leeward>
I can't get `zig -femit-docs build-lib` to spit out any actual documentation. The symbols are pub; do I have to do anything special?
blinghound has joined #zig
<blinghound>
is it possible to construct an array of tagged unions at compile time?
<ifreund>
as long as the size of the array is comptime known, sure
blinghound46 has quit [Remote host closed the connection]
marmotini has joined #zig
nycex has joined #zig
<blinghound>
oops, connection problems
<blinghound>
thanks guys, I'll have a fiddle and see if I can reproduce
marmotini_ has quit [Ping timeout: 256 seconds]
cren has quit [Remote host closed the connection]
traviss has quit [Remote host closed the connection]
traviss has joined #zig
<marler8997>
andrewrk, I ran into a few issues with the latest proposed memory allocator interface. I was able to address them by adding an additional function to the interface to get the full capacity of an allocation.
<marler8997>
let me know your thoughts
traviss has quit [Remote host closed the connection]
<blinghound>
I updated to master and I stopped getting the error: cannot assign to constant, but then the build fails during what *seems* like compilation of sqlite3.c, with no information other than 'The following command exited with error code 5:.....'
<blinghound>
nothing changed in my project other than updating to master
<blinghound>
ok I removed sqlite3 and I'm getting the same union error: cannot assign to constant as before
<ifreund>
i think you'll need to post more code, as you can see from the example I send it works
<ifreund>
tested with 0.6.0
<ifreund>
works with master too
<blinghound>
yup, I'll try to reproduce the error with a minimal example and report back
traviss has joined #zig
shcv has quit [Read error: Connection reset by peer]
shcv has joined #zig
nokierae has quit [Quit: Connection closed]
<tgschultz>
crazy idea: now that we have @frame() and @Frame(), would it be possible to allow access to the stack variables inside the frame? It seems to me that implementations of generators and other state machines could be made simpler that way.
<ifreund>
that would be pretty crazy
<ifreund>
seems possible though
<fengb>
Pretty sure that'd be unsound with how async works internally. I think andrewrk is semi-open for using the same plumbing for actual generators though
emekoi has quit [Remote host closed the connection]
emekoi has joined #zig
layneson has joined #zig
<daurnimator>
tgschultz: what would you get that you don't already with using the address of operator on local variables?
jmiven has quit [Quit: bye]
jmiven has joined #zig
<tgschultz>
not having to do that, for one. fewer pointers means fewer footguns.
layneson has quit [Ping timeout: 260 seconds]
dermetfan has joined #zig
layneson has joined #zig
<fraktor>
This might be a weird request, but is it possible to have std.fmt formats have named parameters?
<ifreund>
not currently afaik
<fraktor>
Would that be useful, or would it just complicate things?
<fraktor>
The particular use case I'm looking at is structured logging, which would be possible if named parameters were combined with std.log'
<fraktor>
s ability to redefine log handling.
<ifreund>
i don't see why you'd need named parameters for structed logging
<fengb>
It's possible. The docstring mentions it
<fengb>
Oh wait, it's only position not named. My bad
layneson has quit [Ping timeout: 260 seconds]
layneson has joined #zig
<ifreund>
i feel like all you need for structured logging is the custom format fn for user types
<ifreund>
and then you make a type that does what you want
<fraktor>
Is it possible to do that with anonymous types? I'd also like to be able to use libraries and still get some useful output from it.
cole-h has joined #zig
<leeward>
I'm trying to use @fieldParentPtr and clearly doing it wrong. Here's a minimal example: https://godbolt.org/z/shvJUL Anyone know what I'm missing?
<ifreund>
leeward: you hit the footgun of the implicit struct copy with =
<ifreund>
make it const iface = &thing.iface;
<leeward>
Ahah!
<leeward>
Thanks, that was really bugging me.
<ifreund>
i think this needs really needs to require an explict memcpy
<ifreund>
there's an open proposal iirc
<leeward>
An open proposal to require struct copies to be explicit?
<ifreund>
i seem to remember another related proposal as well
<leeward>
3803 is linked in that one
<leeward>
This feels like the equivalent of not providing a copy constructor in C++.
<shakesoda>
heh, nice gotcha
<ifreund>
it doesn't seem to be suggested in the proposal, but I would rather do what C does and require an explicit memcpy instead of introducing new syntax
<ifreund>
i thought I saw that mentioned somewhere but couldn't find it
<leeward>
Yeah, I don't see it in either proposal.
<andrewrk>
turns out we needed to install tar with pacman
<marler8997>
andrewrk, ah!
<marler8997>
to prevent this from happening in the future, zig could host it's own msys packages
<andrewrk>
anyway thanks to your work we are no longer depending on a deprecated git repo
<marler8997>
yeah that'll be good
blinghound has quit [Remote host closed the connection]
riba has joined #zig
aruniiird has quit [Ping timeout: 258 seconds]
heitzmann has joined #zig
heitzmann has quit [Quit: WeeChat 2.8]
heitzmann has joined #zig
waleee-cl has joined #zig
r4pr0n has quit [Remote host closed the connection]
r4pr0n has joined #zig
aruniiird has joined #zig
<pixelherodev>
How long until bitrot claims the CI once more? :P
<leeward>
First Tuesday of July
<pixelherodev>
You seem a bit... *too* sure of that
<leeward>
It's when Microsoft releases patches.
satchmo has quit [Ping timeout: 240 seconds]
<pixelherodev>
Haha
<leeward>
I used to work at a security company. The first Tuesday of every month was a scramble to make sure we could detect all the vulnerabilities that were patched...because nobody patches.
<pixelherodev>
lol
<pixelherodev>
That's great? awful? grawful?
st4ll1 has joined #zig
wootehfoot has joined #zig
<andrewrk>
wonderful, now sr.ht is failing
<mq32>
andrewrk, can you stop breaking the internet, please?
<ifreund>
looks like the sr.ht rebuild might be fine though
blinghound has joined #zig
aruniiird has quit [Quit: Leaving]
<pixelherodev>
lol :P
<pixelherodev>
The sr.ht one breaking feels weird, because it's the one that usually passes when I break stage2 stuff XD
<pixelherodev>
(since the tests don't run on there yet :P)
<leeward>
Alright, I'm going to do a write-up of Zig's idiom for generic interfaces. Maybe tonight.
Aransentin has joined #zig
riba has quit [Ping timeout: 256 seconds]
<andrewrk>
tfw when you merge 3+ pull requests per day, and each day there are more open than the previous day
blinghound has quit [Remote host closed the connection]
<leeward>
andrewrk: On the plus side, it means progress is being made. Merging PRs ought to be faster than writing code.
<mq32>
another *really cool* target architecture would be Parallax Propeller 1 & 2
<marler8997>
andrewrk, I ran int a few places where code needed to know the full capacity of an allocation that didn't have access to the allocFn return value
<marler8997>
I started explaining the issues yesterday but you didn't respond
<andrewrk>
ah, I'll go check the chat logs
<marler8997>
I saved the branch that doesn't include the capacityFn function as well
<andrewrk>
oh I see. I didn't understand at first that the semantics of allocFn were changed, thanks for being patient with me
Aransentin has quit [Remote host closed the connection]
<marler8997>
I removed the length from the return value of allocFn and resizeFn, the client already knows they size they requested, and the allocator already needs to support capacityFn, so it made sense to remove length from the other functions, it actually made alot of the code simpler as well
<andrewrk>
and with this, the client is back to tracking the exact size they request, correct?
Aransentin has joined #zig
<marler8997>
yes, they can pass in a buffer with the size they requested, or the full capacity
<marler8997>
so the semantics you proposed yesterday
<andrewrk>
I think it would be useful, as a test case, to update ArrayList to the new Allocator API
<marler8997>
yeah I can do that
<marler8997>
will be a simple change
<andrewrk>
ideally it would be able to take advantage of the full allocation capacity
<marler8997>
it will
blinghound has joined #zig
<Aransentin>
Might be a dumb question, but why are optionals and errors different things? Couldn't functions that return ´?SomeType´ instead be `error.Null!SomeType`, and then there wouldn't be a need for all the duplicated keywords like `catch` and `orelse`...
<leeward>
Aransentin: One reason is that null pointers aren't the same as errors, and Zig makes it easy to link with C.
<marler8997>
my immediate answer would be that errors trigger control flow like "try" and "errdefer"
<leeward>
More basically, it's the difference between the Maybe and Either monads, but...that's Haskell for you.
<leeward>
Really, there's a fundamental difference between "I have nothing to say" and "something went wrong."
<leeward>
We do kinda use optionals as the equivalent of StopIteration.
<andrewrk>
errors have meaning for error return traces, optimization hints, errdefer, and type casting. also, optionals require only 1 bit where as the memory layout for error unions requires an integer which can store all the different error enum values
<andrewrk>
in theory we should be able to make it 1 bit for an error set with only 1 value, but that's not implemented
<Aransentin>
Ah, well... it just seems like optionals is a subset of errors, even if they represent conceptually different things.
<leeward>
They are, technically.
<blinghound>
when will the next dev stream be?
<andrewrk>
not until next week at least, but I am doing a talk at the next showtime (https://zig.show)
<leeward>
It makes sense to have different syntax and handle them differently, since their usage is different, but strictly speaking you could do everything you do with optionals with errors.
<blinghound>
just the thing I was after, thanks guys
Akuli has quit [Quit: Leaving]
<andrewrk>
marler8997, just musing here, I wonder if it would be better perf to also return the capacity from the alloc function, since the data is probably available in the implementation. could potentially prevent doing the lookup based on slice twice, in the case that the client wants the capacity
<marler8997>
possibly
<marler8997>
We dont' have an allocator that does that yet
<andrewrk>
the page allocator would do that, no?
<marler8997>
well the work to get the capacity is just an align
<andrewrk>
good point
<marler8997>
I did have the same thought though, i was looking out for allocators that might take advantage of that
<marler8997>
so that one has to perform some sort of lookup to get the full capacity?
<andrewrk>
yeah it has to find the slot the allocation is in
<pixelherodev>
Oh yay
<pixelherodev>
ZIR restored!
<marler8997>
thinking...
<marler8997>
makes me want to go back to the original design without the capacityFn
<andrewrk>
which one?
<marler8997>
We'd have to change resizeFn to return the size as well
<marler8997>
but yes, now that I see an example I think we should support returning the full capacity from allocFn
<marler8997>
I'll keep capacityFn in for the time being
<marler8997>
maybe there's a way to modify the API to not need capacityFn, if not, then I suppose we can keep it
<marler8997>
so...I'll modify allocFn/resizeFn to return full capacity, sound good?
<pixelherodev>
Heh, I guess I should close my PR :P
ur5us has joined #zig
<pixelherodev>
Or at least, rebase, fix tests, and that's it
dddddd has joined #zig
<andrewrk>
marler8997, yeah that sounds good, and I have another idea to solve the other problems you ran into, just give me minute to formulate it
<andrewrk>
pixelherodev, I'm about to push a commit fixing all the tests
<marler8997>
ok
<pixelherodev>
oh wow
<pixelherodev>
andrewrk: nice :)
<marler8997>
in the meantime I can work on adding the return sizes back into allocFn and resizeFn
<pixelherodev>
I'm going to do the .zig harness rn
<andrewrk>
marler8997 over here going on the hero's journey
<pixelherodev>
Would be nice to get that in immediately afterwards
<marler8997>
lol
<andrewrk>
I'm noticing a pattern
<ifreund>
the quest for the one true allocator interface
<andrewrk>
zig community member gets interested in a small change related to allocators. "I'm not good at allocators" they say (*cough* fengb *cough*) "I don't know what I'm doing" => 2 weeks later they are the resident expert
<pixelherodev>
lol
<pixelherodev>
I'm glad to have broken that pattern :P
<pixelherodev>
I was just *silently* bad at allocators lol
<pixelherodev>
and I'm still probably not that great :P
<pixelherodev>
My OS allocator was mostly usable, but I'm willing to bet a test fuzzing it would cause a kernel panic lol
<pixelherodev>
andrewrk: replaced the PR with a smaller one that just cleans up the output of Transform tests
<pixelherodev>
Oh wait oops
<pixelherodev>
Forgot to remove the expectEqual lol
<pixelherodev>
Okay, test harness time!
<pixelherodev>
This time, for sure!
<pixelherodev>
Then, Execute needs to be implemented, and the compare output tests redirected to single-update cases
<pixelherodev>
andrewrk: let me know when you push the tests fix; I'm going to want to rebase against it so I can update the tests accordingly
st4ll1 has quit [Quit: WeeChat 2.8]
<pixelherodev>
It's currently possible to produce ZIR from Zig via the EmitZIR thingy, right?
<andrewrk>
pixelherodev, ok will do. I'm fixing EmitZIR right now
<blinghound>
I've been getting a lot of error code 5 when compiling my project today, is that code meaningful at all?
<andrewrk>
blinghound, no it's not, is there any other info?
<leeward>
A question about the future: Is the mechanism for polymorphic interfaces that's used in the standard library the way forward for Zig? (e.g. Allocator, where the specific struct has an Allocator member)
<blinghound>
@andrewrk https://github.com/ziglang/zig/issues/5698 then I discovered this when trying to eliminate everything else, but if the value IS initialized properly, I get error code 5. I'm still playing around to reliably reproduce it with a minimal example
<andrewrk>
leeward, the answer to that question is not stable yet
<pixelherodev>
We're not done iterating yet ;)
<andrewrk>
leeward, it's certainly going to be available to do; it's stable that this will be one possible way to do polymorphic interfaces (it's even possible in C)
<leeward>
andrewrk: Ok, so does that mean there's no accepted replacement but you're open to suggestions?
<marler8997>
programmers could easily pass in the full buffer instead, violating the requirement that all buffers track the requested size
<leeward>
That's a good thing to know.
<pixelherodev>
Though I do think we'll require changes to how builtins work in Zig
<pixelherodev>
Let's say there's a new builtin added for a hardware feature, but it's possible to compile the program without it
<marler8997>
I think I'm leaning towards #1...still thinking though
<pixelherodev>
Hmm, no, we could just use a build option :P
<pixelherodev>
ZBS = <3
<pixelherodev>
Well, not =
<pixelherodev>
But not ==
<pixelherodev>
I'm not *making* it <3, but I'm also not *testing* for it; it already *is* <3
<pixelherodev>
if (ZBS != <3) unreachable
<andrewrk>
marler8997, not sure I follow- if you used Allocator.alloc API, it would ignore any extra capacity returned, so there would be no "full buffer". if you called the advanced function, and got a bigger buffer, that's what you'd be tracking, before you passed it to something
<leeward>
Is that transitive? Because I've heard that weechat is also <3. Does that mean that ZBS is weechat?
<pixelherodev>
Hmm, that's an interesting question
Aransentin has quit [Remote host closed the connection]
<pixelherodev>
But no, I don't think it's transitive
<pixelherodev>
Associative, maybe?
<andrewrk>
marler8997, e.g. allocAllowExtra(Foo, 10) internally would call the resize function to track more Foos before returning
<leeward>
Maybe ZBS ∈ <3
<pixelherodev>
Okay, altered testing API
<marler8997>
I'm imagining code that does want to take advantage of the full buffer
<pixelherodev>
Now, instead of `addZIRMulti`, it's `addMulti(name, platform, .ZIR)`
<marler8997>
so something like array_list
<marler8997>
it would need to track the requested length, and the full capacity returned by allocFn
<pixelherodev>
Which means there's also addError(name, plat, .Zig, ...) now :D
<marler8997>
because the code will be using the full capacity buffer, it would be easy to acciddently pass the full buffer back into another allocator function
<marler8997>
idea #1 doesn't have this problem
<andrewrk>
hmm I still don't understand. with idea 2, ArrayList would immediately call resize if the returned capacity was larger than requested. there would not be any room for accidents
<marler8997>
oh
<andrewrk>
with both ideas, the client has to track one specific value, not a range
<pixelherodev>
Okay, old tests work ( I mean they fail, but your commit will fix that)... time for the first new one :D
<marler8997>
ok thinking more...
<andrewrk>
I don't like the double round trip with idea 2, it seems a waste to have to call into the allocator 2x
wootehfoot has quit [Read error: Connection reset by peer]
<marler8997>
that does seem like a disadvantage
<marler8997>
same issue we discussed when returning the full capacity in allocFn
<andrewrk>
yeah
<pixelherodev>
Whelp, first new test fails badly :P
<pixelherodev>
Double exports in Zig code seems to cause an assertion failure :P
<marler8997>
then again, performaing an in-place resize that's already reserved should be a simple addition
<marler8997>
I take that back, you have to lookup the capacity again
<pixelherodev>
Okay
<pixelherodev>
andrewrk: test harness works ;)
<pixelherodev>
But I'm hitting a *lot* of bugs when adding tests
<pixelherodev>
`TODO handle missing function name in the parser`
<marler8997>
I think idea #1 works, if that sounds good to you I'll go with that