golly-test Mailing List for Golly

Can I add to Brice's encouragement in the direction of layers rather 
than overly artificial use of rules.

Some time ago I played around with an idea for palettes based on the 
last few generations at each cell so as to bring out gliders, 
oscillators, reactions, etc. but now see layers potentially delivering 
the same benefits with much more flexibility.

About the only other thing that would be needed would be the ability to 
activate an OR map for one or other engine to collect envelope data, 
especially as it sounds like we can assume at least one interchange 
format will be common to each potential engine.


Tony Smith
Complex Systems Researcher
Meme Media
Melbourne, Australia
http://www.meme.com.au/

Andrew, Tom, modular sounds great! Yes the trace / envelope functionality  
requires extra dedicated support, so it doesn't belong in the current  
interface. However the edit layer system would be purely UI and would be  
universally useful for all rules. Here's a few more thoughts... Suppose  
you are tinkering with a pattern design and you are interested in undo-ing  
it back to a particular state. Providing a layer named "scratch state xyz"  
would be easier than providing incremental undo. Just copy this into the  
active layer and start again. It requires the user to plan ahead a little,  
but having several layers of working space also allows a lot of  
flexibility. And this is subtly different from any kind of MDI system you  
might construct. Layers can be overlayed for display without altering the  
layer patterns while MDI windows can only be copy/pasted. If generic  
layers were available, they would provide a straightforward way to  
"insert" the trace / envelope functionality into the UI later on -- simply  
direct the output into a layer to be overlayed. A layers system could also  
allow display colorings based on the states of multiple layers. The  
individual layers could be one-bit deep or n-bit deep, with various  
intersections displayed in varying colors. The red of the "shadow" states  
in my rule could come from the superposition of two one-bit layers, rather  
than from a multi-state rule and color palette. The visual result is the  
same, communicating the same information about the pattern, but the  
layers-way relies on the UI while the rule-way relies on twisting the rule  
logic. The MCell rule I sent out is really just an ugly hack which forces  
the rule table to simulate a layered state space. General rule tables have  
a lot to offer, but they are not the cleanest way to get the functionality  
I showed you. Other simple ideas: Want to highlight every cell with 7  
neighbors? Write a module that outputs a mask to a layer. Want to  
highlight all gliders of phase x and color y? do the same: module -> mask  
-> layer. Or color code the most common ash after a random run? ... UI  
layers could provide a framework for integrating future display features.  
I'm pitching the layers idea because I'm convinced it offers a lot of  
functionality and opportunity -- far beyond the single example I  
demonstrated. But it's the kind of UI thing that probably needs to be  
designed in early -- or at least prepared for early. I know it's a  
2.0-distant feature at best, but I wanted to bring it up now so you could  
mull it over before too many other UI decisions are made.

Dave, thanks for the mention on your blog... that rule is also very useful  
for assembling p46, p30, etc widgets without having to puzzle out the  
exact numerical phase deltas. For example, if you have two p46 rxns that  
produce & consume gliders. You can run one rxn to some arbitrary phase  
with a p46 stream of gliders as input. The chosen stop point could have a  
glider on the input side and a glider on the exit side. You change the  
state of these gliders to the "shadow" marker state and you can then run  
the second rxn until it's output glider can be aligned / overlayed with  
the next input glider shadow. The "shadow" gliders provide reference marks  
that are in-phase with respect to their p46 rxn. If two widgets are out of  
phase, but aligned, simply run one until it's glider aligns with the  
other's reference mark. Since the new phase of a positioned rxn may not be  
the start phase the shadows get out of phase in various parts of the  
assembly -- ugly. This can easily be fixed by nulling all the shadows to  
state 2 or 0 and then changing all live states to 5 again. Then the whole  
assembly has all shadows in sync. (MCell note: if you select / highlight a  
region of cells, they will not be gen'd with the rest of the field. Kind  
of a backwards way to selectively run different parts of a pattern -- but  
that's what's available. The selected area is also not subject to state  
change commands, so you can null one area or swap states in another by  
fiddling with the selection. Warning: the off-screen undisplayed cells are  
also not subject to state change commands, and sometimes don't get gen'd  
either.)

-brice


On Mon, 27 Feb 2006 01:02:29 -0500, David M Greene <dv...@ju...> wrote:

>> Very nice!  After playing around with MCell for a while it's
>> obvious how useful and revealing such a feature can be.
>
> Just FYI -- I've also been playing around with Brice's rule a bit this
> weekend, and put up a sample pattern on my weblog:
>
> http://b3s23life.blogspot.com/2006/02/new-results-from-glue-2.html
>
> There's a version of the same pattern in Koenig's multi-layer annotation
> format, too, for comparison purposes.
>
> More later --
>
>
> Dave Greene
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the live  
> webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

> Very nice!  After playing around with MCell for a while it's 
> obvious how useful and revealing such a feature can be.

Just FYI -- I've also been playing around with Brice's rule a bit this
weekend, and put up a sample pattern on my weblog:

http://b3s23life.blogspot.com/2006/02/new-results-from-glue-2.html

There's a version of the same pattern in Koenig's multi-layer annotation
format, too, for comparison purposes.

More later --


Dave Greene

Andrew, I think that is an excellent idea---a generic MCell-like engine
that also supports this sort of trail, etc.  It will also help firm-up the
interface (which probably has a few warts that will show up when we
interface the more general routine in there).

On 2/26/06, Andrew Trevorrow <an...@tr...> wrote:
> Brice wrote:
>
> > Hi Tom, Andy, Dave, all, I'm following up on my somewhat scrambled
> > comments from before... I realized they would make more sense if I *sho=
w*
> > you what I mean about the pattern history envelope being so useful and
> > nice. Dave Greene's HistoricalLife rule under MCell and David Bell's
> > "tracks" under dblife both display the "shape" of the pattern's evoluti=
on.
> > Rather than blab about how much I like this feature, I've attached (and
> > pasted below) an MCell .mcl file that will show you where this can go.
> > Just load and run. In MCell click on the "i"nfo button to read about th=
e
> > rule, or skim the text of the .mcl file below. This is a modification o=
f
> > Dave's HistoricalLife. It shows both the history "envelope" and display=
s
> > an in-situ "shadow" of the starting pattern. So you get the before, the
> > after, and the shape of the in-between all together on the screen, live=
.
>
> Very nice!  After playing around with MCell for a while it's obvious
> how useful and revealing such a feature can be.
>
> > If you like what you see, here's a few comments about how this might be
> > able to work in Golly someday. ...
> >
> > If Golly could copy the current
> > state into a layer buffer, then you could easily overlay start, finish,
> > different phasings, etc. The history envelope would require a little
> > support from the core generation code, but essentially would be OR'ing
> > generations together into a separate layer buffer.
>
> That last part is where things could get very messy.  Rather than attempt
> to modify the existing qlife/hlife algos, I think it would be better to
> do all this fancy stuff in a new *lifealgo module that concentrates on
> functionality rather than speed.  Note that Tom's design allows new
> engines to be plugged into Golly -- changes to the GUI would be needed
> but they should be reasonably straightforward.  In fact, one of my
> long-term goals has been to write a tlifealgo module that would support
> different topologies (torus, Klein bottle, etc, as in my LifeLab).
> I'm now thinking more along the lines of mlifealgo (m for MCell-clone!)
> which would also allow more than 2 cell states, different neighborhoods,
> etc.  Maybe in Golly 2.0...
>
> Andrew
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

Brice wrote:

> Hi Tom, Andy, Dave, all, I'm following up on my somewhat scrambled  
> comments from before... I realized they would make more sense if I *show*  
> you what I mean about the pattern history envelope being so useful and  
> nice. Dave Greene's HistoricalLife rule under MCell and David Bell's  
> "tracks" under dblife both display the "shape" of the pattern's evolution.  
> Rather than blab about how much I like this feature, I've attached (and  
> pasted below) an MCell .mcl file that will show you where this can go.  
> Just load and run. In MCell click on the "i"nfo button to read about the  
> rule, or skim the text of the .mcl file below. This is a modification of  
> Dave's HistoricalLife. It shows both the history "envelope" and displays  
> an in-situ "shadow" of the starting pattern. So you get the before, the  
> after, and the shape of the in-between all together on the screen, live.

Very nice!  After playing around with MCell for a while it's obvious
how useful and revealing such a feature can be.

> If you like what you see, here's a few comments about how this might be  
> able to work in Golly someday. ...
> 
> If Golly could copy the current  
> state into a layer buffer, then you could easily overlay start, finish,  
> different phasings, etc. The history envelope would require a little  
> support from the core generation code, but essentially would be OR'ing  
> generations together into a separate layer buffer.

That last part is where things could get very messy.  Rather than attempt
to modify the existing qlife/hlife algos, I think it would be better to
do all this fancy stuff in a new *lifealgo module that concentrates on
functionality rather than speed.  Note that Tom's design allows new
engines to be plugged into Golly -- changes to the GUI would be needed
but they should be reasonably straightforward.  In fact, one of my
long-term goals has been to write a tlifealgo module that would support
different topologies (torus, Klein bottle, etc, as in my LifeLab).
I'm now thinking more along the lines of mlifealgo (m for MCell-clone!)
which would also allow more than 2 cell states, different neighborhoods,
etc.  Maybe in Golly 2.0...

