ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<GitHub39>
zig/master 3a8dc4e Andrew Kelley: zig fmt: line comments in struct initializer
<andrewrk>
I just got all the behavior tests passing with new ptr deref syntax
<andrewrk>
I used zig fmt to automatically update all the source from old ptr deref syntax to new ptr deref syntax
alexnask_ has joined #zig
alexnask has quit [Ping timeout: 240 seconds]
SimonNa has quit [Remote host closed the connection]
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
davr0s has joined #zig
Ichorio has joined #zig
noonien has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexnask_ is now known as alexnask
<alexnask>
Andrew, is the syntax for pointer reform finalized?
<alexnask>
I know syntax is the last thing we should worry about but I find so many sigils to be a bit onfusing
<alexnask>
Perhaps confusing is not the right word actually, the pattern makes sense but I'm sure many people will struggle to get it and use [*] everywhere :p
<alexnask>
Also, what do you think about having an additional @namespaceInfo() builtin that produces a []TypeInfo.Definition?
davr0s has joined #zig
<alexnask>
I think @typeInfo is finally done
<alexnask>
let's see if appveyor and Travis CI agree :p
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Dodo has joined #zig
Dodo has quit [Client Quit]
davr0s has joined #zig
<GitHub66>
[zig] Hejsil opened pull request #970: Fixed extern enums having the wrong size (master...extern-enum-size-fix) https://git.io/vp0ht
steveno_ has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<GitHub22>
[zig] Hejsil closed pull request #970: Fixed extern enums having the wrong size (master...extern-enum-size-fix) https://git.io/vp0ht
<GitHub111>
[zig] Hejsil reopened pull request #970: Fixed extern enums having the wrong size (master...extern-enum-size-fix) https://git.io/vp0ht
<alexnask>
Am I doing something a bit too magical? :p
<andrewrk>
intToPtr does not work at comptime
<alexnask>
The function body is not meant to work at compiletime
<andrewrk>
oh right
<alexnask>
I just want to generate the function at comptime
davr0s has joined #zig
<andrewrk>
one guess about what's going on:
<andrewrk>
when I originally programmed the way that scopes work, I didn't think it was possible to put a function inside a function
steve_____ has quit [Ping timeout: 260 seconds]
<andrewrk>
so we have bugs such as: compiler crash because inner function codegen tries to run outer function's defers
<andrewrk>
it's possible that the inner functions think they're in the comptime scope from the outer function
<alexnask>
Ok, I'll take a look at this specific case and try to fix it
<andrewrk>
of course this is all going to be fixed, but right now, functions inside functinos is still an open issue
<alexnask>
I think it's the only error left, the rest of the implementation seems to work well
<alexnask>
Which is pretty good
<andrewrk>
people are doing metaprogramming in zig way before I thought its metaprogramming features were ready
<alexnask>
Well, @typeInfo and @field is pretty good already ;)
<andrewrk>
:)
<alexnask>
I mean, abstracting away all of that Interface stuff is something that I think would only be possible in C++ and Dlang (at least the way I did it)
<alexnask>
So zig metaprogramming is not that shabby at all :P
<andrewrk>
argh, it seems that std.atomic.queue is sometimes failing on CI. I've been running the failed test in a loop in gdb for 3 hours and I can't reproduce it
<andrewrk>
maybe it's time to work on a race detector
<alexnask>
I noticed it appveyor and travis both took a long time to complete that test on my PR
<alexnask>
Though they didn't fail for me
<andrewrk>
I wonder if it's just getting killed by CI because it's a little resource intensive
<andrewrk>
I like that explanation because that means my code isn't broken
<alexnask>
haha
<andrewrk>
it wants to make 6 kernel threads and then watch them thrash and probably travis/appveyor have only 2 each
<andrewrk>
anyone in here have experience with lock-free programming and want to check std.atomic.queue and std.atomic.stack?
bodie_ has joined #zig
<bodie_>
hi
<andrewrk>
hi bodie_
<alexnask>
yo
<bodie_>
watching the tetris vid. wouldn't printf evaluate to an error if it fails, and the return type %void would be satisfied?
qazo has quit [Ping timeout: 240 seconds]
<bodie_>
(but the compiler says the error is ignored)
<andrewrk>
I think that video is over a year old and things have changed a lot since then
<andrewrk>
that is in fact how it works now if you use std.io.getStdOut()
<bodie_>
cool
<bodie_>
do you guys have a preferred social hub, like a discord? I'm thinking of picking it up a bit and will have questions
<bodie_>
or is that IRC
<andrewrk>
this channel is the best place for questions, feedback, and discussion of zig
<bodie_>
(nice language btw)
<bodie_>
okay, cool.
<andrewrk>
so far it's been very pleasant. I'm really happy with how nice everybody has been to each other
<andrewrk>
and I'm hoping we can keep it that way as it grows
<bodie_>
you'd better restrict it to Canadians only then ;)
<bodie_>
j/p
<andrewrk>
bodie_, what are you thinking about working on using zig?
<bodie_>
Honestly I just stumbled back upon it because I was reading a little about higher-kinded types and noticed that I liked the "comptime" syntax a lot. it resembles something I was attempting (without much success) with Go
<bodie_>
I'm thinking of using it for a game / small engine
<andrewrk>
neat, that's a good use case
<bodie_>
I have some other requirements for some backend applications I will probably prefer Rust or Go for
<andrewrk>
if your game is open source drop a link and I'll follow along
<bodie_>
right on :)
<bodie_>
it's nothing yet and I haven't allocated it any priority, but hopefully I will be able to pretty soon
<andrewrk>
you're going to run into immaturity problems in zig that you wouldn't run into with go or rust, but if you're ready for that, then I think you're gonna have a great time
<bodie_>
I _really_ dig how usable it is with gdb
<bodie_>
is that a similar story on windows?
<andrewrk>
I've been using msvc to debug on windows
<bodie_>
I didn't notice whether Zig has first-class functions or closures. It seems like those would be a little tricky to manage memory for, especially generically
<bodie_>
That still seems to be a problem for rust
<andrewrk>
it gets the call stack correct, but I noticed a lot of variables are missing. This is the same problem as clang + linking with LLD, so if that community improves debugging then we get the benefits too
<bodie_>
YOU get a Box and YOU get a Box and YOU get a Box!
<bodie_>
Kind of, Rust enums are pretty similar but don't have the ability to do proper types as their members. They're all tuples I think
<bodie_>
I'm sure you could apply comptime to enum in zig, right?
<bodie_>
the closures issue is pretty nice
<bodie_>
are there any projects I could look at for a good intro to zig at the current iteration?
<bodie_>
( andrewrk )
<bodie_>
oh another thing I've had issues with in Rust is building on Windows wanting to compile packages that only have Linux build scripts
<bodie_>
for shared lib imports
<alexnask>
@andrewrk Btw, I managed to work around that issue with a small helper function
<alexnask>
So the interface lib works now! Not bad :)
<alexnask>
@bodie_ Enums work in comptime yes
<alexnask>
@bodie_ The only things that don't work are inline asm (-> syscalls), pointer casting and some other low level stuff
<alexnask>
(in comptime)
<bodie_>
nice. I assume it chains right? like you could have a whole tree of comptime types evaluating
<alexnask>
Yes, no issues there
<bodie_>
could you also use comptime'd enums to support heterogeneous lists that way?
<alexnask>
Types are just expressions at comptime
<alexnask>
@bodie_ Tuples are a planned feature (replacing varargs)
<bodie_>
instead of say, vec T... trying to think through how this would look
<alexnask>
Well, you could make a union (rust enum/ADT) of the types you need and require a slice of that type
<alexnask>
In theory, you could use comptime varargs and check the types yourself but they are broken atm (and probably will be removed from the language)
<bodie_>
hm
<alexnask>
As for examples, I'm not sure what exactly you are looking for, I have some cool (but pretty confusing) metaprogramming code if you want to check that out :P
<bodie_>
that would be fun. I'm looking for cross-platform opengl game stuff
<bodie_>
maybe concurrency
<alexnask>
You should be able to call into OpenGL really easily using @cImport()
<alexnask>
I have some code that does that but it's windows-only (with a nice OpenGL loader based on metaprogramming too)
<bodie_>
last question, should I go with the emacs or the vim package?
<alexnask>
That code is pretty confusing but it showcases some metaprogramming with the new @typeInfo builtin
<bodie_>
nice, ok
<bodie_>
sorry *VS Code
<bodie_>
not vim
<bodie_>
also, has anyone played with wasm?
<bodie_>
it _appears_ that the vsc package has the most features, but I am a habitual emacs user...
<alexnask>
Well, my goal was to automatically load GL functions from a struct like: http://prntscr.com/jcflh2
<alexnask>
I'm using sublime text, so I couldn't tell you ;)
<bodie_>
that's just syntax highlighting, right?
<alexnask>
Pretty much
<alexnask>
For OpenGl, you should just be able to @cImport(@cInclude("gl/gl.h")) and get all GL types + functions
alexnask_ has joined #zig
<alexnask_>
My ISP sucks -_-
<bodie_>
wow, @typeinfo looks nice
<alexnask_>
It's pretty nice ^^
<bodie_>
this metaprogramming gist looks a bit like an implementation of runtime generics. is that right?
<alexnask_>
It's not available on master yet though
<alexnask_>
Yes
<bodie_>
like Go's interfaces or Rust's trait objects
<alexnask_>
Right on
<alexnask_>
With a choice of storage policy (just sbo_storage for now)
<alexnask_>
+ optional functions
<bodie_>
so are you guys planning to add such a type to zig?
<bodie_>
or maybe just as a library
<bodie_>
I find runtime dynamic types pretty annoying but I recognize that they are necessary. I think it's a sore spot from having no other choice in Go for the last few years
<alexnask_>
That's my implementation
alexnask has quit [Ping timeout: 256 seconds]
<alexnask_>
The idiomatic way to do it is much different
<bodie_>
oh?
<bodie_>
what's that, c-style?
<alexnask_>
People usually make a vtable type that they insert as a field in their implementation types
alexnask_ is now known as alexnask
<bodie_>
This is like .... C-style evil OOP interfaces
<alexnask_>
Basically they insert the vtable into the implementation as a field and use the field pointer to get back to the implementation struct's pointer
<alexnask_>
Well, C-style evil OOP interfaces is how everyone implements them under the hood ;)
<bodie_>
lol
<alexnask_>
At least in my version the implementation is separate from the interface type ;)
<alexnask_>
(it doesn't need to know about the interface at all)
<alexnask_>
So I guess that makes me a bit less of a monster :P
alexnask has quit [Ping timeout: 256 seconds]
alexnask_ is now known as alexnask
<bodie_>
so MyInterface.init constructs a new interface wrapper w/ the vtable from FooReader
<bodie_>
right?
<alexnask>
Yes
<alexnask>
It basically generates the vtable at comptime
<alexnask>
Gets a pointer to it (in static binary memory) and stores it
<bodie_>
ahhh, init is a comptime function
<alexnask>
Then the storage policy takes care of holding the object
<alexnask>
This takes a pointer to a comptime evaluated function which returns a vtable
<alexnask>
That forces the compiler to store the vtable in static memory
<bodie_>
how did you come up with that idea?
<alexnask>
I saw that technique used in C++ in some CPPCon talk
<alexnask>
Not very original :P
<bodie_>
works for me
<alexnask>
And I kinda assumed the compiler was going to do the right thing with that expression
<bodie_>
doesn't C++ have virtual classes though? lol
<bodie_>
or was that implementation-side
<alexnask>
Yes, C++ has virtual methods
<alexnask>
But the presenter basically made his own version
<bodie_>
featuring "duck-typing"
<alexnask>
To decouple the interface/implementation types + get whatever storage policy you need
<bodie_>
I'm not following the bit about storage policy and allocation
<alexnask>
Well, the storage policy simply takes care of providing us the pointer to the implementation object
<alexnask>
You could, for example, have a non-owning storage policy which just takes the pointer and stores that
<alexnask>
The SBO storage policy copies the data into a buffer (if it fits) or allocates on the heap and copies the data there
<alexnask>
Another example would be an inplace-only storage policy (a single buffer, where the implementation _must_ fit to be constructed)
<bodie_>
in other words, Box
<bodie_>
er, Box would be the first example
<alexnask>
Box is always a heap allocation, isn't it?
<alexnask>
But yes, kinda like box
<bodie_>
so the sbo_storage object owns its own allocated memory for the boxed value and manages its lifecycle
<alexnask>
Right
<alexnask>
My plan is to add a nonowning_storage and an inplace_storage
<alexnask>
Then the user can define theirs if they need to
alexnask_ has joined #zig
<bodie_>
is the purpose of this to make mockable APIs?
<bodie_>
I'm not necessarily following
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<bodie_>
it seems like a lot of legwork in a direction that is kinda the opposite of what Zig looks like it's for
<bodie_>
just curious, not trying to attack
<alexnask_>
Well, it is just an extra configuration point
<alexnask_>
Right, no problem ;)
<alexnask_>
If you need a non-owning interface
<alexnask_>
And you know the object will always be alive while the interface object is alive
<alexnask_>
Then you can do that
<alexnask_>
If you want to store the interface objects and gurantee that your implementation objects fit into it, you can do that
<alexnask_>
If you just want to heap allocate the implementation object and keep a pointer to it, you can do that too
<bodie_>
Zig++ :P
<alexnask_>
I'm not too keen on interface types either, tbh, it just seemed like an interesting application for metaprogramming since we don't have traits
<bodie_>
well it's definitely cool
alexnask has quit [Ping timeout: 260 seconds]
<bodie_>
I'm just evaluating it as an outsider who's trying to understand how people think about design in zig
<bodie_>
um, on that note, what about type constraints? comptime T where T has methods ...
<alexnask_>
Well, make it clear and simple is the general idea
<alexnask_>
@bodie_ You can use @typeInfo or other metaprogramming builtins to check for those
<bodie_>
gotcha, but it's still call-time
<bodie_>
in the sense of C++ templates
<alexnask_>
Yes
<bodie_>
I guess you could do "types for types" somehow with a comptime fn....
<bodie_>
hold on while my mind unravels
<bodie_>
ok, better now
<alexnask_>
I'm not too sure I understand what you mean :P
alexnask_ is now known as alexnask
<bodie_>
like compile-time generics in Rust (I've been thinking about Rust a lot recently sadly)
<bodie_>
I guess I was thinking, have a struct that defines the methods you want on your interface, and then have a comptime method that checks your "implementing type" for those methods, but eventually you're going to barf somewhere down in the comptime elaboration of the fn for the implementing type
<alexnask>
Can you link me to an example? Not too familiar with rust beside the basics
<bodie_>
like if Duck has Quack and you call Quack inside your comptime fn, you'll fail if you pass Dog
<bodie_>
but not until you hit Quack
<bodie_>
but if you had a macro that checks to make sure T implements Quack, before trying to elaborate the CallQuack fn, then you would fail _there_
<bodie_>
CallQuack(IsDuck(Dog)) or whatever
<bodie_>
IsDuck would also have to return its passed type argument in the success case
<bodie_>
alexnask, basically traits are just compile-time interface types that you use in your template
<MajorLag>
alexnask, does @typeIno know about a type's namespaced fns? If so that's basically already done.
<bodie_>
I'm just thinking you still have to manually check the comptime type's methods when you elaborate, so why not just let it fail deep inside the graph
<bodie_>
unless you have a type verification macro
<bodie_>
just an idea
<bodie_>
I'll stop rambling ^_^
<MajorLag>
well that's what I was thinking would do it: have a fn that iterates over a type's namespaced fns and compares them to a desired set of fns.
<MajorLag>
you can do that with members currently, but not namespaced stuff. So yeah, your only option would be to call it later and let the compiler complain.
<MajorLag>
but that doesn't help if you want to change behavior based on the passed in type
<bodie_>
MajorLag, what do you mean by namespaced fns? Like methods in another language?
<bodie_>
Oh, I see. "Methods" could be functions defined only in the scope of the enclosing struct, or they could be actual fields of the struct
<bodie_>
"namespaced fns" must be the former
<MajorLag>
yeah, that's what I mean. They're normal every-day functions, but they exist in the namespace of a struct/union/enum, and have the one special property of using `instance.func()` syntax to pass the struct instance as the first argument.
<bodie_>
that's just like Go method sugar
<alexnask>
@MajorLag @typeInfo knows about all definitions within the scope of the type
<alexnask>
Ah, I thought traits were runtime polymorphism, I didn't realize the where thingy was a compile time thing
<andrewrk>
bodie_, there's an emacs mode
cenomla has joined #zig
<andrewrk>
bodie_, my opinion on metaprogramming is that it's good to be skeptical about it. there are times when it's the best solution, but it can be tempting to abuse it
<alexnask>
@MajorLag I'm already using that to generate vtables from arbitrary types (looking into the namespaced funcs etc.)
<andrewrk>
for example, a programming language on top of assembly is metaprogramming, but it's something we've come to agree upon certain standards and there is a lot of tooling that goes around it
<andrewrk>
on the other hand, "shallow metaprogramming" - where you use it just for 1 use case, I think can be easily abused
<andrewrk>
often a little bit of verbosity or even redundancy can be ultimately better for maintenance
<andrewrk>
that said, if metaprogramming can prevent footguns in practice, it's a pretty good justification
steveno_ has quit [Quit: Leaving]
cenomla has quit [Remote host closed the connection]
<bodie_>
alexnask, weirdly, traits are both
<bodie_>
they are adding a "dyn T" syntax to distinguish. it's very confusing at first
<alexnask>
Hmm, TIL
<alexnask>
When you use them as a function argument, do they always work as runtime polymorphism?
<alexnask>
And using them in where clauses forces compile-time checking?
<bodie_>
it's syntax dependent, I'm still not quite clear on it, and the pain of rust types is making me not want to gitgud at it
<alexnask>
Or does the compiler decide which functions are going to use them as vtables and which are just going to be specialized?
<alexnask>
Haha, fair enough :)
<bodie_>
I think it depends on the type signature
<bodie_>
of the declaration
<alexnask>
Are you @binary132 on github btw?
<bodie_>
yes
<alexnask>
Ok, good to know, I answered your comment on the namespaced functions, let me know if you need any clarifications
<bodie_>
excellent example!
<bodie_>
are you using Zig for games?
<alexnask>
I'm planning on writing a 4kb intro with it
<alexnask>
So kinda :P
<bodie_>
nice
<bodie_>
anyone using it with libjit?
<alexnask>
Not as far as I'm aware
<bodie_>
lua bindings?
<bodie_>
I guess you can just use anything from the C world
<alexnask>
Then again, since you don't really need to write bindings on C libraries, someone may as well be using it
<alexnask>
Hand-writen bindings are only required if you want a more idiomatic zig layer over the C calls
<alexnask>
Or for particularly involved translations (think windows header bindings, even there the changes you need to get up and going are minimal)
<andrewrk>
arguably we wouldn't even need bindings if C let you annotate more type information - such as non nullable pointers
<alexnask>
Do we parse GCC style __attribute__?
<andrewrk>
yes
<andrewrk>
we support the nonnull attribute on parameters, so one option is improving .h files to include this attribute
jjido has joined #zig
<andrewrk>
the attribute is for parameters only - it cannot describe types generally
<bodie_>
in particular, having a good consistent build system that is compatible with windows is really important.
<bodie_>
being able to grab C deps, etc
<bodie_>
or even using zig to build a whole C / C++ project
<andrewrk>
bodie_, there is some proof of concept of the build system, but it's not ready to build C/C++ projects cross platform yet
<andrewrk>
the planned work in that link is all still planned
<bodie_>
cool :)
<bodie_>
andrewrk, one last query. do you use GTD or some other planning system?
<bodie_>
I'm working on something for myself to use but it's a bit of a chicken-and-egg problem. I have been using org-mode with pomodoro with varying success
<andrewrk>
I mostly just try to organize my life so that I can squeeze in zig work in between my full time job and maintaining my (happy!) relationship with my girlfriend
<andrewrk>
someday soon though I hope to work on zig full time and get funded via donations
<bodie_>
haha, my third kid was due yesterday, so managing time is always a critical challenge.
<bodie_>
yeah. it would be neat if you could get sponsored by a company that would see its utility
<andrewrk>
btw to other contributors - you are welcome to have your own donation links - I'll even put them on ziglang.org
<andrewrk>
I think company sponsorship will happen eventually
<andrewrk>
at some point zig will be just too good to ignore :)
<bodie_>
If I start making good use of it I'll be sure to pitch in :)
<andrewrk>
I'll never sell to a company though. zig will always be free and open source software that is motivated by the open source community
davr0s has joined #zig
<andrewrk>
that will always be a weakness and a strength - weakness because we don't have $$$ and strength because our motivations are pure
<andrewrk>
bodie_, in more direct answer to your planning question - for zig issues we have milestones. every issue is assigned a milestone (except ones that are brand new)
<andrewrk>
the milestone is priority
<andrewrk>
however, at least up until 1.0.0, zig is coordinating releases with LLVM. So when LLVM 7.0.0 is released, 1 week later zig will release 0.3.0
<bodie_>
I was asking more personally since I really respected the level of detail and organization of your overall structure
<andrewrk>
ah. thanks for the compliment
<bodie_>
I happen to be interested in personal project management / optimization techniques
<bodie_>
not great at it myself
<andrewrk>
for me I've vowed to only use zig for my own open source projects from now on
<andrewrk>
and I have a lot of open source stuff I want to build... so I better get zig to a reasonable level of maturity!
<bodie_>
cool, do you feel it has good support for web-facing applications at this point?