<ekleog>
zimbatm: oh? I thought to remember you were the one who created it, sorry then… any idea who I can poke for a change to either the RFC repo or discourse? :)
sir_guy_carleton has joined #nixos-dev
lassulus_ has joined #nixos-dev
lassulus has quit [Ping timeout: 252 seconds]
lassulus_ is now known as lassulus
phreedom has joined #nixos-dev
phreedom_ has quit [Ping timeout: 256 seconds]
jtojnar has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
phreedom_ has joined #nixos-dev
phreedom has quit [Ping timeout: 256 seconds]
<zimbatm>
ekleog: I only have admin on discourse
<ekleog>
zimbatm: oh 'k, so if you wish to create a pre-RFC category on discourse… :° (I guess it's possible to post to Development, but… sounds like it'd mix up RFC and non-RFC talks… not sure whether that's a problem, though, will do if you think it'd be better)
<gchristensen>
IMO we should just add some IDs with good human-readable names
<gchristensen>
it will take all but 10 minutes
<Profpatsch>
> In fact, if you run the same stylesheet with the same input document a second time, the XSLT processor may not generate the same ID values that it generated the first time.
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):196:8
<Profpatsch>
lol, so it’s useless
<gchristensen>
this is why I've worked so hard to remove auto-generated IDs from our docs
<Profpatsch>
Ah, that’s news to me.
<Profpatsch>
But I see.
<domenkozar>
btw asciidoctor auto generates human readable ids
<Profpatsch>
“If you set this parameter's value to 1, then the template named object.id will replace the use of the function generate-id() with <xsl:number level="multiple" count="*"/>. This counts preceding elements to generate a unique number for the id value.”
<Profpatsch>
lol, so this docbook option is even more useless than generate-idn)
<Profpatsch>
Because it will not only create different ids, it will also make them point to different parts of the document if something is added or removed.
<domenkozar>
hm, I might do another experiment for documentation, seems like asciidoctor can output to either html5 or docbook
<domenkozar>
and if claims are true, conversion should be isomorphic and thus almost lossless
<Profpatsch>
ahem, isomorphic means lossless.
<domenkozar>
"and thus"
<gchristensen>
"almost"
<Profpatsch>
:D
<gchristensen>
Profpatsch: would you mind adding IDs?
<Profpatsch>
can do
<gchristensen>
I'm digging in to the generation step
<domenkozar>
actuall this time it's going to be more painful
<domenkozar>
we've accumulated quite a bit of markdown
<gchristensen>
unfortunately so
<gchristensen>
Profpatsch: so I have a way to do it, but it is ugly... I'll be asking someone for further help in a couple hours when they're awake
<Profpatsch>
gchristensen: The problem is they need to be *stable between runs*, but also *unique*.
<gchristensen>
Profpatsch: adding IDs should be done by hand, via xml:id="builtins-xxxx"
<Profpatsch>
Yeah.
<Profpatsch>
Ah, you mean you found a way to generate anchors?
<gchristensen>
the thing I have a way to do, but is ugly, is adding the little linkey thing.
<Profpatsch>
There’s already a little linkey thing on headers.
<Profpatsch>
Can’t copy that?
<gchristensen>
it is ugly because the ID is on an <a> with no inner elements or text, so you have to hover over a secret square to find it. some possible solution I'll explore but first I need to make breakfast
<Profpatsch>
+2
<Profpatsch>
I think it was a mistake that ids have to be globally unique in XML documents.
<Profpatsch>
Should have been a path down the document or something.
<gchristensen>
makes it more complicated for cross-linking docs though I think
<Profpatsch>
Or maybe we shouldn’t use ids for permalinks?
<gchristensen>
they're not necessarily permalinks, but for ... identifying ... the element :)
<gchristensen>
we could have cross-linking nixpkgs <-> nixos without much trouble, using IDs of each other's elements
<Profpatsch>
As long as they are stable. :)
<gchristensen>
exactly, though the validiting of the links is checked at build time
<Profpatsch>
gchristensen: Huh, you should add some <variablelist> examples to docbook.rocks as well.
<gchristensen>
yeah, I've considered adding another page for slightly more complex stuff
<gchristensen>
oh, yeah, it took me a long time to feel comfortable reading that page. in general, don't need to look when you're doing simple expansion of nix* docs
<pie__>
i mean i felt like smeone would have brought it up already
<infinisil>
ah
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 264 seconds]
<infinisil>
pie__: Oh god, that mic
<infinisil>
Oh that was a bit delayed, I already finished watching it
<infinisil>
Very interesting talk!
<infinisil>
(and paper too probably)
<pie__>
seems like it was extremely summarized :p
<infinisil>
Yeah, a bit too rushed, would've loved to hear more!
<pie__>
going by the talk the paper is probably pretty readable
<infinisil>
Yeah probably
pie__ has quit [Ping timeout: 252 seconds]
FRidh has quit [Quit: Konversation terminated!]
pie__ has joined #nixos-dev
orivej has joined #nixos-dev
ericnoan has joined #nixos-dev
<andi->
So, I want to prepare a PR for the staging-18.03 branch. Since that is a bit outdated I decided to run a `git merge --ff-only origin/release-18.03` on that branch. That should be the normal workflow?
<andi->
I bounced it through a NIX beginner and it looks helpful. One thing that might be missin and/or confusing there is that most of those aren't accessed with the complete path (lib.attrsets.filterAttrs) but via lib.filterAttrs within nixpkgs.
<samueldr>
> moar docs
<samueldr>
Verified
<gchristensen>
(my iternet is still bad, so it is still hard to edit typos on IRC, sorry)
<samueldr>
uh, that Verified is github's DOM doing silly stuff
<gchristensen>
haha, I thought you were approving my PR :)
<samueldr>
nah, but still it works: "Verified, you added moar docs"
<samueldr>
(wanted to check the docbook side of things to see if my observations were right)
<gchristensen>
lib.attrsets.foldAttrs has my favorite type signature
<gchristensen>
andi-: true, maybe could add a "also known as" thing
<samueldr>
gchristensen: improvement idea, the examples and their return values should maybe be either separated in different elements, or at least identified using docbook wizardy so it'd be possible to (in another time and place) test their output
<gchristensen>
agreed!
<andi->
The other thing that could probably be a bit confusin is that you talk about the arguments "name" before introducing the order of them or actually mentioning the "signature" with names of the fields. The current signatures are great for people familiar with functional programming. What I am missing would be something like: `foldAttrs op nul` (or similar)
<gchristensen>
andi-: hmm I agree
<samueldr>
(though, my main fear isn't valid, it looks like hljs doesn't go mad at seeing invalid stuff after the nix code)
<samueldr>
and additionally, if the return value's representation is valid nix itself, hljs may have a better time trying to parse it than after a "=>"