golly-test Mailing List for Golly

I wrote:

> spacefiller.rle: skip=3D1, fps=3D100
> infinity-hotel0.rle, skip=3D13, fps=3D60
> ...
>
> In the last pass through, I took all this extra stuff out...

I'd still kind of like to include default settings equivalent to 'skip'
and 'fps' in #CXRLE tags at some point... not for the 1.1 release,
presumably, but sometime if and when I can manage to supply code for it
-- if I can get a go-ahead on the basic idea.

Here's a sample proposal:  suppose I work on figuring out how to extend
the key/value pair system to other Golly options, and also add a
preference that says

XRLE pattern preferences overwrite user preferences:
- Never
- Temporarily
- Permanently

(with the default being "temporarily").  The idea is that an XRLE
pattern would be able to override the relevant user settings -- but
only while that particular pattern is loaded.  Opening a new pattern or
moving to a new universe would revert back to the settings in Preference=
s.

This will be a little annoying, because it means maintaining some
current-state information that may conflict with existing user
settings... for example, suppose the XRLE specifies a delay that's
outside the minimum and maximum delay set by the user in Preferences?

But the advantage is that it would be possible to set (for example) the
hashing settings to match the best way to run a particular pattern, or
the non-hashing base size to match Alan's "skip" values, WITHOUT the
user having to set it back again manually afterwards.

-- Okay, y'all can go ahead and tell me I'm crazy now...

Keep the cheer,


Dave

Found some time this week to go through the current pattern collection
and fix some errors in the comments, straighten out the headers and so
forth.  One of the things that came up was a series of non-standard RLE
headers from Alan Hensel's 'bclife' -- they include step and speed
parameters instead of specifying a rule.

These were last discussed on May 21, I think -- Andrew Trevorrow wrote:

> > Any thoughts on the best way to store this kind of pattern
> > metadata -- viewpoints, default speeds, etc.?
> =

> I'd prefer to store such info as special comments in the pattern
> file itself, perhaps as some sort of extended RLE format or a
> new Golly-only format.

[Aha -- this might explain my initial wild hopes for the XRLE format...]=


Anyway, I didn't standardize the RLE headers when checking them in
originally, because it seemed like potentially useful information and I
didn't want to lose it.  There's quite a range of default settings
among the various patterns:

spacefiller.rle: skip=3D1, fps=3D100
infinity-hotel0.rle, skip=3D13, fps=3D60
infinity-hotel1.rle, skip=3D5, fps=3D30
primer.rle, skip=3D17, fps=3D40
unique-high-period.rle, skip=3D1, fps=3D20
traffic-light-hasslers.rle, skip=3D1, fps=3D20
low-period.rle, skip=3D1, fps=3D6
extensible-low-period.rle, skip=3D1, fps=3D6
billiard-table.rle, skip=3D1, fps=3D6
puffer-train.rle, skip=3D21, fps=3D40
pi-fuse-puffer.rle, skip=3D1, fps=3D100
line-puffer.rle, skip=3D29, fps=3D40
spider-rake.rle, skip=3D9, fps=3D40
basic-rakes.rle, skip=3D1, fps=3D20
stargate.rle, skip=3D5, fps=3D20
heisenburp-30.rle, skip=3D1, fps=3D30
orthogonal.rle, skip=3D1, fps=3D10
diagonal.rle, skip=3D1, fps=3D10
corderships.rle, skip=3D1, fps=3D100
oscillator-syntheses.rle, skip=3D1, fps=3D6

In the last pass through, I took all this extra stuff out.  If it's
okay, I'll check in all the edited patterns along about the end of this
weekend -- I actually ended up making trivial standardization changes
to well over half the collection, but there's nothing too exciting. =

The biggest change is to use a different phase of the Galaxy for the
'O' in golly-ticker.rle [with Brice's permission]; since the objections
came up, neither of us could look at the current logo any more without
seeing a dratted swastika.  Arrgh.

I did want to try to fill in a few gaps in the collection, though --
for example, I somehow missed putting in Paul Tooke's Cordership gun. =

If it's okay, and if the official Golly 1.1 doesn't get rolled out
_too_ soon, I was thinking of digging up ten or twenty recent patterns
to fill in, say, the folders with fewer than ten patterns in them. =

Puffers, rakes, and spaceships still seem seriously underrepresented --
mostly just due to the random subset of pattern collections that I had
managed to sort through by the 1.0 release date.

The current collection also has a serious skew toward my general area
of semi-expertise [which is... um... Rube Goldberg devices?].  Not that
I'm apologizing or anything -- Rube Goldberg devices run so very nicely
in Golly -- but nominations for additions to other categories would be
gratefully accepted.  Otherwise I'll probably just pick some
rakes/puffers/spaceships out of a hat, more or less -- too many good
possibilities to choose from.

-- Also still planning on a fresh draft of the metafier script.  And
unless someone objects I'll also throw in a version of the
fuse-watcher.py script from a while back [last posted May 18th] to show
a pattern being tracked by a moving viewport.

Keep the cheer,


Dave Greene

>> And "All files (*.*)" and/or "All CA files" (.l, .lif, etc.)
>> would be nice...
> =

> Those options don't make sense in the Save dialog.  The pop-up menu
> is for specifying the file format (if no known extension is
> supplied), not the file types that are visible.

Yeah... point taken for "All CA files", anyway -- and yet... changing
the pop-up setting _does_ alter the file types that are visible -- and
sometimes it's handy to be able to see what's there.  In Windows, at
least, since it's a standard dialog, you can do all sorts of useful
maintenance tasks in the Save window, such as right-clicking in the
window to rename files or create a folder to put your new pattern in. =

So an "All Files (*.*)" option would allow you to rename an existing
file to ".bak", for example, and then put your new pattern in the old
file location.

Here I'm basically describing the way I use my text editor, TextPad,
which has an "All Files" option in the Save window.  Obviously if "All
Files" is chosen, no extension is appended automatically, so you might
just get a bare filename -- in my book that's OK too.  In MCell the
"All Files" filter is in the pattern folder display, not the Save
dialog, but there's an easy way to rename, delete, or edit the text of
files from there [right-click menu -- hmm, cross-platform trouble again.=
]
 =

>> ... it would also be wonderful to be able to paste patterns with
>> comments into a new universe and save them with the comments
>> intact..
>> ...
> Nice idea -- feel free to implement it. :)

