<mq32>
andrewrk, have you figured out how to get an image out of the rasperry pi for clashos?
<andrewrk>
mq32, you mean draw an image on the display?
<mq32>
yeah
<andrewrk>
I didn't personally figure it out but I, incredibly, I got a pull request from someone named "markfirmware" and now there is a zig logo displayed
<samtebbs>
I'm gonna be going over some of the oldest issues marked with a milestone of 0.5.0 and seeing if they're still valid or if they've been inadvertently fixed
<fengb>
Just write a bot to auto close old issues :P
<samtebbs>
Hopefully we can get rid of some fixed issues that weren't closed by a PR to make the stats look good
<samtebbs>
fengb: I've actually been thinking of that. Something that will run the code supplied in the issue and see if there are still problems
<samtebbs>
Then auto-close if it's fixed
<andrewrk>
I like to give manual attention to these things
<samtebbs>
You couldn't just close them if they're old since they could still be bugs
<andrewrk>
there is often other important observations besides the test case alone
<samtebbs>
andrewrk: yeah this is a long term project idea of mine
<fengb>
Oh I was joking. A lot of projects closes "stale" issues
<samtebbs>
fengb: Oh right :D Yeah sounds like a bad idea to me
<fengb>
Stale being no recent activity. It's really infuriating
<fengb>
No complaints? Working as intended™
<andrewrk>
I can understand closing "stale" issues that don't have enough information. Other than that, I agree, if it's an open bug with steps to reproduce, wtf?!
<samtebbs>
"We haven't decided to work on fixing this bad bug, hence there's been nop activity, so we're gonna close it!"
laaron- has quit [Remote host closed the connection]
<fengb>
I need a better emoji for sarcasm. :P doesn't cut it
<andrewrk>
thanks for the help with the parser & zig fmt :)
<Tetralux_>
Outstanding.
<Tetralux_>
And welcome o7
<andrewrk>
I think fixing up / improving the semantics of packed structs will be a separate issue
<andrewrk>
I'm not going to mess with that as part of #3115
<kristoff_it>
is there a way to initialize a struct type with the default type for each field that defines it, and undefined for everything else?
<samtebbs>
andrewrk: Do we know if that helps with #2627 ?
<kristoff_it>
*with the default value
<andrewrk>
samtebbs, that's what I'm not messing with yet
<Tetralux_>
kristoff_it +1
<andrewrk>
kristoff_it, you could set the default value of the other fields to undefined
<samtebbs>
andrewrk: I see, I'll hold off with that issue until then
<fengb>
There's a proposal to expose the default value into @typeInfo
<kristoff_it>
andrewrk: makes sense, but it's generic code, so I don't control the struct definition
<andrewrk>
this seems like a good use case for the proposal mentioned by fengb. if it's possible to briefly explain what you're trying to accomplish on that proposal, it would go a long way toward getting it accepted
<andrewrk>
on x86_64 it's just a mov. but it has implications for what the optimizer can and can't do.
darithorn has joined #zig
<Tetralux_>
Wait - x64 loads are always atomic?
<mq32>
Tetralux_, yeah. how do you imagine should the hardware do this? :D
<mq32>
(do it in a non-atomic way)
<Tetralux_>
By naively trying to read a value at the same time as another thread writes it? xD
<mq32>
another "thread" does not exist ;)
<mq32>
you mean "another core"?
<mq32>
there is no "threading" on instruction level
<Tetralux_>
I do mean another core, yeah.
Tetralux_ is now known as Tetralux
<mq32>
they work in "lockstep", so when a core wants to write memory, the CPU has to make sure that you read that value from the caches right
laaron- has quit [Remote host closed the connection]
<Tetralux>
Can another thread not modify the value and invalidate the cache?
<fengb>
There's no half read state for the CPU. That'd be terrible hardware design
<Tetralux>
Or rather, more precisely, is it not the mfence that ensures the cached value is thrown out.
<andrewrk>
atomic instructions are mostly for cache coherence
LargeEpsilon has quit [Ping timeout: 272 seconds]
<Tetralux>
andrewrk: .. meaning that multiple threads will not see the old value after the new value was atomically stored?
<Tetralux>
.. under any circumstances)
<Tetralux>
.. whereas normally each core would read from it's cache.
<Tetralux>
.. and so may not see other's core's writes.
<mq32>
you have to make sure that you actually write your value to the caches, but reading from them is always atomic
<Tetralux>
Or do I have that entirely wrong?
<companion_cube>
I think a core that writes a value will invalidate other cores' cache line on that value
laaron has joined #zig
<Tetralux>
mq32: By, "write your values to the caches", you mean "invalidate the other cores caches"?
<Tetralux>
Only I thought that only happened if you use a fence.
<mq32>
i think we have to consult the intel developer manual on that :D
* Tetralux
grins
<Tetralux>
The shorter version is, what do I do if I want to ensure that no other core will read the old value once a core atomically writes a new value.
Akuli has joined #zig
<andrewrk>
that's not how it works in zig or other languages. in zig there are language semantics, and atomic operations have well defined behavior that work across all supported targets, as well as define what the optimizer may do
<andrewrk>
if you write inline assembly, then you can ask yourself this question. but if you're writing zig it's the wrong question to be asking
<Akuli>
what was the question?
<andrewrk>
<Tetralux> The shorter version is, what do I do if I want to ensure that no other core will read the old value once a core atomically writes a new value.
<Tetralux>
Let me be clearer: If you used @atomicLoad/@atomicStore in Zig, then once the call to atomicStore returns, any other atomicLoad will return the new value.
<Tetralux>
That is the semantics on all OSes, correct?
<Tetralux>
Also, RE asking the wrong question if writing Zig; I disagree - I want to understand the underlying semantics well enough that I can look at the assembly output of Zig and say "Okay - that does <THIS> and looks right to me." - Or the first part, at the very least.
<Tetralux>
But I believe I know what you mean.
<Tetralux>
If you're writing Zig, you shouldn't _need_ to worry about that, because the Zig spec is that it'll JustWork(TM), essentially.
<Tetralux>
*reads the LLVM docs and feels my brain melting*
<Tetralux>
See
<Tetralux>
This is why I hate SeqCst and friends...
<Tetralux>
> In addition to the guarantees of unordered, there is a single total order for modifications by monotonic operations on each address. All modification orders must be compatible with the happens-before order.
<Tetralux>
(That's the first sentence for the description of Monotonic.)
<Tetralux>
It tells me nothing. xD
<fengb>
It's funny that C is simultaneous "barely a language atop assembly" and also "not a low-level language"
<Tetralux>
Not a low level language??
<fengb>
That's what andrewrk's article says
<andrewrk>
I'm planning on having the atomics section of the zig language reference be the best resource on the internet for going from 0 atomics knowledge to understanding the nitty gritty details of memory ordering constraints
<Tetralux>
OH MY GOD PLEASE YES
<fengb>
Oh I just read the article. It just means it doesn't map correctly to modern architectures
<fengb>
Kind of a click-baity headline :/
<Tetralux>
But please for the love of something beautiful, mention in those docs that if you just want to make sure that you don't get torn writes ever, to use <insert memory ordering here.>
<Tetralux>
torn reads or writes*
<Tetralux>
Like, I'm guessing that .SeqCst from what I can guess, but I can't make head or tail of the LLVM docs to be confident of that.
<Tetralux>
.. and that just makes me hate the fact that I have to choose one.
<Tetralux>
Like - part of me would rather just use strong cmpxchg everywhere than having to parse the LLVM docs XD
<Tetralux>
JUST because I'm more confident I know what that does.
<andrewrk>
if you're using atomics, you don't get to not think carefully about it and not be informed about the details. if you can't handle that level, use mutexes
<andrewrk>
don't be summoning demons without your necromancer diploma
<Tetralux>
I feel like if just want to make sure that multiple threads can read/write the same value in a sane way, and that summons demons, you're doing it wrong.
<fengb>
I don’t believe they can sanely write to the same memory
<Tetralux>
fengb: You're saying that atomics cannot sanely write to the same memory?
<fengb>
That’s just asking for demons :P
<Tetralux>
Oh - you're referring to two different values aren't you.
<Tetralux>
xD
<andrewrk>
use mutexes or embrace the knowledge of memory ordering constraints. there is no in between
<Tetralux>
I'd rather use cmpxchg everywhere xD
<fengb>
No I’m saying multiple threads with shared write memory is inherently scary
<Tetralux>
Unless you have bloody good docs.
<mq32>
<andrewrk> don't be summoning demons without your necromancer diploma
<mq32>
true dat
<fengb>
Demons aren't undead :(
<mq32>
i still wonder how people mad the concurrent lockless queue
<mq32>
it's over my head, my world is still singlethreaded
<andrewrk>
I tried to make one for 2 weeks straight and failed
porky11 has joined #zig
<companion_cube>
if you want fun brain puzzles, there's rust' Arc implementation
kristoff_it has quit []
<companion_cube>
with atomic refcounts using acquire/release and comments about why it's safe 😅
LargeEpsilon has joined #zig
<mq32>
does zig already has some kind of channel/concurrent queue structure?
<mq32>
companion_cube, that's a thing where i say: there MUST be comments about that
<mq32>
nobody understands such stuff without the reasoning behind it
<Tetralux>
mq32: I strongly advise avoiding channels.
<Tetralux>
Just my two cents.
<Tetralux>
For speed.
* Tetralux
raises fist into the air
<mq32>
Tetralux: what alternative would you use?
<andrewrk>
mq32, std.atomic.Queue is a blocking thread safe queue. it needs to get renamed but there it is. for Channel we have std.event.Channel, which interacts with async/await
<companion_cube>
this does copy-on-write for an Arc<T>, depending on whether the caller is the unique owner of that ref 🙃
<Tetralux>
mq32: Depends on the app; but generally, avoid the copy and intermediate storing of it if you can.
<Tetralux>
There's something else to that, but I'm blanking on it right now xD
<mq32>
yeah, but it's not *that* easy to synchronize stuff if you have multi-consumer and multi-producer parts
<Tetralux>
Semaphore?
<mq32>
and there's the question again
<mq32>
how to try-get a value from a storage with multiple produces lockless?
<mq32>
(so: busy-waiting until something arrives)
<mq32>
but: got to go for now
<Tetralux>
Maybe even just cmpxchg + semaphore for waiting.
<mq32>
yeah but then you have lockstep synchronization
<Tetralux>
That's what the cmpxchg would do, no?
<mq32>
which means each consumer blocks all other consumers
<mq32>
(when waiting)
<mq32>
laters!
<Tetralux>
More later then!
* Tetralux
waves
porky11 has quit [Ping timeout: 250 seconds]
porky11 has joined #zig
<mikdusan>
andrewrk: if inserting zig-ir during analysis (pass1) should all instr be `ir_mark_gen()` (is_gen=true). and `ir_ref_instruction()` for all added instrs ?
<mikdusan>
(this is in context of hoisting safety checks to llvm-ir -> zig-ir
<andrewrk>
mikdusan, ir_mark_gen just sets is_gen=true. the only thing that does is silence "unreachable code" compile errors when such generated code ends up not being unreachable
<andrewrk>
*ends up getting elided because it is unreachable
laaron has quit [Remote host closed the connection]
<Tetralux>
What should I do if I get linker errors regarding pthread on FreeBSD when attempting to build a zig program?
kristoff_it has joined #zig
<Tetralux>
Thoughtful question: Why _don't_ we have @pause() ?
<Tetralux>
(see __mm_pause)
porky11 has quit [Ping timeout: 264 seconds]
porky11 has joined #zig
<Tetralux>
> What should I do if I get linker errors
<Tetralux>
--library pthread --library c
wootehfoot has joined #zig
LargeEpsilon has quit [Ping timeout: 245 seconds]
<lunamn>
are issues where the compiler crashes but i'm not able to find a reproducible test case other than my entire project.. valid?
<lunamn>
it's likely related to coroutine rewrite (even though i don't use coroutines on the projects)
<Tetralux>
lunamn: I've suffered that problem too.
<Tetralux>
Maybe we need a tool that you can run on your codebase that breaks, that makes a source copy and makes changes to the copy until it's like one or two functions but still breaks xD
<lunamn>
well, at least I have tracebacks and know its something related to IR, but other than that i'm completly clueless
<Tetralux>
Do you import other files into your main file in your project?
<lunamn>
i'm unsure what you mean.. one common caracteristic is that they use other libraries and C headers, would that count?
<Tetralux>
I suspect there's a bug related to importing a struct from another file more than once. In my example, a struct field wasn't getting its type set but was trying to resolve it an was asserting.
<Tetralux>
I wasn't able to narrow it down though.
<Tetralux>
It was a Zig struct though.
<Tetralux>
(non extern)
<Tetralux>
Or possibly a union(enum)?
<Tetralux>
I forget exactly.
<Tetralux>
Oh
<Tetralux>
I used GDB to find where it was crashing.
<lunamn>
the tracebacks were related to unions iirc, i'm building current HEAD to make sure
<Tetralux>
Because the stack trace was just a bunch of ???s
SimonNaa has quit [Ping timeout: 272 seconds]
SimonNaa has joined #zig
<lunamn>
oh huh the traceback mentions the errors happening on llvm, from ir_render_struct_field_ptr
<andrewrk>
lunamn, they're less useful than smaller repros, but I'm willing to have a look at your crash if you make a branch for me and explain steps to reproduce
<lunamn>
gotcha
<andrewrk>
but as you might understand I would prioritize the bugs that already have small test cases
SimonN has joined #zig
SimonNaa has quit [Ping timeout: 244 seconds]
<marler8997_1>
I'd like to use a C library that is installed on the system and has a pkgconfig...zig's build system doesn't already support pkgconfig does it?
<andrewrk>
not yet
<Akuli>
pkg-config support is planned?
<Akuli>
nice
<Tetralux>
Is pkg-config the build system type-thing for Arch?
<marler8997_1>
I'm going to add support for it in my project at least. I can work on a PR for the standard library as well if you like. I was just thinking of adding a function to the Builder object to add pkgconfig libraries
<marler8997_1>
It would just run pkg-config, parse it's output and call the corresponding funcitons on builder
<marler8997_1>
let me know if you have a different design in mind and/or if you'd like me to make a PR for std
<Akuli>
Tetralux, no, it's not specific to any linux distro, it's a thing that figures out c compiler flags and linker flags
<Tetralux>
We talking "these are the best flags for building this program on this system"?
<marler8997_1>
pkgconfig provides a tool that you can use to query for libraries installed on the system. You can ask for C flags or library files for example. To tell pkgconfig about your package, you install a "*.pc" file with all the information about your package.
<andrewrk>
marler8997_1, I think that it would make sense to integrate pkg-config support with linkSystemLibrary
<marler8997_1>
yeah that interface makes sense
<andrewrk>
linkSystemLibrary should try pkg-config if it exists and is available
<Akuli>
Tetralux, i guess you wouldn't want to hard-code things like that into your makefile?
<marler8997_1>
cool I'll work on that
<andrewrk>
marler8997_1, would the api need to be improved? or is just the library name enough?
<marler8997_1>
library name is enough
<marler8997_1>
that's what meson does
<Tetralux>
Akulia, marler, I see. So it's basically a way to say "Hey system! I'd like to link to the system-installed library libfoo. Can you find that for me (and make the flags for the C compiler out of it) ?"
<Akuli>
yeah
<Tetralux>
It seems to me that it would be better to extract out the first part and then just pass on the second part, rather than combining the two, but I guess that makes a little more sense if you want to just have something to make the flags for you.
<Tetralux>
Can pkg-config just print to stdout the paths instead of making them into flags too?
<Akuli>
i don't know, rtfm i guess :D
* Tetralux
grins
<Akuli>
hmm the manual page is kinda messy
<Tetralux>
It seems kinda weird to me that you wouldn't validate that the exact version of the lib you want is what the system actually has.
<Tetralux>
I'm not sure why it wouldn't be more useful to vendor it or something.
<Tetralux>
For reliability's sake, that is.
<Akuli>
you can check it with the c compiler though
<Akuli>
assuming the library defines handy version macros ofc
<Tetralux>
Indeed.
<Tetralux>
Which it prob doesnt xD
<Tetralux>
Or if it does, it ain't consistent or something.
<Tetralux>
Will the zig package manager allow packages to do a similiar thing? "If it's this version, do this, otherwise just do this."
alexander92 has quit [Ping timeout: 258 seconds]
<Tetralux>
Or is the hope that won't be necessary or w/e.
<andrewrk>
so far 2/2 of the false positive "depends on itself" are fixed
<andrewrk>
I'm still looking for more issues
FireFox317 has joined #zig
<FireFox317>
Nice andrewrk! Now its time to close al lot of issues right?
<FireFox317>
s/al/a
<andrewrk>
yes
<Tetralux>
OH
<Tetralux>
I JUST REALISED WHAT THAT SUBSTITUTION THING MEANS
<Tetralux>
It's literally the same as
<Tetralux>
> to close a lot*
<Tetralux>
THE WORLD MAKES SENSE NOW
<andrewrk>
easy on the caps lock please
<Tetralux>
Is that because you're afraid everyone'll start doing it? xD
<fengb>
Man, copying over the std is so much faster
<Tetralux>
fengb: the std?
wootehfoot has quit [Read error: Connection reset by peer]
<fengb>
From making zig
<fengb>
It used to take cmake forever but it's now in zig build
<Tetralux>
Oh yeah I gotcha
<Tetralux>
I appreciated that too xD
<andrewrk>
fengb, that's also building libuserland.a at the same time (or skipping it because it's cached) with perfect cache invalidation detection
<andrewrk>
compile errors just got a bit more chatty, we'll see if it's ok or too annoying
<andrewrk>
now there's always a trace of notes saying why something is getting analyzed. it helps with lazy analysis and with dependency loops
<Akuli>
kinda like in gcc?
<kristoff_it>
I'm trying to import a file from the parent directory
<kristoff_it>
whops sorry I tabbed to the wrong window
<kristoff_it>
and by reflex tried to run the last command haha
<fengb>
I'm guilty of dumping :q into all my windows
tav has quit [Quit: Connection closed for inactivity]
<Tetralux>
kristoff_it: Yeah - do that exactly thing all the time xD
<kristoff_it>
is any of the lazy evaluation work going to help with recursive functions and error set inference breaking with `function 'foo' not fully analyzed yet`?
<andrewrk>
no, I didn't mess with that in this branch
<andrewrk>
although a similar strategy could work to help with that
<Sahnvour>
andrewrk: about this git-bash assuming mingw thing, I'm not sure it is safe to guess the libc to use based on the shell environment that is detected
<andrewrk>
Sahnvour, I think you're right
<kristoff_it>
I see. Well, to be fair at the moment it's almost a feature because points out when I'm doing bad things with the parser, like a recursion that doesn't have a clear comptime-known end
<Sahnvour>
I bet a lot of people use these shells even for native windows stuff, given how windows' console/terminal emulator is ... meh
<andrewrk>
yes, I've done that myself
<andrewrk>
kristoff_it, I plan on implementing safe recursion soon. I realized that it's related to the async/await stuff.
<andrewrk>
and I have a plan that I think is reasonable
<andrewrk>
code can mostly be structured the same. the only difference will be for recursive functions you'll need an allocator and to handle failure
alexander92 has joined #zig
<kristoff_it>
andrewrk: I think I know what you mean, I'm seeing this when writing the parser for the Redis protocol. 99% of the work is about parsing user-provided types that can be composite (like a struct), so I loop over each field and recur. This works perfectly and the errorset gets resolved, but I also have 'DynamicResponse' type for when you don't know the shape of the reply that you're going to get. That type is recursive because it must be abl
<kristoff_it>
e to parse any possible level of nesting, and as such breaks errorset resk,
<kristoff_it>
*resolution
<kristoff_it>
which is somewhat connected to the fact that it needs to allocate frames when doing async/await
<andrewrk>
kristoff_it, the go-to way to resolve the error inference issues, is to create an explicit error set and use it for a given function, to break the cycle. it's pretty straightforward to do, because you can use an empty set, and then the compile errors tell you which ones you're missing
<andrewrk>
it's true that this stuff is all related
juturnas has joined #zig
<andrewrk>
there's also a || operator to merge error sets
<kristoff_it>
andrewrk: yes that's what I did too. I have yet to design how I want errors to look like, for now I'm waiting to get a better idea of how the networking part will have to look like.
<juturnas>
How are you intended to perform an async read from a client socket inside an async server's callback? I've poked around inside the std.event.* code a bit and tried a few things, but no success
<andrewrk>
juturnas, I'm in the middle of redoing all that code. it's leftover from before async/await rewrite
<andrewrk>
the next thing I'm going to try for that API is using std.event.Channel (which also needs to be reworked a little bit) for the connections
<juturnas>
Ah gotcha. I was hoping to port a little HTTP proxy from OCaml to zig using async. Is that feasible on either 0.4 or master at the moment?
<andrewrk>
juturnas, not yet, I recommend waiting until the 0.5.0 release which is scheduled for sept 30
<juturnas>
Ah okay, I'll table this for the time being then. Thanks!
<andrewrk>
it should be quite interesting to play with, we're very close to a big thing here
<juturnas>
Looking forward to it : )
FireFox317 has quit [Ping timeout: 246 seconds]
<andrewrk>
one thing that would help, is getting the normal, blocking http API in the std lib improved
<andrewrk>
because that will mostly be the same API for async; the only difference will be the underlying read/write implementation
<andrewrk>
or rather, networking in general, not even http yet
<juturnas>
I haven't written much zig code yet and I'm not sure I could contribute idiomatic code at this point, and the proxy I'm porting also has a custom HTTP implementation because of its use case (fuzzing). I might start porting it now with sync code, and if I can contribute to the stdlib after getting my feet wet I'd love to
<Tetralux>
I actually went some distance to writing from scratch a thing for sync sockets.
<Tetralux>
It's could use a slimming-pass, but it works.
<Tetralux>
UDP and TCP.
<Tetralux>
Client and server.
<Tetralux>
Only tested on Windows, and that's probably where the slimming pass would help.
<D3zmodos1>
Is there meant to be a difference in the behaviour of command line arguments across windows and linux? I'm getting the name of the executable/command as the first argument on windows but not getting it at all on linux (https://gist.github.com/jacquesh/0eafc5ac84f68488190663554ac571fe). Is that intentional?
<andrewrk>
D3zmodos1, no, that is supposed to be a cross platform abstraction. however , it is possible on linux that the calling process fails to fulfill the convention of giving the executable name as the first arg. what is the calling process in this case? bash?
<andrewrk>
also are you using an old zig version? we had a bug related to this that was fixed
<D3zmodos1>
I'm using zig 0.4.0, and yes its getting run from bash
<andrewrk>
I believe that is fixed in master. next release is sept 30
FireFox317 has quit [Remote host closed the connection]
<THFKA4>
same thing as every team i've been on :|
<Tetralux>
Clearly you've not been on the right teams xD
<Tetralux>
Clearly we need more languages where you can easily write an entire software package by yourself in mere minutes.
<THFKA4>
we even have a nifty buzzword for the process, called "bug bankruptcy"
<THFKA4>
you declare bankruptcy, you see, and shed your technical debt
<bgiannan>
andrewrk, is there a way to force the dark mode of ziglang.org?
<Tetralux>
bgiannan: I did it, so I know you _can_.
<Tetralux>
However I do not now know how I did it XD
<andrewrk>
bgiannan, I use the Dark Website Forcer firefox extension
<bgiannan>
ah thx
<bgiannan>
on macOS it switches because of the OS dark mode but on linux i was stuck
<andrewrk>
I would prefer if firefox would respect the system color scheme preferences, but I lost that battle on the bug tracker
<bgiannan>
not possible on chrome?
<andrewrk>
idk I don't use chrome
<bgiannan>
a little switch somewhere on the page would simplify it
<andrewrk>
I think it's better to make the CSS correct, which it is, and let the software ecosystem fix itself
<Tetralux>
"People that use Javascript have the time to fiddle with stuff like that. I thought they had all they're time taken up by just making the thing remotely workable."
<Tetralux>
like that? *
<marler8997_1>
looks like if I call "linkSystemLibrary("xcb")" it just works right now
<marler8997_1>
not sure why
<andrewrk>
most libraries are as simple as -lxcb
<marler8997_1>
well I'm in a nix-shell so the CC environment variables are set...I didn't think zig would use them but it looks like it does
<andrewrk>
yeah, the point of linkSystemLibrary is to integrate with your system. so here, it makes sense to poke around and detect the system
<marler8997_1>
well since it's working now I don't need pkgconfig right now...so I'm going to hold off on implementing that until I find a need for it
alexander92 has quit [Ping timeout: 248 seconds]
shinzo has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
Akuli has quit [Quit: Leaving]
<juturnas>
BufferedInStream shouldn't block if the underlying stream doesn't, right?
<andrewrk>
it can still block if the buffer is full
<andrewrk>
err, empty, sorry
Ichorio has joined #zig
juturnas has quit [Remote host closed the connection]
<D3zmodos1>
andrewrk: Sorry for the delayed response (I got distracted) but regarding the process arguments differing on windows and linux: Confirmed, after fixing some errors from stdlib changes, I get consistent behaviour across windows and linux when using zig 0.4.0+326b7b79 (the master pre-built binaries on the website)
<andrewrk>
D3zmodos1, good to hear. I'd recommend using that newer version at least until 0.5.0 release
<andrewrk>
zig is getting more stable, but we're still a ways to go before 1.0
juturnas has joined #zig
nrdmn has joined #zig
juturnas has quit [Remote host closed the connection]
juturnas has joined #zig
ky1ko has joined #zig
<juturnas>
andrewrk what would the design goals be for HTTP in the stdlib? Ease of use, correctness, perf, ? Is there a lib in a language at a similar level of abstraction as zig that would be a good reference
<andrewrk>
correctness is primary. I'd start with building the smallest useful abstraction, and then repeat, until the level of abstraction is the desired one
<halosghost>
lwan might be worth looking at
<halosghost>
it definitely has a larger scope than would be wanted in zig's stdlib, but it is a pretty minimal web server in plain C
LargeEpsilon has joined #zig
<companion_cube>
andrewrk: couldn't find why using curl in the stdlib is bad?
<halosghost>
companion_cube: you mean why not to use an external dependency in the stdlib?
<andrewrk>
you're suggesting to ship with curl? that's right out
<halosghost>
yeah, if that's what you're suggesting companion_cube, making a language's stdlib inherently dep on an external project written in a different language is… questionable
<andrewrk>
I think I learned the wrong definition of that phrase from Monty Python. I mean "no we will not ship with curl"
<fengb>
What if we rewrote curl 🤔
<andrewrk>
yeah I mean, that's the idea
<companion_cube>
halosghost: it's the case of almost all languages, isn't it?
<fengb>
zurl
<andrewrk>
what else is std lib networking, but a rewrite of curl
<fengb>
I meant port over all of its quirkiness >_>
<andrewrk>
ah
<companion_cube>
ah, though it'd be socket-level stuff :D
<companion_cube>
thought*
<companion_cube>
curl is much more complicated to replicate
<andrewrk>
the whole point of networking in the std lib is for the package manager, which the main point is to bootstrap dependencies
<andrewrk>
I mean, the whole point of more-than-basic-networking
<THFKA4>
std::ipfs when
<andrewrk>
one of the things zig is bringing to the table is being a reasonably small self contained dependency, that can bring in or build other dependencies
<companion_cube>
do you also plan to reimplement TLS?
<andrewrk>
in addition to declaring package dependencies, there will be a way to declare "fetch dependencies" so that you can get your packages from places that require more involved code such as ipfs or https
<andrewrk>
the recursion has to stop somewhere though
<andrewrk>
we'll start with the stuff that we know needs to be done and continue along those paths until future paths become more clear
<kristoff_it>
andrewrk: yes that's what I did too. I have yet to design how I want errors to look like, for now I'm waiting to get a better idea of how the networking part will have to look like.
<kristoff_it>
jesus sorry I did it again
<fengb>
lol, I tried to follow that chain this time >_>
<halosghost>
companion_cube: not as far as I know
<companion_cube>
so you'd download stuff over http? :s
<halosghost>
companion_cube: any self-hosted language (which should include most systems languages) can't really do that
<halosghost>
companion_cube: I wasn't responding to TLS
<companion_cube>
ah!
<halosghost>
but actually, I think TLS probably doesn't make sense in the stdlib at first
<companion_cube>
I mean, you need a C compiler, right?
<halosghost>
companion_cube: for self-hosting langauges, you only need a different compiler to bootstrap
<halosghost>
Zig is not quite entirely self-hosting yet (that, I believe, is what andrewrk refers to as “stage 2”)
<juturnas>
Probably easier to use HTTP with package signatures of some kind, rather than pulling something gnarly like TLS in, I'd think
<andrewrk>
companion_cube, insecure connections for packages are reasonable given that all dependencies are secured with a cryptographic hash. this is "Trust On First Use"
<companion_cube>
it just sounds to me like, if there's a dep on clang that is to remain, curl isn't that big
<companion_cube>
yeah, using a good hash, ok
<halosghost>
companion_cube: there are plans to allow other backends iirc
<andrewrk>
but yeah I could definitely see a zig curl package being a pretty useful package early on in the ecosystem
<andrewrk>
especially as you noted, zig can build curl from source
<halosghost>
plus, before TLS is in the stdlib (if it ever happens), a TLS-terminating proxy server (à la hitch) might be pretty easy to build in Zig
<halosghost>
that could be a reasonable non-stdlib package
<companion_cube>
so to bootstrap you'd just need to know enough http to download a few archives, check their checksum, and then use curl for the package manager?
<andrewrk>
that's what it will likely look like, early on, for https dependencies
<companion_cube>
ok that makes sense indeed
halosghost has quit [Quit: WeeChat 2.5]
<andrewrk>
that doesn't address certificate authorities though
<andrewrk>
I need to brush up on how that works, but if those expire on a relatively short basis, that's probably a "system dependency"
<andrewrk>
which in this case, is pretty reasonable I think.
<THFKA4>
they don't. the OSes used to ship with a list of trusted CAs, but these days the browsers have their own lists
<THFKA4>
you could depend on the system's CAs still
juturnas has quit [Ping timeout: 260 seconds]
<THFKA4>
nixpkgs.cacert is probably on your system right now
juturnas has quit [Remote host closed the connection]
juturnas has joined #zig
<juturnas>
So with `BufferedInStreamCustom` with default buffer size (`mem.page_size`), read is blocking. With buffer_size of 128, it behaves normally, and buffer_size of 64 I'm hitting `EBADF => unreachable, // Always a race condition.` in os.zig. Before I sink time into debugging this, is there a chance this is working as intended and I misunderstood the
<juturnas>
interface, or does this sound like invalid behavior?
<andrewrk>
hmm is something getting closed too early?
<juturnas>
Let me reduce it and I'll paste it here