wootehfoot has quit [Read error: Connection reset by peer]
lunamn has quit [Ping timeout: 240 seconds]
<andrewrk>
daurnimator, your fifo code is proving useful for test coverage. currently it's the last remaining std lib test failing, blocking the merge of #3787
<andrewrk>
once we're shipping self-hosted, then this only has to be how much memory it takes to build self-hosted
<stratact>
andrewrk: After getting used to build.zig from before, I appreciate how straightforward it is to link more C libraries with it. In FreeBSD, I find what I need with `find /usr/local/lib -name "*name*"` for the lib object in build.zig and `find /usr/local/include name "*name*"` for the cInclude in the source. Boom, it compiles.
<stratact>
wait, there is more room for it to improve? :)
bjorob has quit [Ping timeout: 250 seconds]
<stratact>
Ah right, a package manager can help automate that.
<stratact>
but I think, as you have said, requires more planning.
Ekho has joined #zig
<pixelherodev>
Gotcha
squeek502 has joined #zig
<daurnimator>
andrewrk: all the talk around align(0) and packed structs happens to align with what I was thinking last night.... about 2 hours before you mentioned them :)
leeward has joined #zig
<daurnimator>
I was looking into capnproto support for zig: I was trying to figure out how to map their concept of unions
<daurnimator>
==> in capnproto, if you have a struct with a union member, it allows members of that union to be spread through the whole struct
<nooga>
ha, just found out that my terminal does font ligatures
<daurnimator>
leeward: isn't everyone ditching mercurial at this point? didn't they refuse to move to python3, and hence everyone is dropping mercurial at python2 end of life in a few months?
<daurnimator>
nooga: terrifying :P
<daurnimator>
nooga: tried putting firacode in there?
<daurnimator>
andrewrk: I'm happy to hear about the value-range-propagation proposal. However I'm scared it might result in a code explosion as different types are passed to a generic.
<daurnimator>
wondering if input to a generic needs to be "marked" for which properties are used
<daurnimator>
e.g. if I have a pure-storage generic, like ArrayList, then the range of the members doesn't really matter for the code: all I really care about is the size of it.
<leeward>
daurnimator, but I like it better, and it will move to py3k eventually.
<daurnimator>
andrewrk: added as a comment on your proposal.
<daurnimator>
andrewrk: let me know if you need me to explain more about what capnproto does: its both a puzzle to figure out how to interface with it from zig; but also it provides us some ideas/concept on how we can do struct layout ourselves...
<andrewrk>
is that the deserialization library that tries to not parse untrusted input? seems misguided
<daurnimator>
andrewrk: its not so much a deserializer as a struct-layout ABI + an RPC protocol
<daurnimator>
andrewrk: 2 main concepts from it: 1. the fastest way to parse is to not parse at all: have a struct ABI thats the same "everywhere" and now no one needs to parse/serialise. 2. RPC with promises; where you can send a request "call function X with the result from function Y" => which looks like: `promise = Y(x,y,z); new_promise = X(promise); result = new_promise.resolve()`
<andrewrk>
ok now we're back to "seems misguided". you can't not parse untrusted input
<andrewrk>
there has to be a layer where you translate input into program state which upholds your data semantics
<andrewrk>
anyway, what's the trouble with matching the ABI?
<andrewrk>
uh, the top half. bottom half is just cleaning up messy codegen
<daurnimator>
oh, another thing, did you see this error message I posted last night: "error: expected type 'usize', found 'i30' note: unsigned 64-bit int cannot represent all possible unsigned 30-bit values"
<daurnimator>
I had a quick look into it... and it seemed like there may be a deeper bug lurking
<andrewrk>
daurnimator, looks like a 1 line fix to me, I typo'd `wanted_type` 2x instead of making the 2nd one `actual_type`
<andrewrk>
"error: expected type 'usize', found 'i30' note: unsigned 64-bit int cannot represent all possible signed 30-bit values"
<andrewrk>
the corrected message is correct
<daurnimator>
ahhhhh'
<daurnimator>
I was looking at the sprintf arguments
<daurnimator>
I didn't look two lines above
<daurnimator>
doh
<daurnimator>
here I was worried that result location was messing up the type's is_signed field
<andrewrk>
will push the fix in a moment
<daurnimator>
no problems. sorry for not looking closer
<andrewrk>
no worries
kapil_ has joined #zig
<daurnimator>
Looks like 3787 touches a lot of things: I'm betting a lot of other PRs will need to be rebased
<andrewrk>
I'm about to merge it too
lunamn_ has quit [Quit: leaving]
<pixelherodev>
3787?
<pixelherodev>
Ah
<andrewrk>
I don't expect anybody to rebase their PRs that are already finished before breaking changes are merged
<daurnimator>
So many interesting proposals lately
muffindrake has quit [Ping timeout: 246 seconds]
muffindrake has joined #zig
<cncl>
just curious: if i'm stuck on mac os 10.12, but want to play with zig, should i use a linux vm? or docker? (i have no idea how to use docker, but i'm presuming this is the sort of thing it gets used for)
mahmudov has quit [Ping timeout: 268 seconds]
noonien has quit [Quit: Connection closed for inactivity]
Spacemonkey2126 has joined #zig
leeward has quit [Quit: Leaving]
<Spacemonkey2126>
Hey folks. I'm checking out zig for the first time. I'm a long time C programmer (20+ years) that has been looking for a Better C for sometime.
<andrewrk>
howdy Spacemonkey2126
<Spacemonkey2126>
I was looking into compile times since that is one of the most important things to me (iteration times are crucial)
<Spacemonkey2126>
The zig binary is significantly larger which probably explains it (zig is compiling a lot more code)
<Spacemonkey2126>
~/prj/zig_eval/01_comp_speed $ ls -la main main-clang main-gcc
<andrewrk>
you're comparing -O2 clang to zig in debug mode, which is unfair to clang
<Spacemonkey2126>
Any ideas on how to reduce the amount of code the compiler sees?
<andrewrk>
but it's a moot point; it's not time to measure compile time perf yet. this is the bootstrapping compiler, it is optimized for simplicity so that we can get to self-hosted status
<Spacemonkey2126>
Sure. But, there's clearly there is probably a couple orders of magnitude more IR being thrown at LLVM than required. Is this expected?
<andrewrk>
yeah, zig has stack traces on in debug builds
<andrewrk>
try getting a segfault :)
<Spacemonkey2126>
Any ideas on how to get a small build down to 200-ish millis
<andrewrk>
try passing --strip, this will disable debug info stuff
<Spacemonkey2126>
Otherwise I'm probably going to have to wait for the stage 2 or stage 3 compiler .. my workflow efficiency is super important to me .. I have large large projects in C that compile fully in under 10s and incrementals in under 1s
<andrewrk>
yeah sounds like you should come back in 1 year
<andrewrk>
but for sure compilation speed is a high priority for self-hosted
<Spacemonkey2126>
(err.. medium size code-wise but they do a lot for the code size)
<andrewrk>
Spacemonkey2126, check the 0.6.0 release notes in april
<Spacemonkey2126>
Ooo --strip is better.. how painful is it to debug a segfault now?
<andrewrk>
I'm sure it's nothing as painful as it would be for me to watch you try to debug a segfault with --strip enabled when we have perfectly good stack traces
<Spacemonkey2126>
Ha.
<Spacemonkey2126>
Okay, well there's probably something workable here.. I will definitely keep an eye out for 0.6.0.. Otherwise, there is a lot pointing in the right directions for zig.. Just don't kill it with feature creap ;-)
<andrewrk>
I'm getting good at saying "no"
<andrewrk>
Spacemonkey2126, oh, also clang is dynamically linking libc and zig is creating a static binary. you can dyn link glibc by using -lc
<andrewrk>
(assuming you're on a glibc system)
dbandstra has joined #zig
<Spacemonkey2126>
I don't have a strong preference on that at this stage (I'm in explore / eval mode).. but I strongly prefer static binaries anyways .. at the moment there is no compile-time speed difference. It seems to all be debug-data overhead that takes it from 200 millis => 1000 millis
<Spacemonkey2126>
Extremely hypothetically, if someone wanted to help Zig reach its build speed goals, what might one help with?
<andrewrk>
with improving the completeness and robustness of std lib's evented I/O support
<andrewrk>
for example, one might start with `zig fmt`, as a smaller project. get all the I/O that that uses to be properly evented, on all OS's, and fuzz test it to make sure there aren't bugs in the event loop implementation
<andrewrk>
self-hosted will be using all the available CPU cores from the very beginning
<andrewrk>
you could also help with https://github.com/andrewrk/zasm once it gets a bit further along (this is the beginning of a non-llvm backend, which is one of the experiments to make things fast)
<Spacemonkey2126>
Okay, thanks. I'll have to think about it. I have a very time-consuming career as is (you know about that...), but I'd really like to see this project succeed.
<Spacemonkey2126>
I appreciate your time. Keep up the good work!
<andrewrk>
thanks
_whitelogger has joined #zig
leeward has joined #zig
adamkowa1ski has joined #zig
_whitelogger has joined #zig
adamkowa1ski has joined #zig
adamkowa1ski has quit [Client Quit]
adamkowalski has quit [Ping timeout: 268 seconds]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 240 seconds]
kapil_ has quit [Quit: Connection closed for inactivity]
adamkowalski has joined #zig
adamkowalski has quit [Ping timeout: 240 seconds]
dbandstra has quit [Quit: leaving]
kapil_ has joined #zig
mahmudov has joined #zig
Spacemonkey2126 has quit [Ping timeout: 260 seconds]
FSX has quit [*.net *.split]
bkleiner has quit [*.net *.split]
tbodt has quit [*.net *.split]
tbodt has joined #zig
bkleiner has joined #zig
FSX has joined #zig
wootehfoot has joined #zig
<mq32>
andrewrk: both #3803 and #3804 are good proposals
mahmudov has quit [Ping timeout: 246 seconds]
<stratact>
oh no... either I'm doing something wrong or the Zig compiler (even freshly built from latest git HEAD) can't import the C macros I need from libjpeg for some reason...
<Snektron>
I think its the latter
* stratact
will take a break from his X11 wallpaper setter project
<adamkowalski>
I'm looking for people to try it out and see what breaks before I submit a PR back to vim-test. So if you hate it, love it, want to throw tomatoes or whatever just let me know and i'll try and improve it and get it ready for use
<andrewrk>
neat, how's that working for you?
<andrewrk>
mikdusan, btw I'm happy to do another comment on #3794 if you prod me with another comment :)
<adamkowalski>
I'm used to that workflow from other languages, so it's nice to have it here too
<adamkowalski>
It supports :TestNearest :TestFile :TestLast :TestVisit
<adamkowalski>
so when you just want to run one test over and over until it works, you move your cursor to the test in question, run :TestNearest
<adamkowalski>
Then you go to the implementation file, start making changes, and then run :TestLast without having to go back to the test file
<adamkowalski>
Once you're happy with it, and you want to write your next test you can :TestVisit to go back to the test file no matter where you currently are
<adamkowalski>
Then as a sanity check you can :TestFile and commit and push
<adamkowalski>
I still haven't figured out how to implement :TestSuite though. I could use some help with that
<andrewrk>
my only complaint would be that :TestFile is 12 keystrokes but alt+tab, up, enter is 4
<andrewrk>
but I suppose that's what one's vimrc file is for
<adamkowalski>
Oh yeah I would never type that out manually
<adamkowalski>
I have it set to <leader>tf
<adamkowalski>
for test file
<andrewrk>
neat
<adamkowalski>
<leader>tn
<adamkowalski>
and so on
Spacemonkey2126 has joined #zig
<Spacemonkey2126>
I've been doing some more testing, comparing C vs Zig esp in respect to code-gen on simple examples. I'm using LLVM in both cases to help make it more isolated.
<andrewrk>
oh lovely, godbolt has zig asm code again
<Spacemonkey2126>
For the most part, very similar .. most differences explainable by different codegen decisions, zig having inlining that is too aggressive, etc
<Spacemonkey2126>
But, I was caught massively off-gaurd by an implicit copy which surprised me. To me, this is one of my biggest gripes with C/C++ and was hoping this would be better given Zig's Philosophy (There is no hidden control flow, no hidden memory allocations, no preprocessor, and no macros. If Zig code doesn't look like it's jumping away to call a