<andrewrk>
if you go to details on the azure one you'll see linux is still building
ur5us has joined #zig
<andrewrk>
or being tested rather
<marler8997>
ok cool, so after CI is done it automatically deploys
<andrewrk>
yes, only if all checks are green
<andrewrk>
right now we need to update www.ziglang.org repo as well, which has its own process that is now failing thanks to your latest merged PR :)
<marler8997>
andrewrk perfect!
<marler8997>
let the propogation of {s} begin
<andrewrk>
indeed :)
nvmd has quit [Quit: Later nerds.]
<ifreund>
that will make updating my stuff from 0.7.1 to 0.8 much more plesant :)
<andrewrk>
yeah it was a mistake to do the former change without the latter, IMO, sorry about that.
<ifreund>
no worries here, I haven't hit any major enough issue on 0.7.1 yet to consider moving river and its deps back to master zig
<andrewrk>
yeah hopefully river can stay on releases from now on :)
<fengb>
How do I get the obj file path from build.zig?
ur5us_ has joined #zig
ur5us has quit [Ping timeout: 264 seconds]
<marler8997>
andrewrk, hate to say "I told you so"...not really though :)
<andrewrk>
fengb, the path is not determined until the build starts happening (after the script finishes running). if you need it in other commands, there are special case ways to reference it, such as RunStep.addArtifactArg. otherwise you can use setOutputDir to force the output path to be something you know ahead of time
M-ou-se has quit [Ping timeout: 272 seconds]
M-ou-se has joined #zig
<andrewrk>
fengb, if you use setOutputDir how this actually works is that it additionally copies the files from zig-cache/ to the output dir that you set
<ifreund>
andrewrk: I'm off for the night so don't worry about conflicts for 792
<ifreund>
7920, will see what you've left me in the morning
<andrewrk>
ifreund, roger that. thanks!
a_chou has joined #zig
<fengb>
Ah cool, setOutputDir worked. Thanks!
a_chou has quit [Ping timeout: 246 seconds]
a_chou has joined #zig
jukan has joined #zig
jukan_ has quit [Ping timeout: 256 seconds]
xentec has quit [Quit: memento mori]
xentec has joined #zig
cole-h has quit [Ping timeout: 272 seconds]
leon-p has quit [Read error: Connection reset by peer]
leon-p has joined #zig
<daurnimator>
marler8997: looks great :)
a_chou has quit [Remote host closed the connection]
<daurnimator>
marler8997: I would do it only if *every* enum member has that prefix.
a_chou has joined #zig
<daurnimator>
marler8997: I remember windows have a couple of weird ones where there were enums mashed together weirdly
<marler8997>
what kind of weird?
<daurnimator>
like enum `FOO` has members FOO_A, FOO_B, FOO_C, BAR_D, FOO_E
<marler8997>
eww
<marler8997>
well luckily I didn't have any conflicts yet
<daurnimator>
I don't think you'll have conflicts, but my point was to only strip if all enum members have the same prefix
<marler8997>
right, I'm not sure what I like better yet
<marler8997>
like, imagine they accidently included a bad value, now all the names are messed up
<marler8997>
it's always easy to add corner case handling as well
<daurnimator>
marler8997: ha. yeah they've done that too... see e.g. WinsockError in `lib/std/os/windows/ws2_32.zig`
<daurnimator>
at first the prefix was WSA_, then they apparently dropped the underscore
gazler_ has joined #zig
gazler__ has quit [Read error: Connection reset by peer]
<marler8997>
yeah, they got some geniuses over there are Microsoft
<daurnimator>
then some decades later they brought the underscore back again
<marler8997>
interesting I don't see the error codes in the metadata
<marler8997>
the win32metadata project is still pretty new, they'll probably get added in later
kchambers has quit [Quit: WeeChat 3.0.1]
a_chou has quit [Ping timeout: 240 seconds]
ur5us_ has quit [Ping timeout: 264 seconds]
ur5us has joined #zig
earnestly has quit [Ping timeout: 240 seconds]
ur5us_ has joined #zig
osa1 has quit [Ping timeout: 256 seconds]
ur5us has quit [Ping timeout: 264 seconds]
<v0idify>
ugh i wish we had some kind of gui on zig
<v0idify>
like fyne.io
<tdeo>
marler8997: from what i can tell in zigwin32, you use ?*opaque{} where the bindings specify an unknown type pointer, have you considered using ?*c_void instead? from what i understand it's impossible to pass a pointer to a function taking an anonymous ?*opaque{} without some weird typeinfo hackery
<marler8997>
tdeo yeah I actually already ran into that and changed it to ?*c_void for things like function parameters
<marler8997>
but maybe there are some cases still using ?*opaque{}? Can you point me to the one you're seeing?
<tdeo>
marler8997: there are a lot, i'm looking in system_services.zig
<marler8997>
I see it on types but I don't see any as function parmaeters
<ismaell>
DarkUranium: not having one at all is a better alternative than having a bad one
<ifreund>
agreed
<ikskuh>
ismaell: me looking at C/C++, i don't really agree. it's a horrible mess
<ismaell>
DarkUranium: APIs don't match either
<DarkUranium>
Debian and such, for example, might have an ancient version of some package you require, too ancient to be useful.
<ikskuh>
i started just vendoring all libraries and donÄ't have any proper upgrade path at all
<ikskuh>
because it's the way of the least resistance
<ismaell>
DarkUranium: you can't rely on anything just working, you have to test, that's the first thing chustom package managers fail at
<DarkUranium>
ismaell, that's a naive POV.
<ifreund>
ikskuh: if you stick to unix like systems and rely on the system package manager, C is fine
<ikskuh>
ifreund: it's not :(
<ikskuh>
sadly
<DarkUranium>
ismaell, your software, if successful, will be used in hundreds of different OSes and configurations. There is literally no way for you to conclusively test everything.
<DarkUranium>
Best you can hope for is for the dependencies to be available. A language-specific package manager helps here.
<DarkUranium>
ifreund, yeah, ikskuh is right, it's really not.
<ismaell>
yeah, C makes it easy to shoot your own foot
<DarkUranium>
Software A needs 2.1, software B needs 2.2. OS package managers don't typically allow installing both (except for a handful of packages where maintainers foresaw problems)
<ikskuh>
that's not the problem ;)
<ismaell>
the problem is you can't rely on versions
<ismaell>
you need to test the ABI
<DarkUranium>
ismaell, then ... what, exactly?
<ikskuh>
it's the only thoing you need to rely on
<ikskuh>
if you ever tried shipping a program from source for both arch and debian, you see horrors
<DarkUranium>
A compatible ABI does not imply a compatible library.
<DarkUranium>
Behaviour can change without ABI changes.
<ismaell>
behavior is part of the ABI
<ismaell>
semantics must be encoded too
<ismaell>
we don't have a thing yet, but we should
<ikskuh>
zig doesn't have an ABI ;)
<DarkUranium>
The only way to encode all semantics is to store them all before you load the library.
<ikskuh>
which will kinda solve all abi-related problems :D
<DarkUranium>
... at which point, you don't need the library at runtime. It's called static linking.
<DarkUranium>
You still need it at compile-time, though. So this doesn't help OS-wise (static linking helps with distribution, but not development)
<DarkUranium>
(also, behaviour is not part of an ABI)
<ikskuh>
ismaell: things where zig is different: you cannot distribute binary libraries/packages
<ismaell>
DarkUranium: behaviour isn't implementation, and it doesn't need to be perfect, you just need some mechanism to avoid the programmer to do stupid things like name a function the same if it does a different thing
<ikskuh>
except for C abi stuff (which is pretty well defined)
<DarkUranium>
ismaell, yeah, you won't win on that one.
<DarkUranium>
In a perfect world, sure. But in *our* world, maintainers will change semantics without a function rename.
<ikskuh>
ismaell: renaming functions will break the source, except they have exactly the same API
<DarkUranium>
ikskuh, eh? A rename is a change of API (also ABI, for that matter)
<ismaell>
ikskuh: no, they won't, that's the point, different name different ABI
<DarkUranium>
ismaell, you're missing my point.
<ismaell>
and you can support more than one
<ismaell>
like GLIBC's versioned mess, it works
<DarkUranium>
ismaell, you need to depend on some shitty lib where behavior changed between 2.1 and 2.2. Who knows why, it could be a good reason. The "why" is irrelevant.
<ikskuh>
it still only affects external dependencies
<ikskuh>
which aren't build with zig
<DarkUranium>
You *need* 2.2. Another piece of software you have installed *needs* 2.1. Now what?
<pixelherodev>
ismaell: most of the time, you *want* behavior to change when the library changes it.
<pixelherodev>
See: security fixes.
<ismaell>
DarkUranium: but the problem arises when things compile but fail at runtime, if they fail to build that's fine
<DarkUranium>
ismaell, this can be either one. You're missing the point.
<DarkUranium>
ismaell, the point is: Most OSes won't provide you with both versions.
<ismaell>
pixelherodev: true, there's corner cases, but that's probably on a grey area most of the time
<DarkUranium>
With a very few exceptions (libpython, for example)
<pixelherodev>
ismaell: not really?
<pixelherodev>
90% of the time, you want the new ABI
<pixelherodev>
honestly, either just statically link or ship the source
<pixelherodev>
Both options are good enough
<ismaell>
pixelherodev: behavior that was explicitly promised can't really change
<DarkUranium>
ismaell, the ultimate point is: you cannot rely on the OS's package management. It'll be different OS to OS, and your dependencies might not exist on it.
<ismaell>
DarkUranium: that's better than a package manager that simply doesn't work at all and which upstream has no incentive to support
<DarkUranium>
If they do exist, it might be the wrong version.
<ismaell>
(your OS)
<ismaell>
DarkUranium: wrong version results in build failure, so that's equivalent to non-existence
<DarkUranium>
That's a patently false assumption.
<ismaell>
you need to ensure that
<DarkUranium>
How do *I* ensure that?
<pixelherodev>
This still breaks security.
<DarkUranium>
(other than with version checks)
<pixelherodev>
ismaell: your entire *goal* is to ensure that people either stick with old libraries or wait for package authors to opt-in to new versions.
<ismaell>
DarkUranium: you can't test versions, you can't rely on that because the OS/user might have patched your depedency
<pixelherodev>
That goal is *entirely* antithetical to any semblance of stability or security
<DarkUranium>
ismaell, so what *do* you use?
<ismaell>
or they might be providing an alterantive implementation
<ismaell>
alternative implementations must be permissible
<DarkUranium>
What if the alternative implementation is incompatible?
<ismaell>
pixelherodev: why?
<pixelherodev>
updates are typically bug or security fixes.
<ismaell>
DarkUranium: then it's not "alternative" it's something else completely
<DarkUranium>
ismaell, you speak of testing. What would you rather use:
<pixelherodev>
If they can't be deliveered in a timely manner, that's a fatal flaw of your package manager
<DarkUranium>
ismaell: A dependency that a software package was well-tested with, and thoroughly ... or your OS's mismatched package?
<DarkUranium>
ismaell, alternative implementations are just about never 100% compatible.
<ismaell>
think autoconf, why do they test? because you can't possibly encode all possible versions that might work across the entirety of options available
<DarkUranium>
They *will* diverge. Intentionally or not.
<ikskuh>
ismaell: when you can compile zig for your os, the official package manager will also compile ;)
<pixelherodev>
honestly, the problems your discussing can be solved by just finding 1(one) person who uses a given OS to keep your package up to date.
<DarkUranium>
ismaell, generally speaking, two different libraries will have different behavior even if they implement the same spec.
<pixelherodev>
"OSes don't have enough manpower, so there's packaging problems" is a social problem, not a technical one
<DarkUranium>
pixelherodev, you mean the dependency? Have them be a package maintainer?
<pixelherodev>
The technical aspects are symtomatic
<pixelherodev>
symptomatic*
<pixelherodev>
DarkUranium: in large part? Yes.
<DarkUranium>
pixelherodev, you're making a number of assumptions there:
<ismaell>
DarkUranium: yes, but they shouldn't diverge on the defined ABI, as long as it's undefinded you can't rely on it
<DarkUranium>
1) That the OS has a package manager.
<pixelherodev>
If it doesn't then the point is moot.
<ismaell>
also, it would be possible to provide meta-data that compiles to the OS package manager's spec
<DarkUranium>
2) That the OS would even be interested in having your package in it (<-- this is a big one).
<DarkUranium>
3) That all the dependencies are, and stay, compatible.
<pixelherodev>
see e.g. oasis + nix
<DarkUranium>
pixelherodev, see #2 & #3.
<DarkUranium>
ismaell, so?
<DarkUranium>
ismaell, *there are other compatibility issues than just ABI*.
<DarkUranium>
How many times do I have to reiterate that point?
<ismaell>
DarkUranium: right, but then you make your whole ecosystem unusable for a lot of corner cases
<DarkUranium>
pixelherodev, also, good luck finding anyone for a less popular OS.
<pixelherodev>
DarkUranium: then good luck finding someone using it.
<DarkUranium>
pixelherodev, that's an absurdly shitty stance to have :|
<pixelherodev>
but consistent!
<ismaell>
the problem is when the compiler starts to rely on the packaged stuff
<pixelherodev>
also, I disagree
<ismaell>
if that is not done, it isn't an issue
<pixelherodev>
DarkUranium: I meant that users of unpopular systems should understand that if they want more things packaged, *they* have to step up
<pixelherodev>
Not "You're using an unpopular system so screw you," but "you're using a system without many other people, so *you* do the work since noone else will"
<DarkUranium>
ismaell, I mean, there's a reason versioning is a thing. The core issue, for the umpteenth time, is that OS packages: 1) are untested with your software (the particular version); 2) might be incompatible (see #1); 3) if incompatible (see #2), will typically not have compatible versions installable (be it earlier or later), because only 1 version is provided
<DarkUranium>
pixelherodev, okay. But suppose I'm a user and I want to use something on my OS.
<DarkUranium>
With a lang-specific package manager, I can install the deps easily, and get running in minutes (+ compilation time, I guess).
<pixelherodev>
and the OS has noone else working on it? Package it yourself
<DarkUranium>
With what you're saying, I have to run through hoops to get it done.
<pixelherodev>
Or, if all the people contributing to the language package managers contributed to their own OSes instead, it wouldn't be an issue.
<DarkUranium>
Which can be mountains of bureucracy depending on OS (and all ending with "no, the package is too new/too unknown/too unstable/wrong license/...")
<pixelherodev>
What if something isn't in the language repos?
<pixelherodev>
You package it.
<pixelherodev>
All that language-specific package managers do is add a level of indirection
<pixelherodev>
and a very poort one
<pixelherodev>
poor*
<DarkUranium>
The difference is that the language repo, you package it once. And as someone using the language, you know it'll be available on a myriad of OSes.
<pixelherodev>
and, again, be untested on most.
<pixelherodev>
That's *worse*.
<pixelherodev>
the point of os repos is that packages are *tested*
Kiori has joined #zig
<DarkUranium>
pixelherodev, but your package isn't tested with the OS package.
<pixelherodev>
If I install something from Debian, I know it's been tested against its dependenies *on Debian*.
<DarkUranium>
pixelherodev, and what if version does mismatch? WHAT DO YOU DO?
<DarkUranium>
You still haven't answered that.
<pixelherodev>
Package it myself
<DarkUranium>
Okay. OS says "fuck you, we won't add another version just for you".
<DarkUranium>
Now what?
<pixelherodev>
Use a third party repo
<pixelherodev>
Like literally every reasonable OS supports
<DarkUranium>
Okay, now you need to add a third-party repo for every single OS you want to support.
<DarkUranium>
You need to add *and maintain* that repo.
<pixelherodev>
No, only those refusing to suppport it
<DarkUranium>
For all live versions of the OS.
<ismaell>
DarkUranium: we can't fix the divergence, but at least make it work at ABI level instead, so only the subset you actually use matters, instead of relying on version checks that are most likely not carefully tailored to the requirements but just bumped for whatever is installed on the developer's machine
<pixelherodev>
and in my experience, if an OS rejects somethingt, there's good reason
<DarkUranium>
ismaell, ABI compat != drop-in compat.
<ismaell>
DarkUranium: if you have enough information, it is
<pixelherodev>
no
<pixelherodev>
because then it's not the ABI.
<ismaell>
pixelherodev: important behavior should be
<DarkUranium>
Also, with the amount of information you're implying, you're basically talking about in-tree dependencies.
<pixelherodev>
That's meaningless.
<DarkUranium>
ismaell, you keep using that word. I do not think it means what you think it means.
<pixelherodev>
The only thing that "should" be part of an application's *binary interface* is the interface the *binary uses* to communicate with libraries and subroutines.
<DarkUranium>
And also, yes.
<pixelherodev>
Hence, ABI.
<DarkUranium>
Also literally impossible. Even if you define an "ABI+".
<DarkUranium>
It's only possible if you can prove no bugs.
<DarkUranium>
You cannot prove no bugs (c.f. halting problem). Thus, impossible.
<ismaell>
run-time behavior is inherently part of the ABI
<DarkUranium>
Remember, dependencies could be incompatible due to bugs.
<ismaell>
it doesn't need to be perfect
<pixelherodev>
No, it's not
<DarkUranium>
ismaell, no it's not.
<pixelherodev>
Behavior == semantics.
<ismaell>
yes...
<ismaell>
so?
<pixelherodev>
If behavior was encoded in the ABI, you wouldn't need machine code.
<DarkUranium>
ismaell, if you're replacing a package manager, it *must* be. Because the alternative is horrendeous.
<DarkUranium>
<pixelherodev> If behavior was encoded in the ABI, you wouldn't need machine code.
<DarkUranium>
^ hence me saying: DarkUranium> Also, with the amount of information you're implying, you're basically talking about in-tree dependencies.
<ismaell>
behavior is what you intend to do, not how
<ismaell>
so no, it's not at all machine code
<pixelherodev>
No, behavior is what you *do*
<pixelherodev>
INtention is utterly irrelevant.
<DarkUranium>
A computer is not magical, ismaell, it cannot derive intention.
<ismaell>
yes, "what", not "how"
<ismaell>
also, it doesn't need to be complete
<pixelherodev>
machine code is what you do.
<DarkUranium>
(there's entire fields dedicated to trying to make computers do exactly that; but it's both an open field *and* generally impossible --- even humans often struggle with this)
<ismaell>
and bugs don't matter as long as it works
<pixelherodev>
ABI is just how you get to doing it
<pixelherodev>
Bugs matter.
<pixelherodev>
I've literally never run into a bug with an OS package manger on any OS.
<pixelherodev>
Not even Debian's, to my surprise
<DarkUranium>
Bugs *will* happen. They'll happen in the manner where behaviour is affected in making-things-incompatible ways.
<DarkUranium>
Sometimes, the fix will break compatibility yet again.
<pixelherodev>
apt, apk, portage, pacman, etc have *never* given me a single bug
<ismaell>
separation of concerns, bugs don't matter to building stuff, bugs matter for integrity, for the OS, for the user, generally not for building unless they actually affect the build result
<pixelherodev>
If your solution is buggy, nobody will use it
<DarkUranium>
pixelherodev, er, that's very false.
<pixelherodev>
also, again, even if what you want is possible, it's *bad*
<DarkUranium>
There's SO MANY horrendeously buggy programs used in various industries.
<pixelherodev>
DarkUranium: true, people are idiots^Wstimuli reaction devices, I keep forgetting that
<ismaell>
you can't avoid bugs, and the OS will try it's best to provide up to date libraries
<ismaell>
and upstream can help by providing metadata in a neutral format
<pixelherodev>
Am I the only one who thinks OS package managers are actually good enough that there's zero need for a replacement?
<ismaell>
but a language-specific package manager is going to do more harm than good
<pixelherodev>
This might be my first unpopular positive opinion shared here :P
<pixelherodev>
DarkUranium: I'd contend that your issues with OS repos are correct
<ismaell>
pixelherodev: haha, I think it's not that simple, but yes, overall I agree with you
<pixelherodev>
So let me ask you something
<pixelherodev>
You write a new package manager to solve it, and give it new repos!
<pixelherodev>
Okay, sounds reasonable
<pixelherodev>
Why on earth would you limit it by language?!
<ismaell>
pixelherodev: +1, and also, why not help fix existing ones instead?
Kiori has quit [Read error: Connection reset by peer]
<DarkUranium>
pixelherodev, that's a fair point. It's usually about control (a weaker argument, but).
<pixelherodev>
Hermes is the only Linux package manager I actually intend to be running long term
<DarkUranium>
pixelherodev, basically, it's for the same reason as to why you make your own syntax instead of inventing something else. Etc.
<pixelherodev>
I'm setting up Alpine in a VM, then using it to set up Oasis in a VM, then nuking Alpine, setting up Hermes, and that Oasis image will be the final Linux disatro I ever use :)
<DarkUranium>
pixelherodev, also, the language is in some cases tied to the package manager (there are both advantages and disadvantages to this).
<pixelherodev>
I mean, to be fair, if npm, pip, and cargo were one thing, it'd probably be so horrendously stupid it would implode into a black hole and end human existence
<pixelherodev>
So maybe it's a good thing
<DarkUranium>
pixelherodev, it's also simpler when it's single-language.
<pixelherodev>
Then that's a bug with the languages.
<DarkUranium>
("do one thing and do it well" applies here, to some extent)
<DarkUranium>
No.
<DarkUranium>
What I mean is, two arbitrarily-chosen languages will, in general, not be able to interoperate.
<DarkUranium>
And when they can, they will not have ready-made or automatic bindings available.
<pixelherodev>
So? Many libraries cannot be used as dependencies of others.
<DarkUranium>
Package managers aren't typically per-language, they're really per-ABI.
<pixelherodev>
There's a very simple solution to that used in OS package managers.
wilsonk_ has quit [Ping timeout: 272 seconds]
<pixelherodev>
*Not listing them as deps*.
<DarkUranium>
pixelherodev, well, here's the thing.
<pixelherodev>
Technical solutions are not needed for human problems.
<pixelherodev>
Only for technical problems.
<DarkUranium>
Suppose I'm writing a piece of software and I need a JSON parser.
<pixelherodev>
Then you pick one you can use.
<pixelherodev>
That's pretty obvious.
<pixelherodev>
`bespoke search json --tags=c`
<DarkUranium>
Sure. But you've just changed the selectivity of the index, so to speak (in DB terms).
<pixelherodev>
not seeing the issue
<DarkUranium>
That's 8 characters to both remember to type and actually type, for every. Single. Operation.
<DarkUranium>
Here's the issue.
<pixelherodev>
It's not eight characters lol
<DarkUranium>
I don't give a fuck about Rust libraries if I need a Python one. And vice-versa.
<pixelherodev>
It's one flag and the language you're using.
<DarkUranium>
So *every single invocation* would use that.
<DarkUranium>
But granted, such a pkg manager would be useful.
<DarkUranium>
I'm just saying there are good reasons to specialize, too.
<pixelherodev>
alias definitelyacolypkgman='bespoke --tags=c`
<DarkUranium>
No need to prefix everything with coyote-, for example.
<DarkUranium>
(or python-/py- or c- or ...)
<pixelherodev>
alias `definitelyacoyonlypkgman='bespoke --tags=coyote`
<pixelherodev>
You could use UUIDs and metadata
<pixelherodev>
instead of traditional categories
<DarkUranium>
I suppose.
<DarkUranium>
Categories will also be different from language to language.
<pixelherodev>
`install json` "There are three packages available by that name. Do you want C, Java, or Rust?"`
<DarkUranium>
For example, C, Rust, and Python would have your generic collection (graphics, net, .......)
<pixelherodev>
UUIDs + metadata would still work to replace that easily
<DarkUranium>
R will instead have fine-grained categories relating to statistics.
<pixelherodev>
The user doesn't care about the UUID and will never see it
<DarkUranium>
But the user *will* see the categories.
<pixelherodev>
Tags can be entirely arbitrary, and the package manager would just show where they diverge, for instance
<pixelherodev>
Sure
<pixelherodev>
but they can filter them
<DarkUranium>
And if you try to list all categories in such a system, you'll have literal thousands.
<pixelherodev>
`c.foo`
<pixelherodev>
`rust.bar`
<pixelherodev>
the package manager hides the first part
<DarkUranium>
Right.
<pixelherodev>
This is all fully solvable
<pixelherodev>
Trivial? NO
<pixelherodev>
No*
<pixelherodev>
Both feasible and reasonable? Yes
<DarkUranium>
What if you need something the package manager doesn't provide?
<pixelherodev>
Better than a language-specific package manager in jusst about every possible way? Yes
<pixelherodev>
What if you need something not in pip?
<pixelherodev>
Not in npm?
<DarkUranium>
I don't mean a software package.
<pixelherodev>
You *add it*
<DarkUranium>
I mean a feature of the package manager *itself*.
<pixelherodev>
See above.
<DarkUranium>
100% false equivalence.
<pixelherodev>
You're never going to have everything for everyone.
<pixelherodev>
There will always be something people don't want
<pixelherodev>
and things they do
<pixelherodev>
Make it a library
<DarkUranium>
If Python needs something pip doesn't provide, then Python can have it added to pip.
<DarkUranium>
This is NOT true with a generic one.
<DarkUranium>
"What, you need this feature that'll affect our entire codebase for your small toy-looking language? No."
<pixelherodev>
Sure, but languages should never need pkgmanager specific features
<DarkUranium>
That's not true at all. I can easily think of 2 languages that would benefit.
<pixelherodev>
Examples?
<DarkUranium>
One is a real one: R. Integrating a package manager can seriously ease machine learning and such. Could even be extra clever and pull new algorithms fastish.
<DarkUranium>
The other is hypothetical: A provable programming language, where dependencies are found by their properties (e.g. "I need a set with O(log n) insertion and O(1) lookup").
<DarkUranium>
Can go further with IDE integration (think pulling various samples for a graphics-programming-oriented language).
<DarkUranium>
(or GPU kernels)
<DarkUranium>
The core issue of generic software is that innovation is harder with it. Innovation is not always good (not all ideas are good), but it's nevertheless important.
<DarkUranium>
This holds for protocols (it's more limiting to extend than to make your own), libraries (ditto), etc. Package managers are no exception.
<DarkUranium>
This is not necessarily a major downside, mind you. It depends.
<DarkUranium>
But it *is* a downside.
<pixelherodev>
I disagree - I consider that a feature :P
<pixelherodev>
I don't *want* people able to toss in literally any of the features you mentioned into a package manager
<DarkUranium>
For example, maybe I want my package manager to have builtin support for software licenses, so that it can generate a that blob of copyright text for me *and* tell me if I can safely do $X.
<pixelherodev>
If you want them, you can build them *over* it
<DarkUranium>
And how is this different from them just making their own package manager?
<DarkUranium>
It's an incompatible piece of software that lives in its own walled garden.
<pixelherodev>
They don't need to implement dependency resolution ;P
<pixelherodev>
or build scripts
<DarkUranium>
Well, now you're no longer talking about a generic, cross-language, package manager.
<DarkUranium>
But rather a package manager library.
<DarkUranium>
Which, BTW, is something I've been wanting to make.
<pixelherodev>
but more importantly, they're not trying to get their awful ideas into real world programs
<DarkUranium>
Not all ideas are awful.
<pixelherodev>
Agree to disagree.
<DarkUranium>
Really?
<pixelherodev>
My idea that all ideas are awful? Awful.
<DarkUranium>
lol
<pixelherodev>
Your idea that there are good ideas? Awful.
<pixelherodev>
:P
<DarkUranium>
But seriously. It's sometimes important to throw things onto a wall, and see what sticks.
<DarkUranium>
It's how we got away from CVS for revision management.
<DarkUranium>
git ... leaves something to be desired. But I'll take it anyday over CVS or even SVN.
<DarkUranium>
Zig & Coyote both are this. They're trying something new.
<DarkUranium>
(every new programming language is, by definition)
<pixelherodev>
git is absolutely perfect.
<DarkUranium>
Ha.
<pixelherodev>
The official client, thoguh? hahahaahhaa no.
<DarkUranium>
Actually, even git itself has a problem --- huge repos.
<pixelherodev>
With git9, there is literally no feature I miss and nothing I dislike about git itself
<DarkUranium>
It slows down to a CRAAAAAAAAAWL.
<pixelherodev>
--shallow
<pixelherodev>
.
<pixelherodev>
:p
<DarkUranium>
I need to check that out. git9, I mean.
ifreund has quit [Ping timeout: 246 seconds]
<DarkUranium>
Nah, the issue is that pushing will stop then.
<pixelherodev>
If you're not running plan9, it'll be useless to you ;P
<DarkUranium>
Well, plan9 itself is an example, actually. Lots of innovation.
<DarkUranium>
Well, more like iteration for the most part.
<DarkUranium>
But also some innovation.
<DarkUranium>
pixelherodev, my point is, a package manager, just like any big piece of software, is a framework.
<pixelherodev>
Sure, and as I've mentioned elsewhere, one of the key reasons I like p9 is that people *haven't* thrown a lot of, uh, "modern" ideas at it.
<DarkUranium>
Frameworks are *great* if what you need to do fits their assumptions. But they very quickly get absolutely horrendous if it doesn't.
<pixelherodev>
That's why I don't use one ;)
<pixelherodev>
Half-kidding - I'm actually working on one for 9
<DarkUranium>
But such a generic package manager *is* a framework. That's my point.
<pixelherodev>
But all it does is find a repo you point it at, figure out deps, and invoke the mkfile
<DarkUranium>
What I'm getting at is, there are reasons, good ones, to roll a custom one --- even in the presence of a generic one.
<pixelherodev>
Package managers are only frameworks because people toss *more* on them
<pixelherodev>
If all you do is "clone, resolve deps, invoke makefile - which can invoke language-specific stuff if needed"
<DarkUranium>
I'll likely do this for Coyote, because I need something lightweight (Nix & such are huge), and portable to more OSes than those two will allow.
<pixelherodev>
Congrats, you've solved just about every problem real people have
<DarkUranium>
pixelherodev, but what about versioning and such?
<pixelherodev>
Hermes?
<pixelherodev>
DarkUranium: git.
<DarkUranium>
Package managers have to figure that out, too.
<DarkUranium>
No, of packages.
<pixelherodev>
This is for 9
<DarkUranium>
Talking generally.
<pixelherodev>
That's not generally an issue we face ;)
<pixelherodev>
"Write better software."
ifreund has joined #zig
<pixelherodev>
Literally, you mentioned earlier that it's an issue because people will make changes without bumping version properly
<DarkUranium>
My point is, they have to start assuming things about versioning & dependency compatibility (a provable language might have completely different constraints than, say, C). So now we're moving firmly towards a framework.
<DarkUranium>
Yes.
<pixelherodev>
I literally just use HEAD of every repo cloned.
<DarkUranium>
Which might be a decent idea if it's a security fix that *must* be done.
<DarkUranium>
lol
<DarkUranium>
That's not gonna be stable, so no. You can't do that versioning in a package manager.
<pixelherodev>
It's only a problem if people break their software
<pixelherodev>
YOu can if all of the users are sane
<pixelherodev>
:P
<DarkUranium>
Right :P
<pixelherodev>
Which does exempt most linux software
<DarkUranium>
But I'm talking generally. I'm still on the topic of a generic package manager, vs custom.
<pixelherodev>
Note that this is part of why I use 9
<pixelherodev>
to avoid Linux's generall.... linuxness
<DarkUranium>
My #1 concern, BTW --- and a generic package manager does *NOT* resolve this --- is one of culture.
<pixelherodev>
GNU ideas have infected too much of the linux world
<DarkUranium>
Yes =\
<pixelherodev>
I'm happy to call it GNU/Linux for them.
<pixelherodev>
As a condemnation,
<pixelherodev>
And yes, culture is absolutely the point
<pixelherodev>
My main advantage with nine isn't technical at all
<DarkUranium>
Anyways: consider pip, with relatively reasonable packages, each of them being a library or a tool, generally speaking.
<DarkUranium>
Now compare: npm with a shit-ton of single-line packages, 40000-package-deep trees, and whatnot.
<pixelherodev>
It's cultural :O
<DarkUranium>
I'm not sure what the root cause is, but I suspect it's cultural.
<DarkUranium>
Yes. And that's what scares me more than anything else.
<pixelherodev>
Oh for sure
<pixelherodev>
Here's the thing: you can't make a fully inclusive solution and not have to deal with people thinking that's reasonable.
<DarkUranium>
How the hell do I prevent this problem? A generic package manager (such as Nix) does *not* help if my language's culture ends up doing the npm thing.
<ismaell>
pixelherodev: GNU has mutated over the years, it's worse now than it used to be
<pixelherodev>
ismaell: I don't doubt i
<pixelherodev>
t
<pixelherodev>
DarkUranium: this is why my solution is "find an obscure group which has yet to be infected in such a manner"
<DarkUranium>
pixelherodev: it's a tradeoff, though. You want to be inclusive from a marketing standpoint.
<tane>
pixelherodev, the problem is centralization
<pixelherodev>
Disagree
<ismaell>
DarkUranium, pixelherodev: my concerns are more about having interdependecies between the language and the package manager, etc. I want to be able to decouple the language from everything else in a simple way, so I can build just the compiler and live with that, maybe and probably I don't need the rest
<DarkUranium>
ismaell, Coyote won't depend on the package manager, if that helps you.
<ikskuh>
that will always be the case i think
<pixelherodev>
I'd rather deal with lower software support if it means getting a signfiicantly better culture
<pixelherodev>
DarkUranium: there's one fact you *have* to face if you want to do this.
<DarkUranium>
ikskuh, there are some langs that do depend on it. Isn't node one? (at least partially)
<pixelherodev>
You *cannot* solve societal and cultrual issues with technology.
<ikskuh>
ismaell: zig is meant to be used in a similar fashion as C, but with the fact that zig actually needs no standard library
<DarkUranium>
pixelherodev, excuse me, but yes you can.
<ikskuh>
DarkUranium: only talking for zig here ;)
<ikskuh>
i don't care for most other langs anymore
<pixelherodev>
Agree to disagree, then
<pixelherodev>
ikskuh: monster!
<pixelherodev>
:P
<ikskuh>
seriously.
<pixelherodev>
Not even... not even shell?!
<DarkUranium>
pixelherodev, in 1945, we figured out how to make an atomic bomb. You get a big enough one, and *all* the cultural issues are resolved in one swoop!
<ismaell>
DarkUranium: what's coyote?
<tane>
ikskuh, but your hostname tells me otherwise :)
<ikskuh>
which is?
<tane>
php-friends.de
<pixelherodev>
DarkUranium: thank you.
<pixelherodev>
For proving my point,.
<DarkUranium>
pixelherodev, *that* is a societal & cultural issue resolved with technology!
<ikskuh>
tane: that's actually just a damn nice hosting service ;)
<DarkUranium>
Suddenly: 0 issues!
<ikskuh>
it has nothing to do with php
<tane>
ikskuh, just kidding anyway :)
<ikskuh>
it's not even my own domain
<DarkUranium>
ismaell, my own lang.
<ikskuh>
<pixelherodev> Not even... not even shell?!
<pixelherodev>
Or LOST?!
<ismaell>
DarkUranium: link?
<ikskuh>
when i can, i try to prevent shell scripts at all cost
<pixelherodev>
Or asm?
<DarkUranium>
ismaell, completely different goals from Zig, so.
<pixelherodev>
Not even... not even SPU?!
<pixelherodev>
that's a language!
<ikskuh>
pixelherodev: spu is an ISA, not a programming language
<pixelherodev>
Agree to disagree.
<ikskuh>
nah
<ikskuh>
i don't consider machine code a programming language
<ikskuh>
and even then:
<ikskuh>
it's an ISA; not its machine code representation :D
<ikskuh>
i can get -pedantic too
<ismaell>
pixelherodev: I struggle with the "new linux" culture more than the GNU culture
<ismaell>
#sourcemage is nice in that we've got musl support and you don't really have to use GNU stuff if you don't want to
<ikskuh>
what is the "new linux" culture?
<DarkUranium>
pixelherodev, anyways, you can't resolve such issues with technology (well, you can to some extent), but what you *can* do is try to educate.
<companion_cube>
Everything that is not Gnu, ikskuh
<DarkUranium>
For example, strongly discourage people from making 3-line libraries.
<DarkUranium>
And also providing a collection of vetted packages.
<ikskuh>
companion_cube: thanks
<ikskuh>
i want to make a "new linux" myself then, too :D
<DarkUranium>
(think core packages vs -contrib, in OSes)
<ismaell>
ikskuh: hard to define, but the bloat-loving kids running software they don't understand, and wrtiting more software on top of it and whatnot
<DarkUranium>
ismaell, like piling 50 things on top of Docker, systemd, etc?
<DarkUranium>
I've noticed Linux has been doing a rather heavy embrace/extend/extinguish lately.
<DarkUranium>
Mostly Red Hat.
donniewest1 has joined #zig
<DarkUranium>
But others don't realize RH is doing that, so ...
<companion_cube>
ismaell: I sure understand all Gnu code I run
<tane>
DarkUranium, there are many issues at play that increase the likelihood of something like NPM: (1) make it easy to add packages, (ii) make it easy to include packages and (iii) have a bad and inconsistent standard library, JS+NPM satisfies (i)-(iii), rust+cargo satisfy (i)-(ii), thus resulting in wide and deep dependency trees, where you just wanted to try a small lib and got 100 small libs instead.
<DarkUranium>
tane, aren't 1&2 generally good things, though?
<ikskuh>
it depends
<tane>
they are, but have a bad side as well
<ikskuh>
zig will have 1&2 as well
<tane>
I don't think it's sooo easy to add a package to PIP
<ikskuh>
but: there won't be a central index
<tane>
ikskuh, not having a central index will make (ii) harder already
<ikskuh>
which is what most people associate with a package manager nowadays
<ikskuh>
tane: true, but it will be still simple
<tane>
yes, I think nuances are enough
<ikskuh>
assuming the package is available via git, you can just use github :D
<DarkUranium>
tane, I figured I'd have a central index (but optionally others, mind you), but split the repo into 3 parts.
<DarkUranium>
I'm hoping that'd help.
<DarkUranium>
Basically: official, vetted, others
<DarkUranium>
(official are 100% official packages that have certain guarantees; but aren't part of core distribution for one reason or another [usually size or dependencies])
<tane>
well, I wonder whether vetting could be done via signing, using established public-key technologies, building a web of trust
<DarkUranium>
Not that not all packages I make will be official.
<DarkUranium>
... most won't, in fact.
<ismaell>
DarkUranium: yeah, that matryoshka deployment style too
<DarkUranium>
ismaell, hm? What do you mean by that?
<DarkUranium>
To be clear, a rule of thumb for official packages is that they'll all essentially be "extended stdlib" features.
<DarkUranium>
Coyote stdlib will be minimal by design (remember: embeddable)
<ismaell>
companion_cube: I didn't mean GNU with that, GNU has other problems, like ego issues, the FSF owning everything, RMS in the past dictating what projects should do on the technical side, etc.
<DarkUranium>
Official packages will provide stuff for stand-alone use, though. Think a library to do HTTP requests, async I/O, that sort of stuff.
<DarkUranium>
Sockets.
<DarkUranium>
gtg for ~20 mins.
<tane>
just a personal issue: I dislike the term "official" :D
<ismaell>
DarkUranium: I meant your comment on docker, systemd, etc.
<ismaell>
DarkUranium: each enviroment/library/supervisor being more complex than the thing running on top of it
<ikskuh>
luckily, we only have an official source repo :D
<tane>
indeed
<tane>
I find the decentralized community approach good as well
<tane>
this focus in the rust world on "the Rust community" is a really nice marketing scheme - and it works too, creates identity etc etc - personally I find it off-putting, but a lot of people disagree on that
<pixelherodev>
I find it horrendous
<pixelherodev>
well
<pixelherodev>
More their particular implementation than the concept
<pixelherodev>
Topic-based community, sure
<companion_cube>
there's a community anyway, whether it's official or not
<companion_cube>
people reading the same newsletters, watching the same projects, asking questions with the same topics
<pixelherodev>
The issue isn't that there is a "rust community"
<pixelherodev>
it's *the* "rust community"
<pixelherodev>
pretty toxic from what I've seen
<tane>
from the Rust foundation website: "As a flurry of blog posts from community leaders discussed in 2016: Rust’s product is not a programming language or a compiler. Rust’s product is the experience of being a Rust developer and it follows that Rust’s website declares its official slogan"
<pixelherodev>
^
<pixelherodev>
Yeah, that.
<tane>
I don't need community leaders, nor do I need a new identity - I always wondered what people actually refer to themselves as "gophers" or "rustceans", but then, everyone is different :)
<ismaell>
anyway, zig looks very promising, that's why I brought my concern about package management here :)
<pixelherodev>
tane: fully agree.
<tane>
so I'm not going spew more - I wanted to keep a more positive vibe in 2021 :D
<pixelherodev>
:)
backwhack has joined #zig
<DarkUranium>
back
<DarkUranium>
ismaell, ah, right.
<DarkUranium>
ismaell, what really pisses me off is when projects use Docker as the only distribution method.
<DarkUranium>
"Using $THING" -> "Here's how you start it with Docker ..."
wilsonk_ has joined #zig
<ismaell>
DarkUranium: worse, they make the build depend on docker too
<ismaell>
DarkUranium: so you download ubuntu + compiler + ecosystem + the code then build inside docker
<ismaell>
pretty standard nowadays
<ismaell>
DarkUranium: plus they make it very convenient by "curl $URL/myscript.sh | bash"
<DarkUranium>
Ha.
<DarkUranium>
I love that one.
<tane>
docker is nice though :D
<ismaell>
tane: is it?
<DarkUranium>
I know other approaches are technically the same as `curl | bash` (because do you really inspect all the build scripts?), but the sheer audacity of running something in a shell straight out of the socket ...
<tane>
to play around with stuff, before littering its stuff all over the system, sure
<tane>
or if you want a full LAMP stack (for whatever reason)
<ismaell>
DarkUranium: it would be better if the .sh came with a signature...
<ismaell>
DarkUranium: but no, and in turn it downloads and runs more stuff
<ismaell>
tane: you don't need docker for that; we've been doing it with tarballs and jails/chroot/VMs for ages, it does add the composability automation, but still, that hardly enough to justify the complexity
<DarkUranium>
I've been using FreeBSD jails :D
waleee-cl has joined #zig
<ismaell>
BSDs rock, but they were too heavy in the early days, that's mainly why linux got so much traction
<ismaell>
now linux is the bloated one
<companion_cube>
I always heard that chroot wasn't that safe
<companion_cube>
but maybe these days with linux containers it'd work
<pixelherodev>
Actually, I heard there was a licensing thing that kiilled the BSDs :P
<tane>
ismaell, well, you're right I guess and I'm lazy. So a student gave a presentation on how to docker, so now I can do it too :P
<ismaell>
and the BSD licensing style means companies often shoot themselves in the foot with their choices when they go BSD, so a lot of us prefer GPL so they don't make stupid choices, even so they still do manage to ruin it
<ismaell>
companion_cube: chroot isn't about safety, you need namespacing for that, and that's what containers actually are, but jails are namespaced so are containers :)
<pixelherodev>
queue DarkUranium's "GPL is awful" rant which successfully swayed me to using MPL for my copyleft stuff :P
<ismaell>
yeah, GPL has it's problems, I wouldn't deny it, but it does a good job anyway
<ismaell>
I don't want another rant at it, I have even my own
<ismaell>
MPL is weak, so doesn't do what I need it to do
<ismaell>
GPL is the only reasonable option, sadly :(
<ifreund>
pixelherodev: tldr? I like the GPL for my non-library programs
<ifreund>
s/programs/projects/
<ismaell>
pixelherodev: not sure about that, you mean the berkeley vs bell labs dispute? or SCO trying to sue everyone?
<ugla>
There's the EUPL too, which is much like AGPL, but is available in many translations that are all "of equal value." Comes with a license compatibility matrix which is pretty handy too.
hnOsmium0001 has joined #zig
<marler8997>
andrewrk, so what's holding up the new commits from getting to ziglang.org?
<marler8997>
is it the ziglang.org CI issue you mentioned the other day?
nvmd has joined #zig
dyeplexer has joined #zig
pixelherodev has quit [Ping timeout: 264 seconds]
zags_ has quit [Ping timeout: 256 seconds]
geemili has joined #zig
zags has joined #zig
donniewest1 has quit [Ping timeout: 240 seconds]
donniewest1 has joined #zig
a_chou has joined #zig
Akuli has joined #zig
<marler8997>
I seem to be getting 64-bit executables with: zig build -Dtarget=i386-windows ??
<marler8997>
build.zig is using b.standardTargetOptions(.{})....so not sure what's wrong
xackus__ has joined #zig
<marler8997>
oh you know what, I'm an idiot, I was calling setTarget somewhere else with .{ .os_tag = .windows }
plumm has joined #zig
plumm has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
dyeplexer has quit [Remote host closed the connection]
xackus__ has quit [Ping timeout: 256 seconds]
cole-h has joined #zig
<voldial>
first time using zig, I figured I'd compile some C, it went perfectly: https://bpa.st/OAMA that's really cool. How do I generate a pie ELF?
<marler8997>
hmm, still not sure how things get deployed :)
meatcar has quit [Quit: bye bye.]
<andrewrk>
main zig CI makes a commit to www.ziglang.org repo, which has its own CI that deploys
meatcar has joined #zig
<marler8997>
ah
<marler8997>
I dub this new version of Zig as holy water, cleansing all it touches, starting with the ziglang.org gatekeeper
<andrewrk>
lol
<ifreund>
andrewrk: I think I've found a good aproach for line comments in zig fmt, still working through test cases to make sure it doesn't break down somewhere
<zags>
ifreund: isn't that an extra copy? Or does it place it into my allocate area?
<andrewrk>
marler8997, same. I don't really see the value in an abstraction for this
<voldial>
ifreund: thanks. readin'
<ifreund>
zags: oh I didn't read well, you'd need x.* = .{ .myfield = somevalue }; since x is a pointer (you could make it const by the way)
<voldial>
marler8997: cool
<marler8997>
yeah, it seems like every time I see a cmdline parsing library, there's always corner cases to handle which eventually makes the library bloated/complex or using the library ugly
<ifreund>
andrewrk, marler8997: My reason for an abstraction here was to avoid code duplication between (eventually many) sub commands
<zags>
ifreund: question remains, do I allocate and then immediately copy here?
<zags>
which would be wasteful
<ifreund>
zags: there is no other way to initialize allocated memory
<andrewrk>
ifreund, ah that makes sense
<marler8997>
an application specific parser that's used in multiple places makes sense. It's the general case that seems to be hard
<ifreund>
and my arg abstraction is quite primitive tbh, but still nice to use
<zags>
ifreund: yeah, stack allocated does it immediately, feels like heap allocated memory should have a way to do it as well, but I guess we'll rely on elision in the future
<voldial>
marler8997: you prob know, but portage does something similar, we have slots, so parallel installed versions of stuff is easy
<andrewrk>
I wouldn't worry about allocating memory for args, you do it once and it's not going to be noteworthy when compared with mem & cpu usage of the rest of your app
gazler has joined #zig
<ifreund>
zags: you get uninitialized memory from the OS, there is no way to initialize it without copying something into it
<zags>
sure, i mean if the literal is a temporary here, but I'm thinking in C++ terms haha
<ifreund>
andrewrk: yeah, but allocation is annoying cause then there are errors to handle. my abstraction is allocation-free and, like river, does not support windows :)
gazler_ has quit [Ping timeout: 256 seconds]
<andrewrk>
nice :)
gazler_ has joined #zig
<marler8997>
voldial are you saying portage's cmdline parsing is similar to the example I sent you?
<ifreund>
and it only trigger one stage1 comptime bug, for which I found a workaround :P
<ifreund>
anyhow, I'm going to get back to zig fmt fun
<voldial>
marler8997: no sorry, I was saying that portage has someting similar to zigup, in a ebuild (the install instructions portage parses) you can specify which version of something to use or depend on. it's very mature and nice.
<marler8997>
oh cool
<andrewrk>
ifreund, so you're doing comments? I'll work on some of those recovery cases then
<marler8997>
nice, it's like dipping your toes in the NixOS water :)
meatcar has joined #zig
<voldial>
marler8997: heha. gentoo, but Nix is sweet... it's just missing the compile flags we love (called USE flags)
tnorth has quit [Ping timeout: 264 seconds]
<marler8997>
USE flags?
<g-w1>
tells gentoo which features to compile in
<voldial>
marler8997: yea, they let you decide ./configure opyions globally or per-package. so I can say (for example) disable X support on everything)
<g-w1>
supposedly makes ur binary faster since it is customized to ur machine
<marler8997>
well, nixos has that in it's configuration file
<voldial>
of curse, there is no ANSI color supporting bpaste :( but I assure ya, it looks nice here
zags has quit [Read error: Connection reset by peer]
<voldial>
g-w1: I find them useful to disable features I dont want. for example, globally disable ipv6, or suport for a particular init system (gentoo supports multiple)
<voldial>
ok. back to learning zig
geemili has quit [Ping timeout: 272 seconds]
<tane>
does the compiler elide error checks if the error union is provably empty?
geemili has joined #zig
<ifreund>
aahh found another lastToken() bug :D
<ifreund>
I'm not a fan of how they cause spooky action elsewhere
<ifreund>
tane: I'd assume llvm is smart enough to do that yeah
nycex has quit [Remote host closed the connection]
nycex has joined #zig
motiejus has left #zig ["User left"]
leah2 has quit [Ping timeout: 260 seconds]
leah2 has joined #zig
sord937 has quit [Quit: sord937]
sebonirc has quit [Ping timeout: 240 seconds]
dddddd__ has joined #zig
dddddd_ has quit [Ping timeout: 256 seconds]
dddddd_ has joined #zig
plumm has joined #zig
dddddd__ has quit [Ping timeout: 256 seconds]
dddddd__ has joined #zig
dddddd_ has quit [Ping timeout: 256 seconds]
dddddd__ has quit [Ping timeout: 256 seconds]
dddddd has joined #zig
<ifreund>
andrewrk: put up the pull request for line comments. I've realized there's an issue with my bright idea to get rid of renderExtraNewline() though as it's currently too permissive
<ifreund>
I'm pretty sure we need to solve this differently than what renderExtraNewline() was doing as it wasn't aware of comments
<ifreund>
so overall a good step in the right direction, but not yet all the way there
<ifreund>
I also haven't taken a good look at multiline strings yet... I'm done writing code for the day though
Akuli has quit [Quit: Leaving]
<ifreund>
(of course if you think the approach is totally wrong that's fine too, I undestand the problem a lot better now at the very least)
<andrewrk>
thanks ifreund! I'll keep pushing on astgen stuff for now, there's a good chunk of work to be done here
<andrewrk>
who would have thought that completely redoing memory layout for the first 2 stages of the compiler pipeline would involve so much code rewriting?
<tane>
;)
<ifreund>
andrewrk: also, I think we might need to add ContainerDeclSemicolon variants or use the *Comma ones for semicolons as well :/
<ifreund>
I'm not entirely convinced this approach is cleaner than recursion in the end tbh
<andrewrk>
oh recursion would certainly be cleaner
<ifreund>
not that I actually recommend doing that, just to demonstrate that you can :P
<andrewrk>
why not just put the dots at the end?
<andrewrk>
also I'm not a fan of this thing where you use a return value to structure your syntax differently
<andrewrk>
I am skeptical those functions chain like that without forcing them to redundantly return one of the parameters as the return value
<g-w1>
will zig fmt ever change the ast?
<zags>
andrewrk: this is for a streams api (which I've heard you dislike, but I like them so I make them :) and putting the dot at the beginning is what everyone do. But I'll try to adapt.
<andrewrk>
I don't see any error handling here
<zags>
it's now able to filter, reduce, fmap, zip, skip
<zags>
the error is propagated
<zags>
the example is not from my api, that was just a formatting test
<zags>
presumably #1717 will clean up the latter one
<andrewrk>
ah yes, some people are fond of programming like this
<zags>
I don't use it as a style in general, but it's immensely powerful when you need it
<zags>
Streams, that is
<andrewrk>
fair enough :)
<zags>
will add skip, limit, distinct, sort, flat-map, searching, stats, and collecting into arrays, then push it up so people can ignore it.
<zags>
It's mainly to learn zig anyway (and it's awesome)
<andrewrk>
I'm sure you'll find plenty of folks who enjoy that style of coding
<zags>
I'm not advocating a style of programming though
<zags>
It's for when you actually need to compose lots of operations on a dataset and use little memory while at it
<zags>
Not sure how it's possible to be against it :) It's just a list of things that needs to be done, quite expressive and error propagation works, so :)
<zags>
Here's the important part: Zig is a side language and it'll be days between I look at it. But the language is so small and things compose so well it's a no-brainer to pick it up again. That's not the experience I had with Nim, Rust or Swift this year. So huge kudos on the language.
donniewest1 has quit [Quit: WeeChat 3.0.1]
<andrewrk>
:)
a_chou has quit [Ping timeout: 272 seconds]
tane has quit [Quit: Leaving]
<andrewrk>
tdeo, looks like this does not make zig fmt auto fix code, right?
riba has quit [Ping timeout: 240 seconds]
GrooveStomp has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
GrooveStomp has joined #zig
<tdeo>
andrewrk: it does, that's the first commit
<andrewrk>
ahh my mistake. nice work on this!
<andrewrk>
I'm going to have to rework some of it for the ast-memory-layout branch but I think this is good to land in master branch in the meantime :)