ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
<andrewrk> we're gonna merge this branch today, I can taste it
notzmv has joined #zig
notzmv has quit [Remote host closed the connection]
notzmv has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
notzmv has quit [Remote host closed the connection]
<andrewrk> all zig fmt test cases passing again!
<andrewrk> now it's just the CI
Pistahh has quit [Ping timeout: 272 seconds]
mikdusan has joined #zig
<g-w1> oof the ci failed
fengh has quit [Quit: WeeChat 3.0.1]
mikdusan1 has joined #zig
<g-w1> on the cli tests
fengh has joined #zig
<andrewrk> also discovered some more regressions by running zig fmt on the std lib
mikdusan has quit [Ping timeout: 260 seconds]
brzg has joined #zig
ur5us has joined #zig
karchnu has joined #zig
<karchnu> I nearly finished the translation of the overview page… the original page is quite verbose. ^^'
<andrewrk> indeed it is
swills has quit [Ping timeout: 264 seconds]
ur5us has quit [Quit: Leaving]
ur5us has joined #zig
ur5us has quit [Client Quit]
ur5us has joined #zig
brzg has quit [Quit: leaving]
cjb has joined #zig
osa1_ has joined #zig
osa1 has quit [Ping timeout: 265 seconds]
notzmv has joined #zig
swills has joined #zig
notzmv has quit [Quit: ERC (IRC client for Emacs 27.1)]
blueberrypie has quit [Quit: leaving]
blueberrypie has joined #zig
<andrewrk> damn, I can only repro that failing CI issue on aarch64 in release mode
osa1_ has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 264 seconds]
earnestly has quit [Ping timeout: 260 seconds]
swills has quit [Ping timeout: 264 seconds]
<andrewrk> a tokenizer bug? ಠ_ಠ
ur5us has joined #zig
<g-w1> was const std = @import("std"); never tested?
<g-w1> it is
<andrewrk> I suspect a MultiArrayList bug
xackus has joined #zig
xackus__ has quit [Ping timeout: 240 seconds]
decentpenguin has quit [Ping timeout: 264 seconds]
swills has joined #zig
<g-w1> andrewrk: does the bug trigger if you use libc allocator?
decentpenguin has joined #zig
lqd has quit [Quit: Connection closed for inactivity]
squeek502 has quit [Remote host closed the connection]
casaca has quit [Remote host closed the connection]
fengh has quit [Quit: WeeChat 3.0.1]
notzmv has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
<marler8997> I think a good word for the programming style I've developed would be "bread crumb programming"
<marler8997> I work on the things I want to work on but make sure to leave good bread crumbs everywhere else
<marler8997> I wonder if that's already a "thing"
<andrewrk> g-w1, yes
<andrewrk> marler8997, that sounds very similar to the style I have arrived on as well
<marler8997> yeah I notice you use the same technique when I see you live stream
<marler8997> it's something I think I started really learning about 5 years ago, around 8 years after I started programming in college
<marler8997> would have loved to have learned about it back then :)
<andrewrk> heh, I can repro the zig fmt issue with qemu-aarch64
decentpenguin has quit [Ping timeout: 240 seconds]
<andrewrk> *sigh* it was llvm silently doing incorrect codegen for @reduce on aarch64
bitmapper has quit [Quit: Connection closed for inactivity]
<mikdusan1> #7138
decentpenguin has joined #zig
swills has quit [Ping timeout: 264 seconds]
swills has joined #zig
swills has quit [Ping timeout: 264 seconds]
squeek502 has joined #zig
squeek502 has quit [Remote host closed the connection]
squeek502 has joined #zig
swills has joined #zig
<andrewrk> ifreund, we're down to just 2 small zig fmt regressions left!
<andrewrk> I'm done for the day
osa1 has joined #zig
decentpenguin has quit [Ping timeout: 240 seconds]
decentpenguin has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
decentpenguin has quit [Ping timeout: 260 seconds]
decentpenguin has joined #zig
dch has quit []
dch has joined #zig
sord937 has joined #zig
swills has quit [Ping timeout: 260 seconds]
decentpenguin has quit [Quit: ZNC crashed or something]
decentpenguin has joined #zig
cjb has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
tnorth__ has joined #zig
lqd has joined #zig
ur5us has joined #zig
<marler8997> just finished what is probably my longest github comment ever :)
<andrewrk> wowie zowie
<marler8997> yeah I'm in talks with a publisher, it's clear I like writing novels when I'm passionate about something :)
geemili has quit [Ping timeout: 260 seconds]
xackus has quit [Quit: Leaving]
<ifreund> andrewrk: nice, I'll take a look after breakfast :)
<ifreund> marler8997: stitch looks pretty sweet by the way, interested to see where it goes
<marler8997> ifreund oh thanks alot, still got stuff to iron out but it's been coming along, made alot of progress that past couple days
earnestly has joined #zig
<ifreund> lots of prior art here by the way:
<ifreund> though it seems stitch is more focused on non-interactive usage (is interactive usage even planned?)
<marler8997> ifreund, nope, it's purposely left out since I've found features of both can be contradictory
<marler8997> i.e. optimize for reading vs writing
<marler8997> thanks for the links, this will be useful reading
ur5us has quit [Ping timeout: 264 seconds]
<marler8997> oil is written in python, and translated to C++, that's nifty
xackus has joined #zig
<ifreund> keeping it non-interactive makes sense, should certainly keep thing simpler
<marler8997> goodness, why do these shells have so much code in them?
<ifreund> yeah, a lot of them really suffer from complexity :/
<ifreund> probably one of the reasons I'm still using zsh for interactive usage and posix sh through dash for scripts
<ifreund> not that zsh is simple, but it's old and stable enough to be a known evil
<andrewrk> marler8997, added a comment to the @tryImport thread
<andrewrk> happy to discuss more tomorrow, but for now I'm going to watch some One Piece and then go to bed :)
cole-h has quit [Ping timeout: 240 seconds]
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
geemili has joined #zig
geemili has quit [Ping timeout: 272 seconds]
Techcable has quit [Remote host closed the connection]
<karchnu> Links on are broken in the overview page.
<karchnu> right, I should see the current issues on github :D
Miaourt has joined #zig
ed__ has quit [Quit: Leaving]
<ifreund> andrewrk: got those last test cases fixed, might go looking for more in a bit :)
Swahili has joined #zig
Snaffu has joined #zig
<ifreund> urgh, this test case was too simple actually. The current solution isn't sufficient
proteusguy has quit [Quit: Leaving]
proteusguy has joined #zig
dyeplexer has joined #zig
<karchnu> can someone explain to me this part of the website? "This target may only support --emit asm and cannot emit object files"
<ikskuh> karchnu: that means that the compiler cannot link or create object files
<karchnu> the way it is said, this seems very specific
<karchnu> but, okay, I'll try to find the right wording in french
waleee-cl has joined #zig
<ikskuh> marler8997, you there?
<marler8997> yeah
<ikskuh> answering to your comment here to prevent some lengthy discussions
<marler8997> sure
<ikskuh> in this case you'd have two options: accept bearssl as a build dependency
<ikskuh> flat-copy the bearssl build instructions into your build.zig
<marler8997> right
<ikskuh> i'm with andrew here, it's more reasonable to fetch everything to be able to work offline and *maintain* the project even in case of internet outage
<marler8997> this has nothing to do with the internet
<marler8997> it is completely orthogonal
<ikskuh> not quite
<ikskuh> if i only ever fetch openssl
<ikskuh> i will not be able to *ever* test with bearssl in this case
<marler8997> you're also going to need the 80 MB zigwin32 repository, even though you're not even on windows
<ikskuh> yep
<marler8997> and all it's dependencies. Every dependency that build.zig depends on now has to be downloaded
<ikskuh> because i might want to cross-build to windows in two years
<ikskuh> but don't have internet right now
<marler8997> this solution doesn't scale, and what's going to happen is people are going to come up with clever hacks to get around this limitation
<marler8997> They are going to come up with "configure" script to run before Zig build
<marler8997> ikskuh, it's fine if you want to cross build, we're not talking about that case
<marler8997> we're talking about the case where you are downloaded dependencies that you don't need and aren't using
<marler8997> downloading all your dependencies might be fine for small projects, and while Zig is in its infancy
<marler8997> and it's fine if it's hard to do dependencies because it naturally makes people not use them
<ikskuh> marler8997: it contradicts maintainability though
<marler8997> when you see a library you want to use, you now have to decide if you want to require everyone to always download it, even if its not being used
<marler8997> why are we forcing people to comprimise?!?
<marler8997> right, because it's easier to maintain everyone's ad hoc solution that gets around the limitation??
<ikskuh> i am in daily pain that people fucked up their dependency management
<ikskuh> and only use what they *thought* they need
<ikskuh> what i want (and zig gives me that right now) is this:
<ikskuh> "copy the project and compiler onto a stick, move it into an airgapped machine and compile the project there"
<marler8997> this has nothing to do with our discussion
<marler8997> again, it's completely orthogonal
<ikskuh> it has
<ikskuh> because if i don't have all deps available in this moment
<ikskuh> i cannot compile the project over there
<marler8997> of course
<marler8997> orthogonal
<ikskuh> why? it's missing win32 ;)
<ikskuh> because it has other build dependencies on another machine
<ikskuh> we're in zig
<marler8997> whether or not a dependency exists has nothing to do with the build systems ability to detect and handle that missinjg dependency
<ikskuh> we could make packages depend on the freakin' CPU microcode patch
<ikskuh> so
<marler8997> we are only talking about the ability to detect and handle missing dependencies
<ikskuh> what does it do in the case of a missing dependency?
<ikskuh> ffail?
<marler8997> this has nothing to do with fetching or managing them
<ikskuh> and cry? :D
<marler8997> it's an error like "failed to import missing package "foobuild""
<ikskuh> and then i'm fucked because i cannot ever get this foobuild
<marler8997> of course
<marler8997> again, this is all orthogonal
<ikskuh> i don't think so
<marler8997> I think you're making the assumption that if the build system can handle a missing dependency and provide a nice error message, that this also implies that it's not tracked properly as a dependency at all and therefore wouldn't have been downloaded
<ikskuh> i don't really think there's such a thing as an "optional" build dependency
<ikskuh> marler8997: this implies that you're building with the exact same configuration
<marler8997> ikskuh, that is very easily provably false
<ikskuh> what if i'm suddenly legally not allowed to build with openssl anymore because of $reasons
<marler8997> what does this have to do with the ability of build.zig to detect and handle missing dependencies?
<marler8997> again, this has nothing to do with fetching and managing dependnecies
<ikskuh> even then i think @tryImport is the wrong solution here, as it's too late there already to do anything about it
<ikskuh> so it can also just fail ungracefully
<marler8997> ikskuh, nope
<marler8997> definitely nope
<ikskuh> what is the thing that should be done then?
<marler8997> but that's also orthogonal
<ikskuh> display a nice error message?
<marler8997> I'm not saying build.zig has to do anything about it
<marler8997> it could, but that's unrelated to the fundamental ability for build.zig to handle it at all
<ikskuh> but why should it handle it at all?
<ikskuh> the only reason i see is to *not* download and fetch a dependency
<marler8997> because some dependencies are optional
<ikskuh> otherwise, the dependency would be fullfilled with a guarantee
<ikskuh> and we don'T need an option to detect this
<ikskuh> because it is always available
<ikskuh> by design
<marler8997> when I build the openssl backend, if the import to "zigwin32build" fails, I don't care
<ikskuh> then again: why should it fail, we have fetched it ;)
<marler8997> I don't want to fetch it, that's the point
<marler8997> if I dont' need it, I don't want to fetch it, I don't want every user to have to download every dependency for every possible build configuration
<marler8997> and if I'm a project maintainer, this is going to encourage me not to add new dependencies because it means that everyone is always going to have to download this new dependency, even when it is only required for some esoteric build configuration
<ikskuh> yes, exactly.
<ikskuh> that's the point though
<marler8997> maybe I want to add some Android ssl backend, which requires a large Android SDK project, now everyone has to download that very large project for android
<ikskuh> if you only fetch a partial copy, you are unable to maintain the project
<marler8997> even if they have ssl completely disabled
<marler8997> ikskuh, you fetch the dependencies you use
<ikskuh> and as said: then i might be able to build today
<ikskuh> but not tomorrow
<marler8997> let me ask you this question, what if we were talking about the dependencies of the project itself?
<ikskuh> can you explain me *any* difference?
<ikskuh> a dependency is something i need to build the project
<ikskuh> period.
<marler8997> well you seem to be ok with them being handled differently correct?
<ikskuh> nah, fetch them.
<marler8997> you're saying it's ok to download all possible dependencies of a build.zig file, but it's not ok to do that for dependnecies that the project itself uses?
<marler8997> is that correct?
<ikskuh> no
<ikskuh> it's not okay to not fetch dependencies
<ikskuh> imho
<ikskuh> i cannot archive the software i'm writing at work
<ikskuh> and it so freaking sucks
<marler8997> so say you have a project like a text editor
<marler8997> and it can compile for every possible known operating system out there
<marler8997> it's got like 5 GB worth of dependencies if you combine all of them, but you only need the core project and the linux platform dependnecy, which amount to around 2 MB
<marler8997> you're saying that the package manager should always download all 5 GB of dependencies for all platforms no matter what, even if you just want to build the linux variant
<marler8997> is that right?
<ikskuh> if i want to work on the project: yes
<marler8997> that's absolutely ridiculous
<ikskuh> if not, i can use a prebuilt distribution and don't need a source variant of it
<marler8997> I'm not ok with that
<marler8997> it looks like we have a fundamental disagreement here
<ikskuh> yep
<ikskuh> had too much pain with depending on *anything* outside a project folder
<marler8997> what irks me here is you're asserting that your position here is the superior one by not allowing me to support my position
<ikskuh> including the OS itself (windows project with heave ignorant use of case insentivie file names)
<marler8997> to say this use case is invalid is too strong of an argument, even if I agreed with your fundamental point
<mikdusan1> why again is it superior that a maintainer for a native-gui must download qt5 ? I think I'll pass on that.
<marler8997> a perfect example, ikskuh says you MUST download qt even if you're not using it
<mikdusan1> not gonna happen. qt5 is the devil.
<marler8997> that just seems ludicrous to me
<ikskuh> mikdusan1: because only then you can actually maintain the project properly and see if you don't break stuff with your changes
<marler8997> it sounds like somethine Microsoft would do
<ikskuh> also you are able to build for another platform if that is necessary
<ikskuh> what i think could be an option:
<mikdusan1> ikskuh: maybe qt5 doesn't even build on my platform. so I have no way to see if my stuff breaks . thus qt5 will never be used for me.
<marler8997> ikskuh, of course you can, we're not saying you shouldn't be able to download all the dependencies, we're saying it shouldn't be required if specifically build a variant that doesn't need them
<ikskuh> make the user *opt-out* of the behaviour i proposed with a warning that they might not be able to compile the project anymore in the future due to not being able to fetch missing dependencies
<marler8997> that's exactly what @tryImport allows you to do
<ikskuh> it's not having that warning *grin*
<ikskuh> mikdusan1: you never know
<ikskuh> i took roughly 1 full-time week to get a project we have in the company to build
<ikskuh> because people didn't archive their projects properly
<ikskuh> result:
<ikskuh> "download this library" isn't possible anymore
<ikskuh> so the only solution to maintain this project was: reimplement that library functionality from scratch
<marler8997> ikskuh, please stop attacking this straw man
<ikskuh> it's sadly some stuff where i had serious pain with
<ikskuh> and thus is important to me
<ikskuh> to prevent future pain
<marler8997> your use case is safe and sound, this is orthogonal
<marler8997> granting the ability to handle missing dependencies does not mean that we are removing support to download all the dependencies
<ikskuh> yeah as said: i can agree on opting out of "download all dependencies"
<ikskuh> but i am strongly for "it should be default"
<mikdusan1> shuld be other way around. sorry.
<ikskuh> i think we have different backgrounds on this then
<marler8997> > i can agree on opting out of "download all dependencies"
<marler8997> fundamental disagreement solved?
<marler8997> I don't think I've ever seen such a fast turnaround like that :)
<ikskuh> marler8997: well, that was exactly the point of this discussion
<ikskuh> not spamming github :D
<marler8997> yeah real-time discussion is alot more efficient and allows conversationt to be more focused because of the feedback loop
<ikskuh> yep!
<ikskuh> but even then, i'm not sure that @tryImport is the right solution
<ikskuh> imho something like "comptime" build options for build.zig would be better
<ikskuh> provided from a static file, similar to zig_packages.json
<marler8997> it's uncanny how much you are adhering to the theoretical example in my "Story Time" comment
<mikdusan1> i had some early thoughts on this and felt that we'd need to start with, looking from a zig perspective of .zig deps, 2 things: a `@package(spec)` builtin and externalization of `spec`
<mikdusan1> so `@package()` defines the package name (uuid'sh thing), where to fetch it, etc.
<mikdusan1> and the externalized .json version is what ends up on a website for each (eg.) tarball
<marler8997> ok given these idea, how do we tie the command line option -Dbackend=QT to this comptime configuration?
<mikdusan1> build.zig already has a comptime config mechanism
<marler8997> -Dbackend=QT isn't available till runtime, so how does it affect a comptime config?
<mikdusan1> looking for an example. I wrote one a while ago
<marler8997> hold on, I might be mixing up yours and ikskuh's examples
<marler8997> is @package() called at runtime or comptime
<mikdusan1> tbh I should put together a proposal. but `@package(spec)` would be a language builtin with comptime spec.
<mikdusan1> so build.zig would convey options (the config) to our .zig sources which based on that config, can choose what to supply `@package(spec)` with. @package in my idea is basically just an elaborate `@import`
<mikdusan1> and the usual lazy use applies. nothing is pulled in unless needed.
<mikdusan1> one of the cases I wanted it to soundly support, and I think it would, is the mtaintainer vs. release manager
<mikdusan1> so build.zig would drive a config of "maintainer mode or not?" and if maintainer == trun @import else @package
<mikdusan1> s/trun/true
<earnestly> Huh, for a second I thought this might be an Ada channel, heh
<marler8997> brb
fritchie has left #zig ["Leaving"]
<ikskuh> <marler8997> it's uncanny how much you are adhering to the theoretical example in my "Story Time" comment
<ikskuh> keeping to the same example is better for everyone in a discussion
<ikskuh> switching examples is just a red herring and confuses people
Akuli has joined #zig
hnOsmium0001 has joined #zig
<mikdusan1> marler8997: this is just shooting from the hip. but this is further along in how I see .zig declaring/using packages:
wootehfoot has joined #zig
<marler8997> looking
<mikdusan1> i did a "what if" we just put that info in .zig source directly. obviously it applies only to .zig deps
<mikdusan1> the cost I suppose of moving out of .zig is less type-safety and then @import("foo") would need to match a external .json somewhere
<marler8997> I'd have to think about the pros and cons of where to put the dependency information, I'm not sure of them at the moment
<marler8997> but I hope it's clear that all this is completely orthogonal to @tryImport, all @tryImport does is provide a mechanism for build.zig files to handle missing imports. How dependencies are specified or resolved or how the package manager is somewhat related, but ultimately orthogonal
wilsonk has quit [Ping timeout: 240 seconds]
<marler8997> just talking about the information you're including in your dependnecy data structure, I know the data you've given here is addressing real problems. Things like a package identity, semantic versioning, signing. All stuff we'll need to address with the package manager. But I'm sort of laser focused on the @tryImport thing before I can really weigh in on these details
<mikdusan1> i _think_ I see that you're using a rebuild-build.zig approach for each package but admit I haven't totally grok'd tryImport
<mikdusan1> yet
<mikdusan1> i mean for each package that build.zig requires
<marler8997> yeah
<marler8997> there's really no way getting around this requirement. Without this feature, we have to make sacrifices no matter what
<marler8997> i.e. just throwing our hands up in the air and saying that some dependencies just always have to be downloaded...we don't support any logic to determine when to download them
<mikdusan1> I am not sure but would it be easier to visualize tryImport in the use-case of say needing to imbue build.zig with ability to fetch using (example) http3
<marler8997> that might be a bit of a stretch and rub people the wrong way because it sounds like it's trying to be a package manager
<marler8997> we can stick to examples of just using other libraries to configure our build in various ways
<marler8997> the Android example is a good one I think
<marler8997> ok I think I have 3 statements that if people agree are true, shows the need for @tryImport
<marler8997> Statement 1: build logic is codified in Zig (not BASH or Python etc)
<marler8997> Statement 2: we want to allow logic to be used to configure dependencies
<marler8997> Statement 3: the logic we use to determine our dependencies can have its own dependencies
<marler8997> in thinking about this problem quite a bit, @tryImport was a result of a reduction of the requirements and the current state of Zig
dyeplexer has quit [Remote host closed the connection]
<marler8997> ikskuh actually helped along the way, it's a generaliztion of the "prebuild.zig" idea I had, where it allows build.zig to serve as it's own "prebuild" so it can bootstrap itself. This is the same idea he presented when he talked about build.zig building another builder_runner
<marler8997> Statement 1: I think everyone will agree on
<marler8997> Statement 2: this was our earlier discussion which shows without this feature, everyone will need to download every possible dependency that a build.zig file might import including the ones they will never use, and keep in mind this also means downloading all your dependencies possible dependencies
<marler8997> say I'm using zig-bearssl, and it adds support for android, so now suddenly my project which uses zig-bearssl but doesn't support android has to pull down android even though my project can't even use it
wootehfoot has quit [Read error: Connection reset by peer]
<marler8997> For Statement 3: Android and QT are good examples of why it would be useful to provide libraries to use logic to determine our dependencies
wilsonk has joined #zig
<marler8997> if anyone has trouble seeing why these 3 statements infer the need for @tryImport, let me know and I can walk you through it
nimaje has quit [Quit: WeeChat 3.0]
wilsonk has quit [Ping timeout: 240 seconds]
Swahili has quit [Remote host closed the connection]
Snaffu has quit [Read error: Connection reset by peer]
Snaffu_ has joined #zig
<marler8997> It might also help to mention that @tryImport is only necesary for the corner cases where dependencies are dynamic. In most cases, dependencies are static and will therefore not need @tryImport.
Snaffu has joined #zig
proteusguy has quit [Remote host closed the connection]
Snaffu_ has quit [Ping timeout: 260 seconds]
wilsonk has joined #zig
gpanders has quit [Quit: ZNC -]
gpanders has joined #zig
<braket> I'm assuming no, but is there a non-comptime way to construct a struct with an anytype member?
<g-w1> no
<g-w1> anytype is an only-comptime construct
<marler8997> tagged union is probably want you want
<braket> I'm trying to store a function and its parameters (in another member), so I don't think a tagged union would help there unfortunately
<marler8997> it's the only solution, asside from using a reference
wilsonk has quit [Ping timeout: 240 seconds]
<braket> how would the union approach work if you don't mind explaining. I know about them but I've never worked with them before so
<marler8997> is this function argument going to be a value of a set of known types?
<braket> no
<marler8997> so you don't know the storage size of this struct holding the function pointer and the argument?
<g-w1> if this were c I would use *void, but its not.
<braket> correct, which I guess is why comptime is required
<marler8997> for example, for all you know the argument could be a struct that has 100 that right?
<braket> right right
<g-w1> usually when this happens, I think of another way to do it because I am probably using the language wrong
<marler8997> then you have to use a reference
<marler8997> but I would also question whether or not you can actually get the set of known types
<marler8997> for example, you can create a tagged union type like this Variant(i32, usize, []const u8, ...)
<braket> This is for a task queueing library where I was hoping to be able to take any sort of function and arguments and store them in a task struct to later be executed.
<braket> But yeah, I'll look into references and perhaps maybe try for a different approach cause I don't people to have to write comptime var and do comptime initialization too. that's just annoying
<marler8997> I recall it was either Kprotty or Andrew put together a task queue library, and they may have had a solution for this, maybe I can find it
<marler8997> you might want to take a look at std/event/batch.zig in the standard lib
<braket> alright, I'll take a look
<marler8997> looks like it's using anyframe to encapsulate an asynchronous function call
<marler8997> which would have any arguments passed to the function
<marler8997> a more generalized version of a functionpointer/argument structure
<g-w1> thats an interesting idea, or maybe making a context argument as a struct that gets passed to th efunction
amk has quit [Read error: Connection reset by peer]
amk has joined #zig
<braket> ooooh, this might work out nicely. thanks! i'll try it out
cole-h has joined #zig
amk has quit [Read error: Connection reset by peer]
Techcable has joined #zig
wilsonk has joined #zig
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
remby has joined #zig
<braket> the batch.
<braket> welp, that didn't work. I thought it would be different b/c of the & for some reason lol, but `&async foo()` just calls foo like normal async stuff, which isn't what I want as tasks may be nonasync. I guess that's why it says Batch only runs async functions in parallel, cause for non-async functions it just runs the function before it adds it to
<marler8997> I don't know enought about async to help much
tughi has joined #zig
<braket> all good, maybe i'll just make users put a suspend in all their task functions ;D
<marler8997> one thing you could do, is instead of a function pointer, you could pass a pointer to a Task struct that contains a function pointer
<marler8997> this function pointer takes a pointer to the Task struct as the first argument, then you can use @fieldParentPtr to create "sub type" of your Task to add whatever data you need
<marler8997> this is what the Allocator interface does
<marler8997> and is a common Zig pattern to emulator what classes do in other languages
amk has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
notzmv has quit [Ping timeout: 240 seconds]
tnorth__ has quit [Ping timeout: 258 seconds]
ur5us has joined #zig
sord937 has quit [Quit: sord937]
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
zags has joined #zig
remby has quit [Quit: Connection closed]
remby has joined #zig
<zags> I had a bug where I passed in an arena allocator to a socket handler, which in turned stored a ptr to allocated memory long-term, while the caller nuked the arena. My bad, but is there a good strategy here/any way to get help from the language? That is, how to ensure allocators live long enough.
<ifreund> if your arena was backed by the std's gpa the use-after-free detection should help you
<zags> yeah it wasn't, but mostly looking for ways to prevent this form happening in the first place, but don't think there's a static solution
<braket> is there a builtin for getting the return type of a function? I thought I remember seeing one somewhere..
<Gliptic> @TypeOf?
<braket> oh wait nvm
<braket> yeah @TypeOf(@Call(...)) was what I was looking for
<g-w1> you can also probably use @TypeInfo
eax has joined #zig
jmiven has quit [Quit: reboot]
jmiven has joined #zig
Snaffu has quit [Ping timeout: 260 seconds]
<braket> gah, i'm so close
<braket> what's the frame_buffer used for in @asyncCall?
<braket> in the example it looks like it never gets used
<braket> ah nvm, found better examples in stdlib
<andrewrk> ifreund, zig fmt on the std lib looks good :D
<andrewrk> oh wait a minute, looks like I have a parser issue to tackle regarding a return type that is a labeled block
<ifreund> \o/
<g-w1> yep thats the one issue i saw too
<ifreund> there's definitely some things in render.zig that could use cleanup but nothing that needs to block the merge
<andrewrk> I think this CI run is going to pass
<g-w1> is the parser issue a merge blocker?
<g-w1> ah its a LabeledTypeExpr
<andrewrk> yeah, I'll fix it after lunch
geemili has joined #zig
Akuli has quit [Quit: Leaving]
cjb has joined #zig
<andrewrk> drews gonna drew
<earnestly> Cry wolf, anything worthwhile he could add is overshadowed by all of the rest
<josias> I want to see his language completed.
<josias> Or at least published.
<g-w1> ?
ur5us_ has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
<ikskuh> how big is stage2 right now when we exclude std?
<andrewrk> you mean like how big is the stripped ReleaseFast x86_64 executable?
<ikskuh> yep
<andrewrk> or .zig source line count
<ikskuh> file size
<josias> g-w1: Oh. I didn't know about that.
<josias> "Please do not share this website with the others until we believe it's ready for broader distribution." Ah. That explains it.
<g-w1> oh didn't see that XD
eax has quit [Remote host closed the connection]
<josias> Where did you discover it?
<g-w1> andrewrk posted it on the discord server :D
<andrewrk> nark
<andrewrk> ikskuh, 3.2M in the ast-memory-layout branch, where I reduced some of the bloat of zig fmt
<ikskuh> pretty big
<andrewrk> statically linked
<ikskuh> but we have a cool set of nice features :)
Techcable has quit [Remote host closed the connection]
<andrewrk> to be fair, is 2.0M
<ikskuh> well… :D
<ikskuh> i noticed we cannot fit std on a floppy though
<ikskuh> in source form
remby has left #zig [#zig]
<andrewrk> that is a price I am happy to pay in 2021
kbd has joined #zig
<mipri> probably cheaper to get old bulk MMC cards than floppies. And those are *physically* small, so it's more impressive
<ikskuh> you mean getting a microsd? :D
<ikskuh> MMC is 💩
<ikskuh> (i have one, 32 MB of MMC gloryness)
zags has quit [Ping timeout: 240 seconds]
<andrewrk> I think ast-memory-layout is merge ready now
marijnfs2 has joined #zig
<marijnfs2> how do i replace std.ArrayListSentineled(u8, 0)
<andrewrk> gonna do a quick benchmark on master branch vs ast-memory-layout branch of `zig fmt` on the entire std lib
ur5us_ has quit [Ping timeout: 264 seconds]
ur5us has joined #zig