klltkr_ has quit [Remote host closed the connection]
klltkr_ has joined #zig
<pixelherodev>
Plz no templates kthx
<pixelherodev>
Templates are just godawful
<pixelherodev>
I mean, they're nice in terms of code cleanliness
<pixelherodev>
But compile times are long enough as is :P
<foobles>
maybe they just shouldnt be marked constexpr then
<foobles>
because its never const-evaulated
ur5us has joined #zig
<pixelherodev>
Does it matter?
<foobles>
its just a bit misleading i guess
<foobles>
probably not
<pixelherodev>
Uh
<pixelherodev>
Why do you say it'll never be comptime evaluated?
<pixelherodev>
`since they all require pointers to be called, it will NEVER be evaulated at compile time` [CITATION NEEDED]
<pixelherodev>
`since a constexpr pointer variable must be initialized by an address constant expression, which, by [expr.const]/3, must evaluate to the address of an object with static storage duration, the address of a function, or a null pointer value.`
<foobles>
if a constexpr function is called with runtime parameters it will not be evaluated at comptime
<pixelherodev>
Yes, but comptime pointers are possible
<foobles>
ok i was wrong there
<foobles>
but these pointers are all runtime
<foobles>
all 3 places they are called, they are runtime pointers
<foobles>
to heap objects
<foobles>
but we are only calling this function since it provides an instance of IrInst[src/gen]Id based on the overload
<foobles>
which is purely comptime
<foobles>
so it could be a constexpr function, if it was a template instead
<foobles>
and its already doing overload resolution, so making a template wouldn't change the speed of compilation at all afaik
<pixelherodev>
I don't think there's any situation in which switching to templates *doesn't* impact compilation time :P
<foobles>
if anything, it will be completely negligable
<foobles>
its doing the exact same kind of lookup
<foobles>
and the template wont be generating any code
<foobles>
i mean the optimization is probably being done anyway
mattmurr has quit [Ping timeout: 260 seconds]
mattmurr_ has joined #zig
<pixelherodev>
Anyways, I'mma get back to work
<pixelherodev>
I learned more about c++ than I wanted to know :P
livcd has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
cole-h has joined #zig
<Snektron>
<pixelherodev "I don't think there's any situat"> Its not _that_ bad
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
benjif has quit [Ping timeout: 244 seconds]
joey152 has quit [Remote host closed the connection]
Biolunar has quit [Ping timeout: 252 seconds]
Biolunar has joined #zig
nephele has quit [Read error: Connection reset by peer]
nephele has joined #zig
klltkr_ has quit [Ping timeout: 240 seconds]
nephele_ has joined #zig
nephele has quit [Ping timeout: 260 seconds]
nephele_ is now known as nephele
marijnfs_ has joined #zig
marijnfs has quit [Ping timeout: 244 seconds]
xackus_ has joined #zig
xackus has quit [Ping timeout: 244 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
jrl has quit [Ping timeout: 258 seconds]
<foobles>
is anyone available to talk about generating LLVM ir? I am trying to generate code to unwrap an optional, and I see the logic for doing so actually requires a pointer to an optional
<foobles>
is there an easy way to get an LLVMValueRef that is a pointer to another local value? im learning just by reading the existing code
<foobles>
so i may be way off with even my question
<foobles>
I guess I could just extract the logic of ir_render_ref
<foobles>
but if I use the pointer generated by that, I think that could cause issues with mutating variables when I unwrap it
<foobles>
oh-it looks like unwrapping it if it isnt a pointer just returns the value directly without doing anything? im very confused
dimenus has joined #zig
<dimenus>
pixelherodev: even sway can't compensate for xwayland's blurryness
<dimenus>
the good news is wayland native apps are crystal clear
aerona has joined #zig
<pixelherodev>
Sure, but that's still an x11 issue :P
<dimenus>
and it's only on my scaled monitor that it looks poor
jrl has joined #zig
dimenus has quit [Remote host closed the connection]
<foobles>
any ideas for what i was talking about?
<foobles>
wait never mind, i think i have an idea 8)
aerona has quit [Ping timeout: 260 seconds]
Kingsquee has joined #zig
<tdeo>
now that @Type(.Opaque) and @Type(.Vector) are implemented, should I make a PR to replace all usages of @OpaqueType/@Vector?
<tdeo>
with a possible std.meta.Vector (or std.meta.VectorType to match IntType? i think it should just be std.meta.Int there) because typing out @Type for vector is long
mattmurr_ has quit [Ping timeout: 264 seconds]
mattmurr has joined #zig
jrl has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 240 seconds]
Nypsie has joined #zig
cole-h has quit [Ping timeout: 260 seconds]
metaleap has joined #zig
foobles has quit [Ping timeout: 240 seconds]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen1 has joined #zig
dingenskirchen1 has quit [Client Quit]
dingenskirchen has joined #zig
jrl has joined #zig
jrl has quit [Ping timeout: 264 seconds]
xackus_ has quit [Ping timeout: 264 seconds]
ikskuh has quit [Ping timeout: 260 seconds]
wootehfoot has joined #zig
jrl has joined #zig
mq32 has joined #zig
mq32 has quit [Read error: Connection reset by peer]
<Flaminator>
Is there a reason there is no defer that only runs when a non error is returned? We have errdefer when we return with an error and defer that always runs.
<mq32>
Flaminator: there was no reason to have one yet
<mq32>
because all use cased could be solved with defer then
metaleap has quit [Quit: Leaving]
jrl has quit [Read error: Connection reset by peer]
pilnik_ has quit [Ping timeout: 240 seconds]
Sphax has quit [Read error: Connection reset by peer]
Sphax has joined #zig
Sphax has quit [Client Quit]
Sphax has joined #zig
ur5us has joined #zig
wootehfoot has quit [Ping timeout: 246 seconds]
wootehfoot has joined #zig
Kingsquee has quit [Quit: Konversation terminated!]
wootehfoot has quit [Quit: Leaving]
cren has quit [Ping timeout: 240 seconds]
ur5us has quit [Ping timeout: 244 seconds]
<l1x>
hi folks, is there already a udp socket in zig std lib?
<mq32>
kindaish
<daurnimator>
nope
<mq32>
you can code UDP with the stdlib, but you have to use unix sockets for that
<daurnimator>
mq32: UDP != unix sockets... so that's already a "no"
<l1x>
mq32: do you have a link?
<daurnimator>
but also: there isn't really bindings to udp socket management functions
<l1x>
daurnimator: to be clear i would like to bind to a port and receive UDP datagramms
<daurnimator>
nor is there any facility for message based communications
<mq32>
daurnimator: "unix sockets" as in "berkely socket function API"
<mq32>
not "unix domain sockets"
<l1x>
daurnimator: thanks, i guess it is coming later
<daurnimator>
mq32: most of std.net is based around stream communication
<mq32>
yeah
<daurnimator>
l1x: all that said: we really just need someone interested enough (and with enough time) to implement it all
<mq32>
l1x, give me a second!
<l1x>
mq32: i give your minutes! :)
<l1x>
s/your/you/
<l1x>
daurnimator: i see, what is the scope of this task?
<mq32>
it's not yet complete, TCP client sockets are not supported yet
<mq32>
but you can write TCP servers (and accept clients) as well as write UDP communications with multicast support
<mq32>
IPv6 is stubbed atm
<l1x>
nice!!
<mq32>
it's even documented! :)
<l1x>
i am just trying to port djbdns to a sane language zig or rust because I would like to have more control over my DNS infra and non of the current solutions are what i would like to have.
tritao has quit [Quit: Connection closed for inactivity]
zigazeljko has joined #zig
<alexnask>
mq32, Nice
<alexnask>
This really reminds me I should add docs to my iface impl and publish it
<mq32>
l1x, alexnask: i would love to receive pull requests fixing the still missing parts, i will probably add windows support some time, but this stuff is usually only updated when i need more features
<mq32>
alexnask: yes, please! zig-interface, tag with zig-package on github :)
<zigazeljko>
what's the situation with dynamic linking in zig?
<zigazeljko>
do you need to have the .so/.dll file you want to link against?
<l1x>
daurnimator: thanks
<mq32>
zigazeljko: yes, that's usually the case
<mq32>
but afaik you can also provide a def-file
<zigazeljko>
mq32: why is a separate def file needed?
<zigazeljko>
is it not possible to generate the import section just from library name and function names?
dddddd has joined #zig
bluesunground has joined #zig
<alexnask>
I'm pretty sure you can use the `extern "libname" fn FnName(arg: c_int) c_int` syntax for dynamically linked libraries too
<zigazeljko>
alexnask: i know, but it still requires a def-file
<mq32>
zigazeljko: then a typo will yield valid compiling code ;)
<mq32>
and get you runtime crashes
<mq32>
instead of compile errors
<zigazeljko>
mq32: what runtime crashes?
<zigazeljko>
you mean a missing symbol error on startup?
<ifreund>
i'm hoping there's some way to make things more consistent across platforms with zig's metaprogramming tools, but haven't really dug into those yet
<zigazeljko>
mq32: such wrappers don't work when cross compiling
<tdeo>
not what you're asking, but i actually did a thing with zig metaprogramming and wl_listeners once
<mq32>
zigazeljko: OpenGL works cross-compatible, as the layout of libGL/OpenGL32.lib is defined
<mq32>
but yes, still you have several OSes and you need to ship the libraries you use with them
<mq32>
in order to make sure your program works
<mq32>
"depending on system libraries" does not work well for linux, is required for BSD libc, and on windows you can rely on some GUI stuff being available
<mq32>
but i still don't see why we should give up def files
<mq32>
they make your code more reliable and maintainable
<ifreund>
tdeo: neat, i will save this for when I have the time to wrap wlroots/libwayland
<tdeo>
hm, what do you mean by wrapping?
<tdeo>
it doesn't need you to redefine anything from the headers if that's what you mean
<ifreund>
I mean a thin layer over the libraries providing more idiomatic zig bindings that calling into the c code directly
<ifreund>
s/that/than/
<tdeo>
ah
<ifreund>
i'd mainly want this for libwayland since I plan on writing my future clients in zig
<ifreund>
maybe I'll even make something like smithay's client toolkit eventually
<tdeo>
i'm slowly working on a pure zig wayland implementation but i keep throwing out my progress haha
<ifreund>
oh? i've been considering trying that but would rather spend my time on river right now
<fengb>
Oh how is Wayland? Better than X11 I hope :P
<ifreund>
so much nicer to write code for
<ifreund>
and yeah imo it's objectively better
<tdeo>
wayland is pretty controversial but i like it a lot
<pmwhite>
But it doesn't have network transparency.
<zigazeljko>
mq32: what i was trying to say is: as it is currently, cross-compiling requires additional work (in form of def-files or otherwise) compared to compiling for native platform
<tdeo>
neither does modern x11 :)
<zigazeljko>
with my idea, those two would be the same
<tdeo>
the protocol is *much* simpler to deal with than x11, at least
<tdeo>
i've played around with writing client libraries in a few languages now
<tdeo>
still working on the zig one i mentioned, as well as a small rust one, and i finished a go one but didn't really know how to fit it into go's concurrency model well
<fengb>
It'd be really hard to make anything as bad as X11 :P
zigazeljko has quit [Quit: Leaving]
<fengb>
Hmm, what's the disconnect with Go's concurrency?
<pmwhite>
fengb: the web development world makes stuff as bad as x11 all the time.
<fengb>
I wonder when the web will invent compositing onto canvas directly
<fengb>
I suppose it already did with Flash
<fengb>
But... web pays my bills :P
wootehfoot has joined #zig
<tdeo>
well you create protocol objects and you can send requests/receive events with them, and you usually add a callback(s) to receive the events. if you don't add a listener and then you read events from the connection, you just silently lose them, but that's fine since there's usually a single thread and a main loop
<tdeo>
but i wanted the go one's api to not have a main loop, to just act like a network connection you can send and receive stuff from, so you can use multiple goroutines to do stuff with it and not be tied to one thread (because that's just the natural way to do things in go)
<tdeo>
but then you have a race condition between creating a protocol object and setting its listener
<tdeo>
i could just add that as an argument to the functions that can create an object, hm
<fengb>
Hmm... I typically see things to force itself running on the main loop if there's a need, but that's probably not the Go way
<fengb>
Actually... is there a good UI toolkit that doesn't require the main/UI thread doing specific things?
<fengb>
I admit I'm a mobile/web guy, but Android, iOS, and web all have that limitation
<tdeo>
ifreund: check your issue again :)
<tdeo>
the problem wasn't actually the zig issue you linked, that's for types rather than fields
<pmwhite>
fengb: the limitation is more like enforced good practice, right? Unless I'm misunderstanding your complaint.
<fengb>
It's more that the UI rendering requires coordination and most systems I've seen sorta gives up and tosses all the rendering onto the same thread. I don't think it's necessary but I haven't seen a better solution
<fengb>
I dunno if a different architecture can fix this. Maybe just an inherent concurrency problem
<fengb>
What if there's a field named "unnamed_0"? :P
<tdeo>
there are many more common things a c header can do to break translate-c :)
<tdeo>
mostly macros though
<ifreund>
i love you tdeo
<fengb>
We could make it an illegal C identifier! `@"unnamed_0@"`
<ifreund>
hmm, i guess this means i'll probably move to zig master then
<fengb>
`xxStrikeYouDownxx`
TheLemonMan has joined #zig
cren has joined #zig
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<pixelherodev>
Is there a pattern for deprecation yet?
<mq32>
yeah
<mq32>
first stage: function gets marked as deprecated with a comment
<mq32>
second stage: function gets deleted with @compileError()
<pixelherodev>
Okay but that's not what i meant :P
<pixelherodev>
Idea though
<pixelherodev>
Switch the function to require another argument, a tuple which must have `ack_deprecation = true`
<tdeo>
i feel like the point of deprecating something is to avoid breaking code immediately
xackus_ has joined #zig
<fengb>
Do it the Java way. Leave in a comment indefinitely 🙃
<tdeo>
zig could add a @compileWarning but i think zig is anti-warnings in general
<pixelherodev>
tdeo, the idea of this is to allow code to continue functioning, but to require explicitly acknowledging that you should move away from the function ASAP
<pixelherodev>
The underlying thought process is that if you have to change it *anyways*, you're more likely to fix the problem instead of postponing it forever
<tdeo>
but the person building the code isn't always the one that wrote it, i mean
<tdeo>
imo if you're going to do that just go ahead and do @compileError instead
<fengb>
I wonder if there's a middle ground. Warnings will error if it's a direct consumption, and apply a "this package is bad" warning if it's indirectly included
<pixelherodev>
Or
<pixelherodev>
Check build mode
<pixelherodev>
compileError in debug modes, allow it in release modes
<alexnask>
pls dont touch my @compileError, make your own @debugError or smth :D
<alexnask>
@debugCompileError
mgxm has quit [Remote host closed the connection]
<fengb>
@yourCodeIsBadAndYouShouldFeelBad
mq32 is now known as ikskuh
metaleap has joined #zig
<pixelherodev>
alexnask, I'm not changing anything
<pixelherodev>
I'm thinking of adding a metafunction `deprecated` which uses `std.debug.warn` in release modes and compileError in debug mode
foobles has joined #zig
cole-h has joined #zig
mgxm has joined #zig
<yrashk>
I had a dream of a FreeRTOS-like project in Zig. I wish Xtensa LLVM was more mature -- ESP32 is my primary microcontroller of interest these days!
<fengb>
Once ZIR becomes more stable, you can write your own backend!
gpanders has quit [Ping timeout: 260 seconds]
gpanders has joined #zig
<yrashk>
indeed!
<yrashk>
so, a year or two?
<TheLemonMan>
...if you have the knowledge to write your own backend you're better off helping LLVM finishing their
<pixelherodev>
^
<pixelherodev>
As someone writing a Zig backend, I second that
antaoiseach has joined #zig
<antaoiseach>
Hello, all. I tried using the CMakeLists patch for the macOS Homebrew + LLVM issue, but I'm still running into build issues... anyone else face this?
<antaoiseach>
The first error I face is this: "Scanning dependencies of target zig_cpp
<antaoiseach>
In file included from /Users/z0ltan/software/zig/src/zig_llvm.cpp:23:
<antaoiseach>
[ 76%] Building CXX object CMakeFiles/zig_cpp.dir/src/zig_llvm.cpp.o
<antaoiseach>
/usr/local/opt/llvm/include/llvm/Analysis/TargetLibraryInfo.h:53:10: error: unknown type name 'StringLiteral' static StringLiteral const StandardNames[NumLibFuncs];"
<antaoiseach>
One thing though - I am building from source - the linked Github issue mentions support only for Zig installed from Homebrew. Is that correct?
<antaoiseach>
alexnask: ah, okay... no worries! :-)
<alexnask>
I had the issue with the llvm apt packages myself but compiling llvm+clang+lld myself fixed it (didnt want to patch my cmakelists)
nephele has quit [Ping timeout: 240 seconds]
nephele_ is now known as nephele
<antaoiseach>
alexnask: Hmmmm... yeah, I was thinking of going that way - but my old laptop doesn't have enough space (or grunt to be honest) to build llvm myself :(
<alexnask>
This doesn't seem to be directly related to this bug anyway
<antaoiseach>
Hmmm
<antaoiseach>
It's most frustrating... still, I could revert to an older commit till this thing is sorted out - just feels weird that it was running smoothly so far and now macOS builds are a mess
<fengb>
Unfortunately LLVM 10 introduced a lot of build crud
<antaoiseach>
fengb: yeah... looks like it... irksome!
<TheLemonMan>
the polly problem has been fixed in the git version
<antaoiseach>
I reverted to 6f10e3fda6ca3ef2846c87b149d308fa461fdbb0, but stil won't build with LLVM 10.0.0_3 .. will try 10.0.0 and see
<cren>
Hi everyone. I'm learning Zig. How should I define a program constant; the sort of thing that might be specified with `#define MYCONST 42` in C?
<companion_cube>
`const MYCONST = 42;` should do
<cren>
Ok. That's what I was doing anyway. Just checking. :)
wilsonk has quit [Ping timeout: 256 seconds]
wilsonk has joined #zig
wilsonk has quit [Ping timeout: 246 seconds]
<foobles>
cren don't use screaming case tho ;)
<cren>
Ah yes, I automatically didn't actually, I didn't really register that the constant had its own case
<antaoiseach>
anybody in here ever try Ada? I've been learning it of late, and it's quite fun!
<antaoiseach>
(all this while I wait my llvm brew formula to download -_-)
<cren>
What domain is Ada for? Is it maths?
<antaoiseach>
cren: safety-critical stuff and RTOS etc., embedded, avionics et al.. according to the docs!
<antaoiseach>
It's not terribly verbose (as I was made to understand), and the types are quite strong from what I can tell .. .quite enjoyable actually
<companion_cube>
antaoiseach: seemed super verbose to me when I looked, all the `end foo;` for every single construct :(
<antaoiseach>
companion_cube: Haha... yeah, but doing a decade in Java has made me immune to that level of verbosity :-)
<antaoiseach>
the ada docs at learn.adacore.com are superlative - that is how a tutorial should be written IMO (much like the Rust tutorial was before 1.0, and then it strangely went awry)
<companion_cube>
do you use an IDE?
<antaoiseach>
I was hoping for something similar for the zig stdlib... sadly nothing as yet
<alexnask>
I don't know too much Ada but I love their integer types `type Page_Num is range 1 .. 2_000;
<alexnask>
`
<antaoiseach>
companion_cube: There is an IDE, but I just use the CLI for now... the module system is quite nice and amenable to working on the command line
<antaoiseach>
alexnask: yup, that's brilliant, isnt't it? With very strict type checking as well
<alexnask>
type Byte is mod 256;
<alexnask>
Yeah from what I've seen it has a very good type system
<antaoiseach>
alexnask: the only irksome part so far was the multitude of string types - but the docs are very helpful and easy to work with, so it's been fun so far! well worth a check out imo
<antaoiseach>
As for Zig, I'm done with the core lang from the master docs, and now should hopefully get my hands dirty on some project! :-)
<antaoiseach>
you guys working on something interesting?
<pixelherodev>
Depends who defines "interesting" :P
<antaoiseach>
how're you guys finding working with Zig on real examples though?
<fengb>
Planning on streaming some more in ~10 hours if you're still around
<antaoiseach>
fengb: where?
<fengb>
twitch.tv/fengb
<antaoiseach>
fengb: btw, your post on reddit about pointers in Zig was quite helpful to me... appreciate it
<antaoiseach>
cool.. will check it out. thanks!
<fengb>
np
<fengb>
In general, I think Zig helps expose low level fundamentals, even more so than C
<antaoiseach>
followed... should be edificational and fun
<antaoiseach>
fengb: can you elaborate?
<fengb>
It works amazingly well for freestanding targets, the stdlib has useful general purpose things but the OS integration can be a bit spotty at times
<fengb>
And the language has been changing every other week... so definitely not stable yet
wilsonk has joined #zig
<antaoiseach>
Hmmm... okay, not much experience in low-level stuff so cannot fully appreciate that, but trying to learn :-)
<antaoiseach>
fengb: yeah, I saw some pretty lively discussion on new semantics for `const` the other day (not sure what the conclusion was though)
<fengb>
Oh for low level stuff... things like alignment, sizing, memory padding, etc. They're pretty hidden in C
<antaoiseach>
Ah, yes indeed... just curious - how do these get translated down.. alignment in particular... or are these purely at the type-level?
<antaoiseach>
Does LLVM itself have support for it?
<fengb>
Yeah it does. C has extensions for it but you sorta need to know where to look
<fengb>
I didn't know it existed and I've been dabbling in C for ~15 years now. Never really low level stuff but still
<antaoiseach>
fengb: that makes sense to me ... very interesting indeed!
<antaoiseach>
well, makes me quite excited to get to that kind of stuff eventually!
<fengb>
Also it's got pretty good support for wasm. There's some functionality that's missing, but overall it works nicely and translates code in an understandable way
<fengb>
Rust is probably the closest alternative there but I didn't have the intelligence / patience to learn Rust :P
<fengb>
Admittedly, Rust's wasm toolchain is pretty incredible
<companion_cube>
still dubious about that fengb
<companion_cube>
rust isn't hard to learn if you know how to think about pointer ownership
<fengb>
What, I talk big. I don't actually know a lot :P
<companion_cube>
tss tss
<companion_cube>
rust isn't conceptually hard, for the most part, if you're not trying to do ultra generic code
<companion_cube>
you just have references whose type indicate what stack frame they're valid for, basically
<companion_cube>
and if the reference escapes that frame, compile error
<tdeo>
is there a way to get a ZigFn from a ZigType?
SimonN has quit [Remote host closed the connection]
SimonNa has joined #zig
<tdeo>
actually, that wouldn't make sense
<cren>
Should I be calling `std.io.getStdOut()` more than once per program? I was about to put it in a function...
<pixelherodev>
cren, doesn't matter
<tdeo>
no, call it as many times as you want
<pixelherodev>
It's completely fine
<cren>
No performance penalty? Okay.
<pixelherodev>
Well, no *penalty*, but if you want to improve stdio performance, check out BufferedStreams
<cren>
Cool, alright.
<cren>
While we're here, what does the `try` keyword do?
<pixelherodev>
It's syntax sugar
<cren>
It seems to be something to do with errors and returning? I can't see a chapter for it in the docs
<pixelherodev>
It means `try blob;` == `blob catch |error| { return error; }`
<cren>
Ah
<cren>
That explains quite a lot, thanks
<pixelherodev>
:)
<andrewrk>
cren, getStdOut() (and related functions) are extremely cheap, but have to be function calls because of the way the data is accessed on windows
<andrewrk>
as noted by pixelherodev, the more important performance related concern is making sure you use a buffered stream and don't forget to flush it
<cren>
Okay. I'm just learning, so at this stage I'm more concerned with correctness than optimality. I was thinking about making `const stdout = try std.io.getStdOut()` a global variable, but in trying that I discovered that `try` is not allowed outside of functions
<andrewrk>
the same reason that getStdOut() has to be a function and it can't be a global, is why you can't make it a global. the std lib would have already done that if it was possible
<cren>
That makes sense. Alright.
<andrewrk>
your intuition is correct. it would be nice if it were a global and not a function call
<andrewrk>
if you look at the windows implementation you will see why it cannot be so
antaoiseach has quit [Ping timeout: 244 seconds]
<andrewrk>
also just to be sure, I noticed you are using `try` there. that applies to 0.5.0 but not 0.6.0 and I strongly suggest using the latter and not the former
<cren>
Ah, I was using 0.5.0 because when I started learning 0.6.0 was not released yet (it was released about a week later) and when I last checked my distribution hadn't packaged 0.6 yet
<andrewrk>
it's also quite easy to use a pre-built tarball if your package manager does not have it
antaoiseach has joined #zig
<tdeo>
hmm, can i get a ZigValue function pointer to the function for a ZigValue frame?
<pixelherodev>
Would a std.meta.castable function be useful to anyone other than me?
<pixelherodev>
e.g. `std.meta.castable([]const u8, value)`
<foobles>
like it returns a bool?
<pixelherodev>
Or an optional
<pixelherodev>
e.g. ?T
<pixelherodev>
I think it'd be useful for variable types
<pixelherodev>
e.g. `func("literal");` will pass it as an array
<pixelherodev>
But it *can* be `@as([]const u8)`ed
<pixelherodev>
I mean, it's probably better to just require an @as at the callsite
<antaoiseach>
Phew! Finally managed to build commit 448f8c2eb8335e1c8fc0dd76c3ed728b80487a63 ... I do hope this macOS issue gets resolved somehow
<antaoiseach>
fengb: Hahahah... yeah, Rust is fun, but once you get into lifetime hell, it can be quite a bit irritating
<antaoiseach>
companion_cube: what I particularly like about Rust is the ecosystem - cargo and the module system are extremely usable
<antaoiseach>
By the way, what is the idiomatic way of reading numbers/strings etc. from stdin in Zig? The standard documentation doesn't have any examples of I/O apart from the "Hello, world" example...
joey152 has joined #zig
<companion_cube>
and the enums ♥
<antaoiseach>
companion_cube: that's actually interesting.. though I personally feel Zig's separation of unions and enums made the concept stick better in my mind. Rust's one-in-all enums is certainly very usable though - along with `match`!
<companion_cube>
match is the magic
ifreund has quit [Quit: WeeChat 2.8]
<gonz_>
Does `stb_image` no longer work via zig?
<gonz_>
Seems it's having issues translating functions, ones you'd access even via basic `stbi_load` usage.
<cren>
Is there a printf equivalent in Zig?
<ikskuh>
cren: OutStream.print or std.debug.warn
<cren>
I need stdout so OutStream it is I guess
<ikskuh>
yep
Akuli has joined #zig
<ikskuh>
stream.print("foo: {}", .{ value });
<cren>
thank you
<cren>
:q
cren has quit [Remote host closed the connection]
<antaoiseach>
okay, so I have tried to figure out how to read an i32 looking at std/io/in_stream.zig, but still can't make it work :|
<antaoiseach>
I see a bunch of `read` functions, but something like this does not seem to work: ` const x = try stdin.readInt(i32, builtin.Endian.Big);
<antaoiseach>
`
<antaoiseach>
So how does one read in an i32?
klltkr_ has joined #zig
antaoiseach has quit [Quit: leaving]
<tdeo>
read a line and parse it into an integer
<tdeo>
(unless you really do want to read bytes, like from a binary file)
<tdeo>
readUntilDelimiter '\n' for a single line
Xavi92 has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
return0e has quit [Read error: Connection reset by peer]
<pixelherodev>
Isn't there a readInt convenience function or something?
<fengb>
There’s fmt.parseInt
ifreund has joined #zig
r4pr0n has joined #zig
return0e has joined #zig
ifreund has quit [Quit: WeeChat 2.8]
dputtick has joined #zig
Nypsie has quit [Quit: WeeChat 2.8]
pystub has joined #zig
<foobles>
what is the best way to unwrap an optional when generating IR?
<foobles>
without any checks
<foobles>
and I know that it isn't an optional pointer
<foobles>
should I still get a ref -> ir_render_optional_unwrap_ptr -> deref?
<mikdusan>
when using dot-access it sure would be nice if keywords were not a factor: `@"type": MyType,` and then `instance.type == MyType`
<fengb>
I'd like that very much
<foobles>
yeah same
<foobles>
i still oppose it tho :v
<mikdusan>
wait. duh. it was only my vim color syntax telling me it's bad. this actually works.
<fengb>
It does?
<fengb>
I've been tricked by Vim too!
<mikdusan>
tricked. duped. bamboozled.
<mikdusan>
ah i think because `type` is not a keyword?
<mikdusan>
doesn't work with `foo.for` but `foo.type` yes
<mikdusan>
I'll take it :)
<pixelherodev>
`type` is a `type`, isn't it?
<pixelherodev>
Not a keyword
<fengb>
Hmm that's weird
<pixelherodev>
@TypeOf(type) == type
<pixelherodev>
I think
<mikdusan>
looks pretty consistent. if it's a type (bool, u32, anyerror) then no problem with dot-access
Kingsquee has joined #zig
dirkson has quit [Quit: WeeChat 2.7.1]
<Snektron>
<fengb "We could make it an illegal C id"> then just name it anything starting with E or to
<Snektron>
(officially that is undefined behaviour in C)
<alexnask>
what? seriously?
<Snektron>
According to cppreference, yes
<fengb>
C is an undefined behavior language with some systems programming capability
* ikskuh
has made his CPU emulator wasm-compatible ☺
jmiven has quit [Quit: bye]
<ikskuh>
thanks to fengb for his support with my first wasm steps :)
jmiven has joined #zig
ifreund1 has joined #zig
ifreund1 has quit [Client Quit]
alexnask has quit [Quit: Leaving]
metaleap has quit [Quit: Leaving]
<pmwhite>
I'm a little confused by the ChildProcess API. Does anyone know the proper way to start child process and be able to pass bytes to stdin while receiving bytes from stdout?
<mikdusan>
pmwhite: maybe this will help. warning: old code from a year ago:
<pmwhite>
I think I figured that part out. After creating the ChildProcess, I can call spawnPosix, which should then set the stdin and stdout fields. I didn't understand that it was multiphase.
<pmwhite>
Now I need to figure out how to "read byte if there is one, but don't block if there isn't"
<pmwhite>
mikdusan: ahh, that looks better than what I was thinking, thanks.
<pmwhite>
what happens on `read` call if there are no bytes to read? Is there a way to read all available bytes?