<worldofpeace>
It has been decided to have biweekly meetings, which will make it better. The time of said meeting is a bit skewed to London'ish time, hopefully that gets sorted
<worldofpeace>
The "Workflows and notes from Nix steering committee" just makes me think the team would be much easier. Somebody changed that first already
<gchristensen>
right, I'm just thinking it'd be nice to have the list be in a version controlled spot so you can see when and how it changed easily, which you can't do with teams
<gchristensen>
and since the change is not often, not much of an overhead
<yorick>
LnL: did libexpr moved to passing string_view instead of string&?
<LnL>
not sure, I'm not very familiar with this part of the code
<yorick>
I think string& is fine
<yorick>
the other errors have it too
<LnL>
ideally it would show the original code instead of it's representation, since that can look a bit strange
<LnL>
but better than nothing
* LnL
continues fighting with weird null errors
<domenkozar[m]>
LnL++
<{^_^}>
LnL's karma got increased to 19
kenjis has joined #nixos-dev
noonien has joined #nixos-dev
drakonis has joined #nixos-dev
<gchristensen>
holy guacamole, LnL!
<tazjin>
I'm building a package tree documenting tool now (as a demo for the RFC and to experiment with useful features) and the two formats I'm experimenting with are markdown & asciidoc. All links I can find for asciidoc lead me to the Ruby (:/) implementation being the only canonical one, but I've heard there's another one - any ideas?
<gchristensen>
I think that is all there is
<tazjin>
there's a former website for asciidoc (up to 2011), which eventually links through to a python version that is marked as deprecated: https://github.com/asciidoc/asciidoc
<tazjin>
and that's all I can find
<gchristensen>
drakonis: hey so your idea for metadat anad whatnot for nixpkgs for discoverability could even get a grant under NGI0 I think?
<tazjin>
I think it would be useful for the RFC demos if we had a target output page (say one page for a NixOS module, one page for a language build infrastructure)
<__monty__>
Probably having all the features people mention being important demonstrated is important, tazjin?
<tazjin>
__monty__: people have mentioned every feature under the sun, spread out over various IRC logs, RFC comments and forum threads :|
<__monty__>
Yeah, but not covering the features will mean these people will object to the demos.
<__monty__>
Might also lead to bias in favor of a certain format. "Oh, this thing is easy in X, I'll put it in the reference demo."
<tazjin>
is that really bias if X is a good feature?
<gchristensen>
drakonis: yeah
<__monty__>
tazjin: Yes because it makes X look good even though it doesn't support features a, b and c.
<gchristensen>
who cares?
<gchristensen>
that is the point of a PoC
<gchristensen>
and the reason somebody invested in a format would be best suited to do a PoC
<__monty__>
Well, if you're gonna use markdown to do the PoC you're gonna miss most features but it'll look the best because markdown is designed to look nice and simple in exchange for being featureful.
<tazjin>
__monty__: I think extensibility should be a real criteria here actually, so if X doesn't have a, b and c one question should be "how hard is it to add them?"
<__monty__>
Sure.
<tazjin>
15:38:05 <__monty__> Well, if you're gonna use markdown to do the PoC you're gonna miss most features <- citation needed :]
<__monty__>
I'm just saying maybe we should figure out a subsection of the docs that includes most of the features people want.
<__monty__>
I.e., I think one section's too few for example. Because interdocument links are one of the features people wanted.
<tazjin>
I think the only format that doesn't support links natively is plain text
<__monty__>
Markdown doesn't have them. Not sure about commonmark.
<tazjin>
and I was just saying to gchristensen that I think we need to clear the format hurdle before we can move on to the interesting stuff, e.g. what should the docs layout be
<tazjin>
I'm quite sure Markdown has links, I have written lots of links in Markdown
<__monty__>
Urls, not links inside the same file or across some local files.
<tazjin>
that is a function of your docs layout and serving system, not of the format
<tazjin>
in fact I'd argue in the opposite direction
<tazjin>
if links to your output are so hard to construct that you need special tooling support ... rip
<tazjin>
because humans also construct links manually sometimes (or try to)
<tazjin>
I suspect what you actually mean is "internal link validation at build time", which is not a big issue in any format
<__monty__>
What? "Cf. the last section" <- Why shouldn't that be a link? Without having to go "OK, the rendered version's gonna have urls like /docs/ch1/sec12."
<__monty__>
I'm talking about a very simple thing, like latex's \ref.
<__monty__>
I'm assuming it's not true for docbook?
<gchristensen>
of course it is true for docbook
<gchristensen>
docbook is the king of extensions
<gchristensen>
there is no limit to the extensions you can do with docbook, because there is no limit to the structural tree parsing and manipulation steps you can do before passing it to the docbook-xsl formatting step
<__monty__>
Extensions in the markdown sense or does it offer a way to "extend" the language you write docs in?
<gchristensen>
you can do literally anything you want
<__monty__>
You can process any format any way you want though.
<jtojnar>
tazjin can you add links inside markdown code blocks?
<__monty__>
Are we talking lisp-macro-like extensions?
<gchristensen>
XML is basically S-Expressions yes
<gchristensen>
(and XSLT is essentially a lisp)
<tazjin>
jtojnar: not oob
<jtojnar>
hmm, maybe we could run Nix parser in JS and link the options in codes at runtime
FRidh has quit [Quit: Konversation terminated!]
<tazjin>
jtojnar: pls no
<gchristensen>
there you go
<gchristensen>
though you could do it with xslt
<jtojnar>
I think I would even prefer writing Nix parser in JS to XSLT
<tazjin>
I only just realised that the current manual barely has syntax highlighting
<gchristensen>
jtojnar: well yeah, you could use ,jdwhat's parser in Rust and WASM your way to a JS parser :P
<qyliss>
tazjin: the canonical one is written in Python I believe
<tazjin>
qyliss: that's deprecated
<qyliss>
oh, right
<gchristensen>
tazjin: it was an intentionally chosen theme to be minimal and unobtrusive
<qyliss>
then maybe everyone just moved to Asciidoctor
<tazjin>
yeah asciidoctor is the official one (as per the info string on the old python repo)
<__monty__>
Maybe antora is the second implementation now?
<tazjin>
jtojnar: I can't think of a syntax for links in code blocks that wouldn't be disruptive to reading the thing in plain text
<tazjin>
I guess docbook just shoves a ton of XML into the snippets?
<__monty__>
tazjin: That's one of these features that result in bias towards asciidoc I think : ) (They call it out specifically while I don't know of other formats supporting it.)
<jtojnar>
tazjin can't we get away from plain text in 2020?
<tazjin>
jtojnar: no, thanks
<tazjin>
__monty__: what's their syntax for it?
<jtojnar>
tazjin not a ton, just the regular elements
<qyliss>
aanderse: what do you think I should do about #75782? Make my own PR? Merge it with jonringer's suggestions? Fold it into by bigger PR?
<tazjin>
jtojnar: I'm not sure if adding even more barriers to entry by introducing a custom editor is sane, tbh
<gchristensen>
jtojnar: not sure I'm keen on a project for documentation editors where their main home page is just an initial homepage from 19 years ago
<qyliss>
Being able to make changes using the GitHub web UI is probably important.
<gchristensen>
I meant to add a `:P` to the ond of that btw :)
<jtojnar>
if it worked it could be an extra option, not suggesting it to be the official editor™
<jtojnar>
not sure GitHub web UI is a good way to edit docs for anything but fixing typos
<qyliss>
I don't think it is either, but drive-by-ers might.
<jtojnar>
and Docbook should not prevent you from fixing typos
<gchristensen>
it probably doesn't
<aanderse>
qyliss: probably just poke @peti with a sharp stick :)
<qyliss>
not sure I have any special powers in that regard
<aanderse>
qyliss: was mostly just a FYI
<qyliss>
Ah, right.
<aanderse>
yeah i didn't necessarily think you should do anything
<qyliss>
I've been making several PRs related to things he's a maintainer for for the past few weeks and haven't heard anything from him on any of them :(
<gchristensen>
jtojnar: cool!
<aanderse>
it was an fyi, and maybe it will remind him to take a look
<qyliss>
Yeah. Thanks for the ping.
<aanderse>
no problem
<aanderse>
i was carefully watching your mailman PRs...
<aanderse>
until recently when i found out i am able to ditch the mailman instances we have
<qyliss>
Aww
<aanderse>
which is great news for me... because i wasn't looking forward to taking 2 separate mailman instances from debian 6 or 7 (can't recall atm) and somehow merge+migrating them to anything else
<qyliss>
Yeah that doesn't sound fun
<qyliss>
I have been enjoying Mailman though
<qyliss>
Hyperkitty rocks
<aanderse>
i thought "at least i can migrate them to nixos"... but then i found out i can just shut them down, so i'm happy :)
<aanderse>
yeah i just found out we run 2 instances at work recently and started digging into them
<aanderse>
its a nice piece of software
drakonis has quit [Ping timeout: 248 seconds]
<worldofpeace>
qyliss: I think I was just talking about your mailman stuff with spacekookie a few days ago. I'm eager :D
<qyliss>
:D
<qyliss>
I've been working on it for _months_.
<qyliss>
Or rather, I had it working months ago, but it's taken this long to get it into logical, reviewable commits that don't just look like I decided to rewrite the whole thing for fun :P
drakonis has joined #nixos-dev
<qyliss>
If you're particularly excited, btw, review is very appreciated! As mentioned above peti doesn't seem to be particularly responsive atm.
<worldofpeace>
That's considerate of you qyliss, because those kinds of prs are hard to land and review (not that I wouldn't review it like crazy anyways)
<worldofpeace>
> aaron probably just poke @peti with a sharp stick :)
<{^_^}>
error: syntax error, unexpected '@', expecting ')', at (string):273:26
<worldofpeace>
I've heard from gchristensen that there might be a peti summoning ritual
<qyliss>
Yeah I find reviewing modules extremely difficult.
<worldofpeace>
Can't really go into the details, because afterwards you have no memory of how the interaction occured. just that it did. I can lend some incense however, if you're desperate
<worldofpeace>
qyliss: you can ping me when you open it, I'm just not in the position currently to promise anything I'm afraid
<tazjin>
qyliss: I'm curious why you dropped the systemd StateDirectory stuff?
<qyliss>
An excellent question to which I can no longer remember the answer
<tazjin>
:)
<__monty__>
Did you get rid of the state along with it?
<qyliss>
no
<qyliss>
tazjin: Oh it's because the directory setup is done by the mailman-setup service now
<tazjin>
qyliss: hmm, but couldn't that also have been set up by systemd? (since the statedir is specified by name, it'd be possible to have the two share the same statedir rather than having to set it up in the script & take care of permissions)
<tazjin>
not a big deal, but I'd personally be happy if people used the systemd options for managing this stuff (tbh including the service user itself) more
* tazjin
has been running `git blame --line-porcelain` over all of nixpkgs for a while and it's taking *forever*
* gchristensen
too
<tazjin>
gchristensen: huh :p
<gchristensen>
delayed. I mean w.r.t. leading on systemd options which do nice things :)
<tazjin>
ah!
<qyliss>
tazjin: it would be possible, but it would be more code and there would be zero advantage
<qyliss>
The systemd stuff is great most of the time, but it doesn't buy anything here
<qyliss>
tazjin: also, this service sets up multiple directories, /var/lib/mailman and /var/lib/mailman-web
<qyliss>
So which one would I put as StateDirectory
<qyliss>
It would make no sense to put one and not the other
<gchristensen>
so I think I'll probably change the hydra build layout to mark like a quarter of the big machinse big-parallel, with cores-per-job set to like 12 or something
<samueldr>
could implementing TAGS in hydra (was it tags?) be another good project for GSOC
<samueldr>
I'm thinking about the one that cancels builds and push them to a beefier machine in turn
<gchristensen>
that is a really cool idea
<gchristensen>
yeah, that is TAGS
<samueldr>
my gut feeling is it would *really* help
<gchristensen>
same
<gchristensen>
I was thinking I could implement a not great version of TAGS in r13y
<samueldr>
where should we document good ideas for GSOC?
<flokli>
samueldr: if there's not yet a place, maybe just a pad somewhere?
<samueldr>
"just a pad"
<samueldr>
that's why I'm asking :)
<flokli>
one second
<samueldr>
I don't know where I should send that that would be useful
<samueldr>
I'm also thinking of self-contained, mostly conflict-free things
<gchristensen>
all the building is local, so not the same exactly but: for a machine with 48 cores, for each derivation build with jobs=48,cores=1,timeout=30; ones that timed out: jobs=24,cores=2,timeout=60; then jobs=6,cores=8,timeout=600, ...
<flokli>
(requires login via github or other sso as a simple barrier, else public)
<samueldr>
just noting that i18n for nix is really the nix tooling, not nixpkgs and nixos :)
<aanderse>
samueldr: are you feeling charitable with your time right now?
<samueldr>
depends, kinda re-inventing the world in stage-1
<samueldr>
(with great success)
<aanderse>
ha ha ha yeah that doesn't sound like something i want to interrupt
<aanderse>
keep going!
<samueldr>
still, ask
<gchristensen>
I also should probably get back to work and stop chatting about tags :P
<samueldr>
maybe someone will be able to help you?
<aanderse>
nah not me. i just noticed a PR that hasn't been reviewed in 27 days, sitting there. motivation is to run kodi on embedded. i thought you might have an opinion on two on the PR shrug
<samueldr>
I was wondering if you had something in mind already
<lovesegfault>
I'm a SWE, I have some time, I like Nix?
<lovesegfault>
Ah, not really, it just seems like an interesting problem
<samueldr>
right, the "how?" can be read in so many tones
<lovesegfault>
:D
<samueldr>
I lost track of any actual documentation about all that from previous discussions though
<lovesegfault>
I mean, the fact that Hydra is all perl kind of deters me hacking on it
<lovesegfault>
because I do not know perl
<samueldr>
it's the web thing that's perl, the other parts are less perly
<lovesegfault>
And after working with Rust for a couple years I am now an addict
<samueldr>
but I think the initial idea was to implement the nix builder protocol so anything could use it transparently
<samueldr>
hydra, in the end, would be none the wiser
<lovesegfault>
gchristensen's doc mentions that approach
<lovesegfault>
So I guess it'd be cpp to make use of all the Nix libs?
<samueldr>
with the current interest for rust-with-nix it might be possible to do it in rust
<gchristensen>
I would recommend not doing that actually, and instead try doing it in hydra-queue-runner
<gchristensen>
(C++)
drakonis has joined #nixos-dev
__monty__ has quit [Quit: leaving]
<evanjs>
samueldr: gchristensen yeah my initial thoughts after reading the discourse thread and etc were that it might be best to try it with small apps outside of nix core like samueldr’s nix-top. Though, okay, that was more just me wanting to RiiR, fine.
<evanjs>
Anyway, nix utilities that are not central to infrastructure and operations might be a good first target
<samueldr>
my (possibly) wrong opinion is that a prototype implementation in any language is better than none; even if there is the need to rewrite it, it's likely to show the warts and bugs first
<samueldr>
(possibly wrong)*
<samueldr>
though yeah, for what you're looking at, it's likely good
<samueldr>
and evanjs, having a nix-top that actually has knowledge about the daemon rather than a hack that looks at the filesystem would be great
<evanjs>
samueldr: totally agree. Trying my best not to let my bias/rustlove not outweigh my reasons whenever I bring it up for such discussions is all :P
<evanjs>
samueldr: yeah my initial focus for it was system-level stuff without bash
<evanjs>
as Rust _is_ a systems language haha
<samueldr>
nix-top is free of bash :3
<evanjs>
samueldr: sorry, right, shell wrangling is more what I meant haha
<samueldr>
I didn't exactly take it personally, I wasn't sure if that was aimed at nix-top
<evanjs>
no I get it, I just have a bad habit of not clarifying/providing enough context at times