<marler8997>
hmmm, how do I get the zig executable?
<marler8997>
preppedbuild.zig
<marler8997>
I'll need a way to cause "zig build" to print an error that they need to run "zig run build.zig"
<marler8997>
interesting, maybe that will work
<marler8997>
This solution is easily solvable with prebuild.zig, how do I do this with your solution. I'm not seeing it but you said it was more flexible
<marler8997>
I don't see a way to forward the call from build.zig to subbuild.zig, the "build" entry point doesn't support forwarding as far as I can tell
<marler8997>
build.zig just builds subbuild.zig and calls it, but how do I forward all the options from one to the other?
<marler8997>
subbuild.zig is what imports the files from project B
<marler8997>
so with your solution, I split project A into build.zig, and subbuild.zig
<marler8997>
I have project A which depends on project B, and project A wants to import files from project B into it's build.zig file
<marler8997>
I'm not sure what this has to do with getting the options from the dependencies into zig build
<marler8997>
I'm not declaring them in build.zig, there in my subbuild.zig
<marler8997>
I'm not sure what you mean by "declare the deps"
<marler8997>
otherwise, I'll just geting compile errors about failing imports
<marler8997>
I can't use the deps on the first pass that's the whole point of the first pass :)
<marler8997>
that's what the first pass is for
<marler8997>
because I can't do it on the first pass, they won't be availble till the second pass when I've retrieved my dependencies
<marler8997>
are the options supposed to be determined on the first run or the second?
<marler8997>
the options are part of what's generated by my dependencies
<marler8997>
how do I forward all the options from the child build to the main build?
<marler8997>
hmmm, I'm seeing a problem with this method
<marler8997>
well, that's what I'm working on
<marler8997>
I feel like I don't need a package manager, I just need a way to request file trees
<marler8997>
ikskuh, what do you think I should name my subbuild file? realbuild.zig? childbuild.zig?
<dch>
marler8997: np, I'm sure eventually somebody will poke it with a stick. thanks!
<marler8997>
dch, sorry I'm not too familair with that, you might have to ask another time since it seems no one is responding right now
<marler8997>
what's your github name?
<marler8997>
interesting
<marler8997>
oh because you're customizing how build.zig is built, whereas with prebuild.zig, you're not customizing how build.zig is build
<marler8997>
how so?
<marler8997>
so what makes this method better than prebuild.zig?
<ikskuh>
marler8997: exactly what i'm saying
<marler8997>
what does "compile your own build runner" mean?
<dch>
marler8997: typically we need microcode update & compiler functionality like retpoline to address these, and yes some of them are basically "get a better cpu"
<marler8997>
huh?
<marler8997>
what way is that?
<ikskuh>
marler8997: i don't think having prebuild.zig is a good idea
<marler8997>
seems like a hardware issue that can't be solved with software
2021-02-15
<marler8997>
oh cool, I guess I'm gonna be famous now, I'll be sure to get an agent and I'll try not to forget my now peon friends
<marler8997>
spotlight huh?
<andrewrk>
marler8997, I want to make sure to give you the spotlight you deserve in this talk ^ :)
2021-02-14
<marler8997>
but then I won't see where the mistakes are
<marler8997>
I could make ALL pointers optional by default for the time being
<marler8997>
because win32metadata hasn't properly marked all it's optional pointers as optional
<marler8997>
the parameter type
<marler8997>
without modifying the type
<marler8997>
is there a way to trick Zig into letting me pass null to a non-optional ptr?
<marler8997>
struct fields that reference other fields? I remember an issue for that, what's the status on it?
<marler8997>
with this, zigup can be written entirely in zig
<marler8997>
yeah crazy, I figure I might as well support it in my ziget library though
<marler8997>
ok cool, worth a try then
<marler8997>
so, would I theortically be able to use that to talk HTTPS?
<marler8997>
what was that zig library that could do ssl/tls?
2021-02-13
<andrewrk>
marler8997, I'll have another look, thanks for the ping
<marler8997>
one thing I think I've realized since is I think #7664 isn't correct because it requires all paths to be resolved to absolute paths first, and I don't think it's doing that
<marler8997>
andrewrk, what can I do to help make progress on issue #6044 and/or my PR #7664
<marler8997>
technically @This() at the top level is still just a type
<marler8997>
well, I suppose at some point something has to be unqualified
<marler8997>
obviously const Types would not be correct?
<marler8997>
and ifreund, in your variation, what kind of consts do you think should be qualified?
<marler8997>
ifreund, I've added a "Varition" section to describe that
<ifreund>
marler8997: even if there was, that sounds too complex IMO
<marler8997>
Maybe there's a way to tell if a variable has any mutabaility?
<ifreund>
marler8997: I don't think the proposal is worth it without applying to const decls as well
<marler8997>
having to us a type qualifier for every single constant...not so sure about the tradeoff on that one
<marler8997>
ifreund, yeah that's a good point, but, that would be a much bigger change
<ifreund>
marler8997: I think it needs to affect const decls as well, a const pointer to mutable data is not at all uncommon
<justin_smith>
marler8997: OK, it was worth checking out that namespace, std.debug.dumpCurrentStackTrace(@returnAddress()) lets me create a dump that makes my editor jump to the failed test instead of the test failure code
<marler8997>
lol
<justin_smith>
marler8997: d'oh, of course that already existed
<zags>
marler8997: https://github.com/ziglang/zig/issues/2859 looks similar, but no realworld footgun motivation so it was rejected. Doesn't seem to preclude opening a new proposal.
<marler8997>
justin_smith, isn't that what std.debug.panic does?
<marler8997>
ok, I'm working on a simple proposal
<zags>
marler8997: Shared.x already works, so I'll use that as an idiom for now, would be nice to have it enforced for sure
<marler8997>
I don't remember seeing this proposal before, but it's possible it has been proposed, anyone that's lurking know?
<zags>
marler8997: that works, love it
<marler8997>
You would have to declare const Self = @This(); at the top of your file
<marler8997>
a nested function
<marler8997>
oh
<marler8997>
not sure what you mean by "struct function"
<marler8997>
it would also mean access global variable would be different
<marler8997>
it's an interesting idea, I think worth considering
<marler8997>
for generic types it would be @This().x
<marler8997>
yeah you're right, a type is pretty distinct from a value
<marler8997>
you see what I'm saying, TypeName is also inside struct, everything in Zig is inside a struct
<marler8997>
But could TypeName also be an instance variable?
<marler8997>
I suppose you would say no because it is "const" instead of "var"? Is that right?
<marler8997>
could you make the same mistake with Shared?
<zags>
marler8997: could you elaborate on why Shared.x moves the problem? If you HAD to use self.x or Shared.x, for fields and decls respectively
<marler8997>
you're more likely to make both mistakes
<marler8997>
yeah I can see how this would be an issue if you're working with other language
<marler8997>
that's the first mistake
<marler8997>
of course
<marler8997>
sure I can see that opinion, my point was just that it's harder than having to make just one mistake
<marler8997>
so that's 2 mistakes that have to work in concert simultaneously
<marler8997>
I mean, you have to both mistakenly declare the variable as a global instead of a field, and also forget to access it through "self.foo"
<zags>
marler8997: you mean not using self. two places? That's an obvious risk when you write the two functions at the same time. If you make the mistake in the first function, you're likely to make it in the next.
<marler8997>
because accessing Shared has the same issue?
<marler8997>
but maybe that is just moving the problem?
<marler8997>
zags, using Shared.x is an interesting idea
<marler8997>
I was saying it's going to be more rare if you have to make 2 mistakes in concert
<marler8997>
lol, well that wasn't what I meant
<zags>
marler8997: you're better than me
<marler8997>
I'm sure I've made both mistakes at different points, but I don't think I've ever made both mistakes at the same time
<marler8997>
you had to make 2 mistakes there
<marler8997>
if it was an instance variable, it would be self.x += 1
<marler8997>
inside the struct
<marler8997>
zags, you still have to access then differently
<zags>
marler8997: because the update happens behind accessors
<marler8997>
since you access instance/global variables differently, how did you mistake it for an instance variable?
<marler8997>
in your case, how did this become a footgun?
<marler8997>
there was a proposal for that, it got rejected maybe I can find it
<marler8997>
zags, if nothing else changed, that would mean putting static on literally everything because files are also structs
<marler8997>
yeah, but it's an important detail, maybe important enough to be included in it's own bullet (or mentioned in the first bullet)?
<marler8997>
Wording could probably be improved, but something like that maybe
<marler8997>
So maybe in the proposal we say something like. "In Zig the "return" statement is overloaded to return both values and errors with error flow-control. This proposal simplifies "return" to only handle values, and adds a new "throw" keyword to handle errors. This has the advantage that one can always immediately tell whether a return/throw statement will return a value or trigger an error."
<marler8997>
with proposal: try = "maybe throw", return = "no throw", throw = "throw"
<marler8997>
for the exact same reason we though it was better not to overload try, we are moving the "return" overload
<marler8997>
that's a more general description of the error.Bad example we just looked at
<marler8997>
I think the stronger issue this solves is that currently you can't tell lexically whether error flow-control is triggered "return x" may or may not
<marler8997>
yeah it's a really weird mix between how Zig handles error vs values
<marler8997>
it also means there's no way to actually return a value from this function
<marler8997>
using a tagged union makes sense there
<marler8997>
oh yeah I see what you're asking
<marler8997>
it means the caller would get an instance of Foo when the catch/switch on the error
<marler8997>
yeah, that's what the proposal is trying to address
<marler8997>
throw SomeStruct.init(...)
<marler8997>
actually if you're going to explain, I would also say it's triggering error flow-control
<marler8997>
sure, I don't think you need to explain what it's doing, but probably doesn't hurt
<marler8997>
mikdusam that works
<marler8997>
or we could say "replace the current 'return ERROR' mechanism with 'throw ERROR'"?
<marler8997>
"introduce the 'throw' operator to trigger error flow control"
<marler8997>
so this bullet is really just introducing "throw" to replace the old "return error"
<marler8997>
oh right
<marler8997>
ok
<marler8997>
or "error flow may now only be triggered by 'try' or 'throw'"?
<marler8997>
for bullet 2, maybe say "only try and throw trigger error control flow" ??
<marler8997>
yeah, that one's been bugging me too
<marler8997>
`return` no longer triggers error flow-control
<marler8997>
that's your first bullet
<marler8997>
actually ignore me on that
<marler8997>
I dunno, it should be somewhere though :)
<marler8997>
because before, you wouldn't necessarily know whether "return x" executes errdefers or trigger the caller's catch block
<marler8997>
this definitely makes Zig adhere more to its tenant of "no hidden control flow"
<marler8997>
Maybe "With this proposal, "return x" is always regular control flow." ??
<marler8997>
I think we should include that second sentence to.
<marler8997>
better
<marler8997>
sure
<marler8997>
right, now "return x" always returns, never triggers error flow. Error flow now required either "try" or "throw"
<marler8997>
triggered by runtime values?
<marler8997>
yeah
<marler8997>
with this proposal, "return x" never triggers error flow control no matter what the value of x is
<marler8997>
what about this? "The primary goal of this proposal is to distinguish error control flow lexically rather than have it be triggerd by values at runtime."
<marler8997>
The first sentence "Primary to this proposal..." doesn't sound grammatically correct to me
<marler8997>
with "By providing this builtin, the programmer has full control over when to clear the error stack, if at all."
<marler8997>
"By providing this builtin the programmer is able to have full control of when and to clear the error stack if at all."
<marler8997>
self correction, replace
<marler8997>
there's a way to do it
<marler8997>
you should put the try/throw case in the same box, on different lines
<marler8997>
good, I was about to say something :)
<mikdusan>
marler8997: added binary table (just after code example)
<marler8997>
I quoted "array" because I've overloaded the term here
<marler8997>
where ptr is pointing to an "array"
<marler8997>
its like a struct like this "struct { char *ptr; size_t len }"
<marler8997>
a slice is not a pointer to an array
<marler8997>
in c terms, a Zig array of 4 bytes is equivalent to struct { char _0; char _1; char _2; char _3};
<marler8997>
no
<marler8997>
yeah, and pointers to arrays (which are "values" in zig) implicitly convert to slices
<marler8997>
&cartridge.magic
<marler8997>
prefix with &
<marler8997>
^
<marler8997>
magic: [4]u8 = "\x4e\x45\x53\x1a",
<marler8997>
in your case, I would set .magic as a default value
<marler8997>
an yet another option is partial initialization: var cartridge = Cartridge { .magic = undefined, .prg_blocks = 0 };
<marler8997>
another option is adding default values to your fields
<marler8997>
var cartridge : Cartridge = undefined
<marler8997>
*a block of code is worth a thousand words* :)
<marler8997>
stilbruch, can you provide a link to the code?
<marler8997>
typo "...programmer is able to have full control of when to clear the error stack if at all"
<marler8997>
We found multiple cases where a programmer may want to clear the error stack at different places or even not at all. By providing this builtin the programmer is able to have full control of when and to clear the error stack if at all. Note that this builtin does not prevent other features from also being implemented to clear the error stack such as https://github.com/ziglang/zig/issues/1923#issuecomment-461530246
<marler8997>
this is what I would say:
<marler8997>
what was the proposal to clear error stack after catch block?
<marler8997>
I can make a comment at the bottom I can't see how to make line comments
<marler8997>
I think we can improve the rationale section for @clearErrorStack
<marler8997>
oh and I just realized doit's actual error set is Overflow/Megaflow
<marler8997>
lol
<marler8997>
the comments for .Overflow and .Underflow are showing different ways of representing the error set of f1()
<marler8997>
we should probably update the comments about the error stack with the new terms clear/push/throw
<marler8997>
I think that's supposed to be error.Overflow (in the .Overflow case of the switch)
<marler8997>
I think that's a sign of a great proposal, that is solve many issues
<marler8997>
if we want to mention it, I would say something like "because this proposal provides a lexical way to throw errors, it could be used to solve #2647"
<marler8997>
it helps because it provide a lexical way to throw an error without it being an error value
<marler8997>
yeah true, it would have to coerce down properly to be reasonable
<marler8997>
do you think we want to mention this as a path forward to solve #2647 in related proposals?
<marler8997>
oh dang
<marler8997>
"catch" more bugs with "catch", now we have a slogan! :)
<marler8997>
very nice, that's great data, you immediately catch 16 existing bugs!
<marler8997>
let's make sure we include that footgun somewhere in there, is it in there?
<marler8997>
right, that's definitely a footgun
<marler8997>
so that's a good argument to keep it under this proposal
<marler8997>
yeah, it still falls under that umbrella
<marler8997>
if that's the case, we may want to make the separate proposals
<marler8997>
unless I'm missing something
<marler8997>
I mean, you could do everything else in the proposal and not do that, its still an improvement and everything still works
<marler8997>
right I understand the justification, I'm just saying I think it's orthogonal to the other changes
<marler8997>
without the "catch EXPR", wouldn't "const x = doit()" just work like today, where "x" is just an error-union?
<marler8997>
it might be completely orthogonal to everything else
<marler8997>
looking at this now, I actually think the whole "catch EXPR" is an optional part of the proposal
<marler8997>
after "Primary to this proposal to elevate error flow-control to lexical distinction from regular flow-control:"
<marler8997>
I mean in the initial list that currently has 4 items
<marler8997>
I don't see the new "catch EXPR" being mentioned there
<marler8997>
I think you're missing an item in the initial list of changes
<marler8997>
then further down show how you can use errors as values also
<marler8997>
we could change afunc to return !void, then show that "return error.Bad" would result in a compile error