ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<andrewrk>
and here's what happens if you change all the `var` to `const`: https://clbin.com/yk0en
<daurnimator>
andrewrk: to use kernel32.dll+user32.dll or not is sort of like the question to use libc or not for linux.
<daurnimator>
andrewrk: copy ellision progress is good. Though my lack of ability to read LLVM IR only lets me observe assume that a single removed memcpy call is what you were trying to do.
scientes has joined #zig
commander has quit [Remote host closed the connection]
oconnor0 has quit [Ping timeout: 256 seconds]
ShrewdSpirit has quit [Ping timeout: 246 seconds]
<andrewrk>
daurnimator, also the fewer number of alloca's
<andrewrk>
also if you slice the expression inside @sliceToBytes in master, it creates yet another memcpy/alloca, but if you do it in copy elision branch, it does not. still only 1 alloca per var
zachcarter has quit [Ping timeout: 246 seconds]
Ichorio has quit [Ping timeout: 272 seconds]
reductum has joined #zig
<mgxm>
andrewrk: I made some progress on the freebsd side
<andrewrk>
mgxm, do tell
<mgxm>
tomorrow I will try to get the stack trace working
<mgxm>
yes, but it's not implemented on the debug.zig, so I'm getting "unable to open deub info"
<andrewrk>
daurnimator, find out what the ABI is and use that, and ignore valgrind.h
<andrewrk>
if they don't have a stable ABI and require depending on C code, give up
<daurnimator>
andrewrk: valgrind.h is full of per-target inline assembly
<daurnimator>
each target with a 1000-line explanation of platform specific hacks
<andrewrk>
I suggest starting with x86_64
<daurnimator>
linux?
<andrewrk>
sure, I mean it's up to you, which platform would be most useful to you right now?
<daurnimator>
andrewrk: well amd64 linux is what I use day-to-da
<daurnimator>
y
<daurnimator>
though my question was more about what approach is best
<daurnimator>
sounds like you think porting the header to zig is the best answer?
<andrewrk>
daurnimator, I think so. make sure the ABI is stable
<daurnimator>
andrewrk: it is (though its extensible)
<daurnimator>
one "trouble" may be valgrind plugins that add more things on top of valgrind.h
<daurnimator>
andrewrk: why did you immediately dismiss the approach of e.g. improving @cImport (I have no idea what definciencies may existg)?
francis36012 has quit [Ping timeout: 250 seconds]
<andrewrk>
daurnimator, it's an unnecessary dependency on libclang
<daurnimator>
andrewrk: so what's the long-term steady state? that valgrind also ship e.g. valgrind.zig 'headers'?
<andrewrk>
I don't want to create dependencies on C where they don't fundamentally exist
<andrewrk>
the long term steady state is that valgrind has a well documented stable ABI, and then languages can create their own bindings packages
<daurnimator>
I'm not sure that makes sense
<daurnimator>
AFAIK, valgrind essentially "emulates" a CPU. it tracks loads/stores to look for undefined behaviour. it has a JIT to run at almost-native speed.
<daurnimator>
what the valgrind header does is insert 'magic' assembly no-ops that valgrind looks for as it emulates a CPU
<daurnimator>
so you run a no-op instruction that tells valgrind "memory at 0xdeadbeef is now defined to write to for 42 bytes". "memory at 0xcafebabe is now undefined"
<daurnimator>
so the "ABI" as I guess we call it is "insert this specific assembly instruction; insert the arguments by ______; this clobbers registers X,Y,Z"
<andrewrk>
it comes down to inline assembly
<daurnimator>
andrewrk: yeah.... so you're still saying you want to just implement it as inline assembly in valgrind.zig?
<andrewrk>
yes, I would be reluctant to add the first .h file to the zig standard library in order to get this valgrind compatibility
<daurnimator>
okay. I may have to figure out how inline assembly works in zig. I have seen it once or twice I think
reductum has quit [Quit: WeeChat 2.3]
_whitelogger has joined #zig
IntoxicatedHippo has joined #zig
<IntoxicatedHippo>
Has anyone looked in to making a Zig Emacs mode based on cc-mode? I've been trying to do it but I can't find a good way to handle while and for loop syntax.
meheleventyone has joined #zig
porky11 has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Zaab1t has joined #zig
ross_k has joined #zig
IntoxicatedHippo has quit [Quit: Leaving]
<ross_k>
Is there a reason the std library doesn't define abs() for integers? There's fabs() and complex.abs(), but can't find one that takes an i32.
porky11 has quit [Read error: No route to host]
porky11 has joined #zig
steveno has joined #zig
Hejsil has joined #zig
<Hejsil>
ross_k, i think you're looking for absCast
<knebulae>
daurnimator and andrewrk - I have a lot of experience going down this road to varying degrees of success, and daurnimator is right, using raw NT opens up a lot of possibilities for pure POSIX on Windows (not WSL/Cygwin/MinGW). But the truth is that hardly no one actually writes raw NT software really except drivers and utilities mostly. There are a few things needed to get UEFI going. I will make the changes to the options discussed, and prepare a
<knebulae>
basic PoC UEFI application. Then I need to learn to use git well enough to do a PR. And no, I'm not new, I'm old. :/
<bodie_>
andrewrk, what's your priority on the coro rewrite? that's a ton of work, right?
<andrewrk>
knebulae, we're not too much sticklers for process around here. feel free to mail your patch to the mailing list
<andrewrk>
or paste a link here
<andrewrk>
bodie_, yes it's a ton of work and depends on this copy elision branch that is also a ton of work. I think the coro rewrite is less work than copy elision though
<andrewrk>
my plan after merging copy elision is to do some other, less huge things, such as SIMD, anon enum literals, then move on to coro rewrite
<andrewrk>
probably just fix bugs for a few days and merge PRs too
zachcarter has joined #zig
halosghost has joined #zig
Hejsil has quit [Quit: Page closed]
Ichorio has joined #zig
<bodie_>
andrewrk, I was just reading your comment on 943 (package management.) This is an obviously huge problem for many stacks, not just languages. Have you thought about a Nix-like option?
<MajorLag>
You know, if you could `use` with structs, then you could include an interface's 'convenience' functions in your implementation directly. They'd just have to be written with `self: var`
Zaab1t has quit [Quit: bye bye friends]
<andrewrk>
that's an interesting idea
oconnor0 has joined #zig
steveno has quit [Ping timeout: 250 seconds]
<bodie_>
then the in-tool solution would just need to support the features required by something like that
<bodie_>
"just"
<bodie_>
but it frames the problem differently...
<halosghost>
“just” has become one of my favorite four-letter words
<bodie_>
it is very often a weasel-word or has other social weirdness
<halosghost>
“just get me this report that we have no spec for and has all sorts of weird edge cases… by Thursday”
<andrewrk>
what would it look like with `use` as you want it to work?
<MajorLag>
you wouldn't need the `AllocatorInterface(Impl)` wrapper, AbstractAllocator and FixedBufferAllocator (or wahtever) could just have `use AllocatorInterface;` (defined with `self: var`).
<MajorLag>
and I suppose I'd rename AbstractAllocator to just Allocator
<MajorLag>
It was just a thought as to how it could be cleaned up a bit, but I'm not sure that allowing `use` in structs will ultimately be a good idea.
<MajorLag>
I'm willing to forge ahead as is on updating std.
ross_k has quit [Remote host closed the connection]
rayman22201 has joined #zig
ForLoveOfCats has joined #zig
<ForLoveOfCats>
Is the Zig compiler fully self hosting or is the C++ implimentation currently being used?
<andrewrk>
ForLoveOfCats, c++
<andrewrk>
I started a serious effort to self host, and that led to a coroutines rewrite which is now blocking further progress
<ForLoveOfCats>
I thought so, but the readme mentions compiling the self hosted compiler as a step in compiling Zig for normal use
<ForLoveOfCats>
Am I misinterpreting it?
<andrewrk>
I wonder if the italics actually make people not see the notes rather than point them out
<ForLoveOfCats>
I did read that, however the wording threw me off hence I came here to ensure I understood its meaning
<ForLoveOfCats>
which I did
<ForLoveOfCats>
Thank you for your time!
<andrewrk>
ForLoveOfCats, I see, thanks, I will clarify the wording
<andrewrk>
ForLoveOfCats, I pushed a commit to clarify the wording. thanks for the feedback
<ForLoveOfCats>
Oh wow, awesome!
steveno__ has quit [Remote host closed the connection]
zachcarter has quit [Ping timeout: 256 seconds]
daurnimator has quit [Ping timeout: 250 seconds]
halosghost has quit [Quit: WeeChat 2.3]
daurnimator has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
zachcarter has joined #zig
porky11 has quit [Ping timeout: 268 seconds]
oconnor0 has quit [Ping timeout: 256 seconds]
<daurnimator>
knebulae: writing drivers and utilities in zig seems like a reasonable goal IMO....
<daurnimator>
but also, as I mentioned earlier, there are many situations where normal programs drop down to the nt api for a single task
<daurnimator>
e.g. libuv uses the nt level socket api for polling, bypassing winsock. (which is much faster!)
<daurnimator>
knebulae: also there is a project 'midipix' which is an implementation of posix on top of the nt api. I'd love it if zig "just worked" for midipix