Andrew

Hi Tom, Andy, Dave, all, I'm following up on my somewhat scrambled  
comments from before... I realized they would make more sense if I *show*  
you what I mean about the pattern history envelope being so useful and  
nice. Dave Greene's HistoricalLife rule under MCell and David Bell's  
"tracks" under dblife both display the "shape" of the pattern's evolution.  
Rather than blab about how much I like this feature, I've attached (and  
pasted below) an MCell .mcl file that will show you where this can go.  
Just load and run. In MCell click on the "i"nfo button to read about the  
rule, or skim the text of the .mcl file below. This is a modification of  
Dave's HistoricalLife. It shows both the history "envelope" and displays  
an in-situ "shadow" of the starting pattern. So you get the before, the  
after, and the shape of the in-between all together on the screen, live.  
The shadow state and the history state behave like background cells except  
for their colorings.

I find this rule very useful for two things: A) following the logic of  
engineered patterns, especially those lumpy herschel track things, and  
also any really complex machinery like the telegraph line or turing  
machines. Complex patterns make so much more sense when you can see the  
"shape" of the reactions and the placements of the pathways. B) I also use  
this a lot when screening the results of gencols searches. It is very easy  
to screen out junk results just by looking at the shape of the reaction. I  
can screen several thousand reactions in 5-10 min by gridding them and  
letting my eye find the ones with good shapes and interesting  
before-and-after placements. I find the envelope shape conveys more  
information, and quicker, than the start or end patterns alone. Large  
searches become more practical this way, even when gencols is not  
sophisticated enough to narrow the results to less than 50,000 final rxns.  
Plus I've learned a lot just by seeing so many variations on themes.  
Anyhow...

If you like what you see, here's a few comments about how this might be  
able to work in Golly someday. MCell implements this via a generalized  
rule table which amounts to an adjacency table for a state transition  
graph. It is very flexible, and it is costly to compute. One big downside  
to implementing the envelope cells as part of the runtime rule is that the  
"live" cell population includes all the envelope cells -- all these  
background cells must be run through the rule table every gen. A  
generalized rule table may or may not have a place in Golly. (It's not on  
my wishlist.) I think dblife's "tracks" are done differently, and more  
efficiently. I believe the program keeps track of all the cell coordinates  
that have ever been alive in a data structure separate from the running  
pattern. This historical "track" is overlayed at display time, and only  
marginally affects runtime performance.

Rather than adding general rule tables to Golly, I think much more benefit  
would come from adding Photoshop style layers to the display and edit  
code. Dblife's tracks are essentially a layer that can be overlayed or  
not. The shadow states in my MCell rule could just as well be part of a  
static layer containing the start pattern. If Golly could copy the current  
state into a layer buffer, then you could easily overlay start, finish,  
different phasings, etc. The history envelope would require a little  
support from the core generation code, but essentially would be OR'ing  
generations together into a separate layer buffer. One downside to my  
MCell rule is that all the states exist together in a single plane. The  
blue background can be useful for aligning two patterns or deciding if two  
reactions will fit together, but it can also get in the way since it will  
overwrite live cells when pasted.

If Golly had a Photoshop style layer system, then the envelope could be a  
display-only layer. It would provide guidance, but not interfere with  
placements. If you were composing a complex pattern, you could store  
segments in separate layers. A "merge layers" style command could let you  
select which layers to merge into a runnable pattern layer. One other  
benefit would be a much more sophisticated cut/paste capability. Rather  
than have a single invisible copy buffer (Ctrl-C) you could use layer(s)  
as intermediate scratch space. You'd have all the benefits of multiple  
copy buffers, with the huge advantage that everything would be visible  
(unlike Ctrl-V). Analogs to locks and channels and groupings may also be  
useful. Run-lock the scratch layer so it never gets gen'd during  
copy/paste/edit ops. And the history envelope layers ideally would remain  
grouped with the pattern layer from which they came -- this is similar to  
the sub-channel vs. layer distinction in Photoshop.

Layers could also implement Dave's "pattern object grouping" almost for  
free. Dave would initially have to lasso and place his objects on sparate  
layers, but afterwards the selection logic could simply select the entire  
layer when he clicks on member cells. Draging could simply shift the  
entire layer. No need to delineate the actual physical cell group every  
time you touch it. And no need for sophisticated pattern matching or  
pattern decompositions, which can only be easy in the simplest, most  
connected cases -- how does a program know that all four end-blocks belong  
to a p46 osc? they aren't even 2-connected much of the time. You can  
hand-sew a library of heuristic cheats for specific patterns of interest  
like WinLife32 does, but the general problem seems very hard. Implementing  
layers would be a lot less complex than solving the general problem of  
finding functional pattern groups and finding psuedo still lifes, etc.  
Layers are not as sexy as AI, but they would accomplish the same results  
with little extra effort.

Dreams, dreams, dreams...

