jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<daurnimator>
So notable observation re: linking and static binaries. go recently had a new release which includes security fixes to e.g. net/http. To bring in these fixes we have to rebuild every go package.... which is going to take on the scale of days... and every user of all go packages in the world is going to need to redownload their program. Say "no" to static linking!
<shachaf>
Say "yes" to static linking, and also to being able to deploy bug fixes easily.
<Tetralux>
It taking days sounds like a failure of the go compiler...
<Tetralux>
It should take less than one second to rebuild everything from scratch.
<fengb>
Go compiler is pretty fast
<daurnimator>
Tetralux: huh? compiling e.g. chezmoi takes me about ~8 minutes locally
<Tetralux>
There's no way in hell that compiling anything should take that long.
<Tetralux>
That is a travesty.
<Tetralux>
I can believe it though.
<daurnimator>
I see you haven't met e.g. webkit
<daurnimator>
I think last time I compiled webkit it took ~15 hours
<Tetralux>
Well.
<Tetralux>
****.
<fengb>
Have you tried Rust? It makes C++ look fast :P
<Tetralux>
YUP.
<daurnimator>
but that's all fine
<daurnimator>
the issue is that a bug fix in the standard library or some other core/heavily used library *shouldn't* require a recompile of the whole program. and note that build caches are *not* a solution.
<Tetralux>
I don't want build caches. I want fast compilation personally.
<shachaf>
Recompiles should be fast and easy. For Go code that's mostly true (for C++ it's not true, but I guess the usual answer is to cache object files or something).
<daurnimator>
shachaf: a good distro always compiles in a clean environment.
<shachaf>
Dynamic linking only "solves" a pretty small fraction of bug fixes. You need to be able to handle the rest anyway.
<daurnimator>
shachaf: the issue is having to "rebuild the world" instead of a specific library/program
<shachaf>
If you're willing to reuse dynamic libraries, you should be willing to reuse object files.
<daurnimator>
shachaf: not at all: you can depend on other packages; you can't depend on temporary build artifacts.
<shachaf>
Other packages can export .a files, though?
<daurnimator>
Yes you can have static library packages.
<shachaf>
If the bug fix requires an API change, or is somehow in the way you're interfacing with a library, changing dynamic libraries won't help you.
<daurnimator>
shachaf: it does though: an API change usually only propagates to "one package up". C depends on B depends on A. if A changes API, B will need a recompile but C won't
<shachaf>
Before you deploy a dynamic library change, you're going to want to test it with your dynamically linked executable anyway. You're not going to just change a globally-installed .so and hope ffor the best (right?).
<daurnimator>
shachaf: of course you do. that's standard practice for decades.
<Tetralux>
If an api changes, you don't necessarily want it just changing under the apps feet.
<Tetralux>
Because the person making the app wants assurance that it works.
<Tetralux>
And to do that, you vendor a particular version.
<Tetralux>
You don't then change it without vetting it works.
<shachaf>
OK, you should specify your deployment environment probably.
<daurnimator>
Tetralux: sorry, I should clarify: I was speaking to the case of an ABI change with same C API (e.g. changing a C function to a macro)
<shachaf>
I generally agree with Tetralux.
<daurnimator>
shachaf: every linux distro I know of
<daurnimator>
and brew...
<scientes>
Ulrich Drepper wrote a great paper about this
<shachaf>
I was thinking of server environments where you prefer to control everything.
<shachaf>
But I think it's not that different elsewhere.
<daurnimator>
shachaf: and those are usually a mainstream linux distro (otherwise you're going to be in a world of security pain)
<shachaf>
If you want your deployment to be reliable, you should be able to test your program in exactly the environment you're deploying too, as much as you can.
<shachaf>
Nowadays people use "containers" which are like a bad version of static linking.
<daurnimator>
shachaf: the companies doing containers right are rebuilding them daily with security updates.
<fengb>
I like containers because it's the least bad way I've seen that lets me specify an environment as code
<daurnimator>
there's a few companies/services out there that they outsource it to
<shachaf>
So instead of rebuilding your container you should rebuild your static binaries.
mq32 has quit [Ping timeout: 246 seconds]
<fengb>
... implementing a streaming parser is so much simpler with async functions
<daurnimator>
fengb: oh? have you been practicing?
marijnfs has joined #zig
<fengb>
I'm working on protobufs for funsies, and making the encode async would remove the need for an allocator altogether
<fengb>
I could fake it with a "large enough" buffer but that's super brittle
<daurnimator>
fengb: I figure you'd pass an "output" function sort of like std.fmt.
<daurnimator>
fengb: if the output function was async under the hood... then it should "just work"
<fengb>
Well I was gonna return []u8 per chunk but a callback would work too
<shachaf>
A state machine API is generally nicer than a callback API.
marijnfs__ has quit [Ping timeout: 246 seconds]
<daurnimator>
shachaf: yes. however you can create a state machine API with a callback API now that we have async
<daurnimator>
and callback APIs are generally easier to write + debug
<fengb>
callback might be better actually since you don't need to have extra copies
<fengb>
nvm... it'll be there, just a bit more hidden lol
<daurnimator>
fengb: howso?
<fengb>
I might be typing faster than I’m thinking
<shachaf>
Presumably "async" makes it easy to write either one?
<daurnimator>
shachaf: async makes them isomorphic instead of opposed design philosophies
<fengb>
Yeah, the hard part is saving half written state
kristoff_it has joined #zig
<fengb>
Like buffer is only 1kb but the data is bigger
<fengb>
Async should just be suspending in the for loop when the buffer fills up
kristoff_it has quit [Ping timeout: 245 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<fengb>
Been awhile since I've built Zig. Cmake no longer spits out reams of useless info!
waleee-cl has quit [Quit: Connection closed for inactivity]
<daurnimator>
fengb: yeah zig now uses `zig build` for the final stages of building :)
tgschultz has quit [Quit: Going offline, see ya! (www.adiirc.com)]
ltriant_ has joined #zig
ltriant has quit [Ping timeout: 272 seconds]
_whitelogger has joined #zig
<fengb>
Is there a way to check whether a frame is complete?
<daurnimator>
no
<daurnimator>
scientes: I thought @intToFloat errored if there was precision loss?
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
mla has quit [Quit: WeeChat 2.2]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
mq32 has joined #zig
laaron has quit [Remote host closed the connection]
<fengb>
If I just assign this, it creates bad LLVM IR
<fengb>
I’m out at lunch so don’t have the error message
<andrewrk>
i agree that appears to be related to the recent result location semantics rather than async/await
wootehfoot has joined #zig
Akuli has joined #zig
<andrewrk>
Oh. Never mind. Actually that is the problem of needing to "spill" more stuff after resuming from suspend
casaca has quit [Ping timeout: 272 seconds]
casaca has joined #zig
<andrewrk>
By introducing a separate variable you've worked around the problem by manually spilling the value
<fengb>
Oh
<nrdmn>
andrewrk: is building with BUILD_SHARED_LIBS=ON supported or planned to be supported?
<andrewrk>
where do you see this build option defined?
<nrdmn>
it's defined by gentoo's build framework
<andrewrk>
what is it supposed to do?
<andrewrk>
are you talking about stage1 or zig build system?
<nrdmn>
I'm talking about stage1
<nrdmn>
it's supposed to make cmake build shared libraries
<nrdmn>
I don't know anything about cmake, sorry :/
<andrewrk>
the build artifact of stage1 is zig binary, no installed libraries are produced
<nrdmn>
the gentoo maintainer that I am working with wants me to figure out how to build it with BUILD_SHARED_LIBS=ON instead of overriding the build framework's default
<nrdmn>
I think I've found a solution, let me just check...
<andrewrk>
what is the gentoo maintainer trying to accomplish? if I understand that I can probably suggest a better solution
<andrewrk>
I'm happy to talk with them, are you in #gentoo?
<nrdmn>
just joined
<nrdmn>
but I think my solution works
<nrdmn>
wait, I'll just push it
wootehfoot has quit [Read error: Connection reset by peer]
<nrdmn>
apparently this is due to CMakeFiles/embedded_softfloat.dir/deps/SoftFloat-3e/source/8086/s_propagateNaNF32UI.c.o and CMakeFiles/embedded_softfloat.dir/deps/SoftFloat-3e/source/8086/s_propagateNaNF64UI.c.o not being built
Akuli has quit [Quit: Leaving]
<nrdmn>
I have no idea why it fails with BUILD_SHARED_LIBS=ON and not with BUILD_SHARED_LIBS=OFF
<andrewrk>
I still don't understand what the goal is here
<andrewrk>
what's the problem with status quo?
<nrdmn>
I have no idea
<andrewrk>
I'm guessing they want zig to dynamically link against softfloat
<andrewrk>
against *system* softfloat. not produce a dynamic softfloat library
wootehfoot has quit [Read error: Connection reset by peer]
<andrewrk>
I would be willing to accept a patch which adds an option ZIG_FORCE_EXTERNAL_SOFTFLOAT
<nrdmn>
doesn't the build breaking when s_propagateNaNF32UI.c.o and s_propagateNaNF64UI.c.o are missing indicate that it tries to link against your softfloat lib?
<andrewrk>
I don't understand your question, but the reason it works as a static lib (and the reason I purposefully don't compile unneeded files) is that with static libs, unused functions are deleted
kristoff_it has joined #zig
<fengb>
I wasn't necessarily going towards async functions at first, but I had a hard time iterating through the fields. So I figured why not!
<mikdusan>
i think what's happening is nrdmn build error is caused *because* they build zig's bundled softfloat as a .so
<mikdusan>
and it doesn't like the unresolved symbols. whereas .a let's you get away with it.
kristoff_it has quit [Ping timeout: 272 seconds]
<mikdusan>
in other words: zig.exe finds everything it needs and any those unref are never used so who cares. making softfloat.so is different, you have to resolve undefs by default. ie: build the missing .c, or using a different .so creation flag to ignore undefs
<andrewrk>
there's no reason for zig to produce a dynamic library from its bundled softfloat. nobody wants that. I guarantee you if the gentoo maintainer wants something other than status quo, they want zig to link against system softfloat .so
<andrewrk>
I personally would prefer if the maintainer would let me bring my own static libs to the table, but I understand the arguments against it
<mikdusan>
i agree. just saying *that* is what error build is doing: building zig's copy of softfloat as .so
<andrewrk>
agreed
<mikdusan>
nrdmn: to simplify i think you have 2 options:
<mikdusan>
1. obviously leave it as-is and use bundled static build style
<mikdusan>
2. provide a patch as andrew suggested to support: ZIG_FORCE_EXTERNAL_SOFTFLOAT where it links to whatever kind of softfloat library your project wants.
<nrdmn>
mikdusan: they said nothing about linking against system softfloat. I don't think this is the reasoning behind the BUILD_SHARED_LIBS=ON requirement