<geemili>
The short of it is that async doesn't automatically finish itself, you need to make sure that the async frames are saved somewhere and completed
<ed_t>
so coroutines
<ed_t>
not threads, at least for now
<geemili>
Yes
<ed_t>
thanks - it explains what I was seeing.
<ed_t>
would you know if there are plans to change this before 1.0
* ed_t
remembers working in ibm's CICS when it just had cooperative multitasking - I would end up fixing some strange performance bugs...
<ed_t>
I eventually had to put a preprocessor on the compiler to insert susends() in potenially long loops so as not to cause stalls....
<ed_t>
suspends()
Techcable has joined #zig
<geemili>
I don't think there is? If you want to do some threading you can use `std.Thread`
<geemili>
`std.Thread.spawn` to be specific
<ed_t>
thanks
<geemili>
The std library also provides a multithreaded event loop for async tasks if you enable it
<geemili>
What daurnimator referred to earlier as `io_mode = .evented`
<daurnimator>
ed_t: `async` in zig just means that a function should be *started* but not finished in the current location
sineer has quit [Read error: Connection reset by peer]
st4ll1 has quit [Quit: WeeChat 2.9]
gazler_ has joined #zig
gazler has quit [Ping timeout: 264 seconds]
earnestly has quit [Ping timeout: 272 seconds]
<ed_t>
what I wanted for this case was Thread.spawn. In my test program, just moving the xterm update to a thread run about 30% faster.
<ed_t>
coroutines using zig's async, are great but not for what i was trying to do.
mikdusan1 has joined #zig
nickster1 has joined #zig
rtpg_ has joined #zig
lukego_ has joined #zig
dreda_ has joined #zig
gonz__ has joined #zig
swills_ has joined #zig
mikdusan has quit [Read error: Connection reset by peer]
amk has quit [Ping timeout: 240 seconds]
rtpg has quit [Ping timeout: 240 seconds]
lukego has quit [Ping timeout: 240 seconds]
nickster has quit [Write error: Connection reset by peer]
dreda has quit [Ping timeout: 240 seconds]
gonz_ has quit [Ping timeout: 240 seconds]
swills has quit [Quit: No Ping reply in 180 seconds.]
skuzzymiglet has quit [Ping timeout: 240 seconds]
betawaffle has quit [Ping timeout: 240 seconds]
nickster1 is now known as nickster
gonz__ is now known as gonz_
rtpg_ is now known as rtpg
lukego_ is now known as lukego
skuzzymiglet has joined #zig
amk has joined #zig
betawaffle has joined #zig
racoon has quit [Remote host closed the connection]
marler8997 has joined #zig
racoon has joined #zig
xackus has joined #zig
xackus_ has quit [Ping timeout: 260 seconds]
v0idify has joined #zig
reductum has joined #zig
reductum has quit [Quit: WeeChat 3.0]
plumm has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
leon-p has quit [Remote host closed the connection]
kenran has joined #zig
remby has quit [Quit: Konversation terminated!]
leon-p has joined #zig
craigo has joined #zig
sord937 has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
kenran has quit [Quit: leaving]
cole-h has quit [Ping timeout: 260 seconds]
xackus_ has joined #zig
xackus has quit [Ping timeout: 256 seconds]
zags has joined #zig
gazler_ is now known as gazler
dongcarl has quit [Quit: Ping timeout (120 seconds)]
dongcarl has joined #zig
casaca has quit [Ping timeout: 272 seconds]
gpanders has quit [Remote host closed the connection]
gpanders has joined #zig
gpanders has quit [Remote host closed the connection]
gpanders has joined #zig
marler8997 has quit [Read error: Connection reset by peer]
_whitelogger has joined #zig
geemili has quit [Ping timeout: 260 seconds]
techtirade has quit [Read error: Connection reset by peer]
techtirade has joined #zig
earnestly has joined #zig
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
zags has quit [Ping timeout: 260 seconds]
<johnLate>
sometimes the solution/workaround is so simple... Xlib has function equivalents for (most of?) its macros -> I just needed to use the XDefaultRootWindow function instead of the DefaultRootWindow macro
midgard_ has joined #zig
midgard has quit [Ping timeout: 265 seconds]
xackus_ has quit [Read error: Connection reset by peer]
xackus_ has joined #zig
<ifreund>
... why does the macro exist then
<ifreund>
probably some legacy reason
zags has joined #zig
<johnLate>
ifreund: "The following lists the C language macros, their corresponding function equivalents that are for other language bindings, and what data they both can return.
<shachaf>
The macros are for C, and the other functions are meant for this situation.
<shachaf>
"This file makes full definitions of routines for each macro. We do not expect C programs to use these, but other languages may need them."
<shachaf>
inline wasn't part of C89, and this code is older than 1989 anyway.
<shachaf>
So macros were presumably the reasonable way to do this.
<ifreund>
so "some legacy reason" seems to be right :P
Swahili has joined #zig
nycex has quit [Remote host closed the connection]
nycex has joined #zig
Swahili has quit [Remote host closed the connection]
Snaffu has joined #zig
forgot-password has joined #zig
dreda_ is now known as dreda
<forgot-password>
Did any of you ever write macos-specific code in objective-c and added that to their Zig program? I'd rather not go through the hassle of calling Objective-C APIs from Zig
talin has joined #zig
<talin>
hello. i sometimes read that zig is more like c than rust. any thoughts on why that is? also, which of the problems inherit in c does zig solve?
dyeplexer has joined #zig
<ifreund>
talin: zig is far simpler than Rust which places it closer to C on the complexity scale
<ifreund>
zig's type system is much more powerful than C's and makes writing correct code easier/bugs harder
<ifreund>
zig also allows you to use types as first class values at compile time, which allows generic code without great complexity
<ifreund>
and unlike C, zig has no preprocessor or macros nor any need for them
Swahili has joined #zig
<ed_t>
Unreachable at /tmp/makepkg/zig-git/src/zig/src/stage1/analyze.cpp:7263 in const_values_equal. This is a bug in the Zig compiler.thread 1521449 panic:
<ed_t>
any ideas on what to clean up?
<ifreund>
impossible to say without seeing code
<ed_t>
I am using the git version, guess I will rebuild it
<ed_t>
after removing the inline from the library I get: Unreachable at /tmp/makepkg/zig-git/src/zig/src/stage1/analyze.cpp:7279 in const_values_equal. This is a bug in the Zig compiler.thread 1540976 panic:
<ed_t>
Unable to dump stack trace: debug info stripped
<g-w1>
run zig fmt on the code that has the inline
<g-w1>
it recently changed to a type of calling convention
<ed_t>
zig fmt prim.zig does not complain
<ed_t>
after restoring the inline to prim.zig, building just panics and I do not see the problem in prim.zig
<g-w1>
zig fmt should change the inline to the correct callingconv form
<ed_t>
so just zig fmt prim.zig ?
<g-w1>
with the inline in it
<ed_t>
yes
<g-w1>
so yes
<ed_t>
would a trace back help? If so, let me know what has to change in the build's make files. I am on arch linux so it should not be too hard to do.
ed_t has quit [Quit: Leaving]
<talin>
ifreund: thank you. does it help you avoid memory corruption errors like rust? does it have something similar to a borrow checker? and what about multithreading, does it aid you in enabling "fearless concurrency"? i am a bit disillusioned with rust, which is why i ask. wasted too many years obsessing over language rather than getting stuff done when i worked with C++ in the past
<ifreund>
talin: zig has no borrow checker, its path to safety is largely based on runtime checks for illegal behavior in safe build modes and good tooling. The general purpose allocator from the standard library does double free and leak detection for example
<g-w1>
ed_t a back trace would help although did zig fmt change the inline to callingconv(.Inline)?
<ifreund>
when it comes to threads, zig currently doesn't have any massive advantage over C/C++. Zig's defer certainly makes relasing your locks regardless of control flow easier though
<ifreund>
also "fearless concurrency" is a falsehood IMO, rust's borrow checker/type system only protects against data races
<ifreund>
when it comes to productivity, I feel more productive in Zig than any other low level language I've tried
<ifreund>
(I've written my fair share of C, C++ and Rust)
<ifreund>
zig's also super fast to pick up if you already know C in my experience
<companion_cube>
ifreund: real question: what other kind of races do you have?
dyeplexer has quit [Ping timeout: 260 seconds]
xackus has joined #zig
<companion_cube>
deadlocks I can see, but what other race conditions?
zags has quit [Ping timeout: 265 seconds]
dyeplexer has joined #zig
xackus_ has quit [Ping timeout: 264 seconds]
<ifreund>
anything involving syscalls
<ifreund>
e.g. modify a file
<ifreund>
or send something over the network
<ifreund>
though I do admit that eliminating data races statically is no small feat and one of the best reasons one may want to use rust
<companion_cube>
I mean, yes, it's like types in general, it works within the program
<companion_cube>
(tbh for concurrent modifications of files I'd directly reach for sqlite, posix is a nightmare)
<ifreund>
my point is mostly that the "fearless concurrency" has a big caveat that often gets ignored. You mentioned deadlocks as well, which are very much within the logic of the program and independant from the OS
<companion_cube>
yep
<companion_cube>
I think it's still quite valid when contrasted with threads in C or C++
<companion_cube>
deadlocks when you deal with _multiple_ locks are less common than just forgetting to use a lock to protect something
<companion_cube>
like, you can have bugs, but just starting a few threads to do stuff is now pretty pedestrian, I'd say
<ifreund>
I think the cases in which threads are really necessary are few and far between tbh. Usually they just cause unecessary complexity without significant benefit
ed_t has joined #zig
<companion_cube>
idk, for me it's still the simplest form of concurrency if you're not on erlang/beam
waleee-cl has joined #zig
<fengb>
Arguably, erlang processes are an implementation of the threading model
<fengb>
With less explicit sharing and more message passing, but still
<fengb>
Less implicit*
<companion_cube>
yeah
<companion_cube>
(the only implicit sharing is that of big immutable binary blobs iirc)
<companion_cube>
in a way rust is the same, there's no implicit sharing, and that's why it's safer
nvmd has quit [Ping timeout: 260 seconds]
nvmd has joined #zig
ed_t has quit [Quit: Leaving]
nvmd has quit [Quit: Later nerds.]
cole-h has joined #zig
marler8997 has joined #zig
maier has joined #zig
ed_t has joined #zig
ed_t has quit [Client Quit]
chrismills has joined #zig
maier has quit [Quit: leaving]
zags has joined #zig
zags has quit [Ping timeout: 272 seconds]
zags has joined #zig
ed_t has joined #zig
Akuli has joined #zig
<forgot-password>
Since my question didn't get any answers earlier I figured that I'll just give it another shot: Did anyone here ever incorporate macos-specific objective-c code into their Zig application? And if yes, how did you do it?
chrismills has quit [Quit: Connection closed]
marler8997 has quit [Quit: Leaving]
leon-p has joined #zig
gazler has quit [Remote host closed the connection]
<Swahili>
Q: Multiline string literals in Zig is supported by \\, there's no other way right?
<ifreund>
that's right
<ifreund>
though you can of course do "foo" ++ "bar" ++ "zag" over multiple lines
<ifreund>
but proper multiline strings are cleaner
gazler has joined #zig
<Swahili>
Thanks!
gazler has quit [Remote host closed the connection]
gazler has joined #zig
gazler has quit [Remote host closed the connection]
gazler has joined #zig
blackpawn has quit [Ping timeout: 240 seconds]
<forgot-password>
What's the best way to get a [:0]const u8 from a []const u8 at comptime?
<forgot-password>
Doing `name ++ "\0"` gives me an error
<ifreund>
forgot-password: are you sure name is comptime known?
<ifreund>
oh, \0 isn't a thing, you want "\x00"
jokoon has joined #zig
nvmd has joined #zig
dyeplexer has quit [Remote host closed the connection]
<forgot-password>
ifreund: Ah yes, that fixed it. Thanks! :)
donniewest1 has quit [Ping timeout: 272 seconds]
zags has quit [Ping timeout: 272 seconds]
kwilczynski has quit [Remote host closed the connection]
tracernz has quit [Remote host closed the connection]
procnto has quit [Remote host closed the connection]
r0bby has quit [Remote host closed the connection]
kushalp has quit [Remote host closed the connection]
jbou has joined #zig
donniewest1 has joined #zig
casaca has quit [Ping timeout: 246 seconds]
<ed_t>
I have a fn with the sig: pub fn initRest(self:*Hash, pop:usize) !void {
<ed_t>
I want to call it using: var tNewgrid = try std.Thread.spawn(alive.items.len, newgrid.initRest);
<ed_t>
which fails (not unexpectedly)
<ed_t>
how should I be calling this?
<ed_t>
I want to call it using: var tNewgrid = try std.Thread.spawn(alive.items.len, Hash.initRest); also fails
<ed_t>
opps
<ed_t>
I want to call it using: var tNewgrid = try std.Thread.spawn(.{newgrid, alive.items.len}, Hash.initRest); also fails
<ed_t>
this is related to the panic in the zig compiler mentioned here this morning
jokoon has quit [Quit: Leaving]
forgot-password has quit [Ping timeout: 256 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 265 seconds]
blackpawn has joined #zig
r0bby has joined #zig
kushalp has joined #zig
tracernz has joined #zig
<ifreund>
ed_t: see the doc comment of std.Thread
<ifreund>
startFn must have type fn startFn(@TypeOf(context)) T
Akuli_ has joined #zig
Akuli_ has quit [Remote host closed the connection]
<ed_t>
pub fn spawn(context: anytype, comptime startFn: anytype) from std.Thread
kwilczynski_ has joined #zig
procnto has joined #zig
<ed_t>
what I understand this to mean (I may be wrong), is that context should be the sig of the startFn
<ed_t>
what am I missing/missunderstanding?
kwilczynski_ has quit []
kwilczynski has joined #zig
forgot-password has joined #zig
<ifreund>
startFn() must take exactly 1 argument that is the same as the type of context
<ifreund>
and the return type of startFn() must be as described in the doc comment as well
casaca has joined #zig
<ed_t>
so the answer is I need a wrapper...
<ed_t>
and using tNewgrid = try std.Thread.spawn(alive.items.len, newgrid.initRest); triggers a panic instead of an error
Swahili has quit [Remote host closed the connection]
hnOsmium0001 has joined #zig
zags has joined #zig
geemili has joined #zig
riba has joined #zig
<fengb>
Probably a boundFn bug
<fengb>
Don't pass those around :P
emptee has joined #zig
mikdusan1 has quit [Quit: WeeChat 3.0.1]
emptee has quit [Quit: Konversation terminated!]
tracernz has quit [Remote host closed the connection]
kwilczynski has quit [Remote host closed the connection]
procnto has quit [Remote host closed the connection]
kushalp has quit [Remote host closed the connection]
r0bby has quit [Remote host closed the connection]
Techcable has quit [Ping timeout: 256 seconds]
r0bby has joined #zig
kushalp has joined #zig
viashimo has quit [Disconnected by services]
viashimo has joined #zig
tracernz has joined #zig
<viashimo>
I'm trying to have some code only execute for debug builds. I thought checking `std.builtin.mode == .Debug` would work, but when I compile with -Drelease-fast=true, the code is still executed. what's the correct way - if there is one - to do this?
forgot-password has quit [Ping timeout: 265 seconds]
kwilczynski_ has joined #zig
procnto has joined #zig
<ifreund>
that is the correct way
<ifreund>
and it works fine for me
Akuli has quit [Quit: Leaving]
<viashimo>
hmm, okay. I'm not sure what I've done wrong then. thanks ifreund
<ifreund>
do a quick sanity test with hello world if you like
<ifreund>
zig build should also print out the full command it used
<ifreund>
see if it passes -OReleaseFast properly
<ifreund>
if not then it's a bug in your build.zig
<viashimo>
my build.zig was missing both setTarget and setBuildMode (c.f. helloworld init-exe)
<viashimo>
ifreund: thanks again
<ifreund>
no problem!
<zags>
Tracy on macos is shit, any tried running it in docker?
wootehfoot has joined #zig
dmgk has joined #zig
v0idify has quit [Remote host closed the connection]
v0idify has joined #zig
riba has quit [Ping timeout: 264 seconds]
<v0idify>
will compiling memory usage be reduced on stage2? by ~what magnitude
<ikskuh>
"a lot"
<v0idify>
sounds good
<v0idify>
Welcome to the ZLS configuration wizard! (insert mage emoji here)
<ikskuh>
sweet
<ikskuh>
andrew is currently reworking the parser to use way less memory and wants to replace other parts of the compiler with that technique as well
<ifreund>
stage2 will be way faster and more resource efficient than stage1 yeah
<v0idify>
in all seriousness, that's awesome. probably will test the development experience in a netbook when stage2 is a bit more stable... it doesn't support i686 yet right?
<v0idify>
will it support i686? :|
<ifreund>
it will support everything
<v0idify>
all the things
<v0idify>
right now it's just amd64 and aarch64 right?
<ifreund>
but stage2 is definitely not usable yet, still lots of work to do
<fengb>
i686 = Pentium 4?
<ifreund>
x86 not x86_64
<v0idify>
^ that's what i mean, i read there
zags has quit [Read error: Connection reset by peer]
<v0idify>
there's also i386 and honestly it just confuses me
<fengb>
i386 will be renamed to x86. The default CPU is Pentium 4
<v0idify>
okay
Snaffu has quit [Ping timeout: 272 seconds]
Techcable has joined #zig
<v0idify>
how should i use pkg-config on build.zig
<v0idify>
linkSystemLibrary
<v0idify>
oh, but that's just -l, it doesn't include -I
<ifreund>
it should
<ifreund>
if you're doing something weird you may need addIncludeDir though
wootehfoot has quit [Read error: Connection reset by peer]
<v0idify>
yuup that works
<v0idify>
that's awesome..
<v0idify>
does it use a c lib or does it parse the files directly?
kwilczynski_ is now known as kwilczynski
kwilczynski has quit []
kwilczynski has joined #zig
donniewest1 has quit [Quit: WeeChat 3.0.1]
forgot-password has joined #zig
mikdusan has joined #zig
sord937 has quit [Quit: sord937]
swills_ has quit [Ping timeout: 246 seconds]
swills has joined #zig
geemili has quit [Quit: WeeChat 2.8]
leroycep has joined #zig
<forgot-password>
Is it possible to get a path to the binary itself when my code is lodaded as a shared library?
<forgot-password>
Like std.fs.selfExePath
<andrewrk>
it becomes much less portable for that use case
<forgot-password>
What exactly do you mean? It's only relevant for macOS in thise case
<andrewrk>
ah, I meant if you were targeting more than only macOS you might have issues
<andrewrk>
you want the path to the dylib? I don't think we have support for that in std lib and I have not looked into what implementing that looks like on macOS
<forgot-password>
Alright, I'll look up how to do that on macOS. Thanks for your answer