<marler8997>
g-w1, not sure, it should be working but for some reason it's failing
<g-w1>
marler8997: what was wrong with bearssl? it seems like you fully nuked it?
<marler8997>
g-w1, that's why I was saying bearssl and/or iguana, because they can be compiled statically
<marler8997>
and bearssl also not working, need to figure that one out
<marler8997>
but iguana not working yet
<marler8997>
would be nice to either use iguana or bearssl I think, for the prebuilt-binary backend
<marler8997>
ok, which backend are you going to use though?
<g-w1>
marler8997: ok I will just do macos and linux for now
<marler8997>
it doesn't work on windows yet
<g-w1>
marler8997: I am trying to add github actions check and deploy binaries of zigup, can I add more steps besides x86-linux to the github release step?
2021-02-22
<siraben>
cc marler8997 ^
<marler8997>
shoot
<marler8997>
is 10.12 one of the versions Apple no longer supports?
<marler8997>
just leave Go how it is, then we can use this article as a reason not to use Go. Zig Stonks!
<marler8997>
but best not to encourage them to make Go better right? :)
<marler8997>
yeah, they could do the same with Go if they were so inclined
<marler8997>
sorry, I mean Nix (not Zig)
<marler8997>
but if Zig encapsulated every go package in a derivation, it could do that
<marler8997>
right, overriding go.mod would need to be recursive
<marler8997>
if you have a better solution than lockfiles, that means my build doesn't break I'd love to hear it
<marler8997>
daurnimator what do you suggest?
<siraben>
marler8997: sounds like it. The only way I think of to override go.mod is to done some sed wizardry
<daurnimator>
marler8997: I think the pattern of having a lockfile in version control is poisoness
<marler8997>
I think if Go had a way to easily configure/override go.mod, then maybe that would be enough?
<marler8997>
right that's kinda what it sounds like
<daurnimator>
marler8997: I think Go in particular has made it impractical to do "the right thing"
<marler8997>
I can see nix deciding to just leverage what Go already has, if Go wants to change it, it can change it
<marler8997>
every python package has it's own deriviation, so updating it updates it for everyone
<marler8997>
but siraben I believe you're correct about python packages
<marler8997>
I'm not sure what nixpkgs does with go
<siraben>
marler8997: in building Python packages for Nixpkgs you have to specify all the python inputs actually, so it would follow the "latest" version (latest in nixpkgs)
<marler8997>
the nixpkgs CI to be specific
<marler8997>
in nix land, verified means it has passed CI
<daurnimator>
marler8997: what is "verified"
<marler8997>
If your philosophy is "I always want the latest version of all my dependnecies, even if they have not been verified", then that's just a fundamental difference
<marler8997>
daurnimator, my guess is it's not using go.mod
<marler8997>
oh we're talking about indirect dependencies, not direct dependencies
<marler8997>
I'm not seeing the problem, daurnimator are you saying that package managers should take updates from every single tool/project they reference automatically?
<marler8997>
and/or, submit a PR to nixpkgs to apply it
<marler8997>
nix package override?
<siraben>
marler8997: say I update SDL2 in Nixpkgs, then every package that depends on it (directly or transitively) gets a rebuild.
<marler8997>
> if that's the case, then this is not an issue for nix, because updating a package in your nixpkgs file updates it for everyone (by default)
<siraben>
marler8997: " buildRustPackage requires either the cargoSha256 or the cargoHash attribute which is computed over all crate sources of this package. cargoHash256 is used for traditional Nix SHA-256 hashes, such as the one in the example above. cargoHash should instead be used for SRI hashes. For example: "
<daurnimator>
marler8997: why not?
<marler8997>
daurnimator, yeah that's an issue with "lockfile dependencies", but this doesn't apply to nigpkgs
<marler8997>
not sure on that one
<siraben>
marler8997: but for Rust/Go packages aren't they pinned by the project's lockfile?
<marler8997>
if that's the case, then this is not an issue for nix, because updating a package in your nixpkgs file updates it for everyone (by default)
<marler8997>
If I understand correctly, in the article he said "pinning dependencies" is problematic because it makes updating them more difficult
<marler8997>
it's codifies a programming technique that I've learned over the years and I think makes my code better overall
<marler8997>
but I'm glad that you are taking issue with the rule, I think it shows that the rule in and of itself is not obvious
<marler8997>
unless again, the other 2 criteria apply
<marler8997>
if it's a buggy implementation, I think I would disagree
<marler8997>
if it's a partial implementation I would agree
<marler8997>
did I say we shouldn't point to it when reviewing code?
<daurnimator>
marler8997: what's the point of the zig zen if not something to point at when reviewing someone else's code?
<marler8997>
it's saying, if you're about to implement something that you know will have bugs, maybe just @panic() for now and come back to it later
<marler8997>
This is just a general guidance when writing code
<marler8997>
daurnimator, I'm not sure what you mean by "won't everyone say"?
<marler8997>
the rule of no implementation > buggy implementation wouldn't apply if 1) a bug-free implementation is impossible and 2) having any implementation at all provides good benefit
<marler8997>
that really leaves us with no choice
<marler8997>
unfortunately
<marler8997>
yeah that sounds super ugly, but sometimes ugly is necessary
<daurnimator>
marler8997: the implementation we use right now for selfExePath on OpenBSD only works if: 1. you are an application not a library. 2. you don't modify arg0. 3. no one has called chroot. 4. no one has moved or replaced the running executable. 5. you haven't modified PATH in the current process..... etc.
<marler8997>
this one might be an exception to the rule then
<marler8997>
oo that's a tricky one
<daurnimator>
marler8997: this isn't a "sometimes works" though: its a "has bugs when used in combination with a few other features that's undectable; and we're sort of just luck we don't use right now"
<marler8997>
so having a implementation of selfExePath that works some of time, without bugs, wouldn't apply to the rule
<marler8997>
daurnimator, we already clarified that "sometimes works" != "has bugs"
<marler8997>
yeah the Nix phdthesis mentions that exact issue
<daurnimator>
marler8997: the implementation we have now does have potential bugs: it's a hacky work around. but without it we wouldn't have 1. stack traces on openbsd. 2. be able to distribute binaries.
<marler8997>
maybe the rule would state, it's better to not implement the selExePath feature on OpenBSD unless it can be implemented without bugs?
<marler8997>
OpenBSD doesn't support getting it's own exe, not sure the relation
<marler8997>
no implementation is better than buggy implementation ?
<marler8997>
I think my original statement of "sometimes works" was actually supposed to be "has bugs"
<marler8997>
yeah that seems like a good place
<marler8997>
examples like the one you just mentioned
<marler8997>
Maybe providing examples of our Zig Zen points somewhere would be beneficial
<daurnimator>
marler8997: exit with "segmentation fault" is better than "run random data as code"
<marler8997>
oh yeah that's true
<daurnimator>
marler8997: which is the whole philsophy of segfaults
<marler8997>
looking back it looks like it's basically what daurnimator said "runtime crashes > bugs"
<marler8997>
yeah that's a good description
<marler8997>
there's some sort of distinction between "partially implemented" and "buggy code that fails catastrophically"
<daurnimator>
marler8997: you can also get into tricky definitions of "works" -> e.g. what if something is O(n^2) on one platform and O(1) on another?
<marler8997>
so maybe then the definition of "works" needs modification
<marler8997>
daurnimator I would agree with that
<marler8997>
it's saying, don't release a feature half-baked, either implement it robustly, or don't implement it at all
<daurnimator>
marler8997: except when the alternative is doesn't work....
<marler8997>
what I think is insightful is that its better to "always fail" than "sometimes work"
<marler8997>
everyone can agree "sometimes works" is bad
<marler8997>
exactly
<daurnimator>
marler8997: "sometimes works" is the opposite of robust, which is in the language tag line
<marler8997>
"sometimes works" is where bugs live
<marler8997>
I like "runtime crashes are better than bugs", these 2 statements might be more different in some ways
<daurnimator>
marler8997: we had to select a "sometimes works" rather than a "robust"
<marler8997>
g-w1, yes, I think it's a more general version of that
<daurnimator>
marler8997: e.g. have a look at the issues around OpenBSD not having a good .openSelfExe
<marler8997>
daurnimator, the opposite actually
<daurnimator>
marler8997: ehhhhhhh. that ends up being a recipe for bad portability
<marler8997>
something I codified this morning as I tried to analyze some of my programming sensibilities
<marler8997>
candidate for Zig Zen: "always fails is better than sometimes works"
2021-02-21
<Xavi92>
marler8997: thanks for your reply :)
<marler8997>
*type verification at comptime
<marler8997>
that was for Xavi92
<marler8997>
the C printf security issues don't apply to Zig because it does type verification at runtime (i.e. using {s} for an integer will be a compile error)
<marler8997>
clang maybe?
<marler8997>
try a different compiler?
<marler8997>
one of the reasons why Zig not having warnings will be nice
<marler8997>
or sometimes an older compiler, sometimes older compilers aren't smart enough to detect valid things. A common one is detecting whether variables are uninitialized
2021-02-20
<marler8997>
ifreund thanks for the clarification
<ifreund>
marler8997: write should never return 0 on posix conformant systems
<marler8997>
like, maybe it's a bug in writeAll?
<marler8997>
stil not sure it's actually a bug though, was wondering if anyone knew more
<ikskuh>
marler8997: happy to accept PRs
<marler8997>
I think Writer is expecting write not to return 0 ever...not sure
<marler8997>
oh no that's not what supposed to be called, but returning 0 does cause an infinite loop
<marler8997>
it looks like bearssl might have a "br_sslio_write_all" function for this purpose
<marler8997>
ikskuh I think there's a bug in your zig-bearssl, I think write cannot return 0, it creates an infinite loop in std.io.Writer.writeAll
<marler8997>
does the engine passed into Client.init need to outlive Client as well?
<marler8997>
so i've got a stream that references Client, I assume client needs to outlive stream
<marler8997>
ikskuh you're not available are you?
<marler8997>
anyone familair with bearssl online that can explain to me the lifetime of a couple things?
<marler8997>
ok going to add bearssl, my guess is it takes an hour
<marler8997>
ah didn't know that
<marler8997>
Thal20, nope, my_ptr[0..my_len] give you []u8
<marler8997>
I like this convention, we should keep going, I wanna see lionssl, and walrusssl and so on
<marler8997>
so along with wolfssl, there is also bearssl
<marler8997>
Thale20, mmap?
<marler8997>
ifreund...oooo, didn't know about that...will look
<marler8997>
I think I'll have to wait to get iguana working before releasing static prebuilt binaries of zigup, depending on openssl and trying to make that work on all distributions is going to require some "reloader" magic that I don't feel like dealing with
<marler8997>
ah @tagName
<marler8997>
comptime string
<marler8997>
enum value to string?
<marler8997>
yeah, it's fundamental design and features are really good. There are however some oddities that can be improved
<marler8997>
in any case, I think setOutputDir will work, thanks for the help
<marler8997>
might be unnecessary complexity, not sure
<marler8997>
when using outputdir, they are handled the same
<marler8997>
when using cache, .o files and exe files are handled different
<marler8997>
not the exe though, which is what is causing the problem
<marler8997>
ah I see
<marler8997>
I thought zig would put the output of compiler invocations in the cache
<ifreund>
marler8997: the output dir is where the output of zig compiler invocations go. The install dir is where these artifacts will be copied to when you do zig build install
<marler8997>
where does alexnask hang out? Is he here on irc or dicord?
<marler8997>
I'm still unclear what Zig thinks the output dir is for, and/or the install prefix for that matter at this point
<marler8997>
but I'm confused why it puts .o files in there? wouldn't those go into the cache, not the output dir?
<marler8997>
ok, so I've confirmed setOutputDir is relative to CWD
<marler8997>
maybe but I still want to build the binaries with build.zig
<ifreund>
marler8997: output dir won't be set until the objects are built...
<g-w1>
marler8997, do you think it would be a good idea to setup a github actions to automatically compile the latest zigup and package it in github releases? I can do that if you want?
<marler8997>
it looks like it goes into cwd?
<marler8997>
it doesn't go into zig-cache
<marler8997>
I'm still confused about output_dir
<ifreund>
marler8997: oh, I think I actually implemented something that will do what you want, see LibExeObjStep.override_dest_dir
<marler8997>
the goal is simple here, just build a bunch of exe variants
<marler8997>
that's fine
<marler8997>
ok that make sense with everything else
<marler8997>
in that case, it doesn't have anything to do with install prefix right?
<marler8997>
ok great, that answers one question
<marler8997>
is it for both?
<marler8997>
I see .o files in it, so it seems like it's for build, but if it's relative to install prefix, then it's for install, hence the confusion
<marler8997>
is output dir supposed to be for build or install?
<marler8997>
yes
<marler8997>
for the purposes of uploadeing to github
<marler8997>
my build.zig file is building a bunch of variants of the same exe
<marler8997>
oh I see dest_dir, maybe that's what I want
<marler8997>
is output_dir supposed to be a relative dir to install prefix?
<marler8997>
I'm adding a step in my build.zig to build binaries for multiple platforms, I'm a bit confused in outputdir vs installdir
<marler8997>
yeah this is what I needed
<marler8997>
ooo I think I'm on to something
<marler8997>
wait, maybe I can make these exe steps depend on a check step?
<marler8997>
I could run the check in there
<marler8997>
is there a way to add a callback to a target just before it builds?
<marler8997>
zig build -h should work whether or not they've specified a backend
<marler8997>
zig build --help doesn't work unless an ssl backend is selected now, which is not what I want
<marler8997>
I'm now adding a new target that doesn't require an ssl backend
<marler8997>
it requires the user to select an ssl backend they want to build with
<ikskuh>
marler8997: why does "zig build" require ssl?
<marler8997>
I could check whether or not the "help" is being enabled, if that's available, does this sound correct?
<marler8997>
My build.zig file for zigup requires that the user select an ssl backend, but that makes "zig build -h" not work without a backend selected
<marler8997>
it is an odd use case because it's only declarations, no actual Zig code in there
<marler8997>
andrewrk I was thinking to test tokenization/parsing perf
<marler8997>
ikskuh yeah the Win32 api is massive
<ikskuh>
marler8997: wow, that's one big chungus
<andrewrk>
marler8997, not yet - this is stage2 so the next step before we can test that is to make stage2 support more language features
<marler8997>
done
<marler8997>
sure I'll do that
<g-w1>
marler8997 just looked at some of the files in api, you can replace test "" { with test {
<marler8997>
that's over 4 times bigger than the standard library!
<marler8997>
shoot I didn't get notified about this stream
<marler8997>
oh shoot, I will look that up then
<marler8997>
Zig showtime about the techniques you used here, you're using data-oriented design techniques if I recall yes?
<marler8997>
zig build ... Error: unable to locate LLVM, add -Dbuild-llvm to build it here
<marler8997>
when buildin the zig compiler to be specific
<marler8997>
this gives me ideas of enhancing zig to be able to autobuild llvm/clang/lld when requested by the user
<marler8997>
does it work?
<marler8997>
has anyone tried to build LLVM/Clang with zig cc?
<marler8997>
challenge, translate all these cmake files to build.zig
<marler8997>
that's great, a whole bunch of cmake files
<marler8997>
I've been spoiled by this awesome all-in-one sdk, I never want to go back to msvc
<marler8997>
andrewrk, is it easy to update the windows Zig+llvm+clang binaries? they don't build since the nameless tests were added
<andrewrk>
marler8997, nameless tests are never filtered out with --test-filter, so they can be used to import other files and have --test-filter work when using zig test to discover the entire source tree
<marler8997>
having troubles using it with zigup at the moment because "zig build" is trying to create a symlink for some reason
<marler8997>
g-w1, I got ziget to work with schannel by the way
<marler8997>
huh, Zig has nameless tests now?
2021-02-16
<marler8997>
takes elements from what you were telling me earlier
<marler8997>
I think the right solution is going to involve actually hooking into zig build somehow
<marler8997>
the problem with "zig run" is that the zig exe is gone, the problem with "zig build" is that the entry point is not flexible enough
<marler8997>
I think the fundamental problem here is that zig needs to be involved during the whole process, it can't build an exe and peace out in the middle of the build
<marler8997>
not with execve
<marler8997>
it makes me think there's something wrong with this solution, like we're missing something
<marler8997>
I can't think of a good solution to this
<marler8997>
for what reason?
<marler8997>
in fact there was a bug for that already :)
<marler8997>
that's already being used
<marler8997>
ZIG_RUN_EXE?
<marler8997>
the only viable solution I can think of is to add an environment variable
<marler8997>
shoot, this means we'd have to patch "zig run"
<marler8997>
zig will have to pass itself to the resulting build executable somehow, is it doing this?
<marler8997>
how does that give me the same zig executable that was used on "ZIG run build.zig"?