ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
adagio1 has quit [Quit: Leaving.]
btbytes has joined #zig
fjvallarino has joined #zig
isd has quit [Quit: Leaving.]
adagio1 has joined #zig
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
btbytes has joined #zig
tiehuis has quit [Quit: WeeChat 2.1]
btbytes has quit [Client Quit]
mahmudov has quit [Remote host closed the connection]
zolk3ri has quit [Remote host closed the connection]
<andrewrk>
this is the zig equivalent of a go channel
btbytes has joined #zig
alexnask has quit [Ping timeout: 240 seconds]
btbytes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
btbytes has joined #zig
btbytes has quit [Client Quit]
donlzx has joined #zig
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
vegecode has joined #zig
<vegecode>
In the documentation for @import it says that the path is relative to the path of the file that contains the include statement. This could get cumbersome. Is there a way to add a search path for includes? I tried -L<path> but no dice.
JinShil has joined #zig
kristate has quit [Remote host closed the connection]
xtreak has joined #zig
vegecode has quit [Ping timeout: 260 seconds]
xtreak has quit [Remote host closed the connection]
<oats>
I like how tab characters are illegal
<oats>
nice
tiehuis has joined #zig
<tiehuis>
vegecode: use `-isystem` for now for cImports
<tiehuis>
if you mean for zig packages themselves, i believe you want to use pkg-begin to create an alias for a directory
<dbandstra>
i'm getting a weird crash when running `zig build test` and i think if i had a binary i could debug it
<dbandstra>
not really sure though
<andrewrk>
you can use `zig build --verbose` to see the command it runs
<andrewrk>
and then run that directly (perhaps in a debugger)
<andrewrk>
zig build test --verbose
<dbandstra>
hmm ok
<dbandstra>
i guess it's failing at runtime. i got this much info 'Stop reason: signal SIGSEGV: address access protected (fault address: 0x241328)'
<dbandstra>
not sure if there's any more i can get
<dbandstra>
probably copied a struct by value somewhere or something
<andrewrk>
a debugger (gdb on linux, lldb on mac, msvc on windows) should be able to give you a useful stack trace
<dbandstra>
hmm yeah i'm debugging with vscode and lldb
<dbandstra>
i'm wondering what it means when it says the value of a function pointer is "<not available>"
<dbandstra>
does that mean it's null/garbage, or just that it can't print a function pointer
<dbandstra>
(talking to myself)
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
xtreak has joined #zig
xtreak has quit [Read error: No route to host]
jjido has joined #zig
<dbandstra>
will have to come back to it tomorrow
dbandstra has quit [Quit: Leaving]
<andrewrk>
it means the debugger wasn't capable enough to understand the debug info, or the debug info wasn't good enough to describe the value
davr0s has joined #zig
<very-mediocre>
is there an idiomatic preference for streams vs coroutines for iterable data?
<very-mediocre>
i feel byte-at-a-time will be slower as a "generator"/coroutine but multiplexing in languages such as golang offset this greatly
<very-mediocre>
(and of course the input would be buffered)
<andrewrk>
it's hard to make a generalization
<andrewrk>
I have some more experimentation to do with coroutines before I can fully answer that question
<very-mediocre>
okay, i was thinking in terms of language design at least
<very-mediocre>
coroutines are "sexier"
<very-mediocre>
but there's obviously a tradeoff
<very-mediocre>
anyway, I'll toy around with it too
<very-mediocre>
(knowing that coroutines are not yet optimized)
<andrewrk>
I'm testing this Channel abstraction that I made today. It should be pretty useful for concurrency with coroutines
<very-mediocre>
i saw it, looks cool
<very-mediocre>
i was just looking at golang channels yesterday
<very-mediocre>
one nice thing golang has is "select"
<very-mediocre>
which sort of like "load balances" between channels
<very-mediocre>
it's like a switch statement that has a block for different channels
<very-mediocre>
and it enters the block for whichever channel has data ready to be consumed
<very-mediocre>
it feels less deterministic than async/await though
<very-mediocre>
it's more of a listener model.
jjido has quit [Ping timeout: 240 seconds]
<andrewrk>
hmm I should be able to add "select" support in userland
<andrewrk>
I can't think of when I would need it though
<very-mediocre>
when channel bottlenecks vary, and you want to do whatever is ready first
<very-mediocre>
the most obvious example is for a task-worker kind of thing
<very-mediocre>
with different types of workers
<very-mediocre>
say you have MailWorker and NotificationWorker
<very-mediocre>
in node you wouldn't want to do `await MailWorker.get(); await NotificationWorker.get()` in sequence
<very-mediocre>
you'd end up using events
<very-mediocre>
it's a bit boilerplatey
<very-mediocre>
actually I'm doing something like this in one of my node projects
<very-mediocre>
select would've been nicer
<very-mediocre>
don't mean to ramble, so i'll clarify a bit briefly
<very-mediocre>
in the project there's a beanstalkd queue with various jobs being pushed into it
<very-mediocre>
of different types, which need to be handled by different kinds of workers
<very-mediocre>
and the dispatching of work is pretty ugly, it's separate statements for listening to each kind of event
<very-mediocre>
and invoking the correct kind of worker
<very-mediocre>
in golang the entire abstraction of listening to events from a channel is built-in
<very-mediocre>
you just `select` on some channels as if it were a synchronous select, and whichever channel has something enqueued has its block run
<very-mediocre>
sorry if i'm too wordy, I suck at describing these things
<very-mediocre>
tl;dr: in go, listening to channels is implicit, you don't need to explicitly subscribe to events, the channels themselves are also the events
<very-mediocre>
in node you'd either not use async/await at all here (and weave a tangled web of `.then` handlers) or use a combination of explicitly listening to events and `awaiting` results
<very-mediocre>
i re-read that and reaffirm that i am terrible at describing these things, lol
<very-mediocre>
actual tl;dr: in golang you can dispatch centrally which is much nicer than using `.then`
<very-mediocre>
...and also much nicer than dispatching custom events and consuming them
donlzx has quit [Quit: Leaving]
<very-mediocre>
actually andrewrk, how would you handle something like this in zig?
<very-mediocre>
there's no .then
<very-mediocre>
say you want to receive jobs from different queues/channels
<very-mediocre>
you can't `await` them in sequence
<very-mediocre>
and you can't do a .then on each one of them to have its own handler when the job comes in
<andrewrk>
hmmm let me think
<andrewrk>
you do event_loop.onNextTick() on an async function handler for each channel
<andrewrk>
the event loop runs all the async functions, which all await their respective channels
<andrewrk>
and then when the respective channel gets something put in it, it will resolve
<very-mediocre>
ahh, so you're explicitly scheduling it
<andrewrk>
yeah because the event loop is in userland
<very-mediocre>
okay, i see
<very-mediocre>
i'm sure this could be abstracted into a select if needed
<very-mediocre>
also in userland
<andrewrk>
good night
<very-mediocre>
bye
alexnask has joined #zig
JinShil has quit [Read error: Connection reset by peer]
noonien has joined #zig
zolk3ri has joined #zig
very-mediocre has quit [Ping timeout: 260 seconds]
very-mediocre has joined #zig
koomi has left #zig ["WeeChat 1.6"]
jjido has joined #zig
alexnask has quit [Ping timeout: 245 seconds]
vegecode has quit [Ping timeout: 260 seconds]
metaden has joined #zig
<metaden>
hi everyone
<metaden>
New to zig.
very-mediocre has quit [Ping timeout: 260 seconds]
adagio1 has joined #zig
alexnask has joined #zig
adagio1 has quit [Ping timeout: 264 seconds]
adagio1 has joined #zig
Hejsil has joined #zig
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kristate has joined #zig
adagio1 has quit [Quit: Leaving.]
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
<oats>
metaden› me too!
<oats>
kinda neat, isn't it
kristate has joined #zig
adagio1 has joined #zig
fjvallarino has quit [Remote host closed the connection]
fjvallarino has joined #zig
kevw has joined #zig
<kevw>
andrewrk: I was reading the thread local proposal on github (https://github.com/ziglang/zig/issues/924) and I was wondering what you meant by: "For example, thread local buffers cannot be used in a function which is directly or indirectly recursive."
btbytes has joined #zig
davr0s has joined #zig
btbytes has quit [Ping timeout: 264 seconds]
Hejsil has quit [Quit: Page closed]
kristate has quit [Remote host closed the connection]
<metaden>
@intToPtr does not work
<metaden>
*i32 does not exist
<metaden>
oats, ya
<metaden>
docs are not updated to 0.2
<metaden>
for ex:
<metaden>
test "volatile" { // In Zig, loads and stores are assumed to not have side effects. // If a given load or store should have side effects, such as // Memory Mapped Input/Output (MMIO), use `volatile`: const mmio_ptr = @intToPtr(*volatile u8, 0x12345678); // Now loads and stores with mmio_ptr are guaranteed to all happen // and in the same order as in source code. assert(@typeOf(mmio_ptr) == *volatile u8); }
<metaden>
this is correct.
<MajorLag1>
@intToPtr does work. 2.0 is wildly out of date compared to current master. Documentation you quoted is from master.
davr0s has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<MajorLag1>
There are quite a lot. I'm not aware of any single list, most of it is scattered across github issues. Pointer syntax was entirely changed, explicit casting now uses builtins, and @typeInfo was added are the biggest changes I can think of offhand.
jjido has quit [Read error: Connection reset by peer]