Tyler Strikes with WebloggerMode!

After a long hiatus from publishing, I’ve been checking out some ways to lower the cost of creating new posts. This is an experiment with , which lets you create posts from emacs and pushes them to the wordpress server via xml-rpc, which is pretty slick. I think wordpress has a lot of advantages and the only real problem I had was writing in the wordpress UI. A true emacs disciple never writes more than a line in anything other than a trusty buffer! weblogger.el also saves you from having to login to the dashboard, further reducing the psychological barrier of writing a new post. It was available on and dead simple to set up. I look forward to exploring its capabilities and limitations. I can already see there are some formatting issues and keybindings I’ll need to change. Until next time!

Comments Off on Tyler Strikes with WebloggerMode! Posted in emacs

Factor Resources

Main Project Page with downloads:


Factor Wiki — main source for documentation:


Beginner Tutorials:



A Couple New Words for Factor…

Here are some words that have been living in my utilities file that I thought I would propose to the greater community.  If you like them or hate them or know a better way, go ahead a tell me!  Also, as so often happens in factor, a similar or identical word may already live in an existing vocabulary.  I have a couple thoughts on how to address that general problem but I’ll save them for another time…

First, a simple one: zipwith.  A haskell staple, I find myself using this one quite a bit,   just a partial application of assoc>map.

: zipwith ( assoc quot -- seq ) { } assoc>map ;

Next, something more interesting: lfind.  It finds the first element of a list that satisfies a predicate or f if nothing does.  Used in conjunction with lazy lists, it often is a much more elegant solution than using a “while” loop.  Defining lfind using locals for the definition always came out shorter and clearer for me than non-local attempts.  Can you come up with a better non-locals version?

My definition:

:: lfind ( list pred -- elem/f )
 { { [ list nil? ] [ f ] }
 { [ list car pred call( x -- y ) ]
 [ list car ] }
 [ list cdr pred lfind ]
 } cond ; inline recursive

Using lfind in conjuction with ltake, you can easily and elegantly compose the stopping criteria for searching through always useful lazy lists.  Using lazy lists, ltake, and lfind this is easily separable into three parts:  generating the lazy list, limiting the number of iterations with ltake, and specifying where to stop with lfind.  A concrete example I used this for is for testing whether a complex point remains bounded under a function for a certain number of iterations (for calculating julia and mandelbrot sets).  The “lazy list+ ltake+lfrom” idiom is more natural for factor than using a while or for loop in many cases. Anyway I think lfind would make a nice addition to the lists vocab.

Now cleave>seq.  A variation of cleave, I find many situations where this would be more useful than cleave due to the arbitrary and potentially large number of elems that cleave would leave on the stack.  Its just a small variation of cleave:

: cleave>seq ( x quot-seq -- seq ) [ call( x -- y ) ] with map ; inline

Finally, to end with on a controversial note, I introduce a parsing word.

Since I use make heavy use of tuples in conjunction with the undo combinator  for general stack management, I nearly always use the default constructor, C: CTUPLE: combines  TUPLE: and C: , effectively cutting the number of lines you need to specify your default data-structures in half.

Here is my definition, although I must admit my experience with writing non-trivial parsing words is extremely limited ( which is why this made for a good exercise)

SYNTAX: CTUPLE: parse-tuple-definition
 [ define-tuple-class ]
 [ drop drop
 [ name>> "<" ">" surround create-in dup reset-generic
 ] keep define-boa-word ] 3bi ;

I’ll end with crazy idea which I personally believe would be cool but probably no current language really handles, an idea possibly related to “first class macros”.  I’ve experimented with it in lisp but I’m not terrible satisfied with the results.  In factor it effectively amounts to mapping or iterating parsing words.  So instead having dozens or hundreds of lines of repeating some parsing word over and over (extra.cpu.8080 comes to mind, which is by the way part of a very cool piece of work) like so:

INSTRUCTION: NOP          ; opcode 00 cycles 04
INSTRUCTION: LD   BC,nn   ; opcode 01 cycles 10
... ( repeat 250 more times )
INSTRUCTION: RST  38H     ; opcode FF cycles 11

we would have a word, call it DEFINE-ALL:, that allows you to say:

NOP           opcode 00 cycles 04
LD   BC,nn    opcode 01 cycles 10
RST  38H      opcode FF cycles 11 ;

Or something to that effect. DEFINE-ALL would work for arbitrary parsing words, eliminating the need for words like SYMBOLS: , etc. and make factor a little more orthogonal.  Is it worth the effort?  Will someone ever care enough to write DEFINE-ALL?  Only time will tell.

Well, that’s all for now.  If I’ve provoked a strong emotional response from you, constructive criticism is welcome.

Factor Tutorial Part 1: You already know factor

This post is for those who want to start learning factor but are unsure of where to start.  I started learning factor about a year ago.  The first few months may have been a little confusing.  Maybe factor was the hardest language I have yet learned.  Soon the initial struggle passed and factor became the quickest and easiest language for me to use.  My next few posts will share some of the key insights that I helped me to become comfortable with the factor.

Anyone whose ever done object oriented programming in ruby already knows the basic paradigm of chaining methods together.

