<frmdstryr>
When using a package in build.zig, zig appends ".package" to the name. This make gdb give a syntax error when I try to use `p .mypkg.some.var`, how do I print a value from a package with gdb?
<pixelherodev>
I don't think that's a build.zig thing
<pixelherodev>
I think it's Zig's internal naming - if you have `const a = @import("something.zig")` in your root file, and a contains a global `b`, then it'll be named `.a.b`
<pixelherodev>
I could be entirely wrong, I've not had the best experience with it so far either
<frmdstryr>
Hmm, ok, I wonder if there's any issues on this
<keegans>
experienced what I believe is a bug, but am not sure how to track down if it has been reported yet. for a statement that can return a set of errors, say X Y Z, if you explicitly handle X and also have a `else => return err;`, X is still in the set of errors that can escape out of that function
<keegans>
(when in reality since Y and Z cases resolve to a return err, only Y and Z can actually be returned from the function)
<danyspin97>
it's great but not yet aimed at everyone
<danyspin97>
due to its mail based workflow
<danyspin97>
do you have projects there?
<isolier>
I see. I self host Gitlab, but it is a beast.
<danyspin97>
ah, yea it is
<danyspin97>
I use gitlab often because the distro I use has a selfhosted instance
<danyspin97>
and sometimes it becomes slow. I have also seen that freedesktop pays a lot for its instance
<isolier>
It is definitely featureful, but I think I am going to switch to source hut or gitea or something.
<isolier>
Yeah, they defintely make it easy to set up your own instance, despite the amazing complexity.
<danyspin97>
gitea is good, but I disklike go..
<fengb>
You prefer Ruby over Go? 🤔
<danyspin97>
yup
<isolier>
Indeed. I just want to use though, so hopefully the implementation language doesn't matter so much.
cren has joined #zig
<danyspin97>
ruby: modular packages, easy to bootstrap (afaik)
<danyspin97>
go: hell to bootstrap, huge packages, bad practices until last year
<fengb>
Um... Ruby best practices are... amazing
<fengb>
And not sure what you mean by bootstrapping because Ruby doesn’t build itself
<danyspin97>
never developed in Ruby, but I am biased packaging some software
<fengb>
Oh GOPATH was shitty
<danyspin97>
yea, that's why ruby it's good, you can compile it in C
<fengb>
I’m glad they finally figured that out
<cren>
what exactly did Go do with GOPATH?
<danyspin97>
the language choosed how to deal with packages
<fengb>
Every “package” in Go needed to be in GOPATH
<danyspin97>
and GOPATH was used
<cren>
That sounds reasonable enough
<danyspin97>
the headaches trying to understand it
<danyspin97>
only for local development
<fengb>
It’s a global space where all packages go
<ifreund>
that sounds horrible
nycex has quit [Ping timeout: 240 seconds]
<cren>
That doesn't sound much different from what python does
<fengb>
And there’s no way of loading a different path
<danyspin97>
no, python is good for this
<ifreund>
python package management is also horrible
<danyspin97>
it's workable
<fengb>
Python let’s you add stuff like virtualenv
<danyspin97>
I actually like python package management
<cren>
I like that there are a lot of packages
<danyspin97>
you can install packages in /usr/lib, use local files or user installed packages
<ifreund>
aye with venv it's workable
<fengb>
Anyway, Go has actual modules now
<cren>
I do not like that you cannot recursively remove a package and its dependencies with pip
<danyspin97>
pip without --user it's bad
nycex has joined #zig
<fengb>
Most package managers don’t let you exclude a transitive dependency
<cren>
Is the last expression in a Zig function returned automatically?
<fengb>
No
<ifreund>
not anymore at least
<cren>
I think that's good
<ifreund>
I agree
<cren>
As a Python person I don't like implicit things
<fengb>
It wasn’t implicit though: return by dropping the terminating semicolon
<fengb>
Not very obvious either >_>
<leeward>
pip is only good in virtualenv; anywhere else use the distro's package manager
<pixelherodev>
I use `pip --user` for local installs when packages aren't available in the normal repos
<pixelherodev>
Which isn't often, but happens occasionally
<pixelherodev>
Like, twice, ever
<pixelherodev>
:P
<leeward>
I have a work thing that has to run on CentOS, and the packages I need aren't in the distro so the whole thing goes in a virtualenv that gets installed to the SD card image at build time. Makes it super easy to manage dependencies and debug on the target hardware.
cren has quit [Ping timeout: 260 seconds]
<pixelherodev>
I don't use venvs :P I just install to wherever `pip --user install foo bar` goes lol
<pixelherodev>
Haven't had any conflicts yet :P
<leeward>
"yet"
<pixelherodev>
It's been two years.
<pixelherodev>
I'm pretty confident that it'll be fine
<leeward>
I've been using Python for...a lot longer than that.
<pixelherodev>
I haven't had this laptop set up for all that long lol
<fengb>
I’ve been using python before you were born 🦖
<leeward>
Being able to have python 2 and 3 venvs coexist on the same server is useful.
<leeward>
Also knowing that CI, prod, and dev machines have the same set of packages even when they're running distros, and being able to wipe the whole thing and reinstall without worrying about hosing your system is good.
<fengb>
This is the reason Docker exists :P
<leeward>
I think the first time I looked at Python was either 1999 or 2000.
<leeward>
It is, but I'm not putting docker on my production system.
cole-h has joined #zig
<leeward>
er, running different distros
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pixelherodev>
Relevantly, finally got mnemosyne running without WINE :)
<pixelherodev>
In a glibc chroot for now, until I get around to patching PyQtWebEngine
<pixelherodev>
But this is still a major improvement, since I already had most deps in the chroot anyways, and now I can wipe WINE out of it
<leeward>
\o/
<leeward>
No idea what mnemosyne is, but...cool
marnix has quit [Read error: Connection reset by peer]
jjido has joined #zig
decentpenguin has quit [Quit: ZNC crashed or something]
marnix has joined #zig
manikawnth has joined #zig
<leeward>
looks like I found a regression in translate-c
<danyspin97>
can I convert a packed struct to a []u8?
<leeward>
@bitcast
<leeward>
Though I think it would be a [N]u8 first.
<Nypsie>
There's also std.mem.toBytes
<leeward>
^probably better
<danyspin97>
I'll try it right away
<danyspin97>
what about the opposite?
<danyspin97>
from []u8 to a packed struct?
marnix has quit [Read error: Connection reset by peer]
KKRT has joined #zig
<scientes>
@memcpy
<scientes>
(that is how it should be implemented)
<leeward>
std.mem.bytesAsValue gets you a pointer.
<scientes>
or just @ptrCast()
<pixelherodev>
slice.ptr gives [*]u8, which can be ptrCasted
<pixelherodev>
std.mem is probably better, since a lot of its functions handle low-level details (like endianness) which everyone tends to overlook
frmdstryr has joined #zig
<leeward>
Maybe bytesAsValue should be called fromBytes fro symmetry.
<leeward>
Also for symmetry
recombinant has joined #zig
<danyspin97>
hmm, this struct cannot be packed because it contains []const u8
<gruebite>
Are there any ideas for what the name Zag would be used for? Package manager? :P
<pixelherodev>
I used to call the standard library that
<pixelherodev>
Then Andrew whacked my PR with a rolled up newspaper and I stopped :P
<ifreund>
gruebite: only use case I've heard andrew mention was a name for an unstable/testing branch post 1.0
<ifreund>
I have a theory that 50% of first zig projects are named zag though
<leeward>
ahah, made a minimal example that shows translate-c being broken
<leeward>
Now to turn it into a bug report...
<gruebite>
i already have two projects named zag
<ifreund>
gruebite: ahead of the curve, I like that :D
<ifreund>
my main project was named zag for the first few days, before I found all the others and realized that I was not, in fact, original at all
<leeward>
Er, no I haven't. That was the wrong code.
<gruebite>
i haven't written much zig yet. waiting on c abi
<danyspin97>
allocator.alloc(u8, 18) why does it return []u8 of size 16?
waleee-cl has joined #zig
<pixelherodev>
gruebite: we have a C ABI...
<pixelherodev>
Wait, is it not fully implemented or something?
<pixelherodev>
That wouldn't surprise me too much
<ifreund>
pixelherodev: there's some low-hanging fruit with passing structs by value and whatnot
recombinant has quit [Quit: Leaving]
<Nypsie>
danyspin97: What did you expect it to return?
<danyspin97>
[]u8 of size 18
<pixelherodev>
ifreund: gotcha
<ifreund>
I haven't hit any of it in practice though, and I think I have one of the larger zig projects interfacing heavily with C
<Nypsie>
My bad, for some reason I couldn't see the difference between 18 and 16 haha
<danyspin97>
np xD
wootehfoot has joined #zig
<danyspin97>
i have a packed struct of size 18
<danyspin97>
and @bitPack complains
<Nypsie>
Packed structs are still quite buggy
<danyspin97>
ah, I see
<leeward>
Are all the elements in your packed struct aligned to word boundaries? If not, expect problems.
<danyspin97>
no idea about aligning
<ifreund>
and get excited for stage2 to fix all the bugs :D
<leeward>
Those bugs will get fixed once self hosted is working. They're not necessary for writing a compiler, so they got put on the shelf.
<ifreund>
danyspin97: that seems strange, but I think you'd need to post code if we're to make any sense of why the allocator is returning the wrong size
<leeward>
fengb: That's the thing. I wonder how important it is to be able to build tests in environments without fork.
<leeward>
Seems like not.
<pixelherodev>
Hmm, I disagree, it should be considered important
nikita` has quit [Quit: leaving]
<leeward>
Why?
frett27 has quit [Ping timeout: 260 seconds]
<leeward>
fengb: Amusingly, when I use that (modified to make it work) I get an error return trace printed out with my segfault, followed by "All 12 tests passed."
<fengb>
Yeah I have a special thing that hides stderr
blinghound has quit [Remote host closed the connection]
pmwhite has joined #zig
<pixelherodev>
Tests marked as `std-native-Debug-bare-multi`: what's `bare-multi` there?
* pixelherodev
facepalms
<pixelherodev>
The SPU II branch fails locally too, I just accidentally muted the tests
<pixelherodev>
I eagerly await the day we can use stage2 to work on stage2 :P
<gpanders[m]>
Hey all, when I run 'zig targets' it lists my CPU, OS, and ABI under the "native" section as "x86_64", "macosx", and "gnu", respectively (running macOS). Running 'zig build' with no target specified works just fine, but when I try 'zig build -Dtarget=x86_64-macosx-gnu' I get an error with C importing ("error: C import failed"). I'm assuming the problem is that I'm not actually specifying the correct target, but how do I
<gpanders[m]>
determine what the right target is?
<gpanders[m]>
(For context, I'm trying to write a build script that compiles my program for different architectures, and I'm trying to find the right way to build for macOS)
<fengb>
I don’t think macOS cross compile works right now
<pixelherodev>
I'm 99% sure it doesn't
<fengb>
Might want to try -Dtarget=native_native
<fengb>
Er... native-native
<pixelherodev>
You could do something like `if (host is macos) { build with native_native } else { error that cross-compilation for macos is not supported yet }`
<gpanders[m]>
fengb: yea -Dtarget=native works, but then that wouldn't translate when running the build script on a non-macOS machine, so I was trying to find a more portable solution
<gpanders[m]>
I think for now I'll just cross compile for Linux in my script and manage the macOS binaries manually
<fengb>
We need to port libc headers at the very least