<pmwhite>
oh, i see...my mind skipped over the threadspawn.
<pmwhite>
that's kind of annyoing...i was hoping to stay single-threaded.
<mikdusan>
the catch is... if you feed/read you either need 1 thread beyond current thread, or async IO
<pixelherodev>
Why can't you just check how much data is available within one thread?
<pixelherodev>
I've run subprocesses and monitored output single threaded before...
<mikdusan>
well I'm assuming spin-checking is to be avoided
<pmwhite>
no, that's fine. I'm planning to check before rendering each frame. I mean, I don't need to have anything until I want to show it to the user.
<pmwhite>
I'm making a terminal emulator by the way.
<pmwhite>
pixelherodev: yeah, that's what I'd like to do. I don't know how to do check how much data is available, though...
benjif has quit [Ping timeout: 244 seconds]
<pmwhite>
hmmm, I think `poll` or `select` can be called to return immediately if no data is available.
<mikdusan>
what if the child is slow?
<fengb>
You beat them?
<mikdusan>
there is that
knebulae has quit [Read error: Connection reset by peer]
<pmwhite>
that's the case I'm worrying about. if the child is slow, then I don't want to block waiting for it to send data, since I have other things to do.
<pmwhite>
if the child is fast, then I could still end waiting, but it wouldn't be as bad i guess.
<pmwhite>
wait, so how do I get the file descriptor from the stdin File? There is a handle field, but I don't know if that is the same. I need the file descriptor to pass to `poll`.
knebulae has joined #zig
<mikdusan>
in the parent, `child.stdout.?.handle`
<pmwhite>
Okay, so the handle is that same as the fd?
<mikdusan>
yup
<mikdusan>
also an old +1 thread workaround if you don't have async IO, is to write feed bytes to a tmp file, open the file for read, pass it as "stdin" to child
<mikdusan>
and by "old" I mean fengb-old
<fengb>
🦖
<daurnimator>
if you have <4096 bytes of data you can shove them in a fifo
<mikdusan>
the pipe is a fifo. if that indeed is the minimum he can just write to it after spawning child
<mikdusan>
or maximum safe. whatever
<pixelherodev>
poll/select should be fine though, right?
_Vi has quit [Ping timeout: 272 seconds]
<mikdusan>
I think that answer depends on how the polling is done. if you're checking for EWOULDBLOCK then a blocking-fd might be an issue. I could be hazy on the actual details. so rtfm
<mikdusan>
s/could be hazy/am hazy/
<daurnimator>
EWOULDBLOCK/EAGAIN is the only way really
<pmwhite>
Nothing beats just trying things.
<demizer>
Hi everyone. I am trying to learn zig by updating libraries on github to zig 0.6. I am having trouble with understanding an error message I am getting when trying to pass a FixedBufferAllocator.allocator to an ArrayList.init(). The error is: ./src/time.zig:875:45: error: expected error union type, found 'std.array_list.AlignedArrayList(u8,null)'
<demizer>
var buf = try std.ArrayList(u8).init(alloc);
<demizer>
I looked at ArrayList.init() code and don't see an error union return type
<tdeo>
you are using `try` on a function that can't fail
<pixelherodev>
demizer, std.ArrayList.init can no longer return an error
<pixelherodev>
The try isn't needed anymore
<demizer>
Ah, thanks a bunch! I've been stuck on this for a day or two.
<pixelherodev>
:)
<daurnimator>
demizer: the error is saying "`try` expects an error union type but got something else"
<demizer>
I was completely looking in the wrong place. :]
<foobles>
what is the best way to generate IR to unwrap a guaranteed non-pointer optional?
<foobles>
with no safety?
<foobles>
i looked at the implementation of ir_render_optional_unwrap_ptr
<foobles>
but that seems to handle a bunch of edge cases im not sure are necessary
<foobles>
and is especially complex because it requires a pointer to the optional for some reason
<mikdusan>
ir_render_optional_unwrap_ptr is not suitable for your needs. roll your own. I can't speak for the pointer question, but start off understanding you'll need a CondBr but the fail_block (meaning null) will instead of gen_safety_crash will just return false in your the codegen compare function I presume you're working in
<foobles>
yep, thats the plan
<foobles>
huh ok, i guess I could just look at what it's doing
<mikdusan>
first "if" is safety check. you'll be doing similar except for the if-null then return a bool;
<mikdusan>
second "if" is dealing with types in zig that have 0-bits
<mikdusan>
and a 0-bit type always has "0" as the value iirc
<mikdusan>
"else" for second "if" handles types with actual info bits; the first sub-if looks to me (I'm not certain) if it's a struct or not (scalar). if a simple scalar the base_ptr already suffices. I believe this would be the case for "?*T" because a pointer itself is the scalar, and the optional is it's zero value;
<mikdusan>
otherwise it's a struct. we represent non-pointer optionals as a 2 field struct. the non-null-bit and the value (sorry cannot recall actual field names, just winging it).
<mikdusan>
so "maybe_null_index" is the field-index into that struct. llvm instruction LLVMBuildStructGEP is going to get a pointer to that field
<foobles>
oh awesome
<foobles>
ok
<mikdusan>
the first use is "maybe_null_index" which is 1
<foobles>
well the zero-bit check can be done inside the rendering function
<foobles>
instead of a runtime check definitely
<foobles>
but the null-check has to be runtime
<mikdusan>
the second use is "maybe_child_index" which is 0. so those correspond to fields [0] and [1] where 0 is the ACTUAL PAYLOAD
<foobles>
aaah ok cool
<foobles>
thats why unwrapping the optional, if its a non-pointer, just returns the pointer back
<foobles>
since the data is first
<mikdusan>
so a sanity check ultimately is when you see .ll from your PR, the basic_block for getting the value is LLVMBuildStructGEP with index 0
<foobles>
what is `.ll`
<mikdusan>
llvm-ir human readable
<foobles>
oh ok cool
<foobles>
thank you so much :)
<mikdusan>
so just as we do --verbose-ir to see zig's IR, use --verbose-llvm-ir to see .ll or, even easier imo, -femit-llvm-ir and it produces .ll file
<foobles>
when running zig build?
<mikdusan>
well to whatever is running `zig build-obj` command.
frett27_ has joined #zig
frett27 has quit [Ping timeout: 260 seconds]
aerona has joined #zig
<andrewrk>
I think SSAT is going to solve all our result location bugs. this coming out squeaky clean. https://clbin.com/kEv3u
<andrewrk>
this is almost certainly worth backporting to stage1
klltkr_ has quit [Ping timeout: 265 seconds]
nephele_ has joined #zig
nephele has quit [Ping timeout: 244 seconds]
nephele_ is now known as nephele
<mikdusan>
anything that simplifies result-location in ir will be huge
<mikdusan>
I see in that zir condbr() and {}! I guess that means cfg intermixed with SSA. I can dig it. I hope that works out.
marijnfs has joined #zig
<mikdusan>
have you fleshed out anything towards uber-passes; allowing arbitrary instruction insertion/deletion including flow control?
joey152 has quit [Remote host closed the connection]
marijnfs_ has quit [Ping timeout: 260 seconds]
<andrewrk>
mikdusan, yeah that's the T part of it (Tree)
<andrewrk>
have not done anything with passes yet
<andrewrk>
my goal is to iterate towards a non-trivial long computation, and do some performance testing and resource usage testing of a long running comptime loop
<andrewrk>
something that activates the comptime garbage collector
<andrewrk>
see if we can get better than CPython perf for equivalent code
<foobles>
how do you create a runtime boolean when generating LLVM IR?
<foobles>
i can't find the function to do it
<foobles>
nevermind, is it render_const_value? :p
<andrewrk>
foobles, that uses the LLVM API to make an llvm const value
<foobles>
oh, hmm
<andrewrk>
based on an already existing ZigValue
<foobles>
aah ok
<andrewrk>
if you want to directly create an llvm bool value, it's actually just an i1
<foobles>
and how would you do that?
<andrewrk>
an i1 is the result of LLVMBuildICmp, or you can truncate a larger int down to an i1, or you can directly create it with LLVMConstInt
<foobles>
LLVMConstInt, ok awesome
<foobles>
thanks; im trying to just insert a boolean known at comptime into a basic block
<andrewrk>
np
<andrewrk>
using the ir builder is fun :)
klltkr_ has joined #zig
<mikdusan>
zir.builder ftw
xackus has joined #zig
xackus_ has quit [Ping timeout: 264 seconds]
<andrewrk>
foobles & mikdusan: this is a good time to pay attention to what's happening with ZIR (right now in the stage2-tests branch). I'm working on getting this to a contributor friendly point as soon as possible, and happy to answer any questions you have about the direction things are headed
<andrewrk>
as well as concerns or other ideas
<foobles>
: )
<foobles>
heh, well i believe you; i see 2 new commits to ZIR from 3 minutes ago :b
<andrewrk>
I predict (and am working to make it a self-fulfilling prophecy) that this will be a fun and meaningful area to contribute to
<andrewrk>
pixelherodev same to you ^ and anyone else who wants to be involved in self-hosted
<daurnimator>
some interesting things in there; e.g. `block` as a keyword: `block { .... }`
klltkr_ has quit [Ping timeout: 260 seconds]
<mikdusan>
one thing I like about inverted blocks is this pattern: `block { if (!comptime) break; if (foo % 2 == 0) break; work(); }` -- it helps avoid ugly formatted multi-line conditionals... and it's short-circuit oriented which reads easier imo
<mikdusan>
for goto fans stuck using structured programming :P
aerona has quit [Remote host closed the connection]
<tdeo>
simplest (and only one i can think of) way is just to make value `?comptime_int`, and guarantee that to always be non-null when returned from @typeInfo
<tdeo>
then if you pass an explicit one to @Type it only works if the error already exists and has that exact value?
<tdeo>
or it could always fail if you pass a non-null value to @Type
<mikdusan>
can you just ignore the in-value of builtin.Error.value ?
<tdeo>
yeah
<tdeo>
i feel like that's still unintuitive but works well, no unwrapping when you use @typeInfo
<mikdusan>
a super-clean interface would be... @Type takes a "builder" variant of builtin.Error ... but is this the only type thus far with such a field? if it is, meh, document it as "no meaning / ignored"
<tdeo>
there's also the problem that EnumField also doesn't let you omit the value... but i don't think it's bad for every user of @Type to manually implement a simple counter
<tdeo>
does zig always start from zero and go up by one if you don't supply an enum value?
<fengb>
daurnimator: shoulda used zig instead :P
<mikdusan>
yeah we're double-purposing a struct for both @typeInfo(), and for @Type()... one could change @Type to take builtin.TypeInfoBuilder, and map every union tag identically, except for ErrorSet and Enum, and have them use new suitable TypeInfo.ErrorSetBuilder and TypeInfo.EnumBuilder types
<mikdusan>
actually, why does it have to take builtin.TypeInfo? why not `(comptime tagname: []const u8, builder: var)` - I presume stage1 is already switching on tagname; this way you expect 2 custom types, don't get it, emit an error
<mikdusan>
today isn't it something like: `var e = builtin.Enum{...}; var T = @Type{.{ .Enum = e });` ... compare to:
<mikdusan>
`var T = @Type( "Enum", e );` (sorry I had bad outer braces in previous @Type())
<mikdusan>
and to be convenient if we're switching.... @Type( .Enum, e )
<tdeo>
i think the simplicity of having a single type is fine unless there's really one that *can't* work with it
<tdeo>
but if there are more problems, yeah, there could be @Type(id: builtin.TypeId, builder: builtin.TypeBuilder) or something
<mikdusan>
small adj. if it's 2 args then sending in a union is redundant
<tdeo>
ah yeah
<mikdusan>
2 args was just a tweak to avoid making a mapping union; the switch _is_ the mapping :)
<mikdusan>
(grain of salt. flying blind here, never looked at @Type impl)
<tdeo>
the union seems fine though, type safety is good
wootehfoot has joined #zig
dputtick has quit [Quit: Connection closed for inactivity]
waleee-cl has quit [Quit: Connection closed for inactivity]
aerona has quit [Quit: Leaving]
foobles has quit [Ping timeout: 240 seconds]
Kingsquee has quit [Read error: Connection reset by peer]
alexnask has quit [Read error: Connection reset by peer]
alexnask has joined #zig
slowtyper has quit [Ping timeout: 246 seconds]
slowtyper has joined #zig
marijnfs1 has joined #zig
marijnfs_ has quit [Ping timeout: 265 seconds]
<Snektron>
yea it turns out bitfield layout isn't defined by the C standard
<tdeo>
well normal struct layout isn't defined either :)
<ikskuh>
tdeo: in C it is
<tdeo>
in the c standard or the abi standard?
<ikskuh>
at least "it's sequential"
<ikskuh>
yes
<ikskuh>
you are allowed to assume that structs that have the same prefix will share these prefixes with the same layout
<ikskuh>
so
<tdeo>
ah, i knew that the pointer to first field is interchangable with the main pointer but not that it's sequential
<ikskuh>
struct Base { int type; int size; };
<ikskuh>
struct Derived { int type; int size; int value; }
<ikskuh>
are compatible for the first two fields
<ifreund>
anyone know why zig is able to translate the glibc version? i don't get it, but my C knowlege also breaks down around this level
<ikskuh>
ifreund: glibc version is actually an ELF feature and has nothing to do with C
<tdeo>
does it still work if you paste the definition you found into a file and translate that? it might be using a different definition for some reason
<ifreund>
ikskuh: wonderful :D
<ikskuh>
ifreund: it allows you to embed several functions with the same symbol name, but different versions in an ELF file
<ifreund>
makes sense
<ifreund>
i guess my only option for a workaround is writing the code that need to use timespec in C and linking that
<ifreund>
i'm already doing this actually to use some other headers that can't be translated
<ifreund>
this one would likely be a good bit more invasive though
<ifreund>
hopefully some awesome person will figure out how to fix #1499 before zig 0.7.0
<tdeo>
well, you could have a header file that, if it detects you're not using glibc (because you can't detect musl), defines the timespec struct and defines __DEFINED_struct_timespec
<tdeo>
then include it before the others
<ifreund>
sounds fun, I'll give that a go later today
<ifreund>
thanks
dddddd has joined #zig
klltkr_ has joined #zig
nephele has quit [Ping timeout: 246 seconds]
metaleap has quit [Quit: Leaving]
<pixelherodev>
How to enhance productivity: `sudo ip netns add no_internet && sudo ip netns exec no_internet su - $USER` :P
waleee-cl has joined #zig
r4pr0n has quit [Quit: r4pr0n]
TheLemonMan has joined #zig
tgschultz has joined #zig
<pmwhite>
so, when I try to use `std.os.execvpe`, the compiler complains that I'm discarding the error if I do `_ = ...`, but it complains that it is expecting an error union type if do `... catch unreachable`.
Nypsie has joined #zig
<pmwhite>
Not sure what it wants from me.
Patrice_ has joined #zig
<TheLemonMan>
money
<TheLemonMan>
keep inserting unmarked bills in the cd drive until it stops complaining
<pmwhite>
how often has that worked for you?
<TheLemonMan>
more than I'd like to admit
<fengb>
It works once eventually
frett27_ has quit [Ping timeout: 260 seconds]
<TheLemonMan>
execvpe returns a single error value, not an error union
<TheLemonMan>
why? who knows!
<TheLemonMan>
oh, I think it's because noreturn!E doesn't work
<pmwhite>
hmmm, now I'm getting a different error: "expected USD, but found monopoly money"
<pmwhite>
yeah, i saw that. what am i supposed to do with a single error value return type?
<pmwhite>
Is that a planned feature?
<TheLemonMan>
well if execvpe returns you have an error, if it doesn't return the child is executing
<tdeo>
assign it to a variable and do nothing with it?
<tdeo>
not sure if that works
<tdeo>
then unreachable;
<TheLemonMan>
you can simply switch on it
<pmwhite>
i think tdeo's suggestion works
<tdeo>
but yeah you should usually handle that failure :)
<TheLemonMan>
yes, it's simple scalar value
<pmwhite>
the code i'm writing is pretty jank right now, so my priority is just to get something working. i'm gonna work on getting a cleaner and more correct version later.
<pmwhite>
i agree
<tdeo>
oh, #3257 is accepted
<tdeo>
i hope enum {} and union {} work when that's implemented
foobles has joined #zig
foobles has quit [Remote host closed the connection]
<pmwhite>
hmmm, neither openpty nor posix_openpt seem to be found the zig compiler. Maybe those aren't included in the shipped libc or something.
metaleap has joined #zig
<pmwhite>
Oh, looks like I need _XOPEN_SOURCE >= 600
<TheLemonMan>
what's the ioctl definition? are you using the C stdlib one?
<pmwhite>
yeah, I'm using the C stdlib one, not one from the zig os layer.
<pixelherodev>
How do you specify floating point precision to std.fmt?
<pixelherodev>
Ah wait, found it
<pixelherodev>
Was looking in the wrong place
<TheLemonMan>
weird, varargs should work, at least I remember printf does work
<TheLemonMan>
grab the definition from the translate-c file
<pixelherodev>
Ahh I see what my issue is; I don't *want* it printed in scientific notation
<pixelherodev>
Probably going to need to just split into two decimal components and print those
<pmwhite>
TheLemonMan: it seems to be working if I pass a pointer in instead of 0
<TheLemonMan>
hmm, try @as(u32, 0) instead of a bare 0
<pmwhite>
I'm calling this multiple times, the first one i solved by just not passing the 0. (I was porting this from something that uses NULL as the last argument, so I don't think I needed that last one.
<alexnask>
pixelherodev, I think {d:.2} the notation for decimal + 2 decimal points
<alexnask>
places*
<pixelherodev>
Wait you can do that??
<pixelherodev>
argh
<ikskuh>
yeah
<ikskuh>
formatting is super-versatile
<ikskuh>
{X:0>8} → hex, large characters, 8 width, fill with 0
<fengb>
It's deceptively flexible. Many of the formatters don't understand options >_>
<pixelherodev>
ikskuh, alexnask, thanks!
<pixelherodev>
saved me ~seven lines of int->float->int,int conversions :)
<alexnask>
:D
cole-h has joined #zig
antaoiseach has joined #zig
layneson has quit [Quit: WeeChat 2.8]
<TheLemonMan>
is any of you on Windows and have git bash installed?
<alexnask>
I have no issues with any other terminals fwiw (cmd.exe and WSL stuff)
r4pr0n has joined #zig
FireFox317 has joined #zig
cole-h has joined #zig
<alexnask>
TheLemonMan, That fixes it yes
<TheLemonMan>
cool, do you mind submitting it? (the value should really be cached as it's an expensive call)
<alexnask>
Sure
antaoiseach has quit [Quit: leaving]
tgschultz has quit [Ping timeout: 240 seconds]
nephele has joined #zig
ifreund has quit [Quit: WeeChat 2.8]
tgschultz has joined #zig
<FireFox317>
andrewrk, regarding the zig self hosted stuff you are working on, is the part where you convert the ir into analyzed ir considered pass1 (src) in the current compiler and the part where you convert the analyzed ir into actual code the pass2 (gen) pass of the current compiler?
<andrewrk>
FireFox317, that corresponds to pass2 in stage1
<andrewrk>
pass1 would be the part where AST turns into ZIR
<TheLemonMan>
so AST -> Semantic analisys -> ZIR ?
<FireFox317>
ah okay yeah that makes sense. Thanks for the clarification :)
Xavi92 has joined #zig
<andrewrk>
TheLemonMan, I think SSAT is going to solve all our result location woes. the code is squeaky clean doing it this way
<FireFox317>
TheLemonMan, i think it is more like: AST -> ZIR (unanalyzed) -> Semantic analysis -> ZIR (analyzed)
<andrewrk>
yes ^
<andrewrk>
the analyzed version has the types and values in memory while the text format has to render types and values to ZIR instructions
johnLate has joined #zig
<andrewrk>
but this time, bothering to maintain parsing to and from the text format allows a new kind of test coverage
<TheLemonMan>
oh so you plan on doing the type-checking on the IR itself?
<andrewrk>
yeah that part I dont see why to make it different than stage1
<andrewrk>
did you have something in mind?
tgschultz has quit [Ping timeout: 256 seconds]
benjif has joined #zig
<TheLemonMan>
well you lose some info about the original AST, if you consider a possible implementation of #952 you really want to work on a `For` node rather than a set of blocks & conditional branches
<andrewrk>
SSAT uses a tree structure rather than basic blocks & phi nodes
<andrewrk>
let me look into how #952 will work
<andrewrk>
we can always reference back to the AST - the information is not lost
<andrewrk>
each instruction corresponds to source ast nodes
<TheLemonMan>
do you have a sketch of what the ZIR for that loop would be?
<andrewrk>
one sec
<TheLemonMan>
oh another request, what do you think of adding a method to check if a type A can be coerced into type B ?
<TheLemonMan>
right now we have to use a ZigType and a ZigValue because we may need to deduce the literal type
<andrewrk>
are we talking about stage1 now?
<TheLemonMan>
but such a function can return an enum such as { Yes, No, DependsOnValue, YesSameMemoryLayout }
<TheLemonMan>
a cooler version of const_cast_only
<andrewrk>
where does that need to get used?
<TheLemonMan>
stage2 of course, changing that in stage1 is useless
<TheLemonMan>
well think of the peer-type resolution
<andrewrk>
ah I see how it could clean that up
<andrewrk>
makes sense to me. I think we should implement all the hard stuff and buggy cases early in stage2
<andrewrk>
so the design can be guided by these cases
<andrewrk>
let me get that example for you
<TheLemonMan>
oh one more thing to keep into account for the ZIR stage, let's move the panic/stack-trace/error codegen in the IR
<andrewrk>
I removed the `%foo = ` part from the instructions which return void/noreturn
<pixelherodev>
repeat() means go back to the beginning of the loop?
<andrewrk>
yes
<pixelherodev>
Neato!
<pixelherodev>
Does the final ZIR have comptime stuff resolved?
<pixelherodev>
Or does that come later in the pipeline?
<Sphax>
Hi. in a project I'm using the C library lz4, which works fine with the native target x86_64, but not with i386-linux-gnu. I'm on fedora and have installed lz4-devel.i686 but seems like that's not enough, what am I missing ?
<Sphax>
to be clear, I get lz4.h file not found
<andrewrk>
pixelherodev, when you process this text format, it gets parsed into untyped, unanalyzed ZIR. then there is a semantic analysis pass, which yes does comptime stuff, and then you can either render to machine code or back to ZIR
<pixelherodev>
Sphax, how are you including the library?
<pixelherodev>
andrewrk, right, but I mean if I'm going to try writing something on top of ZIR
<pixelherodev>
That is, an *alternate* pass
<pixelherodev>
Or an optimization pass
<pixelherodev>
Or so on
<pixelherodev>
Will comptime have already been resolved?
<pixelherodev>
I'll just have to keep improving the pieces I plan on integrating with it later
<pixelherodev>
Sphax, yeah, that won't help
shakesoda has joined #zig
<pixelherodev>
For cross-compilation, it's not a system library as I understand it
<pixelherodev>
See `when cross compiling you will have to specify the paths to the header files and lib files` from slightly up
<FireFox317>
andrewrk, damn that is some complicated ZIR :D especially when you are not used to looking at stuff like LLVM IR etc xd
<Sphax>
alright thanks, I'll try that. I also just realized that by installing the i686 package from fedora it broke the x86_64 build because zig thinks /lib/liblz4.so is the x86_64 lib but it isn't on fedora
<TheLemonMan>
andrewrk, cool, so that issue is solved by running the reachabbility analysis pass after the other simplifications are done
<TheLemonMan>
andrewrk, what about #707 ?
<Sphax>
is that a bug with fedora or with zig ?
return0e has joined #zig
<TheLemonMan>
that's slightly more involved as it's related to type-checking
<andrewrk>
TheLemonMan, for #952, the way I see this working is the while loop cmp instruction will be comptime resolved as `true`. so the condbr flattens out, only the "true block" gets kept. then there are no "merge(break)" calls anymore, so zig knows the code after the "break" label is unreachable
<andrewrk>
you can see there is a conflict here between %x being void or an int, but when the condbr gets flattened, only 1 merge remains so the conflict is gone
<andrewrk>
if the else was needed, the condbr wouldn't get flattened, and there would be a peer type resolution on all the values that merged into the same label
<andrewrk>
to be clear: when I say "condbr being flattened" I mean that the condition is comptime known, so it only analyzes one branch
<marijnfs>
thats a minimal example, does something seem obviously wrong there?
<marijnfs>
i'm using ?*c_void for pointers (void pointers in c)
<hazeycode>
andrewrk so I got an evented io program to compile on macos. Before I continue to make it actually work and not crash hard I just wanted to raise something I have to hack around. For some platforms, (i.e. darwin.zig) fd_t, pid_t and mode_t are translated as c int types, in contrast to linux where they are normal int types, causes problems when
<hazeycode>
later coercing. Is there a recommended way to deal with this? My hack is to for example @intCast(usize, fd) but that just isn't gonna fly
marijnfs has quit [Ping timeout: 260 seconds]
marijnfs has joined #zig
<andrewrk>
hazeycode, @intCast(usize, fd) is good - that's asserting the fd is not -1
<andrewrk>
I think that's appropriate since you are presumably using the "userdata" field of kevent right?
<andrewrk>
I don't see that as a problem
<hazeycode>
that's right, I guess it's not a problem there...
<hazeycode>
what about `.mode = @intCast(c_uint, mode),` in openZ.... which is a shared code path?
<hazeycode>
* Loop.openZ
<andrewrk>
openZ should be using mode_t there instead of c_uint
<andrewrk>
I don't see that
<hazeycode>
before my change is ws .mode = mode
<andrewrk>
it is using mode_t
<hazeycode>
ohhhh, I just need to use mode_t, got it
FireFox317 has quit [Ping timeout: 256 seconds]
<hazeycode>
Thanks for the assistance, I gotta go sleep now, but hopefully I can find time to fix the crash tomorrow. Night
hazeycode has quit [Remote host closed the connection]
<andrewrk>
good luck and night!
pystub has quit [Ping timeout: 258 seconds]
<marijnfs>
ok i found the source of my crazy crash, but i'm still confused
<marijnfs>
I had a exe.linkSystemLibrary("stdc++") in my build script, which in some way screwed up the code the zeromq library was using
<ikskuh>
andrewrk: i found another problem with "deinit(*T)"
<ikskuh>
i cannot deinit a parameter which was passed to me as it is immutable
<andrewrk>
well that makes sense. if it is immutable you should not be able to deinitialize it
<ikskuh>
but how do i pass ownership then?
<andrewrk>
a mutable pointer
<ikskuh>
but this does not transfer storage
<ikskuh>
imagine a function that gets an arraylist to do whatever it does with that arraylist
<ikskuh>
for example, move the array list between two threads via a queue
<ikskuh>
queue.append(my_list);
ur5us has joined #zig
<ikskuh>
if i would have a mutable pointer, i would need to have the list mut again everywhere and the idea of "make const where possible" will quickly lead to "nothing is const anymore except primitive values"
<andrewrk>
if you do `queue.append(my_list)` then it's your `queue` that you will want to be mutable
<ikskuh>
but my_list should not be passed as a pointer, i don't want to pass the reference, but the value
<andrewrk>
ikskuh, if function consume takes a non-pointer parameter, it will not be able to retain the resource longer than the duration of the function call without a copy, in which case you can copy it to mutable memory
<andrewrk>
why not instead case 2 ? it makes sense for consume to take a mutable pointer
<ikskuh>
why? i could set that pointer to undefined?
<ikskuh>
(well, the value it points to)
<andrewrk>
"consume" means "it's mine now and I get to be in charge of what's happening to it" which implies that it wants to be able to mutate the memory
<ikskuh>
hm
<andrewrk>
it makes sense for the caller to need mutable access
<ikskuh>
maybe i think too much in c++-value-semantics
<ikskuh>
but it kinda contradicts my idea of "make const wherever possible"
<andrewrk>
I think wherever possible excludes this case
<ikskuh>
hm
<andrewrk>
use const when it makes sense that a function should not be able to mutate the data under any circumstances
<ikskuh>
i'm not sure which i like more
<ikskuh>
the ability to possibly detect use-after-deinit() (by setting it to undefined)
<ikskuh>
or the non-ability to mutate non-mutable data by accident
<ikskuh>
both are valid optimization goals for the code
<ikskuh>
as the function will not change the bits in Abstract, but will only release some memory in pointers