<marler8997__>
let's see if zls documents which compiler version it works on...
<marler8997__>
oh no...I think compiler version issue
<marler8997__>
I'm going to forgo reading your helpful message for now and we'll see how easy it is :)
<marler8997__>
let's see how long this takes me, start the timer :)
<marler8997__>
oh, vscode is saying it needs zls exe in path...ok
<marler8997__>
any idea how I would configure it outside vscode?
<marler8997__>
alexnask, I assume you can configure it in vscode?
<marler8997__>
kakoune huh...maybe I need to check that out?
<marler8997__>
ifreund, I just tried it, didn't get any syntax highlighting, is it supposed to have it?
<marler8997__>
Nypsie that's a good suggestion, I'll see what I can find
<Nypsie[m]>
marler8997__: Yeah it's the language server. Not sure why the Zig extension is causing so much lag then. Have you verified all options are set correctly? Maybe it's trying to reach some path it cannot find.
<marler8997__>
ZLS is another plugin correct? If so, then no I don't have it installed
<marler8997__>
Nypsie, my source files aren't that large either
<Xavi92>
marler8997__: none so far. However, cpptools *is* really laggy and resource-intensive, at least on x86_64 GNU/Linux
<Nypsie[m]>
marler8997__: Do you maybe also have ZLS' semantic highlighting turned on?
<marler8997__>
been using vscode, and the Zig plugin from Marc Tiehuis really causes the editor to lag, anyone else experience this?
2020-11-05
<g-w1>
probably better to chat than github :P marler8997__
<marler8997__>
For those interested in Windows, I've got an initial implementation of my autogenerated Zig windows bindings, along with a concrete set of Goals for this project: https://github.com/marler8997/zig-os-windows
2020-10-11
<marler8997__>
let me know what he says
<wilsonk>
marler8997__: yeah, I sort of pinged them hoping they would let you know how they did it ;)
<marler8997__>
I don't see any script or docs on how gonzo generated what he has
<marler8997__>
I'm wanting a complete win32 api available in zig modules
<marler8997__>
wilsonk yes....however, it looks to be pretty bare bones
<wilsonk>
marler8997__: is github.com/GoNZooo/zig-win32 something like what you are looking for?
<marler8997__>
what would you use as the source for generating the modules?
<marler8997__>
But maybe I should implement more of a data-driven approach, where I generate the modules?
<marler8997__>
My thoughts for now is just to copy standard lib implementation, and add declarations as I need them
<marler8997__>
TheLemonMan, and guidance for me?
<marler8997__>
in that case, I think it will be best to create my own windows declaration library
<marler8997__>
great thanks for that link, I had no idea whether Zig was aiming for partial or complete declarations, sounds like it's not decided
<marler8997__>
user32 is a good example, it contains alot of const/typedefs
<marler8997__>
ok, so you're saying it should be in bits.zig?
<marler8997__>
gdi32.zig, contains PIXELFORMATDESCRIPTOR, why isn't that in bits.zig?
<marler8997__>
bad example, they are in bits.SUBLANG
<marler8997__>
for example, os\windows\sublang.zig contains alot of const declarations, why aren't they in os\bits\windows.zig?
<marler8997__>
when would you put a const/typedef in bits vs in another os module?
<marler8997__>
add "-lc"
<marler8997__>
ok here's my guess...bits.zig is a place to hold const/type declarations that are used in multiple modules for an os?
<marler8997__>
anyone know what the purpose of "bits.zig" is in general?
<marler8997__>
For example, why is there os/bits/windows.zig and os/windows/bits.zig?
<marler8997__>
This means I need to understand the std lib organization and I got some questions
<marler8997__>
I'd like to start using Zig to make Windows applications, and I'd like to pad out the standard library with the missing windows functions while I do it
2020-10-09
<marler8997_>
is Rocknest on here? I wanted to ask some clarifying questions on his proposal without littering the github comments too much
2020-10-06
<marler8997>
ah you're right
<marler8997>
I think so....
<marler8997>
that isn't typedefd
<marler8997>
including a struct definition using cImport
<pixelherodev>
marler8997: what do you mean?
<marler8997>
do we have a solution to access C struct definitions that are not typedefed from Zig?
<marler8997>
why would we want to maintain the C version manually after 1.0 instead of just updating it using the C backend?
<marler8997>
oh I see
<pixelherodev>
marler8997: nope
<marler8997>
in other words, not maintaining a C version of the compiler, but utilizing the c backend to make a C version of the compiler available
<marler8997>
oh you know what, I read through issue 6378 again...and I think I misunderstood what Andrew's proposal was. I think he's actually proposing exactly what I suggested
<marler8997>
I could be misunderstanding the requirement, but I don't see the need to manually support a C version of the zig compiler for bootstrapping if we have a C backend...?
<marler8997>
justin_smith, do you have an idea what they meant in this particular case by dependency loop?
<justin_smith>
marler8997: reading what they said, it's a dependency loop, where each stage relies on the other
<marler8997>
pixelherodev, what do you mean by "a bootstrap loop"?
<pixelherodev>
marler8997: not sure if your comment on #6378 has been addressed, but the fundamental issue (to me) with using CBE to regularly regenerate a "stage1" is that we would be trapped in a bootstrapping loop, effectively
<marler8997>
Compiler from September 28 (0.6.0+e60939bfa) works
<marler8997>
I'm linking to openssl (libcrypto.so.1.1 and libssl.so.1.1), it looks like I'm missing a "runpath" in my executable with the latest compiler
<marler8997>
having runtime loader problems with the latest zig compiler on NixOS...anyone else see something similar?
2020-09-20
<marler8997>
ikshuh, sure thing, at some point the goal will be to upstream it into the zig repo so everyone will just have it
<ikskuh>
marler8997: thanks for zigup btw :)
2020-09-19
<marler8997>
I think I gotta go to bed, 4:30 AM my time
<marler8997>
yeah you too
<pixelherodev>
marler8997: thanks for the brainfood :)
<marler8997>
lol
<marler8997>
ah...I'm right :)
<marler8997>
I thought the "a" stood for "ascii"?
<marler8997>
well sure, and each program will have it's own branch predictions
<marler8997>
it's almost as if, as processors get smarter, programs should get dumber
<marler8997>
as processors get better, the more predictable you make your code the faster it generally goes
<marler8997>
its' kinda funny
<marler8997>
I just understand that there are alot of pieces to it, and one thing I've learned is that no matter how much you theorize, you'll never know until you actually test
<marler8997>
I hope to see more data on it
<marler8997>
I make no claims that dynamic or static is better
<marler8997>
and to be clear
<marler8997>
I'm enjoying it though
<marler8997>
you remind me of myself 4 years go :)
<marler8997>
oh wow
<marler8997>
and 24 yrs old?
<marler8997>
5 years programming seriously?
<marler8997>
let me guess
<marler8997>
wait
<marler8997>
out of curiosity, how old are you and how long have you been programming seriously?
<marler8997>
still can't make the inference though, that's not the whole pictures...again, complexity
<marler8997>
that's the same rule in your inference
<marler8997>
but the system will stop
<marler8997>
If I give my application exclusive CPU access it will run faster
<marler8997>
I'll give you a counter example
<marler8997>
you can't make that inference
<marler8997>
> If individual applications are better off like this, the system is too.
<marler8997>
you still can't make that inference
<marler8997>
I understand
<marler8997>
so you can't make the inference that if one program runs faster, then an entire system would
<pixelherodev>
marler8997: but it *also* means significantly lower imem too
<marler8997>
so there's reasons why running multiple programs statically could be slower
<marler8997>
But remember, that when you compile statically, running multiple programs together means less instruction memory can be shared
<marler8997>
yes that will be good
<marler8997>
you can't look at one application and extrapolate that to the entire system
<marler8997>
to say that a system as a whole will run faster if you compile everything statically is something you would have to test
<marler8997>
not using dynamic libraries will have an affect on the system overall
<marler8997>
that still brings us back to that programs don't run in a vaccuum
<marler8997>
oh I see
<marler8997>
what?
<marler8997>
Computers and processors an kernels and hardware and electronics are too complex to be able to make large inferences like that
<marler8997>
Unless they actually took a large set of programs, compiled them statically/dynamically and tested it
<marler8997>
I don't think anyone on the planet could make a claim like that, unless they actually tested it
<marler8997>
but you can't inferences like 99% of programs are better off static from them
<marler8997>
It's an interesting data point
<marler8997>
but that doesn't follow
<marler8997>
The practial usage numbers of dyanmic libraries doesn't say anything about whether 99% of programs are better off static
<marler8997>
What data?
<marler8997>
I don't see that on this page?
<marler8997>
And where is the data that 99% of programs are better static?
<marler8997>
On what system though?
<marler8997>
oh, you're talking about the linked page?
<marler8997>
so your initial claim that 99% of them are "better off static"...are you saying that mean they startup faster?
<marler8997>
wait
<marler8997>
what?
<marler8997>
you claimed that 99% run faster
<marler8997>
that link is showing one program that performs faster statically
<marler8997>
that 99% of libraries are better off static?
<pixelherodev>
marler8997: yes.
<marler8997>
so is this based on tests/data?
<ikskuh>
marler8997: i think most functions from a libc would eventually be inlined in static linked libs
<marler8997>
oh?
<marler8997>
not necessarily though
<marler8997>
like libc
<marler8997>
A very commonly used library with very commonly used functions might pratically have better performance as a dynamic library
<marler8997>
but the statement "Statically linking improves caching" is not true in every case
<marler8997>
sure
<marler8997>
yup
<marler8997>
not if you are running multiple
<marler8997>
for one program
<marler8997>
processor caches
<marler8997>
not necessarily
<marler8997>
per use
<marler8997>
sure I'll give you that
<marler8997>
Maybe it's a 10 GB library, but most applications are using around 1GB of it
<marler8997>
well, so long as the applicaitons are using 1GB worth of the library
<marler8997>
That measn that you save 1 GB every time you link to it dynamically vs statically
<marler8997>
so lets' say, each applicaiton uses 1GB of code from the library
<marler8997>
it's the amount of code used I supposed
<marler8997>
well percentage doesn't really matter
<marler8997>
2 users of a single library, they use 100% of the library and the library is huge
<marler8997>
So take the worse possible case against your statement
<marler8997>
"If *most libraries* are used by few applications, link those specific libraries statically - since they won't be shared anyways
<marler8997>
I think you're making generalations and inferences here that just don't follow
<marler8997>
about static linking with optimization?
<marler8997>
Or I should say, 1 library and 2 users of it
<marler8997>
It only takes 3 libraries to break that assumption
<marler8997>
however, I'm not sure about your second assumption
<pixelherodev>
marler8997: or you missed some of my statements ;)
<marler8997>
ok so your statement was incomplete....I see
<marler8997>
damn how did you type that so fast?
<marler8997>
that's a copy/paste of what you said
<marler8997>
You literally said this: And if most things are better off static, then that means that *everything is*
<pixelherodev>
marler8997: but that was never the inference.
<pixelherodev>
marler8997: I think that actually creates a perfect hybrid. If *most libraries* are used by few applications, link those specific libraries statically - since they won't be shared anyways, and that allows for inlining. For something like libc, which is used by nearly *everything*, link it dynamically - since that allows for sharing.
<marler8997>
This is not a valid inference: If most thare are better of X, then that means everthing is better off X
<marler8997>
please don't start a new religion :)
<marler8997>
that's like saying, if people are better off being in heterosexual relationships, then that means everyone should be
<marler8997>
that makes no sense :)
<marler8997>
why?
<marler8997>
If somthing is better off static, then make it static, if something is better of dynamic, make it dynamic
<pixelherodev>
marler8997: that's my point!
<marler8997>
Basica
<marler8997>
Then it wouldnt' fall into the category of "better off dynamic"
<marler8997>
yes
<marler8997>
If an application is better off dynamic, why wouldn't you make it dynamic?
<marler8997>
You're saying that some should be static even if they are better off dynamic?
<marler8997>
how does that follow
<marler8997>
why does that mean everything should be static?
<marler8997>
if some are better off static, then they should be static
<marler8997>
how does that follow?
<marler8997>
there was an article I saw recently about the importance of having a binary ABI/API, I didn't read it I"ll have to see if I can find it
<marler8997>
ok gotcha
<marler8997>
Ok, so you're just talking about compiling dynamically vs statically in general, which to choose
<marler8997>
an applciation can use any mechanism regardless of what the system is doing
<marler8997>
what does a systems' primary mechanism have to do with an application's mechanim?
<marler8997>
having a dynamic system...and compiling statically are not mutually exclusive
<marler8997>
I don't know what that has to do with your original statement
<marler8997>
yes I understand
<pixelherodev>
marler8997: when building a Zig executable with, say, Hello World
<marler8997>
I can't follow your logic at all
<marler8997>
I'm very confused by what you're saying
<marler8997>
then compile statically
<marler8997>
why is it impossible to inline on a *primarily* dynamic system?
<marler8997>
what's the expense?
<marler8997>
why is it an expense to have both?
<pixelherodev>
marler8997: for using a fully static system?
<marler8997>
what is the expense?
<pixelherodev>
marler8997: That's because those are, for all intents and purposes, *edge cases*.
<marler8997>
but you seem to be ignoring the other cases
<marler8997>
sure with those numbers it can makes sense to statically compile
<marler8997>
they're not the same bits?
<earnestly>
marler8997: Content Addressable Storage solves that issue
<pixelherodev>
marler8997: because they're not the same bits.
<marler8997>
I'm not sure why you would want to store the same bits over and over again on your computer, when you can just store it once and share it
<marler8997>
for small things, it's fine
<marler8997>
If you want to be able to use big dependencies, then it becomse unreasonable to compile statically
<marler8997>
libraries that are gigabytes in size
<marler8997>
imagine you want to use firefox as a library or webkit
<marler8997>
it allows you to share bits
<marler8997>
even static binaries don't solve the problem
<marler8997>
any of these things can break your application
<marler8997>
atoms, time
<marler8997>
kernel
<marler8997>
hardware
<marler8997>
you can mitigate it to a high degree though
<marler8997>
this isn't one of them
<marler8997>
There are lots of problems that are solvable
<marler8997>
it's an unsolvable problem
<marler8997>
any solution you come up with...wills till break
<marler8997>
still not a solution
<marler8997>
even if you version every symbol
<marler8997>
that's what Nix does
<marler8997>
compatibility isn't just to do with ABI
<marler8997>
that still doesn't solve the issues
<marler8997>
in fact, even with hashed dependnecies, you still don't solve the problem
<marler8997>
it's literally impossible
<marler8997>
not sure what you're asking
<marler8997>
why can a change break an application?
<marler8997>
why what?
<marler8997>
any change within the library could potentially break any user of it
<pixelherodev>
marler8997: that's the question I'm asking.
<marler8997>
how do you prevent a library update from breaking an application?
<marler8997>
why?
<pixelherodev>
marler8997: but the library updates shouldn't cause those to break.
<marler8997>
there are old programs
<marler8997>
but it's not even the culture
<marler8997>
It gives me the best of both worlds, a dynamic executable that behaves like a static executable
<marler8997>
Nix allows me to do that
<marler8997>
When I deploy an application, I want all my dependnecies to be as fully-specified and as possible
<marler8997>
it's a good read actually, easy and understandable
<marler8997>
you should read the phd thesis
<marler8997>
it's just a feature that you have the option to use
<marler8997>
nix doesn't force you to use them, if you have other solutions, you can still use all the other features of nix
<marler8997>
then don't use them
<pixelherodev>
marler8997: IMO, exact dependencies are a *problem*, not a *solution*.
<marler8997>
essentially reducing your binary to the functional equivalent of a static executable
<marler8997>
it's just that nix also let's you have cryptographically hashed dependencies that you know won't change
<marler8997>
you can still do that with tnix
<marler8997>
and a solution like that is orthogonal to what nix is doing
<marler8997>
you now have to test every version with every other version
<marler8997>
That would result in an exponential explosion of cases to test
<marler8997>
you're saying that all libraries should be 100% backwards compatible?
<marler8997>
if it isn't kept up-to-date every time something changes, then we shouldn't suppor tit
<marler8997>
You're saying that we shouldn't use old software
<marler8997>
you need to solve the problem
<marler8997>
if you want your old software to still work
<marler8997>
some apps will update, some won't
<marler8997>
Libraries get updated
<marler8997>
it's an issue that will always occur
<marler8997>
that's not a solvable problem
<marler8997>
Sure, but having a solution doesn't mean it's hiding a problem
<marler8997>
It's a solution to that problem
<marler8997>
That's what nix solves
<marler8997>
How do you handle that issue?
<marler8997>
When libraries change, not all apps update, and some apps require updates
<marler8997>
Which is?
<marler8997>
What's the problem?
<marler8997>
Yes
<marler8997>
Nix doesn't require multiple versions of things to be installed
<marler8997>
You still require disparate versions to be installed? What does that mean?
<marler8997>
I'm not understanding...
<marler8997>
what does that mean? "still incompatible"?
<pixelherodev>
marler8997: fundamentally, the SOs on a Nix system are *still incompatible*.
<marler8997>
what issues doesn't nix solve though...I'm still wanting to understand that point
<marler8997>
nixos is a distribution
<marler8997>
nix is a package manager that can run on most distributions, even mac and bsd
<pixelherodev>
marler8997: fundamentally, it's that nix *isn't a solution*
<marler8997>
so what issues doesn't nix solve?
<marler8997>
that's the list I wrote down after going through the creator's PHD thesis
<marler8997>
* The system depends on non-portable techniques.
<marler8997>
* The component framework is narrowly restricted to components written in a specific programming language or framework.
<marler8997>
* Component composition is manual.
<marler8997>
* It is difficult to adapt components.
<marler8997>
* The system supports either source deployment or binary deployment, but not both; or it supports both but in a non-unified way.
<marler8997>
* There is no link between binaries and the sources and build processes that built them.
<marler8997>
* Deployment actions can only be performed by administrators, not by unprivileged users.
<marler8997>
* Applications must be monolithic, i.e., they must statically contain all their dependencies.
<marler8997>
* Upgrade actions are not atomic.
<marler8997>
* It is not possible to roll back to previous configurations.
<marler8997>
* Components can interfere with each other.
<marler8997>
* It is not possible to deploy multiple versions or variants of a component side-by-side.
<marler8997>
* Dependency specifications are inexact (e.g., nominal).