<andrewrk>
until that issue is solved, `zig cc` should be considered an internal unsupported command
marmotini_ has quit [Ping timeout: 240 seconds]
<andrewrk>
use build-exe
<daurnimator>
andrewrk: I'm trying to use zig as a cross compiler
<daurnimator>
(a C one)
<andrewrk>
zig build-exe --c-source foo.c
<daurnimator>
==> I'm plugging in CC="zig cc" to
<daurnimator>
==> I'm plugging in CC="zig cc -target ......" to various existing build systems
<andrewrk>
#3089 ability to use zig as a drop-in replacement for a C compiler
<daurnimator>
okay. so consider that not-ready for now?
<andrewrk>
right
<daurnimator>
doh. okay
marmotini_ has joined #zig
<daurnimator>
andrewrk: also I'm still hoping for guidance for 4165
marmotini_ has quit [Ping timeout: 272 seconds]
epmills has joined #zig
epmills has quit [Ping timeout: 260 seconds]
<HesamR>
Hi! Is there a way to set column limit for "zig fmt"?
<daurnimator>
HesamR: no
<daurnimator>
hmmm, fs.Dir.close expects a mutable pointer
<HesamR>
daurnimator: thanks
<fengb>
There probably never will be any configuration for zig fmt
<daurnimator>
HesamR: for e.g. function args you add a trailing comma and it will go to multiple lines
<fengb>
... the solution for mixing async and generator problem would be... more async frames
marmotini_ has joined #zig
marmotini_ has quit [Remote host closed the connection]
knebulae has quit [Ping timeout: 268 seconds]
knebulae has joined #zig
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
ur5us has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
<daurnimator>
oh god.... I just noticed that half of functions take AT_SYMLINK_NOFOLLOW and half take AT_SYMLINK_FOLLOW
SimonNa has quit [Remote host closed the connection]
<aperezdc>
lol
<aperezdc>
true, that's “great” API design
<aperezdc>
yay Unix 🤷♂️
ur5us has quit [Ping timeout: 260 seconds]
alexpana has joined #zig
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0__ has joined #zig
<mq32>
aperezdc: grown structures
alexpana has quit [Ping timeout: 260 seconds]
WilhelmVonWeiner has joined #zig
WilhelmVonWeiner has left #zig [#zig]
alexpana has joined #zig
_Vi has quit [Ping timeout: 245 seconds]
dddddd has joined #zig
<betawaffle>
uhg, i'm having trouble focusing on work because I want to play with zig
epmills has joined #zig
return0__ has quit [Remote host closed the connection]
epmills has quit [Quit: Leaving...]
epmills has joined #zig
<epmills>
thanks plumm for the hint about using 'inline for' to generate multiple build targets
return0e has joined #zig
epmills has quit [Remote host closed the connection]
doublex has quit [Ping timeout: 260 seconds]
doublex has joined #zig
_Vi has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
Snetry has quit [Ping timeout: 265 seconds]
Snetry has joined #zig
waleee-cl has joined #zig
rom1504 has quit [Ping timeout: 252 seconds]
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
rom1504 has joined #zig
<fengb>
betawaffle: introduce Zig at work 🙃
<betawaffle>
i wish. i mean it's not crazy, just not ready for that yet. we're currently a mostly-go-dipping-into-rust shop
<mq32>
Zig is sadly not production ready yet :(
<fengb>
I’m mostly joking. Zig has had about 8 breaking changes the previous month so it’s definitely not production ready
<leeward>
I'm actually giving a talk on it at work today, and one of the subjects is "Why not use Zig?" The biggest answer is "It's not done."
<betawaffle>
i'm glad it's at least really obvious how not done it is
<fengb>
Why... not? So you’ve already sold them on why? :P
<betawaffle>
rather than so close you might not realize how bad of an idea it would be
<betawaffle>
my first attempts at messing with async stuff was met with completely useless non-errors from the compiler
<leeward>
Yeah, there's some talking up.
<fengb>
Async is still super new so there’s a lot of hidden bugs
<leeward>
I work on medical devices, so it will be a while before Zig is ready.
<betawaffle>
i can't even imagine doing that kind of work
<leeward>
There are plenty of areas where Zig isn't ready for prime time, but bugs tend to get closed pretty fast. I'm amazed at the development pace.
<betawaffle>
you'd have to ensure you haven't written any bugs, but also that the compiler hasn't compiled your bug-free code into any bugs
<fengb>
It’s sorta uncharted territory for the compiler so it’s a big Wild West
<betawaffle>
leeward: how does the industry deal with this problem pre-zig? (under the assumption that zig will eventually be a great fit for that)
<leeward>
betawaffle: Lots of process. Not all things depend on software for patient safety, but if they do it adds process that has to be documented.
<leeward>
Really, it's just a bunch of documents showing that the stuff has been designed and verified.
<betawaffle>
remind me never to get a medical device installed
<leeward>
Yeah, really.
<leeward>
The thing that scares me is security. It's getting better, but I really wouldn't want a pacemaker from 10 years ago.
<betawaffle>
i'm glad to be in a sector where the worst that can happen is people losing money
<fengb>
There’s also the CompCert C compiler
bheads has quit [Quit: bheads]
<leeward>
There are so many C compilers. Several are certified.
<fengb>
I’d expect (and probably want) Rust to make more headway into medical devices
<leeward>
Rust has fans, but I don't know of any projects we've done with it. The problem is newness. The amount of work you have to do to verify that a compiler generates the code you expect is not small.
<fengb>
No doubt
<fengb>
Rust has much stronger safety guarantees than Zig, so I’d trust it more
<leeward>
Also, I'm not a huge fan of Rust's, personally. It's very complicated.
<fengb>
I agree. I’m here because I couldn’t grok Rust
<leeward>
It has strong safety guarantees if the code in the unsafe blocks is written correctly.
<fengb>
Zig is the 90% solution and that’s enough for me
<leeward>
I took a few cracks at it, and the last time I managed to get a decent grasp of most of the concepts. It's just that there's so much going on in every line that it's hard to reason about.
<betawaffle>
and that level of understanding doesn't necessarily stick around if you stop using rust
<leeward>
It's really true. Also, it's not particularly aimed at embedded devices.
<leeward>
It feels like it was designed for making large network-connected applications like web browsers.
<leeward>
I don't know where I got that impression.
<betawaffle>
lol
<BaroqueLarouche>
When I tried Rust, I kinda liked it but it was hard to use, I couldn't see some of my colleages at my old job use it
<betawaffle>
it also kinda has the problem of many ways to do the same thing
<leeward>
It's a lot like C++. If I had to use C++, I would love to switch to Rust.
<betawaffle>
something go and zig seem to be really good at avoiding
<BaroqueLarouche>
the module system wasn't intuitive at all in Rust
<leeward>
Yeah, I think Go (and Zig) had the right philosophy. Simpler is better.
<BaroqueLarouche>
and so many hours wasted fighting the borrow checker
<betawaffle>
sometimes i'm frustrated by how much go gave up on
<leeward>
If I need concurrency, I'll use Erlang.
<betawaffle>
when is someone going to write a programming language programming language?
<gonz_>
Racket is that already.
<betawaffle>
is it though?
<gonz_>
Yes.
<betawaffle>
why isn't everyone using it for that then?
<gonz_>
They sort of are...? Are you complaining that it's not popular enough or about the usage patterns of the current users?
<gonz_>
Generally speaking the way you solve problems in Racket is to write new languages that all run on Racket.
<betawaffle>
maybe we have different definitions
<gonz_>
Provided you need to, obviously. Naughty Dog used/uses Racket to compile their own scripting language to C++.
<leeward>
betawaffle, OCaml?
<betawaffle>
i want something specifically designed for all the problems of writing a new programming language, including first-class support for automatically generating full-featured plugins for every editor
<leeward>
Racket is just another Lisp, and in Lisps, people write DSLs.
<gonz_>
It's not really just another Lisp
<leeward>
OCaml was designed for writing languages.
<gonz_>
That's a massive oversimplification.
<leeward>
It's a descendant of Scheme, which is a Lisp for education.
<gonz_>
Again, you're kind of underdescribing it.
<leeward>
I think I'm describing it enough for these purposes.
<gonz_>
If you have no experience with it it'd probably be better if you just stopped talking about it.
<leeward>
My point is that DSLs are the way to do things in the Lisp family of languages.
<gonz_>
And my point is that Racket is a few levels above CL, Clojure, et al in terms of language making facilities.
<gonz_>
They're toy languages in comparison when it comes to language creation.
<fengb>
The problem with old Lisp was that every project invented their own incompatible ecosystem
<leeward>
Huh, I hadn't realized that Racket focused on PL creation. I remember a bunch of politics when it split off from Scheme, but missed that part.
HesamR has quit [Read error: Connection reset by peer]
<betawaffle>
"automatically generating full-featured plugins for every editor" seems to be a missing feature in basically everything
<leeward>
Anyway, the first version of the Rust compiler was actually built in OCaml.
<gonz_>
> Racket is a general-purpose programming language as well as the world’s first ecosystem for language-oriented programming. Make your dream language, or use one of the dozens already available, including these ...
<leeward>
It's easy to parse your language when your language is a parse tree.
<gonz_>
I'll let the promo blurb speak for itself. It's completely true as well; Racket really is that kind of language.
<leeward>
gonz_, Yeah, that's what made me realize I was wrong.
<leeward>
Though "these" all look suspiciously lispy.
<betawaffle>
they sure do
<gonz_>
As long as you can write a reader for it you can use it, it just happens that it's way easier to fit a language like this into your project if you already know Racket.
<gonz_>
I would argue datalog isn't very lispy.
<fengb>
Al Lisps have basically the same syntax, but semantics are where they differ greatly
<leeward>
I like the graphic for "The best of Scheme and Lisp". It looks like a giant pile of left parens.
<fengb>
And Lisp programmers commonly claim that exposing the AST directly is better
<leeward>
gonz_: Yeah, that's fair. Datalog looks more like prolog than lisp.
<leeward>
fengb: That's the claim.
<fengb>
I don’t agree with it but it has many merits
<gonz_>
I think Lisp syntax is overblown as a problem but I'm also not using Lisps 24/7 nowadays. I think carp, a low-level Lisp with borrow checking and static types, is very interesting, though.
<gonz_>
But that's because of what it offers over the classic Lisp runtime profile more than anything. It's a departure from most of those languages.
doublex has quit [Ping timeout: 260 seconds]
<fengb>
I wonder how the world would be if hardware Lisp machines actually won
<leeward>
I don't think it's a problem, per se, just that syntax is a valuable tool in the language designer's kit and just making it a parse tree leaves a lot of useful stuff on the floor.
<gonz_>
Making it a parse tree opens other doors, though, provided you want them.
<gonz_>
If you have no interest in macros there's no real point, though.
marmotini_ has joined #zig
<leeward>
The problem with Lisp machines, from my understanding, is that they couldn't be made to go fast enough in the '80s. Given that we're still pushing hardware to perform as well as possible in a lot of domains, I suspect it had to go the way it did.
<gonz_>
I feel like the only pushing we're doing is accidental because everything is super inefficient nowadays.
<leeward>
I feel like we've gotten to the point where the common uses for metaprogramming can be put in languages with tools that are less sharp than macros.
<gonz_>
The hardware is certainly struggling to keep up, but it's mostly because no one actually cares to do anything well.
<fengb>
We are definitely optimizing poorly. I wonder how bad the 'local maxima' is for even x64 design
<leeward>
I don't know about that; Google spends a lot of money on electricity. Better performance per watt would make a lot of people happier.
marmotini_ has quit [Read error: Connection reset by peer]
<betawaffle>
i think hardware folks are generally doing a pretty good job. software is the problem
<fengb>
We've spent the past 5 decades on developer productivity. It's easier than ever to get started and not have to worry about hardware resources
<gonz_>
Better performance everywhere would be great. We're not getting better performance because everything sucks and is made to suck because of "business".
<leeward>
The thing is, most of the time that's the right way to go.
<fengb>
I mean, I owe my day job to that focus :P
<betawaffle>
same
<leeward>
If you haven't profiled your program, you don't know how to make it faster.
<leeward>
And for most development the fast bits are already fast because application writers are just calling functions in optimized libraries.
<fengb>
But there's also some truth to it. We don't need to profile to know that Slack is a dog
<gonz_>
Most programs are created gratuitously slow from the beginning. It's not even that people are avoiding premature optimization, they're prematurely pessimizing.
<fengb>
"prematurely pessimizing" 😂
<leeward>
Holy crap, you're right about slack.
<betawaffle>
fengb: and that's a great example... slack is so bad because they're prioritizing all the wrong things
<betawaffle>
or maybe just what we consider wrong
<leeward>
Or maybe they're prioritizing the right things. It's pretty successful.
<betawaffle>
just picking electron is a problem
bheads has joined #zig
<fengb>
It's actually a little funny. A lot of people shit on React but it can do things much better than jQuery ever good. But because everything is so much easier now, we have so much more React schlock
<betawaffle>
right, i like slack, but i also hate it
<gonz_>
Arguably Slack are doing great, yeah. This will never, ever be solved by business people. Only people who want to make good things will change even a small part of this trend.
<fengb>
Electron doesn't have to be terrible. VSCode is generally well received
<betawaffle>
sure, but vscode is heavier than it should be too
<gonz_>
Meanwhile all I want is more native apps that do as little communication as possible.
<fengb>
wasm doesn't have to mean web
<gonz_>
Fair enough. Not as much about communication as it is about the characteristics of a browser based environment, I guess.
<gonz_>
With that said I'm not a curmudgeon about it; I use VSCode because I think it delivers a lot of value and is reasonably well made.
* leeward
goes back to emacs
<gonz_>
But involving browsers more in anything is inherently just not something I want. Running WASM code in specialized VMs outside of that context, maybe, I don't really know. If it helpspeople, fair enough.
<fengb>
wasm doesn't even understand the browser :P. I think the "web" gives people a poor connotation
<fengb>
It's just a standardized bytecode system with proper sandboxing. The instruction set is tiny but robust
<gonz_>
I was really "ugh" about how hard it was to run code in certain languages on Windows for a while and WASI would've helped there.
<gonz_>
So I see the point
euandreh has joined #zig
<leeward>
I just want people to stop using Windows, but that seems unlikely to happen.
<gonz_>
And jump to what? Linux sucks too and who wants to pay for a Mac?
<leeward>
I'm pretty happy on Linux.
<fengb>
ChromeOS :P
<leeward>
I had to use Windows for work for a while, and it hurt.
<gonz_>
I've spent entirely too much time on Linux to be happy with it. It really is an awful platform with a fundamentally broken eco system that is irredeemable.
bheads_ has joined #zig
<leeward>
I don't know, I've been using it as my primary desktop for...20 years?
<betawaffle>
i want riscv with native support for wasm
<leeward>
Are you talking about red hat?
<gonz_>
They'll never fix it because the whole idea is that it's just a bazaar and nothing is even remotely supposed to be working with everything else.
<gonz_>
I ran mostly Arch. For a linux distro it's fine and I liked it for a long time, but I think the whole kernel/distro split is broken as well.
<Cadey>
gonz_: my goal is to replace native code with webassembly
<fengb>
systemd will fix everything 🙃
<Cadey>
so that the underlying OS and CPU are irrelevant
<Cadey>
like they should be
<gonz_>
Nowadays I have to run Windows because there is zero chance that my voice coding software will ever run reasonably on Linux.
<fengb>
gonz_: so what about one of the BSDs?
<leeward>
Cadey: That works fine for the CPU (see: Java, .NET) but video cards become problematic.
<fengb>
Oh well that answers that :P
bheads has quit [Ping timeout: 265 seconds]
bheads_ is now known as bheads
<Cadey>
yeah leeward i don't have a good solution for that
<gonz_>
fengb: Yes, I think an actual team taking ownership of the OS as a fairly complete unit is much better as a base concept.
<gonz_>
In general most things are better about BSDs, even the code quality.
<leeward>
So it sounds like you do want to pay for a Mac.
<Cadey>
^
<Cadey>
tbh this is why i use macs/iPads for my main computing stuff
<gonz_>
Meh, not really. I've been leaning towards it a few times but fundamentally it irks me that they charge so much for it as well. Windows isn't even half as bad as people make it out to be, also.
<fengb>
Yeah I use a Mac because I like the default UI. I don't have to do homework just to get my desktop working
<leeward>
I tried a mac for a while maybe 10 years ago. Couldn't be productive. Went back to Linux within 6 months.
tane has joined #zig
<fengb>
And as much as I like Linux... I absolutely despise X11
<fengb>
I have no idea why the ecosystem settled on that
<gonz_>
It's just old and crufty
<betawaffle>
wasn't X11 from before linux?
<tane>
howdy, is there some guide on how to use the zig build system to e.g. (i) build a library, (ii) build another executable that uses the library and both in different projects, i.e. not in one build.zig?
<leeward>
XFree86?
<leeward>
Yeah, that's older than Linux.
<leeward>
tane: Not really, but if you need help getting it done the know-how is in this channel.
<fengb>
When we're not too busy having OS flame wars :P
<leeward>
^^
<tane>
leeward, alright, thanks :)
<leeward>
Oh, right, that. Your OS of choice is wrong and bad, and you're a bad person for choosing it.
<fengb>
Zig build system hasn't been too stable so there hasn't been much documentation or guides
<gonz_>
As a last comment on Linux vs. Windows the only thing I really miss now is a tiling window manager.
<fengb>
I'm a corporate sellout. I gave the soul of my firstborn to Apple for lickable buttons
<leeward>
They are pretty buttons, and who really uses their soul anyway?
<betawaffle>
hey i didn't get lickable buttons...
<betawaffle>
i feel cheated now
<fengb>
“We made the buttons on the screen look so good you'll want to lick them.” — Steve Jobs
<betawaffle>
ohh, those
<betawaffle>
i thought you meant literally
<fengb>
I dunno about you, but I lick my screen whenever it boots up
<Cadey>
licks for luck
<leeward>
How do you deal with the streaks?
<betawaffle>
microfiber cloth
<fengb>
tane: Zig prefers source based libraries over distributing binaries. At the moment it's generally copying over the source or linking it in via submodule or something, but the package manager will come soon™
<tane>
fengb, source copying is fine with me, I'm just used to that kind of thing with C++, where it means adjusting a CMakeLists file for 1h before you can actually proceed. All I hope for is an easier way to include a while subfolder into the build tree :)
<fengb>
Was previously used to cancel async functions, but the semantics were unsound with the async rewrite so that got dropped / punted
<frmdstryr>
I don't get why that would require a keyword?
<frmdstryr>
vs just a `frame.cancel()`?
<fengb>
Cancel triggers errdefers
<fengb>
So it needs to be integrated into the compiler somehow
<betawaffle>
so, when i was reading about cancel before, it struct me that the only thing that matters from a resource perspective is whether the result makes it to the caller or not
<leeward>
hmm?
<fengb>
Currently taht's sorta true. You need to wire in all of the early exits manually. With proper cancellation semantics, you can kill a running frame and it should cleanup after itself
<fengb>
But that got into a whole can of worms, hence it got dropped
<frmdstryr>
Yeah shouldn't it just set a flag and have the event loop stop resuming it?
<betawaffle>
right. i liked the idea of *actual* cancellation being an opt-in check-for-yourself thing, where in the worst-case, cancel is the same as await
<betawaffle>
but with the difference being that the result is discarded, and so the errdefers need to handle it
<fengb>
The problem is that due to no colors, any function can become async and thus cancellable
<betawaffle>
which seemed to work, except for basically the case of cancel happening in the last segment of a function
<fengb>
And we can't possibly force every function to cleanup at any point, because that's just reintroducing colors
<betawaffle>
ie. when the function's author isn't expecting a cancel to make sense
doublex has joined #zig
<betawaffle>
i think it's reasonable to punt on it, though, since the workaround isn't so bad
<fengb>
If we had cancel in the language, the only idea we have right now is that every function must understand cancel or suffer resource leaks, which is a little ridiculous
<fengb>
With current semantics, nothing understands cancel... which isn't great but less bad
<betawaffle>
you can still implement cancellation manually with what we have now
<fengb>
I wonder if a solution is have explicit cancellation points
<betawaffle>
that's what i was thinking
<fengb>
Any explicit suspend / await would be marked as cancellable.
<betawaffle>
have the first cancellation point being the user asking "have i been cancelled yet"
<fengb>
And any implicit one (like synchronously calling an async function) will not because that's unsound
<betawaffle>
ehh, i'm thinking even suspend/await being sketchy
<betawaffle>
i think it should be completely explicit
<betawaffle>
if @isCancelled() { ... }
<betawaffle>
i like the idea of the function author being in complete control
<fengb>
... I'm not sure I'd like this. It'd mean we'd have more seams since cancellable would be a different return type
<betawaffle>
really?
<fengb>
Request is cancellable. Therefore anything that makes a request must understand what cancellable means
<fengb>
Maybe inject it as an error type? That might work
<frmdstryr>
Why cant async just returned a Future struct with a few methods and flags? It's the same ideas as "Thread" not?
doublex has quit [Ping timeout: 265 seconds]
<leeward>
Errors seem like a good fit for this.
doublex has joined #zig
<leeward>
Though that conflates some unrelated things, and you can't handle "Cancelled" and carry on as usual.
<fengb>
You can sorta handle it. e.g. if a request is cancelled, there's other work that might make sense
<betawaffle>
i sorta feel like cancellation should just be a way to more concisely do it the same way you'd do it manually
<betawaffle>
but maybe i'm missing some important thing
<fengb>
Yeah I like having an error. That could be as simple as return error.Cancelled
<fengb>
So... this idea cropped up in that thread
<betawaffle>
exactly... you'd only be able to cancel functions that can return errors, or maybe only functions that can specifically return that error
<frmdstryr>
That's how python's twisted did it before all the asyncio stuff. But how do you cancel from "outside" then?
<frmdstryr>
twisted/tornado used both, cancel from inside using an error or outside using a flag
mahmudov has joined #zig
<betawaffle>
frmdstryr: yeah, so something that was mentioned in the thread is an extra bit in the frame's state for cancellation
<betawaffle>
it seemed like the *only* issue with that was for functions where cancellation wasn't supported but requested, the function doesn't know it has to add extra errdefers for that situation
<betawaffle>
what it seems like you'd want in those situations is for the compiler to not let you cancel it, such that you're forced to await and clean up the resource returned to you
<betawaffle>
fengb: does that sound right?
<fengb>
Yeah, every function can automatically become async
<fengb>
But if you don't know it, there'd be lots of trouble
<betawaffle>
i mean, in reality, it doesn't make sense to cancel a function that doesn't support it. but we'd need the compiler to enforce that
<betawaffle>
right, async without cancel is fine for "every function"
<betawaffle>
but cancellation has to be explicitly supported in any situation involving resources
<fengb>
This discussion was a few months ago and I'm generally a devil's advocate and not necessarily understanding nuances :P
<frmdstryr>
" issue with that was for functions where cancellation wasn't supported but requested"
<frmdstryr>
cancellation should only ever happen "from the outside" at a suspend point
<betawaffle>
well, yes and no
<betawaffle>
first of all you're right that it's not really cancellation if it happens from "the inside", it's something else
<betawaffle>
as far as at a suspend point... that depends on what the programmer thinks the contract of a suspend point is
<betawaffle>
and whether that contract is reasonable
<betawaffle>
for example, if the contract is that any suspend point can be cancelled, but that those suspend points may be non-obvious to the function author, that's probably not reasonable to expect them to get it right
<frmdstryr>
It would imply that every function that suspends also returns an error (cancel error) which the author would have to handle
<betawaffle>
yeah, that too
SimonNa has joined #zig
gonz_ has quit []
gonz_ has joined #zig
return0e has quit [Remote host closed the connection]
<metaleap>
ok just to doublecheck altho langref doesnt suggest this is possible: we can `if` on nullables, we can `if` on error-unions, but for other/tagged unions only `switch` goes, right? I'm translating Go code to Zig full of `if goal,isgoal := someval.(*GoalType); isgoal { /* use `goal` here */ }` constructs. and it's usually only ever 1 case out of numerous, so every time a switch block with 1-case plus mandatory `else => {}` starts to look quite noisy.
wootehfoot has joined #zig
<metaleap>
if we could "pass syntactic blocks" to comptime funcs to be "emitted" inside a non-comptime-if, that could allow for such sugars to be done in userland of course =)
jmiven has quit [Quit: bye]
<metaleap>
s/nullables/optiontypeds
jmiven has joined #zig
<frmdstryr>
Yay async usart works :)
<via>
frmdstryr: how are you doing resumption? cause you don't want to resume from your int handler do you?
<via>
i was gonna make an event loop that just busy waited on flags being set
alexpana has quit [Ping timeout: 268 seconds]
<via>
and the int handler for when its writable (usb in my case, not uart, but meh) just sets that flag
_Vi has quit [Ping timeout: 245 seconds]
<frmdstryr>
Well it's not using interrupts yet so it's still more or less just a busy loop
<via>
checking to see if the uart fifo has free space
<via>
?
<via>
so basically the same thing i was planning to do
<via>
i'm using opencm3, it looks like you've put a lot of effort into doing it without a lib, thats awesome
<frmdstryr>
Yes, using c defeats the purpose of zig imo
<via>
it sucks that you basically have to re-invent an entire event loop
<frmdstryr>
yeah i know
<frmdstryr>
it's quite simple since it's a single thread though
<via>
i disagree, all my real application logic can be in zig, i don't really care that estting up some gpio pins and other things is all C
<via>
yeah but its not just the loop, you're recreating futures and queues too
<via>
why not the std queues?
<frmdstryr>
I don't think zig's main event loop uses Futures anyways
<frmdstryr>
i wanted to make it so the whole node could be copied
<frmdstryr>
it's technically not needed
<via>
either way, its awesome to have it working
<via>
are you planning to wrap it in an outstream?
<via>
last i looked that was problematic with the current interface design
<frmdstryr>
Haven't thought about it yet.
<metaleap>
tagged union fields are: enumerant plus type. whats the comptime builtin that given the former, yields the latter?
<metaleap>
none of @TagType @Type @TypeOf @typeId @typeInfo seem to fit the bill. or on 2nd thought @typeInfo could be it? not clear from langref, will try
<metaleap>
nope.. not it.
Akuli has joined #zig
waleee-cl has quit [Ping timeout: 260 seconds]
odc has quit [Ping timeout: 252 seconds]
l1x has quit [Ping timeout: 252 seconds]
shakesoda has quit [Ping timeout: 272 seconds]
dch has quit [Ping timeout: 264 seconds]
wjlroe has quit [Ping timeout: 252 seconds]
strmpnk has quit [Ping timeout: 248 seconds]
tracernz has quit [Ping timeout: 252 seconds]
wjlroe has joined #zig
waleee-cl has joined #zig
shakesoda has joined #zig
strmpnk has joined #zig
odc has joined #zig
<mikdusan>
meta.TagPayloadType() ?
<metaleap>
oooh you mean @Type(..).Payload? gonna try
<metaleap>
oh you mean std.meta
<mikdusan>
+1
<metaleap>
seems to be the ticket, merci!
marmotini_ has joined #zig
tracernz has joined #zig
_Vi has joined #zig
mouseghost has joined #zig
<mouseghost>
hi, i started to filled with winsock2 and i initialize a struct; in C its easy: WSADATA ws; - how can i reproduce a similar behaviour in zig? when i did var ws: c.WSADATA = c.WSADATA{}; it errors on me because it misses fields
<fengb>
Is it populated via pointer? If so, you can do `var ws:c.WSADATA = undefined;`
<mouseghost>
thanks
<mouseghost>
yhm next question, can i link against win32 somehow
<gonz_>
Which has no automatic link info in that lib
return0e has joined #zig
<gonz_>
Heh, I don't keep up, I guess
<mouseghost>
i could use -lWs2_32 or something, no?
<mouseghost>
i dont want to use any wrappers or something .x.
<fengb>
I keep up and I just forgot so probably not any better :P
<gonz_>
mouseghost: `-l` AFAIK, yes, but you can also mark the extern fn you've made with a library annotation
<mouseghost>
.-. my point is that it doesnt link AAAAA
<gonz_>
Is my client double sending what I write? IRCCloud is getting DDoSed and it's behaving oddly for me. If it's double sending it I'll just stop writing.
<mouseghost>
no, it doesnt double
<mouseghost>
why it doesnt link reee aaaa
<mikdusan>
mouseghost: presumably you are sending `&ws` to a C function that is declared somewhere
<mikdusan>
it has an `export` line
<mikdusan>
err. scratch that
<mikdusan>
it has an `extern`
<betawaffle>
gonz_: only seeing one from you
<mouseghost>
uh i mean... it doesnt even link; it errors as if i didnt add -lws2_32 to gcc with c source
<metaleap>
i have a recursive func that sometimes creates and returns new &MyStruct{.Field1 = .., .Field2 = .., ...} . these all ultimately build up trees that do end up being put in a pre-alloc'd slice of such trees (think AST top-level nodes) ---
zfoo_ has joined #zig
<zfoo_>
What does this type mean: [*:null]const ?[*:0]const u8
<metaleap>
they all end up with the same values across all nodes that are such MyStruct trees UNLESS i create them in the recursive func not "locally" (aka on stack via &MyStruct{} notation) BUT using allocator.create --- only then do they preserve each their own individual correct values --- rather than all being equal tho not equal-addrs
<metaleap>
whats up with that?
<fengb>
`[*:null]const` — null-terminated slice of const <something>, `?[*:0]const u8` — optional 0-terminated slice of const u8 (e.g. strings)
<fengb>
`[*:null]const ?[*:0]const u8` — null-terminated slice of const (optional 0-terminated slice of const u8)
<metaleap>
ahh lemme guess: taking addresses of local vars and returning them for the ultimate caller to hold on to is not a good idea in langs like C / Zig, right? at least not from recursive funcs?
<metaleap>
i'm used to doing that in go but i know they track "stack escape" for GC
<fengb>
Yeah, that's a current footgun. At some point in the future the compiler would detect them and throw a proper error
<zfoo_>
fengb: how would one construct this type inline?
<metaleap>
fengb: thx for confirming! applies to all funcs not just recursives, right? so i need to really heap-alloc anything that is to survive local scope of func (such as by being returned), right?
doublex has quit [Ping timeout: 260 seconds]
<metaleap>
now that i think it through cleanly, its the only way that even makes sense in a non-gc lang :D man its a new world.
<fengb>
Yes you'll need to externally allocate any managed lifetimes (or dynamic sizes). Things like ArrayList are built with allocators
<fengb>
zfoo_: I'm not quite sure actually. Sentinel termination is a recent addition, and most of Zig userland are slice based because they are easier to work with (but incompatible with C)
<fengb>
argv is something the OS provides so I never really thought about creating the type manually before
<zfoo_>
okay, I'm looking at it with std.os.execveC
ur5us has quit [Ping timeout: 260 seconds]
<fengb>
I can brute force something real quick but please don't think it's the right way
<andrewrk>
that's one of the benefits of zig string literals being able to cast to both slices and null terminated pointers
waleee-cl has quit [Quit: Connection closed for inactivity]
doublex has quit [Ping timeout: 258 seconds]
doublex has joined #zig
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
zfoo_ has quit [Remote host closed the connection]
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
mouseghost has quit [Quit: mew wew]
doublex has quit [Read error: Connection reset by peer]
doublex has joined #zig
marmotini_ has quit [Remote host closed the connection]
return0e has joined #zig
tane has quit [Quit: Leaving]
Akuli has quit [Quit: Leaving]
doublex has quit [Ping timeout: 258 seconds]
alexpana has quit [Quit: WeeChat 1.9.1]
moo has quit [Quit: Leaving]
leeward has quit [Remote host closed the connection]
leeward has joined #zig
metaleap has quit [Quit: Leaving]
shakesoda has quit [Quit: Connection closed for inactivity]
leeward has quit [Remote host closed the connection]
<watzon[m]>
Does zig have variable length lists? I can't find anything about adding new items to an array or vector in the docs.
<frmdstryr>
std.ArrayList
<watzon[m]>
Thanks :)
ur5us has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
leeward has joined #zig
<daurnimator>
frmdstryr: why did you add your own copy of TailQueue?
mahmudov has quit [Remote host closed the connection]
<frmdstryr>
Originally because std.atomic.Queue wasn't working
<frmdstryr>
Then I realized it works if I set it to build with single_threaded = true
<frmdstryr>
And wanted to be able to return the whole Queue node as a "Future"
<frmdstryr>
I'm just using std.atomic.Queue now
ur5us has quit [Ping timeout: 260 seconds]
<frmdstryr>
I was hoping to be able to use the addCallback/callLater, etc. and return a Future from those but I can't think of any way to make that work