Below is the text of the .mcl attachment in case something breaks in  
transit. Just copy the lines between the lines to a file with a .mcl  
suffix. Every line in the file should begin with a hash mark (#), in case  
the emailers play with the line breaks. Hopefully the attchment makes it  
through the list server. If anyone is on linux, MCell runs well under wine.

P.S. thanks Tom for the link!

-brice

--------------------------------------------------------------------------------------------------
#MCell 4.20
#GAME Rules table
#RULE 1,0,1,0,0,0,1,0,0,0,0,0,0,2,2,1,1,2,2,2,2,2,0,2,2,2,1,2,2,2,2,2,
#RULE 0,8,8,5,5,8,8,8,8,8,0,0,0,0,0,0,0,0,0,0,0,8,8,5,5,8,8,8,8,8,0,0,
#RULE 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8,8,8,5,8,8,8,8,8
#PALETTE 3 colors
#D RULE: RunHistLife BeforeAfter
#D .
#D Simulates Conway' Life --  simultaneously showing an in situ shadow of  
the start state, and a
#D cumulative envelope of pattern history.
#D .
#D USAGE: Start Cells in State 5 (or 3). To run a regular life pattern,  
use the "Colors/Change State
#D of All Alive Cells" menu command and choose state 5. Cells started from  
state 1 will not leave a
#D shadow.
#D .
#D To rerun a sequence of generations, the starting and ending patterns  
can be interchanged
#D using the "Colors/Change State X to State Y" menu command. First change  
state 8 to state 5 to
#D reactivate the starting pattern. Then change state 1 to state 8  
(shadow) or 2 (background) to
#D inactivate ending pattern. Blue background can be left in place without  
affecting new run.
#D .
#D COLORS: using standard 3-color palette: live cells = green or yellow;  
starting pattern shadow
#D cells = red or yellow; cells previously live but now dead = blue.
#D .
#D STATES:
#D state 1 = live cells
#D state 2 = dead cells previously alive = cumulative history
#D state 3 = alternative start state - equivalent to state 5
#D state 5 = live cells superimposed on shadow cells
#D state 8 = shadow cells = historical start cells
#D .
#D Credits: rule by Brice Due -- an extension of Dave Greene's  
HistoricalLife rule
#D .
#D a) Stable glider to LWSS converter
#D This device uses Paul Callahan's stable glider to Herschel converter  
and various
#D Herschel conduits. At the time of this writing (June 1998) this device  
is the smallest
#D of its kind. Dieter Leithner, 9 Aug 1997
#D b) p00221.lif from Dieter & Peter's Gun Collection,
#D featuring a Boojum reflector... don't look!
#D c)A selection of p46 glider and spaceship reflectors from David Bell's  
Collection.
#D Slow reflector at lower-left by David Bell, 13 Sep 96.
#D Glider->2glider reflector by Paul Callahan, 27 Jun 94.
#D d)mosaic of Jason Summer's quadruplicator, from David Green's blockish  
& blockic
#L 295.AA$295.AA$313.AA$313.AA4$299.AA$298.A..A$299.AA$115.E$113.3E38.E
#L 162.AA$58.EE52.E41.3E110.AA48.AA4.AA$48.EE7.E.E15.EE35.EE16.E26.E22.E
#L 20.E65.AA54.AA$48.EE7.E17.EE51.3E25.EE20.3E11.E7.E.E107.A$57.3E67.E49.
#L E14.3E6.E107.A.A$127.EE48.EE16.E16.E96.A.A$194.EE14.3E79.A11.AA4.A$
#L 147.E61.E81.A.A10.AA$57.3E43.EE40.3E61.EE60.AA18.A.A33.AA$57.E17.EE26.
#L EE39.E125.A..A18.A33.A..A$57.E.E15.EE54.EE11.EE125.AA12.AA40.AA$58.EE
#L 71.EE152.AA$187.EE25.EE129.AA$100.EE85.EE25.E130.AA$100.EE110.E.E58.AA
#L 27.AA$212.EE59.AA7.A18.A..A33.A$29.EE250.A.A10.AA6.AA33.A.A$28.E.E250.
#L A.A9.A..A40.A.A$28.E170.EE63.A17.A11.AA24.A11.AA4.A$27.EE10.3E114.EE
#L 32.EE6.E.E62.A.A53.A.A10.AA$41.E78.EE34.EE11.EE20.E6.E64.A.A42.AA9.A.A
#L $40.E79.E.E46.E20.E6.EE65.A43.AA10.A$122.E47.3E17.EE$122.EE48.E83.AA
#L 26.A27.AA$256.AA25.A.A26.AA$116.EE34.EE129.A.A$115.E.E34.E121.AA8.A4.
#L AA11.A27.AA$116.E14.EE20.3E45.EE70.A..A12.AA10.A.A25.A..A$132.E22.E44.
#L E.E71.AA25.A.A18.AA6.AA$129.3E68.E54.AA45.A18.A..A$129.E69.EE54.AA65.
#L AA12.AA$336.AA$$246.AA$246.AA30.AA11.AA27.AA$94.EE182.AA10.A..A18.A7.
#L AA$94.EE163.AA30.AA6.AA10.A.A25.AA$258.A..A36.A..A9.A.A24.A..A$259.AA
#L 14.AA22.AA11.A17.A8.AA$59.EE214.AA52.A.A$59.E.E170.EE95.A.A25.AA$61.E
#L 170.E.E95.A26.AA$16.3E42.EE30.EE139.E26.AA38.AA$18.E74.EE25.EE103.EE7.
#L EE25.AA7.A30.AA7.A39.A$17.E102.E104.E.E41.A.A10.AA25.A.A37.A.A$121.3E
#L 85.EE16.E41.A.A9.A..A24.A.A37.A.A$123.E85.EE16.EE23.A17.A11.AA8.A17.A
#L 8.AA11.A17.A$123.E.E125.A.A37.A.A24.A..A9.A.A$124.E.E73.EE.E47.A.A37.A
#L .A25.AA10.A.A$125.E3.EE69.E.EE48.A39.A39.A7.AA$129.EE54.E32.EE120.AA$
#L 145.E37.3E32.E25.AA26.A34.A$94.EE47.3E13.E22.E33.E.E25.AA25.A.A32.AA$
#L 93.E.E46.E16.3E20.EE32.EE53.A.A32.A.A17.AA$93.E23.EE23.EE18.E99.AA8.A
#L 17.A11.AA22.AA14.AA$92.EE23.EE42.EE38.E59.A..A24.A.A9.A..A36.A..A$201.
#L 3E58.AA25.A.A10.AA6.AA30.AA$97.EE93.E11.E76.AA7.A18.A..A10.AA$89.EE.EE
#L ..E..E92.3E8.EE14.E61.AA27.AA11.AA30.AA$89.EE.E4.E.E95.E22.E.E134.AA$
#L 92.E5.E95.EE23.E$89.EE.E.EE169.AA$89.EE.E..E55.EE112.AA12.AA65.AA$93.E
#L 4.E52.EE125.A..A18.A45.AA$94.5E29.EE141.AA6.AA18.A.A25.AA$113.EE12.E.E
#L 140.A..A25.A.A10.AA12.A..A$96.E16.E.E11.E143.AA27.A11.AA4.A8.AA$95.E.E
#L 17.E10.EE10.EE177.A.A$37.EE57.E18.EE22.E149.AA26.A.A25.AA$20.EE15.E.E
#L 77.E18.3E9.EE32.EE105.AA27.A26.AA$20.EE17.E75.3E18.E11.E20.EE11.EE23.
#L EE$37.3E74.E34.E20.E36.E74.A10.AA43.A$114.EE32.EE17.3E38.3E70.A.A9.AA
#L 42.A.A$167.E42.E58.AA10.A.A53.A.A$264.A4.AA11.A24.AA11.A17.A$37.3E146.
#L EE75.A.A40.A..A9.A.A$20.EE17.E11.EE134.E75.A.A33.AA6.AA10.A.A$20.EE15.
#L E.E10.E.E15.EE114.3E77.A33.A..A18.A7.AA$37.EE11.E17.EE46.EE66.E114.AA
#L 27.AA$50.3E63.EE138.AA$92.EE162.AA$91.E.E222.AA$91.E182.AA40.AA12.AA$
#L 50.3E37.EE181.A..A33.A18.A..A$50.E17.EE204.AA33.A.A18.AA$50.E.E15.EE
#L 227.AA10.A.A$51.EE239.A4.AA11.A$291.A.A$151.E139.A.A$151.3E138.A$38.EE
#L 87.E26.E22.E100.AA54.AA$37.E.E85.3E25.EE20.3E100.AA4.AA48.AA$39.E84.E
#L 49.E109.AA$124.EE48.EE$247.EE53.AA$144.E49.E52.EE52.A..A$142.3E47.3E
#L 17.EE39.E48.AA$141.E49.E20.E39.E$128.EE11.EE35.EE11.EE20.E38.3E$128.EE
#L 48.EE32.EE$221.EE65.AA$220.E.E65.AA$26.3E192.E47.EE35.AA$28.E239.3E35.
#L AA$27.E240.EE.E$97.EE21.EE87.EE58.3E$97.EE21.E.E86.EE29.EE28.E$103.EE
#L 17.E30.EE85.EE$103.EE17.EE29.EE11.EE$166.E$167.3E$101.EE66.E$101.EE5.
#L EE$108.EE39.EE48.EE$149.E49.E53.EE$128.EE20.3E25.EE20.3E50.EE$129.E22.
#L E26.E22.E46.EE$80.EE44.3E47.3E70.E.E$80.E.E43.E49.E74.E$82.E168.EE$82.
#L EE131.E22.EE$77.EE135.E.E21.EE$77.E.E135.E$79.E$79.EE155.EE$220.EE14.
#L EE32.EE$134.EE59.EE23.EE48.3E$134.E..E.E56.E31.EE39.E.EE$136.EE.3E54.E
#L .E29.E40.3E$142.E54.EE27.E.E41.E$34.EE5.EE93.EE.3E78.EE4.EE$34.EE5.EE
#L 93.EE.E80.EE$$186.EE$101.EE84.E40.EE$102.E84.E.E8.E.E28.E$100.E87.EE8.
#L EE24.EE.E$100.EE97.E24.EE.EE102.EE$92.E113.EE123.E$92.3E111.EE16.EE.EE
#L 100.E.E$95.E103.EE24.E.E101.EE$94.EE102.E..E23.E.E$199.EE25.E$97.E5.EE
#L $96.3E4.EE$95.3E.EE157.EE$94.E3.3E140.EE15.E.E$33.EE.E3.E.EE49.E4.E
#L 142.EE17.E$33.E..E3.E..E48.EE164.3E$34.3E3.3E49.E.E$89.E..E..E103.EE$
#L 88.EE3.E.E17.EE84.EE$88.E.E23.E73.E69.3E$111.3E74.EE51.EE17.E7.EE$111.
#L E17.EE56.E.E51.EE15.E.E7.EE$109.E.E18.E127.EE$47.EE60.EE16.3E$46.E.E.
#L EE8.EE9.EE54.E$45.EE3.EE9.EE8.EE12.EE$46.E.E.EE5.5E23.E$47.EE8.4E26.E.
#L EE18.EE$86.EE.EE18.E.E$57.4E50.E57.E.E$57.5E24.EE.EE20.EE56.EE$44.EE
#L 15.EE8.EE14.E.E80.E32.EE5.EE34.EE$23.EE19.EE14.EE9.EE14.E.E68.EE43.EE
#L 5.EE34.EE$24.EE62.EE.EE65.EE$23.E66.E.E$90.E31.EE$89.EE31.E$120.E.E$
#L 119.E.E$115.EE3.E20.E187.EE$115.EE23.E.E103.3E3.3E74.E.E$139.E..E102.E
#L ..E3.E..E75.E$131.3E6.EE103.EE.E3.E.EE75.EE$12.E117.5E$12.EE115.E.5E
#L 15.EE113.EE$11.E.E114.EE.3E..EE13.EE112.EE$129.3E..E.EE129.E$130.E6.EE
#L 30.EE$134.E..E31.E.E30.EE.E3.E.EE$134.3E34.E30.E..E3.E..E$171.EE30.3E
#L 3.3E$96.EE$96.EE$102.EE$102.EE56.EE$EE60.EE96.E.E115.E$.EE59.E.E97.E
#L 114.EE$E63.E35.EE60.EE113.E.E$64.EE34.EE5.EE40.EE52.EE41.EE5.EE$107.EE
#L 40.EE52.EE41.EE5.EE$$130.E$131.E15.EE$129.3E15.EE$223.EE$222.EE$224.E
#L 4$138.EE$138.E.E$140.E$140.EE$$235.E$234.EE$234.E.E

-------------------------------------------------------------------------------------------



On Tue, 14 Feb 2006 17:59:51 -0500, Brice <bri...@ve...> wrote:

> "going backward": prog maintains an m-gen deep buffer of the most recent  
> gens displayed. Stores entire gen plus hash of gen for quick period  
> recognition. If you try to backup more than m-gens, the prog backtracks  
> to a sparser list of every (n*m)'th gen and recalcs the previous block  
> of m-gens. You can notice the delays if you use a very large pattern and  
> hold down the PgDn key to autorepeat... prog periodically will pause to  
> recalc the m-gen buffer (puts up a dialog during the pause). Only  
> current gen +/- m-gens is held in memory. Author describes some of this  
> in various places.
>
> This FastForward/Rewind feature would be more useful in the context of  
> Dave Greene's HistoricalLife rule under MCell. You could then see how  
> the pattern progresses within the "envelope" of the entire pattern  
> history. In other words, if the PgDn showed the prior gens overlayed on  
> top of the current history "envelope", then you could see how the  
> pattern re-approaches the current "envelope" boundries. I find that the  
> rewind is a cool toy for a short while, then I notice that it also  
> rewinds all context, which makes it cool, but less useful.
>
> -brice
>
> On Tue, 14 Feb 2006 16:53:59 -0500, Tom Rokicki <ro...@gm...>  
> wrote:
>
>> That's an interesting program!
>>
>> His "going backward" link is actually surprisingly fast.  I'll have to
>> examine how he does
>> this.
>>
>> Definitely some cool ideas.  I think for this next round though, we
>> may focus solely on
>> Python integration for now.
>>
>> I wonder if he makes source available . . .
>>
>> -tom
>>
>> On 2/14/06, Dave Greene <dv...@ju...> wrote:
>>> A tangential topic, while I'm eating lunch and cleaning up my Drafts  
>>> folder:

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

"going backward": prog maintains an m-gen deep buffer of the most recent  
gens displayed. Stores entire gen plus hash of gen for quick period  
recognition. If you try to backup more than m-gens, the prog backtracks to  
a sparser list of every (n*m)'th gen and recalcs the previous block of  
m-gens. You can notice the delays if you use a very large pattern and hold  
down the PgDn key to autorepeat... prog periodically will pause to recalc  
the m-gen buffer (puts up a dialog during the pause). Only current gen +/-  
m-gens is held in memory. Author describes some of this in various places.

This FastForward/Rewind feature would be more useful in the context of  
Dave Greene's HistoricalLife rule under MCell. You could then see how the  
pattern progresses within the "envelope" of the entire pattern history. In  
other words, if the PgDn showed the prior gens overlayed on top of the  
current history "envelope", then you could see how the pattern  
re-approaches the current "envelope" boundries. I find that the rewind is  
a cool toy for a short while, then I notice that it also rewinds all  
context, which makes it cool, but less useful.

-brice

On Tue, 14 Feb 2006 16:53:59 -0500, Tom Rokicki <ro...@gm...> wrote:

> That's an interesting program!
>
> His "going backward" link is actually surprisingly fast.  I'll have to
> examine how he does
> this.
>
> Definitely some cool ideas.  I think for this next round though, we
> may focus solely on
> Python integration for now.
>
> I wonder if he makes source available . . .
>
> -tom
>
> On 2/14/06, Dave Greene <dv...@ju...> wrote:
>> A tangential topic, while I'm eating lunch and cleaning up my Drafts  
>> folder:
>>
>> I hadn't looked at John Harper's WinLife32 player recently, until a  
>> query came in a couple of days ago from someone named Jim Romig who was  
>> using it to play around with a programmable constructor.  Have you seen  
>> the 2004 release?  Turns out that it's been updated more recently than  
>> Life32 has...  It has an extensible pattern glossary in Xlife format  
>> (!) that it uses to auto-recognize and auto-register subpatterns.  It  
>> does quite a bit of clever monitoring of simulations -- notifies you  
>> when a pattern has evolved to the point where it's no longer  
>> "interesting", and so forth.
>>
>> WinLife32 can also handle non-rectangular selections very cleanly (via  
>> ctrl-double-click... not sure why that couldn't just be ctrl-click, but  
>> I guess that's for adding single cells to the selection).  And I really  
>> like the PageUp / PageDown way of going forward and backward on  
>> moderate-sized patterns -- going backwards indefinitely, on a cyclic  
>> pattern like TRACK.LIF in the WinLife32 pattern library, is kind of a  
>> surreal experience.
>>
>> The pattern editing features seem powerful enough to compare favorably  
>> with either MCell or Life32 (don't know enough to compare with  
>> LifeLab...)  It's certainly an innovative app -- he obviously designed  
>> it from the ground up without much influence by old-guard Life Listers,  
>> since he uses his own non-standard terminology for a lot of concepts --  
>> "growing" a "game" instead of "running" a "pattern", etc.
>>
>> Anyway, it looked like there might be some good ideas in the WinLife32  
>> implementation that Golly could borrow.  -- And yes, I realize in a  
>> project like this, mentioning a possible improvement is tantamount to  
>> volunteering to work on it oneself.  Kind of like the old joke about  
>> the first one to criticize the cooking.  But it remains to be seen  
>> whether I'll manage to get familiar enough with Golly and wxWidgets to  
>> be able to contribute anything useful.  It seemed safest to start with  
>> an import parser, since I'm usually good at those.
>>
>> [Last night turned out to be mostly taken up by just downloading the  
>> wxWidgets package; being a cheapskate, I cut my Internet bill by 80%  
>> last year by downgrading to dialup.  On balance I haven't regretted it  
>> yet -- it actually saves me a lot of time, because now there are lots  
>> of things out there that I know better than to waste time trying to  
>> look at...]
>>
>> Keep the cheer,
>>
>>
>> Dave Greene
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log  
>> files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
>> _______________________________________________
>> Golly-test mailing list
>> Gol...@li...
>> https://lists.sourceforge.net/lists/listinfo/golly-test
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log  
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

That's an interesting program!

His "going backward" link is actually surprisingly fast.  I'll have to
examine how he does
this.

Definitely some cool ideas.  I think for this next round though, we
may focus solely on
Python integration for now.

I wonder if he makes source available . . .

-tom

On 2/14/06, Dave Greene <dv...@ju...> wrote:
> A tangential topic, while I'm eating lunch and cleaning up my Drafts fold=
er:
>
> I hadn't looked at John Harper's WinLife32 player recently, until a query=
 came in a couple of days ago from someone named Jim Romig who was using it=
 to play around with a programmable constructor.  Have you seen the 2004 re=
lease?  Turns out that it's been updated more recently than Life32 has...  =
It has an extensible pattern glossary in Xlife format (!) that it uses to a=
uto-recognize and auto-register subpatterns.  It does quite a bit of clever=
 monitoring of simulations -- notifies you when a pattern has evolved to th=
e point where it's no longer "interesting", and so forth.
>
> WinLife32 can also handle non-rectangular selections very cleanly (via ct=
rl-double-click... not sure why that couldn't just be ctrl-click, but I gue=
ss that's for adding single cells to the selection).  And I really like the=
 PageUp / PageDown way of going forward and backward on moderate-sized patt=
erns -- going backwards indefinitely, on a cyclic pattern like TRACK.LIF in=
 the WinLife32 pattern library, is kind of a surreal experience.
>
> The pattern editing features seem powerful enough to compare favorably wi=
th either MCell or Life32 (don't know enough to compare with LifeLab...)  I=
t's certainly an innovative app -- he obviously designed it from the ground=
 up without much influence by old-guard Life Listers, since he uses his own=
 non-standard terminology for a lot of concepts -- "growing" a "game" inste=
ad of "running" a "pattern", etc.
>
> Anyway, it looked like there might be some good ideas in the WinLife32 im=
plementation that Golly could borrow.  -- And yes, I realize in a project l=
ike this, mentioning a possible improvement is tantamount to volunteering t=
o work on it oneself.  Kind of like the old joke about the first one to cri=
ticize the cooking.  But it remains to be seen whether I'll manage to get f=
amiliar enough with Golly and wxWidgets to be able to contribute anything u=
seful.  It seemed safest to start with an import parser, since I'm usually =
good at those.
>
> [Last night turned out to be mostly taken up by just downloading the wxWi=
dgets package; being a cheapskate, I cut my Internet bill by 80% last year =
by downgrading to dialup.  On balance I haven't regretted it yet -- it actu=
ally saves me a lot of time, because now there are lots of things out there=
 that I know better than to waste time trying to look at...]
>
> Keep the cheer,
>
>
> Dave Greene
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

A tangential topic, while I'm eating lunch and cleaning up my Drafts fol=
der:

I hadn't looked at John Harper's WinLife32 player recently, until a quer=
y came in a couple of days ago from someone named Jim Romig who was usin=
g it to play around with a programmable constructor.  Have you seen the =
2004 release?  Turns out that it's been updated more recently than Life3=
2 has...  It has an extensible pattern glossary in Xlife format (!) that=
 it uses to auto-recognize and auto-register subpatterns.  It does quite=
 a bit of clever monitoring of simulations -- notifies you when a patter=
n has evolved to the point where it's no longer "interesting", and so fo=
rth.

WinLife32 can also handle non-rectangular selections very cleanly (via c=
trl-double-click... not sure why that couldn't just be ctrl-click, but I=
 guess that's for adding single cells to the selection).  And I really l=
ike the PageUp / PageDown way of going forward and backward on moderate-=
sized patterns -- going backwards indefinitely, on a cyclic pattern like=
 TRACK.LIF in the WinLife32 pattern library, is kind of a surreal experi=
ence.

The pattern editing features seem powerful enough to compare favorably w=
ith either MCell or Life32 (don't know enough to compare with LifeLab...=
)  It's certainly an innovative app -- he obviously designed it from the=
 ground up without much influence by old-guard Life Listers, since he us=
es his own non-standard terminology for a lot of concepts -- "growing" a=
 "game" instead of "running" a "pattern", etc.

Anyway, it looked like there might be some good ideas in the WinLife32 i=
mplementation that Golly could borrow.  -- And yes, I realize in a proje=
ct like this, mentioning a possible improvement is tantamount to volunte=
ering to work on it oneself.  Kind of like the old joke about the first =
one to criticize the cooking.  But it remains to be seen whether I'll ma=
nage to get familiar enough with Golly and wxWidgets to be able to contr=
ibute anything useful.  It seemed safest to start with an import parser,=
 since I'm usually good at those.

[Last night turned out to be mostly taken up by just downloading the wxW=
idgets package; being a cheapskate, I cut my Internet bill by 80% last y=
ear by downgrading to dialup.  On balance I haven't regretted it yet -- =
it actually saves me a lot of time, because now there are lots of things=
 out there that I know better than to waste time trying to look at...]

Keep the cheer,


Dave Greene

Dave:

> Rectangular chunks... As I recall, you've been leaving the possibility open of supporting non-rectangular selections in the future?  I don't mean that it's important now, but it does seem like a nice feature to keep in mind, to leave the option open for later.  Don't know about anyone else, but I seem to get into a lot of situations where I want to grab something diamond-shaped and move it a little.

Yep, I would hope we eventually support non-rectangular selections.
Probably not in 1.0 unless someone else is willing to tackle it!

Re scripting...

I've now got Golly doing everything PLife can do, plus a bit more.
Still a few refinements needed, but things are looking good.
Dave, are you able to build Golly from CVS?  If not, I can upload
a Win build on my ftp site in a few days (and a Mac build if
anybody wants to try it?).

Andrew

> set_rule  - Set rule according to string
> parse     - Parse RLE or Life1.05 string and return a cell list
> transform - Apply an affine transformation to given cell list
> put       - Print transformed pattern in Life 1.06 format on stdout
> evolve    - Evolve given cell list for n gens and return new list
> load      - Load pattern from file and return cell list
> save      - Save given pattern to a file (in RLE)
> 
> I plan to implement most of these in Golly.  Some, like put, 
> probably don't make sense (or I could put the results in the
> clipboard).

I like the clipboard idea... though I've never had too much use for Life
1.06 format, come to think of it; it usually takes up a lot more space
than RLE, and even if it doesn't it's all strung out vertically and
painful to work with (in a text editor, I mean).

> > How about "capturing" a pattern from the Golly universe, giving 
> > that a name (like 'pi-heptomino-plus-30-generations') and re-using
> > it as a component of other patterns?
> 
> Yep, I plan to implement a command that converts the current 
> pattern (or any rectangular portion of it) into a list of cells that
> can then be manipulated by the pattern class methods.

Cool.  The only trick is to keep hold of the origin -- the location of
the original pi-or-whatever -- so that the final pattern doesn't end up
shifting around depending on what size it's expanded to.

Rectangular chunks... As I recall, you've been leaving the possibility
open of supporting non-rectangular selections in the future?  I don't
mean that it's important now, but it does seem like a nice feature to
keep in mind, to leave the option open for later.  Don't know about
anyone else, but I seem to get into a lot of situations where I want to
grab something diamond-shaped and move it a little. [Might have something
to do with my bad habit of obsessively optimizing gun patterns...  Nah.]

Life32 has particular difficulties with sticky selection-rectangle
corners picking up things that they aren't supposed to -- there's a
workaround, though, involving a special mouse-cursor mode, the same one
used in handling snapshots... I just didn't find it for a long time! 
With MCell, at least if you pick up a diamond-shaped thing out in empty
space somewhere, you can overlay it onto the main pattern without having
it interfere with other subpatterns until you dismiss the selection.

Here's a random example pattern:  imagine if the top second-from-left p6
in the following pattern has to be moved northwest and rephased, to
correct for changes somewhere else.  A regular rectangle selection picks
up the eaters from the nearby Herschel, and possibly pieces of the
passing glider as well if you're not careful.

Selecting by dragging a diagonally-oriented rectangle might do the trick
here, if that were an option:

#C  P114 gun: Dave Greene, 6 Sep 2002
x = 129, y = 63, rule = B3/S23
54boo$54boo$17bo12boo5boo$17b3o9bobbo5bo$20bo8bobobo4bobo$19boo7boobob
o5boo$30boboboo$6boo14bobboobboobobbo17b3o$6bobo12bobo7boboboboo14b3o$
8bo8boobboo5boobob3obbo12boo3bo28bo8bo12boo$4b4oboobboobboo10bobbo3boo
13bo3boo26b3o8b3o9bobbo$4bobbobobobbo14bob5o15bo3bo26bo14bo8bobobo$bb
oobbo4boo17bo4bo4boo10bobbo26boo12boo7boobobo$bobboobboobo19b4o4bobo
11b3o48bo4boboo$oboobboobobo21bo5bo14bobo42bo4boobobobbo$o3bo5bo24bobb
oo15boo10b3o28bobo3bo3boobboboo$b3obob3o24boo32b3o10bo12boobboo5boobbo
boobbo$3bobobo65boo5bobo11boo10bobobobboo$72bobbo4bobo23bob5o$4b3o21bo
bo42boo6bo4boo19bo4bo$29boo38boo15bobo19b4o$29bo29boo7bobo17bo6bo14bo$
6bo52bo8bo19boo5boo15bo$5bobo52b3o4boo25bobo14boo$6boo39bo14bo$bboo42b
o$bobo42b3o29bobo$bo5boo69bobo3boo$oo5boo70bo4bobo$84bo$$19bo$18boo29b
oo27b3o$18bobo28boo25boobbo$77b3o40boo5boo$78bo41boo5bo$125bobo$125boo
$66bo54boo$16boo42boo4b3o52bobo$16bo22boo19bo8bo52bo$18bo21bo17bobo7b
oo$17b4o19bobo15boo$16bo4bo19boo4bo64bobo$16b5obo23bobo63boo$14boo3bo
bbo10boo11bobo10bo53bo7b5o$13bobb3oboboo5boobboo12bo4boo4bobbo31boo24b
3obob3o$13boobobobo7bobo21bobo3bobbo27boobbo24bo4bo4bo$16bobboboobboo
bbo22bo7bo28bo5bo21boboobobboobo$16boobobo65bobo4b4o19bobo3boobbo$18bo
boboo7boo12boo40boo4bo4bo17boobobbobboo$18bobobo8bo14bo46b5obo14bobbob
o4bo$19bobbo9b3o8b3o45boobbobobo10boobboobboob4o$20boo12bo8bo16bobo27b
obboobobboo5boobboo8bo$61boo6bo20boobobboo3bo3bobo12bobo$61boo5bo24bo
bboboboo4bo14boo$93boobo4bo$66bo28boboboo7boo$65bobbo26bobobo8bo$65bob
o28bobbo9b3o$66bo25bo4boo12bo$73boo18bo$73boo16b3o!

Really I'm looking forward to a time when I can click anywhere on one of
those p6 reflectors and have Golly select the whole thing, because it
knows (from the Python script used to create it?) that that's what that
conglomeration really is.  Might need group / ungroup functionality to
take it apart and get at the component pieces.  -- But there's a lot of
tricky details to deal with there, so I'll try not to mention it (or
think about it) any more for now!

Come to think of it, something like this p114 might be a nice trial
pattern to attempt to build with a Python script in an entertaining way,
when we get to that point:  you could start with a glider heading NW past
a block (bottom center) and add the various catalysts and reflectors just
before the active signal gets to them.  Kind of a "Life-in-the-Dark"
Kriegspiel / Fog-of-War effect.

Really the p114 is just  six p6 reflectors, ten eaters, four blocks, two
toads, and a couple of beehives -- plus three input gliders; the rest of
the gliders and Herschels can be created automatically by running the
pattern.  So a script that can build a pattern in this way, by adding and
subtracting subpatterns over time, would also be a fairly efficient form
of compression.  Doesn't matter for this size, of course, but the same
basic tricks would work for the Caterpillar.

Keep the cheer,


Dave

Dave Greene wrote:

> How about an insert(filepath,x,y) here? -- or else a copy(filepath), to
> pull a pattern from a file onto the clipboard, without affecting the
> existing pattern.

PLife's load(filepath) should handle this -- it will read the given
file and return a cell list which you can then manipulate further.
(I can rename the load command in my first draft to open.)
Of course, we also need a putcells(list,x,y,mode) to paste a given
cell list into the current Golly universe at the given spot.

> Another similar problem I've had with MCell and Life32 automation is that
> it's hard to control where a new pattern shows up in the universe, or
> what coordinates are associated with it when it's saved again.  Both
> programs tend to center newly-opened patterns in the universe, and to
> discard absolute location information when saving patterns back to a
> file.  This can be a bit of a pain when you want, let's say, a pattern's
> input Herschel to stay at (0,0) where you set it up, no matter what shape
> the oscillators around the edges happen to be when you're saving the
> pattern.

I think we should be able to avoid such problems in Golly.

> [Still can't figure out what the syntax should be for RLE-with-origin, by
> the way.  My vote right now would be for a simple #P tag defining the
> upper left corner of the RLE:
> 
> #C sample RLE-with-origin
> #P -10 -10
> x = 22, y = 28, rule = B3/S23

Two thoughts on this:

1. Maybe we don't need it!  If you need an RLE pattern loaded at a
particular spot then just do it via a Python script.

2. If an extended RLE format is deemed desirable then I'd rather avoid
single-letter tags like #P and go for a more sophisticated approach
using a "#RLE+" prefix followed by one or more key=value entries:

#RLE+ pos=-10,-10
x = 22, y = 28, rule = B3/S23
...

This solves other (future) problems.  Consider this example which says
to switch to Wolfram rule 110, set the gen count to 33 and the topology
to a 30x100 torus:

#RLE+ rule=W110 gen=33 torus=30x100
x = 22, y = 28
...

I won't go into any more detail here -- it was mentioned in the LifeCA
list a few years back and didn't arouse much interest.  But I know
this approach works -- I use it in LifeLab's RLE files (with "#LLAB:"
as the prefix rather than "#RLE+").

Back to scripting...

> Might want a plain run() -- presumably the last command in the script, to
> set Golly going until the user hits Stop -- as well as a run-for(t), with
> t in milliseconds.  Maybe a run-to(n) to get to generation n, but that'd
> just be a convenience.

Good idea -- all those could be handy.

> Instead of run-for() -- will it be possible to use a command like
> time.sleep(s) in Python, yielding control to Golly (and/or the operating
> system) for s seconds?

I'll be surprised if Python doesn't have a call like that.

> I guess maybe then you'd need an asynchronous run(), plus a stop() to get
> control back again?  Life32 does things this way -- and the
> asynchronicity has been known to cause some slightly sticky situations.

Yuk -- best to avoid async stuff.

> 'advance(n)' and 'outside(n)' are all very well and good, but with a
> 'clipboard-advance(n)' function -- along with 'copy(filepath)' -- I could
> probably manage to put together a caterpillar.py construction script.  Of
> course 'clipboard-advance(n)' could be faked by pasting the clipboard
> contents to some out-of-the-way corner of the universe, and then
> selecting it and using 'advance(n)' followed by 'cut()' and
> 'paste(x,y)'... it wouldn't necessarily work to paste directly to the
> target location and use 'advance()' there, because the corners of the
> bounding box would often chop pieces out of surrounding subpatterns!

The cell list stuff and the evolve(pattern,ngens) command should simplify
all that.

>>   update() -- redraw the current view (most commands will probably 
>>               do this automatically, but some like setcell will not)
> 
> Maybe an autoupdate(bool) to turn off screen redrawing when the script is
> going to be doing a whole lot of fiddly stuff that's not worth watching
> -- and turn it back on again when it's done?   I seem to recall Life32
> Automation has this option.  In some circumstances it might be okay to
> have screen updates even for setcell() operations.

Good suggestion!

> Okay.  That's probably a lot more than needs to be worried about at this
> stage of the game!  Just wanted to convey my enthusiasm for the
> Python-scripting idea -- might have gotten a little carried away there...

No prob -- that's the sort of feedback I wanted.  Hopefully in a couple
of weeks I'll have something you can play with.

Andrew

Dave Greene wrote:

> ...  I also found PLife fairly inspirational, a year or
> two back; my only problem with it was that the viewer was fairly basic,
> so a PLife script ended up being ... just a kind of structured file
> format, really.

Exactly!  When I first used the PLife viewer I was puzzled why it
didn't let me run any of the supplied scripts (that has to be done
separately by using Python).  Seemed a rather odd approach.

> ...Will it be possible to define named subpatterns in a Golly script, the
> way you can in PLife, and re-use them many times?

Absolutely.  I didn't make it clear in my first post, but I think we
should pretty much duplicate all of PLife's pattern class stuff.
Most of that is actually implemented in Python -- see __init__.py in
plife/python/life/.  The Python code relies only on a few internal
PLife routines implemented in lifeint.cc:

set_rule  - Set rule according to string
parse     - Parse RLE or Life1.05 string and return a cell list
transform - Apply an affine transformation to given cell list
put       - Print transformed pattern in Life 1.06 format on stdout
evolve    - Evolve given cell list for n gens and return new list
load      - Load pattern from file and return cell list
save      - Save given pattern to a file (in RLE)

I plan to implement most of these in Golly.  Some, like put, probably
don't make sense (or I could put the results in the clipboard).
All of these should be quite easy to implement.  Even evolve is easy:
I'll just create a temporary universe, use the given list to set cells,
run the pattern for n gens, use the result to construct a new cell list,
then delete the temporary universe.  Tom's interface makes this nice
and simple.

> Or do you see that as
> a series of copy-paste operations in the Golly GUI?

I think we should allow that as well.  Some people will probably find
it easier to create patterns that way instead of using PLife's more
abstract (but far more powerful) pattern class methods.

> How about
> "capturing" a pattern from the Golly universe, giving that a name (like
> 'pi-heptomino-plus-30-generations') and re-using it as a component of
> other patterns?

Yep, I plan to implement a command that converts the current pattern
(or any rectangular portion of it) into a list of cells that can then
be manipulated by the pattern class methods.  Something like this:

import golly as g
all = g.getcells( g.getbounds() )     # get all cells in current pattern
chunk = g.getcells(0, 0, 10, 10)      # get 10x10 chunk
g.evolve(chunk, 5)                    # advance chunk by 5 gens
combined = all + chunk(6, 9, flip_y)  # add shifted and flipped chunk

The above doesn't do anything useful, and the syntax is probably not
quite right, but it gives you some idea of what will be possible.

Andrew

Tony Smith wrote:

> It appears best practice for a project like this to try to decouple the API from the initial target language so that others can add their alternatives as inclinations change.

Yep, a worthy goal.

> One thing I envisage wanting to add is identifying and counting sub-patterns, so I'd be interested in some way of getting multiple (smallish x and y) cells repeatedly without needing to rerender large areas into a script's working array variables.

Yep, Dave requested much the same thing (I think!) so see my reply to
his message, coming soon...

Andrew

>> The only way I know to "invoke golly" is to start it up. :)
>> Wouldn't bgolly be a better candidate for calling from a Python script?
> 
> Sure, either way works, but will bgolly also be scriptable?

Ah, no, I wasn't planning to do that.  As you know, I'm not all that
interested in bgolly (us Mac-reared folk prefer to Think GUI).
One snag is that Golly's scripting interface (in wxscript.cpp) is based
on a wxScript package I got from wxCode (http://wxcode.sourceforge.net/)
so there are a lot of wxWidgets calls in the code.  I know you want to
keep bgolly free of wx stuff, so the scripting interface would have
to be rewritten to remove all the wx calls and that's a task I'd
prefer to avoid!  Sorry.

Tom, here's a radical suggestion, and I suspect I know your answer,
but here goes...  Given that Golly (the GUI app) can be scripted,
do we really need bgolly any more?  Given a sufficiently powerful
scripting API, Golly + Python should be able to do everything that
bgolly can do.

> The real question is, are you tying in before or after the UI?

After (assuming I understand you correctly).  I want scripts to be
able to automate the GUI, and the simplest way to get that working
is for the scripting interface to call GUI routines that already
exist.

> Right now, for instance, the cut/paste/rotate/invert
> code is all over UI, where it really belongs in either
> hlifeimpls or a layer between UI and hlifeimpls; do you
> agree?

Yep, that would be a cleaner design.

> Figuring out how to factor that out would be
> a great thing to do (and one I've been playing with,
> but so far unsuccessfully).

Good luck!  I'm not that good at designing abstract interfaces,
especially when it comes to using C++ to implement them.
Maybe 5 years from now when I know a lot more about C++ (and wx)
I can help you re-design the GUI from scratch.  In the meantime,
feel free to hack away at my code -- I'm not emotionally attached
to any of it. :)

Andrew

Andrew Trevorrow wrote:
> Before I race off and implement other routines I want to get feedback
> and suggestions.  Presumably we need to expose most of Golly's commands
> so they can be automated, and we probably need new routines to help
> with sophisticated pattern construction (as in PLife).

I have various crackpot ideas about how "sophisticated pattern
construction" might work, which I'll try not to babble on about _too_
much at this point.  Maybe I could just go back through the Life32 and
MCell automation scripts I've written in the past few years, and document
all the spots where I say something like this in the comments:

// this unprintable blankety-blank doesn't work the way I want it to!
//  Have to do horrible workaround thus-and-so...

-- and then see if Golly can arrange to do the same thing less painfully
somehow.

Meanwhile, here's a random suggestion or two for each of the command
categories in your first draft:

> Anyway, here's a tentative first draft of Golly's scriptable commands:
> File commands:

How about an insert(filepath,x,y) here? -- or else a copy(filepath), to
pull a pattern from a file onto the clipboard, without affecting the
existing pattern.  Otherwise it's a bit of a pain composing patterns out
of smaller pieces -- you'd have to keep saving partial patterns (?) and
then loading new pieces and copying them onto the clipboard (or am I
missing a trick?).

Another similar problem I've had with MCell and Life32 automation is that
it's hard to control where a new pattern shows up in the universe, or
what coordinates are associated with it when it's saved again.  Both
programs tend to center newly-opened patterns in the universe, and to
discard absolute location information when saving patterns back to a
file.  This can be a bit of a pain when you want, let's say, a pattern's
input Herschel to stay at (0,0) where you set it up, no matter what shape
the oscillators around the edges happen to be when you're saving the
pattern.

[Still can't figure out what the syntax should be for RLE-with-origin, by
the way.  My vote right now would be for a simple #P tag defining the
upper left corner of the RLE:

#C sample RLE-with-origin
#P -10 -10
x = 22, y = 28, rule = B3/S23
15boo$14bobo$16bo16$bo$obo$obo15boo$bo16bo$19b3o$14boo5bo$14boo$3o$o$b
o!

Life32 and Xlife can handle the above format (by ignoring the #P); MCell
doesn't like it, but there don't seem to be many people besides me using
MCell these days -- and possibly something like this would trigger a
minor update from Mirek, anyway.]

> Control commands:

Might want a plain run() -- presumably the last command in the script, to
set Golly going until the user hits Stop -- as well as a run-for(t), with
t in milliseconds.  Maybe a run-to(n) to get to generation n, but that'd
just be a convenience.

Instead of run-for() -- will it be possible to use a command like
time.sleep(s) in Python, yielding control to Golly (and/or the operating
system) for s seconds?  Handy for the slideshow.py script you mentioned,
as well as for scripts that are doing open-ended searches of one kind or
another... looking for, I don't know, 1xn patterns with unbounded growth,
or whatever.

I guess maybe then you'd need an asynchronous run(), plus a stop() to get
control back again?  Life32 does things this way -- and the
asynchronicity has been known to cause some slightly sticky situations.

> Editing commands:

'advance(n)' and 'outside(n)' are all very well and good, but with a
'clipboard-advance(n)' function -- along with 'copy(filepath)' -- I could
probably manage to put together a caterpillar.py construction script.  Of
course 'clipboard-advance(n)' could be faked by pasting the clipboard
contents to some out-of-the-way corner of the universe, and then
selecting it and using 'advance(n)' followed by 'cut()' and
'paste(x,y)'... it wouldn't necessarily work to paste directly to the
target location and use 'advance()' there, because the corners of the
bounding box would often chop pieces out of surrounding subpatterns!

The lack of a 'clipboard-advance(n)' equivalent is the big shortcoming of
[un-extended] Xlife structured format.  Xlife allows adding a series of
subpatterns to the same universe, but oscillators are always added to the
universe in the same phase as they're stored in the library files -- you
can't advance them a few ticks before dropping them in.  Sometimes
there's an adequate workaround:  drop the oscillator first, advance the
universe n generations, then populate the rest of the universe...  Xlife
kind of assumes that those two methods are equivalent, and for simple
constructions sometimes they are -- but sometimes they just plain ain't.

>Viewing commands:
>
>   update() -- redraw the current view (most commands will probably 
>                    do this automatically, but some like setcell will
not)

Maybe an autoupdate(bool) to turn off screen redrawing when the script is
going to be doing a whole lot of fiddly stuff that's not worth watching
-- and turn it back on again when it's done?   I seem to recall Life32
Automation has this option.  In some circumstances it might be okay to
have screen updates even for setcell() operations.

---------------------------

Okay.  That's probably a lot more than needs to be worried about at this
stage of the game!  Just wanted to convey my enthusiasm for the
Python-scripting idea -- might have gotten a little carried away there...

Keep the cheer,


Dave Greene

Tom Rokicki wrote:
> But I have to say, this is totally awesome.

I second the motion:  Python seems like a fine choice for a Golly
scripting language.  I also found PLife fairly inspirational, a year or
two back; my only problem with it was that the viewer was fairly basic,
so a PLife script ended up being ... just a kind of structured file
format, really.  And Xlife already had a structured format with a much
simpler syntax, simple enough that other Life-application programmers
might conceivably write a parser for it (where they might be reluctant to
import or reimplement a large part of Python!)

But once you're actually running the GUI of an application as complex as
Golly -- where the point of the script might be to visually display the
creation process, not just to get to the final pattern -- and/or you
might want to programmatically repeat the creation of lots of
subpatterns, or do various calculations or whatever --  then obviously
you need something more complex.  Python appears to be as good a choice
as any, and better than most!

...Will it be possible to define named subpatterns in a Golly script, the
way you can in PLife, and re-use them many times?  Or do you see that as
a series of copy-paste operations in the Golly GUI?  How about
"capturing" a pattern from the Golly universe, giving that a name (like
'pi-heptomino-plus-30-generations') and re-using it as a component of
other patterns?

> Have you thought about making the UI and the commands themselves
> sufficiently 1:1 where we can automatically generate a python script 
> for any given user interaction with golly?

Macro-recorder functionality is indeed a wonderful thing.  Only Xlife and
(I think) David Bell's Life editor currently have anything even vaguely
like this.

Keep the cheer,


Dave Greene

On 09/02/2006, at 12:43 PM, Andrew Trevorrow wrote:

> Apologies if anybody feels I'm foisting Python on Golly as a fait 
> accompli.
> I'm quite willing to scrap all this stuff if anybody can come up with a
> better scripting language, but the more I look at Python the more it
> looks like a perfect match for Golly.

I'm not about to argue against the choice as there are plenty of 
opinions I respect who concur that Python is where it is at, but ...

It appears best practice for a project like this to try to decouple the 
API from the initial target language so that others can add their 
alternatives as inclinations change.

 From the way you have described things, I suspect that will not be too 
big a step from what you are planning anyway.

One thing I envisage wanting to add is identifying and counting 
sub-patterns, so I'd be interested in some way of getting multiple 
(smallish x and y) cells repeatedly without needing to rerender large 
areas into a script's working array variables.


Tony Smith
Complex Systems Researcher
Meme Media
Melbourne, Australia
http://www.meme.com.au/

> The only way I know to "invoke golly" is to start it up. :)
> Wouldn't bgolly be a better candidate for calling from a Python script?

Sure, either way works, but will bgolly also be scriptable?
The real question is, are you tying in before or after the UI?

In some sense, we have to decide what our "picture" is; does
it look like:


           pygolly
                |
UI   ---  hlifeimpls  --- display
                |
             bgolly

Or instead

UI -- pygolly -- hlifeimpls -- display
                          |
                       bgolly

or something different?  I think deciding how
the different parts should interact so to maximize
utility is critical (and difficult).  And just like any
large project, there's probably no one right answer;
each would involve different tradeoffs.

Right now, for instance, the cut/paste/rotate/invert
code is all over UI, where it really belongs in either
hlifeimpls or a layer between UI and hlifeimpls; do you
agree?  Figuring out how to factor that out would be
a great thing to do (and one I've been playing with,
but so far unsuccessfully).

I've nothing against experimental coding, on the other
hand, so putting something together just to play
around is not a bad thing to do---consider them
prototypes.  We can rip them to shreds as needed.

I definitely think this is the future, and Python is not
a bad choice for this; it seems to be relatively
standard for commercial tools to integrate or adopt
Python in this manner.

What's uber cool is we can even expose things that
don't make easy sense in a UI (like hlife "snapshots")
but provide sometimes amazing utility otherwise.
(An hlife snapshot is just a node protected from GC
along with perhaps metadata; it often takes little
space because it shares so much with the other
running generations, but it lets you pop back to it,
or redisplay it, or whatever, instantaneously . . .)

Of course any internals we expose become part of
our API :-)

