Playing with Racket: random lines GIF

I'm enjoying playing with Racket. Takes me back to some good old college days writing Scheme, but I don't think creating a GIF was so easy in any of the Scheme systems we were using then. (Which ecosystem -- language + standard libraries -- provides the nicest environment for making animated GIFs?)

#lang racket

(require mrlib/gif)
(require racket/draw)

(define (random-lines-bitmap width height line-count)
  (let* ([target (make-bitmap width height)]
         [dc (new bitmap-dc% [bitmap target])])
    (begin
      (send dc draw-rectangle
       0 0   ; Top-left at (0, 10), 10 pixels down from top-left
       (- width 1) (- height 1))
      (for ([i line-count])
        (send dc draw-line
              (random width) (random height)
              (random width) (random height)))
      target)))

(define (write-random-lines-gif width height line-count frame-count filename)
  (write-animated-gif
   (for/list ([i frame-count])
     (random-lines-bitmap width height line-count))
   10
   filename
   #:loop? true))

(write-random-lines-gif 300 200 50 10 "random-lines.gif")

"Why Concatenative Programming Matters"

I enjoyed reading Why Concatenative Programming Matters. I'd like to do more with Factor sometime. Is it still under active development? I see that new binaries are still getting generated for it anyway.

"https://evincarofautumn.blogspot.com/2012/02/why-concatenative-programming-matters.html" >url http-get* length
...
261104

(This seems to work. Am I leaving extra stuff on the stack?)

Clojure!

https://clojure.org/guides/getting_started emphasizes Homebrew, but MacPorts has it too. I also had to install OpenJDK too. I think for me, the minimal set of commands could have looked like:

sudo port install clojure +rlwrap
sudo port install openjdk11

clj
user=> (+ 1 1)
2

Woohoo!

Notes on "Mythical Man-Month": "Why did the tower of Babel fall?"

Brooks uses the metaphor of the tower of Babel to again emphasize the importance of but difficulties with communication. Several times he (again) brings up problems with potential superlinear complexity owing to to the number of pairs or other groupings of workers.

"How, then, shall teams communicate with one another? In as many ways as possible: Informally... Meetings... Workbook..."

He goes into some detail talking about the workbook and processing surrounding it. It seems that online documentation has solved a lot of his problems though introducing new ones. He talks about the introduction of microfiche to avoid printing out an unwieldy number of pages, but notes the lack of ability to add notes as an important limitation. We have that problem too with online docs -- no margins to write in as an individual reader. Also, support for showing diffs in documentation is pretty uneven.

"If there are n workers on a project, there are (n^2 - n)/2 interfaces across which there may be communication, and there are potentially almost 2^n teams within which coordination must occur. The purpose of organization is to reduce the amount of communication and coordination necessary... The means by which communication is obviated are division of labor and specialization of function."

A tree structure arises because no one should have two bosses. Brooks also notes even if the reporting change forms a tree, plenty of communication outside this is necessary, forming a network.

Necessaries for any subtree:

1. a mission
2. a producer
3. a technical director or architect
4. a schedule
5. a division of labor
6. interface definitions among the parts

What Brooks calls "producer" sounds very much just like "manager" or "technical lead manager" to me while "technical director" seems to map very closely to what I think I know of as "tech lead". (In the group I'm reading this with, we had noted some of the roles he described seemed a bit unfamiliar, but here even if the names are different, the roles seem pretty close to what we have today.)

He talks about three possible arrangements between producer and director: same person, director reports to producer, or producer reports to director. He illustrates the 3rd arrangement, which I don't believe I've seen in real life, with a quote from Heinlein's "The Moon is a Harsh Mistress" where the top engineer is happy to be freed from management work.

x XOR y MOD 9 in R

I was curious what it would take to reproduce the x XOR y MOD 9 plot in R. Here's one way:

x <- 1:32
image(x, x,
    outer(x, x, FUN=function(x, y) (bitwXor(x, y) %% 9) != 0),
    col=c("white", "black"))
dev.copy(png, "~/x_xor_y_mod_9.png")
dev.off()

Looking forward to creating a GIF using the gifski package, which I learned about from gganimate, which I'm also looking forward to exploring.

Zooming out on x ^ y % 9

Having some more fun in Autoplot:

I was happy to be able to move the GIF-writing code into a library. (To keep things neat, I added a "contrib" directory in the "jython" directory within "autoplot_data". Looking at sys.path, you can see that "autoplot_data/jython" is included.)

import os.path

from contrib import gif
from org.das2.graph import DasColorBar

def xor_mod_plot(n=256, modulus=9):
  x = outerProduct(linspace(0, n - 1, n), ones(n))
  plot(gt(bitwiseXor(x, transpose(x))  % modulus, zeros(n, n)), renderType='nnSpectrogram>rebin=noInterpolate')
  dom.plots[0].setColortable(DasColorBar.Type.GRAYSCALE)

gif.plot_to_gif(xor_mod_plot, os.path.expanduser('~/autoplot/xor_mod_zoom.gif'),
   keyword_params=[dict(n=n) for n in range(4, 513)],  delay_tenths_sec=5)

The only change required for the GIF-writing code was the call to writeToBufferedImage(), which required an explicit import when used within the library:

from org import autoplot
...
        images.append(autoplot.ScriptContext.writeToBufferedImage())

Rob Pike's 6 rules of programming

@rob_pike on Twitter, 2018: "People keep quoting my '5 Rules of Programming'. Actually there were (and still are) 6 rules." He points to http://doc.cat-v.org/bell_labs/pikestyle as the best source for the rules... I will leave it to you to read the 6th rule. :-)