README.markdown @ c3927a600883

Update
author Steve Losh <steve@stevelosh.com>
date Sun, 17 Jul 2016 16:50:47 +0000
parents 7ec2ff4278a4
children f5b07159f8fe
.plan
=====

I'm going to try keeping a `.plan`.  Let's see how this goes.

[TOC]

[Bones]: http://bitbucket.org/sjl/bones
[AMOP]: http://www.amazon.com/dp/0262610744/?tag=stelos-20
[Masters of Doom]: http://www.amazon.com/dp/0812972155/?tag=stelos-20
[Mazes book]: http://www.amazon.com/dp/1680500554/?tag=stelos-20
[Mazes]: http://bitbucket.org/sjl/mazes
[ELS 2016]: http://www.european-lisp-symposium.org/
[LOL]: http://www.amazon.com/dp/1435712757/?tag=stelos-20
[WAM book]: http://wambook.sourceforge.net/
[cl-nrepl]: https://bitbucket.org/sjl/cl-nrepl
[Dash]: https://kapeli.com/dash
[Roswell]: https://github.com/roswell/roswell
[ANSI Common Lisp]: http://www.amazon.com/dp/0133708756/?tag=stelos-20
[Successful Lisp]: http://www.amazon.com/dp/3937526005/?tag=stelos-20
[CLtL2]: http://www.amazon.com/dp/1555580416/?tag=stelos-20
[OpenGL SuperBible]: http://www.amazon.com/dp/0672337479/?tag=stelos-20
[CEPL]: https://github.com/cbaggers/cepl
[On Writing]: http://www.amazon.com/dp/1439156816/?tag=stelos-20
[Salem's Lot]: http://www.amazon.com/dp/0307743675/?tag=stelos-20
[Reddit GDC]: https://www.reddit.com/r/gamedev/comments/4oodum/what_are_some_of_the_best_gdc_talks/
[The Implementation of Prolog]: http://press.princeton.edu/titles/5264.html
[Coding Math]: http://bitbucket.org/sjl/coding-math/
[Learning WebGL]: http://learningwebgl.com/
[iterate]: https://common-lisp.net/project/iterate/
[parenscript]: https://common-lisp.net/project/parenscript/
[Wisp]: http://bitbucket.org/Gozala/wisp
[CCL]: http://ccl.clozure.com/
[SBCL]: http://sbcl.org/
[sandbox]: http://bitbucket.org/sjl/sand/
[hype]: http://bitbucket.org/sjl/hype/
[The Road]: http://www.amazon.com/dp/0307387895/?tag=stelos-20
[ancg]: http://www.amazon.com/dp/0470018127/?tag=stelos-20
[heisler]: http://www.amazon.com/dp/0823085651/?tag=stelos-20
[WebGL Fundamentals]: http://webglfundamentals.org/
[Neovim]: https://neovim.io/
[miniyank]: https://github.com/bfredl/nvim-miniyank
[YankRing]: http://www.vim.org/scripts/script.php?script_id=1234
[Paredit]: https://github.com/vim-scripts/paredit.vim
[PAIP]: http://www.amazon.com/dp/1558601910/?tag=stelos-20
[policy-cond]: https://bitbucket.org/tarballs_are_good/policy-cond
[cl-charms]: https://github.com/HiTECNOLOGYs/cl-charms
[Silt]: http://stevelosh.com/blog/2015/12/ludum-dare-34/
[99 Prolog Problems]: http://www.ic.unicamp.br/~meidanis/courses/mc336/2009s2/prolog/problemas/


## June 2016

### 2016-06-01

* Created this thing.
* Added a fish alias to make it easier to edit.
* Also added a Vim mapping...

### 2016-06-02

* Added Prolog list support to [Bones][].  Need to think about the UI more, but
  it speeds things up considerably (I don't *fully* understand *why* yet...).

* Started playing guitar again after a month of so of not at all.  Truss rod is
  all out of whack thanks to the changing weather.

* Read some more [AMOP][].  My brain hurts.

* Read more [Masters of Doom][].

* Noticed the `dynamic-extent` declaration of a `flet`ed function in
  Alexandria's `extremum`... should look into this for the bigass `labels` in
  [Bones][].

* Did a bit more from the [Mazes book][].

### 2016-06-03

### 2016-06-04

* Went to a talk by Tony Hoare at my school.  It was interesting, but the more
  I dive into purely theoretical things the more I realize I really love
  *actually making the computer do things*.

* Started watching the [ELS 2016][] videos.  I wish I could have made it this
  year, but unfortunately my school schedule conflicted.  Next year!

* Asked for help/advice/feedback on the UI for [Bones][]:
  <https://gist.github.com/sjl/1f4bb73967663af0f9276b491af84140>

* Implemented `cut` for [Bones][].  I simplified the book's fuckery quite a bit
  and it turned out to work pretty well, after chasing down a couple of other
  pre-existing bugs.

### 2016-06-05

* Discovered a bug in the [Bones][] compiler, and I think the best way to fix it
  is to rewrite the bulk of the compiler.  This sounds bad, but "rewrite the
  compiler" has been on my list of things to do for a while now, so it's as good
  a time as any.

* The compiler is pretty crufty because it started out with me trying to wrap my
  head around the awful [WAM book][] and grew organically.  Now that I've got
  a fairly solid understanding of how this shit works, my second attempt should
  be nicer.

* Watched more [ELS 2016][] videos.

* Finished reading the main part of [AMOP][].  Gonna put it down and move on to
  [LOL][] instead of trying to power through reading the entire MOP spec.

* Started rewriting the [Bones][] compiler.  Made good progress, will probably
  take another day or so to get working and then another day to clean up.

* I really should go through and type hint all the stuff in that compiler.  The
  type hints have proven useful in the rest of the project.

* Started thinking about what an inspector plugin for [cl-nrepl][] would
  look like.  The "dump the object" code I wrote for the new compiler is ugly
  and painful to write -- if I just had a nice inspector I wouldn't need to fuck
  around with writing it.

### 2016-06-06

* Read more [LOL][].
* Logistic travel stuff.

### 2016-06-07

* [Finished rewriting](https://bitbucket.org/sjl/bones/commits/72bbdd5157258b77c85a6c0172240a26bb7ad4a4) the [Bones][] compiler.

### 2016-06-08

* Implemented Aldous-Broder and a bunch of code cleanup for [Mazes][].

### 2016-06-09

* Downloading/updating everything to prepare for my long-ass flight back to the
  states tomorrow.

* Grabbing doc trees with `wget`, but also might try out [Dash][] to see if it
  can reduce this pain a bit.

* Roswell broke when I updated it through Homebrew and I had to manually remove
  all its cached files in `~/.roswell` for it to work again.  Computers are
  garbage.

### 2016-06-10

* Flew back to the states for a short visit.
* Fixed a pair of really nasty bugs in [Bones][] on the plane.

### 2016-06-11 - 2016-06-23

* Traveling in the US.  I miss American food.

* I had left a cache of paper books at a friend's place in the US, so I read
  through a few while I was there.

* Read through [ANSI Common Lisp][].  Pretty basic, nothing too advanced in it.
  It reminded me how much I hate Paul Graham's function/variable naming style.
  Aim for brevity of *ideas*, not characters.

* Read/skimmed [Successful Lisp][].  Also pretty basic, but kind of weird at the
  same time.  It seemed to just skim a lot of topics and not really go in-depth
  enough on any of them.  Except for the chapter about the bit-twiddling
  operations, which I haven't seen in any other Lisp book (except maybe
  [CLtL2][]).  I don't think I'd recommend it.

* Read through most of the [OpenGL SuperBible][].  Graphics programming is some
  really neat and powerful stuff wrapped in a hilarious nest of disgusting
  syntax and boilerplate.

* I really want to play around with shaders and such, but the C++ development
  environment seems like an enourmous pain in the ass.  There's also [CEPL][]
  but I'm worried that I should really know some OpenGL before diving into that.
  I might poke at WebGL a bit as a middle ground.

* Read through [On Writing][] by Stephen King.  Some good advice in there,
  especially about just reading and writing a *lot*.  I haven't been reading
  enough lately -- so from now on the Kindle is gonna replace my phone while on
  the bus.

### 2016-06-24

* Still jet lagged.  Catching up on things back in Iceland.

* Halfway through [Salem's Lot][].  I forgot how much I loved reading fiction.

* Grabbed a bunch of GDC talks from [this thread][Reddit GDC] to watch later.

* Read more [LOL][].  This dude is a wonderful nutbag.  The chapter on
  efficiency is crazy, but interesting.  I might use some of its ideas in
  [Bones][] once I've got that to a stable place.

* Watched the Juice it or Lose It talk from that Reddit thread.  Really nice.
  Simple stuff like tweening makes a big difference.

### 2016-06-25

* Watched the "Ellie: Buddy AI in The Last of Us" GDC talk over breakfast.  It
  was really interesting.  The idea that making Ellie stick close to the player
  means that any mistakes become the player's fault (so they won't blame her)
  seems obvious now, but wasn't before I watched it.

* Finally finished up a blog post that's been halfway done for months.  Might
  post it on Monday.

* Finished [LOL][] (though I had to tap out halfway through the final Forth
  chapter).  My dude certainly has a lot of fresh, hot, steaming takes.  I'd
  recommend the book, but only with a rabbit-sized grain of salt.

* Watched the [ELS 2016][] talk "Type Checking on Heterogeneous Sequences in
  Common Lisp".  Seems a lot like the Clojure spec stuff that was released
  shortly after.

* Started a blog post about Lisp and symbols which turned into a 5k word
  monster.  Gonna edit it down over the next few days and post it some time next
  week.

### 2016-06-26

* Watched the "Antichamber: An Overnight Success, Seven Years in the Making" GDC
  video.  Pretty inspiring, though I think he still probably underestimates how
  much luck matters.

* Started reading [The Implementation of Prolog][].  Some good ideas and
  explanations in here, though the coding style is maddening.  I might even try
  a clean rewrite of [Bones][] a year or two down the line, using some of the
  concepts I'm seeing here.

* Started doing the [Coding Math][] series again.  Finished episode 28.

* Started back into the [Mazes book][] again.  Implemented Wilson's Algorithm in
  my little [demo][Mazes].

### 2016-06-27

* Printed off and read the manuals for two Lisp things I've been meaning to look
  into: [iterate][] and [parenscript][].

* [parenscript][] seems like an ugly, practical compile-to-JS Lisp.  It's not
  pretty, but it has macros so I make it pretty if desired.  And at least it's
  not abandoned like [Wisp][].

* [iterate][] is neat.  I can definitely see how it's cleaner than `loop`.
  There are some parts that seem tricky, but I have the feeling that they're
  edge cases that I only say because I read the manual cover-to-cover -- I doubt
  they'd appear much in real life.  I really should just bite the bullet and
  start using it -- there's no other way to learn -- but `loop` is like
  a comfortable rut I've found myself stuck in...

* Did the first few lessons of [Learning WebGL][].  So far I understand
  everything (reading the [SuperBible][OpenGL SuperBible] helped a ton).  I'm
  beginning to think graphics programming *seems* really tough because it's
  usually done in weak languages that can't abstract for shit like C and JS.
  Most of the boilerplate in these tutorials could be abstracted away with some
  careful inline functions or macros.  But maybe I'll change my mind once I dive
  in more.

### 2016-06-28

* Finished [Salem's Lot][].  I really want to visit Maine again.
* Did more [Learning WebGL][].  Still pretty smooth sailing.
* More [Coding Math][].

### 2016-06-29

* Watched "Designing Monument Valley" over breakfast.  This style of game isn't
  my particular cup of tea, but the talk was interesting.  He mentioned a few
  times that mechanics get in the way of the storytelling/experience and while
  that can be true, maybe even *most* of the time, I kept thinking about Dwarf
  Fortress as a counterexample.  If you read the DF subreddit or forums you see
  countless stories and characters unfold, each one unique, and all of them
  created by the interaction of the player's imagination and the game's
  procedural mechanics.  I'd love to make a game like that.

* Posted a [blog post](http://stevelosh.com/blog/2016/06/symbolic-computation/)
  about symbolic computation.

* [Added support for dynamic calling](https://bitbucket.org/sjl/bones/commits/de6e248866f44f1b997669339a7cce227305419c)
  (Prolog's `call/1`) in [Bones][].  This lets you write `not/1` trivially,
  which we need for some GDL games.

* Fixed a [nasty unrelated bug](https://bitbucket.org/sjl/bones/commits/05ce726f28744cb1c412e0f450fac3b978a6001d)
  in the `bind!` function of [Bones][]' VM.

### 2016-06-30

* Watched the "Obsessive Compulsive Development" GDC talk over breakfast.  It
  was refreshing to see a talk about a game that didn't turn out to be a huge
  success.  Lots of good advice in it which seems obvious in retrospect, but
  I can see how in the heat of the moment it would be easy to lose sight of the
  bigger picture.

* Did another episode of [Coding Math][].  This one is about writing a tweening
  library.  I ended up writing a ridiculous pair of [tweening
  macros](https://bitbucket.org/sjl/coding-math/src/783609c42ef0955634097267531ee06541275574/src/tween.lisp)
  that will tween arbitrary places with a nice simple UI.  It's much more
  general than the Javascript version, which is limited to tweening (unnested)
  properties of objects.  Want to tween the car of a slot of an entry in a hash
  table?  No problem!  `(tween-place! (car (slot-value (gethash 'foo table)
  'myslot)) 500 2.0 #'tween-linear)`  I shudder to think how you'd do this in
  a language without macros...

* Added support for running [Bones][]' test suite on [CCL][].  Up til now I've
  just been using [SBCL][] for development, but I accidentally opened the wrong
  REPL today and didn't notice until I got a traceback for something stupid
  I typed, so apparently it Just Works™ on CCL too.  SBCL is currently much
  faster, but I'm pretty pleased that it runs correctly on another
  implementation with zero extra effort.  It's *so* nice to be working in
  a language with an *actual standard*.  I put the CCL testing into the
  precommit hook to help keep me honest going forward.

* Ported two GDL games (`hanoi7_bugfix` and `aipsrovers01`) into Bones'
  `examples/` directory.  Now that I can write `not/1` it was trivial, and
  should be trivial for all GDL games.  It is *really* tedious to do by hand
  though, so I really want to write a GDL to Bones translator.  But to do that
  I think I need to sort out the `assert`/`retract` situation.

* More [Learning WebGL][].

* Added the Hunt and Kill algorithm to [Mazes][], and also started diving into
  [iterate][] by switching over a few of the `loop`s.  I'm never gonna learn if
  I don't just force myself to jump in the deep end.

#### Assertion and Retraction in [Bones][]

I've been thinking about the best way to implement the rule assertion/retraction
UI in Bones and I have a few ideas.  The current stopgap UI of "all the parts of
a predicate need to be defined in a single `(rules ...)` call" is *really* awful
to work with.

There are a few ways I could solidify this.  One way would be to delay
compilation of all the predicates until you call a top-level `(compile)`, at
which point all the predicates would be compiled and fixed forever.  This
would let you split apart the rules, but not assert/retract things at runtime
without rebuilding the entire WAM, which is kind of shitty.

On the other end, I could implement full dynamic assertion/retraction.  This
would be the most flexible, but has drawbacks.  There would probably be a lot of
wasted compilation: if you do `(fact (foo 1)) (fact (bar 2)) (fact (baz 3))` it
would compile `foo` three times, throwing the first two away.  I'd also need to
implement a garbage collection algorithm for the code store, which seems like
a lot of work and a large cost at runtime.

An idea I've been rolling around in my head is to try to trade off some
flexibility for speed by using a kind of "stack-based" assertion/retraction
scheme.  You would add rules one at a time and it would delay compiling them
until you call `(allocate-logic-stack-frame)`, at which point it would compile
everything and record the current top of the code store (and which predicates
have been defined).  Then you could define more predicates, as long as they
weren't already used in a previous "frame", and freeze the frame again to use
them.  When you want to retract, you would only be able to pop an entire frame
of predicates in one go.

This gives you less control -- you can only retract entire frames, and if you
want to retract something you defined way back at the start you're also forced
to retract everything that came later.  But the benefit is that you don't have
to suffer useless recompilation, and you don't need to wait for garbage
collection.

This is probably my GGP mindset showing, because this would be perfect for using
with GDL.  When you receive the rules of the game you compile them all, and
freeze the stack.  Then for each state you can just compile and push the `next`
and `does` predicates into the new top frame, and pop it when you're finished
examining the state.


## July 2016

### 2016-07-01

* More [Learning WebGL][].

* Another episode of [Coding Math][].  Penner's easing functions are beautiful
  little functions clouded by a haze of godawful programming style.  I tried to
  write my versions to be a bit more readable, at the expense of some speed.

* Finished [The Road][].  Meh.

### 2016-07-02

* Watched the "Programming Context-Aware Dialog in The Last of Us" GDC talk by
  Jason Gregory.  Really neat stuff.  This is the kind of AAA game I'd love to
  work on.  Vanilla FPS, sports, etc games bore the shit out of me, but The Last
  of Us has a lot more depth to it.

    I admit I did twitch a bit when I saw the infix `(('speaker 'health) > 0.5)`
  notation in their Scheme-like dialog scripting language -- I guess even
  Naughty Dog isn't perfect, hah.

* Shaved a yak related to packages in [cl-nrepl][] that I've been meaning to get
  to for a long time.  Really I need to rewrite that whole project now that
  I'm not a complete noob in Common Lisp.

* Did episode 32 in [Coding Math][].  I decided to use Common Lisp's multiple
  return values for everything this time instead of taking/returning vectors
  everywhere, just to see how it felt.

    Implementing the core functions felt really nice with multiple values, but
  when it came to the drawing code things got a bit more awkward.  Needing to
  use `multiple-value-(call/bind)` to get things done is kind of a pain in CL
  because of how verbose things can get.  I could make some read macros to ease
  the pain, but it's probably not worth it.

    I'm trying to come up with a good rule of thumb for when to use multiple
  values and when not to.  Multiple value return obviously only gives you one
  level of "hierarchy" to work with, so e.g. instead of `(values x1 y2 x2 y2)`
  it's probably better to do `(values point1 point2)`.  Also if the items are
  the same "importance" it's probably also better to just return a structure of
  some kind -- the fact that CL treats the value first differently makes it seem
  like it's special when really `point1` isn't any more important than `point2`.

    I think the general rule I'll follow (for now) is to use multiple value
  returns very sparingly, and only when one of the values is different than the
  rest and is obviously the "most important" one.

* Worked on [Mazes][] some more.  I did a tiny bit more of the [book][Mazes
  book] but mostly it was me playing around with [iterate][].

    Iterate is turning out to be cool.  I made some custom drivers for my maze
  grids and a couple of custom clauses that are really neat.  `(averaging
  (...some expr...) :into some-var)` will keep track of the average of the
  expression over the life of the loop, and `(timing run-time :since-start-into
  v1 :per-iteration-into v2)` sets vars to store timing info.  And they even
  work together -- in `run-stats` I average the per-iteration times together.

* More [Learning WebGL][].

### 2016-07-03

* Watched the "Network Programming for Physics Programmers" GDC talk over
  breakfast.  Impressive results, but I wonder how specific they are to his
  particular data set (or at least the physics engine).

* Did a few more episodes of [Coding Math][].  Ran into a weird issue with
  Sketch's `polygon` function... I'll have to ask vydd about that in IRC the
  next time I have an internet connection.

* Switched [Bones][] over to use `?question-style` for logic variables instead
  of the previous `:keyword-style`.  Aside from updating the tests it was about
  three lines worth of change, which is good.

##### Variable UI in Bones

I'm still not happy with the `?question-style` though.  First, the check becomes
less elegant and efficient:

    (declaim (optimize (speed 3) (safety 0) (debug 0)))

    (defun* variablep (term)
      (:returns boolean)
      (declare (inline keywordp))
      (keywordp term))

    ; disassembly for VARIABLEP
    ; Size: 64 bytes. Origin: #x1006B80692
    ; 92:       4881F917001020   CMP RCX, 537919511               ; no-arg-parsing entry point
    ; 99:       741B             JEQ L2
    ; 9B:       8D41F1           LEA EAX, [RCX-15]
    ; 9E:       A80F             TEST AL, 15
    ; A0:       7506             JNE L0
    ; A2:       8079F145         CMP BYTE PTR [RCX-15], 69
    ; A6:       740E             JEQ L2
    ; A8: L0:   B917001020       MOV ECX, 537919511
    ; AD: L1:   488BD1           MOV RDX, RCX
    ; B0:       488BE5           MOV RSP, RBP
    ; B3:       F8               CLC
    ; B4:       5D               POP RBP
    ; B5:       C3               RET
    ; B6: L2:   488B4119         MOV RAX, [RCX+25]
    ; BA:       483B057FFFFFFF   CMP RAX, [RIP-129]               ; #<PACKAGE "KEYWORD">
    ; C1:       B917001020       MOV ECX, 537919511
    ; C6:       41BB4F001020     MOV R11D, 537919567              ; T
    ; CC:       490F44CB         CMOVEQ RCX, R11
    ; D0:       EBDB             JMP L1

    (defun* variablep (term)
      (:returns boolean)
      (and (symbolp term)
        (char= (char (symbol-name term) 0) #\?)))

    ; disassembly for VARIABLEP
    ; Size: 99 bytes. Origin: #x1006B1C2AF
    ; 2AF:       4881FA17001020   CMP RDX, 537919511              ; no-arg-parsing entry point
    ; 2B6:       7418             JEQ L2
    ; 2B8:       8D42F1           LEA EAX, [RDX-15]
    ; 2BB:       A80F             TEST AL, 15
    ; 2BD:       7506             JNE L0
    ; 2BF:       807AF145         CMP BYTE PTR [RDX-15], 69
    ; 2C3:       740B             JEQ L2
    ; 2C5: L0:   BA17001020       MOV EDX, 537919511
    ; 2CA: L1:   488BE5           MOV RSP, RBP
    ; 2CD:       F8               CLC
    ; 2CE:       5D               POP RBP
    ; 2CF:       C3               RET
    ; 2D0: L2:   488B4A11         MOV RCX, [RDX+17]
    ; 2D4:       8D41F1           LEA EAX, [RCX-15]
    ; 2D7:       A80F             TEST AL, 15
    ; 2D9:       7506             JNE L3
    ; 2DB:       8079F1E5         CMP BYTE PTR [RCX-15], -27
    ; 2DF:       742C             JEQ L6
    ; 2E1: L3:   8D41F1           LEA EAX, [RCX-15]
    ; 2E4:       A80F             TEST AL, 15
    ; 2E6:       751F             JNE L5
    ; 2E8:       8079F1E1         CMP BYTE PTR [RCX-15], -31
    ; 2EC:       7519             JNE L5
    ; 2EE:       0FB64101         MOVZX EAX, BYTE PTR [RCX+1]
    ; 2F2: L4:   4883F83F         CMP RAX, 63
    ; 2F6:       BA17001020       MOV EDX, 537919511
    ; 2FB:       41BB4F001020     MOV R11D, 537919567             ; T
    ; 301:       490F44D3         CMOVEQ RDX, R11
    ; 305:       EBC3             JMP L1
    ; 307: L5:   0F0B0A           BREAK 10                        ; error trap
    ; 30A:       02               BYTE #X02
    ; 30B:       0F               BYTE #X0F                       ; NIL-ARRAY-ACCESSED-ERROR
    ; 30C:       9B               BYTE #X9B                       ; RCX
    ; 30D: L6:   8B4101           MOV EAX, [RCX+1]
    ; 310:       EBE0             JMP L4

In practice this probably won't be too bad (though this is something Bones
checks a *lot* during the initial parsing pass).

On the plus side, it matches what most other logic libraries use, so it's
familiar.  It also matches GDL, so I won't have to transform things when parsing
a GDL game, which is nice.  It'll also let me write a macro to bind results to
variables, which is a nicer UI than having to pull them out of a data structure.

### 2016-07-04

* Watched the "Julia: To Lisp or Not To Lisp?" talk from [ELS 2016][].  I wish
  he had gone further in depth on how Julia does macros.  He showed a simple
  `timeit` macro but I would have liked to know how to introspect the
  expressions a macro gets and work with them.

    One of the things that makes Lisp macros so nice is that the expressions
  macros get (and the tools you use to work on them) are the same kinds of
  things you use everywhere *else* in the language (lists, symbols, etc).  This
  makes it really frictionless to switch back and forth.  If your macros are
  getting some special `AST_Node` type that you need to learn to work with it
  feels a lot more like work.

* Poked around in `#lisp` and `#sbcl` to clear up some performance-related
  questions I had about Lisp arrays.  I have exciting new ideas for [Bones][].

* Added anonymous variables and the `*_void` instructions to [Bones][].  This
  was more difficult than I anticipated, but part of it was a bunch of
  refactoring that had to happen along the way.

### 2016-07-05

* Did the "Intro to Fractals" episode of [Coding Math][].  Fun stuff.  Need to
  play around with animating them like he did at the very end.

* More [Learning WebGL][].

* Spent most of the day implementing the "logic stack" assertion/retraction
  I [rambled about](https://gist.github.com/sjl/1f4bb73967663af0f9276b491af84140)
  a while back.

    It works, and it looks pretty good in action!  It also cut the time in my
  little benchmark almost in half (because we only need to compile the state
  code once instead of like 3+ times at each node), and it's MUCH nicer to read
  rule definitions now.

    I'm thinking that programatically parsing/running GDL games is actually
  feasible now, so I think that'll be my next step.  Once I can run arbitrary
  GDL games without having to translate the logic by hand I'll have a LOT more
  nice test cases.

### 2016-07-06

* Cleaned up the UI of [Bones][] a bit.  The new function/macro pairs are a lot
  cleaner to read and work with.

* Got a couple of books out of the RU library before it closes for a few weeks
  in the summer.  Started going through [Algorithms and Networking for Computer
  Games][ancg] and made a little [sandbox][] repo to play around in.

* Hacked together a quick [proof of concept][hype] GDL player that can read and
  search arbitrary GDL games.  It's so nice to see things finally starting to
  come together!

### 2016-07-07

* Chatted with my advisor about [Bones][] and GGP stuff.  Lots of new ideas!

### 2016-07-08

* More [Coding Math][].

* After rereading the section of the [WAM book][] on anonymous variables
  I realized I could clean things up a lot in [Bones][].  I *knew* it had to be
  easier than I was making it.

* More [Mazes][].

### 2016-07-09

* Watched the "Designing Downwell Around One Key Mechanic" GDC talk over
  breakfast.  No revolutionary ideas in it, but I love "case studies" of
  really well-done things like this.  It's the same reason I love books like
  Gregory Heisler's [50 Portraits][heisler] -- you can learn a lot from
  listening to someone experienced talk about what goes through their mind as
  they create something.

* Finished the [Learning WebGL][] series.  I'd definitely recommend it.  It's
  a really good introduction to OpenGL if you just want to learn how the damn
  graphics card works without fucking around with the nightmarish C/C++
  build/ecosystem.  Just open a browser and start hitting OpenGL.

* Started the [WebGL Fundamentals][] series.  I want to get a second look at
  this stuff before I dive in and try to poke at it with Lisp.

* Started screwing around with [parenscript][] in my little [sandbox][].

* Poked a bit more at the [ANCG book][ancg].  Gonna try to take this one in
  bite-sized pieces.

* More [Coding Math][].

* Poked around at some basic GGP games, which revealed some bugs and memory
  problems in [Bones][], so I fixed them.

### 2016-07-10

* Watched the "Learning Through Failure - Portico" GDC talk.  Short but good.
  I think the best idea in is was "players only learn through failure when they
  *understand* what went wrong".

* Brain dumped some stuff about [Bones][] below.

* Removed the stupid garbage `set-*` opcodes from Bones and consolidated them
  into the `unify-*` opcodes like God intended.  Proceeded to rename those
  stupid `unify-*` opcodes to `subterm-*` so mortals can understand what the
  fuck is going on.

* Poked a bit and pushing the constant optimization down into the compilation
  phase, but ran into a bit of a wall so I threw away the diff.  Might take
  another stab at it later once I let it roll around in my head a bit.

* Mostly refactored the Bones code store to be a `simple-array`, after profiling
  indicates that most of the runtime is spent in data vector refs.

#### Splitting the Bones Store

Up until now I've been writing [Bones][] as mostly a transliteration of what's
in the [WAM book][].  This means, for example, that the heap/stack are just
arrays of bytes in memory.  This made it easy to follow along with the book, but
I'm at the point now where I feel like I've wrapped my head around it and am
ready to move on.  My idea for the next big step in Bones is to split the store
into two separate arrays.

The WAM store consists of "cells", each of which has a type and a value.  For
example, reference cells have a type of `REF` and their value is an
index/pointer to whatever they're bound to.  Because I wanted to pack everything
into a single Lisp array, I've implemented this by storing a cell as an
`(unsigned-byte 16)` with a few of the low-order bits used for a type tag.  So
to check the type of a cell, you mask off everything but the low-order bits.  To
get the value, you shift it right.

This works, and is pretty memory-efficient, but has a couple of problems.
First: you need to do masks and shifts all the time which are extra
instructions.  But that's probably not a really huge problem in practice -- CPUs
are fast.  The bigger issue is that because the value of a cell has to be packed
into part of an `unsigned-byte`, you can basically only store integers as cell
values.  For `REF` (and `STR`) cells this is fine (they're just indexes into the
store array), but for functor cells it's not ideal.  Bones currently keeps what
is essentially a symbol table to map functor/arity pairs to integers, which is
really ugly.

This is an annoying layer of indirection, but it also limits us further.  I'd
*really* like to let Bones work with arbitrary Lisp objects.  For example, you
could say something like `(fact (username sally "sal"))` and the string there
would Just Work.  You'd also get support for numerics basically for free (though
I might still special-case those a bit).

So the solution I've been rolling around in my head for a while is to split the
store into two separate arrays: an array of types and an array of values.  The
types array would just store small unique integer tags, so it could be packed
pretty tightly (maybe four-bit bytes for each tag).  The values array would just
be a normal Lisp `(vector t)`.  This means each cell would be 64 bits, and you
could store pointers to normal Lisp objects.

This would let us ditch the symbol table entirely.  Now a functor cell would
just have a tag of `FUN` and the value would be a pointer directly to the Lisp
symbol.  We'd still need to handle the arity, but we can just follow every `FUN`
cell with a second cell containing the Lisp fixnum for the arity.

Crucially, SBCL (and CCL, possibly others) will still store fixnums immediately
in the array, so for `REF` and `STR` cells we don't need to suffer an extra
memory deref -- we've still got the index right there in the array's contiguous
hunk of memory.  And we actually don't need to deref even for functors in this
new scheme; the functor values are pointers, but since we just need to compare
them with `eq` and it just compares the pointers themselves.

This also has another possible benefit: we don't need the WAM at (query) compile
time.  Currently when you compile a query you need to have the WAM object
present, so Bones can shove any functors in the query inside its symbol table.
But now we just store the functor symbols directly, so there's no need to have
the WAM available at compile time.

This means that for queries which are completely known at compile time, we can
do the expensive compilation of query-to-WAM-bytecode at compile time instead of
runtime with a compiler macro.  For example: if we have something like `(defun
legal-moves () (query-all (legal ?role ?move)))` we can, at Lisp compile-time,
process that `(legal ?role ?move)` query into a hunk of WAM bytecode and turn it
into: `(defun legal-moves () (query-all #<array of WAM bytecode>))`.  Then at
runtime we just load that into the query area of the code store and go -- no
expensive bytecode compilation needed.

For dynamic queries where we need to build the query at runtime (e.g. ``(defun
legal-moves-for (role) (invoke-query-all `(legal ,role ?move)))``) we can't do
this, unfortunately.

So there are a bunch of benefits to splitting up the store, but of course there
are also drawbacks.  Obviously it will use more memory, but I don't care much
about that.  Popping things off the stack/heap will also become more expensive
because now we need to null out references to Lisp objects when we pop them, so
they can be GC'ed properly.

It also makes another idea I've had slightly more complicated.

#### Prolog on the GPU

A few months back when I was thinking about topics for my upcoming master's
thesis one of the things on my list was seeing if I could get my WAM queries
running on the GPU using OpenGL.  This could potentially speed things up when
you want to know *all* the results of a query and not just the first.

The basic idea would be something like this.

Ahead of time:

* Write an implementation of the WAM bytecode interpreter (not the compiler,
  just the VM part) in GLSL as a vertex (or possible compute?) shader.
* For each predicate, note how many different choices it has (essentially the
  number of `try/retry/trust` instructions).

The idea would be to divide up the and/or tree of Prolog choices into `N`
subtrees, where `N` is the number of GPU cores you've got.  Then each core
searches a portion of the subtree and you merge the results at the end.

At query time:

* Push the WAM code store to the graphics card as a texture.
* Walk the and/or tree of predicates breadth-first to generate `M <= N`
  "traces", each of which is a list of which choice you picked at a given node.
* Push all those different traces to the vertex shader as vertices.
* Each time the vertex shader runs, it gets one trace which essentially tells it
  which direction to take at each choice point it encounters, so it can skip the
  backtracking and just dive head-first down this one path.
* Once it reaches the end of the trace, it just continues normally and starts
  backtracking when necessary.
* Results can get written to a texture framebuffer or something and pulled out
  at the end.
* Merge the results from all the vertices.

This parallel mode would be heavily restricted.  Things like `cut` would cut off
(no pun intended) the trace at that point, forcing full processing by the shader
from that point on.  And of course anything with side effects would just error
out.  But when you're just grinding through unification of basic Prolog terms it
might potentially speed things up (though the latency to/from the graphics card
memory could be a problem).

All this is just an idea I've had for the far future, but I've been thinking
about it because if I split up the WAM store and start treating functors as Lisp
object pointers, that complicates things.  We can easily push integers up to the
graphics card, but if functors are pointers (which can potentially get moved
around by GC) what can we do?

For a while I thought it was unsolvable, but now I think there might be a way.
If we just keep a global "object index" that maps Lisp objects to integers, we
can use those integers as stand-ins for the actual objects when we're on the
GPU.  Of course that would interfere with GC, but there's a solution.  Most
modern implementations support hash tables with weak values, so if we use that
for the index I think it would fix the problem.  We'd be able to map objects to
fixnums without interfering with GC and leaking memory.

### 2016-07-11

* Finished up the [Bones][] code store refactor and a couple of other minor
  things.

* Switched over the Bones main store to be a `simple-array` too.  Another
  performance increase.  I've switched to a new game for benchmarking because
  the previous one was starting to finish too fast for me to be confident in
  getting sane results.  I think that's a good sign.

* Puttered around with a bunch of other little optimizations.  Not *super*
  productive, but I did learn a lot along the way, so I think it was worth it.

* Today's commits took the runtime for the `aipsrovers01` game from about 47
  seconds down to 19 seconds.  Not too bad!

### 2016-07-12

* Watched the "Interpreting Feedback & Maintaining Your Vision" GDC talk.
  I like the idea of not backing down and changing to try to give users exactly
  what they want all the time.

    The last slide in the talk is the best -- a game is a conduit to get some
  idea/experience from your head into the players' heads.  Players give you
  feedback based on what happens in their heads, but they don't know what's
  going on in yours, so you need to interpret their feedback keeping that in
  mind.

* More [Coding Math][].

* Implemented last call optimization in [Bones][].  Not much of a speed
  improvement for the particular GGP games I've been testing with, but it had to
  happen at some point, so we can write actual Prolog without blowing the stack.

* Got a good start on splitting apart the Bones store like I wrote about above.
  It'll probably take another day or two two finish up.

### 2016-07-13

* Spent an hour or so cleaning up my `.vimrc` and plugins, and moving fully to
  [neovim][].

    The catalyst was discovering [miniyank][].  I've been using [YankRing][] for
  years, but it has always been *super* janky.  The way the original YankRing
  works is to rebind all the keys that could possibly result in yanking text,
  like `d`, `c`, `x`, and `y` to a function that handles them.  As you might
  imagine, this can cause problems -- especially with plugins like [Paredit][]
  that need to manage those keys too.  Miniyank hooks into a new neovim event,
  which lets it do what it needs to do without all the hacky workarounds.

* Finished splitting apart the [Bones][] main WAM store into separate type/value
  arrays.

### 2016-07-14

* Watched the "Distributed High Performance Computing in Common Lisp" talk from
  [ELS 2016][] over breakfast.  It would be really fun to try to get a GGP
  player running on an 11k-core supercomputer...

* Got [Bones][] to run on ECL.  I needed to hack [policy-cond][] to do it, but
  I talked to the ECL maintainer in IRC and hopefully I should be able to remove
  the hack in the future.  Performance is pretty bad, but at least it runs!

* Tried out the [PAIP][] tries for [Hype][]'s transposition tables, but they
  don't seem to be much better than a vanilla CL hash table, at least in SBCL.
  Oh well.

* Wrote a real nasty macro to improve the performance of Bones' hot loop.

* Remapped a couple of more keys on my keyboard and I feel like I'm going
  insane, but I think it'll be worth it in the long run.

### 2016-07-15

* [Got nerd sniped](https://www.reddit.com/r/lisp/comments/4si6qm/go_forth/d5d827u?context=1) by /r/lisp.

* Tried to work on more [Coding Math][] but *something* I did yesterday with
  Roswell completely fucked my CCL/Sketch situation.  First SDL2 wouldn't build
  at all.  Then it built, but the key input, title bar, and cmd-tabbing are all
  broken when running from the command line.  ClozureCL.app works, until I do
  something that throws an exception, then it just hangs forever and can't be
  cmd-tabbed back to.

    I don't know why I keep trying to ever update anything on my computer.
  Everything always breaks all the time because programming, especially
  graphics/GUI programming, is a dumpster fire.  I should just never update
  anything ever.  A fucking lab mouse would have learned by now.

* Added support for arbitrary Lisp objects in the [Bones][] heap, and hooked it
  up for numbers for now.  This is the first real Lisp/Prolog interop I've got,
  which is pretty cool.  It also means I can excise the stupid number-munging
  code from [Hype][].

* Refactored the Bones compiler to use structs in a few places instead of CLOS
  classes to reduce consing a bit.  Also fixed a couple of other hot points and
  split apart the horrifically large `compiler.lisp` file.

* Removed the functor table from the WAM.  This is the first step toward making
  Bones GC-friendly.

* Finished the Bones store split by splitting apart functor cells into functor
  and arity cell pairs.  Now that I know this is going to work I'm excited for
  what I can do with Prolog/Lisp interop in the future.

### 2016-07-16

* Started wrapping my head around the WAM's clause indexing.  I think I mostly
  understand the idea -- I'll need to let it roll around a bit before I try to
  implement it though.

* Went through and removed `defstar` from [Bones][] entirely because apparently
  the fucking thing is GPL'ed.  This is why we can't have nice things.

* Made a tiny little ncurses demo with [cl-charms][] in my [sandbox][].  I'm
  thinking about porting [Silt][] to Common Lisp for the [August 2016 Lisp Game
  Jam](https://itch.io/jam/august-2016-lisp-game-jam), so I figured I should
  make sure things actually work before the jam starts.

    I was pleasantly surprised to see that cl-charms just worked right out of the
  box, even inside neovim's terminal emulator.

* Ported a few of my solutions to [99 Prolog Problems][] from Prolog over to
  Bones as unit tests.  I found one bug in Bones itself from them, and I expect
  they'll be good to have as test cases in the future.

### 2016-07-17

* Wrote a compiler macro in Bones to precompile static queries to WAM bytecode
  at compile time, allowing us to run them by simply loading the code store with
  the contents of the precompiled array and firing off the main loop.  This is
  a lot faster, and ends up saving a lot of consing too.