Arrr, I knew I was steering into stormy waters with that one [if only
someone had reminded me when I was writing the original email that it
was International Talk Like a Pirate Day...]  But I suppose it might
not be a bad place to start playing around with Golly code in (what I
think of as) the less shark-infested territory.

So -- okay, as soon as I'm done fiddling around with 'metafier' and the
other pattern files, I'll see whether I can figure out the
wxWidgets/Golly/clipboard interface, enough to get that little trick to
work.  That, along with maybe putting keyboard shortcuts into
GollyPrefs, ought to be about my speed...

Mind you, giving me the go-ahead on this is a first step down a
slippery slope: notice that a pattern-with-comments that is copied and
pasted into a new universe, and then saved, is presumably not going to
be overwriting an existing file.  So that sets a dangerous precedent
for carrying comments over into new files -- which I do think that
Golly ought to do anyway, especially as soon as the Pattern Info window
starts being editable.

Just for comparison:  MCell has an editable comments window, and always
carries the comments over when new versions are saved (though actually
it also brings them up in the Save dialog itself and allows changes at
that point.)  The big annoyance with MCell is that leading #C comments
are instantly converted to trailing #C-less comments with every save. =

So, since the leading-#C format is generally more readable and better
suited to emailing, I am forever moving comments back to the tops of
files at the last minute and re-adding the #C prefix, by hand or with a
fixer-upper utility.  I think there's a simple solution to this problem
for Golly, though, relying on the fact that Golly _doesn't_ strip #C
prefixes (or anything else) before displaying comments.

Anyway, apparently I've gotten familiar enough MCell's and Life32's
comment handling that I find Golly's comment-amnesia to be fairly
mysterious and confusing.  So I'd love to work on that.  Think it might
be possible to make the Pattern Info window non-modal and dockable? =

(Oops -- getting myself in deeper trouble, must stop...)