In the following examples we are going to pair real ruby code with “ruby-factor”, which is exactly like factor except all its subroutines or “words” have the same names as python functions and take their inputs in the same order.  Hopefully you will start to notice a pattern.




“abc” upcase


”   abc  “.strip.upcase


”   abc  ” strip upcase




{ 1 2 3 } { 4 5 6 } concat




{ 1 2 3 } { 4 5 6 } append reverse




{ 1 2 3 4 } [ upcase ] map reverse


[1,2,3,4].map{ |x| x + 1 }


USE: locals
{ 1 2 3 4 } [| x | x 1 + ] map

See whats going on here? Good factor code is just like chaining together ruby method calls (with method arguments swapped around) and is read in almost exactly the same way.  Sometimes called “pipeline style”, you can check out the concatenative wiki for more information. It is possible to emulate this style in ruby with methods and blocks: however; factor was designed from the start with this paradigm in mind so it feels more natural. Hopefully these comparisons will make you feel more comfortable trying out factor, which is a really fun language to think in and program with if you are looking for something fresh. See you next time!

Drawing Factor Data Structures

In my last post I mentioned generating using sgraphics for data visualization and gave an small example with binary trees.  As generating good looking trees is no easy task, I did some research into graphviz, a popular visualization tool.  The graphviz docs mention that the DOT domain specific language for producing images is not a full programming language; instead, it suggests using bindings or generating dot files from a outside language.   Factor already has some graphviz support in the compiler.graphviz library, but nothing for displaying arbitrary factor tuples.  Great! Another opportunity to write a mini-compiler.  Shouldn’t be too difficult.  After getting familiar with DOT, drawing a few sketches, I got a an initial version that could display flat tuples fairly easily.  Handling recursive tuples proved a bit trickier, as my initial version was simple but a bit on the hack side.  A few hours later though, I was able to produce complete list and tree structure. Here’s a few examples:

Anyway, the current implementation is only about 50 lines of code but can convert arbitrary factor tuples into tree structured images.

Fractals and Visualizing Data

Describing fractals is the problem space I have been exploring lately with sgraphics.  Fractals fit well as an initial application because they are composed of simple objects and are an easy way to test the expressiveness of the language.  It is easy to test the upper limit of scene complexity my implementation  can handle due to most fractal’s exponential growth.  Here are some more examples I’ve come up, each is specified with no more than 5 lines of code.

As you can see, I added some binary trees on the bottom row.  Data visualization is a one of the next goals of sgraphics.  Towards this end, I wrote some basic binary tree drawing code that generates these images from normal factor lists.  I hope to be able to support drawing more factor data structures in a useful way in the future.  In the process creating these examples I realized getting trees to look nice is an art form; there is quite a bit I more for me to learn about it.

Profiling SGraphics

The first implementation of sgraphics had trouble drawing larger scenes.  If given a scene to draw with too many objects, say, on the order of around 100, it would compile fine, but when calling the quotation was slow at best and “retain stack overflow” at worst.

Optimization being the root of all evil,  I ignored such problems until I was happy with the basic design and feel of the library.  Now that stage zero is over, the implementation needs to be able to stand up to some more demanding applications.

The initial sgraphics compiler would transform each primitive shape into a quotation.  Here’s an example:

( scratchpad ) line{ 0 0 100 100 } gl-compile .
[ GL_LINE [ 0 0 glVertex2f 100 100 glVertex2f ] do-state ]

The list of quotations like this one would then be concatenated together into one long quotation, which in turn becomes the body of the draw-gadget* method for a UI window. This approach worked fine for smaller scene but was slow and caused retain stack overflows for larger ones. Examining the traceback showed that the compiler kept calling post-order-traversal over and over again until the overflow occurred.

As I am still quite unfamiliar with the factor compiler, I sought out help from more knowledgeable source. Dan Ehrenberg advised that quotations should be kept as short as possible for best efficiency. With this new information I devised a new approach. Instead of constructing one monolithic quotation that simply needed to be “called”, I would generate an intermediate data structure and write some code to walk over that instead, hopefully preventing all the confusion I was causing the compiler in the process.

Amazingly, this strategy worked wonderfully. Drawing pictures became much faster and the large scenes that were causing overflows became a non-issue. I’d like to learn more about the factor optimizing compiler and its workings, so the latest sgraphics release contains both the old and new backends. You can switch between them by setting the sg-backend global variable to either the symbol q-backend for the original quotation version, or ds-backend for the new intermediate data-structure version (set as the default).

With this improvement, I was finally able to draw a scene with 32,768 pixels, where each pixels is an sgraphics square.

If you are wondering, this is the so-called “pattern table” for the nes version of pacman.  Look closely and you can see bits of ghosts, fruit, etc.  Click the picture to see a bigger version.

I think the moral of the story here is

  • keep your quotations short
  • don’t use quotations as a data structure

I’d love to here what more experienced Factornauts think about these, its a subject I think could be documented a little more thoroughly.

Anyway, with this first annoying hurdle overcome, I will get back to writing some cool looking demos to test out the expressiveness of the language so far.  Check back soon for updates!