<diltsman>
A couple of days ago, andrewrk told me "make your file my_windows.zig and have it do `usingnamespace std.os.windows;`. then you can augment the std lib with whatever you want"
<daurnimator>
diltsman: yes. for now use `usingnamespace`
<diltsman>
I am trying to figure out how to do that. Sorry, my only experience with Zig up to this point is writing bare metal with no standard library.
<daurnimator>
diltsman: usingnamespace sort of "imports" the referenced struct into your current one
<diltsman>
my_windows.zig has "usingnamespace std.os.windows;" The compiler just says "use of undeclared identifier 'std'
<daurnimator>
diltsman: have you imported std first?
<diltsman>
There we go. I was trying to figure out the @import for that. Thanks.
<daurnimator>
emekankurumeh[m]: you don't use the raw syscalls on windows
<daurnimator>
so that second link isn't useful
<daurnimator>
emekankurumeh[m]: ntdll is sort of like a vDSO that is already in your address space; it contains syscall wrappers.
<daurnimator>
its only for super super rare situations where there is no ntdll wrapper that you'd need to do a syscall directly
<emekankurumeh[m]>
that second link lists ntdll functions as that is the stable syscqll interface (I think)
<daurnimator>
emekankurumeh[m]: you mean the first link?
<emekankurumeh[m]>
that second is just ntdll function availability by windows version
<emekankurumeh[m]>
hmm, it would seem i didn't look too closely
<fengb>
Is release-small an LLVM thing?
<daurnimator>
fengb: I don't know; but I imagine the 'small' is equivalent to `-Os` and the 'release' is more of an instruction to zig
<fengb>
I’m more concerned about the small thing. I have 3 func calls that are being inlined and adds 200 bytes. Not sure if I should just insert @noInlineCall
<fengb>
Sometimes... I should stop counting bytes :P
<daurnimator>
fengb: could you try an equivalent C program with clang and -Os?
<daurnimator>
also am I crazy or did there used to be a `-Oz` option to C compilers that was "really small"
<emekankurumeh[m]>
but, a windows application that didn't rely on ntdll sounds pretty cool
<daurnimator>
emekankurumeh[m]: not really. only useful to avoid things that hook into ntdll for tracing
<daurnimator>
(and hence only really useful for viruses/malware)
kristoff_it has joined #zig
<daurnimator>
ntdll is automatically loaded into *every* process on start. you get it "for free", and you can't opt out: you might as well use it (rather than track syscall numbers that change in minor releases)
<daurnimator>
huh. looks like gcc removed their documentation of the -Oz option. clang still mention it
<emekankurumeh[m]>
ntdll only it is then
<daurnimator>
emekankurumeh[m]: yep. that's called a "native" app. they're really cool and underutilised
kristoff_it has quit [Ping timeout: 244 seconds]
<emekankurumeh[m]>
rust also has a "-Oz" option
<fengb>
wasm-opt also has -Oz
<daurnimator>
fengb: maybe you're looking for the LLVM flag optForMinSize
<fengb>
I kinda want @call now so I can swap between call styles on the release type
<daurnimator>
or maybe not.... that flag seems to have been demoted in ~2016/2017
<daurnimator>
gonz_: enums don't make good bitflags...
<daurnimator>
gonz_: usually enums are 0,1,2,3,4,5,... if you have 1,2,4,8,16,... you should be using a packed struct with u1 members.
<gonz_>
Why don't they?
<gonz_>
This is for C interop and the enum values are defined as powers of two
NI33_ has joined #zig
<euantor>
thanks for the review @daurnimator :)
<daurnimator>
euantor: no problem. hopefully it's helpful rather than nitpicky. I'm not too sure where to draw the line
<daurnimator>
euantor: btw I liked the previous commit with `err != 0` over the current one with err as a `?u16`.... but I can't articulate why
<euantor>
No problem, I'm fairly new to Zig so any feedback is helpful. I wasn't sure which approach I preferred for errors at all, but `?u16` seemed like it was clear what was actually happening
<daurnimator>
euantor: I was wondering if it would be clearer without `num_read` getting returned from a block? really you want to return both err *and* num_read from the block, but there isn't a nice way to do so
<euantor>
Yeah, that's the exact problem I was having. A `Result` type would work, or I could move the block into a function and have it return a `!usize` but I wasn't sure what to do
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
kristoff_it has quit [Remote host closed the connection]
kristoff_it has joined #zig
autodidaddict has quit [Remote host closed the connection]
NI33_ has quit [Ping timeout: 272 seconds]
autodidaddict has joined #zig
Tetralux has quit [Ping timeout: 245 seconds]
Tetralux has joined #zig
nairou_ has joined #zig
<autodidaddict>
I'm trying an experiment where I want to see if I can get Zig to encode and decode protobufs. I figured the "easiest" way to try this would be to harness Zig's C integration and use libprotobuf-c . I'm running into a couple of problems: a) I don't know if I'm supposed to compile that library and copy it into a path prior to Zig compilation, or if I
<autodidaddict>
'm supposed to tell Zig to build libprotobuf-c as well. b) I can't get libprotobuf-c to compile because there's no "protobuf.pc" file in my pkgconfig (even though I've done a make install on protobufs)
<autodidaddict>
My lack of familiarity with the C build tool ecosystem is really the root cause of failure here
<autodidaddict>
After finally being able to build protobuf-c and generate the .pb-c.c and .pb-c.h files, what extra stuff would I need to include in a Zig project to get that to compile?
<Tetralux>
It depends on the use of macros in the generate file.
<Tetralux>
If it's all basic stuff
<Tetralux>
@cInclude may be enough in your Zig code.
<Tetralux>
(In which case, Zig will compile it and handle the object for you.)
<autodidaddict>
how would Zig know that it needs the libprotobuf-c library?
<Tetralux>
You'd tell it.
<Tetralux>
Either `--object path/to/lib/file` or in build.zig
<Tetralux>
`addObjectFile` IIRC.
<Tetralux>
I never used build.zig personally, but I think you'd be able to add it with either `addObject` or `addStaticLibrary`/`addSharedLibrary`.
<autodidaddict>
the zig compiler crashes on tabs?
<autodidaddict>
error: invalid character: '\t'
<Tetralux>
It should _error_ on tabs, not crash.
<autodidaddict>
I was just editing with vi.. didn't realize it was spaces-only
<Tetralux>
Yeah - that can be a bit of a gotcha.
<Tetralux>
xD
Tetralux_ has joined #zig
<autodidaddict>
mind is about to be blown. It compiled... but since I didn't instantiate any structs (yet), it could just be that it stripped the protos
<fengb>
Zig is lazy and doesn’t compile unreferenced code
<autodidaddict>
yeah that's why I suspect it compiled ;)
<Tetralux_>
RE mind blown - I know the feeling - you should also take a glance at `zig cc` when you have a moment too ;)
<autodidaddict>
just trying to figure out how to instantiate a C struct in zig
Tetralux has quit [Ping timeout: 246 seconds]
Tetralux_ is now known as Tetralux
<autodidaddict>
this is what my import looks like:
<autodidaddict>
const c = @cImport({ @cInclude("addressbook.pb-c");});
<Tetralux>
var s: c.MyCStruct = undefined;
<Tetralux>
IIRC.
<Tetralux>
(.. Assuming that "addressbook.pb-c" is the path (relative to the Zig file) of the generated C file)
<Tetralux>
(.. Which it prob isn't. xD)
<Tetralux>
Should be more like:
<Tetralux>
const c = @cImport(@cInclude("soundio/soundio.h"));
<autodidaddict>
it's in the build directory, and yeah I'm having trouble with locating the file
<autodidaddict>
should I cinclude("./foo.h") ?
<Tetralux>
If your .h includes your .c, then worth trying.
<autodidaddict>
I don't think it does. protoc just generated a pair of files - a .c and a .h
drazan has quit [Remote host closed the connection]
<autodidaddict>
ok, pulled from master and that issue went away. Still can't get zig to find the .h file
<samtebbs>
autodidaddict: I've not used C header files with Zig much but I think you can pass `-isystem <path>` to zig to add the path to where your header files are stored. There should be an equivalent for the build system
<autodidaddict>
how do you get it to find the headers from inside a library? I got it to find my .h file, but now it can't find "<protobuf-c/protobuf-c.h>"
drazan has joined #zig
<autodidaddict>
ok, I'm not sure if that was the right way ... but I just included -isystem /usr/local/include
<autodidaddict>
this might be my last question... (yay the newb will be silent!) ... but how do I tell the zig compiler to use the wasm libc (my code requires a libc and so it fails to compile when targeting wasm32-freestanding)
<fengb>
There’s wasm32-freestanding-musl but it’s incomplete
<autodidaddict>
so zig build-lib -target wasm32-freestanding-musl?
<autodidaddict>
I get the same message about "libc headers not available, compilation does not link against libc"
<autodidaddict>
I get another weird error: /usr/local/Cellar/zig/0.4.0/lib/zig/std/fs/file.zig:14:15: error: container 'std.os' has no member called 'fd_t' handle: os.fd_t,
<fengb>
Do you use std.debug.warn? That blows up in wasm32
<fengb>
I’ve been meaning to fix that
<autodidaddict>
my build command: zig build-lib src/main.zig --object /usr/local/lib/libprotobuf-c.dylib -isystem /usr/local/include -target wasm32-freestanding-musl --library c
<autodidaddict>
let me try building it without the stdout code
<fengb>
wasm doesn't (and freestanding cannot) have stdout so that just dies with a cryptic error
<autodidaddict>
right.
<autodidaddict>
it compiles!
<fengb>
\o/
<autodidaddict>
in theory, I should then be able to export a function that involves the packing and unpacking of protobufs (the hypothesis I'm trying to prove)
<autodidaddict>
cool. My apologies for slathering this channel in newbsauce this morning. I've noticed a lot of people exploring Zig come from a place of comfort in the C build system, and that's alien to me so I feel like I'm learning how wheels work while learning how to drive the car
<fengb>
It's fine. Always excited to have another wasm dev :P
<autodidaddict>
I'm trying not to feel like a traitor to Rust after my Rust+Wasm book... but I'm exploring the possibility of hosting Zig-based modules in my Waxosuit host runtime
<fengb>
We're all friends here. I personally believe Rust and Zig are pretty complementary
<fengb>
(I also sorta gave up learning Rust because I couldn't grok it but that's a side note)
<Tetralux>
I tried writing a lexer/parser in Rust, and gave up xD
<fengb>
But I've always been more of a baremetal C guy than C++
<Tetralux>
I might have been, but I like function overloading and auto too much for that
<autodidaddict>
I'm finding it interesting approaching Zig from a Rust background
sourgrasses has joined #zig
<fengb>
We give you rope if you need it :P
<Tetralux>
I like having rope :3
<Tetralux>
Means I can use it as a lassoo if I need it.
<autodidaddict>
Every time I see a pointer being used so casually, I freak out. Rust's compiler spends all day stabbing you for free-roaming unsafe pointer access
<fengb>
Most day-to-day you should use single pointers and slices, which have proper bounds checks
batok has joined #zig
<fengb>
Of course I say this as I'm manually carving out a struct from a slice of u8s >_>
<scientes>
Tetralux, zig has auto
ltr- has joined #zig
return0e has joined #zig
halosghost has joined #zig
<samtebbs>
autodidaddict: newbs are welcome :)
<scientes>
bugs, bugs, bugs, bugs
dimenus has joined #zig
<Tetralux>
scientes: It does indeed. Not name-qualifying, but still. Better than nothing ;D
<scientes>
there are bugs EVERYWHERE
<andrewrk>
scientes, that tends to happen toward the end of the release cycle (before I spend the tail end doing mostly bug fixes)
<scientes>
no, i'm talking about unreported bugs
<scientes>
and bugs in my own code
<andrewrk>
ah
<mq32>
andrewrk, a question on your planned package manager:
<mq32>
how do you want to handle dependencies of referenced libraries?
<mq32>
does each library enforce a certain other version (by hash, name, ...)?
<andrewrk>
every package declares the exact hash of its dependencies. however there is still a concept of semantic versioning of packages, and one package will be supplied instead of another if it is compatible
<andrewrk>
and then there is an auditing tool (`zig pkg --list` or something) that shows what packages end up being used; whether there are duplicates (due to incompatible major versions, etc)
<mq32>
hm. please add an option to allow arbitrary dependency overrides
<mq32>
i currently have a problem in .NET that one library (A) enforces dependency B¹, but i want to use version B² of it
<andrewrk>
that's a possibility. the decentralized nature of it also means you can fork something and use that fork instead, it wouldn't change the package id
<mq32>
both are "current version", but with different "backends" builtin
<Tetralux>
If you specify a version or hash of a package you need, but you want that specific version only, will it in any circumstances provide different ones without confirming otherwise?
<Tetralux>
And if so, will there be a way to prevent that in build.zig and the cmdline.
<Tetralux>
Will there also be a way to quickly get to a changelog of sorts for updates to packages you are using?
<Tetralux>
(.. So that you might audit those changes before upgrading.)
<Tetralux>
.. without having to dig through documentation or git history or whatever.
laaron has quit [Remote host closed the connection]
<andrewrk>
current plan is if you want a package to not participate in semantic versioning then you'd fork it and change the package id
<Tetralux>
That's if you want to do something akin to what Zig currently does with LLD right?
<andrewrk>
what upgrading looks like is a tool that detects new versions of packages, presents those changes in some helpful way, and you can accept the upgrade(s) you want, which locks them in to the new hashes
Akuli has joined #zig
<Tetralux>
One issue I've always had with package managers like apt-get etc, is that they tell you nothing more than the version number changes, at best.
<Tetralux>
That tells me nothing about what the changes actually are.
<Tetralux>
And so I can't really make an informed decision on whether I should update yet or not.
<andrewrk>
ultimately it's up to the programmer to decide what to depend on, but I do intend to put effort into tools to make the job more ergonomic
<andrewrk>
a fully informed decision is out of scope of the package manager; it's a social/technical judgment call the programmer must make based on information the tool does not have access to
<mq32>
andrewrk: to solve my problem, it would be enough to make a local copy of the package manifest the programmer could edit
laaron has joined #zig
<Tetralux>
Except that where the information _is_ located is not very obvious.
<mq32>
(instead of creating a whole new package to just change a single dependency)
<Tetralux>
Which is why I never read it.
<Tetralux>
Further, I'd maybe want to update _one_ package at a time, rather than all or none.
<andrewrk>
mq32, with the current design, you'd have to fork A
<Tetralux>
update A, compile, fix, update B, compile again, fix again, etc.
<andrewrk>
mq32, reasoning here being: the author of A made a clear decision about what to depend on, and to override that decision, you are forking the project
<Tetralux>
Though, since _you_ know the requirements of your project more than the library author does, you can make better decisions about that.
<andrewrk>
mq32, the difference here, however, being that your fork can "steal" their package id
<mq32>
so i have the decision to either "get my project running and update everything by-hand" or "don't get my project running, but have to option to automatically update my depdencies"?
<andrewrk>
I didn't quite understand that
<scientes>
you don't have to fork both
<scientes>
you only have to fork one
<scientes>
right?
<mq32>
andrewrk: when i fork, i'm the maintainer of the package, right?
<andrewrk>
right, you fork A, change its dependency to point to B2, and then update your URL of A to your fork
<mq32>
so i have to provide updates and everything
<mq32>
just because i edited a *dependency*, not the library itself
<andrewrk>
mq32, right. and you should test issues upstream before reporting issues upstream
<scientes>
andrewrk, oh you can't just MITM the dependancy of A?
<andrewrk>
scientes, you can. by forking it
<scientes>
yeah but that isn't MITM
<mq32>
andrewrk: so you're creating the same problem i'm stuck with ATM
laaron has quit [Remote host closed the connection]
<andrewrk>
is the problem how convenient it is to patch someone else's library?
<mq32>
i don't want to change any bit about the source code of the library
<mq32>
not a single bit
<mq32>
just change a third-party dependency to make my project run
<andrewrk>
yes you do, you want to change the bits of the hash of its dependency
<gonz_>
Please never allow dependency overrides
<scientes>
I think the user should have control over the namespace
<scientes>
if only because there isn't any security loss in doing so
<scientes>
with like an override file or something
<mq32>
andrewrk: why i'm bringing up the topic: exactly this topic forces me to edit .NET assemblies by hand to just say: "god damn, use the library with OpenGL backend instead of DirectX. all public members are literally the same, only the *name* of the library differs"
laaron has joined #zig
<andrewrk>
anyway these are good questions. the first step will be the less controversial stuff, basic support, and then we can address the more advanced use cases
<mq32>
i don't want to recompile 10 libraries by hand to get this working
<scientes>
it should always be easy to fork a library
<mq32>
</rant>
<andrewrk>
yes I don't think people here are fully grokking the package id fork thing yet
<gonz_>
Forking is not the same as "I use a dependency and from my project magically override which dependency that has access to"
<andrewrk>
an "override manifest file" is essentially a light weight fork which is stored as a patch file
<gonz_>
Parametric packages would be neat, but magic overrides are not that.
<scientes>
forking a library should be as easy as forking a front-end
<scientes>
but you could print a warning when building with a locally forked package
<scientes>
its essential to debugging to be able to easily fork at any place
<scientes>
that's what open source is all about
* mq32
is still not convinced that "forking" is the right tool here to solve my issue
<mq32>
because of the propagation effect
<andrewrk>
what's the propagation effect?
<scientes>
mq32, we are talking about the same thing
<mq32>
not sure
<mq32>
i have HtmlRenderer.PdfSharp which depends on PDfSharp
<mq32>
PDfSharp is a project that spills several dependencies: PdfSharp, PdfSharp-gdi, PdfSharp-wpf, PdfSharp-silverlight, PdfSharp-core, ...
<mq32>
*-dependcies +variants
<mq32>
each of these variants has the exact same public API
<mq32>
if i would solve the problem of HtmlRenderer.PdfSharp depending on PdfSharp by forking, would create 5 versions of HtmlRenderer.PdfSharp that have exactly sizeOf(dependency-hash) bytes difference
<mq32>
now imagine a next library depends on HtmlRenderer.PdfSharp
<mq32>
now this library also needs 5 variants to be used
<mq32>
*created
<gonz_>
Isn't your problem actually a lack of parametricity in actual code?
<scientes>
dependency hash is a really bad idea
<gonz_>
Something could easily take these as parameters, i.e. as adapters
<scientes>
unless it can be easily overridden
<scientes>
it makes it to difficult to fix things
<mq32>
gonz_, nah, it's a problem in the base technology (.NET)
<mq32>
the splintered their codebase into several subsystems
<mq32>
and yeah, we could comptime-solve this with Zig easily, but my experience tells me that something like this (having several versions of the same library) may also happen with zig in the future
<mq32>
so there is a requirement to reference libraries based on some settings like platform or similar
<andrewrk>
mq32, in this example, what is the modification that needs to be made? the actual problem?
<andrewrk>
why can't you use the upstream package directly?
<mq32>
"change the enforced dependency to PdfSharp to PdfSharp-gdi"
<mq32>
*from PdfSharp to PdfSharp-gdi
<mq32>
(different assemblies of the same library)
<andrewrk>
that sounds like 1 change to me, not N. I don't get it
<mq32>
the point is: i still want to have the upstream version of the original library to obtain all updates and such
nairou_ has quit [Read error: Connection reset by peer]
nairou_ has joined #zig
<mq32>
it would be N libraries if we would make the "clean" version, or i could maintain a local package myself with unnecessary overhead to manually check for updates
<andrewrk>
you already have to manually check for updates with planned zig package manager
<andrewrk>
you don't get code that you didn't ask for
<andrewrk>
strict hashing means you get the exact version you decided on. if you want a different version you have to choose a new hash
<mq32>
that is clear
<mq32>
but there should be an option to check for "has any of my dependencies a newer version out there?"
<scientes>
ugggh, i think that is the exact opposite of what i want
<scientes>
if you want to pin the a version, you clone it locally
<scientes>
otherwise you want to always use HEAD
<gonz_>
Ugh
<andrewrk>
nope that's not going to happen scientes
<andrewrk>
mq32, I see, the fork gives up the convenient detection of updates
<mq32>
yes
<andrewrk>
¯\_(ツ)_/¯ try not to fork stuff
<mq32>
updating should be manually triggerd, but then be done automatically (in terms of zig pkg update my-fancy-library)
<mq32>
andrewrk, but you told me forking is the solution! *grin*
<andrewrk>
forking was the premise
<gonz_>
Personally I want precision in dependency specs. Ideally whatever identifier you have for a dependency always means the same thing for everyone who downloads the dependencies, today, tomorrow and forever.
<andrewrk>
your premise was that you needed to fork a package
<mq32>
hm
<andrewrk>
clearly, a well-managed package that doesn't need to be forked, would be preferable to depend on
<mq32>
my wish was to manually override the dependency for a single package (because i am the developer of this single thing, i have the right to choose what i want to do)
<nairou_>
Is there perhaps a way to tag local forks as having a parent, and package update checks look at the parent in that case rather than the package itself?
<andrewrk>
nairou_, that sounds like it's worth exploring
samtebbs has quit [Quit: leaving]
<andrewrk>
mq32, if you're the developer of the package, why not release a version that actually does what you want?
<andrewrk>
I don't get it, why use packages if you just want to hack them up? commit all the code to a monorepo then
<mq32>
nah
<mq32>
i don't want to change anything about the source of the package
<mq32>
(if you exclude package specification from the source code)
<Tetralux>
mq32> ecause i am the developer of this single thing, i have the right to choose what i want to d
<Tetralux>
mq32: +1
<Tetralux>
In my mind, the author of the package is only in control of what they are publishing.
<mq32>
andrewrk, and i'm not developer of the package i want to change, but of a package that depends on the thing that is wrong
<Tetralux>
Exactly.
<andrewrk>
that is the definition of a fork
<andrewrk>
you're not the developer and you want to change it
<andrewrk>
so do it
<andrewrk>
fork it
<Tetralux>
It's essentially the same problem as how C libraries may have named something "Quarternion" but I have my own quarternion that has a slightly different, but important meaning.
<Tetralux>
If they'd called it "LIB_Quarternion" I'd be okay, but it'd be annoying.
<andrewrk>
or convince the upstream developer to release a version that includes the ability to do what you want
<Tetralux>
And normally, you have to change _yours_ and not theirs.
<Tetralux>
The specific case I was thinking of was where the offending Quarternion was in the Nintendo SDK.
<mq32>
andrewrk, in my case that would mean to first bug the developer of library B, then the developer of library A and then i can finally compile my code ^^
<andrewrk>
one related concept here is build options. packages can expose build options which can be configured by downstream packages
<nairou_>
He wants to change a package dependency that requires no code change. Switching from one API provider to another identical one.
<Tetralux>
mq32> That would mean bugging the dev; +10
<andrewrk>
so for example they could expose a Quaternion option with a default
<andrewrk>
or a PdfViewer option with a default, etc
<Tetralux>
Yes - but they haven't.
<Tetralux>
And they _might_ not.
<Tetralux>
Or it might be a pain to contact them.
<andrewrk>
then you need to send them a patch, or fork it
<Tetralux>
Or even convince them to do so.
<fengb>
Has this been solved in any other package system before?
<Tetralux>
I'd rather not use the package and use one that just works TM.
<mq32>
got to go. just wanted to start this conversation as this happendend not only once to me before
<andrewrk>
thanks mq32 for the good use case
<mq32>
:)
<andrewrk>
people here are thinking from the perspective of the application developer. but the perspective of the library author is important too. we need library authors to be able to rely on their dependencies
<mq32>
and if i have to choose between a) bugging the devs until they fix it, b) creating a fork and maintain until death or c) do evil hackery, i will choose c) because it's the way of least unnecessary work in the long term
<Tetralux>
mq32: +10.
<mq32>
andrewrk: yeah, my point is: if i want to fuck things up i should be able to do so AND be responsible for that
<gonz_>
I don't disagree with that last part
<andrewrk>
I definitely think there should be friction going from (a) to (b) and friction going from (b) to (c)
<Tetralux>
Packages I downloaded should essentially become nothing more than "source files that came from someone else" as far as my project is concerned.
<andrewrk>
(a) is best, (b) is second best (someone has to maintain packages, and if (a)'s not happening then you may need to be the one) and (c) is self-admitted evil hackery
<mq32>
also, before i forget: andrewrk, sorry for the issue if it was unnecessary. i tested with upstream (or at least i though i was) and also searched issues for this problem. but i never found similar issues with github search :(
nairou_ has quit [Quit: Quit]
nairou_ has joined #zig
<andrewrk>
(c) is pretending that someone else is the maintainer of a package, but it's actually you.
<mq32>
sadly, i got to go
<mq32>
laters!
<Tetralux>
What about essentially doing `git diff` on packages, and if there's changes, warn you when updating it and alert you that you'll need to resolve any merge conflicts that result - but, **crucially**, allow you to attempt it and give up and revert to the version you originally had, with the changes that were present.
<andrewrk>
packages are a set of files, not a git repository
<Tetralux>
But the local copy could become a git repo for the purposes of tracking changes - or Zig could track them itself perhaps.
<Tetralux>
Where the initial commit is the state it was downloaded in.
<andrewrk>
there's no local copy when you freshly run the package manager
<andrewrk>
only the hashed versions are available
<andrewrk>
this is decentralization
<Tetralux>
Yes - I mean that once downloaded, the version you gets `git init` run on it.
<andrewrk>
what problem are you trying to solve?
<Tetralux>
The one of making local changes to the package, but still wanting to have a relatively easy way to update it.
<Tetralux>
Rather than being stuck on the version you have right now because it's a pain to update it.
<andrewrk>
what you're describing is vastly more complicated than forking
<Tetralux>
In what way?
<Tetralux>
It seems rather the same to me.
<Tetralux>
By changing it, I, the author of the app that is using the package, is accepting responsibility for the changes.
<andrewrk>
I'm gonna go work on async functions
<Tetralux>
XD
<scientes>
andrewrk, yes
<Tetralux>
Please do - I want to try using those things!
<Tetralux>
I honestly hope they'll be so easy to use and not think about that I can just use them without learning about lots of interesting details. ;)
<donpdonp>
whats the way to get 'zig/build$ make install' to target a specific folder?
<Tetralux>
I honestly hope they'll be so easy to use and not think about that I can just use them without learning about lots of interesting details. ;)
<scientes>
mikdusan2, but a test case is always what prooves it
<mikdusan2>
yes i'll run it thru the test guantlet soon
<scientes>
*new tests*
<scientes>
that demonstate the problem you were seeing
<Tetralux>
What's the best way to pass a `comptime T: type` to a fn, which can be any signed or unsigned type, and do something different in the body if it's signed?
<Tetralux>
.. So that I don't have to have a signed and an unsigned version of this function.)
<scientes>
if (@typeId(T) != .Int) @compileError(...) if (@typeInfo(T).Int.is_signed) {...}
<mikdusan2>
12 seconds. not bad scientes :)
<donpdonp>
is it too early for someone to write a book on zig typing o^O
<companion_cube>
don't forget to cite all the literature on dependent types and staged types ;)
nairou_ has quit [Read error: Connection reset by peer]
nairou_ has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
ntgg has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
<Tetralux>
Is there a way to transmute the element type of a slice?
<Tetralux>
i.e: convert []T -> []U
<scientes>
Tetralux, @sliceToBytes @bytesToSlice
<Tetralux>
Oh dangit - forgot about that xD
<Tetralux>
Ta :P
<Tetralux>
I'm trying to truncate-cast a u64 to a f64.
<Tetralux>
But warn keeps giving a runtime panic with 'integer cast truncated bits'
<Tetralux>
both 'took_sec' and 'len' are u64s that have been @intToFloat'd to f64.
<mikdusan2>
hmm isn't line #3 the error?
<mikdusan2>
presumably bytes.len is > 32 bits, and @intCast doesn't truncate. you'd want @truncate for that
<Tetralux>
I'm not using @intCast.
<mikdusan2>
ok but the error i think is a result of @intCast by std code maybe
<Tetralux>
That's what I was thinking.
<Tetralux>
But I can't do anything about that. xD
<Tetralux>
But bytes.len shouldn't be more than 16 bytes or so.
<Tetralux>
It's literally just formatting a number of bytes to something like "4.5 GB"
<Tetralux>
Takes an f64, and according to how big it is, changes the "G" to a "K" or an "M" etc.
<Tetralux>
I'm not trying to print the world out to stdout xD
kristoff_it has joined #zig
<Tetralux>
I'm fmt.allocPrint'ing the string and then passing it directly to warn.
<Tetralux>
Huh. Okay.
<Tetralux>
It seems that it was that when I returned the string, I wasn't `try`ing it.
<Tetralux>
But the return type was '[] const u8`
<Tetralux>
So I'm not entirely sure why I didn't get a compile error.
<Tetralux>
If I put in the try when I return, and when I warn, it works fine.
<mikdusan2>
aside from what you mentioned by try; i would say this smells like a corrupt buffer being sent down the line and that's why bytes.len is bogus.
<autodidaddict>
is there a progressive set of tutorials we can walk through to get the feel for the language rather than just reading that one html doc? In other words, is there an exercism.io course for Zig, or something similar?
<gonz_>
No, there's nothing that I know of.
<Tetralux>
Is there something specific you feel unfamiliar with?
<gonz_>
These are very early days in zig
<Tetralux>
Is there something specific you feel unfamiliar with?
<Tetralux>
Whoops. Did not mean to write that twice lol
<autodidaddict>
no.. it's just more that what's out there is very reference-y, and not very how-to-y :D
kristoff_it has quit [Ping timeout: 272 seconds]
<gonz_>
Yeah, it's early days enough where most people are just tinkerers and enthusiasts at this point
<autodidaddict>
ok cool. I like to think of myself as an enthusiastic tinkerer ;)
<Tetralux>
As a matter of interest, can you point to such a thing for a language that does have what you're thinking of?
<Tetralux>
The get-started one would be better if it was more on one-page.
<Tetralux>
Feels like I'm wading through tar for some reason.
<Tetralux>
But yeah - something like that would prob be cool.
<autodidaddict>
that get started page is super noisy
<autodidaddict>
but, I like the concept of the getting started roadmap.. build a hello world, then add a struct, now play with pointers, then do this... etc
<autodidaddict>
I'd maybe be interested in doing a zig book if/when it stabilizes on 1.0
<Tetralux>
gonz_: Oh yeah - that is _MUCH_ more my style.
<gonz_>
Most material will be made in time, given an enthusiastic and stable set of early adopters that evolve into it, I'm sure.
<nairou_>
I really liked what they have for Go (https://tour.golang.org), which introduces concepts and gives code samples you can play with.
<Tetralux>
I do remember liking the ability to play with it before moving on when I went through the Go tour.
<autodidaddict>
oh yeah.. the Go tour is awesome
<nairou_>
But I agree with autodidaddict, learning Zig is slow when all you have is reference documentation. Requires searching for examples or just trial and error, for each piece you want to figure out.
<gonz_>
I don't think anyone disagrees, really.
kristoff_it has joined #zig
<Tetralux>
How do you fmt print a float as a normal float?
<Tetralux>
Like 2.55?
<gonz_>
It's a matter of whether or not zig has the user base and is in a position to have materials like that yet. I think it's worth starting something like that if interest is there and seeing whether or not it's maintainable.
<nairou_>
I've been tempted, if only I had the time
<gonz_>
Having a cookbook repo might be a good start that's not too much of a commitment.
tobbez has quit [Ping timeout: 276 seconds]
<gonz_>
With common idioms, etc.
tobbez has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
<Tetralux>
Prey tell, where might one look to discover the characters that can be printed in a reasonable way, for example in warn, to allow me to feast my eyes on a floating point number that is nicely assembled into a 4.55 kind of way with a specifically assigned number of decimal places? :'3
<Tetralux>
And no I'm definitely not going mad trying to find out how I do that.
ltr- has quit [Remote host closed the connection]
<gonz_>
`"{d:.2}"` will give you a decimal representation with two decimals
<gonz_>
To get that I read the source
<gonz_>
`fmt.format` for the general precision/width specifiers, `fmt.formatFloatValue` for the `d`
<Tetralux>
OH MY GOD THANK YOU
<gonz_>
This might be one of those cookbook things.
<donpdonp>
reminds me of the best thing i found in std.fmt - allocPrint, which uses the fmt magic but returns it in a string. const pathStr = std.fmt.allocPrint(allocator, "./dir/{}", name)
<Tetralux>
Man - trying to read the call stack of the functions in std.fmt in order to figure out what the formatting options are is..... not fun.
<gonz_>
donpdonp: Indeed :)
<gonz_>
I've used that one a lot. You can even make it a cstr by ending the string with `\x00`.
<donpdonp>
which ironically doesnt print :)
<gonz_>
I've used it to debug some win32 stuff with messageboxes and `OutputDebugStringA`
<Tetralux>
I'm slightly amused by the fact that generating random numbers with WyHash goes at 9 GB/s in Zig, but 2.3 GB/s in Odin.
<Tetralux>
I smell a bug.
<Tetralux>
Probably mine x'D
<fengb>
I think the Zig "onboarding" only really makes sense for C programmers
<fengb>
*currently
<nrdmn>
has there been any progress on #786 (configurable error set integer types)?
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
<dimenus>
what's the best practice for storing common code for personal projects?
<dimenus>
is there an equivalent of a 'shared' collection in zig?
Akuli has quit [Quit: Leaving]
<nairou_>
For source code, or compiled libraries?
<dimenus>
source code
<dimenus>
eg my vulkan wrapper, matrix math etc
<nairou_>
Noob answer: From what I've seen, you would just keep your collection in a shared folder somewhere, and @import the needed file (or entry point file for a larger collection) using a relative or absolute path.
kristoff_it has joined #zig
<gonz_>
`deps` folder, git repos / links would be what I would go for
<dimenus>
zig does not tolerate relative paths that are outside of it's root
<dimenus>
error: import of file outside package path: '../zig-shared'.
<dimenus>
and so far, it doesn't seem to correctly resolve fully qualified paths either
<nrdmn>
I've been using git submodules for that
<nairou_>
I wonder if that's a bug. Documentation implies it's should work.
<dimenus>
i understand the long term goal being submodules, but they're not fully fleshed out libraries yet
<dimenus>
i'd much rather have a common spot and just deal with the compile errors if i make changes
<nairou_>
andrewrk's final content on that ticket says to import external code as packages. Was that an early reference to the upcoming package manager, or do packages already exist at some level?
<dimenus>
yeah that's what I'm really looking for is to import the content as a package
<dimenus>
the zig compiler compiles soooooooo much faster on *nix
<mq32>
integer representation may be different for the same address in C
<mq32>
i just throw in NEAR and FAR
<mq32>
for those who don't know: FAR is a 32 bit pointer in DOS that does 16 bit segmentation
<mq32>
and 0x00FF:0x0000 is the same (linear) as 0x0000:0xFF00
<mq32>
but integer repr. is differnt
<AlexMax>
Well, I found it curious. I was basically testing out the C-substitute-ability of zig by rewriting a C function in Zig, and I was starting out by doing a very much like the original translation
<mq32>
AlexMax, what does the original code with those magic pointers?
<AlexMax>
the original function does the "keeps multiple pointers into the same stream" thing that C is so well known for
<AlexMax>
I know Zig does things differenty with slices with known lengths and such
<AlexMax>
but it was basically comparing two unsigned char*'s to check to see if was past the end of some scan
<mq32>
ah
<mq32>
then i would recommend using slices, but you could also do @ptrToInt
<AlexMax>
Well, the thing is, the function's input is a [*]u8 coming from C, so it might take some reworking
<mq32>
a single [*]u8?
<mq32>
then just slice it
<mq32>
fn(ptr: [*]u8, len : usize) void { var slice = ptr[0..len]; }
<AlexMax>
Well, actually, I have a question about that, if I'm exporting a function with C linkage, should the parameter be [*]u8 or [*c]u8?
<fengb>
[*], [*c] should only be used from translate-c
autodidaddict has quit [Remote host closed the connection]
darithorn has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
Tetralux_ has joined #zig
<Tetralux_>
The number of people getting pinged from the fact that we have @Builtin functions must find it a little amusing... xD
Tetralux_ is now known as Tetralux
<nairou>
Huh... I tried creating a build.zig for a small C-only program, just to get my feet wet. Finally got zig building it without error. But when I run the resulting program, it's an immediate SIGSEGV. Clang by itself builds the project fine, so it's not that.
<Tetralux>
Does it do the same thing if you try to compile from the cmdline?
<nairou>
It consists of multile c files and multiple libraries, that's why I went with the build.zig file