a_chou has quit [Remote host closed the connection]
ur5us_ has quit [Ping timeout: 264 seconds]
xackus has quit [Ping timeout: 256 seconds]
cole-h has quit [Ping timeout: 260 seconds]
cole-h has joined #zig
cole-h has quit [Client Quit]
_whitelogger has joined #zig
<andrewrk>
what kind of application is it?
<andrewrk>
that's generally the model that node.js gives you and I found it quite comfortable for many kinds of tasks
_whitelogger has joined #zig
ur5us_ has joined #zig
cole-h has joined #zig
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nephele has quit [Ping timeout: 260 seconds]
nephele has joined #zig
ur5us_ has quit [Ping timeout: 265 seconds]
xd1le has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
ur5us_ has joined #zig
<pixelherodev>
I see some nice work has been going on :)
<pixelherodev>
I'm going to be offline for the next week or so, but I intend to have at least a couple CBE / SPU backend patches ready for review at that point
<pixelherodev>
:)
<andrewrk>
looking forward to it
<andrewrk>
hmm I'm considering starting to ship stage2 along with stage1 hiding behind a subcommand like this: `zig stage2 build-exe hello.zig`
gert_ has quit [Quit: WeeChat 2.9]
<andrewrk>
the only reason not to would probably be slower stage1 compilation and binary bloat
<andrewrk>
adding 3.5 MiB onto 119MiB hardly seems like an issue tho
<andrewrk>
so really it would just be resource usage to build it
cole-h has quit [Quit: Goodbye]
<companion_cube>
is there a writeup of the general purpose allocator's design? or just livestreams?
cole-h has joined #zig
<pixelherodev>
andrewrk: personally, I think it's not worth it just yet
<andrewrk>
companion_cube, check out the comments at the top of the file. also it's only a couple hundred lines of code
<pixelherodev>
I think we should wait until at least it's somewhat usable for real projects to enable it properly, at which point it should be `zig stage2` (with associated functionality in build.zig, which I preemptively volunteer to handle), and once it's ready for general usage, it should become the default (with stage1 potentially remaining as `zig stage1` until all corner cases are handled)
<pixelherodev>
For now, I think keeping it distinct makes sense. Until we have support for even basic projects (such that one can take 100 random Zig projects and have at least a dozen compiling for at least one backend), there's really no point in enabling it. It's not that it would cause problems, but that I don't see any real advantage to doing it now.
marnix has joined #zig
<companion_cube>
andrewrk: 👍
<companion_cube>
andrewrk: fun, the hashmap being used to keep track of allocations… in the allocator
_whitelogger has joined #zig
ur5us_ has quit [Ping timeout: 240 seconds]
<leeward>
Looking at some recent changes to Allocator, I'm confused by ret_addr. Are allocators supposed to put their results in that address? And why is zero special instead of just making it a `?usize`?
<daurnimator>
leeward: it's the instruction where the allocation should be considered to occur
<leeward>
Why's it there?
<daurnimator>
leeward: it's used to generate tracebacks for e.g. leaks
<leeward>
ahh
<leeward>
Seems like it should be an optional pointer to an instruction data type, instead of a usize that treats 0 as special.
<daurnimator>
maybe. but it's intended to be used with `@returnAddress()`; so whatever proposal you have should be made for that too
<leeward>
mm, I'll look into that
<leeward>
had actual job work to do recently and stopped paying attention
<andrewrk>
leeward, Allocator implementations can ignore that parameter
<leeward>
Yeah, I gathered.
<andrewrk>
it's pretty darn useful for GeneralPurposeAllocator tho
<leeward>
I'd expect it to be useful for anything that wants to be able to point a finger at leaks.
<andrewrk>
yeah the point is that it saves a few precious frames so that you can store less memory per trace. or rather a trace with N given frames will be more useful without all the Allocator interface & implementation noise in there
<leeward>
That can probably be communicated better in the doc comments.
<andrewrk>
agreed
<leeward>
well, if nobody beats me to the punch I'll put together a proposal this weekend
<leeward>
Huh, that's new. Trying to compile Zig on an arm64 system and X crashed.
<leeward>
Ah, oomkiller
<leeward>
naturally
<leeward>
now to figure out how to add swap to this thing
xackus has joined #zig
xd1le has quit [Read error: Connection reset by peer]
xd1le has joined #zig
brotein has joined #zig
_Vi has joined #zig
brotein has quit [Ping timeout: 260 seconds]
<andrewrk>
things are going to get a little bit worse before they get better
<andrewrk>
but then they will get much, much better
xackus has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
_Vi has quit [Ping timeout: 272 seconds]
<leeward>
That is how these things go.
hsh has joined #zig
<DarkUranium>
also, hey scientes :P
<ifreund>
andrewrk: this is a fairly simple daemon + pam_module to implement the XDG_RUNTIME_DIR of the freedesktop spec
<ifreund>
I've recently dropped elogind for https://git.sr.ht/~kennylevinsen/seatd which has a much more minimal feature set so there are a couple of holes to fill
<ifreund>
I don't really need async, but it makes the code much cleaner
heitzmann has quit [Quit: Ping timeout (120 seconds)]
heitzmann has joined #zig
brotein has joined #zig
knebulae has joined #zig
_whitelogger has joined #zig
brotein has quit [Remote host closed the connection]
<ikskuh>
andrewrk: uuuuh nice #6250. I thought i misunderstood you yesterday, but it looks like we're really getting somewhere with stage 2 :)
philtor has quit [Ping timeout: 264 seconds]
xd1le has quit [Read error: Connection reset by peer]
xd1le has joined #zig
<gonz_>
ggVGc: `ggcG` works fine to do the same thing :D
<ikskuh>
execept when you use two different structs
_Vi has quit [Ping timeout: 272 seconds]
<Cadey>
how do i get more information from a zig error?
<Cadey>
i'm trying to run a subprocess and i get error: FileNotFound
<Cadey>
which file isn't found?
<Cadey>
oh
<Cadey>
it's because /dev isn't mounted yet
<KoljaKube>
ikskuh: too bad, but thanks
marnix has quit [Ping timeout: 260 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
<cr1901_modern>
So if I understand the rules of comptime vars properly, the Zig compiler does something (loosely) like this >>
<cr1901_modern>
If any vars in the current statement or expression are comptime, the zig compiler checks whether it can evaluate it now. If it can't, error out.
<cr1901_modern>
But that definition doesn't work for: result = cmd_fns[i].func(result);
<cr1901_modern>
b/c "i" is a comptime var, but the expression doesn't error out
<scientes>
they are not consts
<scientes>
and that example is not valid syntax
<cr1901_modern>
>they are not consts
<cr1901_modern>
What is that in reference to?
<scientes>
a comptime var is not a const
<cr1901_modern>
(Sorry, I need to take this one part at a time :P)
<scientes>
it can change, but it will never be runtime
<scientes>
cr1901_modern, nah, just play with it
<cr1901_modern>
>and that example is not valid syntax
<cr1901_modern>
It works in my compiler
<cr1901_modern>
I can do something even more absurd that compiles and then panic at runtime with unreachable: http://ix.io/2w81
<cr1901_modern>
I guess the reason it doesn't error out is that "cmd_fns[i]" _can_ be evaluated at comptime, even if "cmd_fns[i].func(result)" cannot.
xackus has joined #zig
<KoljaKube>
cr1901_modern: If you want the whole expression to be evaluated at comptime, you can use a comptime {} block. It will error out if that's not possible. Otherwise only what is possible will be evaluated at comptime
<cr1901_modern>
>Otherwise only what is possible will be evaluated at comptime
<cr1901_modern>
So, what dictates whether evaluating an expression will error out if it's not comptime versus deferring to runtime?
<cr1901_modern>
Whether the expression has a comptime var in it?
<cr1901_modern>
In my above example "cmd_fns[i].func(result)" is multiple expressions w/o whitespace in between (I _think_)
dec05eba has joined #zig
a_chou has joined #zig
<dec05eba>
i see in the docs that @sizeOf(u24) returns 4 because of memory layout but is there any way to get 3 instead of 4? i have comptime T and i want to know what size the type passed is
cren has joined #zig
<cren>
I'm creating sockets with zig-network and not closing them
<cren>
so now I can't use the same port number again
<cren>
is there a way I can manually free up the socket outside of zig?
<cren>
or free up the socket before trying to use it in the program.
<ifreund>
if you're on linux, delete the files
<cren>
ifreund: I am. Do you know where they get put?
<cren>
is it under /dev?
<ifreund>
wherever you put them?
<ifreund>
oh wait these aren't unix sockets i suppose
<cren>
I don't know :/ the library provides an abstraction layer for crossplatform sockets
<ifreund>
try fuser(1)
cole-h has joined #zig
a_chou has quit [Ping timeout: 260 seconds]
a_chou has joined #zig
<cren>
will a `defer` run even if the program hits an error before the point where the defer should run?
<ifreund>
yes
<ifreund>
unless it's a panic
<cren>
kernel panic?
rinwa has joined #zig
<dec05eba>
no a zig panic, which happens for example when you hit "unreachable"
<dec05eba>
or when @panic is called
<cren>
ahaha the problem was nothing to do with the socket, the problem was that the program itself tried to connect the same socket twice *forehead slap*
<cren>
dec05eba: ok
<ifreund>
unreachable is only a panic in safety-checked builds
marnix has quit [Ping timeout: 256 seconds]
<cren>
should I put tests in the same file as the program, or a different file? (I'm aware that this is mostly opinion-based)
_Vi has joined #zig
<ifreund>
depends on the nature of the tests imo
<ifreund>
testing basic functionality of a data structure? same file. Testing input and output of a compiler? different file
<cren>
that's kind of how I feel too ifreudn
dddddd_ has joined #zig
<cren>
s/ifreudn/ifreund
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dddddd has quit [Ping timeout: 264 seconds]
dddddd__ has joined #zig
marnix has joined #zig
dddddd_ has quit [Ping timeout: 240 seconds]
dddddd__ has quit [Ping timeout: 260 seconds]
<cr1901_modern>
andrewrk: So before I make a bug report... this compiles: http://ix.io/2w8l
<cr1901_modern>
Based on lang semantics, this should _not_ compile, correct?
<dec05eba>
you mean empty struct?
<ifreund>
why not?
<cr1901_modern>
because comptime { var i = start; } and start is not comptime
<cr1901_modern>
On the other hand, this does NOT compile: http://ix.io/2w8n
xd1le has quit [Read error: Connection reset by peer]
<ifreund>
it is comtime
<ifreund>
'5' is comptime known
<ifreund>
try passing std.os.argv[0][0] or something
<ifreund>
what error do you get for the second?
<cr1901_modern>
./comptime-test.zig:3:17: error: cannot store runtime value in compile time variable
<cr1901_modern>
var i = start;
xd1le has joined #zig
<cr1901_modern>
which is what I expect because I didn't declare start as comptime, thus zig can't assume all uses of KeyPad are comptime
<ifreund>
no, but it's lazy
<cr1901_modern>
I don't understand what that means... anyways should both the examples I link compile or not?
<ifreund>
by my understanding it should let you do that as long as the value you pass to KeyPad is comptime known
<cr1901_modern>
Then why do you need comptime in the function declaration if the compiler can determine that info for you?
<ifreund>
by "lazy" I mean that the compiler doesn't assume that all uses of KeyPad are comptime, it just checks if it can compile it in the cases where it's actually used
<cr1901_modern>
Then my second link should have compiled then, but didn't
<ifreund>
well, stage1 is far from perfect
dec05eba has quit [Quit: Leaving]
<ifreund>
and we can't really know the answer as to which example is right without a language spec, which is coming before 1.0
<cr1901_modern>
So back to my original question, which example is miscompiling? Are the semantics for the two examples I presented effectively "undecided"?
<cr1901_modern>
Meaning either/or can work, and stop working at any point?
<cr1901_modern>
Which is fine! I just want to not be confused on how comptime vars interact with non comptime vars :P.
<ifreund>
I'm not 100% sure what the intended behaviour is, though my gut says that the second should be fine if you only ever pass comptime known values to the function
<ifreund>
My advice would be to place your focus on building useful software and contribute to zig/report issues found along the way.
<ifreund>
zig is still pre-1.0 and there will be breaking changes
<cr1901_modern>
Well I was going to open an issue :P
<cr1901_modern>
Building useful software? Unfortunately, Idk how much doing old Advent of Code counts.
<ifreund>
heh
<ifreund>
advent of code is fun, but not code your're likely ever going to run again after you solve the puzzles
<cr1901_modern>
I use it as a quick way to get up to speed w/ languages when I can't think of anything else I want to implement myself (that wouldn't require me to already have a decent grasp on the language)
<ifreund>
well, with zig I just kinda jumped in and wrote a wayland compositor as my first project
<ifreund>
you can't reall do that with many languages though, zig is special in that if you know C well you can be productive in a matter of days
<leeward>
I think Zig took the least effort up front of any language I've learned in the last few years, but part of that is probably that Zig doesn't have any features I haven't encountered somewhere else.
<ifreund>
leeward: what else has comptime?
<KoljaKube>
Do C++ templates count? ;-)
<leeward>
D's metaprogramming is similar.
<leeward>
C++ templates do not count3.
<ifreund>
D kinda repulsed me with it's kitchen-sink-ness, never did write any
<fengb>
I wouldn’t say comptime is a new concept as much as a good implementation
<fengb>
Returning types and stuff already exists. The seamlessness of switching contexts makes it novel, but not too hard to learn
<ifreund>
yeah that's kinda the point of it as a feature over macros, same basic semantics
a_chou has quit [Ping timeout: 240 seconds]
<KoljaKube>
Can I use @Type(.Opaque) instead of c_void or am I missing the point?
<KoljaKube>
Seems to work for pointers, but not for function return values
<fengb>
You can’t return non pointers because memory is unknown. It’s akin to a forward declared struct in
<fengb>
C
<KoljaKube>
I'm trying to assign a `?fn() callconv(.C) *@Type(.Opaque)` to a `const void* (*foo)(void)`
<fengb>
That’s not right. Use a *c_void
<KoljaKube>
Assigning a `@Type(.Opaque)` to a `void*` struct member works fine
<KoljaKube>
s/@/*@/
<fengb>
Opaque behaves similar to a “struct Bodiless;” declaration in C
<fengb>
So any time the types don’t work in C, it also won’t work in Zig
<KoljaKube>
What the pointers actually should point to is something not available at compile time
<KoljaKube>
I thought I could use the Opaque pointers to differentiate the various actual types on the zig side
<KoljaKube>
Am I mistaken there?
<fengb>
You can, but the C function pointer expects a void* return
<KoljaKube>
Would that be OK to cast?
<fengb>
Changing that return value isn’t considered safe due
<fengb>
Probably a manual cast is safe
dddddd__ has joined #zig
<KoljaKube>
OK, good
dddddd__ is now known as dddddd
<KoljaKube>
I guess I'll find out should I ever actually use the other rendering backends
<KoljaKube>
OpenGL does not need any of that stuff :D
<leeward>
ifreund: I stopped paying attention to D when D2 became a thing. I stopped being able to tell what made it better than C++, and C++ is below my threshold for languages I want to use.
brotein has joined #zig
<leeward>
My favorite feature from D is in Zig though, in the form of defer.
brotein has quit [Client Quit]
nvmd has joined #zig
brotein has joined #zig
marnix has quit [Read error: Connection reset by peer]