<scientes>
I mean, yes I myself copied some out of musl to do the amd64 patch
<scientes>
and having the ability to build C is awesome
<andrewrk>
this is going to unlock C and C++ libraries for being packaged up with zig package manager
<scientes>
but the stdlib still cannot depend on libc?
<andrewrk>
correct the stdlib does not depend on libc
<scientes>
which means we have to do our own TLS
<andrewrk>
it's more complicated than that though. on some systems (freebsd, macos, netbsd, openbsd) libc *is* the syscall interface
<andrewrk>
further, if the binary *will* be linked with libc, zig std library makes some different choices. for example using pthreads
<andrewrk>
which I believe is desirable behavior
<scientes>
agreed
<scientes>
it looked like a bunch of co-routine stuff disappeared from the code when I looked at it recently
<scientes>
in prep for the re-write
<andrewrk>
let me finish my rant real quick - re: unlocking C and C++ libraries for being packaged up with zig package manager
<andrewrk>
so now, 2 things happen
<scientes>
nvm ir_gen_async_return is still the monstrosity it was
<andrewrk>
1. actual C and C++ programmers switch to zig build so that they can use zig package manager and actually have C/C++ dependencies, which nobody does right now because it's too annoying
<scientes>
packaging C and C++ is a huge pain in the ass, so much that meson-build re-invented the wheel recently
<andrewrk>
I got interrupted, back later
<scientes>
I am fluent with the way debian does it, which is probably the most robust (at least for C, which supports symbol files), but it still could be improved
<scientes>
Is there any write-up on how the package manager will work
<scientes>
like will it interact with rpm and dpkg if they are there?
<scientes>
and the Arch package manager
<andrewrk>
it's entirely independent from system package managers. think of it like a project-local package manager.
<andrewrk>
anyway, 2. zig programmers turn C/C++ libraries into zig packages (it's a matter of switching build systems) so that they can use them. so between (1) and (2) zig programmers and c/c++ programmers help each other directly
<andrewrk>
3. C/C++ programmers now depend on zig for the build system (and potentially even building their code to some degree), and so now it's 0 additional dependencies to write some .zig code for their project. that's how we take over the world
<scientes>
it is just that if your program is graphical you DO have dependencies, at least on Linux
<scientes>
particularly on libwayland or libxcb/libx11
<scientes>
but yeah that sounds like a great plan
<andrewrk>
graphical programs is one use case for targeting glibc
<andrewrk>
point being that zig will be able to build entire dependency chains without accessing any files outside the zig installation, which makes it work reliably on all targets
<andrewrk>
which is the requirement for having a dependency
<scientes>
and then build statically
<scientes>
yeah that is quite nice
<andrewrk>
I'm planning on creatign a detailed design document for zig package manager shortly after 0.4.0 release
<andrewrk>
and then full steam ahead on solving the blockers (copy elision, non-allocating-coroutines)
<scientes>
non-allocating-coroutines: unless creating threads of course?
<andrewrk>
what do you mean?
<andrewrk>
the coroutine can do anything, allocate memory, create a thread, call os.exit(1)
<andrewrk>
by non-allocating-coroutines I mean that the creation of a coroutine itself does not use an allocator
<scientes>
yes
<scientes>
you just pass it a stack
<andrewrk>
after the rewrite that will look like: var stack = coroutineName()
<andrewrk>
which is why it depends on no-copy-semantics
darithorn has quit [Remote host closed the connection]
<wilsonk>
andrewrk: did something change since you posted the GeneralPurposeDebugAllocator code? It won't build out of the box on linux for me. error: expected pointer found usize at line 200 std.debug.captureStackTrace(@ptrToInt(@returnAddress()), &stack_trace);
<scientes>
try removing the @ptrToInt( and the closing brace
<wilsonk>
scientes: yeah, I got that part ;) Just wondering when the change took place as I can't see it in any code being pushed is all
<wilsonk>
scientes: also the function signature in std.debug seems to show that a usize is optional as the first argument...or am I missing something?
<scientes>
I didn't look at the code, I just read the error ;)
<wilsonk>
scientes: ah, ok
darithorn has joined #zig
<scientes>
woah, glibc FINIALLY got <threads.h> support
<andrewrk>
wilsonk, yes, @returnAddress now returns a usize. I pushed an update
<wilsonk>
ok, cool thanks andrewrk
noonien has quit [Quit: Connection closed for inactivity]
kristate has joined #zig
scientes has quit [Ping timeout: 245 seconds]
diltsman has joined #zig
darithorn has quit [Remote host closed the connection]
return0e_ has joined #zig
return0e has quit [Ping timeout: 252 seconds]
jjido has joined #zig
jjido has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hryx has quit [Ping timeout: 252 seconds]
kristate has quit [Remote host closed the connection]
kristate has joined #zig
jjido has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Remote host closed the connection]
kristate has joined #zig
_whitelogger has joined #zig
gamester has quit [Remote host closed the connection]
return0e has joined #zig
return0e_ has quit [Ping timeout: 255 seconds]
dewf has quit [Quit: Leaving]
hryx has joined #zig
very-mediocre has joined #zig
noonien has joined #zig
hg has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
kristate has quit [Remote host closed the connection]
kristate has joined #zig
kristate has quit [Ping timeout: 252 seconds]
jjido has quit [Quit: Connection closed for inactivity]
arBmind has joined #zig
<arBmind>
!nick arBmind
<arBmind>
hi :)
<andrewrk>
hi arBmind
<arBmind>
andrewrk: I like your live streams a lot! great respect - I tried the same in the summer, but gave up because it seemed quite unproductive.