darithorn has quit [Remote host closed the connection]
Ichorio has quit [Ping timeout: 258 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
_whitelogger has joined #zig
reductum has joined #zig
reductum has quit [Quit: WeeChat 2.3]
reductum has joined #zig
companion_cube has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 240 seconds]
<companion_cube>
I'm watching the video on implementing an allocator, it's pretty cool (esp. @fieldOf)
<companion_cube>
I'm a bit surprised the `if` doesn't require {}, even after goto fail
<companion_cube>
(or `while`)
companion_cube has quit [Ping timeout: 246 seconds]
companion_cube has joined #zig
kristate_ has joined #zig
kristate has quit [Ping timeout: 250 seconds]
kristate has joined #zig
kristate_ has quit [Ping timeout: 264 seconds]
reductum has quit [Quit: WeeChat 2.3]
kristate_ has joined #zig
kristate has quit [Ping timeout: 264 seconds]
Ichorio has joined #zig
Zaab1t has joined #zig
<dec05eba>
@fieldOf is cool but im afraid it will cause the same issues reflection in java does where IDE's cant find references to variables because of that. Even intellij idea cant find references to variables when using reflection in java
<dec05eba>
but perhaps not, because unlike java, zig only allows compile time known string for fieldOf
<andrewrk>
dec05eba, I believe companion_cube means @fieldParentPtr
<andrewrk>
however your point is still relevant for @field
wootehfoot has joined #zig
scientes has joined #zig
Ichorio has quit [Ping timeout: 244 seconds]
darithorn has joined #zig
<companion_cube>
sorry, yes, fieldParentPtr
<companion_cube>
I got disconnected apparently, grr
<scientes>
@fieldParentPtr is awesome
<scientes>
it is impossible in go and rust
<companion_cube>
I tried to find docs on `interfaces` (like Allocator, apparently?) but it's "todo" ^^
tgschultz has joined #zig
<scientes>
companion_cube, documentation for the std lib is not written yet
<scientes>
only the language
<companion_cube>
I mean, the concept of interfaces, if there's one
<scientes>
its not the same as go interfaces
<tgschultz>
Also, interfaces might undergo a significant change in the near future (after coroutine rewrite). The current paradigm doesn't optimize well and causes headache related to errorsets.
<companion_cube>
hmm, ok
<tgschultz>
basically we'll be going from intrusive pointer to vtable+pointer.
<companion_cube>
is it this C-like idea that if a struct starts with another struct, you can have a form of polymorphism?
<companion_cube>
as in, disguising FooAllocator as Allocator if it's its first field?
<tgschultz>
kinda sorta. The compiler reserves the right to re-order non-extern, non-packed struct fields however it wants, so we don't rely on field ordering and use @fieldParentPtr instead.
<companion_cube>
makes sense.
<companion_cube>
that's pretty neat.
<scientes>
yet it is still fully compile-time
<companion_cube>
it's funny how it's the little things that I find weird in zig
<companion_cube>
(the return-from-block syntax, the lack of {} around if/while…)
<tgschultz>
but it was revealed through experimentation that the optimizer doesn't like that, so we're considering a change where the new interface would be a struct that contains a pointer to a vtable and a type-erased pointer to the implementation instance. In some ways, this is cleaner and it definitely optimizes better.
<companion_cube>
so, a far pointer?
<andrewrk>
the @fieldParentPtr trick will always be available; it's a valid thing to do semantically. but as tgschultz notes zig may offer a more idiomatic convention for this "interface" problem
<companion_cube>
I mean, @fieldParentPtr is useful for any intrustive structure anyway, isn't it?
<andrewrk>
companion_cube, most C-like languages do not require braces for if/while
<scientes>
companion_cube look how I used @fieldParentPtr in rb.zig
<andrewrk>
companion_cube, correct
<tgschultz>
A far pointer to me has to do with i286 segmented memory.
<companion_cube>
andrewrk: rust does, and it's an easy way to prevent goto fail bugs :s
<andrewrk>
are you talking about where you accidentally indent 2 lines expecting them both to be in the if?
<companion_cube>
yeah, it pops up easily when you modify code
<companion_cube>
what if you write them on one line?
<companion_cube>
if (foo) a; b;
<companion_cube>
hmm ok, but then zig becomes a whitespace sensitive language 🤔
<andrewrk>
companion_cube, in this case you would succeed in writing code that is difficult for humans to understand at first glance what it does
<andrewrk>
I would even propose that should be a compile error
<andrewrk>
certainly `zig fmt` would not leave tha line alone
<tgschultz>
maybe having zig fmt change it to be more readable is enough.
<andrewrk>
all languages are whitespace sensitive languages
<companion_cube>
right, right. without macros I suppose there's no need for long one-liners
<companion_cube>
hu, some languages don't care about indentation
<andrewrk>
this issue is to make it a compile error if the whitespace disagrees with the curly braces
<andrewrk>
I'm pretty confident that will only be a helpful error
<companion_cube>
sure, sure.
<andrewrk>
it also helps IDEs
<companion_cube>
I do like `if foo { bar }` instead of `if (foo) bar` though.
<companion_cube>
simpler and risk-free
<andrewrk>
which can then rely on whitespace as a heuristic if the user has typed only an open brace and not the closed one yet
<tgschultz>
I've grown used to `if a else b;`. But I generally only use it if I can fit it on one line.
Akuli has joined #zig
scientes has quit [Ping timeout: 246 seconds]
<andrewrk>
there's a lot of stuff I'm excited to work on but in order to be maximally productive I have to follow the dependency order
<andrewrk>
for example, IDE integration
<andrewrk>
hot code swapping
<andrewrk>
super fast debug build incremental compilation
<companion_cube>
are you going to write a language server?
<companion_cube>
yeah, you have to bootstrap your own productivity :D
<tgschultz>
I'm less ambitious than andrewrk, I'm just looking forward to chaining streams together in a way I can rely on to optimize well. And whatever will eventually get us a comptime allocator.
<andrewrk>
companion_cube, I'm actually thinking that zig self hosted compiler will have its own sort of "REPL" which supports refactoring, type-aware searches, and other stuff that IDEs would want. and then a Language Server Protocol would be essentially an API adapter into that same core functionality
<andrewrk>
tgschultz, those are important to me too and the kind of things I'm talking about as being "dependencies" of this fancier stuff
<andrewrk>
commander, in order to do super fast debug build incremental compilation, it does 90% of the work that a language server does
<andrewrk>
sorry commander I meant companion_cube
<companion_cube>
hum a good language server needs a parser with recovery, but that's more ambitious
<tgschultz>
That idea is neat. On POSIX systems you could go full Plan9 and wrap that with a FUSE driver to expose your program's data as a filesystem.
<companion_cube>
at least type checking/comptime recovery, since 95% of buffers will be invalid
<andrewrk>
tgschultz, that's really interesting
<andrewrk>
my goal will not to have that feature directly, but to make it entirely possible for a third party application to do that using the Zig compiler's API
<andrewrk>
companion_cube, I haven't tried to solve that problem, but it's on my mind. I think it can be solved in a satisfying way, and I'm potentially willing to make language changes if it's certain they would make IDE integration fundamentally better
<andrewrk>
if you allow me to use gamer jargon, I want the "skill cap" of Zig IDE integration to be through the roof
<companion_cube>
it's more about compiler changes than language changes, I think?
<andrewrk>
companion_cube, sure - I mean we're describing vaporware right now, so any discussion will have to be a bit handwave-y
<companion_cube>
of course
<companion_cube>
the gist of what I've seen in other languages is that you need a compiler that can deal with invalid programs graceful at every step (parsing, type checking, and here probably compile time computations); then make that available as a library
<andrewrk>
companion_cube, one thing to note at least - zig has line-independent tokenization
<companion_cube>
you mean you can parse lines again after a nonsensical line?
<companion_cube>
(like the one the user is editing)
<andrewrk>
e.g. zig does not have /* which can affect lines other than the one it is on
<tgschultz>
Actually, even on Windows it would be possible to write a FileSystem Provider wrapper for it. That'd be great for people like me who don't really like IDEs, we could still have a lot of the same functionality with tools we already have.
<andrewrk>
tgschultz, I'm also imagining you could use this compiler "repl" if you didn't want an IDE
<andrewrk>
since it's sitting there running with some stuff cached in memory to make your incremental builds faster, it may as well have a prompt that lets you query, do refactors, etc
<companion_cube>
tgschultz: by IDE do you mean things like visual studio, or any editor with a semantic plugin?
<tgschultz>
will I be able to script its behavior?
<andrewrk>
tgschultz, there will certainly be a fully capable API to the running compiler. Probably interactions via a socket
<tgschultz>
I mean things like VS mostly. I find them overengineered and rigid. I generally don't go for more than a text editor with syntax highlighting.
<companion_cube>
perhaps with a standard protocol, like, hmm, LSP? :D
<andrewrk>
the current idea is to support the standard Language Server Protocol, as well as Zig's own more powerful one
<companion_cube>
tgschultz: you should try LSP integration for $langOfChoice in a good editor
<companion_cube>
I use vim + semantic plugins, and it's incredibly useful (when the plugin is good)
<tgschultz>
well an advantage of wrapping an FS around that is you can use tools you already have without modification.
<companion_cube>
integration in an editor gives you a much tighter feedback loop
<companion_cube>
(eg you can tab-complete, ask for types, or docs, in <1s)
<companion_cube>
errors appear immediately when you save
<tgschultz>
One thing I like about zig is that I haven't missed any of that.
<companion_cube>
if you had it, you'd wonder how you could do without it, imho
<companion_cube>
at least it's the case for me
<companion_cube>
without that I'm literally twice (or thrice) less productive
<tgschultz>
I work in VS at work, and did a lot of Java with IntelliJ in the past, I know what it feels like to have it.
<companion_cube>
you need to experience it with a good language :D
<companion_cube>
(ok, maybe it's a question of personality, too. I like the computer to help me a lot.)
<tgschultz>
Yeah, I think so. I'm generally against the computer trying to help me too much because it's really bad at it once it crosses a certain complexity threshold.
<companion_cube>
in my experience, as long as it's just completion and typing, it can do a stellar job
<companion_cube>
(and immediate error feedback, which is the easiest to do)
<andrewrk>
tgschultz, how about renaming stuff?
<andrewrk>
that's something I miss
MajorLag has joined #zig
<MajorLag>
it's annoying that even though my registration is tied to my nicknames a temporary disconnect still leaves me unable to reuse my previous one because its "already in use"
tgschultz has quit [Ping timeout: 268 seconds]
MajorLag is now known as tgschultz
<andrewrk>
there's a feature for that. something to do with "ghost"
<tgschultz>
thanks, I'll look into that. Charter has been so unreliable that this has come up a lot.
<strmpnk>
I haven’t seen an LSP implementation do what I’d really want: show me the definition of the structures and functions I’m using in a side panel by context. I find the autocomplete pop ups slow me down (awaiting the prompt) and distracts.
<strmpnk>
I’ll use autocomplete to start learning a library that is poorly documented but I find I can really remember it well till I turn completion off.
<strmpnk>
Things also being tied to `.` for completion severely limits the kinds of things that can be discovered.
<companion_cube>
depends on the language, but yeah
<companion_cube>
something very useful is to show the type or docs of the highlighted expression
<andrewrk>
strmpnk, on the other hand, zig does encourage the `a.b` pattern (rather than importing symbols directly into the current namespace)
<strmpnk>
I occasionally use that when I am writing Rust but for some reason editors thing hovering a mouse pointer or forcing you to the browser is great UX for reading. Going back and forth then becomes a chore since there is no permanent fixture.
<strmpnk>
andrewrk: Yes. It's a good design, but not always enough for some languages.
<andrewrk>
I do like the idea of a dedicated space for IDE assistance
<companion_cube>
ah, in vim it's just a temporary extension of the : line, and it disappears instantly on escape
<companion_cube>
so low overhead
<strmpnk>
companion_cube: Same problem though. If I'm filling out fields in a struct, I'd like to see it for each entry. Making it pop in and out is not great.
<strmpnk>
Anyway... it's a little off topic as it'd probably be editor specific not something Zig has a hand in.
<andrewrk>
I think it's fairly unanimous that zig should at least provide an API for IDEs to use
<strmpnk>
But it's interesting that the LSP uses so far seem very much on the lineage of "intellisense" style assistance and sometimes "refactoring".
<tgschultz>
yeah, I'm not against an API at all. It's a good idea.
<andrewrk>
I think the pace of Zig is going feel like it's accelerating once a few major language things are finished.
<andrewrk>
Once we have recursion solved, copy elision, coroutines, agnostic blocking or event-based code, networking in the std lib, package management, and the oop/interfaces question is resolved, all the sudden there's not really anything left but polish and bug fixes
<andrewrk>
I know that's a lot of stuff, but it's *finite*. the language can get done, and then stay done
<strmpnk>
The Roslyn rewrite of C#'s compiler and TypeScript being written in a similar style by the same team shows how it impacted IDE support using the compiler's infrastructure. The question is if the whole toolchain needs to be built this way or if the needs are different enough to avoid it.
<andrewrk>
one thing I'm doing strmpnk is the self hosted compiler is being developed with a "breadth-first" approach with respect to all the planned stuff. so even when it can only compile hello world, I'm going to make sure documentation generation is working, language server, incremental builds, all that stuff
<strmpnk>
Very reasonable priorities given the already working compiler can pick things up anyway.
<kristate_>
glad that a lot of discussion is happening!
kristate_ is now known as kristate
scientes has joined #zig
develonepi3 has joined #zig
Ichorio has joined #zig
Ichorio has quit [Read error: Connection reset by peer]
Ichorio has joined #zig
fsateler has quit [Read error: Connection reset by peer]
fsateler has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
scientes has quit [Ping timeout: 246 seconds]
kristate has quit [Remote host closed the connection]
xentec has quit [Quit: memento mori]
xentec has joined #zig
xentec has quit [Client Quit]
xentec has joined #zig
xentec has quit [Ping timeout: 245 seconds]
xentec has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
Zaab1t has quit [Quit: bye bye friends]
Akuli has quit [Quit: Leaving]
<emekankurumeh[m]>
@and
<emekankurumeh[m]>
andrewrk: if you store a heap-allocated object in a struct can you get a pointer to that struct using `@fieldParentPtr`?
<andrewrk>
nope - think about it, how would that work?
<emekankurumeh[m]>
so if i allocate the struct and a slice in it, it wouldn't work?
<wrl>
you would need a pointer to the pointer you're holding in the struct
<andrewrk>
(or just a pointer to the struct)
<wrl>
yes and in that case you already have a pointer to the struct and you don't need to do anything further
<andrewrk>
emekankurumeh[m], it might help to draw out the memory on paper with arrows
<wrl>
et voila!
<andrewrk>
@fieldParentPtr has a very clear pattern when you see it visually like that
<wrl>
andrewrk: is @fieldParentPtr similar to C container_of()?
<andrewrk>
wrl, yes. if I had known about container_of I would have called it that. maybe will even rename it
<andrewrk>
@fieldParentPtr is slightly more type safe
darithorn has quit [Remote host closed the connection]
<andrewrk>
emekankurumeh[m], that's invoking undefined behavior, and zig would catch it and crash if it were smarter
<andrewrk>
here's what's happening: passing a slice as a parameter currently secretly passes a pointer. but just like passing any struct as a parameter like that, you're not supposed to rely on it being byvalue or byref
<andrewrk>
so the reason it works is that you got lucky and zig chose byref for the slice (but actually there's an open issue to pass slices destructured)
wootehfoot has joined #zig
Ichorio has quit [Ping timeout: 245 seconds]
<emekankurumeh[m]>
on windows i think zig fmt is trying to format the zig executable.