<pltrz>
never thought to translate simple programs to practice :)
adamkowalski has joined #zig
<adamkowalski>
andrewrk: would it be possible to have "lazy" keyword in zig? That way you could implement "if" in userland by having a function which takes a condition and two lazy parameters, and then you evaluate the parameter depending on the value of the conditional
return0e_ has joined #zig
return0e has quit [Ping timeout: 250 seconds]
marijnfs_ has quit [Quit: Lost terminal]
r4pr0n has quit [Quit: r4pr0n]
redj has quit [Read error: Connection reset by peer]
redj has joined #zig
pixelherodev has quit [Quit: ZNC 1.6.2 - http://znc.in]
<mikdusan>
ugh I can't remember, was `zig0 test -mcpu=baseline --dynamic-linker myfoo.zig` supposed to let zig0 run a test? I get: "Unable to get native target: unrecognized architecture"
adamkowalski has quit [Quit: Lost terminal]
ifreund has quit [Ping timeout: 240 seconds]
gpanders has quit [Ping timeout: 265 seconds]
gpanders has joined #zig
junon has quit [Ping timeout: 264 seconds]
marijnfs_ has joined #zig
return0e_ has quit [Read error: Connection reset by peer]
return0e has joined #zig
marijnfs has quit [Ping timeout: 240 seconds]
sorenbug has joined #zig
<sorenbug>
Shoutouts to me `/join`ing `zig` and not `#zig`
<mikdusan>
watzon: can you paste the result of `zig targets` somewhere? also confirm `zig cc` and executing on same host?
wootehfoot has quit [Ping timeout: 250 seconds]
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
frmdstryr has quit [Ping timeout: 240 seconds]
<pixelherodev>
CMake isn't finding the Clang libraries on my new Gentoo build :(
<pixelherodev>
Is Clang supposed to be version 9 or 10?
<pixelherodev>
LLVM 10 is detected, so I built Clang 10 too...
suppi has joined #zig
dingenskirchen has quit [Read error: Connection reset by peer]
dingenskirchen1 has joined #zig
<pixelherodev>
Guess I'll have it build Clang 9 overnight and try that in the morning
<pixelherodev>
Well
<pixelherodev>
Later in the morning
<pixelherodev>
It's already three :(
dingenskirchen1 is now known as dingenskirchen
dddddd has quit [Ping timeout: 250 seconds]
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
_Vi has quit [Ping timeout: 260 seconds]
ur5us has joined #zig
<wilsonk>
pixelherodev: are you trying to build zig master as of today? You need llvm/clang/lld 10 for that (so not sure why you are trying 9)
<wilsonk>
watzon: did you get any further on that packcc error?
wootehfoot has joined #zig
wootehfoot has quit [Client Quit]
nephele_ is now known as nephele
<wilsonk>
watzon: it appears that zig cc is perhaps defaulting to some stricter casting checks or something. There is a 'ud2' illegal instruction being inserted into the function 'hash_string' in packcc.c when zig cc is run. This illegal instruction has two ops after it that designate the __file__ and __line__ of the issue (I can't seem to see those values in gdb though)...anyways, after hash_string iterates over 5 incoming letters of the string to
<wilsonk>
The fix: change the 'h' variable in hash_string to a long and then cast to an int for the return (ie. int i=0; long h=0; ... return (int)h; ). That should fix things but I am not exactly sure how to fix the overall problem or if andrew would still prefer this stricter check on casting?
return0e_ has joined #zig
<wilsonk>
watzon: then your test grammar should work and the example at the bottom of the packcc documentation also works
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
return0e has quit [Ping timeout: 250 seconds]
dermetfan has joined #zig
gazler has quit [Quit: Leaving]
ur5us has quit [Ping timeout: 256 seconds]
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
marijnfs has joined #zig
marijnfs has quit [Quit: leaving]
marijnfs has joined #zig
marijnfs1 has joined #zig
<mq32>
hey
r4pr0n has joined #zig
slowtyper has quit [Ping timeout: 240 seconds]
ur5us has joined #zig
<wilsonk>
hey mq32
<wilsonk>
a little late, but... :)
ifreund has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
_Vi has joined #zig
lunamn has quit [Quit: Ping timeout (120 seconds)]
lunamn has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
_whitelogger has joined #zig
TheLemonMan has joined #zig
marijnfs2 has joined #zig
marijnfs1 has quit [Ping timeout: 264 seconds]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
dingenskirchen has quit [Ping timeout: 240 seconds]
mahmudov has quit [Ping timeout: 265 seconds]
<pixelherodev>
wilsonk, I was trying nine because CMake failed to find 10 :(
<wilsonk>
pixelherodev: failed to find it in /usr or /usr/local? I always build and install in /usr/local and it seems to work, that is why I mention it...but I assume it is in /usr on Gentoo
<pixelherodev>
Yeah
<pixelherodev>
Works on my laptop, too
<pixelherodev>
But that's using 9 still?
<pixelherodev>
Weird
<wilsonk>
you are on master as of today and it builds with llvm-9?
<wilsonk>
You must have a 10 lying around if that is the case because llvm-10 is required as of 2 days ago
<pixelherodev>
I have 10 installed
<pixelherodev>
*and* 9
<wilsonk>
oh, I see
<pixelherodev>
So my guess is it's still allowing the old paths because the right version is also lying around
<wilsonk>
hmm, can you retarget the output dir of the build to /usr/local easily on Gentoo without having to rebuild the whole llvm suite?
<pixelherodev>
I don't think that's the issue, because I think I found it
<pixelherodev>
Even on my laptop, Clang 10 doesn't have as many libraries showing up locally
<wilsonk>
oh, do you have some dynamic llvm libs and some static?
<pixelherodev>
That's the thing, they're all dynamic
<pixelherodev>
15 files in /usr/lib/llvm/10/lib64; *421* in 9/lib64
<wilsonk>
because on MacOS they dynamic libs for clang and lld were picked up instead of the static ones I had...just mentioning
<wilsonk>
whoa, that seems strange
<pixelherodev>
On a different note, if I wipe the build/ folder I had and set up cmake from scratch, it errors out expecting LLVM 10
<pixelherodev>
Yay?
<wilsonk>
hmm, can you remove llvm-9 (ie. xargs rm < install_manifest.txt)? I assume you still have the build around? Or maybe not
<wilsonk>
I have llvm/clang/lld-8 and 9 and 10 all built on each of my machines and then just overwrite when moving up in versions if there is an error...or remove all and then just install the one version I need to test zig, then install the older versions using my package manager. That way zig always picks up the /usr/local version and any other programs that need 8 or 9 can still pick them up from /usr. This assumes one has enough disk space on
<pixelherodev>
I installed nine after it didn't find ten :(
<wilsonk>
via Gentoo's build system or your own, so you could install to /usr/local (not that it should really make a difference with Gentoo, I suppose...just seems really weird that there are so few libs for 10)
mahmudov has joined #zig
<pixelherodev>
I'm 99% sure that won't do anything
<wilsonk>
ok, I am not a Gentoo guy so I am just taking shots in the dark anyways ;)
rzezeski has quit [Quit: Connection closed for inactivity]
dddddd has joined #zig
mahmudov has quit [Ping timeout: 240 seconds]
mahmudov has joined #zig
<pixelherodev>
I think Clang 10 has BUILD_SHARED_LIBS turned off in Gentoo...
<pixelherodev>
Going to manually tweak that and rebuild :(
<pixelherodev>
After much tweaking and annoyedly updating the hash, it's building with -BUILD_SHARED_LIBS=on
<pixelherodev>
The problem isn't on Gentoo's end, it's on Zig's AFAICT: the recommended build model by LLVM upstream is to have a single giant library instead of a bunch of small ones, but Zig doesn't know how to link against just -lLLVM
<shakesoda>
would @divTrunc or @divFloor be the correct conversion for integer division in c code
<mq32>
yes
<fengb>
I believe C spec is divFloor
<mq32>
depending on what you want :D
dirkson has joined #zig
<shakesoda>
I'm converting some C code and want to be sure I got it right
<shakesoda>
with what it did to begin with
<fengb>
Oh shoot I’m wrong. It’s truncate towards 0
<shakesoda>
trunc, then?
<ifreund>
trunc is the c spec yes
<dirkson>
Hey all. Do we have any benchmarks for zig as a build system? I've got some vague curiosity.
<shakesoda>
thank you
<mq32>
dirkson: in what terms?
<dirkson>
mq32: Tup, for example, does a lot of database storage and is crazily fast as a result - a rebuild with no changes is basically instant, it handles huge numbers of files with slow linear performance degredation, etc
<mq32>
yeah sounds like zig build :D
tane has joined #zig
<mq32>
note that if you compile a project with libc
<mq32>
zig build compiles the whole libc
<mq32>
(or, rather: zig compiles the whole libc)
<mq32>
and it's done "instantly" when finished with that once
<dirkson>
Does the zig build system have a usable way of pulling in non-zig-build dependencies? I.e. Can I reasonably include a project built with cmake or [insert build system here] as a dependency for my project?
<fengb>
Nothing is promised to be stable until 1.0
<mq32>
real0m54,338s
<mq32>
real0m0,181s (second run)
<r4pr0n>
but can i install them on any distribution? ifreund
<r4pr0n>
i'm not using a debian based system
<mq32>
user time is about 0.07s
Akuli has joined #zig
<fengb>
But other than the new anon function syntax, I don't think there's any other big breaking change that's scheduled
<ifreund>
r4pr0n: you may be able to get binarys from there to work, or just wait for your distro to package llvm 10
<dirkson>
mq32: Yeah, that's how I clean my tup builds. Theoretically I wouldn't ever need to do that if my entire build environment was managed by tup, but it turns out operating systems are a thing and sometimes you really do need to clean
<ifreund>
or compile yourself of course
<r4pr0n>
yeah i'd like to do that, but my cpu isn't powerful enough, it takes very long
<dirkson>
mq32: I'm assuming that horribly slow first build speed is just zig compiling all the 'system' dependencies, like libc?
<mq32>
yep
<mq32>
that first build was "make compiler_rt, musl-libc and my code for aarch64-linux"
<mq32>
second build was "check everything"
<dirkson>
mq32: Mind changing something in main.c and re-timing for me?
<dirkson>
Do we have windows/osx cross compiles for C compiles yet?
<mq32>
real0m0,214s
<mq32>
dirkson: doing a win64 build right now, same program
<dirkson>
200ms seems long for a small change. Although checking, my meson/ninja/script takes 400ms for a similarly small change, and I don't notice that, soooo whatever!
<fengb>
It should be
<mikdusan>
watzon: ok thanks; yup I get illegal instruction on my host too
<mq32>
dirkson: 95% of the time is disk I/O ;)
<mq32>
fengb: don't see a libc for mac though
<watzon>
Interesting case. Probably an easy fix, but I wouldn't know where to start.
<fengb>
Oh yeah, that's not ready yet
<mq32>
cross-compiling zig code to mac works
<dirkson>
I don't think I have a working c-based tup build at the moment. Although an unchanged build for tup is real0m0.004s and a single source file change is 0m0.088s, that's almost certainly just capturing compilation time
<dirkson>
mq32: That's a cool metric. It could still be doing unnecessary IO though
<fengb>
We had some questions about header licensing. I found a dumb header <stdint.h> that was actually private
<mq32>
i don't think so, andrew is pretty proud of his caching system
<mq32>
also: zig checks about 2k files when doing a cross build :D
<dirkson>
Like, a 'correct' build the way zig does it is to check every single built library file every time it builds, but those files are only likely to change when zig is updated.
<mq32>
yeah
<mq32>
but then it also only builds those files that have changed :)
<mq32>
and you are free to mutate your libc in any way you want
<dirkson>
Right, but it might still be hashing them each time
<mq32>
and still get safe and stable builds
<mq32>
nope, i'm sure it does not :D
<dirkson>
I think it's probably More than fast enough for my purposes, based on your tests, so I'm doing more devil's advocate than anything at the moment :)
<mq32>
hrhr :D
<dirkson>
Do you know if I can build without compiler-rt and libunwind, offhand?
<mq32>
i think so
<mq32>
but compiler-rt is required for working builds
<mq32>
but it's not included in static libraries by-default
<mq32>
but for executables and shared objects
<pixelherodev>
Nope, I was right; Zig doesn't know about -lclang-cpp
<pixelherodev>
Building the individual libraries got it detecting Clang
<dirkson>
compiler-rt seems to do a lot of things, most of which aren't needed for many builds - i.e. your release build probably doesn't need profiling and asan hooks most of the time. Does it also do things that are absolutely required?
<TheLemonMan>
yes
<dirkson>
(Also I've got no idea what apple's 'blocks' is, and I distrust it because it says apple and I am some sort of stodgy foss man)
<TheLemonMan>
it contains a lot of builtins that llvm (and also GCC) expects
<TheLemonMan>
eg. some 64bit math ops for some 32bit targets
<mq32>
btw, i random thought i had:
<mq32>
is it sane to allow zig building the whole libc with -flto?
<mq32>
this would allow some crazy cross-file-inlinings
<dirkson>
Yeah, I saw that specific bit, lemon, but figured that not everyone was building for 32 bit targets (I'm usually not)
<andrewrk>
mq32, I don't see any reason that shouldn't work
<mq32>
i can imagine that would speed up the final executable by a lot
<andrewrk>
not sure it would help much though, libc is ABI-bound
<TheLemonMan>
it contains several other builtins that are not related to the target being 32 or 64 bits
<mq32>
if everything is compiled LTO, it could ignore ABI-boundaries
<mikdusan>
when using `zig cc` how do I specify -mcpu=baseline or something to make it just minimal x86_64 ?
<dirkson>
TheLemonMan: Yeah, I was slowly working that you based on your responses :)
<TheLemonMan>
you can get rid of compiler-rt if you manage to avoid referencing any builtin, but that's hard
<dirkson>
Fair
<andrewrk>
mikdusan, need to add -mcpu -march etc support, these flags aren't recognized by zig yet
<andrewrk>
mikdusan, if you pass `-target x86_64-foo-bar` it will be baseline though
<dirkson>
As usual with Zig, I am Fairly Impressed by the build system and C compilation.
<mq32>
the whole project is amazing :)
<mq32>
thumbs up for andrewrk! \o/
<dirkson>
Agreed
rappet has quit [Ping timeout: 246 seconds]
<dirkson>
Do we have any ideas about what priority the package manager project has? I think that's the last major feature I'd really want out of a build system.
<andrewrk>
I think there's a good chance we'll have some kind of working version in the next release cycle
<andrewrk>
be warned I said the same thing when 0.5.0 was released 6 months ago
<dirkson>
(My current solution to this is just a bash script that downloads all the dependencies and sticks them where the build system expects them. This is not exactly portable or elegant or hard to break)
<andrewrk>
I just built llvm with CXX=`zig c++ -target aarch64-linux-musl`
<dirkson>
Well that sounds impressive
<mq32>
this is crazy! :D
<fengb>
So we are self-hosted? 🙃
<pixelherodev>
Not quite
<andrewrk>
not so fast, still have to build clang and lld
<pixelherodev>
It's self-hosted as a C++ environment, not yet as a Zig one
rappet has joined #zig
<mq32>
pixelherodev: still something!
<pixelherodev>
True
<dirkson>
The mere fact that you're within spitting distance of some version of self hosting is impressive in and of itself
<mq32>
this means you can download a precompiled tarball, the sources and start hacking zig
<fengb>
I'm mostly joking :P
<mq32>
no need for complicated cross-envs anymore :)
<pixelherodev>
How long before either upstream Clang or someone else duplicates this work as a standalone C++ compiler?
<fengb>
If they wanted to... they'd just make Clang work
<dirkson>
Thanks for all the help everyone. I'm definitely coming down on the side of trying to switch a project or two to the zig build system.
<mq32>
do it! :)
<mq32>
i did for LoLa and it worked just the same as before
<TheLemonMan>
let's scrap Zig as a programming language, people are so much enthusiast of it as a build system (and C/C++ frontend)
<dirkson>
mq32: ... I may have a use case for LoLa
<mq32>
TheLemonMan: I'm just enthusiast because joining zig code and cpp code will work great soon
<mq32>
and i can port more parts of my code to zig! <
<mq32>
*<3
<mq32>
dirkson: tell me!
<fengb>
We could call it giz
<fengb>
... nevermind
<TheLemonMan>
how do you pronounce that? jizz?
<fengb>
Hard G, duh
<ky0ko>
being able to mix zig and c++ code will make it a fair bit more likely that i could get some folks at work to try zig out ...
<dirkson>
mq32: Well, I'm coding a space game. One of the things I always wanted to provide the users was a scripting language to control the terminals. I considered lua, and also considered just Not Doing It, but this sounds like a neat third option
<ky0ko>
us low-level embedded devs all work on c projects, but the app devs are all c++ fanatics
<fengb>
You don't call it zij
<mq32>
dirkson: that's exactly my use case
<TheLemonMan>
mixing C/Zig was already possible, you only have to link all the objects together
<TheLemonMan>
don't tell me how to pronounce zij >:
<andrewrk>
TheLemonMan, don't worry, this has been the evil plan since the beginning. get c/c++ people hooked on a build system / package manager, and then oh? what's that? you already have the zig language as a dependency? might as well use it!
<dirkson>
mq32: Hey, pm me, won't you?
<fengb>
Embrace, extend, extinguish
<andrewrk>
embrace, extend, extinguish. right out of microsoft's playbook
<ky0ko>
yeah, i know c code was possible - i've been working on porting the quake 2 engine to zig as a sort of POC. but not c++
<dirkson>
andrewrk: I mean, I was already interested to start with. Making the switch process easier is a bonus :)
<fengb>
But this time, for good not evil™. Right??
<andrewrk>
chaotic neutral
<pixelherodev>
best alignment.
<pixelherodev>
All that's needed is to reduce the startup times for `zig build` and I'll use it for C projects :P
<fengb>
I need to fill out 2 squares then put in real pictures
<fengb>
But I also should be doing my day jobs
ifreund has quit [Quit: WeeChat 2.7.1]
<mq32>
Lawful Evil = Ada. true as fuck
<mq32>
Lawful good haskell?
<mq32>
or something like prolog?
<fengb>
Was targeting just low level systems languages
<mq32>
ah
<fengb>
Wanted to keep the domain simple or else it’s too hard to choose
* shakesoda
added tinyfx to zig community projects now that it's got a wrapper in the repo
<mq32>
neat!
<mq32>
have to test it one day :)
<shakesoda>
I think it's pretty nice, but I need to put more time into explaining how it works + examples
marijnfs1 has joined #zig
<shakesoda>
perhaps some zig examples coming Soon(tm)
<mq32>
yeah examples are always good :)
<shakesoda>
building the zig wrapper has put some API bugs on my radar, too, mostly related to some of the types in the header being sketchy/used in sketchy ways
<shakesoda>
need an allocator api, too!
marijnfs has quit [Ping timeout: 264 seconds]
<watzon>
Thanks mikdusan
<watzon>
I was gonna do that when I got the chance
<mikdusan>
oh another question, which OS are you on?
_Vi has quit [Ping timeout: 260 seconds]
<watzon>
Fedora
<watzon>
Though I have debian and arch boxes as well
<Kingsquee>
snarky compile error messages are an underrated life experience
<mikdusan>
TheLemonMan: do you think we're running into an issue here with different aarch64 cpu features?
dermetfan has quit [Quit: WeeChat 2.7.1]
<Kingsquee>
so in rust I use a macro to define struct-of-arrays, is there a way to do the same thing in zig using comptime?
ifreund has joined #zig
<TheLemonMan>
mikdusan, no, I'm pretty sure it's a problem with the LLVM optimizer
<mikdusan>
maybe relevent: "std::bad_alloc" presents for me when doing Debug build too
<TheLemonMan>
that's expected, we compile compiler_rt in release mode even for debug build
<TheLemonMan>
(s)
Barabas has joined #zig
<Barabas>
Hello
<Barabas>
I have an issue with `@cImport(@cInclude("Folder/my_file.c"))`. It says it can't find the file, but if I do `@import("Folder/my_file.c")` it can find it (it just complains that it has tabs :P)
<jaredmm>
Barabas: difference between includeDir and mainPkgPath?
<Barabas>
Hmm... maybe... I didn't set any includeDir or mainPkgPath and the zig file from which I'm trying to import is in my top level folder next to my build.zig
<shakesoda>
i wish when i got errors like "index out of bounds" it'd tell me what the index and bounds were
<shakesoda>
it... clearly knows
<TheLemonMan>
yeah but formatting the error message is hard
<Barabas>
Oh I had fun today, it was complaining about return types. It took me a while to figure out I was doing `try` in a function which didn't allow returning errors.
<jaredmm>
Barabas: I'm assuming that @import will go based on the default root path and that @cImport doesn't do that. I've not looked into it, though.
<mikdusan>
TheLemonMan: cool, I just hacked stage1 to not force release-mode on compiler_rt and the "std::bad_alloc" vanished
<shakesoda>
TheLemonMan: it would just make my life a lot easier :(
<fengb>
Barabas: yeah I’ve spent an hour staring at the try return mismatch before
<Barabas>
I added `.addIncludeDir(".");` to my build and now it works. :)
<Barabas>
Thanks guys.
<TheLemonMan>
shakesoda, open a ticket (if there isn't already one), I have a feeling it may not be that hard to implement
<Barabas>
fengb yeah it'd be so much better if it just said: "Can't use try in this function." or something.
<andrewrk>
Sahnvour, "@zigcpp@exe/zigcpp.cpp.obj.rsp" what is this argument? I don't know what that is supposed to do
<Snektron>
I think meson passes quotes around arguments occasionally
<Sahnvour>
andrewrk: ah, that's a windowsism I guess to workaround enormous command lines, to put arguments in a file
<andrewrk>
I think it's not showing the full command line that zig sees
<andrewrk>
need more info to look into this
<Sahnvour>
yes, gist updated
<andrewrk>
ok I know what's happening
<andrewrk>
zig needs to gain understanding of this @ syntax to look at command lines. because it doesn't understand it, and it's a positional argument, so it thinks its a linker object
<andrewrk>
so it sends @zigcpp@exe/zigcpp.cpp.obj.rsp to the linker, but those args are for the compiler
<Sahnvour>
aha
<andrewrk>
mind filing an issue?
<Sahnvour>
not at all
<andrewrk>
the good news is I believe this can be solved entirely in the self-hosted side of things
<Sahnvour>
I think it just needs to detect arguments beginning with an @ and forward them to clang, correct ? supposedly it already knows how to deal with them to get its full command line
<Sahnvour>
ah but maybe zig wants to act on some of those arguments
<andrewrk>
since we have to act on positional arguments, we have to know about all special positional arguments
<andrewrk>
unknown stuff is already forwarded
<Sahnvour>
okay
kenaryn has joined #zig
<kenaryn>
fengb: Lawfull good: Erlang? Chaotic good: D ? (lot of asymmetries and frictions to make the job at all costs).
ur5us has joined #zig
<Sahnvour>
also zig targets looks broken on my windows box, anyone else can try on theirs ?
<pixelherodev>
Found the problem
<pixelherodev>
`on my windows box` <-
<pixelherodev>
/s
<BaroqueLarouche>
Sahnvour: same issue on my side
r4pr0n has quit [Ping timeout: 240 seconds]
<BaroqueLarouche>
❯ zig targets
<BaroqueLarouche>
unable to list targets: BadPathName
<andrewrk>
hmmmm
<Sahnvour>
yup
jjido_ has joined #zig
jjido_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jjido has joined #zig
<fengb>
kenaryn: developed at Bell Labs so not good. Dynamic type so not lawful :P
<squeek502>
andrewrk, for the zig cc 'passing args to the linker' flags, do you want to pass them indiscriminately or were you thinking of parsing lld's options.td like clangs and validating the passed args?
<waleee-cl>
fengb: erlang? Joe Armstrong worked at Ericsson when developing it
<fengb>
Err... why did I think Bell Labs. Still... a corporate sellout 🙃
<andrewrk>
squeek502, I'm thinking about handling all these manually, because I'm pretty serious about implementing an incremental linker, for compilation speed purposes
<squeek502>
ah ok
<andrewrk>
however for now, it's ok to handle them pretty simply, if a bit boilerplate-y. * detection in main.cpp * add field to CodeGen * add to cache hash * add to each of the 3 linker command lines in link.cpp
<andrewrk>
it's a bit of boilerplate but it makes it easy to swap that component out later
<andrewrk>
Sahnvour, I'm confused about the double @ in your rsp example. I actually ran into the same issue when messing with something else, but there's only 1 `@`
<Sahnvour>
andrewrk: the second @ is contained in a directory name, sorry I meant to clarify this but forgot to
kenaryn has left #zig ["WeeChat 2.3"]
<andrewrk>
ok thanks that clears it up
<andrewrk>
I'm going to try to solve this right now because it's required for another task I'm experimenting with
<Sahnvour>
great!
r4pr0n has joined #zig
Akuli has quit [Quit: Leaving]
drvirgilio has joined #zig
ur5us has quit [Ping timeout: 256 seconds]
<mikdusan>
when using std api like `std.fs.cwd().readFileAlloc(...)` must the path match platform? ie. on windows backslashes?
<andrewrk>
the answer to that question is not stable yet. currently I believe you'll get an error for using forward slashes
<mikdusan>
on windows `zig targets` --> unable to list targets: BadPathName
<andrewrk>
there are a few things that need to be improved for windows path handling. another one is allowing invalid unicode
<watzon>
Thinking about doing a stream today or this weekend @and
<watzon>
* Thinking about doing a stream today or this weekend