<hryx>
damn, that's a lot of permissions. such a tragic thing about OAuth apps. I really wish apps could ask for permissions as needed/desired, per integration feature
darithorn has quit [Quit: Leaving]
<NI33_>
andrewrk: If i am not mistaken, when you want to integrate to accounts (and continue to use a non-paid membership) you need to do something very old fashioned, namely send an e-mail and ask them to integrate your accounts (i could be mistaken, but i do think i ran into the same issue a while ago, and just gave up, seeing that)
<NI33_>
*to=two
<NI33_>
If the gitlab service was just a little older, i am sure you would have had to send them a letter via PO-BOX 372834 :-)
<NI33_>
(Note: It might have been some other REPO/CI service that had this, and i am mistaking it for gitlab)
<NI33_>
Please discard my message above. Did a little digging and it was SemaphoreCI requiring me to e-mail them. Sorry about that.
reductum has quit [Quit: WeeChat 2.5]
<mikdusan>
daurnimator: awesome. you got that arm account!
<bheads>
you want the compiler to reject the call site
<scientes>
if (@typeOf( @compileError()....
<bheads>
not the function
<scientes>
its still comptime
<bheads>
call site
<scientes>
then use another function
<scientes>
with differn't requirements
<bheads>
then we dont need inheritance
<scientes>
i don't see the problem
<bheads>
I was responding to the new inheritance proposal
<scientes>
yeah , i'd rather not have inheritance
<bheads>
exactly
<scientes>
@fieldParentPtr is sufficient
<scientes>
once it is fixed
<fengb>
That’s more “traits” than inheritance
<bheads>
@fieldParentPtr is messy
<scientes>
it just has to be fixed
<scientes>
its still beautiful
<fengb>
Yeah I don’t really want inheritance either
<scientes>
OO is best used sparingly
<bheads>
the idea was to make "traits" cleaner
<bheads>
with the trait in the signature not in the body
<mq32>
mikdusan, i hope i get some time later to write a response to your proposal. i have some more specific ideas and commets
st4ll1 has quit [Ping timeout: 268 seconds]
<bheads>
easier to debug that: quack(a_dog); is the error then if ( std.meta.hasFn(duck, some long fn signature)) ...... in duck.quack ...
st4ll1 has joined #zig
<mikdusan>
mq32: would love to hear them
<daurnimator>
bheads: hrm. I can't find it now, but theres a comment around that proposes you can provide a function as a type and it would get called to check if it was valid
<bheads>
I think that pattern would cleanup things like the Allocator and Iterator patterns
<bheads>
even cleaner would be to define the trait as a type
<bheads>
const Allocator: type = var<std.mem.is_allocator>;
<emekankurumeh[m]>
mostly it just makes things nicer as the binary front the downloads page assumes the c ABI as msvc even on gnu
<dimenus>
mingw64 does use the msvc abi
<emekankurumeh[m]>
i suppose we could just add runtime detection for the c ABI
<dimenus>
it's meant to interop without any extra dlls
<dimenus>
unlike cygwin
<emekankurumeh[m]>
by c ABI I mean the libc (basically)
<dimenus>
ah
<dimenus>
yeah in that case they have their own wrappers for certain things
<emekankurumeh[m]>
as that's how zig refers to it in the triple
<andrewrk>
emekankurumeh[m], perhaps we can improve native ABI detection. are there are environment variables or something that mingw-w64 provides?
<dimenus>
i'm making good progress with Vulkan
<dimenus>
other than the occasional hand edits of the translated c, it's been pretty easy to use with Zig
<dimenus>
environment variables or #defines?
<andrewrk>
dimenus, we're talking about an executable at runtime detecting that the native ABI should be mingw
<emekankurumeh[m]>
sure, I think we already do something like that by checking if certain pipe handles exist
jjido has joined #zig
<emekankurumeh[m]>
but also using lld with mingw-w64 is faster that msvc and cl
<dimenus>
i haven't experienced that except on a first build
<emekankurumeh[m]>
I'd rather not make the windows ci job any longer
<dimenus>
cl has incremental linking
<dimenus>
er link does
<dimenus>
i'm not sure I understand why you guys keep referring to this as 'ABI' though other than the target triple being kind of misleading
<dimenus>
the calling conventions of mingw compiled applications are the same as that of native MSVC compiled applications
<emekankurumeh[m]>
really? maybe we should take advantage of pipeline caching
<dimenus>
on msys2/cygin that's a different story
<dimenus>
those programs literally won't load / link with the msvc toolchain
<dimenus>
*cygwin
<emekankurumeh[m]>
in the target triple when targeting mingw the ABI we pass is gnu, there is no difference but llvm pretends there is so we do too
<andrewrk>
dimenus, yes they have ABI compatibility but there are still differences in the target
<emekankurumeh[m]>
msys2 isn't cygwin
<dimenus>
i didn't say they were
<andrewrk>
the linker acts quite differently for the mingw abi vs msvc
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dimenus>
msys-2.0.dll and cygwin.dll both provide a posix translation layer
<dimenus>
agreed
<andrewrk>
we might even want to have std.fs.path.sep be `/` rather than `\` for windows-gnu target
<emekankurumeh[m]>
yes please
<andrewrk>
let's do it
<dimenus>
i don't think that's right
<dimenus>
msys-2.0 is not linked into mingw64 programs
<dimenus>
only msys programs
<emekankurumeh[m]>
though all of zig works with / instead of \ except for zig fmt
<emekankurumeh[m]>
oh, that explains what you mean
<dimenus>
i'm just trying to make sure we're differentiating between msys2/cygwin (which do provide posix translation)
<dimenus>
and mingw64
<dimenus>
which is a regular windows binary
<dimenus>
if you don't link in libc on mingw64, i'd be curious to see if the path actually gets translated
<dimenus>
my guess is that it will not
<emekankurumeh[m]>
translated?
<emekankurumeh[m]>
I can't wait for @result, the result variable was something i really liked in nim
<emekankurumeh[m]>
i'll make a pr for this stuff
<scientes>
emekankurumeh[m], but why, just have a differn't variable, and then return it?
<emekankurumeh[m]>
copy elision, plus i don't like just declaring the variable just to return it, @result feels a lot cleaner imo
batok has joined #zig
<scientes>
I think copy elision can just be done with static analysis
<scientes>
and I'd rather avoid an extra feature in the language
<gokr>
Hi all, I am new to Zig since... 24h, but find it interesting. Was wondering, anyone here with experience in Nim that can ... contrast Zig with Nim? I have done a fair bit of Nim.
<andrewrk>
zig has fewer features than nim, compiles directly to machine code (not C), and emphasizes cross compilation
<gokr>
Those parts I already got ;)
<halosghost>
zig also emphasizes safety and predictability
<gokr>
Although there is also an experimental LLVM backend for Nim, though... not primary work there AFAIK
kristoff_it has joined #zig
batok has quit []
<gonz_>
Hang on, what's this about `@result`?
<halosghost>
nim, in large part because it compiles to C, still has quite a bit of undefined behavior
<andrewrk>
dimenus, I see your point. Yes I think we would only want `/` instead of `\` if it was msys2/cygwin
<andrewrk>
halosghost, I'm not sure that's correct, be careful accusing another language of that
<dimenus>
agreed
<andrewrk>
it's pretty easy to avoid the undefined behavior of C when using it as the output of a compiler
<gokr>
I made Spry (sprylang.se) in Nim and also used it together with Urho3D in my old job etc. It's a beast, but... strangely practical also. Regarding the "undefined behavior" - I have heard that being brought forward lots f times, especially from Rusters - but... it feels largely theoretical.
<halosghost>
andrewrk: it has been a while since I've looked into nim, but the last time I did, it had made some decisions such as defaulting all integers to signed integers and not providing unsigned integers; and, at least at the time, it didn't do anything to catch/prevent overflow
<andrewrk>
halosghost, that's a fair criticism, but that's unrelated to C having undefined behavior - see what I mean?
<halosghost>
mm
batok has joined #zig
<gonz_>
gokr: zig emphasizes compile-time evaluation of normal code in contrast to Nim and many other languages.
<gokr>
"in contrast to nim"?
<halosghost>
I suppose, though I think claiming that it isn't related to C's UB is actually more of an assertion about the language authors than I had made
<halosghost>
andrewrk: I suppose I was trying to offer the benefit of the doubt to the nim authors that they just had to bite that UB because C has it; suggesting that they should do otherwise is an assertion that they made a poor choice
<halosghost>
which is not necessarily incorrect
<gokr>
Compile time evaluation is exactly what Nim also can do.
<gonz_>
gokr: Correct me if I'm wrong, but does Nim not emphasize macros as opposed to just compile time evaluation?
kristoff_it has quit [Ping timeout: 272 seconds]
<halosghost>
but, it was my hope by my phrasing explicitly to not indict them
<halosghost>
it seems like I failed in that, so my apologies
<gokr>
andrewrk: I actually watched that (although speed flipping)
<andrewrk>
halosghost, I think a fair way to put it would be that you disagree with the design decisions about integers
<halosghost>
andrewrk: fair enough
<halosghost>
oh, I can say this
<halosghost>
afaik, nim doesn't have arbitrarily-sized, fixed-width integers and zig does
<halosghost>
which, I think, should award 2^252 (one for each extra integer type that zig supports) points to zig :P
<gokr>
gonz_: Eh.... Nim has a macro system that operates on the AST level, and it does so by using Nim. In fact, Andreas even wrote a Nim interpreter mainly to be used during compilation.
<gonz_>
gokr: Note that AST manipulation is different than what zig does. zig does not try to give you a macro system.
<halosghost>
(seriously, it's one of my favorite things about zig; which I know is a little silly)
<gokr>
gonz_: I know Zig doesn't do AST manipulation, but.... Nim also runs Nim during compile time.
<andrewrk>
that's neat, I didn't know nim had that
<gonz_>
Having used many macro systems I can tell you zig is a different idea than all of them.
<gonz_>
I suggest you make use of it.
<gokr>
For example you can write a const proc that produces a CRC table, and have it run at compile time. It may even be more advanced than Zig in this arena- though I am not sure about Zig's limitations.
<gonz_>
Yes, it *is* more advanced, that's part of the point.
<batok>
Is there a source code example about a tcp server or client?
<gonz_>
zig is a much smaller idea with much more bang for your buck than any macro system.
<andrewrk>
does nim let you do any of these during compile time code execution? inline assembly, external function calls, syscalls
<andrewrk>
batok, yes but that's a bit under construction for the moment. I suggest using C libraries for that (or libc) or waiting a couple months
<gokr>
andrewrk: Unsure about the limitations, the const stuff is meant to be deterministic - so there such stuff is "forbidden" of course.
<andrewrk>
batok, I'm working on async/await right now, and next up after that is event-based networking API in the std lib
<batok>
ok i will wait tks
<gokr>
andrewrk: But nimscript is also based on the same interpreter - and it can do quite a lot of such stuff (since it's used to make "portable shell scripts" etc)
<andrewrk>
gokr, sounds like nim & zig made the same decision then and the features should be roughly equivalent
<gonz_>
gokr: I don't think soliciting responses about differences and mounting defenses about the responses is going to net you more than sitting down and writing some zig. It's a very small, simple language and you can pick it up very fast.
<gokr>
I am a Smalltalker at heart so... I am used to "blurring" runtime and compile time ;)
<gonz_>
Having written production code in Racket and Elixir I can tell you that there is a qualitative difference between the kind of compile-time features you get in zig and macro systems.
<gokr>
gonz_: I am not mounting defenses - I am trying to find the ... major differences.
<gonz_>
You're not going to theorize your way to this, I don't think
<gokr>
Probably not, I know. Was just hoping to find some people knowing both.
<batok>
can nim compile to wasm these days?
jjido has joined #zig
<gokr>
gonz_: So you think Zig goes further towards Lisp/Smalltalk etc?
<andrewrk>
gonz_, I think your suggestions are reasonable, but let's try to have a welcoming attitude to the newcomers :)
<gonz_>
batok: If it compiles to C it can
<gokr>
andrewrk: I am cool, no problem. I may sound as one of those coming to "argue" - but... I am a sucker for languages simply.
<andrewrk>
I agree with gonz_ though that the best way to find out is to try it out
<strmpnk>
I'd call zig more of a staged compilation setup for metaprogramming, which is really different from macro based metaprogramming. Staging isn't as common as AST based metaprogramming but has a lot of advantages with uniformity of language when moving concepts between the two layers...
<gonz_>
gokr: zig is much more limited in what it exposes as an interface for compile-time stuff. The compile-time stuff you write is exactly what you would have for non-compile-time. Pound for pound it's very valuable but as with everything in zig it's intentionally simple.
<strmpnk>
It's a lot easier to lift into or out of comptime than switch an AST manipulation into straight-line code.
<gonz_>
strmpnk: Right? Precisely because it's just zig code and the only thing you really need to consider are the stage requirements.
<strmpnk>
Yes. Constraints like comptime are very expressive IF given good reflection, which Zig has done a good job with.
<gokr>
Yeah, sounds reasonable. Loved the way generics works in Zig btw.
<gokr>
As a Smalltalker I love it when things are reified :)
<gonz_>
Exactly, and that's part of what makes it such a pound for pound good feature
<gokr>
Spry is about .. 2.5k Nim code, I was thinking of porting over to Dart (I work a lot in Dart these days) - but... Zig is tempting.
<andrewrk>
zig is still immature, lots of bugs, beta software, but if you're cool with that then it would be a great fit
andersfr has joined #zig
<gokr>
I do however rely quite a bit on runtime polymorphism (Nim methods) - is the answer in Zig country.... tagged unions?
<gonz_>
gokr: Do you work at a big dart shop? This sounds interesting.
<gokr>
No, I work at a company making... robot gloves ;)
<gokr>
Anyway, I decided to go "all Dart" there for both server side and mobile apps etc.
<gokr>
Has worked really well so far.
<andrewrk>
gokr, tagged unions work well (even untagged unions have runtime safety with a secret tag field) but if you want runtime polymorphism, the current solution is to roll your own using @fieldParentPtr. the relevant issue to track is https://github.com/ziglang/zig/issues/130
<gonz_>
`@fieldParentPtr` is a bit controversial, though, it should be said?
<gokr>
Spry is... just a trivial little AST interpreter - but a fun little experiment. I also noted you mentioned doing "stackless" parsing somewhere - in fact exactly what I wanted to do in Spry next (it's currently just a silly recursive interpreter).
<andrewrk>
fengb, looks like the install step is not doing mkdir -p and that's causing the error
<andrewrk>
fengb, an issue would be appreciated
<andrewrk>
gonz_, I'd say @fieldParentPtr as *the solution to runtime polymorphism* is controversial
<gonz_>
Right, yes
<fengb>
Ah if it’s the install step, I think I can take care of that
<andrewrk>
but that's why #130 is still open
kristoff_it has joined #zig
<andrewrk>
fengb, yeah. I think what's confusing about that error return trace is that one of those errors was handled, but then ultimately the call still errored out
<gonz_>
gokr: Did pure function annotations land in Nim yet?
<andersfr>
andrewrk: I made a context-free LALR parser of Zig. I had my doubts at first but it was indeed possible
<andrewrk>
but that actually gives you more information if you think about it
<gonz_>
gokr: Ah, found it in the manual.
<andrewrk>
andersfr, interesting! I would be interested in engaging with you more on this once the syntax is stabilized - as it is more changes are planned (specifically with regards to async/await and a couple other things)
<gokr>
andrewrk: Not sure if it is of interest - but async/await in Nim was made purely with macros actually.
kristoff_it has quit [Ping timeout: 258 seconds]
<andrewrk>
gokr, that's neat. is it based on stackless coroutines / CPS?
<andrewrk>
does it work with a thread-pool based event loop?
<gokr>
Extremely good question - have no idea :)
<gokr>
But it was dom96 who wrote it IIRC
<gokr>
He is on IRC
<gonz_>
What's this about `@result`, by the way? Is there an issue to look at? GitHub search taunts me as usual.
<gokr>
He also wrote the Nim book and lots of the web stuff in Nim etc. Very nice guy
<dimenus>
i just want to delete a file if it exists
<fengb>
async/await only denotes runtime semantics. It could theoretically be backed by any execution strategy, of which thread pool is one (and event loop would be another)
<scientes>
halosghost, nrdmn it would help if someone wrote up a proposal
<scientes>
I have the code somewhere and it works
<dimenus>
andrewrk: sorry for the false alarm, there's just a big in my zig code
<dimenus>
*bug
<dimenus>
i was trying to copy the *.spv files before the systemCommand actually ran
<fengb>
Sahnvour: I suppose it can be modelled as an infinite loop against 1 thread. I'm not sure how OSs or node.js does it internally
ofelas has joined #zig
<dimenus>
essentially i'm just trying to copy shaders/*foo.spv to my bin directory
<dimenus>
but the system command hasn't run yet
<andrewrk>
dimenus, ah yes one thing to remember is that build.zig is declarative
<andrewrk>
it'll become more clear why that is in the future
<dimenus>
sorry i'm being obtuse, i don't know what you mean by that
<dimenus>
i can just move the copy to later in the process
<andrewrk>
once your build() function completes, nothing is actually done yet. build() only creates a graph of build steps
<andrewrk>
that's why, for example, `zig build --help` contains the options and user-defined steps
<Tetralux>
(The build fn is basically just the system asking you what you want - and then after it returns it then goes and actually does it all.)
<dimenus>
ok, so i have a very similar setup to your vulkan example
<dimenus>
accept I'm also copying the shaders to the output bin directory
<dimenus>
*except
<andrewrk>
dimenus, for your compiled shaders I recommend using the install functions, and then finding them at runtime based on the installation path, or relative to the binary path
<andrewrk>
or `@embedFile` at build time
<dimenus>
i am using installBinFile, the problem is the compiled shader isn't built yet
<dimenus>
or do i just need an extra step?
<andrewrk>
you probably just need to declare a step dependency
<andrewrk>
I should update the vulkan example to do this
<dimenus>
that was it
<dimenus>
just need to have the install step depend on the compilation step (rather than the exe compilation)
<dimenus>
can the install step depend on both?
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dimenus>
nvm, i'm good to go. thanks andrewrk/Tetralux
<Tetralux>
dimenus: o7
<andrewrk>
dimenus, at some point here the API will be improved so that zig build does caching on system commands if you go through the trouble to specify all the inputs and outputs
<andrewrk>
this will also make it easier to make the API friendlier with regards to step dependencies
wootehfoot has joined #zig
huffmanr has joined #zig
marijnfs has quit [Ping timeout: 252 seconds]
marijnfs has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<dimenus>
on to an obj loader!
<andrewrk>
neat
jjido has joined #zig
halosghost has quit [Quit: WeeChat 2.5]
huffmanr has quit [Remote host closed the connection]
st4ll1 has quit [Ping timeout: 248 seconds]
st4ll1 has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
marijnfs has quit [Ping timeout: 246 seconds]
Ichorio has quit [Ping timeout: 264 seconds]
jjido has joined #zig
jjido has quit [Client Quit]
<scientes>
dimenus, are you writing a dynamic loader?
<andrewrk>
scientes, I believe obj in this context is a mesh (for 3d graphics)
<scientes>
oh cool
<scientes>
dimenus, if you need some specific SIMD thing let me know
man213 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<dimenus>
yes, that is correct (mesh loader)
<dimenus>
i have a working 3d scene w/ depth buffer in vulkan
<dimenus>
and now i need meshes
<scientes>
oh, yeah yulkan does its own SIMD/shader compilation
<scientes>
although it actually uses llvm to do it........
<dimenus>
amd wrote another shader compiler
<dimenus>
i haven't tinkered with it yet though
<dimenus>
scientes: I have a local branch with shawnl's vector specific enhancements
<dimenus>
it's worked out well so far
<scientes>
dimenus, type /whois scietes
<dimenus>
ah :D
<dimenus>
scientes: i don't have a link to the specific thread in the llvm mailing list, but they were looking at removing the experimental tag from hadd/hmul
<dimenus>
hadd would be nice for matrix operations
<nrdmn>
what's the correct way to write a C void pointer? *c_void, [*c]c_void or something else?
<scientes>
dimenus, no problem with adding it, but we need a syntax
<nrdmn>
fengb: c_void is a void. I want a void pointer.
<fengb>
Yeah, I just mean you shouldn’t need to type [*c]
<nrdmn>
[]c_void is a slice of c_voids, I think (?)
<andrewrk>
nrdmn, if you can, try to make an @OpaqueType() specifically for the underlying type. if you need a globally opaque type, consider using the pointer address (usize)
<fengb>
In zig we distinguish singular pointer, c_void is a pointer to an item, and array pointer, []c_void is a pointer to an array of items
<fengb>
Slice is not ABI compatible with C
<nrdmn>
fengb: according to the documentation c_void is a void, not a *void
<fengb>
I think my asterisks are disappearing in this app
<fengb>
Ugh..
<fengb>
Sorry those lines were supposed to have asterisks
<nrdmn>
:D alright
<fengb>
*c_void is a pointer to an item, and array pointer, [*]c_void is a pointer to an array of items
<fengb>
Okay I have extra text now... but hopefully that’s parseable
<fengb>
Both translate into *void in C but they carry a little bit of semantic meaning in Zig