(defvar esy/publish-root-directory
(file-name-directory load-file-name))
-(defvar esy/publish-org-directory
+(defvar esy/publish-src-directory
(file-name-as-directory (expand-file-name
- "org"
+ "src"
esy/publish-root-directory)))
(defvar esy/publish-org-posts-directory
(file-name-as-directory (expand-file-name
"posts"
- esy/publish-org-directory)))
+ esy/publish-src-directory)))
(defvar esy/publish-out-directory
(file-name-as-directory (expand-file-name
"posts"
esy/publish-out-directory)))
-(defvar esy/publish-assets-directory
- (file-name-as-directory (expand-file-name
- "assets"
- esy/publish-root-directory)))
-
(defun esy/publish-post-to-dom (file)
(with-current-buffer (find-file-noselect
(expand-file-name
(delete-blank-lines)))
(defun esy/publish-posts-prepare-index (&rest _)
- (dolist (dir (list esy/publish-org-posts-directory esy/publish-org-directory))
+ (dolist (dir (list esy/publish-org-posts-directory esy/publish-src-directory))
(with-current-buffer (find-file-noselect (expand-file-name "index.org" dir))
(org-update-all-dblocks))))
(rx (or ".html"
".ico"
".svg"
+ ".png"
".xml"
".css")
eos))))
(org-publish-project-alist
(list '("all" :components ("assets" "org"))
(list "assets"
- :base-directory esy/publish-assets-directory
+ :base-directory esy/publish-src-directory
:publishing-directory publishing-directory
- :base-extension "svg\\|ico\\|css"
+ :base-extension "svg\\|ico\\|css\\|png"
:publishing-function #'org-publish-attachment)
(list "org"
:completion-function #'esy/publish-completion-function
- :base-directory esy/publish-org-directory
+ :base-directory esy/publish-src-directory
:publishing-directory publishing-directory
:preparation-function #'esy/publish-posts-prepare-index
:completion-function #'ignore
--- /dev/null
+<svg width="400" height="400" xmlns="http://www.w3.org/2000/svg" data-background-color="#111111" preserveAspectRatio="xMidYMid meet">
+ <g>
+ <title>Layer 1</title>
+ <rect width="400" height="400" x="0.00002" y="0" fill="#111111" data-fill-palette-color="background" id="background"/>
+ <g id="tight-bounds" transform="matrix(1.42967, 0, 0, 1.43769, 244.049, 9.88795)">
+ <svg viewBox="0 0 154.0987012987013 247.2" height="247.2" width="154.0987" id="svg_1" x="-110.21414" y="7.95458">
+ <svg viewBox="0 0 154.0987012987013 247.2" height="247.2" width="154.0987" id="svg_10">
+ <svg viewBox="0 0 154.0987012987013 247.2" height="247.2" width="154.0987" id="svg_18">
+ <svg viewBox="0 0 154.0987012987013 247.2" height="247.2" width="154.0987" id="svg_26">
+ <svg viewBox="0 0 154.0987012987013 247.2" height="247.2" width="154.0987" id="svg_32">
+ <svg width="154.0987" viewBox="2.049999952316284 -37.599998474121094 24 38.5" height="247.2" data-palette-color="#cfdfd5" id="svg_37">
+ <g class="undefined-text-0" data-fill-palette-color="primary" id="svg_38">
+ <path d="m24.8,-9l1.25,0.5q-0.55,2.25 -1.75,4q-1.2,1.75 -2.9,2.95q-1.7,1.2 -3.75,1.83q-2.05,0.62 -4.3,0.62l0,0q-2.85,0 -4.95,-0.93q-2.1,-0.92 -3.52,-2.47q-1.43,-1.55 -2.13,-3.55q-0.7,-2 -0.7,-4.15l0,0q0,-1.65 0.43,-3.35q0.42,-1.7 1.27,-3.18q0.85,-1.47 2.13,-2.57q1.27,-1.1 2.97,-1.55l0,0q-2.4,-1.5 -3.47,-3.45q-1.08,-1.95 -1.08,-4.1l0,0q0,-1.7 0.65,-3.38q0.65,-1.67 1.93,-2.95q1.27,-1.27 3.15,-2.07q1.87,-0.8 4.27,-0.8l0,0q1.45,0 2.75,0.33q1.3,0.32 2.3,1.07q1,0.75 1.6,1.93q0.6,1.17 0.6,2.87l0,0q0,1.75 -0.65,3.05q-0.65,1.3 -1.95,1.3l0,0q-0.55,0 -1.2,-0.28q-0.65,-0.27 -1.35,-0.97l0,0q0.7,-0.25 1.13,-1.28q0.42,-1.02 0.42,-2.07l0,0q0,-0.95 -0.32,-1.55q-0.33,-0.6 -0.83,-0.93q-0.5,-0.32 -1.05,-0.42q-0.55,-0.1 -1,-0.1l0,0q-1.1,0 -1.9,0.45q-0.8,0.45 -1.3,1.2q-0.5,0.75 -0.75,1.75q-0.25,1 -0.25,2.05l0,0q0,1.4 0.4,2.7q0.4,1.3 1.23,2.4q0.82,1.1 2.07,1.92q1.25,0.83 2.95,1.28l0,0q-1.6,0.4 -2.85,1.42q-1.25,1.03 -2.07,2.45q-0.83,1.43 -1.25,3.08q-0.43,1.65 -0.43,3.2l0,0q0,1.35 0.35,2.6q0.35,1.25 1.08,2.17q0.72,0.93 1.85,1.5q1.12,0.58 2.72,0.58l0,0q1.2,0 2.5,-0.35q1.3,-0.35 2.43,-1q1.12,-0.65 2,-1.6q0.87,-0.95 1.27,-2.15l0,0z" fill="#cfdfd5" data-fill-palette-color="primary" id="svg_39"/>
+ </g>
+ </svg>
+ </svg>
+ </svg>
+ </svg>
+ </svg>
+ </svg>
+ <rect width="154.0987" height="247.2" fill="none" visibility="hidden" id="svg_23" y="7.95458" x="-110.21414"/>
+ </g>
+ </g>
+
+</svg>
\ No newline at end of file
--- /dev/null
+#+TITLE: Eshel Yaron
+#+AUTHOR: Eshel Yaron
+#+DESCRIPTION: Personal home page of Eshel Yaron
+#+KEYWORDS: eshel language emacs programming prolog
+#+OPTIONS: toc:nil ^:{}
+
+Welcome to [[./index.org][my website]], the one true source of reliable curated information about me and my activities.
+
+#+begin_src prolog
+ ?- likes('Eshel', Stuff).
+ Stuff = 'logic programming';
+ Stuff = 'linguistics';
+ Stuff = 'cognition';
+ Stuff = 'functional programming';
+ Stuff = 'The cyber';
+ Stuff = 'type systems';
+ Stuff = 'coffee ☕️';
+ Stuff = 'free software'.
+#+end_src
+
+* Recent Posts
+:PROPERTIES:
+:CUSTOM_ID: recent-posts
+:END:
+#+BEGIN: posts :dir "/Users/eshelyaron/checkouts/eshelyaron.com/src/posts" :limit 5
+#+END:
+
+
+* Projects
+:PROPERTIES:
+:CUSTOM_ID: projects
+:END:
+
+** =sweep=: SWI-Prolog Embedded in Emacs
+:PROPERTIES:
+:CUSTOM_ID: sweep
+:END:
+
+[[https://git.sr.ht/~eshel/sweep][Sweep]] is an Emacs module which uses the C interfaces of both
+SWI-Prolog and Emacs to bring the two together into one address space.
+
+For more details, see [[file:sweep.org][the Sweep manual]].
+
+** Sourcehut GraphQL client for SWI-Prolog
+:PROPERTIES:
+:CUSTOM_ID: sourcehut-pl
+:END:
+
+[[https://git.sr.ht/~eshel/sourcehut.pl][sourcehut.pl]] - a SWI-Prolog package for interacting with the GraphQL
+API of sourcehut instances.
+
+=sourcehut.pl= can be used to automate maintenance tasks for project
+hosted on sourcehut, for example to attach a build artifact to a given
+tag of a git repository from within SWI-Prolog:
+
+#+begin_src prolog
+ ?- sourcehut_git_repository("eshel", "sourcehut.pl", Repo, []),
+ get_dict(id, Repo, RepoId),
+ sourcehut_git_upload_artifact(RepoId, "v0.1.2", "/tmp/foo/baz.txt", Artifact, []).
+#+end_src
+
+** [[https://git.sr.ht/~eshel/eshellisp][eshellisp]]
+:PROPERTIES:
+:CUSTOM_ID: eshellisp
+:END:
+
+A [[https://git.sr.ht/~eshel/eshellisp][Scheme Lisp interpreter implemented in SWI-Prolog]].
+
+#+begin_src sh
+ $ cat scheme/repl.scm
+ (define repl () (write (eval (read))) (repl))
+ (repl)
+
+ $ ./eshellisp scheme/repl.scm
+ % (cons (+ 1 2) 4)
+ % (3 . 4)
+#+end_src
+
+** [[https://git.sr.ht/~eshel/flymake-swi-prolog][flymake-swi-prolog.el]] and [[https://git.sr.ht/~eshel/diagnostics.pl][diagnostics.pl]]
+:PROPERTIES:
+:CUSTOM_ID: flymake-swi-prolog
+:END:
+
+=diagnostics.pl= is a SWI-Prolog package implementing a simple and
+extensible inteface for diagnosing issues with SWI-Prolog source code,
+exposing by default the powerful analysis used by the built-in
+SWI-Prolog IDE.
+
+=flymake-swi-prolog= is an Emacs Lisp package implementing a Flymake
+backend that leverages =diagnostics.pl= to provide diagnostics for
+SWI-Prolog source code in =prolog-mode= Emacs buffers.
+
+** [[https://git.sr.ht/~eshel/ropes.pl][ropes.pl]]
+:PROPERTIES:
+:CUSTOM_ID: ropes-pl
+:END:
+
+A (SWI-)Prolog implemantation of the [[https://en.wikipedia.org/wiki/Rope_(data_structure)][rope data structure]] for efficient
+massive string editing.
+
+Based on [[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.9450&rep=rep1&type=pdf][Ropes: An alternative to strings]].
+
+#+begin_src prolog
+test(edit) :-
+ string_rope("Hello, World!" , HW),
+ string_rope("Here be dragons", HD),
+ rope_split(HD, 8, _, D), % "Here be " + "dragons"
+ rope_split(HW, 7, H, W), % "Hello, " + "World!"
+ rope_split(W , 5, _, E), % "World" + "!"
+ rope_concat(H , D, HS),
+ rope_concat(HS, E, HE),
+ rope_string(HE, HF),
+ assertion(HF == "Hello, dragons!").
+#+end_src
+
+** [[https://github.com/oskardrums/ebpf][Erlang eBPF library]]
+:PROPERTIES:
+:CUSTOM_ID: erlang-ebpf
+:END:
+
+A low level interface to the [[https://ebpf.io/][Linux eBPF system]] for [[https://www.erlang.org/][Erlang]].
+
+
+** [[https://git.sr.ht/~eshel/eshelyaron.com][This website]]
+:PROPERTIES:
+:CUSTOM_ID: this-website
+:END:
+
+My first taste of web development, a practice that I have always
+refrained from conducting. Created with pure [[https://orgmode.org/][org-mode]] to ease the
+landing.
+
+Inspired by:
+- https://taingram.org/
+- https://sachachua.com/blog/
+- https://occasionallycogent.com/
--- /dev/null
+<svg viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg"><g id="SVGRepo_bgCarrier" stroke-width="0"></g><g id="SVGRepo_tracerCarrier" stroke-linecap="round" stroke-linejoin="round"></g><g id="SVGRepo_iconCarrier"> <path d="M3 8C3 7.06812 3 6.60218 3.15224 6.23463C3.35523 5.74458 3.74458 5.35523 4.23463 5.15224C4.60218 5 5.06812 5 6 5V5H18V5C18.9319 5 19.3978 5 19.7654 5.15224C20.2554 5.35523 20.6448 5.74458 20.8478 6.23463C21 6.60218 21 7.06812 21 8V16C21 16.9319 21 17.3978 20.8478 17.7654C20.6448 18.2554 20.2554 18.6448 19.7654 18.8478C19.3978 19 18.9319 19 18 19V19H6V19C5.06812 19 4.60218 19 4.23463 18.8478C3.74458 18.6448 3.35523 18.2554 3.15224 17.7654C3 17.3978 3 16.9319 3 16V8Z" stroke="#cfdfd5" stroke-width="2" stroke-linejoin="round"></path> <path d="M4 6L10.683 11.8476C11.437 12.5074 12.563 12.5074 13.317 11.8476L20 6" stroke="#cfdfd5" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path> </g></svg>
\ No newline at end of file
--- /dev/null
+<svg fill="#000000" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg" xml:space="preserve"><g id="SVGRepo_bgCarrier" stroke-width="0"></g><g id="SVGRepo_tracerCarrier" stroke-linecap="round" stroke-linejoin="round" stroke="#CCCCCC" stroke-width="4.8"><path d="M21.327 8.566c0-4.339-2.843-5.61-2.843-5.61-1.433-.658-3.894-.935-6.451-.956h-.063c-2.557.021-5.016.298-6.45.956 0 0-2.843 1.272-2.843 5.61 0 .993-.019 2.181.012 3.441.103 4.243.778 8.425 4.701 9.463 1.809.479 3.362.579 4.612.51 2.268-.126 3.541-.809 3.541-.809l-.075-1.646s-1.621.511-3.441.449c-1.804-.062-3.707-.194-3.999-2.409a4.523 4.523 0 0 1-.04-.621s1.77.433 4.014.536c1.372.063 2.658-.08 3.965-.236 2.506-.299 4.688-1.843 4.962-3.254.434-2.223.398-5.424.398-5.424zm-3.353 5.59h-2.081V9.057c0-1.075-.452-1.62-1.357-1.62-1 0-1.501.647-1.501 1.927v2.791h-2.069V9.364c0-1.28-.501-1.927-1.502-1.927-.905 0-1.357.546-1.357 1.62v5.099H6.026V8.903c0-1.074.273-1.927.823-2.558.566-.631 1.307-.955 2.228-.955 1.065 0 1.872.409 2.405 1.228l.518.869.519-.869c.533-.819 1.34-1.228 2.405-1.228.92 0 1.662.324 2.228.955.549.631.822 1.484.822 2.558v5.253z"></path></g><g id="SVGRepo_iconCarrier"><path d="M21.327 8.566c0-4.339-2.843-5.61-2.843-5.61-1.433-.658-3.894-.935-6.451-.956h-.063c-2.557.021-5.016.298-6.45.956 0 0-2.843 1.272-2.843 5.61 0 .993-.019 2.181.012 3.441.103 4.243.778 8.425 4.701 9.463 1.809.479 3.362.579 4.612.51 2.268-.126 3.541-.809 3.541-.809l-.075-1.646s-1.621.511-3.441.449c-1.804-.062-3.707-.194-3.999-2.409a4.523 4.523 0 0 1-.04-.621s1.77.433 4.014.536c1.372.063 2.658-.08 3.965-.236 2.506-.299 4.688-1.843 4.962-3.254.434-2.223.398-5.424.398-5.424zm-3.353 5.59h-2.081V9.057c0-1.075-.452-1.62-1.357-1.62-1 0-1.501.647-1.501 1.927v2.791h-2.069V9.364c0-1.28-.501-1.927-1.502-1.927-.905 0-1.357.546-1.357 1.62v5.099H6.026V8.903c0-1.074.273-1.927.823-2.558.566-.631 1.307-.955 2.228-.955 1.065 0 1.872.409 2.405 1.228l.518.869.519-.869c.533-.819 1.34-1.228 2.405-1.228.92 0 1.662.324 2.228.955.549.631.822 1.484.822 2.558v5.253z"></path></g></svg>
\ No newline at end of file
--- /dev/null
+#+TITLE: Take on Recursion
+#+SUBTITLE: My take on a recursive Elisp function for accumulating a list while walking up an AST
+#+DESCRIPTION: A post by Eshel Yaron describing his take on a recursive Elisp function for accumulating a list while walking up an AST
+#+KEYWORDS: emacs
+#+DATE: 2023-04-01
+
+Over at [[https://takeonrules.com]], Jeremy Friesen has [[https://takeonrules.com/2023/03/25/using-built-in-emacs-29-tree-sitter-package-to-get-qualified-ruby-function-name/][a couple of]] [[https://takeonrules.com/2023/03/25/using-built-in-emacs-29-tree-sitter-package-to-get-qualified-ruby-function-name/][recent posts]]
+about an Emacs command he wrote for grabbing the qualified name of the function
+at point in Ruby files.
+
+I don't know much about Ruby, but the way he implemented this command caught my
+attention because he's relying on the new =treesit= package from Emacs 29 to
+examine the syntax tree of his Ruby code, and I've been playing around with this
+nice parsing framework myself recently.
+
+Apparently, Ruby /functions/ can reside within nested /modules/. Jeremy's
+command thus leverages the function ~treesit-defun-at-point~ to obtain the
+syntax tree node corresponding to the Ruby function at point, and calls a
+recursive helper function called ~jf/treesit/module_space~ that walks up the
+syntax tree and accumulates the names of the enclosing modules it finds along
+the way to the root of the syntax tree. There's just a tiny problem which is
+that this helper function accumulates the module names in a rather awkward
+manner... As Jeremy notes:
+
+#+begin_quote
+The list returned by ~jf/treesit/module_space~ is ~'(nil ("Hello" ("World")))~;
+which is a ugly but workable. Perhaps someone will write to me with a refactor
+of this code.
+#+end_quote
+
+Let's have a look at this function's implementation:
+
+#+begin_src emacs-lisp
+ (defun jf/treesit/module_space (node)
+ (when-let* ((parent (treesit-parent-until
+ node
+ (lambda (n) (member (treesit-node-type n)
+ '("class" "module" "assignment")))))
+ (parent_name (treesit-node-text
+ (car
+ (treesit-filter-child
+ parent
+ (lambda (n)
+ (member (treesit-node-type n)
+ '("constant" "scope_resolution"))))))))
+ (list (jf/treesit/module_space parent) parent_name)))
+#+end_src
+
+Basically what this does is climbing up the syntax tree with
+~treesit-parent-until~ to find the next module boundary (if there is one) and
+then grabbing its name with ~treesit-node-text~. Now all that's left is to
+perform a recursive call and return its result along with the found module name,
+but the way it bundles them together as two elements of a ~list~ causes the
+result to be a nested tree structure, instead of a simple list. Then, to obtain
+the desired list of module names, the calling command needs to apply the
+~-flatten~ function to the tree that ~jf/treesit/module_space~ returns.
+
+Here's my take on this function:
+
+#+begin_src emacs-lisp
+ (defun esy/treesit/module_space (node &optional acc)
+ (if-let ((parent (treesit-parent-until
+ node
+ (lambda (n) (member (treesit-node-type n)
+ '("class" "module" "assignment")))))
+ (parent_name (treesit-node-text
+ (car
+ (treesit-filter-child
+ parent
+ (lambda (n)
+ (member (treesit-node-type n)
+ '("constant" "scope_resolution"))))))))
+ (esy/treesit/module_space parent (cons parent_name acc))
+ acc))
+#+end_src
+
+It's extremely similar to the original version, but the crucial difference is
+that we use an accumulator argument ~ACC~ to hold the result of our syntax tree
+traversal as we climb up to the root. At each step in the way, ~ACC~ holds a
+list of module names which is the ~cdr~ of the list that we'll eventually
+return. We extend this list with the name of the next parent module during the
+recursive call, and when we reach the root of the syntax tree we simply return
+the accumulated list.
+
+For example, if we have Ruby code that looks something like this:
+
+#+begin_src ruby
+module Foo
+ module Bar
+ module Baz
+ def spam
+ :true
+ end
+ end
+ end
+end
+#+end_src
+
+With point inside the function definition we get a simple list:
+
+#+begin_src emacs-lisp
+ (esy/treesit/module_space (treesit-defun-at-point))
+ ⇒ ("Foo" "Bar" "Baz")
+#+end_src
+
+Which is a little cleaner than what we get with ~jf/treesit/module_space~:
+
+#+begin_src emacs-lisp
+ (jf/treesit/module_space (treesit-defun-at-point))
+ ⇒ (((nil "Foo") "Bar") "Baz")
+#+end_src
--- /dev/null
+#+TITLE: The Self-Healing Code Fallacy
+#+SUBTITLE: Remarks about a new CI step that makes your code fix itself before its merged
+#+DESCRIPTION: A post by Eshel Yaron about Self-Healing Code, a new GitLab CI step that supposedly makes your code fix itself before its merged
+#+KEYWORDS: ai
+#+DATE: 2023-04-05
+
+Yesterday, a colleague of mine shared a tweet in our =#random= Slack
+channel about [[https://gitlab.com/min.choi/selfhealing-gitlab-ci/][a new AI-powered plugin for GitLab CI]] that supposedly
+makes your code /self-healing/.
+
+Here's the tweet from Min Choi:
+#+begin_quote
+Say goodbye to manual code fixes! With self-healing code @GitLab CI
+pipeline, powered by @LangChainAI and @OpenAI , you can automatically
+detect and fix issues in your code. This is the future of DevOps!
+
+Building on the GitHub action pipeline created by @xpluscal
+#+end_quote
+
+He goes on to explain all the nitty-gritty details of how it works:
+
+#+begin_quote
+First, a code push triggers the GitLab CI pipeline where Build job
+fails due to code error, which trigger the SelfHeal job.
+
+Using combination of LLMChain prompt and GPT API query, SelfHeal job
+fixes the code, commits, then push
+
+Second, the code push from SelfHeal job triggers a new pipeline with
+the fixed code.
+
+This time Build job passes. SelfHeal job is skipped since Build job
+passed.
+
+Entire processes was fully automated after the initial code
+push. Possibilities are endless in this age of AI. I will keep you
+guys posted as updates are made.
+#+end_quote
+
+* AI Naivety
+
+This hits me as classic case of /AI naivety/. People see LLMs do
+things that they didn't think were possible, and do it fast. That
+makes them think that LLMs can possibly do /anything at all/. They
+forget--that some things remain impossible. It's as if they were
+introduced to some deeper truth that suddenly invalidates the
+constraints of the old world. In the new world, AI can decide the
+halting problem. Just give it a program and it'll tell you! It seems
+to work well for these 10 lines Python snippets that we tested it on,
+doesn't it? And fuck it, who's to say if it gets it wrong.
+
+* A Bad Metaphor
+
+Back to the self-healing code from Min Choi's tweet, the biggest
+problem I have with this idea is the premise that fixing code is
+somewhat similar to how living organisms heal. Healing is when your
+body restores a "previous" good state after enduring some trauma. If
+your code would self-heal whenever you broke it, that'd just mean it's
+reverting your changes time after time. You'd be stuck with a
+self-preserving, "Hello, World!"-printing, CI-passing piece of
+nothing. To fix code you must start from a rigorous specification of
+what it means for the code to be fixed. Min Choi's self-healing code
+needs to first read the developer's mind in order to figure out what
+it should heal /into/, because the code ultimately conveys the
+developer's intent. No problem for the almighty AI, right?
+
+Contrast this wishful-thinking, eye-shutting, based approach with
+something like [[https://pumpkin.uwplse.org/][PUMPKIN PATCH]] from Talia Ringer et al., where
+/automatic proof repair/ (a much more suitable term then "self-healing
+code") is done in the setting of a formal specification of what the
+program must do (or rather, what it must /be/--what type it needs to
+populate).
+
+* Conclusion
+
+LLMs are cool, they really are, but they can't read your mind, and
+they can't make your code self-heal, whatever that means. Do
+understand their function and utility so you can leverage them where
+appropriate, but don't expect them to do the impossible.
--- /dev/null
+#+TITLE: All Posts
+#+DESCRIPTION: Eshel Yaron's blog posts
+#+KEYWORDS: eshel language emacs programming prolog
+
+#+BEGIN: posts :dir "/Users/eshelyaron/checkouts/eshelyaron.com/src/posts" :limit nil
+#+END:
--- /dev/null
+#+TITLE: Public PGP Key
+#+AUTHOR: Eshel Yaron
+#+OPTIONS: toc:nil ^:{}
+
+* My PGP public key
+
+#+begin_src shell :results code :exports both
+ gpg --armor --export me@eshelyaron.com
+#+end_src
--- /dev/null
+<svg version="1.1" id="Capa_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 455.731 455.731" xml:space="preserve" fill="#000000"><g id="SVGRepo_bgCarrier" stroke-width="0"></g><g id="SVGRepo_tracerCarrier" stroke-linecap="round" stroke-linejoin="round"></g><g id="SVGRepo_iconCarrier"> <g> <rect x="0" y="0" style="fill:#111111;" width="455.731" height="455.731"></rect> <g> <path style="fill:#cfdfd5;" d="M296.208,159.16C234.445,97.397,152.266,63.382,64.81,63.382v64.348 c70.268,0,136.288,27.321,185.898,76.931c49.609,49.61,76.931,115.63,76.931,185.898h64.348 C391.986,303.103,357.971,220.923,296.208,159.16z"></path> <path style="fill:#cfdfd5;" d="M64.143,172.273v64.348c84.881,0,153.938,69.056,153.938,153.939h64.348 C282.429,270.196,184.507,172.273,64.143,172.273z"></path> <circle style="fill:#cfdfd5;" cx="109.833" cy="346.26" r="46.088"></circle> </g> </g> </g></svg>
\ No newline at end of file
--- /dev/null
+body {
+ color: #cfdfd5;
+ background-color: #111111;
+ margin-left: auto;
+ margin-right: auto;
+ width: 90%;
+ max-width: 90ch;
+ /* font-size: 1.1em; */
+ font-family: "Helvetica Neue", sans-serif;
+}
+
+a:link {
+ color: #00c089;
+}
+
+a:visited {
+ color: #5dc0aa;
+}
+
+time {
+ color: #9ac8e0;
+}
+
+.home-link {
+ float: left;
+}
+
+.other-links {
+ float: right;
+}
+
+footer {
+ font-size: smaller;
+ text-align: center;
+}
+
+.icon-links {
+ height: 40px;
+ text-decoration: none;
+}
+
+blockquote {
+ border-left-style: solid;
+ padding-left: 1em;
+}
+
+dt {
+ font-weight: bold;
+}
+
+pre {
+ overflow: auto;
+ border-top-style: solid;
+ border-top-width: 2px;
+ border-left-style: solid;
+ border-left-width: 2px;
+ border-right-style: solid;
+ border-right-width: 1px;
+ border-bottom-style: solid;
+ border-bottom-width: 1px;
+ padding: 0.8em;
+ background-color: #222522;
+}
+
+.footpara {
+ display: inline;
+}
+
+code {
+ color: #78afff;
+ font-family: Hack,monospace;
+}
+
+h2 {
+ color: #7fc500;
+}
+h3 {
+ color: #5dc0aa;
+}
+h4 {
+ color: #af9fff;
+}
+h5 {
+ color: #7fcfdf;
+}
+h6 {
+ color: #cfc04f;
+}
+
+/*
+Generated with `M-x org-html-htmlize-generate-css` after loading the
+`ef-bio` theme by Protesilaos Stavrou.
+*/
+.org-builtin {
+ /* font-lock-builtin-face */
+ color: #3fb83f;
+ font-weight: bold;
+}
+.org-comment {
+ /* font-lock-comment-face */
+ color: #b7a07f;
+ font-style: italic;
+}
+.org-comment-delimiter {
+ /* font-lock-comment-delimiter-face */
+ color: #b7a07f;
+ font-style: italic;
+}
+.org-constant {
+ /* font-lock-constant-face */
+ color: #37aff6;
+}
+.org-doc {
+ /* font-lock-doc-face */
+ color: #7fc07f;
+ font-style: italic;
+}
+.org-doc-markup {
+ /* font-lock-doc-markup-face */
+ color: #37aff6;
+}
+.org-escape {
+ /* font-lock-escape-face */
+ color: #cfc04f;
+}
+.org-function-call {
+ /* font-lock-function-call-face */
+ color: #7fc500;
+}
+.org-function-name {
+ /* font-lock-function-name-face */
+ color: #7fc500;
+}
+.org-preprocessor {
+ /* font-lock-preprocessor-face */
+ color: #3fb83f;
+}
+.org-property-name {
+ /* font-lock-property-name-face */
+ color: #78afff;
+}
+.org-property-use {
+ /* font-lock-property-use-face */
+ color: #78afff;
+}
+.org-rainbow-delimiters-depth-1 {
+ /* rainbow-delimiters-depth-1-face */
+ color: #00c089;
+}
+.org-rainbow-delimiters-depth-2 {
+ /* rainbow-delimiters-depth-2-face */
+ color: #7fc500;
+}
+.org-rainbow-delimiters-depth-3 {
+ /* rainbow-delimiters-depth-3-face */
+ color: #5dc0aa;
+}
+.org-rainbow-delimiters-depth-4 {
+ /* rainbow-delimiters-depth-4-face */
+ color: #af9fff;
+}
+.org-rainbow-delimiters-depth-5 {
+ /* rainbow-delimiters-depth-5-face */
+ color: #7fcfdf;
+}
+.org-rainbow-delimiters-depth-6 {
+ /* rainbow-delimiters-depth-6-face */
+ color: #cfc04f;
+}
+.org-rainbow-delimiters-depth-7 {
+ /* rainbow-delimiters-depth-7-face */
+ color: #37aff6;
+}
+.org-rainbow-delimiters-depth-8 {
+ /* rainbow-delimiters-depth-8-face */
+ color: #6fc5ef;
+}
+.org-rainbow-delimiters-depth-9 {
+ /* rainbow-delimiters-depth-9-face */
+ color: #d38faf;
+}
+.org-rainbow-delimiters-mismatched {
+ /* rainbow-delimiters-mismatched-face */
+ color: #ffffff;
+ background-color: #bd1f30;
+}
+.org-string {
+ /* font-lock-string-face */
+ color: #af9fff;
+}
+.org-type {
+ /* font-lock-type-face */
+ color: #7fcfdf;
+}
+.org-variable-name {
+ /* font-lock-variable-name-face */
+ color: #78afff;
+}
+.org-variable-use {
+ /* font-lock-variable-use-face */
+ color: #78afff;
+}
+.org-warning-1 {
+ /* font-lock-warning-face */
+ color: #cfc04f;
+}
+.org-negation-char {
+ /* font-lock-negation-char-face */
+ font-weight: bold;
+}
+.org-regexp {
+ /* font-lock-regexp-face */
+ color: #af9fff;
+}
+.org-regexp-grouping-backslash {
+ /* font-lock-regexp-grouping-backslash */
+ color: #cfc04f;
+}
+.org-regexp-grouping-construct {
+ /* font-lock-regexp-grouping-construct */
+ color: #3fb83f;
+}
+
+.timestamp {
+ color: #5dc0aa;
+}
+
+.subtitle {
+ font-style: italic;
+}
--- /dev/null
+../sweep/README.org
\ No newline at end of file
projects / esy-publish.git / commitdiff
