(define xscreensaver (make <service>
#:provides '(xscreensaver)
#:start (make-forkexec-constructor
(list "/run/setuid-programs/xscreensaver" "-nosplash"))
#:stop (make-kill-destructor)))
(register-services xscreensaver)Guix uses #~ for G-expressions, for example.
Despite their similarities, keywords are used in a different way than identifiers or symbols. Keywords are intended for use (unquoted) as special markers in argument lists and in certain syntactic forms. For run-time flags and enumerations, use symbols instead of keywords. The example below illustrates the distinct roles of keywords and symbols.
Examples:
> (define dir (find-system-path 'temp-dir)) ; not '#:temp-dir
> (with-output-to-file (build-path dir "stuff.txt")
(lambda () (printf "example\n"))
; optional #:mode argument can be 'text or 'binary
#:mode 'text
; optional #:exists argument can be 'replace, 'truncate, ...
#:exists 'replace)I now use req-package so I don't even have to download anything.
I do miss the old style of one file per "kind" though. Doesn't mean use-package is bad but somehow I like having a FS-level idea of my emacs config.
https://github.com/mitchty/dotfiles/blob/master/emacs.org
(actually i use org mode to compile all of my dot files based on predicates, i'm double plus weird here >.<)
I really rather like this way of working with things as it just sticks stuff into ~/.emacs.d/elpa. I can rsync that around if i need/want. And it even bootstraps itself if i'm opening things on a new system. I just like keeping each package in its own use-package declaration so I can have config+setup all in one spot.
I might try to make one from scratch using yours as an inspiration. Just to see how my mindset evolved along the years.
Aka I can customize my dot files based on if i'm going to a bsd/mac/linux box with(out)/nix/perl/haskell/git/whatever and have an easy way to copy things over the top of things or not.
I declared dot file bankruptcy a few years ago and this is my "perpetual penultimate dot file solution" (yes I'm making a joke at my own expense with penultimate here).
But this new setup is easily the most sane I've found so far. Most dot file management uses softlinks which sucks for rsyncing, or some hokey templating language.
All mine amounts to is just a stupid .el file that holds predicate definitions that just controls via stupid elisp when an org babel block gets tangled out into a file. Its pretty simple and straightforward. Wonder if I should do some sort of show and tell for it or not.
Good luck! Hope it helps or inspires something better.
Elsewhere people are saying it's just Scheme. I'm sure I could find a parser for that in Python, and maybe if I'm really lucky that parser will record whitespace and comment nodes, and have a reverse transformation, but do I really want to be writing error prone 20-line AST visitors just to tweak an integer setting? (No, I most certainly do not, and I consider design decisions like this a massive code smell that'd ward me off any further investigation of a system)
edit: downvotes? Is this really such a difficult concept?
edit 2: so apparently the big whoopsie was insulting the religion that is LISP. Yes, using a turing complete language for config syntax causes pain. Nobody does this stuff in the real world for a reason. Deal with it, meanwhile go back to obsessing over novelty code-is-data academic exercises on your obsolete Symbolics machines, you'll cause less damage that way.
All these assuming you want to implement the thing yourself. Which is fine, S-Expressions are one of the easiest tree syntaxes to parse. But there are already libraries that can do this for you (including full Lisp/Scheme interpreters) and some of them can even 'pretty format' the code like the quoted snipped above.
So generally speaking this wont be a problem in practice.
EDIT: Complaining about downvotes and then going on a tirade about how Lisp users are cave-dwellers is not constructive. Personally I think your argument was a valid concern (and I just went to try to find a Scheme parser in Python to help you), but you're not helping your case.
Also, like it or not, but both of the most widely-used editors (emacs and vim) both have turing-complete "configuration" languages. By your statements, that would make the majority of programmers academic cave-dwellers (oh wait... :P).
https://insights.stackoverflow.com/survey/2017#technology-mo...
If you include full-blown IDEs in your definition of editor (which I think you should), Visual Studio was the most widely used editor among all the 19,772 people that responded to this question in the Stack Overflow Developer survey 2017.
Notepad++ was the second-most popular editor.
Sublime Text was the third-most popular editor.
Vim was the fourth-most popular editor.
Visual Studio Code, IntelliJ, Atom, Eclipse, Android Studio, PHPStorm, Xcode, NetBeans and PyCharm followed.
Emacs was the 14th-most popular editor.
That may sometimes be so, but only as a general consequence of "programming computers causes pain". You can do something complicated, which can have a bug; then someone comes along with a half-conceived thought like, "that solution shouldn't have been doble in the config language; therefore config language caused pain".
A non-computational config language also causes pain. Sometimes to the point that a Turing-complete language is used to generate a configuration. Then you have pains like "# this was generated ... don't touch!".
Add far as AST visitors, you're probably better off with XPath/XSLT tree transformations. (Anyone know of a suitable library?)
On the other hand, the don't-swim-upstream approach would be to use one of the best programming languages in existence, Scheme, you do your config management tasks directly, rather than an arm's-length parse, modify, write approach.
You will lose any comments like this though:
[user]
name = My Name ; that's my name!
$ cat my-config.xml
<root>
<!-- i am a comment -->
<thing attr="foo">
<!-- i am another comment -->
<setting>value</setting>
</thing>
</root>
$ cat c.py
import lxml.etree
doc = lxml.etree.fromstring(file('my-config.xml').read())
for setting in doc.xpath('.//thing/setting'):
setting.text = 'set without screwing up the file'
print lxml.etree.tostring(doc)
$ python c.py
<root>
<!-- i am a comment -->
<thing attr="foo">
<!-- i am another comment -->
<setting>set without screwing up the file</setting>
</thing>
</root>Edit: downvotes are because you're sort of insulting Lisp (which is older than you and all your "best practices") with an ignorant complaint.
I recognized it as lisp right away, but I share the complaint about the format. If you want to write a lisp program then do so. If you want to format something for human readability it's probably a good idea to do it differently. This is just a opinion of course, but I suspect it's not an uncommon one.
Furthermore, anything that tricks you into learning Scheme is a good thing. Like eating vegetables.
Ignorant of the cave-dwelling depths some would go to ensure the practicality of the arcane religious icon that is LISP as a massively overgeneral solution to a problem, at the cost of all downstream users who must now "just switch to Guile" or link against chunks of a C compiler just to introspect a config? Maybe, but I'm content with that.
> Elsewhere people are saying it's just Scheme. I'm sure I could find a parser for that in Python, and maybe if I'm really lucky that parser will record whitespace and comment nodes, and have a reverse transformation, but do I really want to be writing error prone 20-line AST visitors just to tweak an integer setting? (No, I most certainly do not, and I consider design decisions like this a massive code smell that'd ward me off any further investigation of a system)
XML satisfies all the above: no AST visitors, no custom parsing routines, no attempting to solve the halting problem in order to introspect a simple scalar value.
What you're saying is that the same is "possible" with Scheme. At least one followup comment (finally) described an algorithm that would actually allow machine-driven file changes, but we're still left with rather than a working out of the box solution, a description of an algorithm that "might someday work" and that's not the sort of thing I want to be dealing with while building business solutions on somebody else's dime, which drives my conclusion above: this config file syntax is not for me, and my original comment explained precisely why.
Sorry for trying to answer your question then...
Nix has limited "Nix-expressions" which resulted in a bunch of bash scripts to get around the limitations, and Systemd ends up requiring C services or bash scripts because it has a limited INI-like syntax. On the opposite end, GuixSD is entirely configured, packaged, and maintained with Guile.
It was my understanding that issue was best handled by having multiple files and having one take precedence over the other. Like having a global config that is pushed to the machine and allowing the user to locally override values set globally in the local config.
Another solution to multiple parties needing to define configuration for the same area without stomping all over each other would be to have a directory wherein all files contained therein are applicable. That way multiple people can maintain their own particular files but some precedence has to be established.
Even if you do need to do this I wouldn't think it would be that hard to modify lisp with lisp.
'foo
(quote foo)
'(1 2 3)
(quote (1 2 3))
#:foo is a keyword argument and '(apache httpd) is a quoted list containing the symbols apache and httpd.
Angled brackets have no special meaning, they are just part of the identifier.
GCL: https://www.gnu.org/software/gcl/
CLISP: http://clisp.org/
I think we can blame the use for lifetimes entirely on the Rusties.
(quote something)
Am I correct that the equivalent to this service file, in the world of systemd, is a binary file ?