<hryx>
Oh, maybe it means "or no token". I would have guessed something more like (A / B / C)? instead but this would make sense too
<dembones>
hryx: I agree. my initial thought was no token; but then I stopped reading the bison manual to watch the last minute of VA/Auburn. LOL
<hryx>
ha!
<dembones>
so, hryx, any thoughts on generics? I think anytime I try to declare a pointer to a function returning a type, it complains about the type not being known at comptime; but I've been stuffing `comptime` between practically every token to see if it satisfies the compiler, but it just won't.
<hryx>
Hm, I'm not sure dembones
<dembones>
the non-inline for call is maybe the problem. I might try an inline for instead
<hryx>
I've had issues with both fn pointers and comptime in the past, but I'm sure there have been many changes since I tried working with either
<hryx>
oh, that's worth a shot
<dembones>
I'm a n00b to zig... started working with it last weekend
<hryx>
well you already seem more versed in it than I was in my first week
<hryx>
also andrew is extremely helpful on IRC, but I think he's pretty busy this weekend
<dembones>
you are not kidding about Andrew
<dembones>
I posted a bug, and he jumped on it in minutes. Really extraordinary
<hryx>
:>
<hryx>
unrleated, I'm working on #1729
<hryx>
sometimes it's extremely relaxing to do repetetive code refactoring tasks...
<hryx>
like washing dishes
<dembones>
lol... that looks like a heavy lift
<hryx>
the sink is full
<dembones>
my bug was a puny little issue in @divFloor, which Andrew fixed in a day or two
kristate has joined #zig
<hryx>
dembones: your date project looks like a great one to start with BTW
<hryx>
have you looked at Go's time.Time?
<dembones>
oh yes
<hryx>
awesome
<hryx>
I'm sure that would be useful for stdlib in zig
<hryx>
Should the grammar define an EnumLiteral rule?
<hryx>
ok, the skeleton of a recursive std/zig/parse.zig is about 650 lines with grammar comments
<hryx>
and aside from those comments, well under 100 columns
<hryx>
I estimate it'll be around the same size as the stage1 parser, but we'll see
<hryx>
feeling good about the readability of this so far!
neceve has quit [Read error: Connection reset by peer]
<shritesh>
andrewrk, cool but I'll pass on C and stick with Zig ;)
_whitelogger has joined #zig
diltsman has quit [Ping timeout: 256 seconds]
_whitelogger has joined #zig
kristate has quit [Remote host closed the connection]
_whitelogger has joined #zig
dembones has quit [Quit: Lost terminal]
_whitelogger has joined #zig
_whitelogger has joined #zig
shritesh has quit []
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
mikdusan has left #zig [#zig]
mikdusan has joined #zig
jjido has joined #zig
<wilsonk>
scientes: you still around?
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined #zig
Zaab1t has joined #zig
jjido_ has joined #zig
Ichorio has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 250 seconds]
<daurnimator>
hryx: go's time.Time has a problem.... they never clarified if it was wallclock or absolute... so now it's both. and hence takes twice the syscalls and twice the memory to use...
<daurnimator>
it would be an example of one of the worser time apis around IMO.
<hryx>
daurnimator: I agree the fact that they shoved monotonic time into the same struct is kind of awkward, and has bitten me a little in the past, mainly in tests. But in general I've found the type to be fairly painless and robust
<hryx>
(disclosure, speaking as someone with limited experience with time APIs)
<daurnimator>
you really need 4 types: wallclock time (with timezone), monotonic time, and duration of each.
<daurnimator>
note that duration of monotonic time can be measured in a single number. duration of wall clock time usually need to be stored as seconds/mins/hours/days/weeks/months/years
jjido_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<hryx>
Interesting, I hadn't thought about the two types of time using different duration types. But that makes sense
jjido has joined #zig
<daurnimator>
I have lots to say around time types. but I think it can+should mostly wait until coroutines
<daurnimator>
reasoning: for timeout-ing operations (usually network operations) you want to configure them with a monotonic duration, but pass it to the actual function as a deadline
<daurnimator>
usually for a statically typed lanugage I would say that you'd overload functions to have no-timeout, timeout and deadline taking forms
<daurnimator>
but zig doesn't do overloading....
<daurnimator>
so optional monotonic duration (i.e. a timeout argument) is probably the best solution
<wilsonk>
scientes: oh yeah, no problems. It is 4:50am here now, but I usually program late :)
<wilsonk>
scientes: I noticed you asked someone if the had the EPYC machine to build with...just mentioning that it is actually me that has that machine. Did you need anything? Or was it just a comment in passing?
<scientes>
it was just a comment in passing
<scientes>
I ended up with a vps running on one of them, but it turns out it still doesn't have the super hot new AVX512VBMI instructions i wanted to play with
<wilsonk>
Ah, I see
<scientes>
the only exist in a cpu that was released a week ago
<telemach>
hello, does anyone know how to #include <OpenGL/gl.h> in Zig on macOS? adding OpenGL framework in build.zig doesn't help (and probably shouldn't as it's about linking i guess)
<telemach>
though test.c with just #include <OpenGL/gl.h> and main function is compiled by cc w/o any extra args
<telemach>
Zig fails with note: 'OpenGL/gl.h' file not found
<telemach>
it uses glfw, but i can't use it as i'm writing lv2/vst plugin
<telemach>
glfw is not designed for having multiple instances
<wilsonk>
Looks like it uses glfw at least...ah, I was just commenting on that...hmm
_whitelogger has joined #zig
<Sahnvour>
telemach, I don't use macOS, but I assume you tried equivalent c/c++ code and it works ?
neceve has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
Zaab1t has quit [Ping timeout: 245 seconds]
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gamester has joined #zig
<gamester>
telemach: What have you done in build.zig? What's the error? Are you on master? In master, system directories are not looked into by default. In build.zig you could do exe.linkSystemLibrary("some-lib") and it'll then also look into system directories so long as you call linkSystemLibrary on more than just the c library: https://github.com/ziglang/zig/blob/master/std/build.zig#L1164
<gamester>
but you can also manually do "exe.addLibPath" and "exe.addIncludeDir"
<gamester>
I'm sure this will all be better explained once 0.4 is released
<gamester>
Lots of changes are being made :)
wootehfoot has joined #zig
Zaab1t has joined #zig
jjido has joined #zig
<scientes>
I wanted to use the type to imply which saturating instruction to use
<scientes>
but I can't resolve the type in ir.cpp, only analyze.cpp
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<scientes>
got it
<wrl>
telemach: i'm using a GL loader for macos
<wrl>
i don't include the system GL header at all
<wrl>
tbqh i'm using a GL loader for all platforms but who's counting
<hryx>
The NodeTypeStructField in stage1 seems to support this expression part (though parsing still fails), but stage2 seems to be lacking the expr part altogether
<hryx>
am I right in thinking that this was supported at some point but removed? I don't see any examples in the documentation of it either
<hryx>
An example of what I assume would be legal if this syntax were supported: `const T = struct { a: bool = false, };`
<scientes>
you can always put a default in your function
<scientes>
or have an init() function if it is an object
<scientes>
oh wow accepted
<scientes>
oh i c
<telemach>
Sahnvour: yes, equivalent include in c file works fine without any extra include/lib dirs provided
<telemach>
gamester: I'm on master and in build.zig I have standard setup for a dynamic library plus lib.linkFramework("OpenGL")
<andrewrk>
telemach, what directory is OpenGL/gl.h found in on your system?
<telemach>
I found gl.h in ` /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Headers`, but somehow clang understands this directory when just OpenGL prefix is given
<telemach>
i failed to find OpenGL/gl.h combo on my system
<andrewrk>
so the full path is `/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gl.h`?
jjido has joined #zig
<telemach>
wrl: nice to see you here! thanks for suggestion about loader. i build straight on top of lv2, and for vst2 i use x42/lv2vst
<telemach>
andrewrk: yes
<andrewrk>
I think we need to teach zig build how to find headers of macos frameworks
<andrewrk>
hmm actually I think the logic would go in `fn make` of LibExeObjStep, and it would look at self.frameworks, and then add some additional -isystem args to zig
<scientes>
I don't think implicit widen_or_shorten is a good idea for vector types
<andrewrk>
telemach, do you have a source build? willing to try something?
<Sahnvour>
are macos frameworks shipped with the OS, or some kind of packages that can be installed ?
Ichorio has quit [Ping timeout: 268 seconds]
<andrewrk>
telemach, I don't understand how clang understands OpenGL/gl.h given that the path does not exist. I'll have to learn why that works before I can make it work in zig
<andrewrk>
as a workaround you can manually add `-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Headers` and then `#include <gl.h>`
<andrewrk>
hmm no that workaround won't work either, gl.h itself expects OpenGL/foo to work
<torque>
I expect there may be some special-case handling that concatenates the framework name with the header name when you pass -framework to clang
<andrewrk>
hmm. I just tried adding `-framework OpenGL` and still getting file not found
<hryx>
oh shoot telemach I ran into this problem recently and was able to solve it. let me see if I can go find what I did
<andrewrk>
mikdusan, I can't even get that to work with a fresh build of clang from source
<andrewrk>
it seems the compiler shipped with xcode has a patch
<telemach>
andrewrk: i don't have a source build of zig atm, but i can do it, what's your idea to try?
<andrewrk>
telemach, never mind - I've reproduced the problem and I'm working on it
<telemach>
thanks!
<hryx>
telemach: did you install Xcode? Kind of dumb, but what I remember is that you actually have to install all of Xcode (not just the CLI tools) and run it once to it finishes setting up
<andrewrk>
it's turning out to be hairy, I'll probably open an issue for it and get back to writing release notes
<telemach>
yes, i have xcode installed
<hryx>
this is something that changed in the last major release or two if I recall
<telemach>
and even started it recently
<andrewrk>
hryx, the weird thing is the system compiler (clang) supports `#include <OpenGL/gl.h>` but a fresh build of clang-8 from source does not
<andrewrk>
it seems apple has a patch on top of clang
<telemach>
andrewrk: yes, definitely focus on release, my case is not super-urgent
<andrewrk>
mine has the same framework search paths, regardless of -F and -framework args
<mikdusan>
do you have a gl.h from ROOT or only in deep SDK directory?
<andrewrk>
mikdusan, ok, I have found a difference
<andrewrk>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/ does not exist for me
<mikdusan>
see above :)
<andrewrk>
but it does exist elsewhere
<andrewrk>
so you think installing xcode would resolve this?
<mikdusan>
yes. but this brings up an interesting issue.
<hryx>
andrewrk: that was part of the solution for me -- see the long path I posted above for where it went after that
<hryx>
there is a GH issue for an unrelated project that had this problem, I'll see if I can find it
<andrewrk>
why does it work for the system c compiler without xcode installed then?
<mikdusan>
SDK selection for building on macos is quite common. a mechanism might need to be documented for that because i’m sure it will come up.
<andrewrk>
thanks for the help on this btw mikdusan
<mikdusan>
andrewrk: your suspicion i think is correct in that a /usr/bin/clang or /usr/bin/cc. but apple plays tricks with tools installed /usr/bin by adding launch binaries that set env variables.
<mikdusan>
env variables, the kind that point to SDK
Sahnvour has quit [Read error: Connection reset by peer]
<telemach>
mikdusan: but /System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/ exist on my machine and i still have the issue
<mikdusan>
telemach: have you tried the -F option?
<telemach>
not yet, give me a second
<telemach>
oh wait i don't have vanilla clang
<telemach>
how can i pass -F via zig?
<mikdusan>
i think that is what andrewrk was working on for you and then he ran into these pecularities
<andrewrk>
I tried all manner of -F and it had no effect. I think -F is a red herring
<andrewrk>
but you can pass additional c compiler args by putting them in between `--c-source` and the .c argument, or in the [][]const u8 arg of builder.addCSource
<telemach>
and when I di @cInclude in ui.zig it fails to find header
<andrewrk>
ah, right. translate-c doesn't provide a way to inject additional args
<andrewrk>
I'll just add a -F argument to zig so that it can be used as a workaround
<andrewrk>
macos keeps moving their shit around
<andrewrk>
every 6 months it's like "bet you can't guess where we put stdlib.h!"
<andrewrk>
thanks hryx
<hryx>
their M.O.
<hryx>
fo sho andrewrk
<hryx>
I feel your pain. A significant portion of my job is working around (and discovering) Apple inconsistencies. I have stories that would make your toes curl
<shritesh>
Is there a way to detect if a non-pointer value was passed to a `var` function parameter? std.os.spawnThread could use a better comptime error than "unable to evaluate constant expression" for invalid context.
<scientes>
shritesh, @typeOf() and @typeInfo()
<andrewrk>
shritesh, are you aware of @typeInfo?
<shritesh>
I missed that. I'll look into it. Thanks.
<andrewrk>
shritesh, btw I don't think spawnThread requires Context to be a pointer
<andrewrk>
also it builds with -target x86_64-windows
<emekankurumeh[m]>
wouldn't run be a function pointer though?
<andrewrk>
what do you mean
<shritesh>
Looks like passing a comptime_int was breaking things
<shritesh>
Is that a bug?
<andrewrk>
hmm we should be able to make it work fine with comptime_int
<shritesh>
Also, I copy-pasted the incorrect line above. The assertion on `comptime assert(@ArgType(@typeOf(startFn), 0) == Context);` is causing the problem.
<andrewrk>
ah yes. that could probably be more helpful
<shritesh>
Sorry :)
<andrewrk>
I mean, I'm agreeing with you with what you said earlier
<wrl>
telemach: hah, great idea using lv2 as your base plugin format :)
<telemach>
it's really nice, i like it much better than vst
<telemach>
it feels thought-out
<telemach>
but in both cases i bang my head against the wall trying to add gui
<telemach>
because of all those problem outlined many times in rust-vst chat
<telemach>
what exactly happens when I use --c-source? will this file only compiled, or linked as well?
<telemach>
omg warning: 'NSOpenGLView' is deprecated: first deprecated in macOS 10.14
<mikdusan>
telemach; —c-source comes after the zig “command”. so `build-lib` or `build-exe` or `build-obj` are all distinct. build-obj will produce a .o; others will cause a lib to link or an exe to link, respectively
<telemach>
mikdusan: ty
<telemach>
hryx: I knew about pushing, but Metal is not x-platform, why to deprecate opengl when people want to write portable stuff
<hryx>
beats me!
<wrl>
telemach: they don't want people writing portable stuff
<wrl>
best interpretation i can come up with
<wrl>
otherwise they'd back vulkan
<wrl>
my plan is to eventually move to vulkan and use MoltenVK on mac
<wrl>
but i'm waiting a few more years until hardware support stabilises/grows, unless apple forces my hand by removing GL
<scientes>
yeah the future is vulcan, not metal
<scientes>
and Apple doesn't have the momentum that Windows had when they launched DirectX
<scientes>
before vulkan it is true opengl is legacy, some developers wanted to support directX11 after the other modernization project of opengl was scrapped
<wrl>
yeah opengl's not great or nothing – vulkan just needs a few years more imo to have a critical mass for hardware
<wrl>
i think if you're writing games it's already there, but telemach and i are doing audio software that just uses the GPU for the UI, and so the hardware skews a bit older
<hryx>
nice to see some fellow audio people here :D
<telemach>
yes, and I in particular don't need event OpenGL's low-level, not talking about Vulkan, I'm resorting to OpenGL because most of frameworks are not friendly to plug-in type embedding
<telemach>
s/event/even/
<wrl>
yea
<scientes>
what do you mean?
<wrl>
i do enjoy offloading rendering to the GPU – I make heavy use of shaders, both vertex and fragment
<scientes>
"not friendly to plug-in type embedding"
<wrl>
just agreeing with you about the plug-in type embedding
<wrl>
there's like 4 or 5 publicly available libs/frameworks
<hryx>
telemach & wrl, are you working together on a project?
<wrl>
hryx: nope, i'm independent
<telemach>
no, just similar projects
<hryx>
neat
<telemach>
hmmm, similar in sense they are audio plug-ins
<telemach>
not more i guess
<wrl>
currently working all in C because I started a few years before the advent of the new-school c/c++-killer langs like zig and rust
<wrl>
but always keeping tabs on what's current in the field :)