>> I'd suggest that, just as the Gen attribute is omitted if it's zero,
>> the Pos attribute (and the entire #CXRLE line) should be left out
>> if there's no useful information in it.
> =

> Yeh, I thought about this, but I don't think it hurts to have a
> tiny bit of redundant info.  It might actually be useful at some
> point to know that a file was saved in XRLE format.

Hmm.   #CXRLE Pos=3D0,0 might as well just be plain #CXRLE, no?  Not tha=
t
I like that any better, being a badly biased big believer in avoiding
vertical sprawl.  Short mostly-blank lines only help to push the real
information off the screen, so this would just be another header
problem I'd have to correct manually all the time. Especially for RLE
interspersed with text, as in a Life List email -- it's good to get
through the machine-readable part of the RLE in as few lines as
possible, so the thread of the surrounding text is not lost.

=2E..Oddly enough, I don't really think of XRLE as an alternate file
format -- it's just standard RLE with some metadata included in the
comments.  So if the XRLE toggle really just means "Save Golly
metadata"... then does it make sense to write out a flag for metadata
if there really isn't any?

To look at it another way -- aha! -- I claim that *all existing RLE* is
in fact extended RLE that just doesn't happen to have any extra
parameters, and that adding distinction-without-a-difference #CXRLE
marks will only get us in trouble somehow.  Just like the Star-Bellied
Sneeches.

-- I'd better rest my case (such as it is) right there, with the
disclaimer that a leading #CXRLE Pos=3D0,0 doesn't bother me all _that_
much, in spite of how many words I've accidentally written about it. =

Mostly I guess I just enjoy following reasonable premises to their
unreasonable conclusions.

[Luckily we're not dealing with multichunk RLE yet, because I'd be
terribly tempted to say the same thing about that: standard RLE ought
to be the n=3D1 case for n-chunk RLE -- this would require doing without=

an initial "Chunks=3Dtrue" flag, but luckily that doesn't look _too_
difficult.]

Keep the cheer,


Dave

> One way (perhaps the most common way?) to specify the file format
> is to type a file name with a known extension.  That is, if you
> enter "foo.rle" then the format will be RLE, regardless of what
> the format menu currently displays.

Very interesting!  I hadn't given enough thought to how this would play
out cross-platform.  In Microsoft-land (where I've been living for far
too long now) the extension can certainly trump the format, but only to
a degree:  it's quite common to have multiple file types in a Save
drop-down list, all of which have the same extension -- as in ".xls" or
".doc" (where you can save several different versions of Excel or Word
files from the latest version of MSOffice).

I think of RLE vs. XRLE being a perfect example of this
different-version-same-extension idea.  In the MSOffice case, if the
file type is not completely determined by the extension, then the
default would be based either on the format parameter setting or on the
current version of Excel or Word.  In Golly, if the user types in
".rle" as a file extension, the "Save Extended RLE" setting could
presumably determine the file type.

> In the end, it may not be a big problem.  I suspect most people
> will simply keep "Save Extended RLE" ticked and never change it.
> That's what I plan to do!  :)

True enough -- as long as there are only two metadata options and they
both fit on one line, most of the problems I'm imagining are kind of a
storm in a teacup.

However, I'm definitely still hoping to convince you and the rest of
the Golly Gang (or else un-convince myself!) that the #CXRLE key/value
system is a fairly good way of handling a lot of other optional
settings for patterns, such as the hashing/hyperspeed parameters, which
I otherwise find myself constantly fiddling around with.  Maybe you
wouldn't want to write all the possible parameters out to every XRLE
pattern by default, but it would be nice to be able to read them in.

Here's why, with apologies in advance (I think I'm rehashing a previous
posting again):  eventually I'd like to be able include suggestions for
Golly GUI settings in the metadata of a large fraction of the sample
patterns.  For example, there's no point in running anything in the
Oscillators folder with hashing turned on -- well, maybe for fun, to
see a pattern running backward or something like that.  The exception
is the huge-prime-period oscillator, which there's not much point in
running *except* in hash mode.

The others seem to be about right at a tenth-of-a-second delay --
except for the (soon to be renamed to) glider-stream-crystal.rle, which
is probably better off at 10^0 or 10^1... and queen-bee-turn.rle, where
the sweet spot seems to be closer to a twentieth of a second.

[Speaking of which, the current default minimum-delay setting of 250
milliseconds seems a bit too high to me -- I end up with a sudden jump
in speed when I cross the boundary from the smallest possible delay to
regular tick-by-tick simulation.  Something like 10 milliseconds seems
to substantially reduce the whiplash effect -- and it would also allow
me to eventually include good simulation-speed suggestions in for
various patterns, without violating the default bounds.]

