Mastodawn

if the goal of "free software" is to give the user control over how the software behaves then is minecraft[1] more free than, say, gcc[2]? thread locked by moderators after reaching 100 pages of intense debate

[1]: where an end-user can usually install >100 mods with a lot changing the game in nontrivial ways reasonably trivially without major conflicts
[2]: where combining multiple features from different forks requires lengthy conflict resolution usually dependent on deep knowledge of the systems being modified

what im trying to say is github.com/FabricMC/Mixin & github.com/LlamaLad7/MixinExtras rock and we need clones of them for more languages and environments

GitHub - FabricMC/Mixin: Mixin is a trait/mixin framework for Java using ASM

Mixin is a trait/mixin framework for Java using ASM - FabricMC/Mixin

GitHub

https://j0̷.lol 4d ago

@kopper i feel like jvm being jvm makes this stuff a lot easier than like c

@j0 @kopper yea, the jvm has an idea of what a local variable is, and only inlined stuff ever if constants (depends on compiler / obfuscater settings too).

something similar for native is, while not impossible, going to be much harder and much less powerful (again, jvm generally has only one form for certain things, native has as many as codegens * their versions

even just inject at head is going to be difficult because where does function prepare end and body begin ?

@j0 @kopper i think there is much more value in making our software's features more decoupled so instead of rewriting parts, you swap them in and out for ones that suit your needs better

@SRAZKVT @j0 this bit is interesting to me. how granular is the swapping parts bit supposed to be? executables? libraries? what's the real difference between the two?

@kopper @j0 it's imo better to standardise executables because a library's api shape how it is implemented, while executables gives a lot more freedom (heh) on how to do things

but there's cases where we need libraries

there's also the possibility to standardise a daemon's protocol for certain operations, though this is in this case mostly useful for things which would need some form of privilege (like ping)

d@nny disc@ mc² 3d ago

@SRAZKVT @kopper @j0 spack has done the most work on swapping libraries that i'm familiar with both through the concretization that reconciles compatibility directives and then through the installation process which e.g. rewrites RPATH. there's not really a distinction there between executables and libraries but it's not magic and as you say there are library decisions that affect this

d@nny disc@ mc² 3d ago

@SRAZKVT @kopper @j0 i also agree that a cli api is standardizeable like a daemon protocol but this is not done for some reason and in fact google engineers will say outright that a cli is not an api when they whine on twitter about linus banning them from the kernel for breaking the perf cli

@hipsterelectron @kopper @j0 a cli is an interface that can be constructed to do needed operations by a program. it's an API.

a restricted one, sure, but it's still one

princess pancake

@SRAZKVT @hipsterelectron @kopper @j0 it's a terrible boundary to cross though

@natty @kopper @hipsterelectron @j0 how so ? your build system does it every day by calling your compiler, i don't see why we shouldn't generalise it

API implementation freedom is inversely proportionnal to how specific to the internals the API is, executables in that regard just give a very generic thing. that's why we can have wildly different C compilers and yet all of them can work together to build something that works

princess pancake

@SRAZKVT @kopper @hipsterelectron @j0 I have no idea what you picked up from our reply, are working on one such project ourselves (it works well in shells)

Generalizing CLI might improve the interface and UX/DX by avoiding repeated parsing and serializing, however it's unlikely to open any new opportunities given how sloooow executing a program is. Microservices already show roughly how small you can go

It's kinda like RPC in that sense, without the R. Replacing argparse with something like a Protobuf definition won't really fix the inherent limitations. It would be an improvement to the status quo tho

You could have the processes running and talk via IPC- hold on that's what Mojo is

@natty @kopper @hipsterelectron @j0 oh i think i misunderstood you because you misunderstood me

i meant generalising the idea of delegating work to another process with the cli itself acting as interface, i didn't said anything about standardising the cli itself, that's pretty much a lost battle already anyway

@natty @kopper @hipsterelectron @j0 and for your last point, yes, a daepon is an api. but when something is done once only, spawning a daemon is a bit overkill, unless you merge in more features and capabilities into it, but then you go back to the original problem of having a single monolith you can't meaningfully modify the inner workings of

princess pancake

@SRAZKVT @kopper @hipsterelectron @j0 I think I misunderstood your misunderstanding because you misunderstood whether we misunderstood, because I am getting lost

We do argue that work-splitting via CLI API can work, but also that the use cases are limited

Although it could be interesting to generalize busybox-style commands for "CLI libraries"

d@nny disc@ mc² 3d ago

@natty @kopper @SRAZKVT @j0 i provided in a separate subthread a characterization of the cases where work-splitting is particularly effective https://circumstances.run/@hipsterelectron/116261376121926115 this ended up being the key insight necessary to parallelize scala compiles where the outline compiler ran in a persistent process in topological order while the longer-compiles could be fully parallelized via this exact approach (although in that case we actually did RPC process executions which pay an additional cost to upload input files)

d@nny disc@ mc² (@[email protected])

@[email protected] @[email protected] @[email protected] no fucking way they added a retry flag but only for process execution. i am always proven right. anyway if you have a coroutine framework available then you can leverage asynchrony in ways the individual tool cannot because it cannot control the execution environment https://docs.google.com/document/d/1iWINqg30nXaCYmBxma5h5RgWzx7sgFqWGJcQJ-RYpRE/edit?usp=drivesdk outline for a conference talk i gave at CGO 2019

GSV Sleeper Service

d@nny disc@ mc² 3d ago

@natty @kopper @SRAZKVT @j0 one notable insight of that document is that it's extremely difficult for the persistent process to generalize across scales of input whereas the ephemeral one-shot invocation can do that without harming either end of the spectrum.

i find your mention of a busybox-esque cli api tantalizing but i am not terribly certain i understand it yet. i have been accidentally producing a shell script compiler for bootstrap scripts after spending a lot of time with autoconf and specifically found incorporating process executions (which becomes a form of constant folding) to be very difficult as it conflicts with the layered output framework of m4

princess pancake

@hipsterelectron @kopper @SRAZKVT @j0 To elaborate, busybox could be generalized to something like a shared library for shell scripts

We're in our free time working on a semi-statically-typed shell that would have a similar property by design, making functions definitions double as a DSL for CLI definitions

It's still heavily WIP though

princess pancake

@hipsterelectron @kopper @SRAZKVT @j0 Essentially it would be first-class reflection kinda like D-Bus

d@nny disc@ mc² 3d ago

@natty @kopper @SRAZKVT @j0 that's super interesting!! i was working on a framework that exposed argv parsing and json deserialization from a shared specification for the zip crate cli which also incorporated named input/output streams and also felt this would be functionality useful to a shell. positional argv parsing by specification also enables some degree of analysis/type checking/optimization but most certainly argv splitting

d@nny disc@ mc² 3d ago

@natty @kopper @SRAZKVT @j0 spack uses json schema for its yaml config which does not change often and idk about the applicability of that more generally but the build system i'm working on has structured argument registration with precedence between hardcoded < env < config file < cli arg, where list and dict argument types support extend operations distinct from completely overwriting the prior value

d@nny disc@ mc² 3d ago

@natty @kopper @SRAZKVT @j0 which is from v1 pants https://v1.pantsbuild.org/options.html the "task scope" mentioned here is also used to dereference named output streams and checksummed cache directories

Pants Options