ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 258 seconds]
cenomla has quit [Quit: cenomla]
hasen_judy has joined #zig
hasen_judy has quit [Quit: hasen_judy]
dimenus has joined #zig
hasen_judy has joined #zig
dimenus has quit [Read error: Connection reset by peer]
<andrewrk>
hasen_judy: this happens when the @cImport generated invalid zig code. I'll need to reproduce this and find out why this is happening
hasen_judy has joined #zig
<andrewrk>
also you should try to use only 1 @cImport block if you can
hasen_judy has quit [Remote host closed the connection]
_dev_zero has joined #zig
hasen_judy has joined #zig
hasen_judy has quit [Remote host closed the connection]
cenomla has quit [Quit: cenomla]
hasen_judy has joined #zig
cenomla has joined #zig
hasen_judy has quit [Ping timeout: 258 seconds]
benq has joined #zig
benq has quit [Client Quit]
_dev_zero has quit [Ping timeout: 248 seconds]
_dev_zero has joined #zig
cenomla has quit [Quit: cenomla]
<dimenus>
hey andrewrk, I have to include a bunch of extra declarations for COM classes, is there a particular file you'd like me to put that in?
<dimenus>
header file is about 900 lines
<dimenus>
(but written by Microsoft)
<andrewrk>
dimenus, just try to isolate it so that only 1 cpp file has to include it, so it doesn't bog down our compile time
steveno has joined #zig
hasen_judy has joined #zig
hasen_judy has quit [Ping timeout: 246 seconds]
redj has quit [Ping timeout: 248 seconds]
<steveno>
how exactly does one run the test suite on posix?
<steveno>
i tried " bin/zig build --build-file ../build.zig test" mimicing the windows instructions but that fails for me
<andrewrk>
steveno, the readme instructions should work
<andrewrk>
what error do you get?
<steveno>
make coverage is not a target
<steveno>
i'm missing lcov. hold on.
<steveno>
nope. still coverage is still not a target
<steveno>
nevermind. ignore me.
<andrewrk>
steveno, tests working now?
radens has left #zig ["WeeChat 1.0.1"]
<steveno>
well, no, but I don't think it's zig's fault
<steveno>
i forgot to add -DZIG_TEST_COVERAGE=ON to my cmake command
<andrewrk>
I don't think you want test coverage on
<andrewrk>
I think you want the steps under the "Debug / Development Build"
<andrewrk>
and nothing else
<steveno>
OHH
<steveno>
"./zig build --build-file ../build.zig test" runs the test suite!?!?
<andrewrk>
steveno, yes, the tests are self-hosted
<steveno>
i did not get that from the readme. my bad.
<andrewrk>
when the whole compiler is self-hosted, it will be `zig build` from the root dir - the weird command is because the build process is partially c++, partially zig
hasen_judy has joined #zig
* steveno
schooled
<andrewrk>
I mean, if you're confused it's because the instructions are confusing. sorry about that
<andrewrk>
hasen_judy, did you get my reply?
hasen_judy has quit [Ping timeout: 258 seconds]
<GitHub112>
[zig] scurest opened pull request #563: Improved printing for floats (master...float-printing) https://git.io/vdjwT
redj has joined #zig
<steveno>
finally got it working. 301 tests passed!
<steveno>
should I be concerned it was "Unable to determine libc lib path."?
<andrewrk>
steveno, what os are you on?
<andrewrk>
zig is configured without knowing where libc is, and I'm guessing you probably want to use c libraries
<dimenus>
andrewrk, I seem to have either found a bug with ZigList or am just misunderstanding the purpose of 'buf_alloc_fixed'
<dimenus>
it resizes the array as exected, but it also sets the length (which I would interpret as the number of chars in the buffer) to the assigned length
<dimenus>
rather than 0
<dimenus>
capacity is then added to the length, so the buffer ends up being way larger than expected with a bunch of debugger initialized data ;)
<andrewrk>
dimenus, yeah Buf/ZigList are made to have amortized O(log2(N)) append operation
<andrewrk>
that's probably the wrong data structure for a lot of things, it could be optimized
<andrewrk>
dimenus, you may notice we also don't free memory anywhere in the compiler
<andrewrk>
I'm planning for the self hosted version to have proper memory management and concurrency and all that good stuff
<dimenus>
i can work around it by just not using buff_alloc_fixed for now as the regular buff_alloc sets length appropriately (because it passes 0 to buff_alloc_fixed)
pupp has quit [Read error: Connection reset by peer]
pupp has joined #zig
<andrewrk>
dimenus, it's still going to have the extra capacity when you add it to the buf though. how much memory are you putting in there?
<dimenus>
MAX_PATH (260 on windows 10)
<andrewrk>
dimenus, just use buf_alloc_fixed, the extra capacity is negligible
<dimenus>
it's not the capacity that's the issue, it sets the length to the wrong value
<dimenus>
so when you append(), it's to the middle of the buffer
<dimenus>
not the beginning
<andrewrk>
dimenus, hmm you should use buf_len for the length
<andrewrk>
it's used everywhere; I don't think it's wrong
<andrewrk>
I guess this is what I get for not using private:
<andrewrk>
pretend Buf::list is private
<dimenus>
hah, will do
steveno has quit [Quit: steveno]
<dimenus>
hmm, probably just understanding it wrong then. I think of it like 'alloc and ensure capacity', is that wrong?
<andrewrk>
dimenus, that is correct
<andrewrk>
it ensures a capacity in memory, but the "length" of the buffer is independent of the capacity
<andrewrk>
and the 0 byte is after the length
<andrewrk>
so if you pass, e.g. buf_ptr(buf) to a win32 api, it's going to look for the null byte and find it in the correct position
Benj has joined #zig
<Benj>
zw
Benj is now known as Guest72714
<Guest72714>
Hello … I understand zig uses LLVM. Is it also partly self hosting (in terms of its compiler)?
<andrewrk>
Guest72714, the tests are all self hosted
<Guest72714>
The compiler is written in c++? (from quick look at the source)
<andrewrk>
Guest72714, yes
<dimenus>
ok, so I have msvc working through both COM and the registry
<dimenus>
now on to kernel32...
<dimenus>
which apparently does not have a consistent key or interface