<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:
<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]
<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 fields...is 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