-- I guess my idea is that people who are looking through the pattern
collection for the first time won't necessarily have any idea of what
they're supposed to be looking for.  Random example: you can get away
with accidentally having hyperspeed turned on when you run
elbow-ladders.rle, but you'll probably want auto-fit on too or you'll
miss the interesting part.  If you then go on to look at
vacuum-cleaner.rle with hyperspeed and autofit on, though, you'll
almost certainly miss the point of the pattern and end up watching a
twitchy diagonal line.  The vacuum cleaner gun probably ought to run at
a minimum-delay step (to keep it from going too fast on a higher-end
CPU to see what's happening).  And maybe it should stop automatically
after generation 3000 or so.

Then there are patterns where it would be nice to suggest a particular
viewport to watch, or a choice of viewports, other than the bounds of
the pattern.  Often the location or size should really be a function of
time, though -- so I guess I'd best drop the whole viewport topic until
I've done enough trial coding to produce an irresistible demo.

You mentioned custom Python scripts, which are certainly one way of
handling this kind of thing [even viewports, sort of, except I'm
stymied by the way dokey() ignores some of the best keyboard
shortcuts.]  I don't know about doubling the number of files in
Patterns, though -- a .py for every .rle seems like a lot of clutter. =

And they'd be such titchy little .py files, too, not really worth the
extra space in the Files list.  But of course replacing all the pattern
files with .py files would make it annoying to extract the RLE to run
elsewhere.

Maybe I should think about setting up a parallel directory under
Scripts instead, with a script pointing back to each Patterns/*.rle
file:  "go to Patterns if you like your Life files raw and
unadulterated, or try Scripts/Patterns to add gourmet seasoning!"...
Other suggestions?

Keep the cheer,


Dave

> 1a)  Side note #1: the Pattern Info window is selectable but read-only.
>  Always has been, I think.  Might editing be possible in this window at
> some point?

Yep, it's in the TODO file (in the suggestions by Bill Gosper).

> 2)  If I immediately choose "Save Pattern" -- let's say on breeder.lif
> -- with the "Extended RLE" option checked by default, I get the
> standard Save dialog with a choice of Extended RLE or macrocell
> formats.

Note that you only get the macrocell option if hashing is on.
Just wanted to clarify that in case it's not obvious.

> Might be nice to offer standard RLE here as a third option?

I was wondering when someone would suggest that. :)
My original implementation actually did so; ie. offered the choice
of RLE and XRLE (and mc if hashing).  But there is a bit of a problem.
One way (perhaps the most common way?) to specify the file format
is to type a file name with a known extension.  That is, if you
enter "foo.rle" then the format will be RLE, regardless of what
the format menu currently displays.

So, if we have both RLE and XRLE available in the Save dialog then
we really need a new extension so that people can choose the XRLE
format by entering a name like "foo.xrle".  But I'd prefer to avoid
creating a new extension -- that opens up new cans of worms!

The best solution would be to have the "Save Extended RLE" option
as a new check box in the Save dialog, but I dunno how to do that
in wxWidgets.  Until I find a way, the next best option is a flag
item in the File menu (unless someone can come up with a better idea).

In the end, it may not be a big problem.  I suspect most people
will simply keep "Save Extended RLE" ticked and never change it.
That's what I plan to do!  :)

> And "All files (*.*)" and/or "All CA files" (.l, .lif, etc.) would be
> nice...

Those options don't make sense in the Save dialog.  The pop-up menu
is for specifying the file format (if no known extension is supplied),
not the file types that are visible.

> 2a) Side note #2:  the breeder pattern loads with (0,0) in the middle
> instead of the northwest corner -- as it should, because it's a Life
> 1.05 pattern and the positions are hard-coded.  The same is true for
> acorn.lif, rabbits.lif, and persian-rugs.lif.
> 
> I think that, just for consistency's sake, I should move those patterns
> to put (0,0) in the upper left corner, before the final 1.1 release. 
> Agreed?

No objections from me.

> 3) If I click on the Pattern Information button again immediately after
> saving, I find that the comments are gone, and in their place there's a
> single line:  #CXRLE Pos=-374,-168 .  The original comments have been lost.

Comments are preserved only when you overwrite an existing file.
If you load breeder.lif and save a new file called breeder.rle then
the comments in breeder.lif are not copied over.  I guess you could
argue they should be copied, but it sounds potentially confusing to me,
not to mention rather messy to implement given that different formats
use different commenting conventions.

> -- While I'm wishing for horses, it would also be wonderful to be able
> to paste patterns with comments into a new universe and save them with
> the comments intact.  I don't know of any Life editors that can
> currently manage this -- which means that after I've copied and pasted
> and saved something from the Life List archives, let's say, I always
> have to open the saved file, select everything, paste again, and
> re-save it, to get the comments to travel with the pattern properly...

Nice idea -- feel free to implement it. :)

> 4) Even if I load a standard RLE pattern, or if I move a pattern
> manually to put (0,0) in the northwest corner, I still get an
> extended-RLE header line:  #CXRLE Pos=0,0 .  I'd suggest that, just as
> the Gen attribute is omitted if it's zero, the Pos attribute (and the
> entire #CXRLE line) should be left out if there's no useful information
> in it.

Yeh, I thought about this, but I don't think it hurts to have a tiny
bit of redundant info.  It might actually be useful at some point to
know that a file was saved in XRLE format.

Thanks for the prompt feedback Dave!

Andrew

> The Golly 1.1 beta versions are now available: ...

I tried out the Windows package and didn't find anything new and
troubling, at least not immediately.  I see the 1.1 updates are all
nicely described in the change log, and the documentation looks great
for the new XRLE behavior in the save() and store() and setoption()
scripting commands.

Haven't double-checked all of that yet, but it looks like exactly what
I need to simplify the latest version of metafier.py (where the ON and
OFF cells are saved to disk after being generated the first time, thus
avoiding the CellCenter[3680] performance hit in later runs).  So I'll
try to get a new metafier.py fixed up and checked in soon.

I did trip over some old existing problems with Golly's
comment-handling, which are made a little bit more obvious by the new
extended-RLE functionality.  Possibly 1.1 might be a good time to
address these (?).  Here's what I found:

1)  Opening one of the commented patterns in the pattern collection and
clicking the Pattern Information button will bring up a nice big
Pattern Info window with the comments in it.  So far so good.

1a)  Side note #1: the Pattern Info window is selectable but read-only.
 Always has been, I think.  Might editing be possible in this window at
some point?  Though I admit there's no reason to allow this at the
moment, because of #3 below.

-----------

2)  If I immediately choose "Save Pattern" -- let's say on breeder.lif
-- with the "Extended RLE" option checked by default, I get the
standard Save dialog with a choice of Extended RLE or macrocell
formats.  Might be nice to offer standard RLE here as a third option?
And "All files (*.*)" and/or "All CA files" (.l, .lif, etc.) would be
nice, so that I could see if there's already a "breeder.lif" in the
current directory.

Also, I get a blank for a filename, rather than a default of
"breeder.lif" or "breeder.rle".  The default location is the current
Windows directory, rather than the location of the original pattern
file [which I think is a good idea -- just documenting all the facts.]

2a) Side note #2:  the breeder pattern loads with (0,0) in the middle
instead of the northwest corner -- as it should, because it's a Life
1.05 pattern and the positions are hard-coded.  The same is true for
acorn.lif, rabbits.lif, and persian-rugs.lif.

I think that, just for consistency's sake, I should move those patterns
to put (0,0) in the upper left corner, before the final 1.1 release. =

Agreed?  I've found a bunch of other trivial maintenance tasks that
need doing in various pattern comments, anyway, now that I've looked at
them again.  -- Also, breeder.lif would be trivial to rebuild as a
Python script as well, since an Xlife version is already available.

-----------

3) If I click on the Pattern Information button again immediately after
saving, I find that the comments are gone, and in their place there's a
single line:  #CXRLE Pos=3D-374,-168 .  The original comments have been =
lost.

Is there any way to avoid losing information like this?  I seem to
remember there's some trouble with writing out comments, except to
existing files.  Is it a matter of not knowing where to put comment
lines, if some of them came from the beginning of a file and some from
the end (as in jagged2.rle, for example)?

It might take some fiddling around to avoid ugliness like invalid
comment lines or #C#C prefixes.  But I think it might be worth taking
the trouble to write out any #C-prefixed comment lines to the top of
the file, and then append any other comment lines at the bottom... with
special handling for #CXRLE lines, of course... Yes, I guess it's a can
of worms; may be another good candidate area for me to try to
contribute some code to, at some point.

[When I finally catch up with the ever-receding spare time on my
schedule, that is.  After I win the lottery, maybe?  Too bad I don't
actually buy lottery tickets...]

-- While I'm wishing for horses, it would also be wonderful to be able
to paste patterns with comments into a new universe and save them with
the comments intact.  I don't know of any Life editors that can
currently manage this -- which means that after I've copied and pasted
and saved something from the Life List archives, let's say, I always
have to open the saved file, select everything, paste again, and
re-save it, to get the comments to travel with the pattern properly...

-----------

4) Even if I load a standard RLE pattern, or if I move a pattern
manually to put (0,0) in the northwest corner, I still get an
extended-RLE header line:  #CXRLE Pos=3D0,0 .  I'd suggest that, just as=

the Gen attribute is omitted if it's zero, the Pos attribute (and the
entire #CXRLE line) should be left out if there's no useful information
in it.

-----------

That seems like more than enough beta feedback for now (!).  Will see
if anything else shows up while I'm revising metafier.py...

Keep the cheer,


Dave Greene

The Golly 1.1 beta versions are now available:

ftp://ftp.trevorrow.com/beta/golly-1.1-win.zip
ftp://ftp.trevorrow.com/beta/golly-1.1-mac.zip
ftp://ftp.trevorrow.com/beta/golly-1.1-gtk.tar.gz
ftp://ftp.trevorrow.com/beta/golly-1.1-x11.tar.gz

Let me know if there are any problems.  I'll wait a few days
before announcing them in LifeCA.

Andrew

> Sounds good to me.  When I looked ahead at your idea of eventually
> extending the #CXRLE format to include more key/value pairs, though --
> thinking for example about simulation speed, zoom level, viewport,
> viewport vector, default views, hash settings, escaped-glider
> auto-erase setting, or you name it -- I got the feeling that different
>  people would either very much want to save, or very much not want to
> save, different subsets of those settings automatically with their
> patterns.  Which got me thinking along the lines of the ugly "Save
> Special..." option.

Maybe that will be necessary eventually, but I'm hoping it won't be.
I'd argue that most of the examples listed above are best implemented
by writing custom Python scripts.  I think we should tread carefully
and only add a new XRLE key when there is a clear advantage and the
vast majority of users will want it.

If it turns out we do need to allow users to specify which keys they
want to be saved it won't be that hard to tack on.  The Prefs dialog
could have a new XRLE tab containing lots of check boxes.  The current
"Use Extended RLE" master switch could remain in the File menu.

> Please!  I have written workarounds for the pattern-centering behavior
> into various scripts, which I would be only too pleased to get rid of.

I've made that change.  Just gotta write some docs, so hopefully I can
build the 1.1 beta versions and put them on my ftp site tomorrow.

PS. I've added metafier.py to the Scripts folder.  It's essentially
your metafier-struct.py but renamed and with one or two simple changes.
You might want to update it to your latest version.

Andrew

> Hmm, I had been planning to always save as XRLE, but you're right;
> probably best to provide a "Use extended RLE" option.  The ideal
> place would be a check box in the Save dialog but I don't know how
> to add that for all platforms (I only know how to do it on the Mac). =

> Next best place would be either a check box in Prefs > File, or a
> tickable item in the File menu.  Latter is probably more convenient,
> just under the Save Pattern item.  I think it should be ticked
> initially.

Sounds good to me.  When I looked ahead at your idea of eventually
extending the #CXRLE format to include more key/value pairs, though --
thinking for example about simulation speed, zoom level, viewport,
viewport vector, default views, hash settings, escaped-glider
auto-erase setting, or you name it -- I got the feeling that different
 people would either very much want to save, or very much not want to
save, different subsets of those settings automatically with their
patterns.  Which got me thinking along the lines of the ugly "Save
Special..." option.

If saving as XRLE doesn't bring up a checkbox list of parameters, maybe
it could just decide by looking in the GollyPrefs file... which could
default to saving everything, but would also provide a way for someone
to dodge that if it got too annoying.  Seems like it might be a good
idea to make the key/value handling as general as possible from the
start, anyway, partly to handle other eventual hiccups like the
line-length problem.

Once people get the XRLE defaults set up the way they like them, they
might not have to fiddle them so much after that -- and it might still
help minimize the rolling of eyes and shaking of fists when various
"temporary" changes to XRLE-recorded parameters accidentally end up
being sticky.

-- Okay, sorry, that was a long two cents' worth... don't mean to beat
a dead horse, but I hadn't thought about the GollyPrefs option before.
 I spend a significant amount of time stripping extra junk out of MCell
RLE headers to get them into the form I need for particular projects. =

Luckily MCell has that handy "View/Edit this file" option, so it's not
_too_ bad; but maybe that's why the all-or-nothing approach sounds like
trouble brewing to me.

Come to think of it, though, I can presumably write Python scripts to
standardize my XRLE headers, if it comes to that.  Python saves the day
again!

[If you think _that_ sounds like an awkward misuse of the scripting
system, wait until you see the mess of scripts I've been concocting to
register patterns in terms of subpatterns...]

> ... I was going to ask if people would mind if I change the way
> Golly loads normal RLE files.  I only center the pattern around
> 0,0 because that's what Life32/MCell/LifeLab do, but on reflection
> it makes far more sense to put the top left corner at 0,0.

Please!  I have written workarounds for the pattern-centering behavior
into various scripts, which I would be only too pleased to get rid of.

Keep the cheer,


Dave Greene

> I'm sure you know from previous LifeCA experience that somebody can
> probably be found to disagree strongly with _any_ file-format
> suggestion...

Yeh, that's why I'm hesitant about mentioning it in LifeCA. :)
As you say, it might be better to make the beta release available
and then announce it for people to try out.  I'll mull over this
a bit more.

> I suppose this does bring up a question, though:  in some cases I want
> to remember the precise location of a pattern or the number of
> generations it's been run -- but in many other cases I *don't*.  If
> I've run an oscillator a few cycles after optimizing its casing, to
> make sure it's still OK, I'd really like Golly to conveniently forget
> about whatever time tick it's gotten to.

Hmm, I had been planning to always save as XRLE, but you're right;
probably best to provide a "Use extended RLE" option.  The ideal place
would be a check box in the Save dialog but I don't know how to add
that for all platforms (I only know how to do it on the Mac).  Next best
place would be either a check box in Prefs > File, or a tickable item
in the File menu.  Latter is probably more convenient, just under the
Save Pattern item.  I think it should be ticked initially.

> And if I've loaded a pattern from a locationless RLE file, I probably
> don't want Golly to peg the upper left-hand corner at (-123, -45) or
> wherever it happens to have ended up, either.  Life32 does that [saves
> to (-width/2, -height/2) in Life 1.05 mode -- even if you've loaded a
> #P 0 0 pattern, as I recall] and it's a little ugly... 

Agreed!  In fact I was going to ask if people would mind if I change
the way Golly loads normal RLE files.  I only center the pattern around
0,0 because that's what Life32/MCell/LifeLab do, but on reflection
it makes far more sense to put the top left corner at 0,0.  The only
potential problem would be if people have written Python scripts that
somehow rely on 0,0 being in the middle, but that seems highly unlikely
(and trivial to fix).  If nobody objects I'll make that change.

> So is there (going to be) a way to set some kind of preference, either
> globally or while saving a particular pattern, specifying which pieces
> of metadata should be written to the XRLE?  I could imagine a column of
> checkboxes in the Save dialog, one for each parameter, with default
> states set in the Preferences somewhere.

Yuk -- I don't want to make each piece of metadata optional.  All or
nothing is much simpler to understand (and implement!).

> Other comments, ranging from trivial to minor:  I'd be happier with
> 
> #C XRLE key=value key=value
> 
> with a space after the #C, if that can be made a valid option -- though
> obviously the #CXRLE form should also be legal.

Not so keen on that idea either.  I'd prefer to keep the parsing code
as simple as possible.  Note that the #CXRLE line(s) would all be
at the start of the file, so they shouldn't really interfere with
the readability of any other comment lines.

> If Golly saves the initial state somewhere anyway, to enable the Reset
> option... maybe eventually it will make sense to allow the initial
> state to be saved out -- on request -- to the RLE, as a separate #CXRLE
> Gen=0 layer.  The Gen=0 pattern is usually relatively compact, right? 
> So it might be worth having the option to record it as part of the
> pattern (?).

Yes, this sort of thing would be handy.  In fact I have changed Golly
so that it saves the starting pattern in a file -- RLE if not hashing
or macrocell if hashing -- rather than saving it in memory.  The main
reason for this was speed (mc files are very quick to write), but it
will make it easier to support ideas like "display the starting pattern
in a separate layer", if/when we ever add multi-layer support.

> Offhand I don't know of any Life players that would object to another
> "#CXRLE Gen=0" line after the exclamation point, with another RLE block
> after that.  ...

At the moment it would cause a problem because Golly treats everything
after the first "!" as a comment.  But that would be easy to get
around by having something like "#CXRLE Layers=true" in the header
lines so that Golly knows to look for and parse multiple layers.

> Speaking of multiple layers -- and this has come up before, but I hope
> no one will mind too much if I mention it again in this context --
> another thing that is painfully missing from the current RLE format is
> a way to specify isolated subpatterns as separate chunks of RLE,
> analogous to multiple #P sections in Life 1.05 format.  Koenig's
> extended RLE format allows this, too, but the intention is often to
> superimpose different generations of the same pattern for display
> purposes... so OR-ing the layers together to produce a "complete"
> pattern is not always a good idea.
> 
> -- If it so happens that there's unanimous support (or
> lack-of-objection) for multi-chunk support as an XRLE feature, I'd be
> happy to try to contribute parser code to support additional
> #CXRLE-headed RLE chunks after the first exclamation point.

I'd be happy to see multi-chunk support, but it might be best to
wait and see how people respond to the simple XRLE stuff first.
I'll try to get the beta release out soon (might not be until
next week as I may be away for most of this week).

> One more trivia question:  should the #CXRLE line(s) come first, before
> the comments, or after them, or would they be valid even in the middle
> of a comment block?

I think they should always come first.  This makes it simpler to ignore
old #CXRLE line(s) when overwriting an existing XRLE file.
In a multi-chunk file there could also be #CXRLE line(s) at the start
of each chunk.  So the general structure would be like this:

#CXRLE Chunks=true Pos=0,0 key=value ...
#CXRLE key=value ...
#C blah blah
#C ...
x = 1000, y = 2000, rule = ...
obob$obob$obo
...!
#CXRLE Pos=123,456 ...
bobobobbo
...!

Andrew

> Sounds great to me!  You might bounce the above email off
> Bontes, the Life list, and Hensel, at the least, to see what
> they say.

Golly, yes!  This will help get rid of an inelegant hack in 'metafier'
and other scripts (where I want to save a pattern out as RLE and re-use
it later -- but the position information gets lost, so I have to fiddle
around to get it back again.)

I'm sure you know from previous LifeCA experience that somebody can
probably be found to disagree strongly with _any_ file-format
suggestion... but we really do need an RLE specification that knows
about position.  So I'd say you should announce your change as a fait
accompli... and then see if any actual alternative suggestions crop up
that are any better!

I suppose this does bring up a question, though:  in some cases I want
to remember the precise location of a pattern or the number of
generations it's been run -- but in many other cases I *don't*.  If
I've run an oscillator a few cycles after optimizing its casing, to
make sure it's still OK, I'd really like Golly to conveniently forget
about whatever time tick it's gotten to.

And if I've loaded a pattern from a locationless RLE file, I probably
don't want Golly to peg the upper left-hand corner at (-123, -45) or
wherever it happens to have ended up, either.  Life32 does that [saves
to (-width/2, -height/2) in Life 1.05 mode -- even if you've loaded a
#P 0 0 pattern, as I recall] and it's a little ugly... making the
header longer by perpetuating garbage numbers as if they were informatio=
n.

So is there (going to be) a way to set some kind of preference, either
globally or while saving a particular pattern, specifying which pieces
of metadata should be written to the XRLE?  I could imagine a column of
checkboxes in the Save dialog, one for each parameter, with default
states set in the Preferences somewhere.

-- And yes, I'm aware that I may well be volunteering to try to write
the code for this myself, and/or that it would probably be painful to
muck around with standard Save dialogs on the various platforms.  So
maybe the column of checkboxes in Preferences would be good enough,
possibly with an extra option to display them after each Save dialog in
a 'Save Options...' dialog box.  Or a "Save Special" menu option, perhap=
s?

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

Other comments, ranging from trivial to minor:  I'd be happier with

#C XRLE key=3Dvalue key=3Dvalue

with a space after the #C, if that can be made a valid option -- though
obviously the #CXRLE form should also be legal.  Just never liked the
looks of comment lines that start right after the C:  when I'm Clooking
at the Cactual text files, the C tags keep getting mixed Cup with the
Cwords.  So I think the marker should be clearly "XRLE", not "CXRLE". =

(But obviously not a big deal either way.)

If Golly saves the initial state somewhere anyway, to enable the Reset
option... maybe eventually it will make sense to allow the initial
state to be saved out -- on request -- to the RLE, as a separate #CXRLE
Gen=3D0 layer.  The Gen=3D0 pattern is usually relatively compact, right=
? =

So it might be worth having the option to record it as part of the
pattern (?).

Offhand I don't know of any Life players that would object to another
"#CXRLE Gen=3D0" line after the exclamation point, with another RLE bloc=
k
after that.  Koenig's extended RLE format does that... but it does
relative positioning using two parameters -- h and v -- instead of one,
and these are added to the RLE header itself instead of a comment line
preceding it.

So I think I do like the comment-line method better, because it can be
safely extended without breaking existing RLE-reading code... that is,
unless you end up with a parameter that takes up more than ~60
characters all by itself.  (MCell, for example, is unhappy with overly
long comment lines.)  Then maybe you'd want some kind of
line-continuation character (ugh).

Speaking of multiple layers -- and this has come up before, but I hope
no one will mind too much if I mention it again in this context --
another thing that is painfully missing from the current RLE format is
a way to specify isolated subpatterns as separate chunks of RLE,
analogous to multiple #P sections in Life 1.05 format.  Koenig's
extended RLE format allows this, too, but the intention is often to
superimpose different generations of the same pattern for display
purposes... so OR-ing the layers together to produce a "complete"
pattern is not always a good idea.

-- If it so happens that there's unanimous support (or
lack-of-objection) for multi-chunk support as an XRLE feature, I'd be
happy to try to contribute parser code to support additional
#CXRLE-headed RLE chunks after the first exclamation point.

[The time that I hoped to have for Golly programming this summer
unfortunately never materialized, but this particular thing would be
worth losing some sleep over.  By way of comparison: I'd also like to
define optional parameters for the view area, simulation speed, and
hash settings, so as to make the pattern collection nicer to look at
and run slide-shows of -- and a viewport vector, so that Golly can
automatically track a moving pattern! -- but those can all wait...]

One more trivia question:  should the #CXRLE line(s) come first, before
the comments, or after them, or would they be valid even in the middle
of a comment block?

Keep the cheer,


Dave Greene

Sounds great to me!  You might bounce the above email off
Bontes, the Life list, and Hensel, at the least, to see what they
say.

On 9/12/06, Andrew Trevorrow <an...@tr...> wrote:
> There are a couple of annoying limitations with the current RLE format:
>
> 1. If you create a pattern and save it as RLE, then after loading the
> file the pattern is no longer in its original position.  (Note that
> the macrocell format doesn't have this problem.)
>
> 2. Also, as Bill Gosper pointed out recently in LifeCA, it would be
> handy to save and restore the generation count.
>
> So I think it's time for Golly to save patterns in extended RLE format,
> or XRLE for short.  Information such as pattern position and gen count
> can be stored in a special comment line at the start of the file.
> For example:
>
>   #CXRLE Pos=10,20 Gen=123
>   x = ..., y = ... etc
>
> When Golly reads such a file it would set the top left corner of the
> pattern's bounding box to the given x,y position and also set the
> generation count to the given number.
>
> Some more notes on XRLE:
>
> - The XRLE indicator is prefixed by #C so other apps like Life32
>   and MCell will ignore the line and read the RLE data correctly.
>
> - The XRLE format is easy to extend in the future by adding new
>   key=value info.
>
> - To avoid the #CXRLE line becoming too long, multiple such lines
>   are allowed.  The above example could also be written out as:
>
>   #CXRLE Pos=10,20
>   #CXRLE Gen=123
>
> To store the current generation count (if > 0) in a macrocell file
> we simply need to add a line like "#G 123" to the header info.
> When Golly loads a RLE/macrocell file that sets the gen count,
> the Reset command can only go back to that gen count.
>
> I've implemented the above ideas in my local version of Golly and
> everything seems to work very nicely.  If there are no objections,
> I'll commit the changes and build 1.1 beta releases so people can
> test things out.
>
> Andrew
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

There are a couple of annoying limitations with the current RLE format:

1. If you create a pattern and save it as RLE, then after loading the
file the pattern is no longer in its original position.  (Note that
the macrocell format doesn't have this problem.)

2. Also, as Bill Gosper pointed out recently in LifeCA, it would be
handy to save and restore the generation count.

So I think it's time for Golly to save patterns in extended RLE format,
or XRLE for short.  Information such as pattern position and gen count
can be stored in a special comment line at the start of the file.
For example:

  #CXRLE Pos=10,20 Gen=123
  x = ..., y = ... etc

When Golly reads such a file it would set the top left corner of the
pattern's bounding box to the given x,y position and also set the
generation count to the given number.

Some more notes on XRLE:

- The XRLE indicator is prefixed by #C so other apps like Life32
  and MCell will ignore the line and read the RLE data correctly.

- The XRLE format is easy to extend in the future by adding new
  key=value info.

- To avoid the #CXRLE line becoming too long, multiple such lines
  are allowed.  The above example could also be written out as:

  #CXRLE Pos=10,20
  #CXRLE Gen=123

To store the current generation count (if > 0) in a macrocell file
we simply need to add a line like "#G 123" to the header info.
When Golly loads a RLE/macrocell file that sets the gen count,
the Reset command can only go back to that gen count.

I've implemented the above ideas in my local version of Golly and
everything seems to work very nicely.  If there are no objections,
I'll commit the changes and build 1.1 beta releases so people can
test things out.

Andrew