<cshenton_>
andrewrk: have you considered setting up a discourse for zig? They're less intimidating than irc for new users and more importantly get indexed by search engines so people can find answers to common questions.
<cshenton_>
I think stuff like this is important to people for language adoption because they can get a feel really quickly for whether other people are actively using the language for the same use cases as them.
<daurnimator>
FWIW I really dislike discourse as forum software
<Snektron>
switch to asmbb instead
<pixelherodev>
What would be neat is if we can get a server automatically integrating IRC logs with the forum
<pixelherodev>
e.g. automatic forum users for IRC users
<pixelherodev>
Though I suspect it'd be a pain to try automatic thread detection for anything not containing a pinging reply
<Snektron>
I love Zig's ability to not be a dynamic executable at all
<Snektron>
Sending a 32K executable to an archaic uni server that runs centos and being able to run it without having to rip packages from ubuntu repos is really nice
<pixelherodev>
Agreed
<pixelherodev>
musl == <3
<Snektron>
i'm doing aoc, part 2 of day 18 is not so nice
<Snektron>
so i adapted my part 1 solution, and while i think of a better method i just pushed this onto one of my uni's servers because i don't have enough ram
<Snektron>
it's gonna take a while though, oof
<mq32>
Snektron, pixelherodev: static linking solves a whole problem class that people now do workarounds for (flatpak, snap, appimage, ...)
<Snektron>
plus i'm fairly sure this server also doesn't have enough ram
<cshenton_>
aren't aoc problems meant to be runnable on pretty minimal hardware?
<Snektron>
yeah, my solution is bad
<Snektron>
at least, it was good for the first one as it was some dijkstra variation
<Snektron>
i adapted it to work for the second part but that blows up the solution space much more
* daurnimator
has been thinking lately about what an ABI for zig would look like
<mikdusan>
some kind of thunking for errors?
<mq32>
daurnimator: i don't think you can build native zig libraries because of comptime
<daurnimator>
mq32: we'd need to ship some sort of "header" format I guess
<mq32>
but you could bundle code as zig IR into a library
<pixelherodev>
I think you can do it
<mq32>
assuming zig gets its own backend, translating zig IR to native code should be pretty fast
<pixelherodev>
But it'd be far easier on e.g. source-based distros
<mq32>
this function is impossible to "precompile"
<mq32>
except into IR representation
<pixelherodev>
Yeah, except that only `export`ed functions would be usable anyways
<Snektron>
oof, out of memory
<pixelherodev>
That's no different than a macro in a C library
<daurnimator>
mq32: one way: it could end up as a macro in a .h file
<pixelherodev>
e.g. #define a(x) x
<mq32>
but that would be a C ABI
<mq32>
:D
<Snektron>
I struggled so much with these damned servers during my bachelor's thesis
<mq32>
we have that already
<daurnimator>
mq32: right. but we can think of a zig equivalent
<pixelherodev>
Huh. Comptime -> macro? I - don't think that's entirely possible
<Snektron>
i even wrote an entire python script "package manager" especially designed to rip packages from ubuntu repo's and install them on archaic systems...
<Snektron>
daurnimator: i once saw a project which used that kind of code everywhere
<Snektron>
it was quite strange
<mq32>
daurnimator: yeah, that macro language is Zig IR :D
<daurnimator>
mq32: except zig IR was not designed for stability
<daurnimator>
or portability
<mq32>
i can imagine that this may change
<mq32>
as it is an implemetation detail atm
<mq32>
so zig could use something like .NET any-cpu assemblies
<daurnimator>
what is architecture but an implicit comptime argument? :)
<mq32>
where a bytecode is stored that may be executed at comptime or be compiled to native code
<daurnimator>
However I *would* like to be able to have zig emit a shared library and be able to introspect the ABI without going via C headers
<mq32>
if we remove comptime from exportable functions, it will be easy to define an ABI
<mq32>
but i don't think it's good to actually have precompiled native libraries in the world of zig
<mq32>
it's something that will reduce the portability and cross-platform ability al ot
<pixelherodev>
I disagree
<pixelherodev>
Native compilation will always be different from cross-platform targeting
<pixelherodev>
As long as native doesn't come at the expense of cross-compilation I'm all for ti
<pixelherodev>
it*
<mq32>
point is: if there is an option for native shared libraries
<mq32>
people will start creating closed-source libraries with a limited set of precompiled targets
<mq32>
let's say win64, linux-x86_64
<pixelherodev>
They can do that regardless.
<mq32>
and you cannot use the library on any other platforms because they don't provide you with the source
<pixelherodev>
You can already do that
<mq32>
in the current state, to provide a zig library, you have to provide the source
<mq32>
otherwise it's just a C library ;)
<pixelherodev>
No you don't.
<pixelherodev>
Well yeah
<pixelherodev>
But that doesn't matter
<mq32>
imho it does
<mq32>
because a library written in Zig, but following C abi rules, will just not be a zig library
<pixelherodev>
If they have to do it as C libraries they will
<pixelherodev>
Removing the option to produce native Zig libraries won't cause people to release the source
<pixelherodev>
It'll cause them make the minor tweaks needed to make native C libs
<mq32>
which would still be a benefit as the library would be usable with C as well then :D
<pixelherodev>
Exactly
<pixelherodev>
I don't think there's really anything we could to force people to release source capable of a draconian license, which would just kill the language anyways
<mq32>
nah, that wasn't my point
<mq32>
i don't want to force people to release the source, but cross-platform-usable libraries
<mq32>
which may be closed source
<mq32>
because that's one thing i really hate about the C env
<mq32>
you have 4 versions of SDL for windows
<mq32>
{32bit,64bit}*{msvc,mingw}
<pixelherodev>
More than four
<mq32>
at least those are the official libraries *per* release
<pixelherodev>
Ah - you meant *official* :P
<mq32>
yeah ^^
<mq32>
and i don't want that this happens to zig
<mq32>
because those libs are all slightly different
<mq32>
and it's only "2" targets
cshenton_ has quit [Remote host closed the connection]
<mq32>
got to go to bed
<Snektron>
finally, i improved my solution
<Snektron>
it fails on one example, but it did find the right solution
<Snektron>
i'll take it
<Snektron>
It's been nice doing these things in Zig, i didn't quite get around to larger projects this semester
<daurnimator>
what is `@sizeOf([1024]u1)` in zig?
<daurnimator>
and how do I get it to be 128?
<fengb>
PackedIntArray?
<daurnimator>
Ah
<daurnimator>
what if I wanted bool instead of u1?
frmdstryr has quit [Ping timeout: 258 seconds]
dingenskirchen has quit [Ping timeout: 248 seconds]
<pixelherodev>
@sizeOf([1024]u1) should already be 128 I think...
<daurnimator>
`[1024] align(0) u1` doesn't seem to be valid
<daurnimator>
pixelherodev: u1 by default has alignment 1. and zig doesn't have "packed arrays" IIRC
ur5us has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
<daurnimator>
I'm running into an issue where a symbol from a library is NULL
<daurnimator>
printing it I get: `extern fn(c_int, c_int) c_int@0`
<mikdusan>
I may be on a wild goose chase here, but it seems to me that we should see UND for "Base blsInit" to match "<blsInit@@Base>" of the library?
<daurnimator>
what is "Base" there?
<mikdusan>
I'm only guessing, maybe it is like an begin version when there is no versioned symbol
<daurnimator>
mikdusan: anything else that might help you figure it out? :)
<mikdusan>
is libbls something i can install? or create?
<daurnimator>
mikdusan: sure, its https://github.com/herumi/bls if you're on arch I recently uploaded a PKGBUILD to the AUR
<mikdusan>
I'll try AUR. updating my arch first.
<mikdusan>
ok I have a reproduction. AUR wasn't that painful at all :)
<daurnimator>
mikdusan: do you use an AUR helper?
<mikdusan>
didn't need to. just git clone'd bls-git and libmcl, makepkg -si and all is good
<daurnimator>
k :)
return0e_ has joined #zig
<mikdusan>
ok so "Base" thing was not an issue.
<mikdusan>
try this: `zig run bls.zig -lc -lstdc++ -L/usr/lib -lbls_c256`
return0e has quit [Ping timeout: 268 seconds]
<daurnimator>
mikdusan: huh... so its a linking libstdc++ thing?
<mikdusan>
...first tried `-lc` and it complained of a missing symbol re: c++ unwinding, so then just added `-lstdc++` to quiet it,
<mikdusan>
I'm fuzzy on linux executable rules. if linking to a c++ .so, must main.exe be linked with -lc and -lstdc++ ? I can't remember.
<daurnimator>
weird.... why was I able to compile without errors/warnings?
<mikdusan>
the bls.c equivalent works without specifying -lstdc++
<mikdusan>
and `gcc -v` on that produces a ton of options that may do something to an exe to support linking against a c++ .so . but don't quote me on that.
<mikdusan>
that is it may do _more_ than whatever zig is doing for a non-libc linux executable
<mikdusan>
long story short, I think you're on bleeding edge here, zig executable without libc, and linking against a c++ .so
<daurnimator>
mikdusan: I'm not sure what the issue(s) to file are...
<TheLemonMan>
leeward, have you checked out ResetEvent in the stdlib?
<leeward>
TheLemonMan: no
<leeward>
daurnimator: Maybe...
<TheLemonMan>
beside that the cond_ api for pthread are already available in c.zig
<leeward>
TheLemonMan: That might be what I was looking for. I didn't really want to depend on posix.
<leeward>
TheLemonMan: ResetEvent looks like it's only good for signalling a single thread. I was using pthread_cond_broadcast, which signals multiple threads.
_whitelogger has joined #zig
<leeward>
Anyone know why there's defer and errdefer but no successdefer?
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<leeward>
D's got scope(exit), scope(fail), but also scope(success).
<leeward>
It feels like an intentional decision.
<daurnimator>
I can't say I've ever found myself wanting it
<leeward>
I hadn't before today, and the thing I wanted it for might be more clearly expressed without it, so that might be why.
<leeward>
It's not the (allocate resource/free resource) pattern that it's usually used for, but it's fewer lines of code: `successdefer thing(); return otherThing();` where otherThing is of type !void. Probably clearer as `try otherThing(); thing();` anyway.
<daurnimator>
not only clearer but highly recommended: if you don't do the `try` then your function won't appear in the traceback IIRC
<leeward>
Really? Isn't `try a` the same as `a catch |e| return e`?
<leeward>
Does it really behave differently from `return a`?
<leeward>
That is, `return try a` vs `return a`
<fengb>
I wrote up a proposal to mandate the try. I don’t think it got a lot of traction either way
<daurnimator>
leeward: essentially I think of it as casting an error to an error union appends to the trace
<daurnimator>
leeward: `return e` => that is then converted to an `someerrorunion!void`
protty has joined #zig
<leeward>
It seems unnecessary to me. `return foo()` from within bar only works if foo and bar have the same return type. All `return try foo()` does is remind the author that both have a ! somewhere up in their prototype.
<fengb>
If you have multiple returns, it’s not obvious which one can error
<leeward>
Hmm, I lied. If foo doesn't have a ! in it, `return foo()` will still work in bar, even if bar does, as long as it has some path that can return an error.
<leeward>
Still, I'm not a fan of making `try a` more complicated than "sugar for `a catch |e| return e`"
<leeward>
fengb: I see your point, but I think I weighted the cost and value differently.
<protty>
leeward: read back a bit in the history. std.ResetEvent could possibly be made to signal all waiters on .set() with a few modifications (or was there a different pthread_cond_t use case wanted?)
<leeward>
daurnimator: Still confused.
<riba>
daurnimator: that does sound like what i need
<leeward>
protty: Yep, using std.ResetEvent. It might be worth adding a .setBroadcast() or something to more accurately mirror pthreads condition variables, but I'm not convinced yet.
<riba>
also, how do i cast to '[*:0]u8'? when i try to @ptrCast i get that ':' is an invalid character
<riba>
(i'm on 0.5.0, could that be it?)
<leeward>
riba: yes
<leeward>
I don't think sentinel-terminated array syntax was in 0.5 yet.
<protty>
... sync primitives: 1) should mutex & spinlock have deinit() removed since they dont represent a resource 2) should reset event broadcast by default
<leeward>
protty: if we leave deinit() on those, it opens up the possibility of implementing them differently, which I like.
<leeward>
2: Hard to say; it can be more expensive than single-thread signalling, but it's more widely useful.
<leeward>
Also more general purpose.
<protty>
will test it out and make a PR if it doesnt slow stuff down too much
<leeward>
Sounds like a good plan.
darithorn has joined #zig
<leeward>
Hmm, I'd like the ability to remove an element from priority_queue.PriorityQueue other than the first one (I have an event queue where events can be cancelled).
<leeward>
Would it be better to add a new type or just add another method to PriorityQueue?
<leeward>
Thats after I updated to master and rebuilt from scratch.
<WendigoJaeger>
Is there a way to have a predictable path for the test executable? I want to attach a debugger to it
rjtobin has quit [Quit: Leaving]
<leeward>
WendigoJaeger: Yes, it's one of the options. Unfortunately, I don't know which.
<D3zmodos>
Is anybody running the zig compiler from a symlink on Windows? I'm fairly certain I had it setup like that a little while ago but now it doesn't work (I get "Unable to find zig lib directory" which I guess is self-explanatory but I'm just wondering if there's something sneaky that I might need to do to point it in the right direction)