Synthetica has quit [Quit: Connection closed for inactivity]
<clever>
Ericson2314: the release.nix should already be in the nix store, and every input must be declared with `-I inputname=/nix/store/hash-inputname`
fpletz has joined #nixos-dev
<Ericson2314>
clever: ah, already in the nix store
<clever>
Ericson2314: you can cheese it with `-I .`, but `src = ./foo` can break that
fpletz has joined #nixos-dev
fpletz has quit [Changing host]
<Ericson2314>
hehe
<Ericson2314>
i have no inputs in this case
<Ericson2314>
so that helps
<Ericson2314>
clever: what's the builtin to stick a thing in the store?
<LnL>
I think hydra does both -I input=path and --arg input=path
<clever>
Ericson2314: nix-store --add-fixed i think
<Ericson2314>
thanks
<clever>
LnL: yep, but only the -I plays a role in fixing the restricted mode stuff, i think
<clever>
LnL: the --arg stuff, also passes a set with git rev in it
<LnL>
ah yeah
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 240 seconds]
drakonis has quit [Read error: Connection reset by peer]
<Ericson2314>
clever: hmm it is now complaining about a fetchTarball with a sha256 argument
<Ericson2314>
that seems odd?
<Ericson2314>
this is reflex-platform, which I we to CI with hydra
<clever>
Ericson2314: is allowed-urls set in nix.conf?
<Ericson2314>
clever: nope
<Ericson2314>
I am just running the command on my own machine
<clever>
Ericson2314: let me double-check the src...
<Ericson2314>
I am trying to basically in a non-hydra CI "do what hydra would do" to recover the nested jobs
<clever>
2133 if (evalSettings.pureEval && !expectedHash)
<clever>
2134 throw Error("in pure evaluation mode, '%s' requires a 'sha256' argument", who);
<Ericson2314>
which btw matt figured out nix-env -qaP would do, except that doesn't work for lambdas with default args
<clever>
infinisil: did you `git checkout FETCH_HEAD` before looking at the history?
<infinisil>
Yup
<infinisil>
I mean you should be able to replicate
<clever>
when i run the cmds, i get the expected output
<infinisil>
Between what commits is your merge?
<clever>
the 2 parents i pasted
<infinisil>
Ohh lol
<infinisil>
I picked the wrong pr
<infinisil>
I posted two above, I used the second one
<infinisil>
Whoops
<clever>
that explains it
<infinisil>
I blame the numbers looking very similar
<gchristensen>
btw I brought up a third evaluator to work through the ofborg backlog
<gchristensen>
right now ofborg's evaluator runs on 2 very-expensive-for-what-they-are VMs. the third machine I just brought up is a fancier bit of hardware, and should perform better than the two VMs
<clever>
gchristensen: how expensive is hydra-eval-jobs for the current nixpkgs release.nix? would it be feasible for ofborg to run that?
<gchristensen>
I think it is pretty much the same thing we already do
<gchristensen>
I think it is pretty much the same thing ofborg already dooes
<clever>
basically, it will recursively eval every attribute in release.nix, and generate json describing the results
<clever>
and it restarts itself at regular intervals to keep the heap usage under control
<clever>
main reason i think of it, is because i can see value in testing it with the exact code hydra tests it with
<clever>
a lack of such testing, nearly bricked the entire tesla car fleet :P
<clever>
there was a json blob, listing every supercharger, and a CI system that ensured the json was valid
<clever>
but, the car software parsed the json with a different library, which segfaulted
<clever>
and crashing in that area, causes a reboot of the entire control system
<gchristensen>
cool cool cool very cool
<gchristensen>
definitely good
<clever>
and its a boot loop, so the updater cant fix things
<clever>
2020-01-06 20:46:00 < Ericson2314> I am trying to basically in a non-hydra CI "do what hydra would do" to recover the nested jobs
<clever>
2020-01-06 20:46:36 < Ericson2314> which btw matt figured out nix-env -qaP would do, except that doesn't work for lambdas with default args
<clever>
gchristensen: and there can be subtle differences between nix-env -qaP and hydra-eval-jobs that you could easily overlook
<gchristensen>
oh?
<gchristensen>
I use nix-instantiate and nix-env -qaP
<clever>
nix-env/nix-build/nix-instantiate, will auto-call any function they encounter
<gchristensen>
yeah
<clever>
i dont believe hydra-eval-jobs will do that
<gchristensen>
that is something we want to test in hydra
<gchristensen>
or at least, in ofborg
<gchristensen>
because we want to replicate the user's experience of using nix-env
<clever>
ah
<Ericson2314>
It will at least auto-call the outer one
<tilpner>
lovesegfault: Did you bring up xz -> std because of the arch-announce mail I just now saw? .8% size increase sounds pretty acceptable, I expected more
<jtojnar>
infinisil yeah, anchors=<a name="foo" /> in HTML terms
<jtojnar>
infinisil by automatic labels I meant things like <xref linkend="sec-language-gnome" />
<jtojnar>
which produces Section 15.7, “GNOME”
orivej has joined #nixos-dev
drakonis_ has quit [Ping timeout: 260 seconds]
drakonis_ has joined #nixos-dev
<jtojnar>
I am conflicted about asciidoc, it offers the good features of docbook but packages them in much less easy to use heterogenous syntax and adds misfeatures like role=green or table column width on top 😥️
<jtojnar>
did not we learn already that separation of form from content is a good thing? Is there semantic mode in asciidoctor that would disallow things like role=green, or would we need to write our own filter
<michaelpj>
the more I learn about asciidoc the less I like it
<michaelpj>
the toolchain isn't that great either (source: spent a looooong time getting asciidoc->epub to work)
<michaelpj>
inter-file links are disappointingly half-baked too
<jtojnar>
infinisil also it would be nice to be able to specify annotations à la ATerm for things like marking properties locked (not overridable in user’s local database) but perhaps that is out of scope for RFC0042
<michaelpj>
my fundamental criticism of asciidoc is that it's leaned hard into "it's just a stream processor", so it has no real document model that it can analyze, hence why inter-file links are dodgy and why the epub converter is just all appalling hacks under the hood
<jtojnar>
infinisil would it be possible to handle the attrset-based types in the custom writers you mention?
<infinisil>
Not sure what you mean
evanjs has joined #nixos-dev
<jtojnar>
infinisil representing non-Nix types as { _type = ...; _content = ...; } and having the custom writer handle it
<infinisil>
Ah
<infinisil>
Yeah it's not impossible, but there needs to be a way for constructing these
<infinisil>
And this might be different for each service, so putting these in lib. might not be appropriate
<infinisil>
And people need to know about them, it won't be as natural as just assigning a native nix value
<infinisil>
domenkozar[m]: Regarding rfc 64, you mean you don't want a public poll to decide on the doc format?
<domenkozar[m]>
it's not that I don't want, it's more like I don't think that's going be actionable and representing
<domenkozar[m]>
maybe if we want to see what format people would like to write documentation in, but I'm not sure that's a good benchmark since not everyone will contribute docs
<infinisil>
It's not only about writing docs, but also reading them
<infinisil>
And a goal of this is to make writing docs easier too and more approachable
<infinisil>
And because of this i think it's very important to involve the community in this decision, the shepherd team is only a very small elite fraction of the people that will be influenced by this decision
<gchristensen>
that is always true about 100% of RFCs
<infinisil>
gchristensen: I don't think so
<domenkozar[m]>
I agree, if the poll is framed as "which format you'd be most comfortable writing docs in"
<domenkozar[m]>
that can be as one of the inputs for RFC resolution
<domenkozar[m]>
but I don't expect for drive-by contributors to have a well-informed opinion as it takes quite some involvement and mostly practice
<infinisil>
domenkozar[m]: If it would be possible to involve many people in the RFC discussion and collect stats on opinions through them, then yes that would be good
<infinisil>
However RFC discussions die down quickly to a couple core members having a strong opinion about it
<domenkozar[m]>
(not to dismiss anyone's opinion, but I think the value of community is exactly that we do have different backgrounds and skills)
<domenkozar[m]>
infinisil: I agree about that and not sure what to really do about it
<domenkozar[m]>
I was happy to see Jonas be more positive :)
<domenkozar[m]>
anyway, I think the focus should be on requirements
<domenkozar[m]>
afaik eelco hasn't given them, except for what format he likes :)
<infinisil>
domenkozar[m]: People not having strong opinions or being uninformed can also be a positive for the poll: If people know format X already then it's totally reasonable for them to agree to use X, even without knowing the other formats
<infinisil>
Everything else would involve more work for them, to learn it and such, and the same thing will be reflected with everybody writing docs in the future
<FRidh>
infinisil: that depends on how you weigh matters
<gchristensen>
if you want a race to the bottom, just pick markdown already! :)
<domenkozar[m]>
it's really hard to judge this things, I strongly believe anyone can learn any format
<domenkozar[m]>
so I give more weight to tooling
<FRidh>
if they would pick whatever they are comfortable with, then we would never be using nix either
<gchristensen>
domenkozar[m]: I agree as long as the experiment cycle time is super low, you can learn by failure
<infinisil>
Not arguing about that, but people are lazy and don't want to learn new stuff if they can get around with stuff they know already
<FRidh>
true
<FRidh>
so how much laziness do we accept
<infinisil>
Well everybody is familiar with Nix already, soo, who knows!
<infinisil>
(though not with a potential doc EDSL)
<domenkozar[m]>
so the vote can be independent of RFC and can serve as input for shepherding team
<FRidh>
that I would prefer as well. Make it a small survey
<__monty__>
infinisil: That still syphons votes away from actual potential candidates. It's a phallacy that's regularly abused by politicians : )
<infinisil>
__monty__: Not getting what you mean
<__monty__>
Including markdown as a candidate for example.
<__monty__>
That'll pull tons of votes away from formats that might actually work.
<infinisil>
I guess, but that's just how polls work
<__monty__>
It's not how they have to work.
<gchristensen>
it isn't clear to me that a poll is the appropriate tool anyway
<infinisil>
__monty__: Hm, I guess with a poll where each option is shown in sequence, without seeing all of them at once, might be better
<__monty__>
Not really.
<infinisil>
Okay then tell me how it's done better
<__monty__>
Evaluate every option on technical merrit. Then have a popular vote if multiple formats serve the problem equally well.
<infinisil>
And how do you evaluate options? With a poll? xD
<FRidh>
technical merrit alone is not sufficient. Sometimes things are technically not the best choice, but they are acceptable when considering other aspects as well.
<__monty__>
FRidh: If they serve well enough then they're an option. I'm not talking about selecting what is technically the best solution.
<michaelpj>
the poll is proposed to use approval voting, right? so having a popular option doesn't necessarily pull votes *away* from others
<__monty__>
I'm not even excluding "Format X would work if we invested Y effort in the tooling."
<infinisil>
michaelpj: Yeah that's the idea
<__monty__>
Some people will only vote markdown because it's what they like. They won't look at other options that might actually support what the project needs.
FRidh has quit [Quit: Konversation terminated!]
FRidh has joined #nixos-dev
<infinisil>
The post can start with short introductions and overviews of each format, telling people they shouldn't vote without taking a look
<gchristensen>
and at the end of it, the shepherd team should read the results of the poll and ignore its final total
<infinisil>
The total is the result though?
<gchristensen>
right
<infinisil>
If the result is ignored then the poll won't have a purpose
<gchristensen>
well, I guess I agree with domenkozar[m] that the results of the poll should be an input to the shepeherd team's decision
<gchristensen>
I will write this on the RFC later, but I have a strong objection to the outcome of a poll being binding
<__monty__>
infinisil: You're proposing for the result to be semi-ignored though. Because you're proposing for evaluation to happen *after* voting. If they knew some of the listed options were basically placeholders they might have voted differently.
<infinisil>
__monty__: Only *another* evaluation. We first do a quick evaluation to eliminate candidates, then vote, then spend time and effort for implementing the winner. If it turns out something doesn't work, then the second one is chosen
<infinisil>
Not sure what you mean with placeholders
<__monty__>
infinisil: The ranking of such a poll would only have the proper order if a "vote" was a ranking according to preference for each voter. Otherwise there's no guarantee that the ranking is still valid if you eliminate an option.
<__monty__>
I guess I was mistaken but I assumed that all the options listed in the RFC would appear in the vote.
<infinisil>
As said, it's a multiple-choice poll, so it is essentially a ranking, just with a scale from 0 to 1. qyliss recently linked to https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem, but it doesn't apply in this case because of it being multiple-choice
<__monty__>
Even with multiple choice. People may decide to only choose 1 option to put more weight behind their vote. If that option is eventually eliminated most of them would probably have preferred to put that vote into their runner-up.
<infinisil>
Ah yeah no the RFC currently just lists some potential candidates, ones that are infeasible won't be included in the poll :)
<infinisil>
__monty__: Hm that is an argument. But on the other hand if people vote for only X, but X doesn't get chosen, they essentially lost their vote, so they may want to vote for multiple ones after all according to their preferences.
<infinisil>
Anyways, I think this is good enough for such a decision, doesn't have to be perfect, nothing is after all
<__monty__>
Yeah, what I'd do is have everyone rank the options. Then they automatically "vote" for their runner-up if their first preference is discarded. Without having to revote every time you discard an option.
<infinisil>
That suffers from the above wiki link though
<infinisil>
And discourse doesn't support that :)
<__monty__>
Sure, it's not perfect. It's better than having to take a vote N times where N is the number of times an option is discarded.
<__monty__>
I guess what I had in mind is between cardinal and ordinal voting. If there's 10 options I'd have people assign the numbers 10 through 1 to each of them. However, they're allowed to use numbers multiple times but only favoring the lower numbers, i.e., 10,9,3..3,2,1 would be a valid assignment of numbers. (This makes things fairer I believe because the total sum, hence power, of your vote is
<__monty__>
diminished in return for tipping the balance more.)
<__monty__>
Disclaimer: I haven't actually studied anything relating to voting, this may be horrendously flawed.
<infinisil>
__monty__: Sounds like standard cardinal voting, just with numbers 1-10 instead of 0-1
<__monty__>
Not really. Cardinal voting doesn't have the limiting. You can vote 10 across the board afaik.
<__monty__>
But that gives more weight to someone who's naturally inclined to rate things higher.
<infinisil>
Oh i missed the part about limiting higher numbers
<infinisil>
__monty__: Could limit it to a maximum total
<__monty__>
Then you get the degenerate case where people vote max, 0..0, to increase the weight of their vote : )
<gchristensen>
~are we sure a poll is the best option~
<__monty__>
Depends on the goal.
<gchristensen>
have documentation which is easy to contribute to with tooling to support multiple pages and search
<__monty__>
That's not *a* goal. That's a complex amalgamation of goals : )
<gchristensen>
how can you say that? it is my goal!
<gchristensen>
all the other stuff is just details
kenjis has quit [Remote host closed the connection]
<__monty__>
Imo, priority should be ease of contribution to the docs. *But* the options should first be evaluated to see if maintenance is practical and they have the desired features, your multiple pages and search and whatnot.
<gchristensen>
multiple pages is an absolute requirement, and having multiple pages means search is an absolute requirement
<gchristensen>
single-page docs don't work because they are not indexed by search engines
<__monty__>
And for ease of contribution a simple popular vote seems like the best way. I know the population of voters and people who might actually contribute docs doesn't align 100% but it's the best representation we have.
<gchristensen>
cool
<__monty__>
Clearly what needs to happen is we have to implement a smart contract blockchain to determine the correct voting procedures so we can decide on what format we want to use and coincidentally define the parameters of the development work that will be required. This transparent cash grab will naturally pay for the consulting company we hire to realize all this work. : )
<gchristensen>
oh man now you're talking
<gchristensen>
we can use the raised funds to pay a technical writer to improve our information architecture
<__monty__>
In all seriousness I've started thinking the real solution's going to be dedicated manhours of editing. People contribute plain text and the editors actually do the formatting in whatever technical format is actually sufficient. : s
<andi->
my 2 cents: nixdoc. Just invent the correct language and tooling.
<andi->
(obviously not serious)
<gchristensen>
€0.000000002
<infinisil>
andi-: I do like the idea of an edsl in nix, would make many things easy
<gchristensen>
"The euro currency sign was designed to be similar in structure to the old sign for the European Currency Unit (encoded as U+20A0 ₠ ). There were originally 32 proposals; these were reduced to ten candidates. These ten were put to a public survey. After the survey had narrowed the original ten proposals down to two, it was up to the European Commission to choose the final design. The other
<gchristensen>
designs that were considered are not available for the public to view, nor is any information regarding the designers available for public query. The European Commission considers the process of designing to have been internal and keeps these records secret."
<michaelpj>
__monty__: approval voting is a pretty standard cardinal voting system that's generally considered to be one of the best ones. Let's not invent our own voting system, that's notoriously hard
<__monty__>
michaelpj: That only works if the outcome isn't revised though : )
<__monty__>
And it's clearly not ad-hoc enough ; )
<michaelpj>
__monty__: it's not totally obvious, but I'd expect approval voting to still be pretty good if you remove some options later. Maybe it slightly changes the tactical voting (Gibbard–Satterthwaite still applies), but the same would be true for any system :)
<qyliss>
I'm concerned that who makes it onto the shepherd team (which is somewhat arbitrary?) could make a huge difference to the outcome of the RFC
<qyliss>
The only fair way to do it would be to make sure that there was a shepherd from each major camp, and then we'll just never get a decision.
<gchristensen>
I think the best way to move forward is for everybody to be in the "docs need to be better" camp
<qyliss>
gchristensen: what do you mean by single-page docs not being indexed? I frequently am pointed to the WeeChat user manual, which is one big web page, when I do a web search for whatever WeeChat question I have
<qyliss>
I'm not sure anybody is not in the "docs need to be better" camp, but within that are these sub-camps
<qyliss>
And at this point I'm sceptical that people will be convinced to change their mind or even compromise, especially because there's so little room for compromise
<gchristensen>
the nixpkgs and nixos docs are so large google's website administatrion toolbox thingy says they don't index them anymore -- domenkozar[m] knows more
<qyliss>
yikes that's good to know
<gchristensen>
I think that when it comes down to it, the shepherds will recognize their obligation to fulfill their duties of deciding based on the quality of the RFC, the feedback of the community, and set aside their own prejudices and preferences
<gchristensen>
and recognize their job is to accomplish the greater goal of "docs need to be better"
<qyliss>
I'd hope so, but it's not an easy thing to do
<gchristensen>
I think I've seen it happen in almost every RFC shepherd meeting I've been in
<gchristensen>
so I am hopeful and optimistic
<qyliss>
I'm still wondering about "docs can be in any reasonable format"
<qyliss>
I'm not sure there's any reason building a system should need to generate the full manual
<qyliss>
And the very least there should be an option to disable installing the manual, if there isn't already.
<gchristensen>
there is
<qyliss>
And it may even be better to disable the manual by default
<qyliss>
I doubt many people are actually using their built-in manual rather than doing a web search
<michaelpj>
it's extremely useful when you've accidentally broken your networking
<michaelpj>
which also tends to make rebuilding with the manual enabled a little tricky
<qyliss>
You could also have a package that's a recent manual for your channel from hydra or whatever
<jtojnar>
I keep recommending `man configuration.nix` at every opportunity
<__monty__>
It's also weird to say "Nix can build the most complex of software. *Except* its own documentation *that* is a special-case that *is* too complex."
<qyliss>
it's not that it's too complex, but that's it's inconvinient
<gchristensen>
that isn't what qyliss is saying
<qyliss>
just because it can doesn't mean it should do it on every rebuild
<qyliss>
And with that out of the way, we can use pandoc or whatever
<qyliss>
And then the community can vote with its feet when people document new modules or packages
<michaelpj>
how do inter-file links work if you have multiple documentation formats?
<qyliss>
If at some point 90% of the documentation is in Markdown, let's say at that point "okay, Markdown it is"
<gchristensen>
I'm not sure documentation formats is the right time for the "let a thousand flowers bloom" philosophy
<__monty__>
Pandoc's very limited in its processing of anything but markdown as well.
<michaelpj>
^^^ this is true
<qyliss>
Doesn't have to be just pandoc
<qyliss>
Otherwise, we have to try to make a decision about what's best for the documentation with no data to back it up
<gchristensen>
I'm not sure documentation formats is the right time for the "let (a thousand flowers) * (a thousand farms) bloom" philosophy
<qyliss>
("Markdown is the most popular on GitHub" doesn't count as data)
<__monty__>
And I agree rebuilding documentation on *every* rebuild would be annoying. Surely it's only rebuilt if the docs changed? And if not, fixing that sounds like a more useful/important change than moving to a "there's a sorta recent version of docs in package X."
<michaelpj>
isn't "making a decision in the absence of sufficient empirical data" precisely what expert deliberation processes like RFCs are for?
<qyliss>
Yes, but it's still a lot easier if you have data
<qyliss>
As an alternative, then, what if we had people produce example manuals from Markdown, and AsciiDoctor, and whatever else?
<gchristensen>
yes that is what I have been wanting
<qyliss>
We would then at least have a point of reference to compare like for like
<qyliss>
Doesn't have to be the whole manual, but a few representative sections.
<__monty__>
I think it's what everyone would want but it's also a very non-insignificant amount of effort.
<qyliss>
Is it?
<gchristensen>
however much effort it is, it seems worth it
<qyliss>
I'd say in a few hours I could have a little demo AsciiDoctor manual with a few translated sections of the NixOS manual, showing the relevant features
<__monty__>
It requires setting up the entire toolchain for one.
<gchristensen>
sure
<gchristensen>
if we think a tool might work, we should probably have actually used it before agreeing to move to it
<michaelpj>
it's also a great exercise for the proponents to go "oh it turns out that this widely used feature is actually a pain in my preferred toolchain"
<qyliss>
Thus giving appropriate advantage to simple toolchains, deservedly I'd say
<__monty__>
qyliss: With seperate pages, search, inter/intra document links?
<qyliss>
idk about search but otherwise, sure
<qyliss>
that's one of the big advantages I see to AsciiDoctor. It's a semi-integrated solution for this sort of thing.
<gchristensen>
I agree
<__monty__>
Except it doesn't support Epub very well.
<__monty__>
If that's a set-in-stone requirement.
<qyliss>
since when did we require epub???
<qyliss>
do we currently support epub?
<__monty__>
It's in the RFC.
<__monty__>
And yes.
<gchristensen>
asciidoctor can convert to docbook which can convert to epub, no worries
<__monty__>
gchristensen: Did you look at michaelpj's issues? It's clearly far from such a simple story.
<michaelpj>
I experienced a lot of suffering trying to make that work, but I guess if we've already got the docbook->epub bit working it's probably not too bad
<michaelpj>
my opinion is only that the asciidoc->epub direct story sucks
<gchristensen>
I hear you, {^_^}, I know the channel updates is being annoying. We're trying <3
<__monty__>
Then we need to clarify in the RFC that formats don't need to be able to target epub if they have good docbook producing support. That can't be an advantage only asciidoc enjoys.
<qyliss>
docbook can be converted to everything, which is a nice feature of asciidoctor too
<__monty__>
And markdown if pandoc's acceptable : )
<gchristensen>
it is always easier to go from a higher abstraction to a lower one :P
<qyliss>
__monty__: targeting epub via whatever other format or chain of formats still counts as targeting epub unless you're taking pedantry to the point of unhelpfulness
<__monty__>
qyliss: Yeah but that may not be obvious to proponents of the other formats. The RFC says epub needs to be an output format. It doesn't say, "We'll maintain the current docbook infrastructure (which this RFC wants to get rid of) just to support format->docbook->epud in case the format doesn't support epub directly."
<gchristensen>
you're putting words in to a lot of mouths, __monty__ :)
<__monty__>
Am I?
<gchristensen>
using libxml to translate docbook to epub is not "We'll maintain the current docbook infrastructure (which this RFC wants to get rid of) just to support format->docbook->epud in case the format doesn't support epub directly."
<__monty__>
Is libxml the current infrastructure used to convert docbook to epub?
<infinisil>
__monty__: I didn't put epub in the RFC iirc
<__monty__>
infinisil: It's come up in the discussion at least.
<qyliss>
are people actually reading the documentation as epub??
<infinisil>
I don't think it should be a requirement, but a nice-to-have
<qyliss>
sure, yeah
<infinisil>
qyliss: Haven't seen anybody do that
kenjis has joined #nixos-dev
<qyliss>
I'd love GNU Info support, but I'm not going to suggest we _need_ it.
<gchristensen>
I surely have
<gchristensen>
but I agree, not sure we need it
<gchristensen>
and again, using a docbook output to translate to epub is not a big lift
<qyliss>
(Docbook -> Info with Pandoc works pretty well also)
<qyliss>
I think we may find as part of this process that a lot of Docbook is actually very desirable
<__monty__>
infinisil: Weren't you the one that said epub had actually been requested before, while you hadn't seen anyone request a pdf?
<gchristensen>
qyliss: it surely is
<infinisil>
__monty__: Hm can't remember
<gchristensen>
docbook is really quite great
<infinisil>
Docbook doesn't sound bad as an intermediate format
<qyliss>
and this is why it feels to be like "we should just have a collection of Markdown files" isn't going to satisfy our needs
<__monty__>
I doubt docbook as an intermediate format would be at all necessary with pandoc. Only for asciidoc maybe.
<gchristensen>
it is difficult to go from a lower abstraction to a higher one
<qyliss>
I think we'd have to end up extending Markdown to support custom attributes or whatever, to make it fit into the overall docs
<gchristensen>
sounds bad
<gchristensen>
but maybe we won't have to -- it would be interesting to see a demo to try it out
<qyliss>
And then that starts to break the argument that Markdown has going for it, which is that people know it already
<qyliss>
Yeah, I'd love to see a Markdown demo
<gchristensen>
easier to know by trying than guessing and worry :)
<__monty__>
I agree, markdown's not a realistic option. Because of lack of features and the terrible html stuff.
* gchristensen
thinks it is definitely an option
<qyliss>
I do like mdbook's output
<infinisil>
__monty__: Github flavored markdown has an extension to disallow structural html elements at least
<qyliss>
(The thing made for the Rust book)
<qyliss>
but it doesn't support non-web
<qyliss>
infinisil: oh that's good
<infinisil>
And I think there's many other markdown extensions that can do more stuff
<qyliss>
I definitely don't want our docs to look like the start of the Nixpkgs README
<qyliss>
(in source form)
<infinisil>
Oh lol, didn't know that was done with html
<michaelpj>
mdbook? which, surprise surprise, has to extend markdown because it's inadequate?
<qyliss>
indeed lol
<qyliss>
Markdown is fine for single documents
<qyliss>
Not great, but fine
<infinisil>
I'm starting to lean towards reST
<qyliss>
why reST over AsciiDoc?
<qyliss>
I haven't looked much into reST, to be honest
<infinisil>
reST has seen more use, and I've heard asciidoc has too much stuff
<__monty__>
I came in to this thinking reST would be the best bet. Then I softened to asciidoc but have since reverted that opinion. I no longer think reST will suffice without significant effort spent on improving tooling.
<__monty__>
I no longer think any format can do everything everyone wants : )
<gchristensen>
probably always true
<adisbladis>
We clearly need to create another one ;)
<adisbladis>
^ only half-joking
<qyliss>
are there serious contenders outside Asciidoc(tor), Markdown, and ReST?
<__monty__>
Imo latex/tex shouldn't be discarded too quickly.
<gchristensen>
I know niksnut would like github.com/edolstra/sst to be a serious contendor
<__monty__>
And scribble is a more modern lighter weight variant of that. (Though would imply implementing more tooling than other options probably.)
<adisbladis>
__monty__: SPeaking of that I love what org-mode is doing with latex
<adisbladis>
It's trivial to write documents in org and sprinkle some tex to make them look really nice
<gchristensen>
uh oh
<adisbladis>
I'm not seriously suggesting org-mode though
<michaelpj>
haha, why do people always put "simple" in the title of their software projects? it always ends up just being embarassing once it becomes complicated later :D
<__monty__>
adisbladis: It's a real contender imo. It's the kind of format that actual powerusers have actually battle tested.
<gchristensen>
sounds like a good way to stick with docbook
<infinisil>
Yeah org mode might be a contender, though not everybody speaks emacs
<qyliss>
Is org at all usable outside of Emacs?
<qyliss>
I guess it is
<michaelpj>
can you convert org to something else on the command line without starting a headless emacs?
<qyliss>
you can with pandoc
<qyliss>
but there's nothing necessarily wrong with headless emacs
<michaelpj>
but presumably pandoc isn't going to support half the fancy stuff you can do with org
<adisbladis>
qyliss: Well, not really
<infinisil>
orgmode tables are nice in emacs
<michaelpj>
pandoc is great, but it's not magic
<adisbladis>
infinisil: Ugh... Pandoc makes for really ugly org
<adisbladis>
Another thing org does great btw: Syntax highlighting
<gchristensen>
oh no what is happening
<adisbladis>
I've even coupled it with pygments
<__monty__>
Maybe we should invest effort into improving pandocs support for a particular format? Then at least the next switch or allowing multiple would be mostly limited to implementing good enough support for it in pandoc : )
<qyliss>
I do like org
* adisbladis
should stop bikeshedding :)
<qyliss>
but I consider my opinion of it as an Emacs user far less important than how it feels to a new contributor who uses VS Code or whatever the latest thing is
<qyliss>
or nano
<adisbladis>
qyliss: Exactly why I dont see it as a serious contender :/
<qyliss>
It might be fine? The syntax isn't that hard.
<qyliss>
But I just feel like that's not my opinion to get to have
<gchristensen>
oh man, and I was just going to say: I'm looking forward to reducing pandoc's closure from 2.3G
<__monty__>
I don't think that closure is bloated because pandoc's big. That's actual bloat. Adding to pandoc wouldn't increase it by much.
<infinisil>
__monty__: Perhaps compiling it statically would make it much smaller
<gchristensen>
it just took me like 30 seconds to a minute to fetch pandoc on my modern, fairly powerful laptop which is plugged in to gigabit etherent connected to a 250gbps network connection
<__monty__>
The pandoc macOS release pkg is 25.2 MB. So I really think most of that bloat is honest to god bloat.
<__monty__>
It doesn't rely on orders of magnitude of shared libs.
<gchristensen>
cool, we should definitely fix it then
<__monty__>
infinisil: GHC and static compilation don't really mix well though : /
<andi->
I "like" how I have to download a bazillion rust package -doc outputs whenever I need pandoc..
<infinisil>
"static-haskell-nix can successfully build > 90% of Stackage executables, so chances are high it can build yours."
<michaelpj>
I'm sceptical that we can get a pandoc-based process that supports e.g. inter-file links and searching well
<__monty__>
Only if you want to support multiple formats, no?
<michaelpj>
well, some people were suggesting pandoc as a way to use org
<__monty__>
And I'm not so skeptical actually. Custom filters seem like a fairly simple way to achieve that.
<__monty__>
It might suffer from the N factor in from M to N formats though.
<gchristensen>
it would be really good to not have to do this
<__monty__>
I don't think any multi-authoring format solution would allow this out-of-the-box.
<andi->
I can't wait for NixOS minimal being blocked on some GHC issue...
<__monty__>
Nor do I think it's realistic to assume any toolchain will support every desired feature.
<gchristensen>
having format fragmentation seems like the worst option
<gchristensen>
and we will never support every possible desired feature
<__monty__>
FRidh is explicitly in favor of format fragmentation though.
<gchristensen>
like, format fragmentation is definitely bad for contributors
<gchristensen>
I doubt he is
<michaelpj>
yeah I agree multi-format seems bad, but I also think that using pandoc as a primary tool for processing a single-format source is a bad idea
<gchristensen>
agreed
<adisbladis>
andi-: ugh... That's something I'm afraid of too
<gchristensen>
andi-: and for r13y to rebuild all of that!
<FRidh>
__monty__: explicitly? Nix is quite a different project from Nixpkgs/NixOS
<andi->
gchristensen: is that a channel blocker yet? ;-)
<gchristensen>
hehe
<gchristensen>
samueldr: I have a minor bug report for the options.html search if you're interested :P
<FRidh>
__monty__: I would prefer if those who want to use a different format would take initative by creating a new form of documentation with *content* that is desired (in whatever format they choose), instead of just converting what we have.
Synthetica has joined #nixos-dev
psyanticy has joined #nixos-dev
<__monty__>
That's still format fragmentation.
<gchristensen>
that would not need to be converted
<FRidh>
yes, but it shows its more than words and indeed then would not need to be converted
<FRidh>
actually it is words hmm
<__monty__>
I'm more familiar with pandoc than other tooling and I'm definitely less pessimistic about it. Its design lends itself well to converting to multiple formats. I'm not as confident that format-specific toolchains would be as easily expanded to new formats.
<adisbladis>
__monty__: Pandoc's closure is huge though
<__monty__>
adisbladis: Yes it's bloated for sure. It doesn't have to be huge.
<adisbladis>
__monty__: Not just runtime, build time.
<adisbladis>
I would be -1 on anything that requires GHC in the minimal channel
<__monty__>
Ah, fine.
<__monty__>
The runtime closure's still ridiculous though.
<infinisil>
adisbladis: Hm, this would disallow any haskell tooling whatsoever, and haskell tooling can be quite good and bugfree because of haskell
kenjis has quit [Remote host closed the connection]
<__monty__>
It probably excludes Rust tooling too?
<infinisil>
If we can sort out the haskell infra it shouldn't be a problem
<infinisil>
E.g. by using haskell.nix
kenjis has joined #nixos-dev
<__monty__>
Does it exclude Tex/latex?
<infinisil>
Well imo these should all be allowed
<infinisil>
I want to use good tooling and not be restricted to tooling due to infrastructure concerns
<FRidh>
tex/latex gets a mess with its packages. Which do we permit, which not. Where would you draw the line (thinking about closure size).
<FRidh>
do enjoy writing in it (doing it right now again)
<infinisil>
I like latex for really scientific papers and stuff, but I don't think it would work well for our docs
<adisbladis>
Platform support is another thing to consider
<FRidh>
infinisil: I agree
<adisbladis>
Does GHC run on riscv for example?
<__monty__>
Probably not yet.
<adisbladis>
Totally not a blocker, but worth consideration
<__monty__>
I wouldn't expect many toolchains to support riscv yet. Is there anything but C?
<{^_^}>
#77238 (by grahamc, 13 seconds ago, open): Get rid of sha1 support for fixed-output derivations
<Profpatsch>
gchristensen infinisil : I’m cutting reading the backlog now, but are we going to keep docbook in the backend for generating the docs?
<Profpatsch>
Because we should make a difference in what people write docs in and what is used to generate the final output.
<__monty__>
Profpatsch: That depends on the outcome of the RFC afaict.
<gchristensen>
Profpatsch: that was a consideration of if we're using asciidoc, we can convert asciidoc to docbook with asciidoctor and use docbook to produce an epub
<gchristensen>
docbook-xsl should probably not be in the flow for generating the HTML / web docs
<Ericson2314>
Yeah we should get to non-bloated haskell infra
<adisbladis>
gchristensen: Nooo!
<Profpatsch>
My opinion is: Everybody knows markdown, so let’s make markdown the default (no HTML spicing allowd). However, markdown isn’t powerful enough, so let’s allow docbook when that is necessary.
<Profpatsch>
gchristensen: Oh, why not? Too many build-time dependencies?
<Ericson2314>
I don't know why people can't just write docbook
<Profpatsch>
s/spicing/splicing/
<Ericson2314>
i always write in the one i am supposed to
<Ericson2314>
in projects
<Profpatsch>
Ericson2314: but why should they when markdown is fine for 95% of docs.
<Ericson2314>
markdown is actually really hard
<Ericson2314>
i am constantly reindenting nested lists
<Ericson2314>
markdown makes no sense
<Profpatsch>
But it’s perfectly fine for unstructured/semi-structured things.
<__monty__>
Docbook isn't a pleasant format to write in and the effect is that many people refrain from even taking a look at contributing to the docs.
<infinisil>
Ericson2314: I believe you're one of the elite few, contributing to many things and such. The average Joe isn't like that
<Profpatsch>
I second that, docbook is brutally hard to get into.
* Ericson2314
only believes in structure, as a matter of priniciple
<__monty__>
Even if those docs aren't actually written in docbook! That should say something.
<Ericson2314>
I am not an elite writer of docs!
<Profpatsch>
A second problem is that the cycle right now is very long. Generating the manual to check a change can easily take 30s–1m
<Profpatsch>
And that’s once you figure out how to do it in the first place.
<niksnut>
the only problem with docbook is that the syntax is verbose
<Ericson2314>
anyways i went here to ask a question, and now am rekindling flames :D oops!
<Profpatsch>
niksnut: I can give you a few more.
<niksnut>
that's why I made a markup language with a simple latex-flavored syntax
<Profpatsch>
- The nesting of elements is hard to figure out and the error messages are horrible
<gchristensen>
that is not the only problem with docbook
<Profpatsch>
- XML is hard to balance
<Ericson2314>
sxml!
<Profpatsch>
- xsltproc is single-threaded
<niksnut>
Profpatsch: that's a problem of xmllint
<gchristensen>
being completely serious here
<Ericson2314>
anyways does one of you know how we build the vms for the vm test? I am not sure how to build a guest nix store in a derivation from the host nix store
<niksnut>
I mean, markdown doesn't have horrible error messages because it doesn't have a concept of errors
<niksnut>
it's garbage in, garbage out
<Ericson2314>
yes!
<niksnut>
markdown will never spot an error for you
<Profpatsch>
- most modern editors don’t have a good xml setup (I have never gotten it to work correctly in Emacs, with xml imports resolved)
<gchristensen>
the XSLT is difficult to tweak and modify to our desires. samueldr spent a ton ton ton of time on https://github.com/NixOS/nixpkgs/pull/68020 only to have it die at the last phase because of the XSLT going quadratic
<{^_^}>
#68020 (by grahamc, 17 weeks ago, open): Vacation PR: multi-paged, styled, searchable docs with wrapper tooling and epubs for NixOS and Nixpkgs
<gchristensen>
samueldr and I*
<niksnut>
complexity of xslt is completely irrelevant
<niksnut>
since nothing about xml requires you to use xslt
<adisbladis>
__monty__: I'm still very intrigued by the concept of writing docs in nix itself
<Ericson2314>
well that is a real problem
<gchristensen>
it isn't irrelevant
<Profpatsch>
adisbladis+
<niksnut>
I mean, what would you use to process markdown?
<Profpatsch>
adisbladis++
<{^_^}>
adisbladis's karma got increased to 27
<Profpatsch>
:)
<gchristensen>
it is literally the problem between me and my goal of having multi-paged, searchable docs which are attractive and NixOS branded
<niksnut>
yes, so don't use xslt
<gchristensen>
there is nothing else?
<niksnut>
literally any programming language you want
<Profpatsch>
Another data point: pandoc is 120MB and many many haskell dependencies, so before we use it we’d have to create a more minimal version.
<gchristensen>
you're proposing we rewrite the 10s of thousands of lines of docbook -> html in docbook-xsl?
<gchristensen>
in a different language?
<Profpatsch>
Also pandoc is the opposite of docbook, it breaks everything down to a rather simple internal model, losing semantics in the process.
<niksnut>
no
<Profpatsch>
Which would make transforming to good docs even harder.
<niksnut>
you want some to do some docbook transformation, you can do that in whatever language is convenient - exactly the same as when you want to process markdown
<gchristensen>
oh I see
<__monty__>
Profpatsch: It doesn't have to lose any semantics though. The internal model can be extended.
<niksnut>
*you want to do
<Synthetica>
__monty__: How?
<Profpatsch>
__monty__: Ah thanks, I didn’t know that. But then we have a GHC dependency on our manual :P
<__monty__>
Synthetica: By extending the AST the Readers and the Writers. I'm not saying the internal format is extensible through a configuration file or something. Just want to note that extending the internal model isn't like moving a mountain.
<Synthetica>
__monty__: Ah okay
<Ericson2314>
did we ever talk about reST?
<infinisil>
Ericson2314: Yeah, I think it's one of the best candidates
<Ericson2314>
I am told by a coworker it is the same data model as docbook
<__monty__>
Synthetica: In contrast to other toolchains that really aren't architected to make such extension possible.
<Ericson2314>
I like the docbook data model
<infinisil>
And reST comes with great tooling and usage through Sphinx
<Ericson2314>
and I have used reST but didn't realize they lined up
<Profpatsch>
Ericson2314: I think everybody likes the docbook data model.
<Ericson2314>
whew :)
<gchristensen>
Ericson2314: I think asciidoc is the one which uses the same format as docbook
<Ericson2314>
clever: error: not an absolute path: 'qwer/gshfgk1s1m87vl2i6qwx5kp77ww5wadg-reflex-platform-everywhere.drv'
drakonis has quit [Ping timeout: 260 seconds]
<infinisil>
Well, if so many people are for keeping docbook then I might just give up on the RFC, I can't be bothered to argue with everybody about why it sucks to write docbook
<infinisil>
But don't expect me to write docs either then
<infinisil>
I'll just ping <insert person that likes docbook> to write docs for me
<gchristensen>
infinisil: I don't think that is true
<gchristensen>
please continue
<infinisil>
What isn't true?
<gchristensen>
the key is to listen to what people are saying, weigh their motivations and interests, and demonstrate that the outcome of your thought process has valued and included their feedback -- even if it doens't satisfy their desires in certain (or all) ways
<__monty__>
Yes, you're doing a very thankless job. Please don't be discouraged.
<infinisil>
My motivation is very quickly decreasing to spend time on this when poeple don't even agree on the premise of the RFC (that we need to change something)
<gchristensen>
I think that in all of the noise about format, there is of signal that yes, we do
<qyliss>
Was it not clear before creating the RFC that not everybody agreed on that?
<gchristensen>
that is part of my thinking about requirements before format
<qyliss>
Eelco has been consistently against it basically every time it's come up, for example
<gchristensen>
last time he and I talked in person he agreed it would be good to switch to something else
<simpson>
infinisil: To use a meme, "docbook sucks, use docbook". The primary problems that folks have talked about, the weight of the existing docs and converting/maintaining them, and the difficulty of bikeshedding the formats; these are common to *any* format-switching discussion.
<simpson>
You basically have to show, in your RFC, that the pain of staying where we are will be greater than the pain of switching.
<simpson>
But the pain of writing docbook, rest, markdown, etc. is roughly similar to me. They all suck, all plaintext doc formats are terribly unergonomic, and we should be thankful that we're not damned to Mediawiki syntax.
<infinisil>
Okay how about this: We have a poll (yes another) on discourse where we just ask "Do you think nixpkgs docs should have a different format?", "No, docbook xml is fine", "Yes I'd rather write Markdown/reST/Asciidoc/other"
<simpson>
Also, careful not to take "everybody" statements seriously! I don't think that anybody here speaks for everybody, including me.
<qyliss>
Who gets to vote?
<infinisil>
Everybody
<infinisil>
Community
<qyliss>
I think that's guaranteed to have the outcome in favour of change
<gchristensen>
me too
<qyliss>
because everybody will be voting in favour of their preferred format
<infinisil>
Yeah, so that would be some hard stats to convince those not in favor
<qyliss>
I don't think the outcome would be at all meaningful for that reason
<gchristensen>
infinisil: your project here is 95% politics
<qyliss>
like Brexit
<simpson>
Hm, I think that that sort of vote is going to overwhelmingly support the status quo, unless everybody is extremely angry already.
<qyliss>
people vote for what they want to happen, not what's likely
<simpson>
gchristensen: Exactly! I was thinking of how to phrase political science insights in a palatable way, but this is asking for "I love democracy" moments.
<infinisil>
It's an idea anyways
<qyliss>
And also, I think a lot of people who would like Markdown especially would like it, but have not thought about the practical considerations that might mean that "Markdown" they end up writing isn't what they wanted after all.
<qyliss>
And that's the sort of risk with an "everybody" poll
<qyliss>
Maybe 90% of people would like Markdown in theory, but only 30% would like the Markdown variant we'd need to use to meet our requirements.
<qyliss>
And in an "everybody votes" poll, getting that context across is going to be basically impossible.
<qyliss>
Especially when what that would actually end up looking like isn't known.
<infinisil>
I and many other people will be fine with anything but xml
<qyliss>
I don't think we can make progress here without example manuals in different formats, showing the tradeoffs we'll have to make for those formats.
<qyliss>
there's no point having any sort of decision making process where people don't know what they're voting for
<__monty__>
Time to start bikeshedding what a decent demo looks like : )
* __monty__
drags in a new shed
<qyliss>
I don't think there's all that much to discuss there
<qyliss>
Have a small but sufficient amonut of content from the actual manual, demonstrating all the features we need or want
<qyliss>
Or as many of those as possible
<__monty__>
Well you considered search out of scope earlier. While what I'm hearing is "Good search is non-optional."
<infinisil>
I think just establishing that many people think our current situation isnt' very good would be a good first step
<qyliss>
__monty__: I did not
<qyliss>
you have been consistently misrepresenting what I've been saying and I am fed up of it
<__monty__>
infinisil: Don't worry about that. Most everyone in this discussion is of that opinion afaict.
<infinisil>
__monty__: I guess the numbers would be mostly to convince eelco
<__monty__>
qyliss: Well sorry, here's what my mental model of your opinion is based on: "idk about search but otherwise, sure"
<simpson>
qyliss: I agree that a demo section would be *very* helpful.
<qyliss>
__monty__: that was in response to whether I could produce a demo manual in a few hours, with AsciiDoctor, from scratch
<qyliss>
Not about whether I thought search was a good idea.
<qyliss>
The preceding few log lines should make that fairly clear
<simpson>
infinisil: I don't know how to phrase this diplomatically, sorry, but an XML allergy is precisely the sort of thing that is *not* going to get much traction as a political issue within the community. You'll have to have some sort of concrete evidence which doesn't trace back to that if you want to move me or similarly-minded folk. (TBF I'm probably the only one this hardheaded~)
<FRidh>
ask people which nixos/ projects they contribute to , whether they've written docs for them and how much and how often, what their hurdles were, what aspects (statements, and open field) they find important about docs. Provide link to overview of formats/tools and possibly demo's.
<infinisil>
FRidh: That sounds like a good idea
<__monty__>
FRidh: But if the goal is to eliminate/reduce *hurdles* you're missing out on the target audience with such a question.
<FRidh>
infinisil: if you like to I could help with formulating questions. Small demo's exist for rest and org, and we already have docbook.
<simpson>
__monty__: It'd be anti-inductive to get doc-writing opinions from folks who don't write docs in the hopes that they'll start writing docs once the conditions are different *unless* we know somehow that a change in conditions *would* work. The best we can do is user stories from people who *did* make the leap, to figure out what they *would* have liked.
<gchristensen>
I just want to call out that domenkozar[m] specifically went to conferences to research this
<infinisil>
simpson: Many people are deterred from docs just because it's xml. I think it's important to get those views
<simpson>
infinisil: Sure. How many, though? And you have to keep in mind that even-flow is both ways: Some folks might *like* the XML.
<qyliss>
One nice thing about XML, _especially_ if you're new, I think, is that there isn't magic syntax you'll accidentally trigger by using punctuation, or whatever
<__monty__>
I've refrained from adding voices to the discussion because it's hard enough as-is. But I want to note that joepie91 is another person with strong opinions on the nix/os/pkgs documentation. (Their particular favorite format is MDX.) Just for the record.
<qyliss>
It's very explicit what you'll get out the other side, and if you're not used to the language that's extremely nice
FRidh has quit [Quit: Konversation terminated!]
<__monty__>
Not that accidental formatting mistakes being less likely helps with lowering the hurdles for new documentation contributors though.
<qyliss>
Gives confidence
<qyliss>
If you're submitting your first contribution or whatever, being confident it's correct is important
kenjis has quit [Ping timeout: 248 seconds]
<__monty__>
Yes but the problem is docbook discourages some people from even trying to contribute.
<infinisil>
On the other hand like every week I have to tell somebody that docs in nixos options aren't markdown and they need to use this and that special xml element
<infinisil>
I've even stopped doing for most things because I can't be bothered anymore
<infinisil>
And nobody even builds docs and checks them
<infinisil>
Well not nobody, but many don't
<simpson>
Sounds like you've found an interesting problem.
ddima has left #nixos-dev [#nixos-dev]
<Ericson2314>
with asciidoc I suppose one can losslessly convert to and from docbook?
<qyliss>
Definitely to
<qyliss>
I couldn't find a way to do from other than pandoc
FRidh has joined #nixos-dev
<michaelpj>
docbook is definitely a superset of asciidoc
<michaelpj>
modelling wise
kenjis has joined #nixos-dev
<Ericson2314>
oh? asciidoc claims to have the same documentation model, but fewer things are expressible?
<michaelpj>
I think it's questionable whether asciidoc (in the form of asciidoctor) has a "document model" at all. AFAIK it just works directly on a parse tree
* Ericson2314
pukes
<Ericson2314>
I soon as well implement one of these myself
ixxie has joined #nixos-dev
<Ericson2314>
asciidoc says it is the same data as docbook, but if that is just the intent and doesn't affect implementation, it doesn't mean nothing
<michaelpj>
it's kind of baffling to me. There are several projects like this, and they inevitably get to the point of wanting to do something like fancy inter-file links, and they realise it's hard to do that when you're a text processor and you *don't have a document model*. what a surprise!
<michaelpj>
or the document model is implicitly the generated HTML, so you have to reason about in what cases it will generate HTML anchors that you can link to, which then obviously is flaky once you have other formats
<Ericson2314>
yup!
<Ericson2314>
i would have nix just wait until incremental happy comes to the top of my todo list :D