waleee-cl has quit [Quit: Connection closed for inactivity]
xackus has joined #zig
xackus_ has quit [Ping timeout: 260 seconds]
cole-h has quit [Ping timeout: 260 seconds]
ur5us_ has quit [Ping timeout: 276 seconds]
earnestly has joined #zig
xackus has quit [Ping timeout: 260 seconds]
pretty_dumm_guy has joined #zig
pretty_dumm_guy has quit [Client Quit]
pretty_dumm_guy has joined #zig
knebulae has quit [Read error: Connection reset by peer]
ur5us_ has joined #zig
squeek502 has quit [Remote host closed the connection]
ur5us_ has quit [Quit: Leaving]
zenkuro has joined #zig
sm2n_ is now known as sm2n
samtebbs has joined #zig
knebulae has joined #zig
waleee-cl has joined #zig
<samtebbs>
Hi all. Has anyone experienced a "mach-o/compact_unwind_encoding.h: No such file or directory" error when trying to build lld for zig?
<samtebbs>
The file doesn#t even exist in the downloaded source or the llvm-project github repo
<mikdusan1>
it exists in the monorepo
mikdusan1 is now known as mikdusan
<mikdusan>
I think what happened was lld introduced a header-only dep on libunwind and in monorepo this isn't a problem because that header exists and is found
mikdusan has quit [Quit: WeeChat 3.0.1]
<samtebbs>
Hmm even when building the monorepo instead of the downloaded source I get the error...
<samtebbs>
Ok, symlinking lld/MachO/mach-o to libunwind/include/mach-o did the trick
ifreund has quit [Ping timeout: 252 seconds]
ifreund has joined #zig
klltkr has joined #zig
xackus has joined #zig
xackus has quit [Ping timeout: 260 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.2-dev]
zenkuro has quit [Ping timeout: 265 seconds]
zenkuro has joined #zig
samtebbs has quit [Remote host closed the connection]
amk has quit [Remote host closed the connection]
mikdusan has joined #zig
amk has joined #zig
yeti has quit [Ping timeout: 265 seconds]
amk has quit [Remote host closed the connection]
Akuli has joined #zig
amk has joined #zig
yeti has joined #zig
zenkuro has quit [Ping timeout: 240 seconds]
zenkuro has joined #zig
mikdusan has quit [Quit: WeeChat 3.0.1]
marijnfs2 has joined #zig
Akuli has quit [Quit: Leaving]
klltkr has quit [Ping timeout: 252 seconds]
nycex has quit [Remote host closed the connection]
nycex has joined #zig
mjsir911 has quit [Remote host closed the connection]
mjsir911 has joined #zig
marijnfs2 has quit [Ping timeout: 265 seconds]
marijnfs2 has joined #zig
cole-h has joined #zig
nycex has quit [Ping timeout: 240 seconds]
nycex has joined #zig
cole-h has quit [Quit: Goodbye]
xackus has joined #zig
cole-h has joined #zig
mikdusan has joined #zig
hiljusti has joined #zig
<oats>
anybody know if justinbalexander/vegecode ever hangs out in here?
<hiljusti>
Has anyone created daemons in Zig? Curious if I can find some example code for that. I have an idea for an experimental database implementation and have been considering Zig over some other compiled languages
<oats>
hiljusti, "daemons" are a very broad category, do you just mean a long-running program?
<oats>
or is there some specific feature you're looking for examples of
<Nypsie>
oats, Not sure about IRC. But definitely seen him on Discord a few times. (He's pretty busy iirc, so isn't that active)
<oats>
Nypsie, oh thanks for reminding me of the discord
* oats
begrudgingly opens discord
<Nypsie>
No problem
<hiljusti>
Good point
<hiljusti>
I guess I'm looking for something that can do LPC and some riff off of the fork/setid/fork song and dance.
<oats>
lolol discord crashed my browser
<oats>
excellent software
<Nypsie>
oats: Just more proof of its quality /s
<hiljusti>
LPC or a unix-style socket or server, or... whatever really (I can figure out that part, I think) just hoping to see an example of what it would look like in Zig
<hiljusti>
I'm somewhere around hello-world level in my understanding of Zig (but also.... loving it!) so just kind of exploring my options
<Nypsie>
I've written a small http server in Zig, I suppose that could fix that criteria
<andrewrk>
not sure what his plans are. I think he might be waiting for a bit more stability in stage2 backend first. I told him I'd support upstreaming it as an experimental C frontend if he wanted to
<g-w1>
ahh, so it would also be a frontend, not just for translate-c. cool
<andrewrk>
yeah it's a common pattern. for example gcc stands for gnu compiler collection, because it has a bunch of frontends and they all emit the same gcc IR code (GIMPLE) so they can share the backend
<andrewrk>
same deal with llvm. C, C++, Objective-C all emit LLVM IR. Also I think there is a Fortran frontend now
<g-w1>
would air have to have gotos? or would it be using some weird block stuff?
<andrewrk>
AIR uses SSAT (Single Static Assignment Tree)
<andrewrk>
it looks basically the same as ZIR but everything is typed
<g-w1>
there are no gotos, which c has. to support c gotos would they have to be added to air, or would some block abuse be needed :)
<andrewrk>
SSAT is capable of representing gotos just fine
<g-w1>
what zir instruction would be needed?
<g-w1>
*air
<andrewrk>
no additional instructions are needed, they're all there already :) either goto down or goto up. goto down is just breaking from a block. goto up is continuing a loop
<andrewrk>
ez pz
<g-w1>
thats what i thought :) thanks
<g-w1>
that is also how translate-c will translate gotos right?
<andrewrk>
there is one thing -c does support putting labels in an array and goto a label. that would require additional support I think.
<andrewrk>
"computed goto"
<andrewrk>
yeah it's the same problem.
<g-w1>
could inline assembly do that?
<kiedtl>
Are there basic high-order functions in the stdlib? (map, foldl, zip, &c)
<andrewrk>
function pointers are generally discouraged
<kiedtl>
Oh. Why is that?
<mq32>
kiedtl: memory management
<mq32>
usually
<andrewrk>
makes your control flow confusing. plus if the function pointer is runtime known, then the compiler loses the ability to understand the complete call graph, which is useful for knowing how much stack space to allocate, which is especially important for async
<kiedtl>
Hm. I see.
<andrewrk>
that's not to say you can't do it. but if you're coming from rust or python, it's a bit of a different paradigm that zig encourages
wootehfoot has joined #zig
<kiedtl>
Yeah, FP has really grown on me.
<kiedtl>
Oh noes, Zig has a rng stdlib module! Now I don't have a good reason to reinvent the wheel!
<andrewrk>
oh yeah it's got a comfy API too
<mq32>
kiedtl: zig is way more imperative than other languages, maybe except C
<mq32>
even C++ nowadays is more functional
<kiedtl>
Well, it doesn't have a `choose_weighted` function. Maybe I can reinvent the spokes of the wheel, then.
<kiedtl>
mq32: Yeah, it's quite a disappointment for me, honestly :^)
<mq32>
a good example is "map"
<mq32>
mapping a string to "lower string" requires allocation which can fail, thus requires error handling, thus each single invocation of your map operation can fail
<mq32>
so you need a recovery strategy for already mapped elements as these must now be freed
<kiedtl>
Not if the user provides the destination buffer.
<mq32>
for each element?
<kiedtl>
Um, no?
<mq32>
for all elements together?
<mq32>
so i need to know the length of all strings beforehead?
<kiedtl>
hmm well
<mq32>
or where does this buffer come from?
<kiedtl>
I see what you're saying
<kiedtl>
mq32: anywhere, could be stack allocated
<mq32>
no alloca ;)
<mq32>
because stack overflow
<kiedtl>
Oh dear, I don't think I explained what I was thinking very well
<kiedtl>
I think I'll come up with a code snippet in a couple hours, gtg now
<mq32>
o/
<kiedtl>
cya
<g-w1>
thinking about it more, arocc could just do some sort of "astgen" step and emit zir. it wouldn't even have to typecheck! then @cimport could be simplified by just emitting zir instead of zig. this way it wouldn't have to go c -> parse -> zig -> parse -> zir but instead c -> parse -> zir. ofc translate-c would still be needed in some cases.
<marler8997>
is there a way to grep this irc channel?
<marler8997>
I'm looking for something from months ago
<g-w1>
my znc server captures logs so if you want them i can send them to you (been running since 2021-02-21.log)
<g-w1>
it works for more than a day
<g-w1>
not filter on top, but search on the left
<marler8997>
feb not far back enough :(
<andrewrk>
g-w1, I don't think either of those ideas would work. ZIR is coupled to zig syntax and semantic analysis of it follows zig rules. it would end up not correctly compiling the C code
<g-w1>
can you give an example? so arocc would have to emit air?
<andrewrk>
for translate-c, it is trying to output readable zig from typed C AST. the output of ZIR is AIR and converting AIR to ZIG would not result in readable zig
<g-w1>
im saying also translate-c could go from c ast -> zig, but for efficiency, it could just use the zir (but its cached anyways so scratch that :P)
<andrewrk>
my gut instinct is that a c frontend would want to perform semantic analysis directly on the C AST and emit AIR. Vexu can probably share some insight on this topic
<g-w1>
ok cool
<g-w1>
ah yea, all the casts would be really weird
<andrewrk>
for an example, have a look at LazySrcLoc and the byteOffset function related to each tag
<g-w1>
i remember :D, some are tied to builtins. it seems like air uses them too. src: Module.LazySrcLoc,
<marler8997>
sorry to interrupt, but air?
<g-w1>
also, can ir.zig be renamed to air.zig ? i instinctively tried to open air.zig :)
<g-w1>
marler8997: analyzed ir
<marler8997>
gotcha
VFEXrt has joined #zig
<g-w1>
an optimiser is an air conditioner
<marler8997>
wow
<marler8997>
the higher you turn on the air conditioner, the lower your cpu temps will be
<g-w1>
maybe the other way around lol
<VFEXrt>
qq: Using the std json parser is there a way to rekey the struct? i.e the struct has a field "some_key" but the json string has the key "somekey" From what I'm gathering, it looks like they have to be the exact same?
<mq32>
no rekeying available i think
<VFEXrt>
Dang, some people choose really gross formats for their json keys and I'd really like to not be stuck with them. Thanks!
<andrewrk>
g-w1, yes I will do it shortly after merging the stage2-whole-file-astgen branch. I don't want to cause unnecessary conflicts with master branch PRs in the meantime
<g-w1>
sounds good :)
<andrewrk>
VFEXrt, you could have a struct that is for matching the json and another which has your preferred names and maybe some cleaned up data
<andrewrk>
this would probably be a useful separation for trust reasons too; the json struct would be unvalidated but the other struct you could trust to have sound data
<VFEXrt>
Yeah, makes sense. The allocation story there sounds a bit out of my (current and very new) understanding of zig
<VFEXrt>
My initial guess would be to realloc all the []u8 types into the cleaned up struct?
<VFEXrt>
Then parseFree the initial struct
<kiedtl>
what's the function to add a source file to the build in build.zig?
<g-w1>
what kind of source file ;)
<g-w1>
in zig, you only need 1 source file, in c pub fn addCSourceFiles(self: *LibExeObjStep, files: []const []const u8, flags: []const []const u8) void {
<kiedtl>
I'm doing @import("foo") where foo is src/foo.zig, but it complains of not being able to find it
<g-w1>
foo.zig
<g-w1>
if you want to add a package in the build for some reason, use pub fn addPackage(self: *LibExeObjStep, package: Pkg) void {
<kiedtl>
Oh, the file extension is necessary. thanks.
<g-w1>
where Pkg is pub const Pkg = struct {name: []const u8, path: []const u8, dependencies: ?[]const Pkg = null,};
<g-w1>
ok cool
pretty_dumm_guy has quit [Ping timeout: 240 seconds]
<noam>
If you're referencing a file, you need the extension; if you're referencing a package, the extension is verboten (unless the package's name includes it, which IMO shouldn't be allowed due to the ambiguity)
<VFEXrt>
Is there a max number of struct fields that the compiler can handle? Seems fine at 9 but I get this error at 10
<andrewrk>
VFEXrt, look up @setEvalBranchQuota in the lang ref
<andrewrk>
you can just bump that up to whatever you need
<VFEXrt>
On it, thanks :)
<andrewrk>
this is how zig solves the halting problem ;)
<mq32>
cut the tape off!
<VFEXrt>
Makes since, I suppose with all the comptime stuff its super easy to get the compiler to never exit
<VFEXrt>
Swift's type checker has (had?) an issue where the type inference grew exponentially and certain matches would take years to resolve so they just timeout and say "hey could you help us out a bit by splitting this line up"
<kiedtl>
Can you create a large zeroed matrix with the ** operator? (something like `[height][width]Type{ [_]Type{.Foo} ** width } ** height;')