<infinisil>
(it's not really runnable by anyone other than me though, and no docs)
<kisik21>
why not rubnnable by others?
<kisik21>
too arcane config?
benley has joined #nix-lang
<infinisil>
Can only be run with some rabbitmq frontend, {^_^} in this case (made by gchristensen), and it needs some stateful setup (like nix-index, nixpkgs version)
<infinisil>
I'll fix all of those things eventually
<ldlework>
what do you mean by stateful setup?
<clever>
make a nixos module that manages both!!
<infinisil>
ldlework: I ran nix-index manually at some point so it has database to nix-locate with
<infinisil>
clever: You mean to run nix-index before it starts?
<clever>
infinisil: and configure all the other state, and run the service via systemd
<infinisil>
Hmm that might be a pretty good idea
<infinisil>
Dealing with this on the haskell side is annoying
<infinisil>
clever: Although, is it reasonable to expect people to only be able to run the bot if they use NixOS?
<infinisil>
I guess that's not too bad
<clever>
infinisil: the module also acts as a document listing what variables have to be set and what commands you must run
<clever>
that wont deal with inter-service deps, but that can run a nixos service
<gchristensen>
but also it is pretty reasonable to expect them to run nixos
<infinisil>
Yeah, considering the bot's target audience
<gchristensen>
and the current actual number of operators
<infinisil>
Yes :P
<clever>
good point :P
<gchristensen>
I catch myself sometimes thinking poeple don't actually want to run nixos, despite them hiring me for my expertise, and me believing nixos is generally the best choice... I have to remind myself no, stand tall for nixos
<clever>
gchristensen: a friend i know works for a company that is very anti-nix
<clever>
because the previous guy to introduce them to nix, was still learning it at the time
<infinisil>
Nix solved problems I didn't even know I had before I used it!
<infinisil>
Or rather in my case: Nix made me a person that would've had problems Nix solves if I didn't use Nix
<clever>
infinisil: the original reason i installed nixos, was to fix a bug only nixos had, lol
<infinisil>
What was it?
<clever>
clicking links in teamspeak did not open chromium
<clever>
teamspeak uses libredirect (a nix only wrapper), to force it to read files from the store
<clever>
and chromium deadlocks if that is in LD_PRELOAD
<clever>
i was initialy a firefox user, and was unable to reproduce it, but liked the idea of nixos and kept using it
<infinisil>
Neat
<clever>
~2 months later, i switched to chrome, and then reproduced it, and had to fix it :P
<clever>
and maybe a year or 2 after that, i was helping somebody else fix a different chrome issue with selinux, and squeezed in the redirect fix
<ldlework>
things like libredirect freak me out
<clever>
why?
<ldlework>
I imagine being at a Dockercon trying to sell nix and trying to explain that libredirect is even a thing and not having the audience stand up and leave
<ldlework>
Having to radically fork software just to get it to work is harrowing at best.
<ldlework>
It kind of reminds me of Emacs. Some people are willing to go all in, but it is clear that the vast majority is not.
<ldlework>
Are you trying to explain that people should discover this functionality by browsing the source?
<infinisil>
ldlework: Hmm yes? :P
<ldlework>
:|
<infinisil>
As long as we don't have some kind of docstrings, that's the best option
<infinisil>
A wiki entry would just duplicate these docs
<infinisil>
And possibly become outdated
<ldlework>
source code comments are not a good way to document things
<ldlework>
they are a good way to explain implementation decisions
<infinisil>
It works fairly well though
<infinisil>
Assuming you're comfortable browsing the source
<ldlework>
documentation is one of the biggest things I have to contend with with people putting nixos down
<ldlework>
and there's nothing to defend
<infinisil>
I guess what would work is to extract the docs for every function with some automated script from nixpkgs/lib and put that into the nixpkgs docs
<ldlework>
if you do that, then lib has to be well organized since the documentation becomes homoioconic with the implementation
<ldlework>
or whatever
<ldlework>
lol
<infinisil>
Not sure what you mean by that
<kisik21>
Idlework: documentation? you need no documentation if you have nixpkgs checkout
<infinisil>
Just get the docs right above the functions definitions
<ldlework>
the structure of the documentation will be the same as the structure of li
<infinisil>
The bitwise not concerns me a bit though
<infinisil>
It just subtracts one..
<clever>
-1 is true
<infinisil>
Oh wait
<infinisil>
> builtins.sub (-1) 10
<{^_^}>
-11
<infinisil>
> builtins.sub (-1) 0
<{^_^}>
-1
<clever>
> lib.not true
<{^_^}>
attribute 'not' missing, at (string):171:1
<clever>
> lib.not 1
<{^_^}>
attribute 'not' missing, at (string):171:1
<clever>
> lib.bitNot 1
<{^_^}>
-2
<clever>
wut?
<infinisil>
Ah never mind, it's correct
<infinisil>
bitwise not in 2s-complement is -x-1
<infinisil>
=-1 -x
<infinisil>
= builtins.sub (-1)
<demize>
infinisil: Next, implement an assembly interpreter.
<infinisil>
On it!
<ldlework>
> better docs don't come from complaining - I'm reporting the fact that the current documentation is indefensible to the typical linux user which doesn't bode well for Nix and you tell me to bugg off and write the documentation myself. This attitude doesn't bode well either. I am just making observations.
<{^_^}>
error: syntax error, unexpected ')', expecting ID or OR_KW or DOLLAR_CURLY or '"', at (string):172:1
<ldlework>
Second time in two days I've heard this sort of "I'm fine with the state of things, but you go fix what you don't like", despite the fact I've contributed to the wiki and nix mode and I am not talking about myself since I am ready to do those things.
<infinisil>
Sorry, didn't mean to sound rude
<ldlework>
Me either, I just wanted to stand ground a little there.
<infinisil>
The wiki is a very good development, comes along much quicker than nixpkgs docs lol
<ldlework>
"patch the source" and "read the source" are just hard pills to swallow for most
<ldlework>
most people are just going to want an OS who's config they can put in git and reproduce on a new workstation / server
<ldlework>
the culture of package management is extraneous
<ldlework>
well, ought to be
<ldlework>
it is absolutely central to the experience right now
<samueldr>
ldlework: one of the bigger issues w/r/t docs is how huge the endeavor (nixpkgs) is, the current set of maintainers is barely managing enough to not accrue too much debt with regards to updates (implmenting stuff, PRs, etc)
<ldlework>
but lib?
<samueldr>
which in other words do mean: we need people to stop doing things and *actually* document things
<ldlework>
yeah, I acknowledge timeline and priority too
<ldlework>
i am not balking against the state of things
<ldlework>
but the attitude i'm hearing regarding it
<samueldr>
and yeah, there's probaby a bit of a case of the people actually knoweldgeable enough to write the docs don't feel the need to (since they know)
<samueldr>
it could be second nature to them to use *anything*...
<samueldr>
not knowing what you don't know is hard :/
<samueldr>
or uh, with the right amount of negation in there :)
<ldlework>
samueldr: which is pretty typical I'd say
<ldlework>
so no special blame to lay or anything
<samueldr>
though I have to say that docstrings in lib/* files are not always present, but are generally good currently
<samueldr>
but one of the issues right now is bikeshedding this :/
<ldlework>
it is almost an intrinsic game theory thing what you just observed, that experts don't feel a pressing need for documentation of what they already understand but are the best ones suited to write it
<infinisil>
How about creating a priority list for stuff that needs to be improved in regards to docs