<daurnimator>
uh that was meant to be @ TheLemonMan, but they left
hio has quit [Quit: Connection closed for inactivity]
<scientes>
is there a way to query if run-time safety is on?
<scientes>
I guess i just have to use "unreachable"
<scientes>
that will do it
redj has quit [Read error: Connection reset by peer]
<daurnimator>
scientes: (I assume) unreachable is also a hint to the optimizer... that doesn't sound like a good way to check...
<scientes>
daurnimator, its actually how assert() is implemented
<scientes>
daurnimator, in debug mode unreachable is reachable, and results in a panic
<daurnimator>
scientes: yes. and in release mode; it assumes that the assert passes; and optimizes code based on that assumption..
<scientes>
that is exactly what i want
<scientes>
i'm just using it for a sanity check
<scientes>
but i can't use assert because it is more complicated
<scientes>
or rather don't want to
voldyman has quit [Quit: Connection closed for inactivity]
ltriant has joined #zig
<scientes>
why can't i use enum literals with @typeID()?
<scientes>
/home/shawn/git/zig/std/math/average.zig:9:24: error: incompatible types: 'builtin.TypeId' and '(enum literal)'
<companion_cube>
hmm so one can use anonymous structs (say, in unions) but it seems impossible to initialize them
<companion_cube>
like `TheUnion {.Foo = <how to name the struct here?> }`
redj has joined #zig
redj has quit [Client Quit]
<hryx>
companion_cube: const x = struct{a: u8}{.a = 24};
redj has joined #zig
<companion_cube>
so I'd have to repeat the type def? better name it
<daurnimator>
companion_cube: or via a complex @typeInfo(TheUnion) expression....
<companion_cube>
yeah, doesn't seem very convenient
<companion_cube>
(ok, the stdlib could use some docs :D I guess it's only 0.4 though)
<daurnimator>
companion_cube: doc comments are welcome in PRs. actually generating docs for them is waiting for stage 2.
<companion_cube>
I'm looking at the source
<daurnimator>
andrewrk: I think #2400 should just be closed?
<companion_cube>
can't really find how to write to a File :D
<companion_cube>
(or rather, how to have a print function taking a std.io.OutStream and using it on stdout)
<daurnimator>
companion_cube: you want to write the print function?
<daurnimator>
or you want to call it?
<companion_cube>
to write it, it just takes an outstream, right?
<companion_cube>
not sure if I can be that generic though
shritesh has joined #zig
<daurnimator>
companion_cube: take a look at std.fmt for the signature of output functions....
<daurnimator>
companion_cube: also note that if you give your struct a member 'format', then std.fmt will use it when it prints your object
<daurnimator>
s/member/method/
<companion_cube>
ah. interesting
<companion_cube>
does it comptime-introspects the struct to find that?
<companion_cube>
ok so the idea is that there's no generic way of printing to something, except by taking a full closure
<companion_cube>
I find it a bit sad that the syntax uses `if (foo) bar` instead of `if foo { bar }` :/
<companion_cube>
(the second is not longer and avoids the goto fail kind of error)
<hryx>
companion_cube: true, but the goto fail thing won't happen as long as you zig fmt on save. which everyone should!
<hryx>
and without that syntax you wouldn't be able to do some of the nice expression-based assignment zig allows
<companion_cube>
what do you mean?
<hryx>
const x = if (a) 1 else 2;
<companion_cube>
if a { 1 } else { 2 }
<hryx>
you could do it with curlies but you'd need a blk: in there
<companion_cube>
yeah well that's really the decision that irks me, tbh
shritesh has quit [Read error: Connection reset by peer]
<hryx>
Originally I thought the ability to assign from expressions with branches like that was just cosmetic, but I've recently learned that there is a remarkable side effect of that feature
<daurnimator>
yes! I had several huge issues with it in a coffeescript codebase I once worked with
<hryx>
it results in you being able to assign almost everything to `const`
<daurnimator>
also it means things often escape scope
<daurnimator>
also if you take it through to the conclusion: what do for loops return? the usual answer is a collection of all the last things in the block: tada: implicit allocations
<hryx>
yeah but zig doesn't do that
<hryx>
probably for that very reason
<daurnimator>
yes I know. but I'm saying what would happen if you took companion_cube's proposal to the 'endgame'
<companion_cube>
why would you implicitly allocate?
<daurnimator>
ky0ko: ps, don't commit the zig-cache directory: add it to .gitignore
<ky0ko>
yeah, that's in the .gitignore in the real project, this was just a quick example copied out from it
<ky0ko>
that seems to have done the trick, thanks a bunch!
jjido has joined #zig
dbandstra has quit [Quit: Leaving]
hio has joined #zig
<hryx>
Before I get to profiling, I want to get CI passing, but after a minor change to the parser error handling, I'm running up against a panic in the IR analyze phase
<hryx>
the line that fails is ir.cpp:21097 - `assert(start_value->value.type->id == ZigTypeIdErrorSet);`
ky0ko has quit [Ping timeout: 264 seconds]
ltriant has quit [Quit: leaving]
<hryx>
Oh, I think I have a clue. It looks like it has to do with switching on an error type. I'll see if I can work around it then create a minimal case for an issue
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Ichorio has joined #zig
IntoxicatedHippo has joined #zig
<IntoxicatedHippo>
Is there a way to pass arguments to lld from build.zig?
scientes has quit [Ping timeout: 244 seconds]
Ichorio has quit [Ping timeout: 244 seconds]
_whitelogger has joined #zig
very-mediocre has joined #zig
IntoxicatedHippo has quit [Ping timeout: 244 seconds]
hio has quit [Quit: Connection closed for inactivity]
<SamTebbs33>
Thanks andrewrk, I'll take a look at it. I'm planning on porting my Zig kernel to aarch64 and arm sometime in the future so that should reveal some holes (it being freestanding may limit that though)
<SamTebbs33>
TheLemonMan, do you have a link to that patchset handy?
SamTebbs33 has left #zig [#zig]
SamTebbs33 has joined #zig
scientes has joined #zig
Sahnvour has joined #zig
halosghost has joined #zig
Xe has quit [Quit: WeeChat 1.9.1]
<tgschultz>
bug that took me a while to work out: Zig never passes a copy, so passing a struct that is actually a pointer through a type erased Fn to a function that expects a pointer actually gets a pointer to the pointer. That's what I get for trying to trick the type system I guess.
<SamTebbs33>
Understanding that takes some mental gymnastics :D
<SamTebbs33>
Is the general practice to assign an issue to the person who's going to tackle it? If not then I suggest that be the procedure as that means people don't have to duplicate work or ask "Is anyone working on this?"
kristoff_it has joined #zig
<kristoff_it>
hi all, one question: I'm trying to use a C variadic function from Zig. Compilation succeeds but I get a segfault at runtime. I tried to troubleshoot it a little but the code works except for the line where I call the variadic function. Is this something that is not fully supported yet?
<tgschultz>
IIRC calling C w/ varargs works, but it has been a long time so I'm not actually sure. Are you sure the extern is declared with the correct calling convention?
IntoxicatedHippo has joined #zig
IntoxicatedHippo has quit [Client Quit]
<kristoff_it>
the function type is produced by the automated header file translation and is as follows: extern fn(?*RedisModuleCtx, [*c]const u8, [*c]const u8, ...) ?*RedisModuleCallReply
<kristoff_it>
all the the types mentioned are opaque
<kristoff_it>
btw, to give more context: i'm writing a module for Redis, so I'm using the headerfile provided by Redis, compiling a shared object file, and loading it. it works, except when I call that function, which causes the server to segfault
<mikdusan>
kristoff_it: zig can call c vararg functions. i've used printf with no trouble.
<kristoff_it>
ok thanks, then I'll investigate more other possibilities
<mikdusan>
are you sending any strings from zig to c ?
<mikdusan>
make sure they're null terminated. zig literal strings currently are not nullz and use explicit syntax `c"hello world"` for that.
<tgschultz>
that does sound more likely than my calling convention hypothesis
<mikdusan>
kristoff_it: and i'm not sure if there is a better way but for runtime strings std.Buffer can be used as it maintains nullz for all its contents. Buffer.init(....); buf.toSliceConst();
scientes has quit [Remote host closed the connection]
scientes has joined #zig
scientes has quit [Remote host closed the connection]
scientes has joined #zig
scientes has quit [Remote host closed the connection]
<tgschultz>
andrewrk: I think I might take antoher crack at #1848 (Interface Reform) with a new, slightly different, pattern that's closer to what Hejsil describes in #1829 and will hopefully also take care of the things I originally ran into on the first pass that made me uncomfortable.
<andrewrk>
tgschultz, sounds good to me
scientes has joined #zig
scientes has quit [Remote host closed the connection]
return0e_ has quit [Remote host closed the connection]
<tgschultz>
on another note, does anyone else wonder if separating the stdlib into 'stuff that only requires the language' and 'stuff that requires OS support' makes any sense?
<andrewrk>
SamTebbs33, the only one here who has a reliable amount of hours per week to spend on zig is me, so using GitHub issue assignments is kind of broken. everything is fair game until it lands in master branch. and even then it's still fair game, and can be improved upon
<andrewrk>
what I mean by that is that assigning an issue to a volunteer is not really how it works, people are donating their time as they see fit and make no promises. so yeah it's a bit messy and sometimes toes get stepped on
<andrewrk>
overall I think it works fine. we can re-evaluate if the zig community becomes 10x bigger
<andrewrk>
kristoff_it, one thing to check, are your strings properly null terminated?
<andrewrk>
we don't have type system protection for detecting that problem yet
<kristoff_it>
thanks all for your suggetions, as it always happens, guess what, it was my fault, something completely unrelated
meheleventyone has joined #zig
<kristoff_it>
andrewrk: there is though a real problem with the automated header file translation, some of it is probably about unsafe code in the original redismodule.h file, but Zig 0.4.0 introduced new problems. Is it ok if I open an issue about it?
<andrewrk>
kristoff_it, yes please do
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Sahnvour>
tgschultz, makes sense to me, do you see it as a stdlib implementation detail (ie. putting source files into 'freestanding' part and 'os-enabled' part) and/or as a user-facing dichotomy (via namespaces or whatever) ?
Ichorio has joined #zig
<tgschultz>
both I guess? From an implementer standpoint it would be nice to know precisely which things I have to implement and from a user standpoint I want to know what isn't going to be available in freestanding.
<tgschultz>
I think it could be accomplished by moving stome parts of standard under os. std.os.heap would have DirectAllocator, for instance, and std.heap's other allocators would move to std.mem, std.heap, or std.mem.heap or something.
<andrewrk>
kristoff_it, I think there are just a couple small issues left, until @cImport is really streamlined
<andrewrk>
tgschultz, I do like having the stuff that depends on an OS namespaced under std.os
<Sahnvour>
I think that's a good idea, it would probably be clearer where to find things, and what to expect
avoidr has joined #zig
jjido has joined #zig
wootehfoot has joined #zig
avoidr has quit [Quit: leaving]
avoidr has joined #zig
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mikdusan>
tgschultz: the more i think about it the more i like idea move os-adapters out of `std`; the posix abstraction falls into the category of os-adapter just a more abstract one than linux.
hio has joined #zig
ky0ko has joined #zig
Sahnvour has quit [Read error: Connection reset by peer]
<andrewrk>
I'd rather keep it to only 1 standard library
<andrewrk>
but open to reevaluating that question during the std lib audit and once we have a package manager
Zaab1t has joined #zig
<tgschultz>
I think it could be accomplished by moving stome parts of standard under os. std.os.heap would have DirectAllocator, for instance, and std.heap's other allocators would move to std.mem, std.heap, or std.mem.heap or something.
<tgschultz>
ignore that
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tgschultz>
up + enter in wrong window
<tgschultz>
why is that even a thing in an irc client?
<very-mediocre>
tgschultz: still a huge fan of #1669
<very-mediocre>
was reading it again and it's just awesome
kristoff_it has quit [Ping timeout: 256 seconds]
jjido has joined #zig
<hryx>
I really like #1669 too
<very-mediocre>
a lot of languages shoehorn in a similar (but more limited) kind of functionality in the form of decorators, which i hate
<very-mediocre>
1669 feels like the right way
<tgschultz>
thanks. occassionally my crazy ideas happen to be good ideas. this is merely coincidence.
<very-mediocre>
I remember the conversation when you came up with it, that was pretty productive
scientes has joined #zig
<hryx>
tgschultz: up & enter in an IRC client is spooky dangerous :<
<tgschultz>
I'm still trying to work out how to turn it off
<tgschultz>
ah, there it is: max editbox history: 0.
<torque>
any reasonable irc client constrains history on a per-channel basis so at worst you will be resending messages
<donpdonp>
pub fn has(key: []u8) bool {}; has("key") => expected type '[]u8', found '[4]u8'
<donpdonp>
whats the right way to pass the string?
<donpdonp>
ah its has(key: []const u8)
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Zaab1t has quit [Quit: bye bye friends]
wilsonk has joined #zig
<tgschultz>
donpdonp yeah, arrays do not implicitly cast to slices, but they do implicitly cast to immutable slices
nicolasman has quit [Ping timeout: 250 seconds]
ky0ko has quit [Disconnected by services]
nicolasman has joined #zig
ky0ko has joined #zig
<tgschultz>
if you needed it mutable: has(&"key") or has("key"[0..]) should work
dembones has quit [Ping timeout: 250 seconds]
<tgschultz>
though... actually because they're literals they wouldn't really be mutable
dembones has joined #zig
redj has quit [Ping timeout: 250 seconds]
wilsonk|2 has quit [Ping timeout: 250 seconds]
<donpdonp>
nod. whats zig doing for string compare these days
<andrewrk>
zig doesn't have strings
<donpdonp>
i was waiting to hear that :). okay. is there a simple byte-wise compare for var str:[]u8 and "value"?
<andrewrk>
you can compare bytes with std.mem.eql, and thanks to UTF-8 this will suffice for encoded strings
<donpdonp>
ah.
<andrewrk>
recommended parameter name for that is bytes: []u8
<donpdonp>
nod. thx!
ky0ko has quit [Remote host closed the connection]
<donpdonp>
im using pthreads and gtk+3 and its been great working with zig's c-interop.
<andrewrk>
glad to hear it. I decided to do some more work on that today
cameris has joined #zig
<tgschultz>
andrewrk: is it allowing comparison of [*c] and null? because that made me abandon plans to convert win32 bindings to use [*c].
<andrewrk>
yeah I just pushed that
<tgschultz>
sweet
<andrewrk>
if you make bindings then you shouldn't need [*c]
<andrewrk>
[*c] is exclusively for auto-generated bindings
<andrewrk>
if you found a use case for [*c] that isn't auto-generated bindings, that's a design flaw in the language that needs to be fixed
<andrewrk>
I'm considering making the syntax for [*c] worse so that people stop thinking they should use it
<tgschultz>
the bindings were autogenerated, I was just going to update them so they were easier to work with. Casting to `*Type` to `?*Type` because a function takes `?*?*Type` is annoying.
<andrewrk>
tgschultz, that makes sense. with null terminated pointers that would be `?*[*]null Type` and you wouldn't need the cast
<andrewrk>
if it's really a `?*?*Type` it's still better to go through the type system. not doing that takes away zig's understanding of what's going on, and the compiler can do less things on your behalf, such as safety and optimizations
<andrewrk>
EBADF is essentially use-after-free for file descriptors
jjido has joined #zig
<andrewrk>
once a file descriptor is closed, the same number can get used again with open()
<scientes>
double-free (double-close) is also a bug
<scientes>
for the same reasons
<scientes>
and re-use is also quite likely, because the lowest available fd is always used
<cameris>
andrewrk, yes, have seen that. just thought race condition is/meant something different.
<cameris>
something like described in fcntl(2) for FD_CLOEXEC.
<tgschultz>
andrewrk: it's almost always just **Type, but because c all pointers are nulable. The annoying thing is that `&thing` where `@typeOf(thing) == *Type` is `**Type`, which will cast to `?**Type` but not `?*?*Type`.
<andrewrk>
tgschultz, isn't the correct thing to do here to make var thing: ?Thing = null; foo(&thing);
<andrewrk>
sorry, var thing: ?*Thing = null;
<andrewrk>
otherwise, ?*?*Thing is incorrect and it should be ?**Thing
<tgschultz>
...yeah, I suppose that's more succinct. I've gotten so used to inferring the type I sorta forgot I could just specify it.
<andrewrk>
cameris, it's a race condition because the standard library - and by default convention all zig libraries - are meant to exist in a potentially multi threaded environment
<andrewrk>
so if one thread gets EBADF, then that means based on another thread's actions, that EBADF could have actually been a "success" but did the wrong action
Ichorio has quit [Ping timeout: 248 seconds]
<cameris>
ah, with this assumptions that makes sense. I was locked into somthing like https://pastebin.com/S79ZZ4pD and could not understand where this can be a race condition. thx for taking the time and helping me understand. also to scientes.
halosghost has quit [Quit: WeeChat 2.4]
ky0ko has joined #zig
Sahnvour has joined #zig
Ichorio has joined #zig
<Sahnvour>
andrewrk, how's posix behaving DirectAllocator regarding thread safety ? My understanding is that there's currently no particular effort towards making it thread-safe.
<andrewrk>
master branch DirectAllocator is in fact thread safe
<Sahnvour>
how does it achieve this?
<andrewrk>
on posix it doesn't have any state
<andrewrk>
on windows it uses atomic operations to make the first allocation grab the heap handle
<Sahnvour>
meaning we are relying on the eventual internal synchronisation from the posix API?
<andrewrk>
I'm not sure what you're asking - DirectAllocator directly uses the mmap/munmap API, which is thread-safe
<Sahnvour>
that's my point; it may occur that DirectAllocatr makes several calls to mmap/munmap during the same realloc/shrink call; does this handle multi-thread correctly if for example several threads are allocating through it at the same time, interleaving m[un]map calls?
<Sahnvour>
I'm asking because of the comment of emekoi on #2249, where I assumed there was nothing special already done about thread safety (given that DirectAllocator has no state in zig user side)
<andrewrk>
it does handle multi-threading correctly - most calls map exactly to 1 mmap/munmap. the edge case is for a very large alignment, in which case it overallocates with mmap and then munmaps the extra stuff, which is thread safe
<Sahnvour>
I see
<Sahnvour>
I think the windows version I wrote might need a small lock then ... disappointing
<Sahnvour>
but probably only in the case where we request an alignment greater than page_size
<andrewrk>
Sahnvour, if it comes down to that, we can have 2 versions: ThreadSafeDirectAllocator and SingleThreadedDirectAllocator. on posix systems they'll be identical. on --single-threaded builds they'll be identical. on multi-threaded windows builds it would do something
<Sahnvour>
that's an option, I'll think about it in the next days and try to find examples of what we want to do
<hryx>
andrewrk: I watched your kcachegrind video, thanks for the tips. Didn't get to try it last night, but will tonight
<hryx>
did get CI passing last night though for the parser branch :>
Ichorio has quit [Ping timeout: 252 seconds]
<andrewrk>
ooohh party time
<andrewrk>
that's such a great feeling
Sahnvour has quit [Quit: Leaving]
cameris has quit [Quit: leaving]
<hryx>
sure is, especially on the 121st commit
Ichorio has joined #zig
<andrewrk>
hryx, and now for another big test: does zig fmt work on the entire standard library?
<andrewrk>
(careful, don't let a bug clobber your work!)
Ichorio has quit [Ping timeout: 255 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
shawn_ has joined #zig
scientes has quit [Ping timeout: 246 seconds]
shawn_ has quit [Ping timeout: 246 seconds]
<andrewrk>
hryx, that's a nice fat +2,888 −3,428. love that delta of negative 540 lines
<hryx>
yeah! I'm happy about the size and indentation impact
<hryx>
aww, zig fmt on stdlib was close. it tripped up on an async fn pointer struct member
<andrewrk>
I can't blame you for that
<andrewrk>
that's sort of in flux
<hryx>
andrewrk: I has opened the gates
<hryx>
(ready for review)
shawn_ has joined #zig
<mikdusan>
doe anyone have handy an array permutation example written in zig?
ltriant has joined #zig
<daurnimator>
hryx: yeah 1669 is good IMO.
<andrewrk>
it looks like this proposal is very popular within the zig community
<andrewrk>
this proposal tackles generics - at the same time I want to consider the proposal, if any, which will tackle runtime interfaces / OOP / virtual dispatch
<andrewrk>
it's likely they will be tightly coupled proposals
<andrewrk>
oh daurnimator you were asking for ideas on contributing, and I think I may have something that would interest you
<daurnimator>
andrewrk: still working on the generic allocator :P
<andrewrk>
let me know if I have correctly understood what you are looking for :)
<andrewrk>
oh yeah that's really good too. I'll still throw this out there for you though
<daurnimator>
andrewrk: sure
<andrewrk>
the idea is to make a proof of concept GUI application. in opengl or whatever, implement a bunch of widgets. buttons, scroll bars, dockable panes, menus, etc
<andrewrk>
first do it with status quo zig. @fieldParentPtr or whatever else makes sense. if it's painful, good, then we found an important use case