Drakonis has quit [Remote host closed the connection]
tertle||eltret has quit [Quit: Connection closed for inactivity]
mog has joined #nixos-chat
<joepie91>
ergonomics question for everybody: if there were to be a typing system of some sort with a serialization/deserialization mechanism that ensured you could only deserialize data back into the same types it was originally serialized from... would you consider two types that have identical type/data constraints but a different display name to be the "same type", or not?
<ekleog>
joepie91: by type/data constraints, do you mean having the exact same fields with the same types, or something more powerful than this that would add struct-wide data constraints?
<joepie91>
ekleog: can you give an example of the distinction you mean?
<ekleog>
like, a type (uint32, uint32), and a type (uint32, uint32) that has as documented invariant that the first one is less than the second one
<ekleog>
do they have the same type/data constraints with your definition?
<joepie91>
ekleog: it's not exactly a static type system in the traditional sense; it's a bit like the latter except constraints can be specified as arbitrary validation rules (ie. arbitrary code)
<ekleog>
so here you'd have a constraint that .0 < .1, and it'd count as a data constraint?
<joepie91>
I've not yet fully thought through whether that can represent all necessary constraints
<joepie91>
that's one thing that should be possible to express, yes, although I should make a note here that 100% strict validation of everything isn't necessarily the goal here, the goal is to increase the chances of errors being caught early/clearly as much as possible without affecting ergonomics too much
<joepie91>
(or, preferably, at all)
<ekleog>
hmm, to me if all the invariants are documented in the type, then two types with the same invariants can reasonably be unified, even if they don't have the same name (though that'd potentially be debatable)
<joepie91>
ekleog: right; the question is mostly one of ergonomics, of preventing unexpected surprises
<ekleog>
if I can't encode all invariants in the constraints system, I think two types with different names shouldn't unify (and thus the first serialized shouldn't be deserializable to the second one)
<joepie91>
any particular reason for that?
<ekleog>
well, I can't give examples in dynamically-typed languages, but I've often used eg. an Index type that's just a uint underneath, but that adds as an invariant that it is an index into [something], for example :) if I could serialize an uint and deserialize it as Index, then it'd potentially break said invariant
<joepie91>
right
<joepie91>
ekleog: how does this account for the case where - given that it's serialization and may involve usage in multiple execution contexts - there are two type definitions that are semantically different but have the same display name *and* the same constraints encoded in the type system?
<joepie91>
(in your view)
<ekleog>
joepie91: I currently am hitting exactly the same issue :D
<ekleog>
(also doing a serialization/deserialization scheme across a distributed system)
<ekleog>
issue is, I don't think it's possible to do any better than checking constraints + name, so, well… even if it's not perfect it's the most I could do
<joepie91>
right
<ekleog>
(and yes, this also hits the issue of a type that has been renamed between two versions that may be running concurrently :/)
<joepie91>
ekleog: I'm considering settling on "only constraints are used in the sameness determination, and in addition to that all the deserialized data goes through the usual constraints"
<joepie91>
er
<joepie91>
constraint checks *
<joepie91>
to be clear, these are runtime checks
<joepie91>
as I'm not convinced that I can encode all the constraints, reliably, in eg. a type hash
<joepie91>
so the hash/sameness check would serve primarily as a way to catch problems early and in the right context, ie. "you tried to use the wrong type with the wrong type" instead of having it fail strangely on a particular field
<joepie91>
relying on the usual validation to provide the actual correctness
<ekleog>
so long as all/most of the invariants can be encoded in your constraints system, it sounds right :)
<joepie91>
yeah
<joepie91>
ekleog: so, for a little more context, I'm writing a sort of data modeling thing for JS, that's part type system, part validation library, part... sorta relational DB?
<ekleog>
the trade-off between “what if two semantically-different types have the same constraints” and “what if I rename a type” is hard to get right :/
<joepie91>
and it allows arbitrary callbacks for validation
<joepie91>
so that's pretty difficult to encode deterministically :P
tertle||eltret has joined #nixos-chat
<ekleog>
yeah indeed ^^ unless you can compile the constraints to bytecode and hash said bytecode? :°
<joepie91>
problem is that there is not a canonical bytecode representation of JS code
<joepie91>
plus then you'd only cover the 'literally the same' case
<joepie91>
semantically equivalent for syntactically different code would register as different
<ekleog>
indeed
<joepie91>
s/for/but/
<ekleog>
(but then, covering semantically equivalent for syntactically different is the kind of thing that requires a prover to get 100% right, so… ^^)
<ekleog>
like, with your system afaik I could encode an Index and decode it as an uint, which may or may not be an issue
<joepie91>
so in principle I could ensure that every serialized version of the data includes the type alias that was used
<joepie91>
but then again they'd still be equivalent in terms of constraints
<joepie91>
so you'd still have the problem of two type aliases with the same 'target type' being treated as equivalent
<ekleog>
I've just noticed there may have been some research into this “strongly-typed serialization in an heterogeneous environment” problem, but… find nothing on google scholar :/
<ekleog>
joepie91: It looks interesting, but I must say I personally feel approx. as bad about javascript everywhere as I feel bad about C everywhere 😇 your project looks like it could bring some sanity in this world, though
<joepie91>
ekleog: shrug, JS has relatively little inherent badness
<ekleog>
hmm… relatively to what? apart from PHP and C I can't think of any currently-actively-used languages that would have more badness than JS :°
<ekleog>
maybe perl, but I don't know perl enough to judge
<joepie91>
ekleog: the inherent badness in JS is pretty much 1) implicit type conversions (this includes nonsense like NaN after numeric operations), 2) == vs. ===, 3) only floating point numbers (but that is being fixed), 4) no way to indicate that eg. an argument *must* be specified, leading to propagated nulls/undefineds causing trouble later on
<joepie91>
that's... about it
<ekleog>
yeah, that's pretty much worse than all other languages I know of :°
<ekleog>
(and you forgot 5) NPM is full of nonsense)
<joepie91>
nope, not a valid point
<joepie91>
easy target, no validity in a discussion of language quality :)
<joepie91>
and the issues listed above are a relatively small handful
<joepie91>
their impact in practice is usually of the 'wastes your time' variety, not of the 'lol you're pwnt' variety, like with eg. memory-unsafety
<joepie91>
they're also issues that - for the most part - you can learn to deal with, without needing to keep a ton of quirks in mental context
<ekleog>
well, apart from C there aren't many memory-unsafe languages nowadays :) (well, C++ written like C too)
<joepie91>
I would much rather that these issues not exist, but they are really not that significant compared to all the quirks in virtually every popularly used language
<joepie91>
certainly not significant enough to single out JS as especially bad
<ekleog>
Well, to me, the podium of bad languages is: JS and PHP as “this makes no sense” (the points you quoted, basically), C and C++ as “potentially unsafe”, and maybe perl but I've only seen code golf in perl so that's not a good evaluation point. Apart from these languages, what would you propose to get in my podium of bad languages? :)
<joepie91>
ekleog: Python has awful dependency management (including how imports work in the language), Perl has a massive security-impacting footgun in, what were they called again, lists as opposed to arrays? see the 'perl jam' talks... Ruby has a ton of different issues because they made the mistake of trying to mimick natural language in a programming language as well as various other ill-informed ergonomic choices, PHP is absolutely full of issues
<joepie91>
including beyond 'wasting your time' issues and right into the security category -- and most of the popular languages have very poor support for arbitrary abstractions
<joepie91>
to just name a few
<joepie91>
the only popular language I've seen that I'd call genuinely well-designed would be Rust, and that makes a bunch of tradeoffs that while well-engineered, make it suboptimal for many usecases in practice
<ekleog>
perl and php were already in the podium :°
<joepie91>
I mean, there's only so many popular languages :P
<joepie91>
and given that you indicated you were unsure about Perl...
<ekleog>
indeed :)
<ekleog>
tbh, python's dependency management, variable scoping issues (similar to JS' let/var) and nested list comprehension order still isn't as bad as the implicit conversions in JS and its only-floating-point behaviour, to me
<joepie91>
only-floating-point is currently being fixed in the language so I'm going to ignore that point for a bit
<joepie91>
as for implicit conversions: Python's dependency management is *worse*, because whereas implicit conversions are something you can develop habits to work around (and even analyze with tooling), Python's dep management is just an inherently unsolvable issue
<ekleog>
for used languages, rust would be #1 for me indeed (hence my pushing to use it everywhere I can :°), but haskell and ocaml would come close, and variants of erlang look pretty good too :)
<ekleog>
(or erlang itself, actually)
<joepie91>
(oh, also, most popular languages are bad because they don't have modules)
<ekleog>
for python, I've never hit an issue with it until now, while I have hit many issues with npm :°
<joepie91>
ekleog: issues such as?
<joepie91>
(and I've had _many_ issues with Python; plus there is a boatload of invisible issues that significantly affect the ecosystem)
<ekleog>
different incompatible versions of a module being pulled at the same time, or just npm refusing to pull the dependencies and balking on me
<joepie91>
former is by design; latter sounds like an npm issue rather than a language issue, but I can't say much more without details
<ekleog>
well, by design or not, it causes really weird errors when trying to debug it :) though I guess some dependency we used had a bug in it
jtojnar has quit [Quit: jtojnar]
<joepie91>
given the tendency to do duck-typing in JS, I've basically never seen a single real-world issue caused by having different versions of modules in the tree
<joepie91>
like, this is a thing that is explicitly supported
<joepie91>
(and it prevents many of the issues that plague Python's dependency system)
<joepie91>
so I'd be very interested to see what error that caused :)
<ekleog>
It was like 3 years ago since I last did JS so I don't remember very well, but somehow we ended up concluding it just didn't work somewhere in the maze of dependencies we had, ragequit and changed the framework we depended on .)
<ekleog>
(basically, point 5, NPM is full of trash, I guess :p)
<joepie91>
'framework' is an immediate red flag to me
<joepie91>
were you trying to use a monolithic batteries-included thing?
<ekleog>
I don't remember very well, but it was something like a version of angular, polymer, and things like that
<ekleog>
(think it was pre-angular 2)
<joepie91>
then that is probably where your issue was :)
<joepie91>
Angular/Polymer/Meteor/etc. have a habit of essentially trying to be their own language and ecosystem that happen to use JS syntax, and they interoperate extremely poorly with other things
<joepie91>
monolithic things like that are also not at all well-supported in the rest of the JS ecosystem
<ekleog>
tbh, if I can't use things like this, there's really no point in JS compared to just using WASM with a sane language :p
<ekleog>
(there wasn't any WASM at the time, though)
<joepie91>
ekleog: 'things like this'?
<ekleog>
all the big frameworks
<joepie91>
then you have an extremely inaccurate view of JS :P
<joepie91>
'big frameworks' are absolutely undesirable in JS
<joepie91>
the whole point of how the language and tooling are designed is to make those unnecessary
<ekleog>
it's true I've only done JS for web development, and it was a PITA :)
<joepie91>
so yes, if you're going to try and stick with big frameworks, you will not have a good time
Ericson2314 has quit [Ping timeout: 265 seconds]
<joepie91>
the solution is to... not use big frameworks, but instead learn how to use JS' strong points
<joepie91>
and stick with modular systems
<ekleog>
hmm… well, just in case, “how the language is designed” is “in one week to get something that roughly works enough to make netscape have an advantage competitors”, heh
<joepie91>
unfortunately it's extremely difficult to get this across to people, especially en masse, as people are used to monolithic things in $whateverOtherLanguage and they just look for a similar thing in JS, assuming that That Is How It Is Done
<joepie91>
ekleog: yeah, no, that is BS
<joepie91>
sorry, but this is tribalist crap
<ekleog>
and modular systems end up in leftpad when taken too far :)
<joepie91>
there's been 20 years of development on JS, the language is almost nothing like its initial version
<joepie91>
ekleog: leftpad was never a language issue, it was an npm infrastructure issue
<joepie91>
you're basically iterating through all the BS tropes about JS right now :)
<joepie91>
none of this is even remotely correct or relevant
<ekleog>
there's a middle-ground in modularity, for sure, but it's hard to strike it correct
<ekleog>
<joepie91> ekleog: yeah, no, that is BS <-- hmm… heard it from someone who was present at the time, if I remember correctly, so…
<joepie91>
(and they're pretty tiring tbh, because it's the same shitty tropes every time and nobody ever has any actual rationale to back it up, or any extensive knowledge of the thing they're criticizing)
<joepie91>
ekleog: see [07:50] <joepie91> there's been 20 years of development on JS, the language is almost nothing like its initial version
<joepie91>
JS now != JS 20 years ago
<ekleog>
and the 20 years of development on JS still haven't managed to get rid of only-floating-point
<joepie91>
JS was not "designed in a week" any more than any other language has been
<joepie91>
pretty much every language in common use was the result of a quickly-developed initial prototype with gradual changes over time
<ekleog>
<joepie91> ekleog: leftpad was never a language issue, it was an npm infrastructure issue <-- for me, npm *is* part of javascript now, because it's almost impossible to use js without it :)
<simpson>
joepie91: A thing you missed: eval().
<joepie91>
ekleog: it's really not; but even if it were, your mention of it in relation to modularity tells me that you don't actually understand what happened with leftpad
<joepie91>
because if you did, you'd know that it had absolutely fuck all to do with modularity :)
<ekleog>
joepie91: well, quite a lot of languages didn't have to deal with 20 years of only-floating-point :)
<simpson>
Anyway, sure, maybe ES isn't complete and total trash. But there's a lot of languages that are like ES but without the bad parts.
<ekleog>
^ exactly that
<joepie91>
ekleog: and to put it bluntly: the modularity afforded by JS is a *necessary change* in programming, something that is an absolutely crystal-clear net positive when you look at the tradeoffs objectively instead of basing it on what you're used to
<ekleog>
(and leftpad is a 10-lines function, if it's given a module just for itself then it means that for every stupid function you start adding a dependency, and thus relyingon someone else)
<ekleog>
which naturally leads to the outcome it has
<joepie91>
ekleog: but instead of trying to understand the tradeoffs and why they exist, people - like you - go OH LOL HAHAHA STUPID because it's unfamiliar and blame everything on whatever is different
<ekleog>
because at some point a mistake must be made
<joepie91>
no, it does not
<joepie91>
all of this is nonsense
<joepie91>
none of this is thought through
<ekleog>
in which way?
<joepie91>
all of this is gut feelings based on familiar mechanisms
<simpson>
ekleog: There's nothing natural about npm; it's not necessary. npm is like a tumor.
<joepie91>
ekleog: I'm sorry, but I'm exceedingly tired of having this very same discussion every time with the very same crappy arguments every time and the same crappy assumptions every time with absolutely no attempt at trying to understand why one's perspective may be wrong
<ekleog>
simpson: tbh, before you two all JS devs I've met only swore by NPM
<joepie91>
this is going to turn into an hour of you making claims about small modules that I then have to disprove only for you to move on to the next claim
<joepie91>
and all of them will be claims that I literally hear every week when this is brought up
<joepie91>
and none of them will have any technical validity
<joepie91>
this discussion is not going to work unless you open yourself up to the possibility that your perspective of the tradeoffs may be wrong, and you're willing to look at the tradeoffs objectively, in depthb
<joepie91>
depth*
<simpson>
ekleog: I'm not a JS dev. I know some people who have infiltrated TC39, the ES steering committee, in order to secretly steer the language.
<simpson>
joepie91: Which module system are we talking about, CommonJS? Its weakness is front-and-center: Static analysis of imports is frustrated, making composition of modules harder.
<joepie91>
like, literally *none of the points you are raising* are novel or particularly on-point, I have heard every single one of them many times before, and I can almost predict what the next point is going to be, that is how regular this is
<ekleog>
I'm willing to look at the tradeoffs, but you haven't given me any argument apart from “what you say is stupid and modularity is necessary” yet :'(
<ekleog>
and yes, I'm not claiming my points are novel, but I haven't heard a good answer to those yet
<joepie91>
ekleog: because I'm not going to play the back-and-forth-for-an-hour-with-assumptions game that people usually turn this into
<joepie91>
and you're not giving my any chance to make any deeper points
<joepie91>
instead moving to the next "lol JS" platitude right away
<joepie91>
there's only so much patience I have for that
<joepie91>
ekleog: if you want to understand the tradeoffs, start by understanding why 'lines of code' is a completely technically irrelevant metric for anything and why it should never enter a discussion about tradeoffs
<joepie91>
but you can write the same code in 10 lines, or 100 lines, with many characters or few, but so long as the code is of the same internal complexity the amount of lines/characters is irrelevant for anything other than "oh hey maybe this code is too condensed to understand all of its complexity"
<joepie91>
ie. the metric that matters is complexity
<joepie91>
both computational and semantic
<ekleog>
joepie91: So let's focus only on modularity :) What I'm claiming about modularity is: 1. Assume I depend on a dozen functions of the simplicity of left-pad (because that sounds like an underestimated number for any real-world application), 2. If the dozen functions are spread on a dozen modules, then I depend on a dozen module authors to not break anything, 3. If they are concentrated in a relatively big
<ekleog>
“helper” module or two, then I depend on one or two authors to not makea mistake. What did I miss?
<joepie91>
ekleog: 2 is already wrong
<simpson>
joepie91: Note how, for example, the module `negative-zero` would simply not have a reason to exist in Python or Monte, where it is such a short expression that it is shorter than the require()!
<joepie91>
and therefore 3 is too
<simpson>
View from the outside would be good.
<ekleog>
(for your argument about lines of code I completely agree, but left-pad is not really a complex in any sense function)
<ekleog>
joepie91: in what way is 2 wrong?
<joepie91>
it is absolutely unreasonable to assume that the amount of modules equals the amount of authors you are trusting; in either direction
MichaelRaskin has joined #nixos-chat
<joepie91>
many modules have multiple maintainers; many maintainers have multiple modules
<joepie91>
of the people claiming "but I'll be trusting hundreds of people when using JS!", exactly zero of them have ever done any actual audit of how many maintainers they are depending on, either for their JS code or their code in $whateverMonolithicThing
<ekleog>
indeed, and it's also true that modules don't break equally easily :)
<joepie91>
and if you start actually looking at the 'trusted parties', there is not a meaningful difference
<ekleog>
but a relatively big library would, on average (from my experience only) be more wary of breaking changes than a small library maintained by one person
<joepie91>
(still typing)
<joepie91>
eg. in the JS ecosystem many of the smaller commonly used modules are written and maintained by a very small group of people; because their scope is extremely limited, they were written early on in the life of the ecosystem when there were less people involved, and have needed little maintenance since
<joepie91>
since their purpose is well-defined, there is also little room for alternatives to take over because modules are generally feature-complete and there is not really a way to improve upon them anymore
<joepie91>
result: a vast part of the small modules you depend on is going to be maintained by the same 5-10 people
<joepie91>
maybe a bit more
<joepie91>
compare to monolithic dependencies, where the requirements are ever-shifting, feature-completeness is never quite reached, maintainers rotate out and get replaced or added
<joepie91>
and there's usually a fairly significant group of trusted parties involved at any one given time
<joepie91>
in practice, I have found no meaningful difference in the amount of trusted parties between applications built with monolithic dependencies vs. applications built with modular dependencies; and so far, nobody has provided any data to the contrary that I know of, anywhere
<ekleog>
just to know, what are you considering to be monolithic dependencies? the big js frameworks?
<ekleog>
(trying to get an idea of the size of said dependencies)
<joepie91>
ekleog: it's somewhat fuzzy, and I've written a whole explanatory thing about it at https://gist.github.com/joepie91/7f03a733a3a72d2396d6, but for the sake of discussion let's assume "implements more than one discrete requirement"
* ekleog
reading
<simpson>
joepie91: It sounds like you're about to start a new tangent; I suppose that there's not time for my criticisms to be addressed?~
<joepie91>
ie. a modular dependency is a single-purpose dependency that has precisely one well-defined behaviour with a well-defined scope
<joepie91>
if you can't determine upfront when it would be feature-complete, it is probably not modular :P
<joepie91>
simpson: not currently
<ekleog>
OK, so as per your definition I'm completely in favor of modularity too
<joepie91>
also
<joepie91>
[08:05] <ekleog> but a relatively big library would, on average (from my experience only) be more wary of breaking changes than a small library maintained by one person
<joepie91>
speaking about the JS ecosystem here - breakage is allowed under semver but frowned upon for modular libraries, you better have a good reason
<joepie91>
(it rarely happens because of said well-defined scope)
<joepie91>
most of the breakage in the JS ecosystem occurs in monolithic things
<ekleog>
*However*, for leftpad, I think modularity went too far, to have a library that would likely be faster to reimplement than to search for
<simpson>
joepie91: That's too bad, as both are fixed by Monte. Monte modules are better than CommonJS modules; in exchange for not supporting mutual recursion, they have statically-defined imports (so they can be *statically linked*) and they have limited authority.
<simpson>
Also `this`. ES `this` is just terrible.
<joepie91>
ekleog: I think you underestimate how much work it is to *fully* reimplement a dependency without already having an exhaustive specification of its behaviiours
<joepie91>
behaviours*
<joepie91>
(in the sense of how the implementation should work)
<joepie91>
it's easy to implement a *naive* version of leftpad, sure
<joepie91>
but that overlooks 1) the research into whether you missed a case that might bite you later, and 2) the cost of actually implementing those cases and testing against them etc.
<joepie91>
shared dependencies amortize those costs
<ekleog>
What I'm saying is not that left-pad should have been reimplemented by all users
<joepie91>
and indeed, in practice almost every case of "I've rolled my own instead of using $library" turned out to be a naive implementation
<joepie91>
(that I have seen, and I've seen many)
<joepie91>
or sometimes even outright broken
<ekleog>
What I'm saying is that a slightly bigger library would have made sense, comprising left-pad, right-pad, center-pad, for instance
<joepie91>
ekleog: left and right pad might have been defensible, although not necessarily; center pad is where it goes wrong
<joepie91>
because what is the 'center' in a string with an uneven amount of padding spaces?
<MichaelRaskin>
joepie91: naive _uses_ of a library which handles all the obscure cases correctly-in-a-consistent-sense do not always end well, though
<joepie91>
different usecases are going to require different implementations for that
<ekleog>
well, just put the different implementations in the `pad` module :)
<joepie91>
now let's say that you need a slightly different version of center-padding with slightly different behaviour for that, so you fork the padding library; now the thing you've forked and need to maintain also includes left and right padding logic that you probably do not care about
<joepie91>
ie. you've just made forking more expensive
<simpson>
ekleog: Why is the existence of small modules a problem? Surely the problem is that somebody thought it worthy to upload to npm and somebody else thought it a good dependency.
<joepie91>
for... what benefit, exactly? because having the logic spread across 2 deps instead of 1 didn't actually introduce any costs
<joepie91>
dependencies, in and of themselves, are free; the costs are in complexity, trusted parties, etc.
<ekleog>
simpson: indeed :)
<joepie91>
(well, they are free in a nested module system anyway)
<joepie91>
(or hash-based0
<joepie91>
)*
<ekleog>
joepie91: because when the code I have is spread over 3 repositories, esp. with such simple functions, it's much longer to review 3 repositories than 1
<joepie91>
ekleog: how is it? it's the same amount of code
<joepie91>
(plus, you'd generally review stuff directly in node_modules, not through their repositories)
<ekleog>
time to find the repositories, clone them and open the code is longer than time to review the code
<joepie91>
why would you need to clone them?
<joepie91>
you already have the deps
<joepie91>
you don't even have a guarantee that the repo matches the installed dep
<ekleog>
that is true and makes checking the deps even harder when having the same dep, at the same version, installed multiple times :)
<ekleog>
also, and maybe more importantly, having more than a trivial function in a module shows a minimal engagement of the author, before pushing the module, thus decreasing the odds they'll just drop everything to the floor (even though that's only odds, not certainty)
<ekleog>
which, if I remember correctly, is exactly what happened with left-pad?
<ekleog>
at least that's the only explanation I can find of why left-pad has happened in the JS/NPM ecosystem, and not anywhere else :)
<joepie91>
back
<joepie91>
[08:19] <ekleog> that is true and makes checking the deps even harder when having the same dep, at the same version, installed multiple times :)
<joepie91>
same versions can be deduplicated; npm does this naively by deduplicating as many versions as possible in a regular tree, package managers like pnpm do this aggressively using symlinks and hardlinks
<joepie91>
(pnpm provides full deduplication)
<joepie91>
[08:20] <ekleog> also, and maybe more importantly, having more than a trivial function in a module shows a minimal engagement of the author, before pushing the module, thus decreasing the odds they'll just drop everything to the floor (even though that's only odds, not certainty)
<joepie91>
keep in mind that the impact of a module going unmaintained is *significantly* lower, like, orders of magnitude lower, for a tiny single-purpose module that will likely never need an update
<joepie91>
it's always possible for a maintainer to drop work on a library; if anything, you want to minimize the impact
<ekleog>
a relatively big library seeing maintener dropping it is also *significantly* more likely to find another maintainer stepping up / the community stepping up :)
<joepie91>
(this minimization of impact through modularity also applies to review; if eg. the left-pad functionality gets updated, having left vs right vs center pad in separate modules means you only need to review 1/3rd of the surface because the other modules remain unchanged)
<joepie91>
ekleog: that only works for the very biggest and most popular libraries
<joepie91>
in practice a ton of things fall by the wayside
<joepie91>
[08:21] <ekleog> which, if I remember correctly, is exactly what happened with left-pad?
<joepie91>
which is something that almost every other package registry got right, just not npm
<joepie91>
this policy has been changed since, although I am not fully convinced that npm really understands their responsibility to the ecosystem; the issues with the company behind npm are a whole different chapter
<ekleog>
well, the author would just have pushed a minor update breaking the interface, if they couldn't have deleted it, wouldn't they?
<joepie91>
even if they tried that, you'd just lock the specific version in and you'd have no trouble
<joepie91>
leftpad happened because an already-used version was deleted
<joepie91>
(and companies did not have infrastructure in place to even deal with npm outages, let alone package deletions)
<joepie91>
like, half the problem with leftpad was npm's stupid policies, the other half was companies not understanding that it's a bad idea to rely on third-party infra for your availability
<joepie91>
which I'm pretty sure many companies still don't understand, judging from how much shit breaks when US East shits the bed again
<joepie91>
:P
<joepie91>
ekleog: btw, not sure how much you heard about the actual failure mode, but the #1 failure with leftpad was companies whose CI processes - that redownloaded dependencies on every evaluation - failed because the package they tried to grab no longer existed
<joepie91>
some companies inexplicably had a setup where this would break their running systems
<joepie91>
like, in prod
<ekleog>
what I'm saying is, a bigger library most likely makes the maintainer feel more responsible for it :) like, rust has this scoped-tls crate, that's been feature-complete for 2 years. It's really small (though much more complex than left-pad), and when I raised an issue to ask the author to bump to 1.0, it looked like they had almost forgotten about checking the status of the lib :)
<joepie91>
ekleog: I can't say that that matches my experience.
<ekleog>
on a slightly bigger library, though, there's be a regular stream of issues/PRs, that would force the author to remember they do have this module
<joepie91>
I suspect you're relating it primarily to _really popular_ monolithic libraries with processes and working groups and multiple active maintainers and whatnot
<joepie91>
my experience with less-well-supported monolithic things is that it's an absolute nightmare to get anything sorted
<joepie91>
because they are much more difficult to support than modular libs
<ekleog>
I'm not saying monolithic (as in “batteries-included”) libs are good, just that left-pad is a bit too much modular :)
<joepie91>
and comparatively, even if the author is not paying attention to their library, it's a single-purpose library so what prevents you from forking it and maintaining it yourself and still saving time over implementing it yourself from scratch?
<joepie91>
if somebody else hasn't already done so, which they usually have when something goes unmaintained
<joepie91>
and no new maintainer has been assigned
<ekleog>
for instance, serde (in rust) looks like a good example: it's a collection of modules where each does a simple thing, but the collection is maintained as a whole, and it has a common objective : (de)serialization
<joepie91>
ekleog: I've seen absolutely no data to suggest that leftpad is 'too modular', and for the reasons described above I'd say that it's absolutely fine.
<joepie91>
ekleog: right, so what's the difference with left-pad, right-pad, center-pad all being maintained as a group of libraries?
<ekleog>
the difference is that (well, I don't think {left,right,center}-pad would make for a “big enough” group for that to kick in, but well) if the group of libraries is big enough, then the author never completely stops developing on this group of libraries
<ekleog>
there's regular activity on the channel from people who want to know how to use it, etc.
<ekleog>
and thus they feel more responsible for it to work
<ekleog>
and to continue working
<ekleog>
and if they stop caring, then a community will have formed around this group of libraries, that will resume mainteneurship
<ekleog>
it's basically building a community around modules vs. dropping a module somewhere to be used :)
<joepie91>
back, cat wanted to file a complaint about her litter bin
<joepie91>
ekleog: you're assuming that there remains something to be maintained, ie. the model of a never-completed library
<joepie91>
I would argue that removing the 'never completed' part and reaching feature completeness is preferable over trying to build a community around a never-completed library :)
<MichaelRaskin>
Well, that works in low-bitrot ecosystems…
<ekleog>
Well, I agree that feature completeness would be great, but when you start doing an ecosystem of modules and not just a module (eg. serde, from above), there is always a feature missing that can make a new module, and thus the library is never really completed, even though individual modules can be completed :) (also, as MichaelRaskin points out, dependencies change with time, which can make code bitrot)
<joepie91>
so long as you don't roll monolithic dependencies into your modular dependencies, bitrot would not be a problem from a maintainer's POV
<joepie91>
re: features missing that can make new modules, sure, but I don't see a problem with that
<ekleog>
iff the dependencies are all already feature-complete
<joepie91>
no, not necessarily
<joepie91>
most dependencies never change their API in a breaking way, and thus can be internally safely updated per semver
<ekleog>
(and proven non-vulnerable)
<joepie91>
this also applies to the majority of security fixes; they rarely involve API changes
<joepie91>
so those are fixed transparently without requiring maintainer action, in most cases
<ekleog>
The point is in “most”, let's say 90% with pure randomness. This 90% is OK when you depend on 10 modules, when you depend on 100 modules it starts to make quite a bit of breakage :)
<joepie91>
far, far higher than 90%
<ekleog>
even 99%, the more modules you depend on the higher the chance your module breaks
<joepie91>
from what I've seen, problematically outdated sub-dependencies are a very rare problem; and in most cases they occur because somebody unwisely pinned an exact version instead of a semver range
<joepie91>
them going unfixed is nearly unheard of
<ekleog>
like, 99% with 100 dependencies => 74% of breakage
<joepie91>
ie. this *already works in practice*
<joepie91>
ekleog: your calculation is off because it assumes that breaking changes always propagate through the dependency tree
<joepie91>
this is often not true
<ekleog>
good point
<joepie91>
if you have project -> dep1 -> dep2 -> dep3 -> dep4 and dep4 introduces a breaking change, in most cases dep3 will just release a patch version that updates the internal dep4 version but does not change its external API
<joepie91>
(this totally breaks down with static typing btw, which is why Rust is having trouble with this)
<joepie91>
(due to type definition propagation)
<ekleog>
(errrhm… no, it's not an issue if dep3 doesn't explicitly expose dep4's API in its own public API, which is a step that must be taken consciously by dep3 developer :) the standard thing to do is wrap the dep4 type into a dep3 type)
<ekleog>
now, I wonder, what's the proportion of feature-complete modules on npm? because in rust there are a few, but definitely not enough yet to actually do complete programs with only them
<ekleog>
(unless it's toy programs)
<joepie91>
blargh, github, stop breaking
<ekleog>
(can be easily counted by counting the number of crates at v1.0)
<joepie91>
ekleog: so I can't link directly because github is broken, but look at https://github.com/rust-lang/cargo/issues/2064, click 'more' to view the hidden items, and then look for the lengthy post written by me
<{^_^}>
rust-lang/cargo#2064 (by sfackler, 2 years ago, closed): Cargo should understand distinctions between public/private dependencies
<joepie91>
which goes into the type propagation issue
<joepie91>
ekleog: btw, compared to the JS ecosystem, Rust is severely behind :P
<joepie91>
almost everything in Rust is still trying to settle on a good API, which is understandable because the 'API' entails a lot more definitions than in JS
<joepie91>
and it's a good deal more complex to solve interoperability problems in Rust than in JS
<joepie91>
there's a ton of effectively feature-complete stuff in npm, in my experience; I haven't kept explicit track of exact numbers though
<ekleog>
joepie91: if the type propagation issue you talked about in the link is an issue, then it means the thing you're depending on is not modular enough, as per your definition :)
<joepie91>
ekleog: not necessarily; thin abstractions over other APIs in particular are definitely single-purpose but are caught by the type propagation issue
<joepie91>
also, I should get to work :P
<ekleog>
'day :)
<ekleog>
it was an interesting discussion for me, even though I'm still not sure I'm convinced about every point :) (in particular I've had people around me complaining about the JS module ecosystem long before left-pad and predicting something like that would happen, while I haven't seen that with any other language yet, so I'd be tempted to think there may be a causation link, even though it's potentially only
<ekleog>
correlation)
<ekleog>
can't find a logical reason for the causation, now, though :)
<ekleog>
(next time, let's pick another topic? :D)
<joepie91>
ekleog: my experience has been that 99.99% of complaints that people express about the module system in JS can, after a bit of digging, be traced back to "this does not work like how I'm used to", and the person applying metrics that are only relevant in monolithic ecosystems to a modular ecosystem with the assumption that they're valid there too
<joepie91>
ekleog: one of the most common examples of that is the assumption that dependencies have an inherent cost, which people have learned because they're used to a flat module system where every dependency really *does* exponentially increase the chance of a version conflict somewhere
<joepie91>
(but which is not true in nested/hashed dependency systems)
<ekleog>
yeah, the thing I'm pondering is, why did left-pad happen with npm and not, like, with python, to compare another popular language that has been around for long too :)
<joepie91>
when somebody speaks of "600 dependencies for a simple project" without specifying what the actual cost is, that is probably the mistake they're making, for example
<joepie91>
ekleog: because npm inc are absolutely incompetent at running a package registry :)
<joepie91>
there have been more incidents, and there will be more incidents
<ekleog>
I personally very much like the rust model of “600 dependencies but picked among 3 dependency groups”
<joepie91>
unlike package registries in most languages, the npm registry is operated *commercially*
<ekleog>
oh yeah, that may be why
<joepie91>
with no oversight of or influence from the rest of the ecosystem
<joepie91>
nor even Node core
<joepie91>
so they regularly fuck up availability / security / etc. and are totally intransparent about it because well they're a company and they have no obligation to non-paying customers etc.
<ekleog>
the thing I still don't like about the rust model is its non-namespacing crates, though :( but npm, pip, stack all do it this way too, so…
<joepie91>
the most recent incident was all package pages on npmjs.com going down, showing what was clearly an internal error due to a backend API being down
<joepie91>
after an hour, still no status page update, no response to tweets, support tickets
<ekleog>
hah
<joepie91>
no acknowledgment that they were even aware of the issue
<joepie91>
this was, what, 2 days ago?
<ekleog>
and noone migrated to another package repository yet? :/
<joepie91>
how would you? it's a network effect problem
<joepie91>
they effectively manage the global namespace of package names
<ekleog>
just add your modules there and remove them from npm? 😇
<joepie91>
and what if somebody creates a module with the same name on npm?
<ekleog>
I guess the problem is it's tightly integrated in all the language tooling
<joepie91>
right
<ekleog>
same problem as most language package managers :(
<ekleog>
(nix!)
<joepie91>
except most language package managers are community-operated :P
<joepie91>
but yeah, this is a serious issue that's going mostly unsolved, unfortunately
<joepie91>
and people get too stuck on varieties of 'this is not like what I'm used to' to work on the actual problems
<ekleog>
well, that doesn't prevent viruses from getting in, etc.
<joepie91>
which is part of why the module-bashing irritates me
<joepie91>
the people who could be fixing this get stuck on things that are either trivial or outright wrong, and the people who don't get stuck on that, also don't have the perspective to fix this :/
<joepie91>
ekleog: sure, but that is generally true for 'open registries'
<ekleog>
I guess one reason is that when you don't review your dependencies, if it's substantial there's more chance someone else will already have reviewed it
<ekleog>
joepie91: namespaced registries ftw
<ekleog>
no longer typosquatting
<joepie91>
hah, my experience is that absolutely nobody reviews anything more than single-purpose
<ekleog>
I don't know of any, though :(
<joepie91>
not unless they're getting paid for it explicitly
<ekleog>
yeah, same…
<joepie91>
leads to fun things like people consistently going "wtf? that can't be right" when you tell them Wordpress still uses MD5
<joepie91>
you'd think that, being one of the most widely deployed pieces of software in existence, that would have been commonly spotted by reviewers by now
<joepie91>
but no, nobody actually does review :P
<joepie91>
and for monolithic things this is understandable to some degree; you're left reviewing a lot of surface that has zero relevance to your usage
<ekleog>
well, there's so many other vulns to wordpress that md5 isn't really the most important one, I guess :°
<joepie91>
that being said, I want better review tooling for JS
<joepie91>
reviewing modular stuff is a lot easier but still a mess if you don't have a way to keep track of what you've reviewed, for example
<joepie91>
the closest thing to large-scale review in JS-land right now is gzemnid
<joepie91>
used for finding common vulnerabilities, measuring usage of particular core features, etc.
<joepie91>
ekleog: have not seen it before, sec
<ekleog>
hmm, Gzemnid is a kind of static analysis tool for JS?
<joepie91>
that looks like it's going to have the PKI/WoT problem
<joepie91>
ekleog: no, it's batch code search
<ekleog>
yeah completely, it's discussed a bit below
<joepie91>
essentially downloads all of npm, and does searches through it
<joepie91>
so if you're wondering "which packages contain text X" then that tool can answer that, so long as it's not obfuscated
<ekleog>
(where I'm advocating for use of the OpenPGP WoT, because to me there's currently nothing better 😇)
<ekleog>
oh, 'k
<joepie91>
I've been working on a code analysis variant of this myself, but gzemnid is just text/ast search
<joepie91>
anyway, what that review thing misses is local review tooling
<joepie91>
ie. reviewing deps yourself locally without cooperation from the maintainers and tracking reviewed versions and whatnot
<ekleog>
yeah, that's orthogonal though I guess
<joepie91>
I *do* actually want to review all of my deps :P
<ekleog>
woo \o/
<joepie91>
but right now I have no good way to track the progress of that
* ekleog
has too much to do to take the time for all the deps
<joepie91>
shrug
<joepie91>
the way I look at it, reviewing deps is consistently faster *and* more educational than writing equivalent implementations yourself
<joepie91>
so given that I want to understand how my application works, 'review everything' is the obvious net positive choice
<ekleog>
oh, completely, I usually just use deps and don't care about unreviewed deps though (well, I mostly depend on well-used crates, as I'm doing “core” stuff)
<joepie91>
I'm not _yet_ reviewing all my deps due to aforementioned issues
<joepie91>
right now I focus on fragile/sketchy/etc. stuff
<joepie91>
eg. if a module claims to solve a difficult problem, you bet I'm going to have a look at how
<joepie91>
:p
<ekleog>
gotcha :)
<ekleog>
I personally skim the documentation to get an idea of how it works, without looking at the details
<joepie91>
I always do that
<ekleog>
(like, futures executors, for the thing that currently hold me)
<joepie91>
I also have a strict no-copy-pasting policy :)
<joepie91>
so reading documentation is the only way for me to use a module
<ekleog>
hmm when the documentation has a code example I often end up copying it, though, because that's the only way to do what I want :°
<joepie91>
right, I definitely don't do that
<joepie91>
I find that an unconditional no-copy-pasting policy helps me much better understand what's going on
<joepie91>
forces me to understand every thing I write
<joepie91>
(it's also something I teach my tutoring students, for the same reason :P)
<ekleog>
oh, it's not copy-pasting, only copying
<ekleog>
(however, no copying without having read the documentation of each copied method)
<ekleog>
(and understood it obv.)
<joepie91>
I still type it out manually, just as a safeguard to make myself go 'wait, why am I typing that'
<joepie91>
I've found it too easy to conclude 'I understand that' when I don't yet, otherwise, and I've seen the same in other people
<joepie91>
unpopular opinion: I don't actually think namespaced registries really help all that much
<joepie91>
if at all
<joepie91>
it doesn't help for preventing naming conflicts because namespaces aren't how people talk about libraries; they just name the library, not the author
<joepie91>
so if you want to prevent confusion in conversations / google searches / etc. you still need a globally unique name
<ekleog>
well, yes and no
<joepie91>
and it doesn't help for preventing typosquatting because now you just typosquat the namespace name
<joepie91>
instead of the package name
<ekleog>
like, if you want to call your module “smtp”, it can be ok
<joepie91>
(after all, there is no conflict on the package name anymore so you can just use that)
<ekleog>
the advantage of typosquats on namespace name is that it can be auto-detected and blocked
<ekleog>
while on package names, too many packages may reasonably bear close names
<joepie91>
that's not really a realistic issue, though
<ekleog>
typosquatting? it's been shown to be done in practice, iirc
<joepie91>
namespaces can clash just as easily because they are often named after the projects themselves
<joepie91>
and typosquatting prevention often requires human intervention anyway
<joepie91>
no, typosquatting is absolutely realistic
<joepie91>
what's not realistic is 'closeness of names' as a problem
<ekleog>
I think (personal opinion) that blocking all names to levenshtein-1 of existing namespace names wouldn't trigger outrage
<joepie91>
you can write pretty effective algorithms based on letter proximity on eg. common keyboard layouts, and have a human-review fallback for anything that's otherwise close
<ekleog>
maybe levenshtein-2 would be OK too, but I don't think it'd be useful
<joepie91>
and this is in fact being done on eg. npm
<joepie91>
(but not until after a lot of prodding, and I'm not convinced that their implementation is optimal)
<joepie91>
the prodding has been ongoing for longer than that :)
<ekleog>
'k :)
<joepie91>
ekleog: most of the security features npm has been introducing recently, are features that behind the scenes, people have been yelling at npm about for at least two years
<joepie91>
it's like pulling teeth
<ekleog>
well, isn't it the same for all security features?
<ekleog>
like, RFC 5
<joepie91>
ekleog: there are people who implement security features proactively :P
<ekleog>
too few :(
<MichaelRaskin>
HTTP and SMTP are Levenstein-2 from each other, right?
<ekleog>
MichaelRaskin: yeah, but I don't think http and smtp should be used as namespace names but as package names, so that wouldn't be a big deal :)
<ekleog>
(then, I said levenshtein-1 was likely enough 😇)
* ekleog
retreat to last line of defence
<ekleog>
then, the primary use case I'd see for namespaced package repository would be for the “crate constellations” of rust, like serde, which could have `serde/*`, while currently it's `serde-*` with some serde-* that are not actually developed by serde developers, but developed by other people
<ekleog>
so that wouldn't be for typosquatting indeed
ma27 has joined #nixos-chat
<joepie91>
ekleog: npm already has scopes
<joepie91>
:P
<joepie91>
they are just optionakl
<ekleog>
huh?
<joepie91>
optional*
<MichaelRaskin>
Sooner or later you just go assign UUIDs and enforce that people can only copy UUID from a page with name, description and author list
<joepie91>
@foo/bar
<ekleog>
oh, didn't know about that
<joepie91>
I think angular uses them?
<ekleog>
MichaelRaskin: this actually sounds good :°
<ekleog>
don't know for recent angular, I was using angular 1 at the time (also, I didn't actively touch the package manager stuff, just did the minimum js I could do to test the backend I was developing)
<joepie91>
I've been studiously avoiding angular for the past several years
<joepie91>
I used Angular 1 back when it was basically the only option in its class, and it broke a bunch of new ground but it was never very well-designed
<joepie91>
Angular 2 came to the party way too late, with React already having eaten its lunch
<joepie91>
and there's Polymer but I'm not sure anybody other than Google and its fanboys are really taking it seriously
<joepie91>
which is kind of understandable given its heavy focus on WebComponents which turned out to be a bit of an ergonomic nightmare
<joepie91>
its main selling point right now seems to be "comes with Material Design elements!" and well, that's not really a selling point for anybody who knows their UX :P
<ekleog>
tbh, all JS code I've done always felt not well-designed, but I guess I just always fell on monolithic frameworks :)
<joepie91>
likely
<joepie91>
there are a few major monolithic options in JS... Angular, Meteor, Sails, etc.
<ekleog>
(“always” being “2+ years ago”, too, haven't done any js since then I think)
<joepie91>
every single one of them is poorly designed
<ekleog>
and now if I do a website I'll likely do it in Rust/WASM
<joepie91>
Meteor and Sails in particular try to be the 'magic' option
* ekleog
fell in love ❤️
<joepie91>
and like all magic solutions, magic eventually fails and good fucking luck fixing it :P
<ekleog>
yeah ^^
<joepie91>
Angular is just...
<joepie91>
Angular 2+ is like, kind of trying to be a modular thing like React, but also kind of trying to remain the Java-esque monster that Google likes so much
<joepie91>
and it doesn't combine particularly well
<joepie91>
and there's not really any reason to use it over React?
<joepie91>
it's just weird, it feels to me like Angular 2+ never really had any merit and just existed because well, Google at one point promised that it would, and they can't give up now
<joepie91>
sunkcost.js and all that
<joepie91>
it's not like it extends the life of Angular 1 applications either because 1 and 2 are totally incompatible
<joepie91>
so... ¯\_(ツ)_/¯?
__Sander__ has joined #nixos-chat
<MichaelRaskin>
joepie91: Google cannot give up on their promises of product existence? That's a novel situation
tertle||eltret has quit [Quit: Connection closed for inactivity]
<joepie91>
MichaelRaskin: developers are a lot more demanding than consumers ;) and unlike with consumers, google actually has a reason to keep developers happy
<joepie91>
ekleog: thanks! looks like a readable paper, for a change, from a glance :)
* joepie91
gets really annoyed by the totally unnecessary impenetrability of many compsci-related papers
lassulus has quit [Ping timeout: 256 seconds]
lassulus has joined #nixos-chat
<ekleog>
tbh, I'm not sure it'll change anything in your reasoning, but if you do change your mind after reading it I'd love to know in which way, I may have missed something in reading it :)
mmercier has joined #nixos-chat
__monty__ has joined #nixos-chat
<joepie91>
ekleog: heh, it's on my reading list
<joepie91>
currently I'm busy with code review
<joepie91>
$work
<joepie91>
things that actually earn me money
<joepie91>
lol
<ekleog>
heh ^^
<joepie91>
not like somebody's going to pay me for writing a runtime typing/validation system for JS...
<ivan>
Closure Compiler had a pass to do that a decade ago
<makefu>
this is some really creepy shit. looks like someone thought "hey! i like bash but i want to do more with it than just using it for things it was intended for!" when you do stuff like that in your shell scripts then you should probably use another programming language
<gchristensen>
+1
<gchristensen>
I don't like bash, I don't like to use bash
<MichaelRaskin>
Still better language than PHP
<gchristensen>
haha
<__monty__>
Then why does nix-shell use bash? : p
<makefu>
very low bar
<gchristensen>
nice to see you, MichaelRaskin!
<gchristensen>
a lot of stuff I happen to do, though, is in bootstrapping where there is no Nix and it is hard to depend on something other than shell
<__monty__>
Are there worse languages than PHP? Even turing tarpits are amusing at least.
<Drakonis>
you ain't seen enough until you saw the bash opengl repl
<MichaelRaskin>
_I_ actually like POSIX Shell
<gchristensen>
I can appreciate PHP for things
<samueldr>
posix shell is fine
<makefu>
i also think posix shell has its place. random old computer will most likely have a posix shell. with that you can work already
<MichaelRaskin>
Parts of PHP scaffolding are nice. You can _probably_ cut out a subset of language that would be almost OK-ish. PHP the language is …
<gchristensen>
a product of its time and improving substantially!
<MichaelRaskin>
Not sure what has happenned is an improvement
<gchristensen>
for example, they're working hard to get rid of the crappy old stuff and move to better semantics
<gchristensen>
"The main challenge in porting to bash 3 lays with creating a polyfill for associative arrays (probably by using every other index for the keys in an array), which are used by the type system." my
<MichaelRaskin>
Given that two rounds of breaking change have not been enough for getting to semantics that makes sense…
<MichaelRaskin>
Heeheehee
<gchristensen>
they've managed to make serious upgrades to the language without creating a python2/3 scenario, and I think that is really commendable
<samueldr>
that would be great development, but woah does working with real-life php is a road to pain; when even the well-known framework is half-assed :/
<MichaelRaskin>
I dunno, maybe I cannot help counting the breaking changes in PHP since learning about ./+ concatenation change (the hard way)
<samueldr>
concatenation change?
<samueldr>
(I haven't kept up with actual changes since earlier this decade when I was a user)
<MichaelRaskin>
At some point in the PHP history string operation concatenation has changed the operator symbol.
<MichaelRaskin>
I think it was between PHP2 and PHP4
<samueldr>
ah, I see, I thought about the way you ordered it, dot to plus and it confused me
<MichaelRaskin>
I am no longer sure what was the direction of change
<MichaelRaskin>
I just remember it was surprising
<__Sander__>
PHP haha
<gchristensen>
I see you, __Sander__, with your composer2nix code :P
mmercier has quit [Remote host closed the connection]
<jD91mZM2>
It certainly is something I can see the usecase of. I'm sure a lot of people will use this for their applications to ease development. /s
__Sander__ has quit [Quit: Konversation terminated!]
<LnL>
interesting, but... why? :p
<gchristensen>
science, evidently :)
<LnL>
add something that causes it to panic 1% of the time, I bet you'll get an issue from somebody that their production binary fails sometimes in a couple of months
<MichaelRaskin>
Evil plotting raccoon is plotting: the great work done by @oxij w.r.t. triaging the upstream package tests creates a clear case that single packages need run-in-X and run-with-DBus checkInputs. Then, once enough packages depend on these for the checkPhase, we can add automated GUI tests using the same DBus/X wrapper
tertle||eltret has joined #nixos-chat
<gchristensen>
evil plotting raccoon is persistent
<gchristensen>
I will note, though, it is good to keep in mind the overall agenda of evil plotting raccoon when reviewing their PRs
<MichaelRaskin>
Which is why the evil plotting raccoon will just direct push «Fixing a few package testsuites» to master
<gchristensen>
I thought E.P.R. was oxij
<MichaelRaskin>
Nope, Jan is definitely not _plotting_ anything
<gchristensen>
they lack tact for sure
<MichaelRaskin>
That's another story.
<gchristensen>
^.^
snajpa has joined #nixos-chat
<MichaelRaskin>
(Unfortunately, I cannot credibly deny that another story's connection to reality)
<gchristensen>
(I can't quite understand that sentence, but that is okay)
<samueldr>
IIRC MichaelRaskin you had that crazy setup with a bunch of lisp, and was preparing a talk or a paper about it, anything new with regards to that?
<samueldr>
(crazy here isn't pejorative)
<MichaelRaskin>
Well, I failed to get that accepted at ELS. Did do a 5-minute lightning talk about that
<gchristensen>
ahh bummer :(
<gchristensen>
I was looking forward to that too
<MichaelRaskin>
I do default to recognise a few epithets (including crazy) as objective classifications unless negativity is unambiguous
<samueldr>
crazy plotting raccoon :)
<MichaelRaskin>
And the system itself… well, I kind of don't do much with it, because I haven't had enough free energy for big things since at least spring, and it doesn't ask for too many small things
<MichaelRaskin>
I did advance a bit on the browsing part, now my scripts leak less Firefoxes because some fetching has been moved in a Lisp process
<MichaelRaskin>
(Yes, I have a script that leaks memory by leaking Firefox instances)
<samueldr>
"leaking firefox" definitely is crazy :)
<MichaelRaskin>
Leaking _one_ Firefox would indeed be strange, leaking Firefox instances is relatively natural if you start by isolating everything into separate instances
<gchristensen>
ok so I wrote in this requirements document I won't write it in bash. is writing it in `expect` any better? =)
<MichaelRaskin>
Mwahaha
<MichaelRaskin>
Actually, if you like TCL better than Bash, then yes
<LnL>
gchristensen: dunno if you can consider tcl better than bash
<gchristensen>
me either :(
<LnL>
not that it does much but there's a bash testing library