ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<daurnimator>
emekoi: ah no. only the latest release
errpr has joined #zig
Ichorio has quit [Ping timeout: 246 seconds]
<knebulae>
andrewrk: now that opaque types seem to be stabilized (according to the docs), any intention to revisit typedef like behavior (https://github.com/ziglang/zig/issues/95)? It would be much cleaner than using single-member packed structs.
<andrewrk>
knebulae, why packed structs?
<knebulae>
passing to/from C
<andrewrk>
you probably want extern for that, not packed
<andrewrk>
the current plan is to not have typedefs. you are welcome to make a proposal to re-introduce them
<knebulae>
andrewrk: typedef is cleaner. Consider pub typedef SegmentSelector: u16; vs pub const SegmentSelector = packed struct { data: u16, }; Plus all of the extra typing to use the single member value.
<andrewrk>
how about pub const SegmentSelector = u16; ?
<knebulae>
andrewrk: That works too. I think typedef has too much baggage imho.
<andrewrk>
that works now
<knebulae>
andrewrk: oh. I was not clear that I could do that.
<knebulae>
I keep forgetting that types truly are first class citizens.
<andrewrk>
:)
<andrewrk>
almost first class. you can't use them at runtime
<daurnimator>
is it possible to add methods to an opaque type?
<daurnimator>
I guess the answer is 'wrap' it?
<daurnimator>
So.... if I want to create a shared zig library, how should I be exporting the definitions?
geocar has left #zig [#zig]
<knebulae>
daurnimator: I may be wrong here, as I'm still learning, but I believe --output-h coupled with --build-lib, with the functions properly marked as "export".
<daurnimator>
knebulae: that would indeed generate a .h file... but is that the preferred form?
<daurnimator>
I thought there might be some sort of 'stripped .zig file' form....
<daurnimator>
(maybe only in andrewrk's brain)
<knebulae>
daurnimator: well, shared libraries are just regular .dll, .so, or .dylib files, but other than .obj files, I'm not aware of any other "form" (i.e. there's no type of shared library / object that's unique to just zig).
<daurnimator>
knebulae: correct. zig uses the standard library formats. but I thought it might have it's own 'header' format
<knebulae>
daurnimator: got me too. no headers.
<daurnimator>
I feel like there should be some sort of format that just exposes signatures but not bodies.
<daurnimator>
probably generated by the 'zig' tool somehow
<knebulae>
daurnimator: if andrewrk ever forsees widespread zig use, the reality is that people (mostly companies) will want to distribute binary-only libraries, which will require some way to provide zig with function signatures other than exporting from one zig module, building a library and generating a c header, than consuming the c-header in another zig file :/
<daurnimator>
knebulae: yeah that's pretty much my thought
<daurnimator>
was hoping there would be an open issue for it or known plan
<knebulae>
daurnimator: having the ability to generate a zig file with only declarations and signatures suitable for importing and then linking with a provided object file.
<knebulae>
daurnimator: I think the new hotness is to avoid header files though. C# gets away with it because IL has a lot of metadata. Not sure how rust handles it, but they don't have header files.
<daurnimator>
Dpm
<daurnimator>
Don't we need it for deep dependencies?
<daurnimator>
If I write a library A that uses B and C internally (but never exposes it), then I don't want the user of my library X to need the .zig files for B and C installed
<daurnimator>
very different question: how do I create an volatile array to six ints?
<knebulae>
daurimator: "Note that volatile is unrelated to concurrency and Atomics. If you see code that is using volatile for something other than Memory Mapped Input/Output, it is probably a bug."
<daurnimator>
hrm..... for my case I don't know what I want then.....
<knebulae>
daurnimator: then I'll have to ask the $25k question. What do you want / what are you trying to do?
<knebulae>
daurnimator: it looks like valgrind has made this pretty straightforward. It just needs a function pointer set. All this macro is doing is marshalling the arguments from C to asm. Zig should be able to do the same easily.
<knebulae>
+ inserting the "magic" to signal valgrind (__SPECIAL_INSTRUCTION_PREAMBLE).
<knebulae>
daurnimator: unfortunately, the two sections of documentation I need to help right now, Assembly & Atomics, are stubs :/
<daurnimator>
knebulae: yep. I've been trying to figure it out from error messages and the standard library
<knebulae>
daurimator: llvm is notorious for being fickle with inline asm, especially compared to gcc. For some reason it doesn't want / cannot allocate EDX to be read as an 8-bit value. There are other ways to accomplish this read that may compile; see: https://llvm.org/docs/LangRef.html#supported-constraint-code-list
<knebulae>
daurimator: see the paragraph prior to the link too.
<daurnimator>
knebulae: ah thankyou
<daurnimator>
looks like llvm doesn't know the shorthand 'd'
<knebulae>
daurnimator: it should. the x86 section mentions registers a, b, c, d as registers that may be 8/16/32/64-bit, but read as an 8-bit integer. That's why, if you're in 64-bit code, I thought using a different access method might work (i.e. explicitly rdx).
Ichorio has joined #zig
<knebulae>
daurnimator: nice job!
<daurnimator>
Any info around on varargs and interop with va_start/va_end?
<knebulae>
daurnimator: lol. that's what I've been asking for a bit.
<knebulae>
daurnimator: it appears to work for non-string-like arguments.
<daurnimator>
From my previous experience, varargs in zig were pretty simple: you just declare a function as taking `someargname: ...` as the last argument
<daurnimator>
and then you can use `someargname` like a slice/array
<daurnimator>
but now I need to interop with C
<daurnimator>
or actually, I need to interact with system vararg ABI. not even C exactly...
<knebulae>
daurnimator: I see the issue. This is actually a problem in C as well (just google wrapping printf).
<knebulae>
daurnimator: the answer is to use the va_start and va_end macros yourself.
<daurnimator>
knebulae: how?
<daurnimator>
knebulae: I'm writing pure zig here. no C compilation step
<knebulae>
daurnimator: I'm afraid you will probably need access to the platform's underlying va_start and va_end macros. Otherwise, you will need to duplicate the functionality of those macros in pure zig code.
<daurnimator>
ooooo. I'll fix my PR to move things to there...
<daurnimator>
any reason Allocator.free doesn't call Allocator.destroy?
jjido has quit [Quit: Connection closed for inactivity]
<daurnimator>
andrewrk: re pushed.... I understand what you mean about proper integration into the language though
<andrewrk>
that would allow this to work at comptime as well
<andrewrk>
I'll take a look though, thanks for this patch
<andrewrk>
even if we end up going the language integration route, it looks like you've distilled the API from the .h file into simple to understand inline assembly
<andrewrk>
which is in and of itself significantly helpful
<daurnimator>
andrewrk: yeah, the first commit is manually converting the .h with inline assembly to zig for i386 and x64
<daurnimator>
only for base, memcheck and callgrind. helgrind I've never used before and looks like lots of work.
<daurnimator>
(well not lots of work, but half an hour or concentration)
<andrewrk>
btw daurnimator, I'm up to 148 of 518 behavior tests passing in the copy elision branch
<daurnimator>
that.... is not the high score I hoped for :P
<andrewrk>
it's not a linear curve though
<andrewrk>
it was 0 for 2.5 months
<daurnimator>
andrewrk: have you heard the saying "the first 80% is done, only the second 80% to go" before?
<daurnimator>
andrewrk: which I guess is me saying: it's probably an S curve.
<andrewrk>
that's true. making progress on the test suite is good for my motivation though
<andrewrk>
those 2.5 months were pretty brutal
<Zaab1t>
just got an idea for how Zig could do classic for loops
<Zaab1t>
if we want to keep for loops as for eachs
<andrewrk>
Zaab1t, is it: `var i: usize = 0; while (i < 10) : (i += 1) {}` ?
<Zaab1t>
andrewrk: no isnt that already possible?
<andrewrk>
yes
<andrewrk>
forgive me, what is your idea?
<Zaab1t>
well I have a worse idea!
<Zaab1t>
while (var i: usize = 0) : (i < 10) : (i += 1) {}
<Zaab1t>
(make while a disguised for loop)
<andrewrk>
you want the variable declaration as part of the syntax of the while loop
<andrewrk>
this accomplishes either: one less level of indenting when using while loops, or eliminating the index variable from scope after the while loop is done
<andrewrk>
both nice things, but a high cost of increased language complexity
<andrewrk>
also I can't help but think that such a solution might be better if it worked for any variable
<andrewrk>
I'd consider syntax to end variable scope without using indentation before I'd consider this while loop change
<Zaab1t>
andrewrk: what have you considered for counting from x to y?
<andrewrk>
var i = x; while (i < y) : (i += 1) {}
<andrewrk>
rust lets you end a variable scope by declaring over it
<Zaab1t>
`[x..y]` could be a slice of ℕ :p
<andrewrk>
I want to have an open mind about this, but I really have a hard time understanding why this feature is so commonly desired
<andrewrk>
I think people want their code to look elegant
<andrewrk>
and zig's philosophy is: give up. you can't have that. but you can get the semantics correct, and you can do it in a maintainable, understandable way.
steveno has joined #zig
<Zaab1t>
andrewrk: keep the open mind. I'm not saying what the better choice is. I'm not even thinking about fighting the case for my suggestions.
<andrewrk>
Zaab1t, I will :) I know it's really important
<Zaab1t>
You analysis is the same as mine; people want to write elegant code. Here's something to consider, but it's a bit hard to communicate over irc
<Zaab1t>
because it may not be a very logical argument, its more about feelings
<Zaab1t>
It's fun to write elegant code, so if Zig's philosophy is /give up/, then it may hurt Zig in the long run if it turns out that zig code isn't fun to write
<andrewrk>
to be honest, fun is not one of zig's driving forces. zig will happily trade in fun for less bugs or more maintainable code
steveno has quit [Ping timeout: 250 seconds]
Zaab1t has quit [Quit: bye bye friends]
<oats>
fwiw, I'm having plenty of fun
<oats>
howdy everyone, hope you're having a pleasant sunday
<oats>
how can I notate a function pointer type in zig?
<andrewrk>
oats, it looks the same as a function definition, except with no body, and the parameter names are optional
<andrewrk>
example: fn()void
<oats>
so that's the equivalent of a pointer to a void -> void function in C
<andrewrk>
yes
<oats>
awesome, thanks
<andrewrk>
and they work with pointer casting builtins. for example @intToPtr(fn()void, 0x1234) or @ptrCast
<andrewrk>
daurnimator, 278 / 518
Zaab1t has joined #zig
<Zaab1t>
hi again, why is the return type of main !void or void and not u8?
<andrewrk>
Zaab1t, u8 is a valid return type of main