ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<shcv> I'm on gentoo; I guess I can try the nightly
stripedpajamas has quit [Quit: sleeping...]
<pixelherodev> shcv: I'm on Gentoo
<pixelherodev> The default ebuilds aren't usable
<shcv> I think the "registered more than once" error is because I chose the dynamic libraries
<shcv> yeah
<pixelherodev> I should set up an overlay...
radgeRayden has quit [Quit: - Chat comfortably. Anywhere.]
<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> here's incremental compilation hooked up demoed with that silly 1,000,000 print() example:
<pixelherodev> andrewrk: while you're on
<pixelherodev> Export was changed for ZIR to use `str, func`?
<pixelherodev> i.e. `@0 = str("name") @1 = export (@0, @func)`?
<andrewrk> ZIR is just broken right now, because it's the secondary use case to .zig code. the next check box on my list ( is to fix ZIR test cases now
<andrewrk> I mean in the branch. I'm about to fix it and once that's done the branch can be merged
<pixelherodev> I've been fixing ZIR
<pixelherodev> That's why I'm asking
<pixelherodev> I had the error tests working before the last commit :P
<andrewrk> the dangers of basing a patch against a branch
<pixelherodev> I know
<pixelherodev> I rebased
<andrewrk> I just pushed another commit
<pixelherodev> That one shouldn't affect me
<pixelherodev> ... probably
<pixelherodev> Finding out rn
<pixelherodev> No issues rebasing :)
<andrewrk> nice
<pixelherodev> And with my patches, tests *build*
<pixelherodev> `:8:10: error: unknown instruction 'ref'`
<andrewrk> yeah there's no ref anymore
<andrewrk> check the commit message of d9c1d8fed3e121c4fe91d5aea301574ff763ef95
<pixelherodev> I know
<pixelherodev> That's why I was asking about export :P
<pixelherodev> It uses the str instead of a ref now, right?
<andrewrk> yeah, str no longer makes an array value, it now makes an anonymous Decl and references it
<pixelherodev> Right, so export(str, func)?
<pixelherodev> That just requires fixing up resolveDecl...
<pixelherodev> Or, perhaps, not breaking it
<pixelherodev> ... nope, fixing it
TheIronFlame has joined #zig
<pixelherodev> non-anon decls are still broken
<pixelherodev> My previous fix no longer works
<pixelherodev> :(
<andrewrk> you might have better luck working on something that is not exactly the same thing I am currently working on
<pixelherodev> True
<andrewrk> there's plenty of orthogonal work to do
<pixelherodev> I was originally going to add a new harness
<pixelherodev> The .zig one
<pixelherodev> But I wanted to fix ZIR tests first
<pixelherodev> and I was making good progress before :P
<andrewrk> they're not broken in master
<pixelherodev> I know
<pixelherodev> But the tests depend on your branch implicitly anyways
<TheIronFlame> hey, I'm looking for some help on just running zig on macOS. Getting a "Unable to create builtin.zig"
<daurnimator> TheIronFlame: which version of zig? and where did you get it from
<TheIronFlame> master branch
<TheIronFlame> well, the master build from the main download page
<pixelherodev> ah, nightly
<TheIronFlame> gotta have that bleeding edge
<pixelherodev> andrewrk: My PR against your PR is good to go for now, though it doesn't do much
<andrewrk> I'll take a look
<pixelherodev> ... there's probably mistakes, too
<pixelherodev> Oh hm, the function ZIR might be what broke on the rebase...
<pixelherodev> I'll switch to adding the harness
<pixelherodev> That'll require the least rebasing :P
B4s1l3 has joined #zig
B4s1l3 is now known as opDispatch
shakesoda has quit [Quit: Connection closed for inactivity]
TheIronFlame has quit [Remote host closed the connection]
waleee-cl has quit [Quit: Connection closed for inactivity]
aruniiird has joined #zig
aruniiird has quit [Ping timeout: 246 seconds]
aruniiird has joined #zig
<aruniiird> Hi all, a general question, what are zig programmers referred as (like gophers => go developers, pythonistas => python developers, etc...)
<daurnimator> aruniiird: ziguanas
<daurnimator> (our mascot is an iguana)
aerona has quit [Quit: Leaving]
fraktor has joined #zig
lukeholder has quit [Quit: Connection closed for inactivity]
<aruniiird> Thanks daurnimator
dddddd has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 240 seconds]
cole-h has quit [Quit: Goodbye]
stripedpajamas has quit [Quit: sleeping...]
stripedpajamas has joined #zig
<pixelherodev> I have a different term
<pixelherodev> Humans.
stripedpajamas has quit [Quit: sleeping...]
<marler8997> looks like azure msvc build is broken. Seems like this issue:
<andrewrk> here's a template we can copy to fix it:
greenfork has joined #zig
<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"
<marler8997> what a nasty bug
jmiven has quit [Ping timeout: 240 seconds]
aruniiird has quit [Ping timeout: 240 seconds]
marijnfs_ has quit [Ping timeout: 264 seconds]
jmiven has joined #zig
marijnfs has joined #zig
riba has joined #zig
aruniiird has joined #zig
<andrewrk> yeah, wow
<marler8997> someone has a PR to add the provides('msys2-base') back into the 'filesystem' package:
<marler8997> I made a comment about how I think this is a bug in pacman
<marler8997> how much does zig rely on msys2?
dermetfan has joined #zig
<andrewrk> oh you got it working!
<andrewrk> marler8997, only the CI system relies on it, for the windows scripts here:
<marler8997> I disabled the pacman update
amohan has joined #zig
aruniiird has quit [Ping timeout: 246 seconds]
amohan is now known as aruniiird
aruniiird has quit [Ping timeout: 260 seconds]
casaca has quit [Remote host closed the connection]
casaca has joined #zig
riba has quit [Ping timeout: 246 seconds]
student069 has quit [Ping timeout: 272 seconds]
casaca has quit [Remote host closed the connection]
casaca has joined #zig
ncon has joined #zig
dddddd has joined #zig
riba has joined #zig
aruniiird has joined #zig
ttmrichter has left #zig ["The Lounge -"]
marmotini_ has joined #zig
st4ll1 has quit [Ping timeout: 240 seconds]
st4ll1 has joined #zig
ifreund has quit [Read error: Connection reset by peer]
ifreund has joined #zig
riba has quit [Ping timeout: 246 seconds]
waleee-cl has joined #zig
forgot-password has joined #zig
forgot-password has quit [Client Quit]
aruniiird has quit [Ping timeout: 260 seconds]
st4ll1 has quit [Quit: WeeChat 2.8]
shakesoda has joined #zig
st4ll1 has joined #zig
st4ll1 has quit [Client Quit]
factormystic has joined #zig
nokierae has joined #zig
dermetfan has quit [Ping timeout: 272 seconds]
joey152 has joined #zig
cren has joined #zig
<cren> How would you describe Zig to an IT person who has never heard of it before?
<leeward> Are you using IT in the American sense of a non-programmer who manages technical infrastructure?
<leeward> Or is this a professional programmer/CS degree holder?
<cren> What I really mean is: a person who works for an information tech company, but who may or may not have any/much programming experience
<leeward> ah
<greenfork> better C
<leeward> Better C is the elevator pitch, but if you have time, maybe the first paragraph of
<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
riba has quit [Ping timeout: 240 seconds]
<blinghound> this is a very simplified version of my code
<blinghound> but I'm getting error: cannot assign to constant .Circle = .{}
<ifreund> blinghound: is there a reason you aren't using the inferred tags there? a packed enum seems odd
<ifreund> also you need to make the shapes variable var if you want to modify it
dingenskirchen has quit [Quit: dingenskirchen]
<blinghound> even 'const circle = @unionInit(Shape, "Circle", .{})' I get cannot assign to const
<blinghound> same with var
<blinghound> I've tried using a normal and packed enum
<blinghound> am I being stupid?
nycex has quit [Remote host closed the connection]
<ifreund> maybe it can't infer the type properly, try `.Circle = shape_namespace.Circle{}`
<ifreund> and all you should need for the taging is to do union(enum)
<ifreund> there's no need to manually create an enum type for the tagging in most cases
nycex has joined #zig
<blinghound> hmm, I tried with and without enum type
<blinghound> and specifying the namespaces
<blinghound> still not working
<blinghound> can anyone reproduce?
<leeward> blinghound:
<leeward> It has Zig support, and if you can get the same error message there it's easy for people to fiddle with it.
nycex has quit [Quit: Quit]
blinghound52 has joined #zig
blinghound52 has quit [Remote host closed the connection]
blinghound46 has joined #zig
<ifreund> blinghound: works fine for me
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: 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?
dingenskirchen has joined #zig
<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.
marmotini_ has joined #zig
<leeward> found
<leeward> Yeah, I kinda do like requiring explicit copy for non-intrinsic types.
<leeward> Then the compiler goes "Hey, you're trying to copy this thing. Is that what you wanted?"
marmotini has quit [Ping timeout: 240 seconds]
layneson has quit [Ping timeout: 272 seconds]
<ifreund> yup, it's a lot more explicit
<blinghound> guys I'm back after experimenting
<blinghound> I'm not sure if a comptime struct member should result in an error in this wya
<blinghound> *way
<blinghound> but that was the issue anyway!
<leeward> If you don't rely on the default initializer for Square, it seems to work (.Square = .{.id=0})
<blinghound> just noticed that too, good catch
<leeward> It's not an anonymous struct literal issue either; Square{} fails but Square{.id=0} succeeds.
<blinghound> yeah, I experimented with automatically inferred types too, it's definitely the default initialize
<blinghound> should I open an issue?
<leeward> Assuming nobody else chimes in with a reason why that shouldn't work...probably a good idea.
satchmo has joined #zig
<ifreund> making the id field not comptime also works
<ifreund> here's a condensed version for the issue:
waleee-cl has quit [Quit: Connection closed for inactivity]
marmotini has joined #zig
aruniiird has joined #zig
marmotini_ has quit [Ping timeout: 246 seconds]
blinghound has quit [Remote host closed the connection]
blinghound has joined #zig
dddddd has quit [Ping timeout: 260 seconds]
<leeward> Interesting. This code runs much slower in releas-fast when --single-threaded than in release-small or release-safe.
Akuli has joined #zig
r4pr0n has joined #zig
<andrewrk> marler8997, thanks for getting the ball rolling with azure ci. I got it working based on your branch:
<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 is failing
<mq32> andrewrk, can you stop breaking the internet, please?
<ifreund> looks like the rebuild might be fine though
blinghound has joined #zig
aruniiird has quit [Quit: Leaving]
<pixelherodev> lol :P
<pixelherodev> The 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.
<companion_cube> applied to andrewrk
<mq32> oh, that's a good sidetrack
<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 (
<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.
<andrewrk> blinghound, other folks in the community stream regularly though, you can follow and
<blinghound> @andrewrk thanks! Looking foward to the next showtime
marmotini has quit [Ping timeout: 264 seconds]
<blinghound> being stuck at home I'm gagging for some programming lang streams
<blinghound> is anyone in the chat from the UK?
<marler8997> ok found an issue with requiring that the buffer size be either the requested size or the full capacity
<marler8997> when allocating an array of items (larger than 1) and the full capacity isn't divisible by the element size
<andrewrk> ah that's a really good point
<marler8997> sounds like we need to accept any size between the requested size and the full capacity?
<mq32> blinghound: sobeston on discord is uk-based afaik
<blinghound> sweet! I haven't joined the discord yet actually
<marler8997> I don't think adding that extra requirement will really be an issue
<andrewrk> marler8997, that makes sense to me
<marler8997> ok
<ifreund> blinghound: if you haven't watched the recordings of the past showtimes there's some good stuff in there
<blinghound> @ifreund cheers for that, I'll check out the last episodes, I only caught the latest one
<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> but haven't seen one yet
<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?
<pixelherodev> Okay cool
<blinghound> I opened this issue earlier today
<pixelherodev> So Transform for Zig input should produce ZIR, right?
<andrewrk> marler8997, 2 ideas:
<blinghound> but after playing around with everything it seems like the order of cIncludes fixed that particular compile error
<pixelherodev> Hmm, is type a *keyword*, or is it just a special type?
<pixelherodev> Pretty sure it's the latter, so `val.type` should be fine as access...
st4ll1 has joined #zig
<andrewrk> marler8997, oops, I had a typo. fixed here:
<marler8997> reading...
<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 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?
<andrewrk> yes, and the suggestion issue is
<leeward> Ooh, a low number.
<leeward> Ok, thanks.
<pixelherodev> Soon, anything four-digit will be a low number ;)
<pixelherodev> Only a matter of time
<pixelherodev> Okay, time to add the first Zig test!
* pixelherodev crosses fingers
<andrewrk> what about after all bugs are fixed and all features are implemented? :P
<leeward> I'm pretty sure "after" doesn't have any meaning in that context.
<pixelherodev> Ha
* andrewrk makes a rainbow appear out of his hands in the air
<pixelherodev> That might happen eventually, for the *compiler*
<pixelherodev> But even there, performance improvements will probably pop up from time to time
<pixelherodev> Not to mention, adding new platforms
<leeward> Maybe for a compiler for a particular version of the language.
<pixelherodev> Eh, I'm pretty sure the language is intended to freeze permanently at 1.0
<andrewrk> there may need to be some exceptions for architecture specific builtins
<pixelherodev> Why would we need those?
<andrewrk> zig will support cpu architectures that haven't even been invented yet
<marler8997> still pondering
<pixelherodev> Mind giving an example builtin?
<leeward> I predict there will be changes in the kinds of things computers do that will necessitate language changes.
<pixelherodev> Ehh
<pixelherodev> I don't like the idea of trying to modify the language to suit every possible use
<andrewrk> example: @wasm_allocate_memory or whatever
<pixelherodev> Hmmm...
<pixelherodev> Why would that need to be a builtin, and not inline asm?
<andrewrk> good question :) I think I opened a proposal to make that inline asm
<pixelherodev> e.g. have std.os.system functions that expose system-specific behavior via inline asm
<leeward> (w)asm?
<pixelherodev> std.os wraps low-level behaviors for all systems
<pixelherodev> std.* uses std.os for high-level functionality
<leeward> It's inductive, but every language that's ever been has evolved.
<andrewrk> even C gets new compiler intrinsics all the time
<andrewrk> e.g. avx512 intrinsics
<pixelherodev> Yes, but that's basically the only change that's happened to C that's in widespread use :P
<pixelherodev> I don't think *anyone* uses C11 threading, for instance lol
<pixelherodev> Source: has tried using it, and was not impressed
<leeward> pixelherodev: C99 introduced a LOT of things that are in widespread use.
<pixelherodev> I know
<pixelherodev> Ah whoops
<pixelherodev> meant to say C11
<marler8997> for idea #2, imagine you allocate a buffer and pass it to a function
<pixelherodev> Not C
<marler8997> that function might resize it
<pixelherodev> C99 was the last real change to C that's worth noting in terms of new features
<andrewrk> phd is right though, my current plan is to not iterate on the language after 1.0
<leeward> The fact that we have builtin support for vector math suggests to me that Zig will get builtin support for future-hardware features.
<pixelherodev> Builtins / intrinsics don't really count
<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> addZIRError => addError(name, plat, .ZIR, ...)
<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
<pixelherodev> Dammit stupid...
<pixelherodev> Ugh
<andrewrk> marler8997, sounds good to me
blinghound has quit [Remote host closed the connection]
<pixelherodev> andrewrk: #5704 :)
<pixelherodev> I actually just reused the ZIR harness, and added a Type tracker which just changes the module file name
dddddd_ has joined #zig
blinghound has joined #zig
dddddd has quit [Ping timeout: 240 seconds]
<pixelherodev> Hmm
<pixelherodev> andrewrk: since "add tests for Zig AST" is in your PR, should I rebase my test harness against it?
blinghound has quit [Remote host closed the connection]
<pixelherodev> andrewrk: how do you feel about test chaining?
<pixelherodev> addTransform(src, output).addError(src, error_list).addExecution etc?
<andrewrk> it's an antipattern
<pixelherodev> Good to know
* pixelherodev casually hits `u` a couple of times
emekoi has quit [Ping timeout: 265 seconds]
<pixelherodev> I wonder how many seconds it'll take for my new proposal to be shot down then :P
emekoi has joined #zig
<pixelherodev> andrewrk: should Execution tests support stdin? Or just check stdout / stderr / exit code?
emekankurumeh has joined #zig
emekoi has quit [Ping timeout: 258 seconds]
<scientes> andrewrk, and I would have gotten away with it if it wasn't for you damn kids!
dddddd_ is now known as dddddd
r4pr0n has quit [Quit: r4pr0n]
<pixelherodev> ?
<pixelherodev> Oh right, gotcha :P
satchmo has joined #zig
<tgschultz> is there a known issue with unwrapping a `?@Frame()`?
dermetfan has quit [Ping timeout: 260 seconds]