<andrewrk>
Cadey, what architecture does TempleOS run on? i386?
<andrewrk>
or rather what architecture would you like to target
<daurnimator>
actually I should create an issue for CFI
<andrewrk>
Cadey, mq32 is correct about ELF files, although I would not be surprised if TempleOS used ELF format. and finally you might be able to utilise the "bring-your-own-OS-layer" feature of the zig std lib, with the caveat that you might have to land a couple patches to expand the features
<andrewrk>
I really think that it would not be quite so insane as you would imagine with zig to emit TempleOS binaries!
<shakesoda>
i am so relieved that debug breaks and stepping work with no extra nonsense needed at all in vscode on windows
<shakesoda>
figured something would try to hurt me for attempting it
<daurnimator>
wooo, happy to see the autojson PR merged :)
<daurnimator>
If I get time tonight I'll start building out a few of the TODOs
<daurnimator>
Should be able to rip out a heap of code from the old json_writer module too
<daurnimator>
(e.g. that module has a 2nd, less correct, routine for json-escaping strings)
<Cadey>
andrewrk: TempleOS doesn't actually use ELF, it doesn't use any binary format
<Cadey>
it just yeets the amd64 bytes into ram
<andrewrk>
Cadey, zig has a new option for that, thanks to BaroqueLarouche
<andrewrk>
Cadey, it's implemented in the build system only. but you can use foo.installRaw() rather than foo.install() and you'll get the yeeted machine code instead of ELF
<Cadey>
this should be interesting
<andrewrk>
Cadey, so that's basically it. you don't even have to use the "bring-your-own-OS-layer" if you don't want to, that's just if you want zig's cross platform abstractions to also work for TempleOS :D
<andrewrk>
if you don't care about that, write some inline assembly for syscalls, and you're off to the races
<andrewrk>
you can look at the inline assembly for the various linux architectures for inspiration: lib/std/os/linux/$arch.zig
<Cadey>
lol
<Cadey>
syscalls
<Cadey>
that's rich
<Cadey>
(TempleOS doesn't have syscalls, technically)
<andrewrk>
what does it look like to interact with the OS?
<Cadey>
you directly call functions in the kernel
<andrewrk>
so they're mapped to hard coded virtual memory addresses?
<andrewrk>
that's even easier. is it the c calling convention?
<Cadey>
no, i think the JIT figures out the addresses at runtime
<Cadey>
lol
<Cadey>
no
<Cadey>
it's a unique/bizarre calling convention
<andrewrk>
ok well you might need some inline asm for that then
<Cadey>
it's a side effect of everything running in ring 0
<andrewrk>
that's basically equivalent to the linux syscall code
<andrewrk>
anyway zig is fully capable of doing this project and is probably one of the best languages to do it in. it's just a matter of the glue code
<daurnimator>
I passed --bundle-compiler-rt, yet I'm not seeing it in the output
adamkowalski has joined #zig
<adamkowalski>
How do I index a anonymous list ie .{ 1, 2, 3} with a runtime value? It seems like you need to use the @"0" syntax
<adamkowalski>
or can I iterate over the values?
<adamkowalski>
nevermind, inline for is magic
<andrewrk>
daurnimator, sounds like a question for godbolt. works for me: https://clbin.com/5HeYg
<andrewrk>
adamkowalski, you can't index it with a runtime value
<andrewrk>
just like you can't access a struct using a runtime field name
nepugia has quit [Ping timeout: 240 seconds]
<adamkowalski>
andrewrk: I ended up using an inline while loop to iterate over the fields in the struct, got each of their names and then used @fields(literal, name) to get the value
<adamkowalski>
would you say thats idiomatic?
waleee-cl has quit [Quit: Connection closed for inactivity]
<adamkowalski>
andrewrk: it's for my machine learning library. It's come along ways in the past few months. However, the syntax for building out nd arrays is quite verbose so I'm trying to support anonymous structs
<andrewrk>
daurnimator, you can think of -femit-asm as defined to mean, "emit the root zig source file as assembly"
nepugia has joined #zig
<daurnimator>
andrewrk: that's sort of odd to me.... it doesn't seem coherent to have "what is emitted" depend on "what is the format to emit in"
<andrewrk>
there is no "the format to emit in" and --emit is deprecated
<andrewrk>
it's only not deleted for godbolt's sake
<andrewrk>
instead we have switches to enable/disable emitting different things
<andrewrk>
the deprecated `--emit asm` parameter means `-fno-emit-bin -femit-asm`
<andrewrk>
-femit-asm means emit the root zig source file as assembly
adamkowalski has quit [Quit: Lost terminal]
<daurnimator>
andrewrk: re: it seems weird that `--emit-asm` would have a different result (apart from comments+order) than building the object and then disassembling it
<andrewrk>
that would be one way to do it, although it might interfere with trying to annotate the assembly with source information. this is starting to get into the territory where LLVM's API dictates how certain kinds of features work
<daurnimator>
I essentially use `-femit-asm` as a shortcut to building the object and disassembling it: what are the alternative use cases?
<andrewrk>
check some of clang's options for emitting assembly
<daurnimator>
heh..... that's what I was doing, and I wanted to see how the affected the implementation of multi3 :P
ur5us has quit [Ping timeout: 240 seconds]
<pixelherodev>
Is there a way to specify "give me the fastest integer with at least N bits?"
<andrewrk>
pixelherodev, just use the integer type that has at least N bits
<pixelherodev>
Sure, but that's functionally identical to just iN
<andrewrk>
uN or iN
<pixelherodev>
Right, but e.g. on x64 64-bit ops are faster than 8-bit, right?
<andrewrk>
zig is allowed to promote 8-bit integers to 64-bit integers to make ops faster
<pixelherodev>
Ah, to put it simply: don't bother, that's the compiler's job
<pixelherodev>
?
<andrewrk>
yeah
<pixelherodev>
Makes sense, thanks
<andrewrk>
I went down this rabbit hole early on in zig's design
<fengb>
Just don’t tie the compiler’s hands with packed bits :P
<pixelherodev>
Nah, it's for a one-off variable used to track what information is still needed for a global definition
dimenus has quit [Remote host closed the connection]
dimenus has joined #zig
dimenus has quit [Ping timeout: 258 seconds]
ur5us has quit [Ping timeout: 240 seconds]
<pixelherodev>
There a way to specify that a tagged union can *never* be a specific type?
<pixelherodev>
`t: unreachable` was the first thing that came to mind, but the compiler rejected that, so I'm guessing there's no real way other than `t: void` and constant `zag.debug.assert(!= .t)`s
<daurnimator>
pixelherodev: use a different tag type :P
<pixelherodev>
Can't :(
dddddd has quit [Ping timeout: 240 seconds]
nepugia has quit [Quit: Leaving]
LER0ever has quit [Remote host closed the connection]
LER0ever has joined #zig
ur5us has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
LER0ever has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
LER0ever has joined #zig
_Vi has quit [Ping timeout: 240 seconds]
metaleap has joined #zig
ur5us has quit [Ping timeout: 240 seconds]
mforney has quit [Excess Flood]
mforney has joined #zig
LER0ever has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lqd has joined #zig
return0e_ has joined #zig
metaleap has quit [Quit: Leaving]
_Vi has joined #zig
Xatenev has joined #zig
<mq32>
<pixelherodev> Right, but e.g. on x64 64-bit ops are faster than 8-bit, right?
<mq32>
x86_64 has dedicated instructions for 8,16,32,64 bit
<mq32>
afaik they are equally fast, but it depends on what you want to achieve
knebulae has quit [Read error: Connection reset by peer]
knebulae has joined #zig
waleee-cl has joined #zig
<Snektron>
Time to break out the intel optimization manuals again
<mq32>
hehe
frett27_ has joined #zig
marmotini_ has joined #zig
decentpenguin has joined #zig
occivink has quit [Quit: WeeChat 2.6]
dddddd has joined #zig
decentpenguin has quit [Quit: decentpenguin]
waleee-cl has quit [Quit: Connection closed for inactivity]
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<fengb>
mq32: I think either math.cast should handle floats, or it should be renamed to math.intCast and we have math.floatCast
<fengb>
Running into the same issue :P
<mq32>
yeah
<mq32>
who should implement it?
<fengb>
Sounds like you're volunteering ;)
<mq32>
damn.
<mq32>
let's just discuss some "features"
<mq32>
int→int is implemented already
<mq32>
float→float would succeed (similar to @floatCast)
<mq32>
int→float will fail when the float cannot represent the integer number
<mq32>
float→int will fail when the float is not an integer or out of range
<fengb>
I think it's easier to just split it into floatCast and intCast
<mq32>
std.math.toFloat() and std.math.toInt() ?
<fengb>
math.floatCast == @floatCast with error return
<daurnimator>
fengb: os.write doesn't use stream.print. it uses string.write
<daurnimator>
uh *stream,
<fengb>
Hmmm
<daurnimator>
and it doesn't even use that either does it?
<daurnimator>
os.write should call the syscall...
<fengb>
I remember something internal uses it heavily
<fengb>
If it's really just debug.warn, then we might be able to invert this and make everything nice
<daurnimator>
yeah.... I made std.json.stringify in std.fmt's image. but now I'm questioning why that exists
<fengb>
I actually started ripping out my generators when I discovered streams can be used as generators
<fengb>
So maybe that's a good solution going forwards
<fengb>
... I swear I encountered some issues. Otherwise this is basically what I did with the generator branch, but more sane and betterer
<companion_cube>
BaroqueLarouche: well I sure hope Zig gets a standard post 1.0
decentpenguin has joined #zig
<fengb>
iirc, a formal written spec on the radar for 1.0
<companion_cube>
I'm really intrigued (and compelled) by the idea of a language having a 1.0 and, basically, no updates afterwards
<companion_cube>
(well there's SML in that style, I imagine(
<companion_cube>
)
<mikdusan>
no joy: `const external_config = @import("config.zig") catch struct {};`
<mikdusan>
(a mechanism to supply empty struct if import is not found)
<Xatenev>
companion_cube, why?
<Xatenev>
companion_cube, you dont like progress?
<companion_cube>
well, if the language is small enough, it could be "done" in some sense
marmotini_ has quit [Remote host closed the connection]
<shakesoda>
is there a reason usingnamespace doesn't work inside of a function
<fengb>
It only works inside of structs/unions/enums
<shakesoda>
i can do @import's inside of them, so i figured i'd also be able to usingnamespace to drop things into that scope
<shakesoda>
fengb: top level, too
<fengb>
Top level is a struct so I'm technically not wrong ;)
<shakesoda>
details!
decentpenguin has quit [Quit: decentpenguin]
<fengb>
I think the technical reason is that usingnamespace clones stuff into the "static" scope. Functions don't have a static scope, unless you create one with `const Foo = struct`
<shakesoda>
I see, it'd be nice to be able to do though :(
<mq32>
just import into "const l = @import(…);"
<shakesoda>
I do plenty of that, I specifically just would like to be able to drop the prefixes from stuff inside of a given function to cut down the noise
<andrewrk>
spec is #75
dingenskirchen has quit [Remote host closed the connection]
dingenskirchen has joined #zig
<mikdusan>
strange. vim has no bundled PEG syntax highlighter
dimenus has joined #zig
<fengb>
Sorting ~170 strings at comptime takes 1s :(
<companion_cube>
quickly, to the comptime JIT!
<andrewrk>
fengb, what sorting algo did you use?
<fengb>
std.sort.sort
<andrewrk>
yeah, it's a bummer, comptime perf is 1-2 orders of magnitude slower than it should be in theory
<fengb>
My silly mem.order hack actually slows down comptime sorting
<andrewrk>
we don't need JIT, we just need a compiler that had a fixed language spec when it was written 😅
<companion_cube>
andrewrk: just wait until people start writing big projects with half the code at comtpime :)
<companion_cube>
but that's why Zig needs several implementations anyway: compete on the compiler, agree on the spec
<fengb>
I had a great hack that squeezed strings into a u128, but then I had strings that were 18 characters long :(
<mikdusan>
try u256
<andrewrk>
fengb, maybe as a workaround the comptime code can produce something you can copy/paste as a sort of manual caching
<fengb>
u256 works. I thought LLVM didn't support it so I didn't try >_>
<mikdusan>
is 18 really your max? u144
<mikdusan>
but more curious, is u256 faster than the 1s sort?
<fengb>
Yeah faster by a lot
<mikdusan>
if you're doing comptime, I _think_ u256 is purely a src/bigint.cpp and llvm is not in the picture
<andrewrk>
the zig language says that even integers larger than u256 are supposed to work. the fact that the llvm-based compiler doesn't is a bug. the issue is https://github.com/ziglang/zig/issues/1485
<andrewrk>
ideally llvm would emit runtime-known integer bit width libcalls for large integers and everything would Just Work
<andrewrk>
this will be easy to solve in a non-llvm backend compiler
<andrewrk>
dimenus, did you have some in-progress self-hosted native glibc version detection code?
<dimenus>
andrewrk: i do, but I likely wouldn't submit a PR until tomorrw. what's up?
<andrewrk>
I'm about to step on your toes
<dimenus>
you're the boss :)
<andrewrk>
would be happy to work based off your diff and give you some credit in the commit msg if you want
<dimenus>
i literally just borrowed the dynamic_library.zig ELF parsing code and then added a bit more to it. I hadn't gotten to merging it with tools/update_glibc.zig yet
<dimenus>
grab PT_DYNAMIC and then look for the DT_NEEDED entry
<dimenus>
for /usr/bin/env, there's only libc
<dimenus>
andrewrk: i'd share it, but it's on my home machine and not pushed
<dimenus>
wouldn't we also want to remove abi verification out of glibc.cpp and into self-hosted as well?
<dimenus>
or i guess not, since the user can choose to skip zig build and execute it via cmd line directly
<andrewrk>
cmd line zig has access to self-hosted code as well
<andrewrk>
e.g. `zig fmt`
<andrewrk>
and `zig translate-c`
<andrewrk>
hmm, you know what else can become self-hosted... main.cpp
<shakesoda>
does zig have some equivalent of c's static in function scope
<andrewrk>
you can make a struct inside a function
<shakesoda>
makes sense
jjido has joined #zig
<betawaffle>
does std.mem.copy work for moving data backwards in a buffer?
<betawaffle>
it doesn't say anything about overlap
<andrewrk>
hmm "dest.ptr must be <= src.ptr" is not correct
<mikdusan>
yeah that's a head scratcher
<betawaffle>
i looked at copyBackwards and it was the opposite of what i expected
<andrewrk>
I think std.mem.copy should have the semantics of memmove, e.g. "the memory areas may overlap; copying takes place as though the bytes in src are first copied into a temporary array that does not overlap src or dest, and the bytes are then copied from the temporary array to dest"
<andrewrk>
actually I don't have enough context loaded into my brain right now, I'm not ready to make decisions about std.mem.copy. there are a few relevant issues open related to this
Barabas has joined #zig
<Barabas>
How do I run the tests for the std?
<Barabas>
oh wait...
<Barabas>
Nope
<mikdusan>
`zig test lib/std/std.zig` or `zig build test-std -Dskip-release -Dskip-non-native`
<companion_cube>
andrewrk: memmove is the right choice, on glibc even mempcy is just an alias to memmove :)
<andrewrk>
orly?
<Barabas>
I think microsoft does the same
Akuli has joined #zig
<Barabas>
If I do this `zig test lib/std/std.zig` I get all kinds of errors (on Windows)
<Barabas>
Oh wait... that's got to do with my setup
jwh has quit [Read error: Connection reset by peer]
jwh has joined #zig
<Barabas>
As I've got the zig std symlinked to C:/User/me/lib/zig/std
<Barabas>
And then it finds everything twice apparently?
<andrewrk>
"finds everything twice" is not a thing
<Barabas>
C:\Users\Me\lib\zig\std\start.zig:25:17: error: exported symbol collision: 'WinMainCRTStartup' @export(WinMainCRTStartup, .{ .name = "WinMainCRTStartup" }); ^.\lib\std\start.zig:25:17: note: other symbol is here @export(WinMainCRTStartup, .{ .name = "WinMainCRTStartup" });
<Barabas>
And when I go to my `C:\User\Me\lib` and run `zig test .\zig\std\std.zig` I get things like these: .\zig\std\os.zig:49:9: error: unable to find 'os/test.zig'
<Barabas>
But the `zig build test-std` works
<mikdusan>
zig does locating relative to zig.exe; so what is zig.exe path?
<Barabas>
C:\User\Me\bin\zig.exe , which is a symlink to E:\Libraries\Zig\build-release\bin\zig.exe
<andrewrk>
oh, the std lib tests require in-source testing
<andrewrk>
I don't think there is a bug here. The supported way to run std lib tests is through zig build
<Barabas>
ok
metaleap has joined #zig
<Barabas>
Everything works fine when I run anything outside std anyway
ur5us has joined #zig
<Barabas>
Hmm... I'm allowed to do something like: `some_function(&@ptrCast(*u32, my_pointer))` and then I get an address to something which is not `my_pointer`.
<fengb>
ptrCast returns a new stack variable
<andrewrk>
rather, the `&` forces into existence a stack variable and takes the address of it
<Barabas>
Does it make sense that this is allowed?
marijnfs has joined #zig
<andrewrk>
there are some compelling reasons to allow taking the address of a temporary
nepugia has joined #zig
<mq32>
andrewrk: do you see a reason to allow that behaviour for mutable references?
frett27_ has quit [Ping timeout: 252 seconds]
nepugia has quit [Ping timeout: 240 seconds]
<dimenus>
andrewrk: i'm curoius about your comment earlier. Are you working on glibc updating directly or is that just affected by other changes?
<andrewrk>
jaredmm, I'll take a look in a few minutes
kristoff_it has joined #zig
frmdstryr has joined #zig
<betawaffle>
should a deinit func mutate the receiver to reflect the de-initialized state? for example, if i have an allocated buffer, and i free it, should i then update invalidate my reference to the old memory?
<betawaffle>
s/update//
<Barabas>
How would you invalidate those?
<betawaffle>
as an example: self.mem = &[_]u8{};
<Barabas>
Up to you I guess, but generally you shouldn't use a struct after a `deinit`, so it doesn't really matter what's in there.
<betawaffle>
ok cool
<fengb>
A semi-common std pattern is `self.* = undefined`
<betawaffle>
but, should my deinit take T or *T?
<betawaffle>
for that, i'd need to take *T
<andrewrk>
mq32 doesn't like self.* = undefined; but I'm pretty sure it's good
<fengb>
You can't reassign any data if it only takes T
<betawaffle>
right, so does that mean every deinit should take a *Self?
<mikdusan>
that's what I do
<andrewrk>
say that you did not have any methods, and it was just a plain old data struct
<fengb>
I think that makes sense in general, *Self implies owned whereas Self would imply value / copy
<andrewrk>
after you freed the relevant things, you could do `x = undefined` which would put it in exactly the same state that it would be in where it is declared: var x: T = undefined; x.init();
<andrewrk>
it's similar to a popular practice in C of having a free() function actually accept a pointer to the pointer, so that it can set the outer pointer to NULL
<andrewrk>
I believe ffmpeg does this for example
<betawaffle>
ok, all of this is what i wanted. thanks
<andrewrk>
mikdusan, out of curiosity, what's your non-yak-shaving zig project?
<andrewrk>
I mean, you do a bunch of contribution to zig itself, but are you working on something in zig that is not zig?
<mikdusan>
oh i'm overhauling my color tty to use new anon-struct literals and some other goodies; eg: `print("hello {}\n", .{ .standout, "world" });`
<mq32>
andrewrk, can you elaborate "yak shaving" to non-native speakers?
<mikdusan>
not there yet but I think this anon struct literal is going to be perfect for "initialization params" for types with significant amount of options
<andrewrk>
neat
<fengb>
andrewrk: daurnimator mentioned earlier this morning / his evening that fmt.format() could take a stream instead of output. What are your thoughts?
<andrewrk>
mq32, apologies, I try not to do that. I elaborated ^
<fengb>
Design wise it'd be pretty identical with my generator changes... except with sane semantics
<andrewrk>
mq32, also I can find a humorous video to explain yak shaving
<shakesoda>
particles + flow fields in my zig sandbox
<BaroqueLarouche>
shakesoda: nice! On which system do you run your IMGUI ?
<shakesoda>
BaroqueLarouche: opengl?
<BaroqueLarouche>
I used win32+Direct3D11 on my side
<shakesoda>
oh, sdl2+opengl
<shakesoda>
on windows, should run on linux too if i go fix the build
daex has joined #zig
<shakesoda>
found a strange bug while doing this, cimgui's functions returning ImVec2 (i.e. struct { float x, y; } cause crashes, had to hack in new ones that just return floats
<shakesoda>
and another one where my function I'm passing a float argument to just... gets 0.0
<shachaf>
Though I gues Zig uses LLVM so it's probably not quite that kind of issue.
<kristoff_it>
andrewrk: thanks. Something changed about that in the last couple of months right? I remember all imports from "../" to fail unless that option was specified, while now apparently I don't even need it to import files from within the project, regardless of which sub-tree they are located in
<andrewrk>
nothing changed afaik
<andrewrk>
how it is supposed to work is that each package has a root dir and root source file. @import, @embedFile, etc only have access to paths inside that package
<andrewrk>
zig sets up a main package for you automatically based on the root source file, which means that the root package dir is the dir the root source file is in. so as long as your root source file is at the root of your package dir you'll have access to everything
<andrewrk>
(or you can override with --main-pkg-path)
<andrewrk>
this is currently a bit problematic with the automatically set up main pkg path when doing e.g. `zig test a/b/inner/foo.zig`, but this can be improved when the package manager exists, and there would be a way to infer a different root package path based on the file system
<kristoff_it>
oh ok I see, I probably encountered that before, because I used to call test on the specific file I was writing
<fengb>
He's just "using" Zig for his own nefarious purposes
<mikdusan>
`zig test a/b/inner/foo.zig`; how about `zig test a/b/./inner/foo.zig` and zig infers --main-pkg-path to be the point of superfluous "/./"; this is a trick that rsync uses to establish a base anchor point
<andrewrk>
that's an interesting idea
<companion_cube>
oh god that syntax :s
<companion_cube>
is this F#? :DD
<andrewrk>
I like to explore first the idea of searching the fs tree up to find a certain file which contains package metadata
<andrewrk>
s/I like/I would like/
<andrewrk>
because it is planned to have some strictly declarative package metadata in a file at the root of a package
<Barabas>
companion_cube I can't read it either :P
<companion_cube>
it's more that it seems extremely footgunny
<companion_cube>
where do things end
<Barabas>
It seems to use whitespace, like python
<mikdusan>
I was actually just thinking about what can be the recommended contrib repo setup. { `package.zig`, `package/` } and/or drive it with package metadata
<Barabas>
But it makes it hard to see the structure imho.
<andrewrk>
mikdusan, the current candidate is zig-package.json
<betawaffle>
(on macos)
<mikdusan>
ah
<betawaffle>
what's the solution to that problem? ^
<fengb>
`package-lock.json` 🙃
<andrewrk>
fengb, it is planned to save hashes (Trust-On-First-Use), so we do need somewhere to put those. I'm thinking it will also be in that same file. It's a file that is both edited by humans and by zig tooling
<betawaffle>
andrewrk: it's almost like we need to support `void` as a valid switch case that deletes the case at comptime
<andrewrk>
it would be nice if the format allowed comments and extra commas... like https://github.com/andrewrk/liblaxjson/ - but I think ultimately, better to stick to the standard
<betawaffle>
right, but it's entirely possible it doesn't actually exist on macos
<mikdusan>
err darwin.zig
<andrewrk>
betawaffle, all uses of EOPNOTSUP should be converted to ENOTSUP
<fengb>
YAML is a standard >_>
<mikdusan>
oh and darwin has that :)
<fengb>
Less trolly: I like TOML as a human editable format
<betawaffle>
but it's still a potential problem... sometimes there are errors that don't exist for a given OS
<companion_cube>
andrewrk: json5 ?
<companion_cube>
but toml sucks for nested structures
<andrewrk>
companion_cube, if json5 is popular enough, then this seems perfect
<companion_cube>
it's not very popular afaik, but if zig supports it…
<mq32>
<companion_cube> but toml sucks for nested structures
<mq32>
i don't think package declarations require much of a nested structure
<mikdusan>
s/json5/zon1/
<companion_cube>
you never know…
<mq32>
it's just a complexity thing
<mq32>
but yeah, maybe…
<companion_cube>
I imagine at least: a list of packages (when you start having several packagesin a repo) with lists of things in each of them
<fengb>
How does Rust solve this?
<andrewrk>
toml
<companion_cube>
there's a cargo file for the workspace, and one cargo file per crate, iirc (when you have multiple packages in a repo)
Barabas has quit [Ping timeout: 260 seconds]
<jaredmm>
I was never a big fan of the way Rust handled it. It was just a mess to figure out. That's the problem with most of these configuration systems. Configuration is hard and they try to abstract it all away, then you end up with a hard problem covered with a leaky abstraction.
<metaleap>
my nr 1 feature request from any future zig pkg mgr is that it wont impair the zig compiler's / build system's ability to function well locally without any notion of pkg mgmt. (always good to be able to have that option to fall back on simple local primitive building blocks and manual deps mgmt if need be)
<jaredmm>
I don't know what the median between everyone is identical and everyone is custom is, but I hope there's something better than Cargo. Multi-crate projects are (were?) hell.
<andrewrk>
metaleap, package manager will just be a glorified downloader and tool to help you figure out wtf is going on with your dependencies. it will always be possible to copy+paste a file or directory into your source control and make that a "package"
<metaleap>
andrewrk glad to hear that!
<andrewrk>
package management in zig will require manual upkeep to update to newer versions of things. people who build your project from source will get exactly the versions of things that you tested with
<andrewrk>
if there's a security advisory in a package you depend on, that's your problem too. zig won't solve this for you automatically
<companion_cube>
aka lockfile? :)
<fengb>
What about resolving duped packages that are on different versions?
<andrewrk>
the plan is more strict than version locking - actual hash of all files of the package. so that it doesn't matter whether it came from a source control checkout, tarball download, ipfs, whatever
<andrewrk>
fengb, I put a lot of thought into that but I forget where I landed
<companion_cube>
almost sounds like andrewrk's mind was contaminated by nix… :-°
<andrewrk>
I know enough that is certain to make progress, without answering that question yet
<mikdusan>
one slick example I like of grabbing repos to add capabilities is vim. just clone into ~/.vim/pack/dist/start and voila!
dimenus has quit [Ping timeout: 265 seconds]
<andrewrk>
I agree, that is a great user experience
<andrewrk>
and it didn't used to be that way
<jaredmm>
Cargo pulls in multiple versions and trys to mangle names to get you working software, but I'm not a huge fan of it.
<fengb>
npm pulls in all the versions and gives you all the versions at once. But sometimes it pretends to dedupes. It's the "best" of both worlds! 🙃
<jaredmm>
I don't know why npm got so many people hopped up on the idea of dependency ranges. You give one version, that's what gets used. ~Fin~. Maven had ranges for years and the entire industry decided not to use it and it was nice.
<companion_cube>
mikdusan: don't you use Bundle or something similar?!
<mikdusan>
companion_cube: old way was to use stuff like that. no longer needed, I think vim 8.0 or higher?
<fengb>
Because in frontend, bloat actually matters. An extra package can be 100kb or more
<companion_cube>
I find that simpler than cloning a ton of stuff in my ~/.vim ?!
<jaredmm>
That's a problem they made themselves, though.
<mikdusan>
bundle/vundle/pathogen. but you have to install those first.
<fengb>
Of course, npm is super lousy at deduping so it's not a good solution either
<jaredmm>
npm bundle isn't a solution to having 18 billion dependencies replicated every time you try to download anything. That's not a runtime size problem, but it is a problem.
<jaredmm>
Things like pnpm try to say "let's be a bit saner about this", but the inconsistency of the tooling means that not everything is compatible.
<fengb>
The 18 billion dependencies is because everyone decided to make tiny packages so it's impossible to do anything sane without pulling in leftpad
recombinant has quit [Quit: Leaving]
<jaredmm>
I know. For 40 explicit dependencies in our `web application`, there are 50k implicit dependencies.
<Snektron>
This is starting to beckme a problem in rust too
<Snektron>
Im looking at you, ncpus
<Snektron>
And rand
<companion_cube>
mikdusan: ah wait, I use `Plug` now, ships with neovim I think
<Snektron>
Beckme -> become
<fengb>
Java has the same problem. I'm sitting on a project with 5 different Optional implementations. It's just less exacerbated because A) there's some semblence of a standard library, and B) bundle size isn't a big concern
<mikdusan>
companion_cube: i dunno. I just clone. and once in a while eg. `cd .../start/zig.vim; git pull`. done.
<companion_cube>
I just `:Plug update` 🤷
<fengb>
I bet we still ahve Joda time since most of this project is before Java 8
<companion_cube>
(and I have > 30 plugs)
<andrewrk>
companion_cube, having only vim installed is simpler than having vim installed + following the installation instructions for those third party projects
<daurnimator>
08:33:34 <fengb>andrewrk: daurnimator mentioned earlier this morning / his evening that fmt.format() could take a stream instead of output. What are your thoughts?
<jaredmm>
Bundle size in Java is a big concern, but not as big as frontend sizes. Java libraries duplicating things that were missing from the standard library is a problem, but mostly because you pay a size penalty even when you don't use it unless you explicitly exclude it (because reflection could use it even if the code doesn't show it).
<companion_cube>
andrewrk: the installation instructions are `Plug 'foo/bar'` in my vimrc
<companion_cube>
for each package
<companion_cube>
it's tremendously simple
<mikdusan>
companion_cube: i'm not sure how much diff neovim is
<companion_cube>
well it's not that different these days
<companion_cube>
but it'll get builtin LSP in 0.6 I think
<andrewrk>
daurnimator, I think it's not time for that yet
<mikdusan>
companion_cube: i'll give you an example. vim does not know what "Plug 'foo/bar'" does
<jaredmm>
Most binary deployments have the same issues and that's why static vs dynamic linking keeps going back and forth as to what the best practive is.
<companion_cube>
nvim does, vim does too if you install, say, Vundle
<mikdusan>
companion_cube: that's my point. you have to install something first
<fengb>
jaredmm: yeah, JS standard library is nonexistent so every project and their mom decides to reimplement their own leftpad. Or use some random guy's leftpad
<companion_cube>
for years I had a submodule with just vundle in it; then I'd use vundle to install the rest
<andrewrk>
streams already have a print method. std.fmt.format is lower level
<companion_cube>
in nvim it's already there ✔
<andrewrk>
I'm going to make a zig leftpad package with the description "haters gonna hate"
<andrewrk>
oh, too bad we don't need it though because we have formatted printing
<companion_cube>
andrewrk: any language with printf can laugh at leftpad :/
<fengb>
Any language with a strong stdlib
<jaredmm>
I mean, the "right" way to do it would probably have been to collect the most popular packages into a single library and have that standardize in the browsers (IE building a stdlib).
<jaredmm>
Probably save a lot of trees and coal that way, too.
<fengb>
But nobody can decide on the standard, so we have 10 standards!
<jaredmm>
Surface it through whichever consortium Google has decided is the real one, since they apparently own the internet now.
<andrewrk>
with zig package manager if you were worried about a package getting removed from the internet then you should mirror it somewhere and depend on that instead
<andrewrk>
zig will only protect you from getting incorrect bits. zig project won't have any central repository
<jaredmm>
I do recall that from the GitHub issue discussion. Once Zig becomes popular enough, companies like Sonatype will add support to their tools. Most enterprises aren't re-downloading data from a central repo.
<companion_cube>
andrewrk: hopefully people will use bittorrent
<andrewrk>
companion_cube, this is off topic, let's keep comparisons with other languages technical and not jump onto a trash talking bandwagon
<companion_cube>
the perfect tool for delivering packages
<companion_cube>
yeah, yeah, sorry.
<companion_cube>
it's more like that guy with his tons of micro repos and "standard.js" styleguid 🙄
<andrewrk>
talking about that here can only cause problems and it's not productive. game theory says: off topic
<fengb>
I used standard before prettier
<fengb>
I liked it since it stopped bikeshedding
<companion_cube>
I think it's a good lesson about having an opinionated syntax though
<andrewrk>
bittorrent for packages would be supported via an "fetch plugin package"
<companion_cube>
andrewrk: yes, I mean I hope people will adopt bittorrent in practice
<andrewrk>
part of that declarative package file would list the fetch plugin packages, which could then allow more ways to fetch bits
<fengb>
Honestly, Go was my biggest eye opener. I `*hated*` Go syntax... then forgot about it a week later
<Snektron>
As long as its consistent really
<andrewrk>
fengb, I'm hoping that happens to me with `const foo = fn...`
<fengb>
You accepted syntax that you hate? >_>
<andrewrk>
yep
<andrewrk>
for consistency
<mikdusan>
fengb: well there is the ultimate card -- anything up until 1.0 is fair game to be changed :)
<fengb>
There's some strong pushback to the new syntax heh
<fengb>
Speaking of which... can someone convince Rocknest that I'm not destroying Zig by asking for declared tuples? :(
<mikdusan>
is XDG Base Directory Specification a linux thing or ok for FreeBSD too?
<andrewrk>
fengb, I think this is one of those problems where you can simply ignore it and it will go away
<andrewrk>
mikdusan, maybe the #freebsd channel would have a good answer to that question
<mikdusan>
searching it shows up at freedesktop.org ; I'm wondering if we should honor XDG_CACHE_HOME on macos too. currently it kicks in for anything not {windows,macos}
<mikdusan>
not a big deal
<andrewrk>
mikdusan, I think that you are a good example of a macos user - what behavior would you expect?
metaleap has quit [Quit: Leaving]
<andrewrk>
if you would expect it to honor XDG_CACHE_HOME on macos then I agree
<kristoff_it>
man I was able to give a good refactoring to my project now that I can import from `..`! That was satisfying. Time to go to bed for me, have a good rest of day to everyone else!
kristoff_it has quit []
<andrewrk>
good night
<mikdusan>
'night
ur5us has quit [Ping timeout: 255 seconds]
<mikdusan>
I've never seen XDG_CACHE_HOME defined on macos. Unless it's a *thing* I'd probably not want to honor it; that aside, when self-hosted matures, we might look to making ZIG_CACHE env var
<mikdusan>
or similar. main reason being when I do tests (for example memory profiling) I do want to start from scratch. make zig do as much work as possible. and `rm -fr` on anything like ~/Application\ Support/zig is freaking error-prone
<mikdusan>
thanks apple for putting spaces in paths
dingenskirchen has quit [Quit: dingenskirchen]
dingenskirchen has joined #zig
<andrewrk>
ZIG_CACHE is probably a good idea
<andrewrk>
ZIG_GLOBAL_CACHE at least
<mikdusan>
and alas, macos doesn't have containers. I really wish they had linux-style containers, or solaris zones. jail support on macos is useless. Sandbox (a macos thing) might hold some promise.
<fengb>
It has Docker for Mac 🙃
<mikdusan>
docker for mac is step1. run linux in a VM. then run docker in linux VM :P