Setting up my blogging environment

Stuff i used

resources

  • parallel concurrent programming in haskell
  • learn you a haskell
  • coursea neural networks
  • real world haskell
  • irc #haskell channel

emacs

Org2Blog

sacha chua notes on setting up

http://sachachua.com/blog/2013/08/helping-someone-get-started-with-emacs-and-org-mode-through-org2blog-troubleshooting-steps/

  • largely not necessary as i got all of the dependencies from elpa code=M-X list packages =code
  • great for getting a list of dependencies for apt
  • one thing missing was the need too install htmlize for code coloring, i may have something wrong though as this is largely untested and its 4am
    • needed to also customize variable org2blog/wp-sourcecode-default-params

Org mode

get it its good, included in emacs by default

inlining source code for emacs

cribbed from my own notes that i will improve

  • org-mode
    • symbols

      http://orgmode.org/manual/Special-symbols.html you can use LaTeX-like syntax to insert special symbols like ‘α’ to indicate the Greek letter, or ‘→’ to indicate an arrow. Completion for these symbols is available, just type ‘\’ and maybe a few letters, and press M-<TAB> to see possible completions. Unlike LaTeX code, Org mode allows these symbols to be present without surrounding math delimiters, for example:

      Angles are written as Greek letters α, β and γ. During export, these symbols will be transformed into the native format of the exporter back-end. Strings like α will be exported as &alpha; in the HTML output, and as in the LaTeX output. Similarly,   will become &nbsp; in HTML and ~ in LaTeX. If you need such a symbol inside a word, terminate it like this: ‘Ástor’. If you would like to see entities displayed as UTF-8 characters, use the following command1: C-c C-x \ Toggle display of entities as UTF-8 characters. This does not change the buffer content which remains plain ASCII, but it overlays the UTF-8 character for display purposes only.

    • code blocks
      • evaluating code blocks

        Evaluating code blocks

        Code blocks can be evaluated1 and the results of evaluation optionally placed in the Org mode buffer. The results of evaluation are placed following a line that begins by default with #+RESULTS and optionally a cache identifier and/or the name of the evaluated code block. The default value of #+RESULTS can be changed with the customizable variable org-babel-results-keyword.

        By default, the evaluation facility is only enabled for Lisp code blocks specified as emacs-lisp. However, source code blocks in many languages can be evaluated within Org mode (see Languages for a list of supported languages and Structure of code blocks for information on the syntax used to define a code block).

        There are a number of ways to evaluate code blocks. The simplest is to press C-c C-c or C-c C-v e with the point on a code block2. This will call the org-babel-execute-src-block function to evaluate the block and insert its results into the Org mode buffer. It is also possible to evaluate named code blocks from anywhere in an Org mode buffer or an Org mode table. Live code blocks located in the current Org mode buffer or in the “Library of Babel” (see Library of Babel) can be executed. Named code blocks can be executed with a separate #+CALL: line or inline within a block of text.

        The syntax of the #+CALL: line is

        The syntax for inline evaluation of named code blocks is

        … call_<name> … … call_<name>[<inside header arguments>][<end header arguments>] … <name> The name of the code block to be evaluated (see Structure of code blocks). <arguments> Arguments specified in this section will be passed to the code block. These arguments use standard function call syntax, rather than header argument syntax. For example, a #+CALL: line that passes the number four to a code block named double, which declares the header argument :var n=2, would be written as #+CALL: double(n=4). <inside header arguments> Inside header arguments are passed through and applied to the named code block. These arguments use header argument syntax rather than standard function call syntax. Inside header arguments affect how the code block is evaluated. For example, [:results output] will collect the results of everything printed to STDOUT during execution of the code block. <end header arguments> End header arguments are applied to the calling instance and do not affect evaluation of the named code block. They affect how the results are incorporated into the Org mode buffer and how the call line is exported. For example, :results html will insert the results of the call line evaluation in the Org buffer, wrapped in a BEGIN_HTML: block. For more examples of passing header arguments to #+CALL: lines see Header arguments in function calls.

      • structure of code blocks

        http://orgmode.org/manual/Structure-of-code-blocks.html#Structure-of-code-blocks 14.1 Structure of code blocks

        Live code blocks can be specified with a ‘src’ block or inline.1 The structure of a ‘src’ block is

        verbatim

        <pre class="src src-” id=”name”><body>

        verbatim The #+NAME: line is optional, and can be used to name the code block. Live code blocks require that a language be specified on the #+BEGIN_SRC line. Switches and header arguments are optional. Live code blocks can also be specified inline using

        or

        <#+NAME: name> This line associates a name with the code block. This is similar to the #+NAME: Name lines that can be used to name tables in Org mode files. Referencing the name of a code block makes it possible to evaluate the block from other places in the file, from other files, or from Org mode table formulas (see The spreadsheet). Names are assumed to be unique and the behavior of Org mode when two or more blocks share the same name is undefined. <language> The language of the code in the block (see Languages). <switches> Optional switches control code block export (see the discussion of switches in Literal examples) <header arguments> Optional header arguments control many aspects of evaluation, export and tangling of code blocks (see Header arguments). Header arguments can also be set on a per-buffer or per-subtree basis using properties. source code, header arguments <body> Source code in the specified language.

      • generating dot from org

        http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-dot.org.html A typical use of a dot source code block is to produce a graph visualization of a data set. In this example, the following input table

        a Hello
        b World!

        is passed to a source code block that is responsible for producing valid dot code

        #+name: make-dot
        #+BEGIN_SRC emacs-lisp :var table=dot-eg-table :results output :exports none
          (mapcar #'(lambda (x)
                      (princ (format "%s [label =\"%s\", shape = \"box\"];\n"
                                     (first x) (second x)))) table)
                      (princ (format "%s -- %s;\n" (first (first table)) (first (second table))))
        #+END_SRC
        

        and this is chained to a dot source code block

        #+BEGIN_SRC dot :file images/test-dot.png :var input=make-dot :exports results
        graph {
         $input
        }
        #+END_SRC
        

        that wraps the input in a graph{} command to produce the following graphic output

  • dot
    • display inline images
    • toggle display imagees inline
      C-c C-x C-v     (org-toggle-inline-images)
      

    • language symbols

      You can use HTML as label so

      digraph G { a [ label=<α>] b [ label=<β>] c [ label=<γ>]

      a -> b -> c } will show alpha -> beta -> gamma.

      • direct input
        • way to enter literal utf8 characters
          C-x 8 C-m en dash
          

        • way to get input table
          M-x set-input-method 
          Tex
          

          then

          you can write things like Σ and it will be changed into the symbol. you can put these things in dot graphs too

          C-h C-\
          

          then

          will tell you the input table

    • Directed graphs

      A directed graph Similar to undirected graphs, DOT can describe directed graphs, such as flowcharts and dependency trees. The syntax is the same as for undirected graphs, except the digraph keyword is used to begin the graph, and an arrow (->) is used to show relationships between nodes. digraph graphname { a -> b -> c; b -> d; }

    • Attributes

      A graph with attributes Various attributes can be applied to graphs, nodes and edges in DOT files.1 These attributes can control aspects such as color, shape, and line styles. For nodes and edges, one or more attribute-value pairs are placed in square brackets ([]) after a statement and before the semicolon. Graph attribute are specified as direct attribute-value pairs under graph element. Multiple attributes are separated by a comma and a space. Node attributes are placed after a statement containing only the name of the node, and no relations. graph graphname { // This attribute applies to the graph itself size=”1,1″; // The label attribute can be used to change the label of a node a [label="Foo"]; // Here, the node shape is changed. b [shape=box]; // These edges both have different line properties a – b – c [label="g'"]; b – d [style=dotted];

Footnotes:

1

DEFINITION NOT FOUND.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s