karrick has quit [Read error: Connection reset by peer]
karrick has joined #zig
<andrewrk>
for now it's recommended to use it with `zig test` because the tests tend to reference more decls making more things show up
jzelinskie has quit [Ping timeout: 260 seconds]
jzelinskie has joined #zig
ovf has quit [Ping timeout: 272 seconds]
eddyb[legacy] has quit [Ping timeout: 240 seconds]
<vramana>
andrewrk: Should this command work ./zig test -femit-docs ./lib/std/std.zig ?
ovf has joined #zig
eddyb[legacy] has joined #zig
<andrewrk>
vramana, I would do: ./zig test ../lib/std/std.zig -femit-docs -fno-emit-bin
<andrewrk>
vramana, looks like it will put the docs in the cache directory if you do that, you can use `--output-dir .` to make it put the stuff in a docs/ directory in the cwd
<vramana>
andrewrk: Many tests currently fail with error: expected type '*mem.Allocator', found '*std.mem.Allocator'
<andrewrk>
I just tried it on latest master branch
<andrewrk>
I think you have a collision between 2 lib folders
<andrewrk>
make sure you are running the test on the same copy of the std lib that zig uses as its detected std lib path
<andrewrk>
(you can check this path with `./zig env`)
<andrewrk>
side note, I'm not sure why the std lib cache_hash blake3 hashing of files is so slow
<vramana>
andrewrk: The std lib path seems to be inside the build folder. But I now get a different error. ./lib/zig/std/crypto/md5.zig:248:15: error: unable to find 'test.zig'
<andrewrk>
the std lib tests require a source checkout
<andrewrk>
I recommend to delete your second copy of the zig lib directory and rely only on the one found in the source tree
<vramana>
Then how would zig env know it? All I did now was run make install to build the zig binary and using that to generate documentation. Now I should change std lib the zig binary uses to lib/std folder from the source is that what you are saying?
ur5us has quit [Ping timeout: 240 seconds]
nvmd has quit [Quit: Later nerds.]
ur5us has joined #zig
<pixelherodev>
What portion of comptime did vexu add earlier?
gpanders has quit [Ping timeout: 240 seconds]
jicksaw has quit [Quit: ZNC is kill]
jicksaw has joined #zig
mgxm has quit [Ping timeout: 272 seconds]
gert_ has joined #zig
mgxm has joined #zig
cr1901_modern has joined #zig
gpanders has joined #zig
waleee-cl has quit [Quit: Connection closed for inactivity]
gert_ has quit [Quit: WeeChat 2.8]
iwq has quit [Ping timeout: 260 seconds]
iwq has joined #zig
cole-h has joined #zig
_whitelogger has joined #zig
<pixelherodev>
Ah crap. Worse than the battery capacity being diminished is that the charge time is much *muchhh* higher now. That'll make Zig work a PITA since stage1 is so CPU-intensive :(
<pixelherodev>
Guess I just got to stay in range of the buildbuddy at all times :P
hspak has joined #zig
craigo has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 240 seconds]
<pixelherodev>
Would anyone here be interested in a Gentoo overlay to fix the LLVM issues when building Zig?
doublex_ is now known as doublex
<Ristovski>
pixelherodev: What issues? Not that I've attempted to compile Zig myself on Gentoo
<Ristovski>
well hmm, I already have llvm 11
<pixelherodev>
Ristovski: The Gentoo ebuilds for LLVM 10+ remove important shared libraries that Zig depends on
<Ristovski>
pixelherodev: Oh /that/. Yeah I remember hitting that issue with some other software that depends on the libs
<pixelherodev>
Which requires a full rebuild with a modified ebuild to work around, currently (this is somewhat ameliorated if ccache is installed with a large enough cache size)
<Ristovski>
Yeah I think I just hacked something horrible together in the meantime
<Ristovski>
pixelherodev: It was a configuration step flag that enables those, right? (can't remember now)
<pixelherodev>
Yep, I did the same thing.
<pixelherodev>
twas a hassle, because it required updating the hash
<pixelherodev>
Hmm. I'm thinking long-term instead of making my own distro (as I've discussed in the past), I'd want to write a replacement for portage (probably in Zig, but distributed as C produced via CBE for more convenient builds), and eventually just write ebuilds which depend on IR sources instead of the original source
<Ristovski>
As in, it would fetch IR instead of source code for packages?
<pixelherodev>
It'd result in, effectively, an upstream-Gentoo-compatible system, distributing per-architecture IR and optimizing it (with -march=native or equivalent) on install
<Ristovski>
I see. I think intels clear linux guys thought of doing the same thing, no idea if they ever did anything
<pixelherodev>
Native portage (instead of python) means faster dep calculations (which have been annoyingly long on multiple occasions for me), and pre-optimized IR means build times on par with *binary* distros
<pixelherodev>
I wouldn't hope to compete with, say, Alpine, but maybe more like Debian install times
<Ristovski>
Heh, dependency checks have become so long for me that I remember all the dependencies (for the most common stuff I recompile) myself
<Ristovski>
so I just pass --nodep
<pixelherodev>
*Ouch*.
<pixelherodev>
See that's kinda my point.
<pixelherodev>
Portage is the one pain point I have with Gentoo
<Ristovski>
Indeed
<pixelherodev>
Says a lot that a core feature is the only pain point *and it's still the best OS I've used*
<pixelherodev>
Alpine's the only one that comes *close*
cr1901_modern has quit [Quit: Leaving.]
rzezeski has quit [Quit: Connection closed for inactivity]
cole-h has quit [Quit: Goodbye]
dddddd has quit [*.net *.split]
creationix has quit [*.net *.split]
leeward has quit [*.net *.split]
[RMS] has quit [*.net *.split]
marler8997_ has quit [*.net *.split]
haliucinas has quit [*.net *.split]
[RMS] has joined #zig
creationix has joined #zig
dddddd has joined #zig
leeward has joined #zig
haliucinas has joined #zig
marler8997_ has joined #zig
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #zig
drawkula has joined #zig
yeti has quit [Ping timeout: 256 seconds]
iwq has quit [*.net *.split]
mgxm has quit [*.net *.split]
traviss has quit [*.net *.split]
blueberrypie has quit [*.net *.split]
mgxm has joined #zig
iwq has joined #zig
blueberrypie has joined #zig
traviss has joined #zig
kushalp has quit [Ping timeout: 265 seconds]
r0bby has quit [Read error: Connection reset by peer]
procnto has quit [Ping timeout: 260 seconds]
karrick has quit [Read error: Connection reset by peer]
r0bby has joined #zig
procnto has joined #zig
karrick has joined #zig
kushalp has joined #zig
riba has joined #zig
traviss has quit [Remote host closed the connection]
traviss has joined #zig
KoljaKube has joined #zig
riba has quit [Ping timeout: 272 seconds]
<pixelherodev>
Wow, ELF loader for SPU II tests was downright trivial :)
<ikskuh>
as said
<pixelherodev>
Getting it to stop infinite looping is a bit harder :P
<pixelherodev>
Hmm. It's infinite-looping :(
<pixelherodev>
I mean, in the interpreter :P
<pixelherodev>
`Test [1/1] test "self-hosted"...tests [23/23] SPU-II Basic Test [1/1] update [5/4] Infinite loop detected in SPU II test!` Eh, better than before :P
<pixelherodev>
Ohhhhh, it's still using four byte pointers in the GOT, so it's getting 0x0000 as the target addr of the function call :P
dingenskirchen has joined #zig
dingenskirchen has quit [Client Quit]
<pixelherodev>
ikskuh: got it passing :D
<ikskuh>
\o/
<pixelherodev>
Pushed :D
<pixelherodev>
Just need to address andrew's comments
<ifreund>
@intToPtr(@ptrToInt()) is the only way to const cast in zig, and I think it's technically UB
<KoljaKube>
ifreund: @typeName(@TypeOf(translate)) looks good, does that count for something?
<ifreund>
can't say, what's the type of cc.glmc_translate?
<pixelherodev>
If you're constcasting, there's probably a problem
<KoljaKube>
ifreund: intToPtr(ptrToInt()) and requiring everything to be var is what I'm trying to get rid of
<ifreund>
My theory is that you have to @intToPtr(@ptrToInt()) the function itself
<KoljaKube>
void glmc_translate(mat4, vec3)
<pixelherodev>
ew
<pixelherodev>
If you need to do that, try to find a better way to accomplish the task
<pixelherodev>
If you need to cast the function type to be able to call it, something *will* break at some point
<pixelherodev>
It's just a matter of time
<KoljaKube>
Mhkay
<KoljaKube>
I had hoped that *adding* const shouldn't be too bad (since I know the implementation, and that it will not change)
<ifreund>
maybe you can get a patch merged upstream
<pixelherodev>
Adding const should be fine.
<KoljaKube>
pixelherodev: But that's what I do
<KoljaKube>
ifreund: Just checked, can't intcast the function ptr
dingenskirchen has quit [Quit: ZNC 1.7.5 - https://znc.in]
<KoljaKube>
It is apparently a runtime value, I don't want to add actual function pointers
<pixelherodev>
KoljaKube: Did you break it down into subexprs?
<pixelherodev>
Always double check these things
<KoljaKube>
pixelherodev: I wrote something above, because I'm not completely sure what you meant
dingenskirchen has joined #zig
<KoljaKube>
ifreund: The thing is, the library has a lot of functions, and does not use const. I would need to annotate all functions for that to make sense
<pixelherodev>
KoljaKube: exactly that
<KoljaKube>
Which is why I hoped to just add the const in zig to all the functions I actually use
<KoljaKube>
Error points at the p in pv inside the call
<pixelherodev>
instead of `a(foo(), bar())`, you split the foo and bar out of it
<KoljaKube>
So, no additional information, aside that constCPtr does it's job
<KoljaKube>
I guess I'll stick to staying const-correct in zig and intcasting away the const when calling C
<pixelherodev>
KoljaKube: the issue that you linked is the other way around
<pixelherodev>
They were trying to pass const values to non-const params, which is (of course) invalid
<pixelherodev>
There's nothing problematic about const in C
<KoljaKube>
The referenced PR (86) marks the correct parameters as const
<KoljaKube>
- glm_translate(mat4 m, vec3 v) {
<pixelherodev>
Yes... and?
<KoljaKube>
+ glm_translate(mat4 m, const vec3 v) {
<KoljaKube>
Maybe I misunderstood "other way around"
<pixelherodev>
Adding const to a parameter that isn't modified is never an issue
<KoljaKube>
Sure
<KoljaKube>
Then they didn't manage to call their functions correctly afterwards, I guess?
<KoljaKube>
Ah well, worst case I will need to actually make some things var instead of casting there in the future, best case I can remove the casts if the code is changed upstream
<KoljaKube>
I happy for a short time when the compiler accepted by function cast ;-)
<KoljaKube>
From a technical perspective, does it make sense that packed unions are align(1)? That would make their contents unusable in some circumstances, wouldn't it?
<fengb>
You can manually align the first element to force the struct alignment
<KoljaKube>
Not for unions
<KoljaKube>
Not yet, anyway
<KoljaKube>
normal unions inherit, but packed ones don't