knebulae has quit [Read error: Connection reset by peer]
craigo has joined #zig
<gruebite>
if i wanted to tackle the C ABI compatibility, is there context i should have? i recall there being a discussion on wanting to implement it fully at a specific stage (not in c++)
gert_ has quit [Quit: WeeChat 2.8]
gert_ has joined #zig
cole-h has joined #zig
knebulae has joined #zig
ronsor has quit [Read error: Connection reset by peer]
craigo has quit [Ping timeout: 240 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
gert_ has quit [Quit: WeeChat 2.8]
waleee-cl has quit [Quit: Connection closed for inactivity]
frett27_ has quit [Ping timeout: 260 seconds]
<shakesoda>
is there literally any use for volatile other than mmio
<shakesoda>
like, if you hypothetically just actually named it "mmio" as an attribute pointers can have, would that be accurate
<shakesoda>
emphasis on this as a question and not a suggestion
<gruebite>
*mmio foo?
<leeward>
shakesoda: I don't know of another use for volatile.
<shakesoda>
gruebite: yeah
<leeward>
It doesn't help with regular memory, since it doesn't affect caches. A cache hit means it won't read from main memory, volatile or not.
<leeward>
If you want to prevent timing attacks, for example, you have to use other mechanisms to evict cache lines.
<leeward>
The only other thing it could affect is aliased pointers, but we have other mechanisms for that.
<pixelherodev>
leeward: shakesoda: I believe other uses are mentioned
<pixelherodev>
Somewhere deep in a GH thread
cole-h has quit [Quit: Goodbye]
marnix has joined #zig
ur5us has quit [Ping timeout: 244 seconds]
eleanor-nb has joined #zig
<andrewrk>
shakesoda, yeah, mmio is just about it
<leeward>
There could be an ISR that services some piece of hardware and updates a chunk of memory as its mechanism for communicating with the rest of the system. That might need volatile pointers.
<leeward>
That case is very similar to mmio though.
<andrewrk>
it could be renamed to "sideeffect" and would be a nice change for asm as well
<leeward>
It's just emulated.
<andrewrk>
`asm sideeffect` / `*sideeffect T`
Nypsie has joined #zig
<eleanor-nb>
May I suggest `impure`? Shorter, and in line with FP terminology. At one time introducing it was part of #5241.
dddddd has quit [Ping timeout: 240 seconds]
eleanor-nb has quit [Ping timeout: 245 seconds]
eleanor-nb has joined #zig
dddddd has joined #zig
<gruebite>
i think impure would be confusing here. not sure fp constructs map well to hardware semantics.
<leeward>
Particularly since it implies that things not using it are pure, which could lead to a lot of overuse.
eleanor-nb has quit [Remote host closed the connection]
<gruebite>
yeah
<gruebite>
i don't mind volatile, since it's deeply rooted in C terminology and familiar. but still misunderstood? i'm not sure how prominent the belief it's for atomic operations is.
<DarkUranium>
There's also the fact that `volatile` means different things in C vs Java, gruebite.
<leeward>
I have no data, but I doubt it's more prominent than the belief it's for "stuff I don't need."
<DarkUranium>
And the fact that *none* of the compilers are compliant with C semantics. (I don't remember why, but I think it has something to do with C semantics not really being useful)
<leeward>
Wha? I've never run into a volatile bug.
<DarkUranium>
leeward, I've lost the source, but I've just read comments by the C standards committee yesterday, on that very topic (among others).
<DarkUranium>
The basically said that they investigated this, and it turned out that 0 compilers implement `volatile` according to Cstd semantics, and it is something that kernel developers (where the difference between the two is critical) are simply aware that this is one of those "normal deviations" --- and they also said that's okay, because C was designed to be practical, so standard theorycrafting is useless if it doesn't fit a purpose.
<gruebite>
java's at a higher level, it won't be touching volatile memory.
<DarkUranium>
leeward, to be clear, apparently, all compilers implement the same semantics --- it just doesn't happen to be the semantics that the C standard specifies.
<gruebite>
and i think the correctness of the semantics vs it's intended use is a separate topic
<gruebite>
its*
<DarkUranium>
I don't know how old the comments were though, so maybe C11 or C14 reconciles that.
<gruebite>
huh, apparently C# has volatile too. didn't know that
<gruebite>
also used differently haha
<DarkUranium>
Does C# have the same semantics as Java there, or ...?
<leeward>
Are you talking about fencing? Most C compilers will reorder access to non-volatile memory around access to volatile memory, but it's not clear the standard forbids that. At least, it wasn't in C99.
<DarkUranium>
leeward, shakesoda: on `volatile` uses, there are.
<DarkUranium>
(w.r.t. this:)
<DarkUranium>
<shakesoda> is there literally any use for volatile other than mmio
<DarkUranium>
<shakesoda> like, if you hypothetically just actually named it "mmio" as an attribute pointers can have, would that be accurate
<DarkUranium>
For example, `setjmp` invalidates all non-volatile locals after a longjmp(). So if you want to use `if(setjmp(...)) { do_something(some_local); }`
<DarkUranium>
Then e.g. `int some_local = 5;` is UB; you need `volatile int some_local = 5;`
<DarkUranium>
s/some local/some_local/
<DarkUranium>
WTF, hexchat is deleting underscores?
<shakesoda>
i'm seeing them here.
<DarkUranium>
Huh, weird.
<shakesoda>
the longjmp issue wouldn't apply in zig, right
<DarkUranium>
shakesoda, unless you're compiling specifically to C, no.
<DarkUranium>
shakesoda, I seem to remember that non-constant globals used in signal handlers (read *or* write) need to be `volatile` too.
<DarkUranium>
I'm sure there are other issues. `volatile` in C is basically `uncached`.
marnix has quit [Read error: Connection reset by peer]
nikita` has joined #zig
dermetfan has joined #zig
Ashpool_ has joined #zig
Ashpool has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
<ikskuh>
ifreund: now that Dunstblick is near-100% zig, i lost most of my code documentation :D
<ikskuh>
i should switch the doc generator to the zig one
<ifreund>
that'd be good, we need more people to learn how the zig docgen works :P
<ikskuh>
haha :D
Ashpool_ is now known as Ashpool
<ikskuh>
first step: add support for that into build.zig
<ikskuh>
aaaand it "failed"
<ikskuh>
docs are somewhere lost in the zig-cache
marnix has joined #zig
_whitelogger has joined #zig
marnix has quit [Ping timeout: 240 seconds]
dddddd has quit [Ping timeout: 256 seconds]
dddddd has joined #zig
marnix has joined #zig
<protheory8-new-m>
How do I link my Zig library to C library `lib.so` in `build.zig` file?
<protheory8-new-m>
* How do I link my Zig library to C library file `lib.so` in `build.zig` file?
<protheory8-new-m>
I guess I don't need to do import?
<ikskuh>
you cannot @import a library
<ikskuh>
if you have a C header, you need to use @cImport
<protheory8-new-m>
I don't have one
<ikskuh>
else you need to write your own package/zig file defining the correct extern symbols
<pixelherodev>
You'll need to define the library functions
<pixelherodev>
Yeah
<protheory8-new-m>
How do I get C header though?
<protheory8-new-m>
I guess I need to write it manually
<fengb>
Zig prefers to share via code
<fengb>
We don't have a defined ABI so it's basically using C's
loooph has joined #zig
<protheory8-new-m>
I got `addPackage()` working, thanks everyone!
<protheory8-new-m>
btw, why is `std.heap.page_allocator` so slow?
craigo has joined #zig
nvmd has quit [Quit: Later nerds.]
<fengb>
Because it's wired into mmap directly. It's not intended to be a general purpose allocator
Ashpool__ is now known as Ashpool
alexnask has joined #zig
<alexnask>
DarkUranium Hey, ping me anytime if you want to talk about zls or lsp stuff, just saw your message in the logs, I wasnt around in IRC for a bit
<DarkUranium>
alexnask, yo!
<DarkUranium>
pong :)
<alexnask>
hihi
<DarkUranium>
Fair warning, I'm not actually familiar with zig otherwise.
<alexnask>
No problem :P
<DarkUranium>
I basically just wanted to ask if you had any guidelines to creating a language with builtin LSP support (n.b.: when I say "LSP", I mean "C API with same features" --- not talking about actual HTTP+JSON protocol, I'll do that via a wrapper)
<DarkUranium>
Bit of background first:
<scientes>
DarkUranium, "builtin" is kinda a mis-nomer, the only important thing is to use the same parser
<pixelherodev>
Not here
<scientes>
and AST
<DarkUranium>
scientes, don't you want the same semantic analysis, too?
<pixelherodev>
It's for a language with an embedded runtime
<alexnask>
I assume they are talking about integrating it into the compiler
<pixelherodev>
Yep
<alexnask>
Which is also a goal for stage 2 eventually afaict
<DarkUranium>
I'm making an embeddable (in the "inside C programs" sense, like Lua; not in the "inside microcontrollers" sense) statically-typed language. A certain someone mentioned this LSP stuff, and I kind of realized that it would be *awesome* if my language had that. It would make it, to my knowledge, the only embeddable language with builtin advanced code editing support.
<pixelherodev>
s/only/first
<pixelherodev>
;)
<pixelherodev>
Only a matter of time
<DarkUranium>
s/first/only* (* terms and conditions may apply)/
<DarkUranium>
there :P
<DarkUranium>
(think someone embedding my language into some custom editor within their program --- they'd have ready-made hooks for autocomplete and all that fancy stuff)
<protheory8-new-m>
I looked up implementation of `std.heap.c_allocator` in master branch, why doesn't `resizeFn` use C `realloc`?
<alexnask>
Yeah it would be nice for sure
<alexnask>
DarkUranium, for LSP specifically (or an equivalent protocol with the same features) all you need access to is the resolved types and their associated definitions
<fengb>
resizeFn guarantees in place
<DarkUranium>
alexnask, yeah ... but the problem is, I can't just reparse the entire universe the moment the user hits a character.
<DarkUranium>
Also, the file they're editing will have errors, which is something to deal with.
<protheory8-new-m>
I'm not sure what does 'expand or shrink memory in place' means to be honest
<alexnask>
Right, both valid points. In zls we reparse the whole file on every change (the editor will usually not send a request for every char change but for a few characters that were inserted/deleted within some timefram)
<pixelherodev>
protheory8-new-m: realloc can change the address
<leeward>
DarkUranium: volatile in C has no interaction with the CPU's cache. It's a compiler directive, not a processor one.
<pixelherodev>
Which isn't allowed for std.mem.Allocator
<fengb>
in-place means the pointer doesn't change
<leeward>
DarkUranium: Also, I had a similar issue with underscores on XChat. Fixed by fiddling with fonts.
<pixelherodev>
DarkUranium: Zig's parser is error-tolerant
<pixelherodev>
It'll always return a full AST even if there are errors in the source
<alexnask>
I thought about doing something more clever but Im using the stdlib parser and its quite a difficult problem in the first place (detecting what statements need reparsing and replacing them)
<DarkUranium>
leeward, aye, I meant more in terms of caching at the language level.
<DarkUranium>
leeward, in that a compiler could decide not to read the same ptr twise.
<alexnask>
The error tolerance is easier, in the zig parser its implemented by skipping ahead to some character depending on the context when the node is not valid
<alexnask>
For example `;` in blocks
<fengb>
So the Zig parser now keeps trying after the first error?
<alexnask>
Yeah Vexu implemented this really quickly right after zls started becoming useful
<alexnask>
Since it was stopping at 1 error before although the API was meant for multiple errors from the getgo
<DarkUranium>
alexnask, for the reparse issue, what I was thinking was to use memoization.
<leeward>
DarkUranium: I guess you could say the C abstract machine gets to cache things that aren't volatile, but that makes my brain hurt this early.
<DarkUranium>
alexnask: For example, if I insert a character at position 50 ... all *that* can change is the token at that position, or the immediately preceding token. Everything before that is 100% okay (and so is any parse subtree that's fully contained to the preceding range).
<DarkUranium>
alexnask, and the moment I run into a token that has the same position & contents as before (shifted by the insertion amount), I know that & everything after it is unchanged, too. Because the lexer is not context-sensitive.
<DarkUranium>
As a bonus, if I use an immutable datastructure for this, I can have async tasks (such as a symbol lookup) running on the old version.
<protheory8-new-m>
Thanks everyone
<DarkUranium>
Semantic analysis is more difficult, but I know for a fact that it's been done before with this approach.
<pixelherodev>
np
<alexnask>
This does sound viable for sure but in my experience reparsing was not such a big performance hit to necessitate rewriting the parser with this in mind. YMMV of course
<DarkUranium>
alexnask, I reckon it depends on the sizes of programs, etc.
<DarkUranium>
Note that it's not just reparsing, but also re-semantic-analysising.
<alexnask>
Yes, this is true. Ive tested zls with 80k+ loc files and this part is good enough (although I could optimize it further for sure)
<pixelherodev>
Hmm, here's a thought
<pixelherodev>
Fully lex every time unconditionally, then do a differentiation against the previous lex to speed up the parser
<DarkUranium>
pixelherodev, that's sort of what I said. Except you don't need to fully lex!
<alexnask>
Right you only need to lex the new text and replace the tokens in the old range that was possibly deleted
<DarkUranium>
Remember that lexers are greedy (basically: once a token is emitted, anything that follows the token *cannot* influence the previous results). That's why a change at pos=50 can only affect the token, or the immediately preceding token.
<DarkUranium>
alexnask, exactly.
<pixelherodev>
True, true
<DarkUranium>
And you only need to re-parse parts that had their tokens changed.
<DarkUranium>
(for parsing, this is a trivially-modified packrat parser)
marnix has joined #zig
<Nypsie>
This case would still parse nearly the full file if you insert an extra line at line 5 for example, right?
<Nypsie>
Well, I guess that could invalidate whatever is behind it anyway so that'
<Nypsie>
s fine
<DarkUranium>
Nypsie, no, like I said, you shift all the later offsets by whatever you inserted.
<DarkUranium>
So if you inserted 3 characters, you'd check if (pos == old_pos+3)
<Nypsie>
Aaaah I see
<alexnask>
Right, this would only cause a new parse of the single newline token (whioch will return 0 nodes) if I understand correctly
<DarkUranium>
After all, parsers don't care about source offsets (other than to forward them to error handling)
<Nypsie>
(I ment with some actual code, Alex. My bad, should've been more specific)
<DarkUranium>
alexnask, I think you could actually special-case this!
<alexnask>
Yeah for sure, just saying in general :)
<alexnask>
This is very similar to what I had in mind when starting zls but I never went ahead with it
<DarkUranium>
alexnask, after all, a newline is an "ignorable token" (my lexers tend to have the concept --- useful for syntax highlighting)
<alexnask>
Mostly because of the convenienve of a good, fast already available parser in stdlib
<alexnask>
convenience*
<DarkUranium>
I did run into this which seems interesting (cc pixelherodev), sec
<Nypsie>
DarkUranium: What if those 3 characters you input, invalidate the tokens behind it?
<DarkUranium>
^ supposedly, it handles incremental parsing for you.
<alexnask>
If the new tokens fall within an old definition/AST node
<DarkUranium>
Nypsie, then those tokens are deleted, and any related parse (sub)trees invalidated.
<alexnask>
Then it is invalidated and you reparse from the start of the old definition to the start of the next definition
<DarkUranium>
Nypsie, you stop when you hit a token with (pos == token.start_pos+num_inserted)
<DarkUranium>
Because if you reach the same exact position, and because lexers are context-free, you know the rest of the result will be 100% the same.
<Nypsie>
Aaaaah true
<DarkUranium>
Nypsie, basically: an insertion "invalidates" (so to speak) a range of tokens (and thus positions).
<Nypsie>
Alright, got it. Thanks both
<DarkUranium>
Any subtree that touches those tokens needs reparsing. But the reparsing can take advantage of tree that have *NOT* been invalidated, to skip the parse.
<DarkUranium>
(this is the core principle of packrat parsing ^)
<alexnask>
I guess there could be some edgecases. Consider: "const a = some_expr; some_fn_call();" -> "const a = some_expr + some_fn_call();"
<alexnask>
But im sure you can design an algorithm that takes care of this as well
<DarkUranium>
alexnask, I don't think that would break anything.
<DarkUranium>
You start parsing from the top.
<DarkUranium>
(or bottom, for LR)
<alexnask>
Right
<DarkUranium>
Basically, in order to facilitate this, you need to change this:
<DarkUranium>
parse_statement();
<DarkUranium>
into this:
<alexnask>
Yeah makes sense, yo ujust have to check that the reparse
<alexnask>
if the reparse*
<alexnask>
Goes into the next nodes from the previous parse
<DarkUranium>
(pseudocode, it's a bit more complex than that because of position shifts due to insertion/deletion, but yeah)
<alexnask>
I may actually experiment with reworking zig's parser to do this, it sounds fun :P
<DarkUranium>
I reckon bottom-up parsing would be even simpler (because you *start* at invalidated parts, and just merge proper ones at reduce steps), but same general idea.
<alexnask>
Cool, Ive seen this linked before but never looked into it
<DarkUranium>
Haven't really look into it either.
loooph has quit [Remote host closed the connection]
<DarkUranium>
alexnask, for semantic analysis, it's tricky. One option is to keep a set of "back-pointers", from AST into symbols, and from symbols into all other symbols, and update them when you reparse ... but that can get hairy, fast.
<alexnask>
Yeah keeping track of all the dependencies sounds like hell tbh
<DarkUranium>
alexnask, this might sound silly, but one option would be to keep a bloom filter that keeps track of which semantic nodes may be affected.
<DarkUranium>
(a bloom filter is a *hugely* storage-saving probabilistic datastructure that has false positives "may be in the set", but no false negatives "is not in the set")
<alexnask>
Hmm
<DarkUranium>
Another option could be to keep a list --- transitively --- of all affected semantic nodes, for each AST node. That's only *somewhat* tracking dependencies, in that I don't attempt to store semantic information other than "depends on".
<DarkUranium>
Note that, because I can mark nodes as being "outdated", it doesn't matter which direction the dependencies go in.
<DarkUranium>
Could be a pointer from the semantic node *TO* a list of AST nodes.
<DarkUranium>
(but that all sounds memory-expensive --- O(nm), really)
<alexnask>
Yeah, not sure about the tradeoffs here. Its an interesting problem for sure
<alexnask>
Are you aware of any compiler that does incremental semantic analysis? Would be interesting to look at their source code
<DarkUranium>
I know TypeScript and Roslyn (C#'s compiler) resolve it somehow.
<DarkUranium>
alexnask, ^ those two.
<DarkUranium>
The author who inspired me to do this is the one who implemented both.
<DarkUranium>
(in an interview)
<DarkUranium>
alexnask, incremental semantic analysis is actually not a problem --- you already do it, where you iterate over everything.
<DarkUranium>
The only difference is that here, you can start it at any node, instead of starting at root (so it changes some assumptions).
<DarkUranium>
Apparently, they do compilation by just doing foreach(everything) resolve();
<DarkUranium>
(+ codegen, obviously)
stripedpajamas has quit [Quit: sleeping...]
alexnask has quit [Quit: Leaving]
frmdstryr has joined #zig
marnix has quit [Read error: Connection reset by peer]
stripedpajamas has joined #zig
cole-h has joined #zig
<frmdstryr>
gdb seems to not be able to print optional fields in a struct, is there any way to make that work?
<frmdstryr>
Oh, nevermind.. using p *&path.to.the.field seems to work
<Nypsie>
No annoying gradle files needed either, nice
cole-h has quit [Quit: Goodbye]
<ikskuh>
Nypsie: when i say 100% zig, i mean that :D
<Nypsie>
Yeah this is wonderful! Great work
<ikskuh>
btw, the app is only 250k in size
<ikskuh>
with support for x86_64, arm and aarch64
<ikskuh>
it shrinks further when you remove support for one or two platforms
<ikskuh>
x86_32 has some linking errors :D
<andrewrk>
ikskuh, with some work the libc requirement can probably go away. what's the template stuff?
nikita` has joined #zig
<ikskuh>
sorry, i don't understand the second question completly
<ikskuh>
you need to link against C libraries and zig requires to link libc then
<ikskuh>
there's a PR that makes linking with android libc easier by using env vars, but afar from that i can't see a way to lift that requirement
<ikskuh>
as you are required to allocate some memory with "malloc" anyways
<andrewrk>
I haven't looked super closely but it appears android libc would be pretty straightforward for zig to provide (no SDK/NDK requirement)
<andrewrk>
I can't imagine it being that much different than musl
marnix has quit [Read error: Connection reset by peer]
<ikskuh>
that would be awesome
<leeward>
Is reading past the end of an array using an array pointer UB in Zig?
<ikskuh>
i think meme/keegan is working on that
<ikskuh>
leeward: i think that's UB on any platform/language :D
<leeward>
(also writing)
<leeward>
ikskuh: I know it is in C, but Zig is particular about its UB.
<leeward>
Specifically, I mean as distinct from safety-checked illegal behavior.
<andrewrk>
leeward, reading past the end of an array using an array pointer is safety checked illegal behavior, which means in safe build modes, it's well-defined to panic, and in unsafe build modes, it is UB
<leeward>
andrewrk: I think there's a bug then. I just printed arr_ptr[100] after assigning `const arr_ptr: [*]u8 = &array;` where `array` is [18]u8 in debug mode.
<ikskuh>
that can't be safety-checked
<andrewrk>
arr_ptr is an unknown-length pointer, not an array pointer
<ikskuh>
there is no knowledge of length in [*]
<leeward>
Ah, nomenclature.
<andrewrk>
an array pointer would be *[100]u8
<leeward>
I meant to say [*]T when I said array pointer.
<andrewrk>
gotcha
<leeward>
Ok, so that's undetectable UB.
<fengb>
multi pointer?
<andrewrk>
not necessarily. zig has a well-defined memory model
<andrewrk>
there's no concept of an end of a [*]T - depending on how you set up the memory, any index could possibly be valid
<andrewrk>
but it's certainly possible (and dangerously easy) to invoke unchecked UB with a [*]T
<andrewrk>
which is why we encourage use of []T instead
<leeward>
Right. I'm just trying to get an accurate handle on the intended state of things.
<andrewrk>
I get the impression that your intuition is accurate
<leeward>
Are there other instances in Zig where it's easy to invoke unchecked UB? (I'm guessing C pointers)
<andrewrk>
status quo, or even after all the plans are implemented?
<leeward>
The plan is more important than today's reality.
<leeward>
Though I am interested in the state of the language now too.
<leeward>
So...both?
<andrewrk>
pointers to function-local variables which outlive the function call are unchecked UB in status quo zig. however there's a plan to make that safety-checked
<andrewrk>
same situation with structs which require not being moved because e.g. they have pointers to their own fields
<andrewrk>
async function frames are examples of structs which require not being moved
<leeward>
It's going to detect structs with internal references?
<leeward>
That sounds fancy.
<andrewrk>
not quite - it will allow the programmer to annotate a struct as "pinned" which will make it a compile error if it would ever get moved
<leeward>
Ah, the pinned thing.
<andrewrk>
and then one would do this annotation if one wanted to make internal references
<andrewrk>
async function frames already need this annotation today
<andrewrk>
(it would be implied; I am not talking about modifying syntax for async stuff)
<leeward>
I remember reading that ticket. It was related to the implicit-copy thing.
<cren>
leeward: thanks, I was just about to ask if that was the one
<cren>
is there an accepted way to use third party libraries in zig yet? Do I just stick it in my working directory?
alexnask has joined #zig
<ikskuh>
just do what you want
<ikskuh>
i use git submodules
<ikskuh>
because it's easier to work with
<cren>
I've never used git submodules before, does it have significant advantages?
<ikskuh>
i can check in code in the package again and push that
<ikskuh>
and you can pull updates
<leeward>
It lets you tie revisions of your code to a revision of your dependency's code.
<cren>
Oh that definitely sounds like a good idea
<fengb>
If you don't know how to use it yet... maybe it's not a great solution :P
nvmd has joined #zig
<leeward>
^not a bad point
<pixelherodev>
Eh, I kinda consider that a disadvantage
<pixelherodev>
Tying versions, i mean
<cren>
oh?
<leeward>
Kinda true about most of git though
<fengb>
I still get super confused when using submodules
<pixelherodev>
Tying *major* versions makes sense to me, but tying the exact patch?
<fengb>
Like trying to switch from one remote to another
<cren>
leeward: it's worth learning how to push and pull and clone just so you can use other people's work and share your work on github & co.
<leeward>
That's...not a disadvantage.
<fengb>
It's just yet-another-workflow that doesn't make a whole lot of sense
<pixelherodev>
It means you don't get bug fixes
<pixelherodev>
And if the dep is making breaking changes without bumping major versions that's a problem too
<leeward>
pixelherodev: You absolutely do get bug fixes; you just have to know you're getting them.
<leeward>
"breaking changes" includes introducing regressions.
<leeward>
cren: Sure, it's worth learning. Git just goes the extra mile to make things harder than they need to be.
<alexnask>
Right, I dont see how this is different than just pulling in some specific version, youd still have to update it manually to get the bug fixes
<pixelherodev>
Git is much easier than you think
<leeward>
It really is not.
<alexnask>
by pulling in I mean copying it in
<pixelherodev>
The problem is that most people learn it by using it
<pixelherodev>
Which is a terrible way to learn
<fengb>
git submodules is a whole nother beast
<pixelherodev>
^
<pixelherodev>
for sure
<fengb>
None of its flows match regular git
<leeward>
The problem is that it's a bunch of scripts written by different authors with different sensibilities wrapped around a core.
<pixelherodev>
Most parts of git are pretty straightforward when you think about it from the perspective of git
<pixelherodev>
I'm not talking about the scripts
<pixelherodev>
Git itself
<leeward>
Scripts like git-fetch?
<leeward>
And git-checkout?
<leeward>
I think those are pretty core to Git's usage.
<pixelherodev>
For sure
<pixelherodev>
but if you understand how git *works* - wait dammit I said I would stop getting involved in pointless discussions
<pixelherodev>
I'm going to get back to finishing the how to backend guide now :P
<leeward>
Also, the author of git submodules doesn't know that "recurse" isn't a word, but that's just me being a grumpy English speaker.
<cren>
but since we're discussing English, if you can say it, it's a word. No-one makes the rules
<cren>
fengb: I tried to install gentoo once because I'd heard that you can install most of the packages as binaries rather than compiling
<leeward>
cren: wiktionary isn't exactly an authoritative source, and I'm going to stay grumpy and prescriptivist on this one.
<alexnask>
Nothing wrong with neologisms
<leeward>
alexnask: That's the opposite of what I'm saying. We will fight now.
<alexnask>
: D
<leeward>
Unfortunately, I need you to keep making zls better so...I guess I lose?
<cren>
re. gentoo: it's a lie. Sure, you *can* install binary packages. But the gentoo project doesn't *provide* any binary packages. So if you want a gentoo install you do in fact have to sit there for hours while everything compiles
<leeward>
fengb: What have you done?
<cren>
I gave up there. Anyway that was my experience
<fengb>
I was trolling phd. :(
<leeward>
cren: I had a friend in college who got an amd64 machine when they were brand new, so he tried putting gentoo on it. 2 days later, Firefox finished compiling.
<alexnask>
Wait, escalator was a brand name?
<leeward>
fengb: I know, and he managed to avoid the bait!
<leeward>
gruebite: What part are you asking about?
<gruebite>
is there a better way to do this (user provides custom function callbacks + type)
<gruebite>
a trait/interface would be ideal
<leeward>
For one thing, I'd skip making `update` optional, but as to the broader question, if you're looking for runtime dispatch you might want to take a look at https://github.com/alexnask/interface.zig
<alexnask>
wew, I didnt even have to link it myself
<alexnask>
(it also supports optional virtual fns btw :D)
<alexnask>
fieldParentPtr smh
<shakesoda>
sounds cryptic
<alexnask>
This is the stdlib way though
<gruebite>
i suppose i should have looked at the stdlib for examples
<alexnask>
I would argue interface.zig is better but I dont have any data to support it so ¯\_(ツ)_/¯
<leeward>
Better on what axes?
<gruebite>
@OpaqueType isn't documented
<leeward>
Isn't it?
<alexnask>
Its deprecated, @Type(.Opaque) is the new way
<gruebite>
ahhhh
<leeward>
Oh wow, I have to update some stuff.
<alexnask>
leeward, Well for startes it completely decouples the interface and implementation, the stdlib pattern requires you to embed the vtable in your implementation type
<leeward>
Yep, that sounds better.
<alexnask>
It also lets you specify a storage policy for the implementation object and I will add a storage policy for the vtable as well one of these days
<gruebite>
i'm assuming these solutions don't remove the need for zig to facilitate this in some standard way?
<alexnask>
(atm I always store a const pointer to the vtable, I will add inline vtable storage as well for small vtables)
<gruebite>
i recall reading an issue regarding traits
<leeward>
gruebite: It's been argued that they do.
<leeward>
Zig: We have that feature in userland.
<alexnask>
I personally prefer a userland solution (ideally in std), its actually more flexible that e.g. traits in Rust
<alexnask>
interface.zig with the NonOwning policy is pretty much equivalent to dyn traits
<gruebite>
yeah, i think i prefer interface.zig or something similar in stdlib
<leeward>
It's a tradeoff. The language is much (MUCH) simpler for not having traits, but there's extra friction associated with using a library.
<alexnask>
gruebite, I wrote it for stdlib but it didnt make it in yet
<leeward>
Same with hash maps.
<fengb>
I do wish we had function arg generic type checking
<alexnask>
Since its not decided if we will have a language feature, keep the current stdlib pattern or add a utility like it in stdlib
<leeward>
I think Zig's philosophy will tend to push it toward userland solutions to problems like this.
<leeward>
fengb: You mean something more specific than "type"?
<gruebite>
i like userland solutions, but common ones should be in the standard library
<THFKA4>
i could've sworn the ~zig way~ had something about clear control flow
<alexnask>
Yeah this is my feeling as well especially if the solution is really flexible
<THFKA4>
not sure, can't find it now. i remember the C++ operator overloading used as a counterexample
<THFKA4>
where you don't know what A+B will call, and with Zig you would
<leeward>
I think something like interfaces.zig will end up in the standard library eventually. As it stands, I find it confusing but I haven't tried to use it in earnest yet. And the @fieldParentPtr method is also confusing (which is why I wrote that thing)
<alexnask>
I will rework it a bit to take an options struct with reasonable defaults and a bit better async handling (it works atm but I dont use @frameSize for some reason)
<leeward>
THFKA4: Yep, that's definitely a thing. I'm not sure how it relates to interfaces though. "No hidden control flow" isn't violated by runtime dispatch.
<alexnask>
I guess it could be argued it hides the indirections but that would be true of a language feature as well
<gruebite>
@fieldParentPtr reminds me of embedded data structures in C
<THFKA4>
well, you don't know what Reader.read() will call until runtime, right
<gruebite>
like tree.h/queue.h
<THFKA4>
obviously a useful feature, but makes reading the code harder
<alexnask>
THFKA4, I agree but this is explicitly what its made for, it should be discouraged unless runtime dispatch is actually needed for sure though
<leeward>
That's one of the reasons why I don't think it will turn into a language feature.
<alexnask>
(I would argue it hides less than a language feature like C++ virtual methods or Rust dynamic traits does as well)
xackus_ has quit [Ping timeout: 264 seconds]
<THFKA4>
yeah makes sense, it's always a balance
<gruebite>
Rust is getting to the level of C++'s "what code will this statement execute?"
<alexnask>
Hopefully one day I can remove the ugly ass switch over argument count
<alexnask>
I just need @Type(.Fn) at this point I think