<pixelherodev>
Is there an idiomatic way to sort an ArrayList?
<pixelherodev>
Without needing to allocate a new one
mokafolio has joined #zig
<pixelherodev>
Huh, there's a std.sort?
<gonz_>
Yeah, I don't think the ArrayList holds on to any pointer to any significant element, so you can sort the `array_list.items`, I think...?
<pixelherodev>
Yeah exactly
<pixelherodev>
It definitely doesn't hold on to anything
<pixelherodev>
Wasn't arrare (pun, not typo ;) there was a slice sorter at all
<pixelherodev>
n * log(n) vs pow(n,2)... I know math even if I don't know formal programming, and log n is obviously smaller than N, so std.sort.sort is probably the best option?
<gonz_>
I've never even bothered checking which sorts we had in the standard library
<gonz_>
I have used it, though
<pixelherodev>
Yeah, std.sort.sort is probably the best opion
<pixelherodev>
option
<pixelherodev>
Hmm, the sort is going to be painful
<pixelherodev>
It's not as straightforward as I'd like
<pixelherodev>
It might be easier to just add local labels first and sort those instead
<pixelherodev>
Labels currently consist of "name", "block", and "offset" (within the block)
<pixelherodev>
Items within the same block should be sorted by offset, but if the block is different the sort is meaningless
<pixelherodev>
The important part is that labels with the same block should be next to each other...
DpEpsilon_t has quit [Ping timeout: 245 seconds]
aerona has quit [Ping timeout: 260 seconds]
satchmo has quit [Ping timeout: 260 seconds]
alexnask has quit [Quit: Leaving]
<pixelherodev>
Ohh! I can use the block address!
<pixelherodev>
That'll sort blocks with each other, but with a few tweaks it should be sufficiently efficient
<pixelherodev>
That makes labelLess as simple as `return @ptrToInt(lhs.Block) < @ptrToInt(rhs.Block) or (lhs.Block == rhs.Block and lhs.Offset < rhs.Offset);return @ptrToInt(lhs.Block) < @ptrToInt(rhs.Block) or (lhs.Block == rhs.Block and lhs.Offset < rhs.Offset);`
<pixelherodev>
Whoops
<pixelherodev>
double paste dammit
<pixelherodev>
`return @ptrToInt(lhs.Block) < @ptrToInt(rhs.Block) or (lhs.Block == rhs.Block and lhs.Offset < rhs.Offset);`
<pixelherodev>
The type is private, but @typeInfo gives fields, and there's a field of the private type... which is now public.
<pixelherodev>
:P
<pixelherodev>
ohhhhhh crap this won't work
<pixelherodev>
Blocks are being stored by *pointers* into the arraylist; after translation, the array list has `items.len = 0`
<pixelherodev>
so pointers are *reused*
<pixelherodev>
hmm, labels should probably just be removed on usage then? that should fix this...
bjornroberg has quit [Quit: leaving]
<pixelherodev>
Yayyy, thinkg work now!
<pixelherodev>
things*
satchmo has joined #zig
_whitelogger has joined #zig
<squeek502>
andrewrk, any reason not to have a link to the google sheets graphs in the gotta-go-fast readme?
reductum has quit [Ping timeout: 256 seconds]
kristoff_it has quit [Ping timeout: 256 seconds]
xackus has joined #zig
xackus_ has quit [Ping timeout: 272 seconds]
xackus_ has joined #zig
xackus has quit [Ping timeout: 246 seconds]
<andrewrk>
squeek502, nope! good point
aerona has joined #zig
reductum has joined #zig
klltkr has quit [Remote host closed the connection]
klltkr has joined #zig
SimonNa has quit [Ping timeout: 260 seconds]
lanodan has quit [Ping timeout: 260 seconds]
SimonNa has joined #zig
lanodan has joined #zig
<pixelherodev>
andrewrk: did you rewrite my graph generator in Zig yet? If not, want me to do it/
<pixelherodev>
?
reductum has quit [Quit: WeeChat 2.8]
kevsmith has joined #zig
stripedpajamas has joined #zig
stripedpajamas has quit [Client Quit]
_whitelogger has joined #zig
dddddd has quit [Ping timeout: 256 seconds]
<daurnimator>
Hey I'm thinking of looking at an allocator again today
<daurnimator>
Maybe stream it...
waleee-cl has quit [Quit: Connection closed for inactivity]
<pixelherodev>
Anyone interested in a stream on stage2 work from someone who has... noticably less experience with it than Andrew does? :P
<pixelherodev>
I'm thinking I might do that at some point tomorrow if anyone's interested
<pixelherodev>
...today.
<pixelherodev>
It's midnight.
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
leeward has quit [Remote host closed the connection]
stripedpajamas has joined #zig
satchmo has quit [Ping timeout: 272 seconds]
aerona has quit [Remote host closed the connection]
aerona has joined #zig
slowtyper has joined #zig
aerona has quit [Quit: Leaving]
Invader__Bork has joined #zig
greenfork has joined #zig
leeward has joined #zig
_whitelogger has joined #zig
kradnoel has joined #zig
stripedpajamas has quit [Quit: sleeping...]
kradnoel has quit [Remote host closed the connection]
kradnoel has joined #zig
kradnoel_ has joined #zig
kradnoel has quit [Ping timeout: 256 seconds]
kradnoel_ has quit [Remote host closed the connection]
<scientes>
how do i generate a ZigValue for a 0 sentinel?
<scientes>
I just want to generate "[:0]const u8"
tdc has joined #zig
<pixelherodev>
Generate?
<scientes>
in stage1
<scientes>
ahh there is a special
<scientes>
for_zero_byte()
<pixelherodev>
Ohh
<pixelherodev>
you meant within the compiler :)
<pixelherodev>
ZigValue should've tipped me off :P
eleanor-nb has joined #zig
_Vi has joined #zig
<eleanor-nb>
Heyo. CMake is struggling to build master. It displays the following errors:
<eleanor-nb>
CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.CMake Error: CMAKE_C_COMPILER not set, after EnableLanguageCMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
<pixelherodev>
What system are you on?
<scientes>
eleanor-nb, you don't have make installed
<scientes>
that is what that is saying
<pixelherodev>
scientes: yes, but that might not be the underlying issue :)
<pixelherodev>
eleanor-nb: are you on Linux? Windows? Mac?
<eleanor-nb>
Huh. So I don't. Weird.
<pixelherodev>
You can also use Ninja, that's what I do :)
<eleanor-nb>
pixelherodev: linux-aarch64. Specifically, Manjaro ARM on Pinebook Pro. It came with clang and LLVM libs, so I assumed it had make as well.
<pixelherodev>
Ahh, neat
<pixelherodev>
Yeah, that's odd
<pixelherodev>
Can't wait until they're back in stock...
<eleanor-nb>
Have they run out already? :')
<pixelherodev>
Yeah :(
<pixelherodev>
I would have placed the order
<pixelherodev>
but my bank said "Uh"
<pixelherodev>
"You never spend money"
<pixelherodev>
"Are you okay?"
<pixelherodev>
And I was all like
<pixelherodev>
"Sheesh I'm fine" and Pine was like, "uh... yeah they're gone now," and I pulled an Anakin
<pixelherodev>
The shouting NOOOO thing
<pixelherodev>
Not the child murdering
<pixelherodev>
... wait whoops this isn't the Discord. ... yeahhhhhh
<eleanor-nb>
Honestly, you're not missing all that much. It's...fine, I guess, but it's not really fundamentally different from the experience on any other laptop. Except it's weak. Very weak.
<pixelherodev>
Except it's metallic instead of this cheap plastic, so it's more durable; it's easier to hack, as the project is much more open; the performance won't be noticably different to me, as anything important I do over SSH;...
<eleanor-nb>
Oh yeah, you have that compile farm, don't you? Then yes, it fits your use case perfectly '=(
<pixelherodev>
Not really a compile farm
<pixelherodev>
It's an old PC :P
<eleanor-nb>
Language is use ;)
<pixelherodev>
`ssh pixelpc grep name /proc/cpuinfo|head -n1` -> `model name : Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz`
<pixelherodev>
True
<pixelherodev>
I might offer to open it up for compilation (for Zig only) for anyone else who needs it on a first-come basis if I can make sure I know what I'm doing enough that security isn't an issue
<pixelherodev>
It's really nothing special, but if it's helpful for people with even older hardware, I'd love to be able to make life easier
<pixelherodev>
I know the pain of trying to develop on a Celeron all too well
<pixelherodev>
:(
<eleanor-nb>
Ew.
<pixelherodev>
Yeah.
<scientes>
more like a celery-on
<eleanor-nb>
Celery on, CPU off.
<pixelherodev>
An assembler on my TI calculator would literally have been faster.
<pixelherodev>
Replacing Windows with a tiny distro made life much easier
<pixelherodev>
(no constant swapping! Yay!)
<pixelherodev>
But it's one of many reasons I ended up ditching C++
<pixelherodev>
Compiling C on there was honestly okay
<pixelherodev>
It wasn't *great* by any means
<pixelherodev>
But it wasn't *bad*
<pixelherodev>
C++ was objectively awful, and I don't even want to imagine what Rust would have been
<pixelherodev>
and I'm ethically opposed to the idea of just "tossing more hardware at the issue!!!" Efficiency isn't just a means to an end IMO, it's a goal we should be striving for for its own sake
<pixelherodev>
To be fair, the language itself isn't really at fault
<pixelherodev>
Some C++ packages compile quickly
<pixelherodev>
ditto with Rust
<pixelherodev>
The problem is that the patterns people use often are those that are most difficult for the compiler
<pixelherodev>
Because people just don't consider compile time a priority
<eleanor-nb>
As usual, humans are the worst.
eleanor-nb has quit [Remote host closed the connection]
<scientes>
pixelherodev, you can't just throw more hardware at a O(n^2) algorithm
<scientes>
it doesn't work
<pixelherodev>
Which is why you should use a better algorithm
<pixelherodev>
That's my point
<pixelherodev>
Fix the software instead
<scientes>
uggh, memory allocation in a library is hard
<pixelherodev>
Really?
<pixelherodev>
Why not just take an Allocator
<pixelherodev>
?
<pixelherodev>
Guessing there's more to it than that?
<scientes>
i need this to be callable from C
<scientes>
from stage1
<scientes>
I am already using two allocators too
<scientes>
a FixedBufAllocator (linear array), and a scratch memory allocator
<pixelherodev>
Hmm
<scientes>
I guess I could just pass in a pointer to realloc C function
_whitelogger has joined #zig
stripedpajamas has joined #zig
dddddd has joined #zig
_whitelogger has joined #zig
<afontain_>
`const slice = array[0..array.len]`?
<afontain_>
(you could stop before len if you want)
<scientes>
yeah, but if it isn't const it isn't const
<scientes>
oh nvm
<scientes>
ueaj arr[0..]
<greenfork>
afontain_: tried, still complains that the slice is of []u8 and not []const u8
<afontain_>
it sounds weird
<afontain_>
I thought it was always possible to take something you can modify and decide not to modify it
<scientes>
ahh yes, you need to do var const_request_line_buf = request_line_buf[0..];
<scientes>
uggh
<scientes>
with : []const u8
<scientes>
to tell it that you are assuring it won't change while it is looking at it
<scientes>
nah
<scientes>
you didn't do [0..]
<scientes>
you did & instead
<scientes>
it should be complaining that it is *[8000]u8 however
<scientes>
that error doesn't seem right
<greenfork>
scientes: thank you so much, `var const_request_line_buf = request_line_buf[0..];` this works
<scientes>
well, request_line_buf[0..] would work too
<greenfork>
with [0..] instead of & the error is still the same
<scientes>
you can't just make a pointer to it
<scientes>
this isn't C
<scientes>
it is type checked
<scientes>
oh hmm interesting
<ifreund[m]>
isn’t the error coming from the parseRequestLine call?
<greenfork>
yes it does
<ifreund[m]>
alright let me get out of bed and pull up this code
<ifreund>
greenfork: so fixedBufferStream expects a type but you're passing it a slice
<greenfork>
ifreund: it's a function, letter "f" is small
<ifreund>
oh no, this is right, i missed the capitalization
<ifreund>
yeah
<ifreund>
greenfork: @as works var request_line_fbs = std.io.fixedBufferStream(@as([]const u8, &request_line_buf));
<greenfork>
oh right. I must have changed so many things, I thought I tried it, this really does work
<greenfork>
thanks!
<ifreund>
this also works for me: const buf: []const u8 = &request_line_buf;
<ifreund>
no problem!
<ifreund>
(this is doing an implicit @as() so it makes sense that it would work)
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
<scientes>
ifreund, a function call should also do a @as however
<scientes>
anyways
<ifreund>
scientes: this function takes var
<ifreund>
the error occurs when the next function takes std.io.FixedBufferStream([]const u8) but a std.io.FixedBufferStream([]u8) which you can't convert with @as()
<ifreund>
*but the []u8 version is passed
wootehfoot has quit [Ping timeout: 246 seconds]
* ikskuh
just killed cImport
<ikskuh>
seems like stuff is broken in translate-c
<ikskuh>
yep
<ikskuh>
including SDL.h breaks zig build atm
tdc has quit [Ping timeout: 264 seconds]
dermetfan has joined #zig
dermetfan has quit [Client Quit]
<scientes>
Semantic Analysis [982/1288] ./bisect.zig:285:42: error: expected type '[*:0]const u8', found '(null)'
<ifreund>
pub fn main() !void {} is what i usually do as it's the simplest
<ifreund>
then you can get the args with `std.process.args`
<ifreund>
or std.os.argv
Michcioperz has left #zig [#zig]
<phdye>
hmm, not an option when must receive it as an argument. In this case, the docopt() will be passed it. And for testing, unit testing argument is more flexible than global IMHO.
<pixelherodev>
A small tour of my compiler project as it stands today :)
<ifreund>
2 hours, nice
<pixelherodev>
Well, I basically covered all the active components
<pixelherodev>
s/active/in active development
<pixelherodev>
ZiggIRat (LLVM IR parser) is basically done, I just need to finish up lightzing so I can hook them up
<pixelherodev>
Heck, I think I might mark ZiggIRat as 0.1 today
<ifreund>
cool stuff
<pixelherodev>
There's ~10 thgings it can't parse currently
<pixelherodev>
but none of them matter for e.g. Zig output
<pixelherodev>
It's fully possible to use it to write a Zig compiler (instead of ZIR) (but please don't)
<ifreund>
you should sign up for one of kristoff_it's events to give a talk if you haven't already :D
<pixelherodev>
I'm going to
<pixelherodev>
The only reason I didn't was I needed some more time
<pixelherodev>
Thor is basically ready to show his muscles now though ;)
aerona has joined #zig
<marler8997>
daurnimator: you here?
<daurnimator>
marler8997: ya
<marler8997>
looks like windows doesn't have a way to make a socket non-blocking in WSASocketW...so should we still handle that flag in os.zig by a subsequent call to setsockopt? So it's the same interface for posix/windows?
<marler8997>
and the socket_type on windows is an enum rather than a set of flags, but I'm guessing we want it to treat it as a flag set in os.zig
<alexnask>
You can make the socket non blocking with ioctlsocket
<marler8997>
oh right, ioctlsocket instead of setsockopt
<alexnask>
However you then have to use select() or WSASelect to poll if its writable to wait for connect() to finish (not sure about other calls like accept bind etc)
<alexnask>
Which doesnt really integrate with the event loop
<marler8997>
but what I'm asking is, should we support the SOCK_NONBLOCK/SOCK_CLOEXEC socket type flags for windows in os.zig
<marler8997>
even though those flags aren't supported on the socket type when you call WSASocket or windows' socket function directly
<alexnask>
I dont think those are even defined in winsock (could be wrong), they def have no effect though
<marler8997>
they aren't
<marler8997>
that's why I'm asking
<marler8997>
but we could take those flags in os.zig, and translate them to the analagous flags for windows
<alexnask>
I dont think that would be the way to proceed personally, the interfaces are just different enough that we shouldnt even offer the windows versions in os.zig imo
<alexnask>
But rather call into os or the windows stuff directly from net.zig
<marler8997>
so if we didn't support windows in os.zig (i.e. posix.zig), would you think we'd create a common networking api that works for both posix and windows?
<marler8997>
oh, net.zig would be the common networking api
<alexnask>
^
<marler8997>
daurnimator: what do you think?
<marler8997>
abandon my change to add windows support in os.zig and start implementing the network api in net.zig?
<alexnask>
This is what we do in zig-network. A lot of the calls are interchangeable but not everything so I think its cleaner this way
<marler8997>
I think you can do it either way, or both if you want to
<marler8997>
I don't care much, I just want something that works
<daurnimator>
marler8997: I think we should end up with implementations in std/net.zig
<marler8997>
so please just tell me when you want
<daurnimator>
and they can be much higher level
<marler8997>
and the other questions I asked?
<ifreund>
I think keeping windows stuff out of os/posix.zig makes sense
<daurnimator>
> socket_type on windows is an enum rather than a set of flags,
<daurnimator>
I don't know what you mean by that one
<alexnask>
(I have a PR for async windows recv and send in zig-network btw havent figured out how to integrate the rest of the non blocking calls with the event loop though)
<marler8997>
on posix, you can specify SOCK_CLOEXEC and SOCK_NONBLOCK along with the socket type (i.e. SOCK_STREAM and SOCK_DGRAM)
<marler8997>
on windows, WSASocketW doesn't recognize the socket type as a set of flags, but an enum of individual values
<marler8997>
you pass the flags in another argument
<daurnimator>
marler8997: ah right. on other OSes AF_ should be an enum too; and then we would @enumToInt and bitwise OR it
<marler8997>
but the question was
<marler8997>
if we support windows in os.zig
<marler8997>
the socket function only has the 3 parameters, and clients can pass SOCK_NOEXEC and SOCK_NONBLOCK to the socket type
<marler8997>
should we support that for windows as well?
<daurnimator>
no.. I said exactly the opposite >.<
<daurnimator>
==> most of os.zig is eventually moving to posix.zig, and it shouldn't make up things for windows that aren't like-for-like.
<marler8997>
what? when did you say that?
<marler8997>
goodness
<daurnimator>
instead there should be something like: `std.net.socket(.INET, .STREAM, 0, .{ non_blocking = true })`
<marler8997>
yes I agree
<daurnimator>
marler8997: that's what the issue 5019 that I linked says
<marler8997>
but that's not what I'm asking about
<marler8997>
You can support windows in both std.net, and you could also support it in std.posix
<marler8997>
that issue never says we shouldn't support windows in std.posix when it can be supported
<marler8997>
that's what I was asking you
<marler8997>
so to be clear, I should remove the dummy flags I just added
<marler8997>
should I also just remove windows support in std.os (aka std.posix) altogether and just get started on std.net?
<marler8997>
again, I don't care, I just want it to work and I'm willing to do it, please just tell me what you want
<marler8997>
hello?
alexnask has quit [Quit: Leaving]
satchmo has quit [Ping timeout: 246 seconds]
<pixelherodev>
daurnimator: you are my favorite person. On Earth.
<pixelherodev>
f5167f7
<daurnimator>
marler8997: I'm leaning towards yes; but that's not my decision to make.... I think you might need to wait for andrew?
<xackus_>
are you supposed to be able to create a union tagged with a non-exhaustive enum? that doesn't make a ton of sense
phdye has quit [Ping timeout: 245 seconds]
<marler8997>
daurnimator: ok
<marler8997>
I'm not sure whether or not we should support Windows via the posix interface when it doesn't conform completely to it
<marler8997>
I think you could go either way
<marler8997>
if we have a platform-independent api on top of it, then there's less reason to support it
<marler8997>
in any case, we could integrate this now and remove it later once we get that API
<marler8997>
this change allows name lookups to work on windows now. Now my ziget tool works on windows
<watzon>
Zig doesn't allow importing C++ code the same way you can import C code, does it?
<watzon>
I'd assume that any C++ would have to be wrapped
<pixelherodev>
Nope
<pixelherodev>
No C++ importing
<pixelherodev>
You can build it though
<watzon>
That's true I guess haha
frmdstryr has joined #zig
riba has quit [Ping timeout: 272 seconds]
_Vi has quit [Ping timeout: 246 seconds]
erai has joined #zig
satchmo has joined #zig
wootehfoot has joined #zig
FireFox317 has joined #zig
wootehfoot has quit [Client Quit]
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
wootehfoot has joined #zig
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
_Vi has joined #zig
doublex_ has joined #zig
doublex has quit [Ping timeout: 260 seconds]
Invader_Bork has joined #zig
doublex_ has quit [Ping timeout: 264 seconds]
tines9 has quit [Ping timeout: 246 seconds]
greenfork has quit [Quit: WeeChat 2.8]
<gpanders>
Hi all. The test in the following paste fails: https://paste.sr.ht/%7Egpanders/622949b3e497fafc0c2f0b7c475fcf7aecc48acb. To explain what's going on, I am creating an ArrayList of const pointers to structs from an existing slice. However, the ArrayList ends up with only pointers to one item in the slice (in this case, the last item), so the test fails. This is a contrived test case, but I'm seeing the
<gpanders>
same thing in a real application as well. Is this a bug, or am I just missing something about the way Zig works?
<gpanders>
it is unique to using an ArrayList of pointers. If I create an ArrayList of the structs (e.g. `Foo`) it works as expected, but I am trying to avoid copying those structs unnecessarily
tines9 has joined #zig
<afontain_>
oh, that one is subtle
<FireFox317>
gpanders, the problem is that when using a for loop, it is actually copying the values. So in your case `for (somefoos) |foo|` foo is a copy, you should use `for (somefoos) |*foo|`
<afontain_>
`for (xs) |x| {}` will create a new variable, x, copied from xs[i]. It it (I think) equivalent to `const x = xs[i]`
<afontain_>
so the pointer won't point to the right address
<gpanders>
ahhhh
<afontain_>
ah, his explaination is probably better
<gpanders>
yep, that was it
<gpanders>
duh
<gpanders>
seems obvious in hindsight
<FireFox317>
afontain_, basically the same explanation :D
<gpanders>
Thanks FireFox317 and afontain_
<afontain_>
hey, it's not because we explain the same thing, that there isn't a better explaination :P
hermier has quit [Remote host closed the connection]
doublex has joined #zig
<ikskuh>
in this case probably yes?
<ikskuh>
there may be valid reasons for using a pointer though
<afontain_>
is there a rule of thumb for when you should use a pointer?
<ikskuh>
hm
<ikskuh>
not sure, actually, we have no spec :D
<afontain_>
is it only if it is a big object?
<ikskuh>
but atm zig keeps the freedom to pass all arguments by-ref
<ikskuh>
and i think the current implementation does so
<afontain_>
like `matrix: [100][100]f32`?
<ikskuh>
but if you want the guarantee for a pass-by-ref, you should use a pointer
<ifreund>
as i understand it you should only pass by *const if you need to use the fact that it's a pointer and compare by pointer or something
<ikskuh>
yeah
<ikskuh>
and if you return pointer to internal objects
<ifreund>
yeah
<ifreund>
oh, that's what's happening here
<ifreund>
i think
<ikskuh>
nah, there's getInternal which does just use a normal arg
<ifreund>
but no, internalGet is pass by value
<ifreund>
though it is returning a pointer to internal objects
<ikskuh>
well
<ifreund>
these objects are on the heap though
<ikskuh>
yeah
<ikskuh>
wanted to say
<ifreund>
hmm, i'd be really nice if this had a getByHash function
<ifreund>
I'm working with a StringHashMap, and would like to store a reference to a value. You can't do that though since modifying the HashMap would invalidate the pointer
<ifreund>
so next best is storing the key
<ifreund>
but with strings as the key, it would require dealing with another allocation
<ikskuh>
only storing the hash may not be enough though
bjornroberg has quit [Quit: leaving]
<ifreund>
yeah i was worried i was missing something about how this actually works :D
<ikskuh>
well, the hash may be not unique
<ifreund>
i think i'll go with the workround of StringHashMap(usize) + ArrayList(MyThing)
<ifreund>
then i can store the usize
<ikskuh>
and if that is the case, you need a full-value compare when querying the keys
<ifreund>
ah, yeah that does make sense
Invader_Bork has quit [Ping timeout: 264 seconds]
FireFox317 has quit [Ping timeout: 260 seconds]
tdc has quit [Ping timeout: 246 seconds]
Akuli has quit [Quit: Leaving]
klltkr has quit [Read error: Connection reset by peer]
ur5us has joined #zig
reductum has joined #zig
layneson has quit [Ping timeout: 272 seconds]
wootehfoot has quit [Ping timeout: 246 seconds]
dimenus has joined #zig
frmdstryr has quit [Ping timeout: 265 seconds]
xackus_ has quit [Ping timeout: 246 seconds]
_Vi has quit [Ping timeout: 246 seconds]
<leeward>
Is there a good way to link to a library I wrote in Zig, or do I have to wait until the package system exists?
<ifreund>
leeward: the standard way is to include it in your repo as a submodule and use addPackage() in your build.zig
<ifreund>
the concept of packages already exists, but there is not yet a real package manager
<leeward>
Ooh, cool
satchmo has joined #zig
<leeward>
ifreund: Do you know of a simple example that does that? There's a lot of missing documantation here, and I really don't want to read all the code in build.zig.
ifreund has quit [Ping timeout: 256 seconds]
<leeward>
I guess not.
dermetfan has quit [Ping timeout: 265 seconds]
<ifreund[m]>
leeward: you can check out the build.zig for zls