<infinisil>
I want to do a sweep through all NixOS modules just cleaning them up and improving them
<ldlework>
all of em!?
<infinisil>
All of em!
<infinisil>
Well I won't have the time for all of them probably, but I think all of them could use some review
<infinisil>
And I won't do this now, but I wish to someday(s)
<infinisil>
I should probably get rfcs#42 finished before though, so I can refactor all those hardcoded defaults and potentially deprecate some extraConfig's
<infinisil>
Well it could be worse, but there's many things to improve
<drakonis_>
i still think nixpkgs needs a section for all module and package definitions considered subpar
<drakonis_>
because it grew really fast in the past few years
<infinisil>
For modules I agree, for packages I don't think so
<drakonis_>
some language packages are
<drakonis_>
welp
<infinisil>
Though these can all be fixed relatively easily with some refactoring
<infinisil>
Bad modules are especially bad because all of it is exposed and supposed to stay backwards compatible
<drakonis_>
always, but as a buyer beware warning
<pie_[bnc]>
drakonis_: R is f***ed up and i have most (?) of a rewrite
<infinisil>
Meaning you can't remove options, change options, even sometimes can't change option assignments in the module, without potentially breaking someone's config
<infinisil>
And people hate when their config is broken..
<drakonis_>
erlang and elixir was messed up enough to warrant a big post on discourse
<drakonis_>
there's a variety of things that arent up to snuff right now
<drakonis_>
let me see if i can name and shame some more things
<drakonis_>
python is definitely mostly functional right now
<drakonis_>
could be much better
<drakonis_>
but this strays into "how can we improve language support" rather than subpar quality packaging
<infinisil>
Yeah all the override business is still a bit screwy
<drakonis_>
R is really bad though
<infinisil>
When to use .override/.overrideAttrs/packageOverrides/what attribute to override, etc.
<drakonis_>
yes
<infinisil>
There's also .extend
<drakonis_>
that needs to go away
<infinisil>
.extend is good
<drakonis_>
there's a lot of ways to do this and its annoying
<infinisil>
It's more powerful than .override/.overrideAttrs
<drakonis_>
i tried to get a R package on nix and it needed to use gcc, it didnt compile because it couldnt find gcc
drakonis_ has quit [Read error: Connection reset by peer]
<colemickens>
sigh, something is using terrabytes of inbound traffic on my azure vm. its free, but it's still weird.
<colemickens>
I have huge rclone drives mounted, maybe something is indexing them?
drakonis1 has joined #nixos-chat
drakonis1 has quit [Quit: WeeChat 2.6]
endformationage has quit [Quit: WeeChat 2.6]
<ivan>
nethogs, iftop
<ashkitten>
pie_[bnc]: rer
<ashkitten>
good noise
Jackneill has joined #nixos-chat
<pie_[bnc]>
heh
<pie_[bnc]>
drakons keeps disappearing and i cant offload onto him the link
__monty__ has joined #nixos-chat
Synthetica has joined #nixos-chat
kenjis has joined #nixos-chat
gspia has joined #nixos-chat
gspia has quit [Client Quit]
gspia has joined #nixos-chat
drakonis has joined #nixos-chat
<drakonis>
pie_[bnc]: i have seen your link
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 260 seconds]
<sphalerite>
pie_[bnc]: also, do you know about ,tell?
<eyJhb>
Exam tomorrow, wish me luck times 100
<eyJhb>
The worst exam so far...
<eyJhb>
Btw. anyone gotten Linux+Exchange to work (Office365)? Currently I use Thunderbird with Owl, but it requires me to 2FA me each time I refresh anything
<infinisil>
for i in $(seq 100); do echo "Good luck!"; done
<ar>
{1..100}
<__monty__>
> map (const "Good luck!") [1..100]
<{^_^}>
[ <CODE> <CODE> ]
<__monty__>
There ya go : >
<gchristensen>
eyJhb: maybe Evolution can do it?
<eyJhb>
Thanks! ;) - The lecturer is litterally MIA and the school cannot contact him.
<{^_^}>
nix#3304 (by grahamc, 1 minute ago, open): Nix parses `1.` as `1` which makes it look like range syntax is a thing
<__monty__>
👍 : )
<qyliss>
'1.' is pretty common in programming languages, isn't it?
<joepie91>
__monty__: isn't that what Python does
<__monty__>
I hate it.
<qyliss>
JavaScript does it too
<joepie91>
huh. didn't know that
<qyliss>
(Not that it's a good idea)
<joepie91>
apparently noone actually does it? :D
<joepie91>
given that I've never seen it in JS...
<__monty__>
I don't think people do it in python since py3.
<qyliss>
well, in JS it's indistinct from "1"
<Synthetica>
qyliss: It is, and it has a place in those languages, but floats are pretty rare in Nix i'd say, so better to be a bit more explicit
<__monty__>
It used to be necessary because otherwise you got integer division.
<qyliss>
Since JavaScript doesn't have integers
<joepie91>
__monty__: shrug, you can just do 1.0 for that
<joepie91>
doesn't require 1. syntax
<gchristensen>
at any rate, 1..2 should probably be invalid
<__monty__>
Yes you can, hence my dislike of `1.`.
<gchristensen>
even if you can justify why it is okay
<__monty__>
Saying `1..2` is ok is like saying `12` should parse as two numbers `1` and `2` though.
<gchristensen>
no it'd be like saying 1.2 should parse as 1 and .2
<gchristensen>
tbh this would be better if list syntax required whitespace between elements
<__monty__>
It doesn't?
<__monty__>
: ( )
<__monty__>
I don't particularly like whitespace as the separator and now you're telling me empty-string is valid too?
<__monty__>
(╯°□°）╯︵ ┻━┻
<qyliss>
I'm not sure .2 should be valid either
<__monty__>
That's in the IEEE float specification unfortunately iirc.
<__monty__>
I don't mind it as much either.
<qyliss>
does that matter?
<__monty__>
Well you can't say you support floats if you don't adhere to the spec imo.
<qyliss>
I'm very surprised the spec defines programming language syntax
<gchristensen>
that is a neat observation
<__monty__>
I kinda like having a consistent representation.
<__monty__>
Especially because the spec writers were smarter than most implementors. Hexadecimal notation is in the spec for example but not all languages have it.
<qyliss>
And you'd say those languages don't support floats?
<__monty__>
Yes, floats without hexadecimal notation aren't reliable.
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 245 seconds]
<qyliss>
so presumably we already don't support floats properly
<__monty__>
> :p 0x.Ap4
<{^_^}>
attempt to call something which is not a function but an integer, at (string):272:1
<__monty__>
> :p 0x1.b7
<{^_^}>
attempt to call something which is not a function but an integer, at (string):272:1
<__monty__>
> :p 0x1
<{^_^}>
attempt to call something which is not a function but an integer, at (string):272:1
<__monty__>
> 0x1
<{^_^}>
attempt to call something which is not a function but an integer, at (string):272:1
<__monty__>
Nix doesn't even have hexadecimal literals?
<gchristensen>
no
<gchristensen>
nix is not a general purpose language
<__monty__>
That's fine. Does mean nix doesn't support IEEE floats though : )
<__monty__>
Does nix need floats?
<gchristensen>
the reason nix gained floats was so it could parse .json files which had floatls
<__monty__>
Ah, all the evil in current day software development traces back to javascript. : >
<Synthetica>
No kidding!
<__monty__>
Hold on, does this mean nix can't parse hexadecimal floating-point? Or that JSON doesn't allow for hexadecimal floating-point?
<gchristensen>
I doubt json has it
<gchristensen>
> [1.2.3.4.5]
<{^_^}>
[ 1.2 0.3 0.4 0.5 ]
<__monty__>
Ouch, JSON just took a major hit in my esteem. : ( I'd somewhat accepted it as good enough.
<yorick>
I would be fine with removing floats from the syntax and only keeping them when parsed from json
<__monty__>
Such a weird decision for JSON to only allow decimal floating-point literals. Especially for a language that only has floating numeric literals.
<infinisil>
gchristensen: I see the potential for not using strings for version numbers!
<__monty__>
Lists of weirdly parsed floats?
<__monty__>
Slap a version number on it and push to production.
<__monty__>
Good work today, let's slide down the Balmer peak.
<infinisil>
Like to have a function that can transform [1.2.3] -> "1.2.3"
<yorick>
gchristensen: (failing) testcase added to nixfmt :D
<__monty__>
infinisil: I always knew Silvas was a villain's name ; >
<__monty__>
Lists have unspecified ordering?!
<infinisil>
__monty__: In the module system yes
<__monty__>
If you're trying to knock me out you're getting pretty close.
<infinisil>
The ordering depends on the ordering of `imports`
<__monty__>
Ok, that sounds reasonable.
<infinisil>
I don't think it does, why should changing `imports = [ foo bar ]` to `imports = [ bar foo ]` have any different behavior
<infinisil>
I wonder if that's fixable..
<__monty__>
Same reason `import foo; import bar` is different from `import bar; import foo` in any language I know.
<ashkitten>
<infinisil> Like to have a function that can transform [1.2.3] -> "1.2.3" // noooooooo
<ashkitten>
this is so disturbing
<infinisil>
xD
<infinisil>
__monty__: In the module system however this ordering doesn't matter in all. If `imports = [ foo bar ]`, options in bar won't override ones in foo, they'll be merged without any ordering bias
<infinisil>
Same for everything else
<ashkitten>
also, silvas is a cool name. very foresty
<infinisil>
Well it's close enough to my actual name which is Silvan, but Silvas sounds cool :P
<infinisil>
__monty__: (Well except this value ordering)
<infinisil>
__monty__: Hehe I knew it would be that one
<__monty__>
#1 XKCD imo.
<ashkitten>
infinisil: interesting
<sphalerite>
ashkitten: yes, you need to mount the root filesystem in stage1! Also /nix in the case of nixos, if it's separate. But you can also mount things in early stage 2, though I can't think of any not-extremely-specialised use cases for that.
<ashkitten>
yeah i meant besides the rootfs
<ashkitten>
but if we already do it by default then i guess there's no issue
drakonis_ has joined #nixos-chat
drakonis1 has joined #nixos-chat
gspia has quit [Quit: Leaving]
drakonis has quit [Ping timeout: 252 seconds]
<pie_[bnc]>
sphalerite: the thought didnt even cross my mind
endformationage has joined #nixos-chat
drakonis1 has quit [Quit: WeeChat 2.6]
waleee-cl has joined #nixos-chat
drakonis has joined #nixos-chat
<__monty__>
: ( I've lost count how often I've stumbled over string and list concatenation being different operators in nix. Who masterminded this devious torture method?
<infinisil>
Hm I wonder if it would be a problem to allow + for both
<infinisil>
Probably causes more trouble than worth though
<qyliss>
I usually get it wrong the other way
<qyliss>
I try to concat strings with ++
<__monty__>
Yeah, haskell habbit probably.
<infinisil>
<> ftw
<__monty__>
I don't understand why overloading + for numbers and strings is fine but lists needed another op.
<__monty__>
Yes, of course. But nix doesn't have Semigroup or Monoid, afaik? : p
<infinisil>
yet!
<gchristensen>
lol
<infinisil>
I think I've seen some Monoidy action somewhere, maybe via Profpatsch
<__monty__>
Tell me more about your devious plans to convert these heathens : )
<LnL>
we already have weird functors, isn't that enough?
<infinisil>
LnL: The ones for type merging?
<LnL>
don't remember
<__monty__>
LnL: I won't rest until nix is statically typed >: )
<LnL>
the __functor stuff
<infinisil>
Ah that
<gchristensen>
(...__functor should probably be dropped tbh...)
<__monty__>
That's a weird function representation though. Not a haskell Functor?
<infinisil>
Tbh I'm not sure why __functor is called functor
<gchristensen>
infinisil: look up C++ functors
<LnL>
I said weird for a reason :)
<adisbladis>
gchristensen: Why? :(
<__monty__>
gchristensen: Isn't it necessary because you can't dynamically define functions otherwise?
<gchristensen>
__monty__: __functor doesn't grant anything special which wouldn't be solved with changing `foo.bar args` to `foo.bar.whatever args`
<__monty__>
I mean dynamically defining a new function.
<__monty__>
Or, programmatically.
<gchristensen>
I don't think __functor does that?
<__monty__>
I thought that was its raison d'être?
<gchristensen>
no, it just makes an attribute set callable
* infinisil
never watched futurama other than the occasional clip
<__monty__>
You can't call a value a type and then say you have dependent types because values can depend on values.
<infinisil>
__monty__: Can't do that in standard haskell though, the type of a value can't depend on a value even if you don't have to specify the type
<infinisil>
Or most other statically typed langs
<__monty__>
You can mimic it to some extent, i.e., hasochism.
<infinisil>
It is a bit of a stretch admittedly, but you can de dependent-type stuff with it
<__monty__>
But no, haskell's not dependently typed (yet).
<infinisil>
s/de/do
<__monty__>
All hail Eisenberg!
<infinisil>
No idea about hasochism :)
<infinisil>
And ddg says "Including results for masochism" lol
<__monty__>
Singletons basically facilitates this approach.
<__monty__>
Any untyped language can do "dependent-type stuff" according to your definition btw.
<gchristensen>
"if it smells like a duck and quacks like a duck then it is dependently typed"
<adisbladis>
^_^
<samueldr>
the river out back is full of types!
<infinisil>
__monty__: Hehe I guess
<infinisil>
I mean it's not entirely wrong. We can e.g. implement a printf that takes differing amounts of additional parameters depending on the string in the first argument
<gchristensen>
samueldr: just don't try to bind or apply them
<__monty__>
Also, because nix is not a total language if it were dependently typed it'd be unsound and hence not necessarily useful for verified code.
<__monty__>
infinisil: But that's not "dependent types". That's just something you can do in untyped languages.
<infinisil>
But the type clearly depends on a value, which is a definition of dependent types
<__monty__>
There is no "type" involved.
<__monty__>
"Dynamic types" aren't types.
<infinisil>
Sure are!
<__monty__>
Nope, it's just a sad clash of terminology.
<infinisil>
A string is a string, whether it's checked at compile time or runtime
<gchristensen>
I'm going to have to side with __monty__ on this one
<sphalerite>
mumble mumble dynamic types just means that there's only one type
<samueldr>
there is only one type, and that type is NullType
<__monty__>
A "type system" is a system that determines whether or not a program is valid, i.e., *is* a program in a given language. Python, for example, accepts *any* program that's syntactically valid. It may result in a "TypeError" when evaluated but it's not rejected as not being a program.
<__monty__>
Haskell is a typed language. `number :: String; number = 4` is *not* a haskell program. It is rejected by the type checker.
<infinisil>
Hmm I get what you mean, a type system in the type theory sense, but I don't think the term "type" is reserved for only those type systems
<gchristensen>
in the world of dependent types, it is
<infinisil>
That sounds reasonable :)
<sphalerite>
It's also a question of definitions. Is it a program if it exits with a type error? If not, then there's absolutely a type system in python.
<sphalerite>
sure, type-checking is intermingled with evaluation, but it's still there :)
<{^_^}>
raspberrypi/linux#1402 (by SebTC, 3 years ago, open): Pi3 bluetooth audio stutters with Wifi enabled
<adisbladis>
sphalerite: It's pretty common that those share a bus/antenna and wont ever work together
<__monty__>
Well the lines for python have gotten blurry with mypy.
<samueldr>
I think the resolution with rasbperry pis is always put the one you care more about on a quality usb dongle
<__monty__>
sphalerite: But a program can throw and catch TypeErrors internally. So that's a really weird definition. TypeErrors mean fail type checks, *unless* they're caught?
<__monty__>
*failed
<sphalerite>
samueldr: or use ethernet x)
<samueldr>
I assumed you needed wireless
<__monty__>
Also, in the type theory sense python absolutely doesn't have a type system : )
<sphalerite>
samueldr: well, I would need to buy a cable and plugs and a punchdown tool and fasteners and drill a hole in the wall (and it's a rented flat) so it's not a trivial option.
<gchristensen>
I was asking gustavderdrache about if there are any untyped languages above the assembly "everything is byte soup" level and they mentioned https://en.wikipedia.org/wiki/BLISS
<sphalerite>
one day I will live in a house with ethernet and it will be wonderful.
<gustavderdrache>
__monty__: python has type (PyObject) that's just a giant pile of cases for each value type (int, str, etc.) and then one catch-all reference type
<sphalerite>
samueldr: now, I'm not sure if I should get a bluetooth USB dongle or a WiFi USB dongle. Any advice?
<samueldr>
not really
<samueldr>
I guess if the reception is crap with the onboard wifi, get a wifi dongle
<__monty__>
gustavderdrache: But no type checker that runs before the program is evaluated. Which is what I meant by type system. Sorry for being imprecise.
<Diogenes->
Did I miss a giant convo on type systems? :/
<__monty__>
Also, doesn't small integers being special-cased sour the "python is unityped" view?
<gustavderdrache>
that's mostly an implementation detail
<__monty__>
And isn't nix untyped?
<gustavderdrache>
same with spidermonkey using NaN tagging
<gustavderdrache>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
<gustavderdrache>
^ i would point out that there is a type system in python, it just doesn't run early enough to catch programmer mistakes :)
<__monty__>
Well PyObject's an implementation detail too afaik.
<gustavderdrache>
the name, yes
<gustavderdrache>
but not the set of primitive and user-defined types
<__monty__>
And no, dynamic typing is not a type system.
<gustavderdrache>
why not?
<__monty__>
What does a type system do? Accept or reject a program. What does dynamic typing do? Throw errors sometimes.
<__monty__>
Those are two very different things.
<gustavderdrache>
i think you're conflating a type system with a type checker
<gustavderdrache>
dynamic typing does type checking and evaluation in the same pass, but static typing separates the two
<__monty__>
Nope.
<gustavderdrache>
why not?
<__monty__>
Because the whole point of a type system is to categorize programs as being valid or not.
drakonis has joined #nixos-chat
<gustavderdrache>
i agree with that point
<__monty__>
Programs with TypeErrors aren't invalid in python. They can be used perfectly fine. Or you can catch the TypeErrors and do something about them.
<__monty__>
*Valid* programs does not mean they don't have bugs.
<__monty__>
A crash because of a TypeError implies a bug not an invalid program.
<__monty__>
Type systems are also *always* formal methods, i.e., syntactical.
<__monty__>
Dynamic typing rarely is.
<__monty__>
If ever.
<__monty__>
Note that I'm not disparaging dynamically typed languages. It's just too bad both concepts use similar terminology. It confuses people.
<LnL>
I think gustavderdrache is talking about the "uni-typed" languages perspective
<__monty__>
That *is* the type theory perspective.
<__monty__>
It's uni-typed, i.e., everything has the same type, thus *nothing*'s rejected as an invalid/badly typed program.
drakonis has quit [Ping timeout: 245 seconds]
drakonis has joined #nixos-chat
drakonis has quit [Quit: WeeChat 2.6]
kenjis has quit [Ping timeout: 248 seconds]
drakonis has joined #nixos-chat
<__monty__>
gchristensen: Wow, just noticed the nixos manual's among the non-reproducible builds >.,
<__monty__>
*>.<
<gchristensen>
that one is a fairly easy fix
<gchristensen>
give the things it is pointing to an ID
<__monty__>
How about the gcc's? Weird that things can be reproducibly built with a non-reproducible compiler.
<gchristensen>
not sure
<gchristensen>
that is beyond my pay grade
<samueldr>
__monty__: reproducible among tested impurities
<samueldr>
I don't think r13y is testing different cpu families
<LnL>
things with parallel builds enabled often become not reproducible because of timing stuff
<__monty__>
We're not talking bit-for-bit reproducible?
<samueldr>
(which remind me I was supposed to setup that old sandybridge laptop to do that)
<gchristensen>
we are, __monty__
<gchristensen>
samueldr: actually r13y is running on some hardware which hydra has very few of
<__monty__>
samueldr: Then what did you mean?
<samueldr>
I'm thinking about stuff like SSE[2,3,4] instruction sets and similar things
<gchristensen>
all of r13y is running on modern hardware, so that is something
<samueldr>
yeah
<__monty__>
I'm gonna need more?
<__monty__>
It wouldn't be reproducible on hardware lacking those extensions?
<gchristensen>
many build pipelines do CPU sniffing to detect what the building host suppuorts
<samueldr>
some build systems look at the cpu, and enable all toggles depending on the cpu on the system it builds on
<__monty__>
Or not necessarily?
<samueldr>
and it's not trivial to hide the CPU from the program
<samueldr>
since they could be (and some are) just building and running a test program
<samueldr>
this is, I think, the main failure in all reproducible builds movements AFAICT
<samueldr>
in ARM-land it's way worse as there's more market segmentation on cpu features
<LnL>
actually it would be neat if we could cache/replace things like ./configure in builds
<LnL>
it's pretty slow and either nix knows what it should be or we don't want it to vary based on architecture etc
<__monty__>
samueldr: If you want reproducible no matter the available extensions what's keeping you from demanding architecture independence?
<samueldr>
hm?
<samueldr>
it's just the way those build systems are currently implemented
<__monty__>
Yeah, I'm saying aren't you asking for *too much*?
<samueldr>
though I don't understand the question
<samueldr>
no I'm not, it's a real issue that's causing spurious failures in some situations
<samueldr>
for a while the sage package was randomly failing since it built on a newer arch, and tested on an older arch, just sometimes
<samueldr>
and you can't come forward and say "my linux distro is 100% reproducible" if changing the hardware it built on changes the result!
<__monty__>
So we're heading towards a future where all software is restricted to what's available on the 8008?
gustavderdrache has left #nixos-chat [#nixos-chat]
<__monty__>
infinisil: I'm surprised Latex is not in the RFC btw.
<__monty__>
Or plain Tex even.
<qyliss>
Texinfo!
<qyliss>
Guix uses Texinfo :P
<__monty__>
That sounds like an unpopular gnu alternative to Tex. Like info pages : >
drakonis1 has joined #nixos-chat
<infinisil>
__monty__: I mean you can suggest it, but I very much doubt it has a chance
<qyliss>
GNU Info is great
<__monty__>
It'd be the only candidate that focuses on semantics rather than appearance though. And the syntax isn't that heavy.
drakonis_ has quit [Read error: Connection reset by peer]
<qyliss>
The problem is it's always been considered a man alternative rather than a web alternative
<infinisil>
texinfo sounds like it might have a slight chance :)
<__monty__>
It's also the only one you wouldn't have to convince anyone of is at least as powerful as docbook.
drakonis_ has joined #nixos-chat
<qyliss>
__monty__: I'm not sure you could make that argument about asciidoc
<qyliss>
Since I believe it was designed to be a docbook syntax or something
<__monty__>
People aren't convinced it's as powerful. There was discussion earlier where someone claimed it probably didn't have custom blocks.
<samueldr>
it does
<__monty__>
That's not the point.
<__monty__>
The point is not everyone's convinced it's as powerful.
<gchristensen>
on the contrary, I feel it is too powerful
<__monty__>
I'm sad man pages are the de facto format for cli docs. I can't wrap my head around why they don't allow inter- and intradocument links : (
<__monty__>
gchristensen: Asciidoc or Tex/Latex?
<qyliss>
__monty__: info does ;)
drakonis1 has quit [Ping timeout: 252 seconds]
<__monty__>
I know, but I hate the info reader. It feels like you need to learn emacs to be able to use info pages.
<infinisil>
__monty__: Yeah man pages are a bit too non-interactive for me too
<infinisil>
__monty__: And agree with that too, I tried the info reader once and it felt weird
<infinisil>
Tried to configure it for vim commands, but that didn't seem to be supported very well
<qyliss>
I'm told that pinfo is the way to go if you're not Emacs
<infinisil>
qyliss: :O
<__monty__>
Man pages are also terribly non-discoverable. I've been to ##linux to ask how to find documentation on some kernel stuff. Was told to RTFM >.< I was literally asking how to find the FM to R.
<infinisil>
qyliss: Trying it out, that's pretty nice
<qyliss>
Most kernel stuff isn't documented in man pages
<qyliss>
(or at all...)
<infinisil>
Suddenly I'm also convinced of texinfo
<qyliss>
lmao
<__monty__>
A lot of it *is* though. And this happened to be.
<infinisil>
Well, I haven't seen the source yet
<__monty__>
I asked where to find the *docs* though, not specifically man pages.
<infinisil>
qyliss: If we had a full texinfo manual.. Damn that would be nice
<infinisil>
Like jumping from options to service docs to nix funciton definitions
<__monty__>
Woah, pinfo can compose and send mail?
<__monty__>
Does it fall back to man pages automatically if info pages aren't available?
<__monty__>
And does it work its linking magic for man pages?
<qyliss>
In Emacs man pages are links
<qyliss>
Like, man page references
<qyliss>
SEE ALSO sections are links, etc.
<infinisil>
I'm now convinced of Markdown because everybody already knows it, reST because it has great support and adoption via sphinx, asciidoc because it seems very well designed, texinfo because of its interactivity and power
<qyliss>
I plan on at some point generating info pages for the Nix manual with pandoc
<qyliss>
Or at least trying it
<qyliss>
Not sure how well it would work
<qyliss>
I'd like that for Spectrum too
<qyliss>
I don't want to write texinfo (or make other people do so), but I'd like info pages
<infinisil>
It doesn't seem like the easiest format to write indeed
<qyliss>
I'm planning to use asciidoc
<infinisil>
Though it does have an advantage with this
<infinisil>
Because if people see asciidoc or rst, they might confuse it with markdown and end up using the wrong syntax because of that
<infinisil>
Whereas with texinfo (or docbook for that matter) it's immediately obvious it's not markdown :)
<qyliss>
I'd hope that a .adoc extension or whatever would be enough to make people realise that it's not markdown?
<__monty__>
How about a documentation EDSL in nix?
<__monty__>
: >
<infinisil>
> standards
<{^_^}>
undefined variable 'standards' at (string):272:1
<__monty__>
I just don't get it. reST is pretty nice and has worked out *really* well for the python community.
<__monty__>
I don't think anyone wants to author in texinfo though. I imagine it's not much better than PerlPOD or troff.
<infinisil>
Probably
drakonis1 has joined #nixos-chat
<infinisil>
qyliss: Regarding the conversion from asciidoc to texinfo, how well do you think that would work? Which texinfo features wouldn't be available?
<__monty__>
My Scribble and Latex suggestions were serious btw.
<__monty__>
They're the only formats so far that focus on substance over form.
<qyliss>
infinisil: no idea
<qyliss>
I haven't really thought about it beyond what I already described
<infinisil>
__monty__: Link to scribble? ddg isn't very good at finding it
<infinisil>
I guess we could have it evaluate nix code examples perhaps?
<drakonis>
yes
<__monty__>
Why is it good? Because authors can focus on *what* they're writing rather than worry about what the result'll look like. `nixos-option(somename) some explanation link(othersection) more explanation emph(important words) note(Some note that'll be formatted to stand out from the rest of the text)`
<drakonis>
you could do a lot of good stuff
<infinisil>
__monty__: Don't all markup formats achieve that? It's just *emph* or [link](othersection), instead of the scribble syntax
<qyliss>
No
<qyliss>
e.g. in GFM when you have to manually write anchor links or whatever
<qyliss>
you're focusing on the output
<__monty__>
The whole shtick of "mark*down*" formatting languages is also to make the formatting *look* like the output more-or-less.
<drakonis>
racket is like writing latex
<drakonis>
in this particular usecase
<__monty__>
Yep, it's why I thought of it : )
<__monty__>
Latex without the scary archaic syntax : )
<drakonis>
its not scary/archaic
<drakonis>
its workable
<drakonis>
racket on the other hand is a full language and can have a lot more available than latex
<__monty__>
Markdown's reliance on HTML is a huge problem imo, btw. It means you basically *have* to convert *to* HTML and from there to all the other formats like pdf and epub but also troff.
<__monty__>
Tex is a full language too, drakonis.
<drakonis>
i'm aware
Jackneill has joined #nixos-chat
<infinisil>
Hm I'm not fully convinced of this, in the end people writing more semantically doesn't seem to be all that useful
<adisbladis>
__monty__: Totally agree. I find I pretty much _always_ end up having some in-line html.
<drakonis>
having better docs is the path forward
<__monty__>
infinisil: The alternative is people need to look up what formatting was used for some concept in the rest of the docs.
<infinisil>
How do you mean that?
<samueldr>
infinisil: totally disagree, semantic writing is the way to go, otherwise you'd better go for word docx
<infinisil>
I mean it might be nice
<__monty__>
Rather than being able to say "Ah, nixos-option(something)" They need to figure out whether the rest of the docs use `some-option` or *some-option* or whatever other markdown-esque syntax, or maybe even <div class=nixos-option>some-option</div>.
<infinisil>
But ultimately having a semantic format isn't the only aspect of a doc format
<samueldr>
and adding semantic helpers specific to nix/nixpkgs/nixos is a big deal, saying [nixos-option:boot.kernelPackages] and that automatically does the hard work is amazingly good
<adisbladis>
I just had a thought; Why aren't we writing docs in Nix?
<infinisil>
We also need it to have good tooling, be easy to write, etc.
<samueldr>
adisbladis: something something not a general purpose language
<__monty__>
adisbladis: I guess you missed my EDSL suggestion. That was not 100% a joke.
<infinisil>
samueldr: We believe this can be done with both reST and asciidoc, they're customizable
<adisbladis>
samueldr: That's a tired meme imho
<samueldr>
adisbladis: :)
<adisbladis>
__monty__: Yep, missed it.
<samueldr>
infinisil: yes, and it should
<adisbladis>
I don't think it's a bad idea
<infinisil>
I mean I can add scribble to the candidates of the RFC, but I don't think it stands a chance
<samueldr>
adisbladis: seriously speaking, I don't think it's a bad idea, but that's also delving deep in the nih territories, and needing to build the whole ecosystem around it
<__monty__>
infinisil: Yes but also : s. It depends heavily on the tooling. reST has custom directives for example. But I don't know any tools that can handle them. So you'd effectively have to extend the tools you use anyway. I think the story's similar for asciidoc.
<__monty__>
samueldr: No no. You'd write a nix EDSL that generates docbook or whatever.
<__monty__>
You wouldn't implement the entire ecosystem. Just the user-facing bit.
<infinisil>
That doesn't seem terrible either now, since linking to options and such becomes very natural
<infinisil>
We could even attach docs to values, a la `lib.types.str._docs`
Jackneill has quit [Remote host closed the connection]
<__monty__>
nn, fine folks
<infinisil>
Nighty night
<drakonis>
threadrippers are back
<drakonis>
64 cores, faster than intel and cheaper
<drakonis>
faster than intel's best
<infinisil>
Neat
<adisbladis>
drakonis: Also pcie 4.0
<drakonis>
yeah
<pie_[bnc]>
ugh isabelle looks like its gonna be a big pain to package
<pie_[bnc]>
but true i should look at that, hmm looks like they do still use the tar.gz there
<pie_[bnc]>
ok i feel really dumb now
<pie_[bnc]>
i somehow didnt think to just try running the binary they provided
<pie_[bnc]>
pie_[bnc]: pie_[bnc] pie_[bnc] what are you doing
<pie_[bnc]>
so what happened was the docs i was looking at didnt say to just run "isabelle jedit" to get the ide, it was on about using proof general, which is an emacs plugin
<pie_[bnc]>
then i got bogged down why that doesnt work
<pie_[bnc]>
then i figured out its deprecated
<pie_[bnc]>
then i ended up as above
<pie_[bnc]>
misleading docs are misleading
__monty__ has quit [Quit: leaving]
<clever>
sphalerite: mostly into the very low level stuff, havent looked into how the bluetooth or wifi directly function yet
* pie_[bnc]
wonders about creating mutable closures