My stuff will need some cleanup of course; qlife
supports easy separable universes just by separate
allocation, but hlife does not (at least not trivially
because of the huge hash table).  But I could
provide "freeze" and "unfreeze" (or "serialize" and
"unserialize") for hashlife, so we only have a single
huge hashtable but we can still deal with multiple
hash universes if we want.  Or, perhaps we don't
even want to expose this, and just want to use
RLE as the interchange format?

-tom

> We'll have to make sure we impress on everyone that this is experimental; we
> may want to be very careful before committing to anything.

Absolutely, that's why I want comments/suggestions before proceeding.
I suspect the first-draft commands (whatever they turn out to be)
will undergo much evolution once people start writing scripts.
We still have a few beta releases up our sleeves (0.96 to 0.99)
before 1.0 sets things in stone. :)

> Have you thought about making the UI and the commands themselves
> sufficiently 1:1 where we can automatically generate a python script for
> any given user interaction with golly?  So we can replay things, or if
> the user builds a complicated pattern with cut/paste/etc., he can
> save that script rather than just the resulting file?

Nice idea!  Some sort of recording mechanism could be very handy,
not just for saving actions in a script but also for implementing
unlimited undo.  I'll have a better handle on this once the first-draft
commands are working.

> Can it go the other way---can a Python script invoke golly and
> interact with it to get the job done, without the user starting up
> golly?

The only way I know to "invoke golly" is to start it up. :)
Wouldn't bgolly be a better candidate for calling from a Python script?

Andrew

Wow, sounds awesome.

We'll have to make sure we impress on everyone that this is experimental; w=
e
may want to be very careful before committing to anything.

But I have to say, this is totally awesome.

Have you thought about making the UI and the commands themselves
sufficiently 1:1 where we can automatically generate a python script for
any given user interaction with golly?  So we can replay things, or if
the user builds a complicated pattern with cut/paste/etc., he can
save that script rather than just the resulting file?

No, this could be major cool, and I'm totally for it.

Can it go the other way---can a Python script invoke golly and
interact with it to get the job done, without the user starting up
golly?

This is the road to some amazing power . . .

On 2/8/06, Andrew Trevorrow <an...@tr...> wrote:
> After having a closer look at PLife (http://plife.sourceforge.net/) I was
> inspired to add Python scripting support to Golly.  I've managed to get
> a simple, proof-of-concept implementation working on all platforms.
> If you drop a foo.py script onto Golly's window (or select it via the
> "Run Script..." item in the File menu) then Golly will invoke the Python
> interpreter and execute the script.  Here's a simple example:
>
> import golly as g
> g.show("Hello Andy!")   # shows message in Golly's status bar
> g.warn("Seeya later.")  # shows message in Golly's warning dialog
>
> When Python sees g.show it calls an internal Golly routine (golly_show
> in wxscript.cpp).  At the moment I've only implemented show and warn.
> Before I race off and implement other routines I want to get feedback
> and suggestions.  Presumably we need to expose most of Golly's commands
> so they can be automated, and we probably need new routines to help
> with sophisticated pattern construction (as in PLife).  Anyway, here's
> a tentative first draft of Golly's scriptable commands:
>
> File commands:
>
>   new() -- create a new, empty universe (ie. New Pattern)
>   load(filepath) -- open given pattern file
>   save(filepath,format) -- save current pattern in given file
>
> Control commands:
>
>   run(n) -- run current pattern for n gens
>   basestep(n) -- set base step (default is 10 for qlife, 8 for hlife)
>   setstep(exp) -- set step exponent; eg. 1 for 10^1, -1 for smallest dela=
y
>   hash(bool) -- turn hashing option on or off
>   autofit(bool) -- turn auto fit option on or off
>   hyper(bool) -- turn hyperspeed option on or off
>   reset() -- restore starting pattern, scale, step size, etc
>   setrule(rule) -- switch to given rule
>
> Editing commands:
>
>   setcell(x,y,state) -- set given cell to given state
>   getcell(x,y) -- return state of given cell
>   select(x,y,wd,ht) -- select given rectangle
>   all() -- select entire pattern, or maybe just use select()?
>   clear() -- clear selection
>   copy() -- copy selection to clipboard
>   cut() -- copy selection to clipboard then clear it
>   paste(x,y,mode) -- paste clipboard at x,y using mode (or, copy, xor)
>   advance(n) -- advance selection by n gens
>   outside(n) -- advance pattern outside selection by n gens
>   randfill(percent) -- randomly fill selection to given percentage
>   rotate(degrees) -- rotate selection by multiples of +/-90 deg
>   flip(axis) -- flip selection about given horizontal or vertical axis
>
> Viewing commands:
>
>   update() -- redraw the current view (most commands will probably do
>               this automatically, but some like setcell will not)
>   fullscreen(bool) -- turn full screen mode on or off, or maybe
>                       use setoption("fullscreen",true)?
>   fit() -- fit pattern in view
>   fitsel() -- fit selection in view
>   view(x,y) -- put x,y cell in middle of view
>   scale(n) -- set scale; eg. -1 for 2^1:1, 0 for 1:1, 1 for 1:2, etc
>
> Miscellaneous commands:
>
>   show(message) -- show message in status bar
>   warn(message) -- show message in warning dialog
>   help(topic) -- open help window and display given topic
>   info() -- display current pattern info
>   setoption(option,value) -- eg. setoption("toolbar",true)
>
> Comments?  Questions?  Suggestions?
>
> Other ideas...
>
> - Provide a Scripts folder with some useful scripts; eg:
>
>   tutorial.py -- A guided tour through most of Golly's features.
>
>   slideshow.py -- Loads every pattern in the Patterns folder with
>   a brief pause between each (user can hit escape to abort script).
>
>   caterpillar.py -- Builds the caterpillar step by step like an animated
>   movie, runs the final result and reports that, yes, it is indeed a
>   17c/45 spaceship.  I'm not volunteering to write this script. :)
>
> - As well as Run Script, add a Run Recent submenu (like Open Recent),
>   a Show Scripts option (like Show Patterns) and a Script Folder dialog
>   (like Change Folder, which I'll probably rename to Pattern Folder).
>
> Apologies if anybody feels I'm foisting Python on Golly as a fait accompl=
i.
> I'm quite willing to scrap all this stuff if anybody can come up with a
> better scripting language, but the more I look at Python the more it
> looks like a perfect match for Golly.  Python is free, cross-platform,
> well-supported, well-documented, and the language is very powerful but
> quite readable.  It's also easy to install (already comes with Mac OS X).
> The Windows installer was a pleasure to use -- you can get it from
> http://www.python.org/download/.
>
> Note for Tom/Jason or anybody else who wants to build the latest Golly:
> You may need to edit makefile-* and change the PYTHON_* variables
> depending on where you installed Python and its version number.
>
> Andrew
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

After having a closer look at PLife (http://plife.sourceforge.net/) I was
inspired to add Python scripting support to Golly.  I've managed to get
a simple, proof-of-concept implementation working on all platforms.
If you drop a foo.py script onto Golly's window (or select it via the
"Run Script..." item in the File menu) then Golly will invoke the Python
interpreter and execute the script.  Here's a simple example:

import golly as g
g.show("Hello Andy!")   # shows message in Golly's status bar
g.warn("Seeya later.")  # shows message in Golly's warning dialog

When Python sees g.show it calls an internal Golly routine (golly_show
in wxscript.cpp).  At the moment I've only implemented show and warn.
Before I race off and implement other routines I want to get feedback
and suggestions.  Presumably we need to expose most of Golly's commands
so they can be automated, and we probably need new routines to help
with sophisticated pattern construction (as in PLife).  Anyway, here's
a tentative first draft of Golly's scriptable commands:

File commands:

  new() -- create a new, empty universe (ie. New Pattern)
  load(filepath) -- open given pattern file
  save(filepath,format) -- save current pattern in given file

Control commands:

  run(n) -- run current pattern for n gens
  basestep(n) -- set base step (default is 10 for qlife, 8 for hlife)
  setstep(exp) -- set step exponent; eg. 1 for 10^1, -1 for smallest delay
  hash(bool) -- turn hashing option on or off
  autofit(bool) -- turn auto fit option on or off
  hyper(bool) -- turn hyperspeed option on or off
  reset() -- restore starting pattern, scale, step size, etc
  setrule(rule) -- switch to given rule

Editing commands:

  setcell(x,y,state) -- set given cell to given state
  getcell(x,y) -- return state of given cell
  select(x,y,wd,ht) -- select given rectangle
  all() -- select entire pattern, or maybe just use select()?
  clear() -- clear selection
  copy() -- copy selection to clipboard
  cut() -- copy selection to clipboard then clear it
  paste(x,y,mode) -- paste clipboard at x,y using mode (or, copy, xor)
  advance(n) -- advance selection by n gens
  outside(n) -- advance pattern outside selection by n gens
  randfill(percent) -- randomly fill selection to given percentage
  rotate(degrees) -- rotate selection by multiples of +/-90 deg
  flip(axis) -- flip selection about given horizontal or vertical axis

Viewing commands:

  update() -- redraw the current view (most commands will probably do
              this automatically, but some like setcell will not)
  fullscreen(bool) -- turn full screen mode on or off, or maybe
                      use setoption("fullscreen",true)?
  fit() -- fit pattern in view
  fitsel() -- fit selection in view
  view(x,y) -- put x,y cell in middle of view
  scale(n) -- set scale; eg. -1 for 2^1:1, 0 for 1:1, 1 for 1:2, etc

Miscellaneous commands:

  show(message) -- show message in status bar
  warn(message) -- show message in warning dialog
  help(topic) -- open help window and display given topic
  info() -- display current pattern info
  setoption(option,value) -- eg. setoption("toolbar",true)

Comments?  Questions?  Suggestions?

Other ideas...

- Provide a Scripts folder with some useful scripts; eg:

  tutorial.py -- A guided tour through most of Golly's features.

  slideshow.py -- Loads every pattern in the Patterns folder with
  a brief pause between each (user can hit escape to abort script).

  caterpillar.py -- Builds the caterpillar step by step like an animated
  movie, runs the final result and reports that, yes, it is indeed a
  17c/45 spaceship.  I'm not volunteering to write this script. :)

- As well as Run Script, add a Run Recent submenu (like Open Recent),
  a Show Scripts option (like Show Patterns) and a Script Folder dialog
  (like Change Folder, which I'll probably rename to Pattern Folder).

Apologies if anybody feels I'm foisting Python on Golly as a fait accompli.
I'm quite willing to scrap all this stuff if anybody can come up with a
better scripting language, but the more I look at Python the more it
looks like a perfect match for Golly.  Python is free, cross-platform,
well-supported, well-documented, and the language is very powerful but
quite readable.  It's also easy to install (already comes with Mac OS X).
The Windows installer was a pleasure to use -- you can get it from
http://www.python.org/download/.

Note for Tom/Jason or anybody else who wants to build the latest Golly:
You may need to edit makefile-* and change the PYTHON_* variables
depending on where you installed Python and its version number.

Andrew