golly-test Mailing List for Golly

Hmm, I forgot to add the 'h' to that second link:

   http://calcyman.awardspace.co.uk/life-massive/phi.mc


-- Dave

>> It's the pi.mc link that not working in my GMail on Firefox.
> Oh, sorry, I think GMail is interpreting it as a link when it is not.

Here's a working link in case it's useful to anyone --

   http://calcyman.awardspace.co.uk/life-massive/pi.mc

Nothing much happens when you run the pattern, though, for the first
15 billion generations or so.  It's maybe somewhat interesting to
switch to the LifeHistory rule and run it relatively slowly to begin
with, to see how the computation is bouncing around in the reflector
arrays.

But it's hard to read the output in LifeHistory, so it's probably
better to restart the pattern in regular Life and push the step size
right up to 2^27 (8^9) or so.  At 250 billion ticks you'll have
"3.14", and by the time you get to 2^44 ticks (~1.75e+13) you'll have
125 digits.

There was also a phi calculator with the same diagonal digit printer,
which runs much faster:

   http://calcyman.awardspace.co.uk/life-massive/pi.mc

I'm still amazed that Golly can handle all of these huge patterns as
well as it does.  The new Gemini spaceship is a bit of a challenge,
though, even at the 2^12 to 2^15 step size that seems to be optimal on
my system.  Don't think anybody will be running that at 2^27 any time
soon...!

Keep the cheer,


DaveG

Tim:

> It's odd that it gives *compilation* errors then.

Not really -- we've seen before that new symbols are added to the perl
lib when a new Perl version is released (see for example the use of
PERL589_OR_LATER in wxperl.cpp).  I think the correct fix is to
restore PERL_LINK to its original setting and make the following
changes in wxperl.cpp.

Add these lines at the top, near where we define PERL589_OR_LATER:

// check if we're building with Perl 5.10.1 or later
#if (PERL_REVISION == 5) && (PERL_VERSION >= 10) && (PERL_SUBVERSION >= 1)
   #define PERL5101_OR_LATER
#endif

Further down in the file you'll find 3 checks for PERL589_OR_LATER.
After each of those checks add these similar checks:

#ifdef PERL5101_OR_LATER
   SV* (*G_Perl_newSV_type)(pTHX_ svtype type);
#endif

#ifdef PERL5101_OR_LATER
   #define Perl_newSV_type          G_Perl_newSV_type
#endif

#ifdef PERL5101_OR_LATER
   PERL_FUNC(Perl_newSV_type)
#endif

Let me know if those changes work.

Andrew

Oh, sorry, I think GMail is interpreting it as a link when it is not.


On 29 May 2010 14:19, Alan Tennant <ala...@gm...> wrote:

> It's the pi.mc link that not working in my GMail on Firefox.
>
>
>
> On 29 May 2010 02:57, Paul Chapman <pa...@ig...> wrote:
>
>> Alan,
>>
>> > Your link doesn't work. Is anything new mentioned?
>>
>> The link works from Outlook Express in the UK.  Perhaps your email client
>> is
>> breaking the link in two.
>>
>> Cheers, Paul
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Golly-test mailing list
>> Gol...@li...
>> https://lists.sourceforge.net/lists/listinfo/golly-test
>>
>
>

It's the pi.mc link that not working in my GMail on Firefox.


On 29 May 2010 02:57, Paul Chapman <pa...@ig...> wrote:

> Alan,
>
> > Your link doesn't work. Is anything new mentioned?
>
> The link works from Outlook Express in the UK.  Perhaps your email client
> is
> breaking the link in two.
>
> Cheers, Paul
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

On 29 May 2010 00:14, Andrew Trevorrow <an...@tr...> wrote:
> Tim:
>
>>> :Following hints from the thread I changed Golly's makefile-gtk like this:
>>> :
>>> :#PERL_LINK = `perl -MExtUtils::Embed -e '$$]<5.010 && ldopts'`
>>> :PERL_LINK = `perl -MExtUtils::Embed -e ldopts`
>>> :
>>> :and it now works. But I've no idea whether this is something sensible
>>> :to do? I'll ask the other Golly developers.
>> ...
>> On Ubuntu 10.04, with just the makefile change as above it seems to
>> work fine - Golly builds and perl scripts run.
>
> I'm a bit mystified about how that fix could work.  I'm guessing your
> system has both Perl 5.8.* and 5.10.* versions installed somewhere?

Not as far as I know. I've looked through synaptic and it seems to be
just 5.10. And I've never installed any perl version through anything
other than synaptic.

>
> Just to be clear, the purpose of that PERL_LINK line is to ensure
> that if your Perl version is >= 5.10 then the PERL_LINK string is empty.
> That is, *no* perl library is linked into the Golly executable.
> This is because we can load the perl library dynamically (the 1st time
> you run a .pl script).  Various #defines in wxperl.cpp should ensure
> that happens (see PERL510_OR_LATER).

Right, so the empty string from the second of Tom's lines was correct.

It's odd that it gives *compilation* errors then. Maybe we need ldopts
for the compilation somehow. (I'm just guessing now.)

>
> I'm still using Ubuntu 8.0 so I should probably update to the same
> 10.04 system you're using -- is that a complicated process?
> Or would it be safer just to update Perl to 5.10.1?

I upgraded via 8.10, 9.04 and 9.10, so I don't know if you can do it in one go.

I don't know if perl 5.10 will work with 8.04. It may do.

>
> What is your perl_lib string set to in GollyPrefs?

perl_lib=libperl.so.5.10

> Presmably it's
> something like "libperl.so.5.10".  If you change it to some garbage
> string like "xxx" does Golly prompt you for a new perl lib when you
> try to run a .pl script?

Yes, it does.

> (That *should* happen if PERL510_OR_LATER
> has been defined.)
>
> Note that a Golly user recently reported a similar problem in this
> ConwayLife forum:
>
> http://conwaylife.com/forums/viewtopic.php?f=7&t=413
>
> Although he doesn't get the same undefined reference to Perl_newSV_type
> that you got.
>
> Clearly something in Perl 5.10.1 has changed, but rather than
> modifying the PERL_LINK line I think we need to add a new
> #define to wxperl.cpp and add/change some of the function(s).
>
> Andrew
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com

On 27 May 2010 23:16, Tom Rokicki <ro...@gm...> wrote:
> Tim,
> Let's consult on this.  Let me know when you have time.
> I'm the one that added the $$] && ldopts and it was added so we could build
> with both Perl 5.8 and Perl 5.10.
> Now you're saying it fails with 5.10.1.
> Can you tell me what this prints:
>    perl -MExtUtils::Embed -e ldopts

-Wl,-E  -fstack-protector -L/usr/local/lib  -L/usr/lib/perl/5.10/CORE
-lperl -ldl -lm -lpthread -lc -lcrypt

> and also what this prints:
>    perl -MExtUtils::Embed -e '$]<5.010 && ldopts'

(nothing!)

> and finally what this prints
>    perl -MExtUtils::Embed -e 'print $]'

5.010001

> Thanks!
> On Thu, May 27, 2010 at 2:46 PM, Tim Hutton <tim...@gm...> wrote:
>>
>> On 27 May 2010 10:19,  <hv...@cr...> wrote:
>> > Tim Hutton <tim...@gm...> wrote:
>> > :On 26 May 2010 22:01, Tim Hutton <tim...@gm...> wrote:
>> > :> Hi Hugo,
>> > :>
>> > :> I'm one of the Golly developers. I've just been trying to build Golly
>> > :> on Ubuntu 10.04 (Perl 5.10.1) for the first time and I'm hitting the
>> > :> error discussed here:
>> > :>
>> > http://www.nntp.perl.org/group/perl.perl5.porters/2009/12/msg155080.html
>> > :>
>> > :> At the end of that thread you say that it's caused by how perl is
>> > :> installed/configured/used? Could you talk me through what I need to
>> > do
>> > :> differently? I don't know much about Perl I'm afraid.
>> > :
>> > :Following hints from the thread I changed Golly's makefile-gtk like
>> > this:
>> > :
>> > :#PERL_LINK = `perl -MExtUtils::Embed -e '$$]<5.010 && ldopts'`
>> > :PERL_LINK = `perl -MExtUtils::Embed -e ldopts`
>> > :
>> > :and it now works. But I've no idea whether this is something sensible
>> > :to do? I'll ask the other Golly developers.
>> >
>> > Neither do I, sorry: from the thread you mention, you'll see that nobody
>> > commented on whether the existing approach was good or bad.
>> >
>> > :Sorry to have bothered you.
>> >
>> > No bother.
>> >
>> > I just tried redoing this from the same tarball (golly-2.1), with just
>> > the
>> > above change. If I set LD_LIBRARY_PATH correctly, the build succeeds
>> > fine
>> > but actually running one of the perl scripts fails with an error:
>> >  Can't locate strict.pm in @INC (@INC contains:
>> > /opt/perl-5.10.1-t/lib/5.10.1/i686-linux-thread-multi
>> > /opt/perl-5.10.1-t/lib/5.10.1
>> > /opt/perl-5.10.1-t/lib/site_perl/5.10.1/i686-linux-thread-multi
>> > /opt/perl-5.10.1-t/lib/site_perl/5.10.1 .) at -e line 1.
>> >
>> > The perl installation works fine (and the @INC is correct), so I'm not
>> > sure what is causing that to fail. I won't have time for a couple of
>> > weeks,
>> > but I'll try to remember to look further into that.
>> >
>> > FWIW this is the command I'm using to build:
>> >
>> >  PATH=/opt/perl-5.10.1-t/bin:/opt/python-2.5.2/bin:/opt/wxWidgets-2.8.10/bin:$PATH
>> > LD_LIBRARY_PATH=/opt/perl-5.10.1-t/lib:/opt/python-2.5.2/lib:/opt/wxWidgets-2.8.10/lib
>> > make -f makefile-gtk 2>&1 | tee make.log
>>
>> On Ubuntu 10.04, with just the makefile change as above it seems to
>> work fine - Golly builds and perl scripts run.
>>
>> CC'ing the Golly list to see if anyone has any ideas.
>>
>> Thanks,
>>
>> Tim
>>
>> --
>> Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Golly-test mailing list
>> Gol...@li...
>> https://lists.sourceforge.net/lists/listinfo/golly-test
>
>
>
> --
> Check out Golly at http://golly.sf.net/
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>
>



-- 
Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com

Alan,

> Your link doesn't work. Is anything new mentioned?

The link works from Outlook Express in the UK.  Perhaps your email client is 
breaking the link in two.

Cheers, Paul 

The link works for me!  But the article just mentions that I showed
off Adam's pattern (but it doesn't mention him, even though I did
say he was the author).

On Fri, May 28, 2010 at 6:53 PM, Alan Tennant <ala...@gm...> wrote:

> Your link doesn't work. Is anything new mentioned?
>
>
>
> On 28 May 2010 14:55, Tim Hutton <tim...@gm...> wrote:
>
>> Here's a write-up of the recent G4G:
>>
>> http://www.newscientist.com/article/dn18950-magic-numbers-a-meeting-of-mathemagical-tricksters.html?full=true
>>
>> Adam Goucher's universal constructor pi.mc is mentioned.
>>
>> --
>> Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Golly-test mailing list
>> Gol...@li...
>> https://lists.sourceforge.net/lists/listinfo/golly-test
>>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>
>


-- 
Check out Golly at http://golly.sf.net/

Your link doesn't work. Is anything new mentioned?


On 28 May 2010 14:55, Tim Hutton <tim...@gm...> wrote:

> Here's a write-up of the recent G4G:
>
> http://www.newscientist.com/article/dn18950-magic-numbers-a-meeting-of-mathemagical-tricksters.html?full=true
>
> Adam Goucher's universal constructor pi.mc is mentioned.
>
> --
> Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

Tim:

>> :Following hints from the thread I changed Golly's makefile-gtk like this:
>> :
>> :#PERL_LINK = `perl -MExtUtils::Embed -e '$$]<5.010 && ldopts'`
>> :PERL_LINK = `perl -MExtUtils::Embed -e ldopts`
>> :
>> :and it now works. But I've no idea whether this is something sensible
>> :to do? I'll ask the other Golly developers.
> ...
> On Ubuntu 10.04, with just the makefile change as above it seems to
> work fine - Golly builds and perl scripts run.

I'm a bit mystified about how that fix could work.  I'm guessing your
system has both Perl 5.8.* and 5.10.* versions installed somewhere?

Just to be clear, the purpose of that PERL_LINK line is to ensure
that if your Perl version is >= 5.10 then the PERL_LINK string is empty.
That is, *no* perl library is linked into the Golly executable.
This is because we can load the perl library dynamically (the 1st time
you run a .pl script).  Various #defines in wxperl.cpp should ensure
that happens (see PERL510_OR_LATER).

I'm still using Ubuntu 8.0 so I should probably update to the same
10.04 system you're using -- is that a complicated process?
Or would it be safer just to update Perl to 5.10.1?

What is your perl_lib string set to in GollyPrefs?  Presmably it's
something like "libperl.so.5.10".  If you change it to some garbage
string like "xxx" does Golly prompt you for a new perl lib when you
try to run a .pl script?  (That *should* happen if PERL510_OR_LATER
has been defined.)

Note that a Golly user recently reported a similar problem in this
ConwayLife forum:

http://conwaylife.com/forums/viewtopic.php?f=7&t=413

Although he doesn't get the same undefined reference to Perl_newSV_type
that you got.

Clearly something in Perl 5.10.1 has changed, but rather than
modifying the PERL_LINK line I think we need to add a new
#define to wxperl.cpp and add/change some of the function(s).

Andrew

Here's a write-up of the recent G4G:
http://www.newscientist.com/article/dn18950-magic-numbers-a-meeting-of-mathemagical-tricksters.html?full=true

Adam Goucher's universal constructor pi.mc is mentioned.

-- 
Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com

Tim:

> Here's the blog entry: http://ferkeltongs.livejournal.com/31455.html
> (I was happy to find a hex icon that worked.)

Nice work on the hex icon!  And I like the Turmite examples you've
added to Golly's pattern collection.

PS. A few of you already know this but I guess I should let others
know that my wife Shanti passed away on May 7th after a long battle
with cancer.  This is why I have been absent from the list for lengthy
periods over the last year or so.  My daughter and I will be going to
India in early July, but after that I hope life will return to a
reasonably normal routine and I'll get back into some Golly work.
Tentatively aiming for a release of 2.2 in August some time.

Andrew

Tim,

Let's consult on this.  Let me know when you have time.

I'm the one that added the $$] && ldopts and it was added so we could build
with both Perl 5.8 and Perl 5.10.

Now you're saying it fails with 5.10.1.

Can you tell me what this prints:

   perl -MExtUtils::Embed -e ldopts

and also what this prints:

   perl -MExtUtils::Embed -e '$]<5.010 && ldopts'

and finally what this prints

   perl -MExtUtils::Embed -e 'print $]'

Thanks!

On Thu, May 27, 2010 at 2:46 PM, Tim Hutton <tim...@gm...> wrote:

> On 27 May 2010 10:19,  <hv...@cr...> wrote:
> > Tim Hutton <tim...@gm...> wrote:
> > :On 26 May 2010 22:01, Tim Hutton <tim...@gm...> wrote:
> > :> Hi Hugo,
> > :>
> > :> I'm one of the Golly developers. I've just been trying to build Golly
> > :> on Ubuntu 10.04 (Perl 5.10.1) for the first time and I'm hitting the
> > :> error discussed here:
> > :>
> http://www.nntp.perl.org/group/perl.perl5.porters/2009/12/msg155080.html
> > :>
> > :> At the end of that thread you say that it's caused by how perl is
> > :> installed/configured/used? Could you talk me through what I need to do
> > :> differently? I don't know much about Perl I'm afraid.
> > :
> > :Following hints from the thread I changed Golly's makefile-gtk like
> this:
> > :
> > :#PERL_LINK = `perl -MExtUtils::Embed -e '$$]<5.010 && ldopts'`
> > :PERL_LINK = `perl -MExtUtils::Embed -e ldopts`
> > :
> > :and it now works. But I've no idea whether this is something sensible
> > :to do? I'll ask the other Golly developers.
> >
> > Neither do I, sorry: from the thread you mention, you'll see that nobody
> > commented on whether the existing approach was good or bad.
> >
> > :Sorry to have bothered you.
> >
> > No bother.
> >
> > I just tried redoing this from the same tarball (golly-2.1), with just
> the
> > above change. If I set LD_LIBRARY_PATH correctly, the build succeeds fine
> > but actually running one of the perl scripts fails with an error:
> >  Can't locate strict.pm in @INC (@INC contains:
> /opt/perl-5.10.1-t/lib/5.10.1/i686-linux-thread-multi
> /opt/perl-5.10.1-t/lib/5.10.1
> /opt/perl-5.10.1-t/lib/site_perl/5.10.1/i686-linux-thread-multi
> /opt/perl-5.10.1-t/lib/site_perl/5.10.1 .) at -e line 1.
> >
> > The perl installation works fine (and the @INC is correct), so I'm not
> > sure what is causing that to fail. I won't have time for a couple of
> weeks,
> > but I'll try to remember to look further into that.
> >
> > FWIW this is the command I'm using to build:
> >
>  PATH=/opt/perl-5.10.1-t/bin:/opt/python-2.5.2/bin:/opt/wxWidgets-2.8.10/bin:$PATH
> LD_LIBRARY_PATH=/opt/perl-5.10.1-t/lib:/opt/python-2.5.2/lib:/opt/wxWidgets-2.8.10/lib
> make -f makefile-gtk 2>&1 | tee make.log
>
> On Ubuntu 10.04, with just the makefile change as above it seems to
> work fine - Golly builds and perl scripts run.
>
> CC'ing the Golly list to see if anyone has any ideas.
>
> Thanks,
>
> Tim
>
> --
> Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out Golly at http://golly.sf.net/

On 27 May 2010 10:19,  <hv...@cr...> wrote:
> Tim Hutton <tim...@gm...> wrote:
> :On 26 May 2010 22:01, Tim Hutton <tim...@gm...> wrote:
> :> Hi Hugo,
> :>
> :> I'm one of the Golly developers. I've just been trying to build Golly
> :> on Ubuntu 10.04 (Perl 5.10.1) for the first time and I'm hitting the
> :> error discussed here:
> :> http://www.nntp.perl.org/group/perl.perl5.porters/2009/12/msg155080.html
> :>
> :> At the end of that thread you say that it's caused by how perl is
> :> installed/configured/used? Could you talk me through what I need to do
> :> differently? I don't know much about Perl I'm afraid.
> :
> :Following hints from the thread I changed Golly's makefile-gtk like this:
> :
> :#PERL_LINK = `perl -MExtUtils::Embed -e '$$]<5.010 && ldopts'`
> :PERL_LINK = `perl -MExtUtils::Embed -e ldopts`
> :
> :and it now works. But I've no idea whether this is something sensible
> :to do? I'll ask the other Golly developers.
>
> Neither do I, sorry: from the thread you mention, you'll see that nobody
> commented on whether the existing approach was good or bad.
>
> :Sorry to have bothered you.
>
> No bother.
>
> I just tried redoing this from the same tarball (golly-2.1), with just the
> above change. If I set LD_LIBRARY_PATH correctly, the build succeeds fine
> but actually running one of the perl scripts fails with an error:
>  Can't locate strict.pm in @INC (@INC contains: /opt/perl-5.10.1-t/lib/5.10.1/i686-linux-thread-multi /opt/perl-5.10.1-t/lib/5.10.1 /opt/perl-5.10.1-t/lib/site_perl/5.10.1/i686-linux-thread-multi /opt/perl-5.10.1-t/lib/site_perl/5.10.1 .) at -e line 1.
>
> The perl installation works fine (and the @INC is correct), so I'm not
> sure what is causing that to fail. I won't have time for a couple of weeks,
> but I'll try to remember to look further into that.
>
> FWIW this is the command I'm using to build:
>  PATH=/opt/perl-5.10.1-t/bin:/opt/python-2.5.2/bin:/opt/wxWidgets-2.8.10/bin:$PATH LD_LIBRARY_PATH=/opt/perl-5.10.1-t/lib:/opt/python-2.5.2/lib:/opt/wxWidgets-2.8.10/lib make -f makefile-gtk 2>&1 | tee make.log

On Ubuntu 10.04, with just the makefile change as above it seems to
work fine - Golly builds and perl scripts run.

CC'ing the Golly list to see if anyone has any ideas.

Thanks,

Tim

-- 
Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com

Hi Alan,

Here's the blog entry: http://ferkeltongs.livejournal.com/31455.html
(I was happy to find a hex icon that worked.)

Previously the only way to get hex CA was to use make-ruletree.py,
following Andrew's work:
http://code.google.com/p/ruletablerepository/wiki/TheRules#Hexagonal_neighborhood

In Golly 2.2 we will support the hexagonal neighborhood in rule
tables, in two ways:
- indirectly: RuleTableToTree.py will convert hexagonal rule tables to
Moore rule trees (done)
- directly: the RuleTable algorithm will read hexagonal rule tables
(I'm nearly finished)

We're not changing the rendering or the processing (hashlife);
internally, Golly still only supports the von Neumann and Moore
neighborhoods. But with the new hex icon the slanted-grid hex
emulation should look reasonably OK, as the examples in the blog post
show. (Especially if you turn the grid lines off.)

If you want to use the hexagonal icon straight away, you can find the
pixels here:
http://golly.cvs.sourceforge.net/viewvc/golly/golly/src/Scripts/Python/glife/EmulateHexagonal.py?view=markup

I hope that's all clear now?

Tim

On 26 May 2010 14:13, Alan Tennant <ala...@gm...> wrote:
> I read on someones blog recently that Golly was being improved to render
> hexagonal neighbourhoods and that icons were available as a work around for
> now on hexagonal rules.
>
> I wondered whether golly will now have "2D squares and 2D hexagons" or if
> some of the stuff in the suggestions part of the RTR will get implemented
> with more generic neighbourhoods and rendering.
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>
>



-- 
Tim Hutton - http://www.sq3.org.uk - http://ferkeltongs.livejournal.com

I read on someones blog recently that Golly was being improved to render
hexagonal neighbourhoods and that icons were available as a work around for
now on hexagonal rules.

I wondered whether golly will now have "2D squares and 2D hexagons" or if
some of the stuff in the suggestions part of the RTR will get implemented
with more generic neighbourhoods and rendering.

>
> 1) the radical rearrangement of folders that we've discussed
> previously, moving all the Conway's Life patterns into one subfolder,
> to put Life on an equal footing with all the other folders specific to
> different rules.  B3/S23 will still be over-represented in terms of
> number of patterns, but it won't have multiple miscellaneous folders
> mysteriously mixed in with single folders for unrelated rules.
>

Horray.


3) a set of "recognizer" scripts to allow a user to build a library of
> registered subpatterns, then write out a new Python script defining
> the current pattern in terms of those registered subpatterns.
>

or golly feature.

On Wed, May 5, 2010 at 7:47 AM, Andrew Trevorrow <an...@tr...> wrote:

> http://with-logic.co.uk/CA/LifeHistoryRules.zip
> ...
> http://ruletablerepository.googlecode.com/files/LifeHistoryRules.zip
> ...
> http://ruletablerepository.googlecode.com/files/HistoricalLife.zip

You're right, this is still a bit of a mess.  Thanks for collecting
these links -- I'll have a closer look at them and get everything
cleaned up.

> So, does the definitive LifeHistory rule have 5 or 7 states?

7 states -- the version I checked in to Golly is the final version.
But very few people actually use the last two states yet -- e.g., I
haven't posted any patterns containing start-ON or boundary-OFF cells
anywhere -- so the 5-state version is equivalent for most purposes.

I am planning on using the start-ON state a lot in the
Herschel-conduit documentation project, though, both in the glife
module and as standard colors for illustrations on the LifeWiki.
Might end up with a stamp collection or two that contains the
boundary-OFF state, as well -- it's very handy from keeping stray
gliders from wandering into unrelated neighboring displays and doing
mysterious confusing damage, and stray gliders are a particular
problem with Herschel tracks...

> If both are valid variants then wouldn't it be better to give
> one a different name (like LifeHistory2)?

The 5-state subset can't do anything that the 7-state one can't do, so
I think I'll stick with "LifeHistory" = 7-state as per Golly 2.1.
Obviously I should have been a little more diligent about killing off
that older trial version.

> And which zip file should people be downloading from the RTR?

There's not so much need to download any LifeHistory packages from the
RTR, now that LifeHistory is built into Golly 2.1.  However, I do have
a set of conversion scripts to get me from Life to LifeHistory and
back, which I use all the time these days.  I'll update the .zip file
to include those.

Keep the cheer,


Dave

The LifeHistory.table file supplied with Golly has 7 states, but in this
zip file linked from the RTR (in the "Life-inspired CAs" section):

http://with-logic.co.uk/CA/LifeHistoryRules.zip

there is a LifeHistory.table file with 5 states.
To add to the confusion, there is also another zip file linked from
the main page and the HistoricalLife page:

http://ruletablerepository.googlecode.com/files/LifeHistoryRules.zip

which seems very similar to the above zip but contains an extra file
called "HistoricalLife ReadMe.txt".

So, does the definitive LifeHistory rule have 5 or 7 states?
If both are valid variants then wouldn't it be better to give
one a different name (like LifeHistory2)?
And which zip file should people be downloading from the RTR?

There's also a featured link on the main page to:

http://ruletablerepository.googlecode.com/files/HistoricalLife.zip

Presumably we don't need that AND LifeHistoryRules.zip?

Andrew

Dave, much thanks for the excellent feedback.  Sadly it could be some
weeks before I'm able to give the attention it deserves (ditto for
Tim's recent message about RuleTableToTree.py).  My wife is currently
very ill and so all Golly-related work is on the back burner.
I'll probably find a little time to spend on Golly, if only to take
my mind off other things.

As for Golly 2.2's release, my best guess is that it's at least
3 months away.

Andrew

>
> It might make sense to show some kind of out-of-memory warning in
> cases like this, at least in the status bar or timeline bar if not in
> a pop-up window -- assuming it's somehow possible to tell the
> difference between a permanent choke-up and regular old
> hard-work-for-hashlife. (?)
>

Yeah, "hash info" gives a clue what's going on, but not much.  We
could introduce a threshold for unrecovered memory during a GC
which would trigger some status message or something.  It's
probably a good thing to do.


> 1.5Gb turns out to be plenty of memory to produce a full 270-tick
> timeline, and it was certainly worthwhile to do it:  with an
> appropriate speed setting you can see the Caterpillar evolve at a much
> higher frame rate than hashlife can normally manage.  Speed
> improvement is near a full order of magnitude on my system.  The
> timeline saves out as a 571Mb macrocell file, which Golly can re-load
> with no problems in a little under a minute.
>

If you turn off population display, it will probably be a *lot* faster
than even that.


> I was thinking that it might be handy for a user to be able to
> *reduce* that 32,000-frame limit -- for example, I could have set the
> limit to 270 frames and just walked away and let Golly generate the
> Caterpillar timeline.  As it was I had to keep an eye on it and stop
> generating new frames at exactly the right time.  For smaller patterns
> and faster computers an adjustable cutoff would make it much easier to
> get exactly the frames you want into the timeline..
>

Yeah, I think your idea from earlier is a good one; add a "chop-after"
and "chop-before" option somewhere in some menu.  The code to do
this is trivial.


> The first time I tried to load a Caterpillar, create a timeline, and
> save and re-load the resulting macrocell file, I got an "Out of
> Memory" crash-and-exit error during the re-loading process, well
> before Golly used up the full 1.5 gigs it was theoretically entitled
> to -- I think Windows XP was reporting Golly's memory use as being
> around 600Mb at the time of the crash.
>

I bet you're running on a 32-bit platform.  This sort of thing will
all but disappear as soon as everyone is on 64-bit platforms.  What
happened almost certainly is memory got fragmented, and Golly
couldn't get the big chunks of contiguous address space it needed.

Even on a 64-bit platform, a 32-bit Golly will be subject to that issue
(but to a much lesser extent).  But moving to a 64-bit Golly will
"halve" the effectiveness of memory since all pointers double in size
(and in Golly, *everything* is a pointer).  A solution to this is to use
array indices rather than pointers, but I haven't coded that up yet
(and there are some subtleties here).

So, really, I don't have a good solution at the present time.


> seriously confused the system somehow.  Haven't seen that error again
> since I tried re-loading the .mc with a new instance of Golly.  I'll
> try to find some steps to duplicate the problem.
>

I don't think there was confusion, just fragmentation, and the need for
large contiguous chunks of memory.  Too bad it has to be visible.


> My newest wildest feature request for timelines would be a
> unidirectional playback option, with an optional dx,dy,dt offset to
> smooth it out.  This is similar but not the same as an offset for
> plain-vanilla layers, which would allow a viewport to track a moving
> pattern automatically.  That feature request is in the TODO list under
> Jason Summers:  to track a Caterpillar in a normal viewport, for
> example, Golly would just have to do its best to move the viewport by
> 17/45 cells every tick.
>

Time lines should be fully scriptable if we wanted to; we just add

"start recording()"
"get-timeline-info()" (#frames, gen at first, gen at last)
"goto frame(#)"
"remove before(#)"
"remove after(#)"

Every "step" will add a frame (if the current frame is the last and the
step size is right), so you could easily "drive" a timeline with a script
including the viewport offsets.


> -- Another scripting-support question:  might Golly 2.2 end up with
> functions that could help a Caterpillar-maker.py script produce a
> Caterpiller-timeline.mc that stores all 270 frames of the pattern?
>

How does this differ from loading (or constructing) caterpiller @ 0, then
stepping it for 270 with recording turned on, then "save"?


> Looks like that would be quite a bit of coding, as things stand now.
> A possible exception might be a huge-stupid macrocell file, where the
> phases of the Caterpillar are saved to normal .mc files, and those are
> concatenated into a #FRAMEd macrocell file -- renumbering as
> necessary, but without worrying about re-using quadtree subpatterns
> between different frames.
>


> Would Golly load a monstrosity like that okay, or would it take a lot
> more memory?  A bigger file might not be too big a deal as long as it
> got shrunk down to "normal" size when it was loaded -- especially if
> the file could be optimized just by loading and re-saving it.
>

Golly (presently) would seriously choke.  Sorry.  Right now there's
no "intermediate" coalescing of identical frames.  This also shows up
when you try to load a too-large-mc for the current memory settings.
This is something I should remedy.


> I'll have to set aside a good chunk of time sometime soon to work on a
> sub-100K Caterpillar script, hopefully built with the assistance of my
> "recognizer" utility -- something small enough to include in the main
> Golly archive (as chrysalis.py, maybe?).  It might take a while for
> the script to build a full Caterpillar pattern file on the first run,
> but after that it can just quickly open a saved .mc file.
>

Excellent!


> More later -- keep the cheer,


Thank you so much; there's so much to do, but so much of it is fun.
Your efforts are essential in the success we've had with Golly.

-tom

>
> When is the beta likely to turn into a full Golly 2.2 release -- any
> target dates yet?  I have a pile of possible things to work on,
> assuming I've got a few weeks left at least.  Here's what comes to
> mind offhand:
>

Probably not for a while, although I can't speak for Andrew.


> 1) the radical rearrangement of folders that we've discussed
> previously, moving all the Conway's Life patterns into one subfolder,
> to put Life on an equal footing with all the other folders specific to
> different rules.  B3/S23 will still be over-represented in terms of
> number of patterns, but it won't have multiple miscellaneous folders
> mysteriously mixed in with single folders for unrelated rules.
>

Sounds great!


> 2) an update for herschel.py in the 'glife' folder, which I can import
> into another script to produce a much larger stamp collection of
> Herschel tracks and other period-independent signal processing
> components, probably in LifeHistory format.  This has been overdue for
> several versions of Golly now -- the current herschel.py only includes
> eight out of the twenty or so known Herschel conduits (depending on
> how you count them).
>

Excellent.


> 3) a set of "recognizer" scripts to allow a user to build a library of
> registered subpatterns, then write out a new Python script defining
> the current pattern in terms of those registered subpatterns.
>
> I have a version of this last project that has been successfully
> tested against a good variety of stamp collections -- e.g., it can
> recognize and build an exact copy of a pattern showing all phases and
> orientations of a swan, or a galaxy, or whatever spaceship or
> oscillator you choose (as long as you add the base object to the
> library first).  There are still a few known bugs in the system,
> though, and I have yet to write up a good user's guide.
>

Love it!


> 4) If I have time, or can convince someone else to work on it, it
> might be worth checking in some version of a census utility also --
> maybe into the glife folder also, so it can be used in larger search
> projects?  For example, I've been increasingly tempted to put together
> a Python script that can replicate a number of Glue's key results, and
> continue into territory that Glue hasn't [yet] explored...  Nathaniel
> Johnston's census script seems to be getting some use across a fairly
> good range of rules, so that might make a good base.  If I get really
> ambitious, maybe I can look up the census-script output in my
> "recognizer" library files to get standard names to report for the
> various object counts.
>

Sounds interesting.


> Anyway, let me know roughly how much time I have left, and maybe which
> of the above sound most worthwhile/useful/interesting, and I'll try to
> start squeezing things in.  More soon --


Heh, they are all good.  I have no problems "holding up" any pending
release while you take your time to pick and choose which to do; there's
no great hurry to rush 2.2 out.

Of course Andrew pretty much holds the keys to the project, as well he
should.

>
> Apologies for the slow response re: Golly 2.2 -- apparently I've been
> painfully busy for the last month.  I did try out the new timeline
> feature as soon as the beta came out, and have a few miscellaneous
> comments and suggestions.
>

Thank you for your comments!  They are much appreciated.  The
timeline feature is something I've wanted for a long time and I'm
totally psyched to see it in there.


> First off, when I started trying to use the timeline, I kept trying to
> use the unlabeled speed slider bar as the timeline slider.  That
> didn't work very well... I got over the confusion eventually, but it
> seemed as if some Slower<<...>>Faster labels might be a good idea
> there.


Heh.  I'll let Andrew discuss that; I know my limits when it comes to UI
design.


> Might it be possible when a timeline is deleted to include all the
> frames in the Undo buffer, instead of just the first one?  And the
> converse would be handy on occasion, too:  if the Undo/Redo buffer is
> a series of "Undo/Redo to Gen Xn", converting it to a timeline would
> allow you to scroll back and forth between the various snapshots.
>

Interesting thought.


> [Which brings up the even crazier idea of being able to save Undo
> information along with a pattern.  I occasionally find I want to do
> that, too -- but maybe not for any very good reasons...  Sorry.  End
> of wild tangent.  Back to main subject.]


Maybe just a "save session" with the current undo history and pattern
and viewports and other settings?


> Yes.  In particular, for projects like Bill Gosper's long-term novelty
> experiments where your goal is to save out an .mc file with various
> interesting stages of a pattern's evolution embedded in it, it would
> be good to be able to run the pattern _without_ recording, changing
> the step size to whatever is appropriate, and then push a button to
> take a single snapshot, or else start recording again for a while at
> the current step size.  I suppose if you can add single snapshots to a
> timeline, it might also be nice to be able to delete the current
> snapshot.  (Deleting a range of snapshots would need too much new GUI
> clutter, probably.)
>

Semantics get a bit unclear here, though, and replay would "stutter"
in odd ways, right?  I'm trying to see how we can conceptualize this.
An arithmetic sequence of generations seems intuitive; how do we
capture a more general ordered sequence, and then make use of it?


>   On a fast computer there isn't a lot of fine
> control for moderate speeds on the speed slider, probably for roughly
> the same reason I have to specify 5 or 10 milliseconds as the smallest
> delay in my default GollyPrefs, instead of the standard 250
> milliseconds.  There's great control available between
> enormously-too-slow down to a-little-too-slow, and then one bump of
> the slider gets you to a-little-too-fast, and then the other half of
> the slider will let you pick a wide range of speeds up through
> ridiculous to ludicrous.
>

I've noticed this too.  So it's not just me.  :-)


> Speaking of which, might it make sense to display the speed slider
> before starting the first recording session, to allow users to avoid
> the runaway-recording problem for short timelines?
>

Time line recording is somewhat 'integrated'.  Perhaps better is to
hit the "record" button, then use the "goto.pl" or "goto.py" script
or some variation (that doesn't change the step size).  And
stuff like that.


> I spent some time looking for a right-click option or menu choice that
> would let me drop everything before or after the current timeline
> position and get rid of the boring part.  Haven't found anything like
> that -- am I missing something?  There are mysterious "Left Edge" /
> "Right Edge" options that almost do what I want, but I think that's a
> bug:  if I choose "Left Edge" when a pi has just stabilized, the
> timeline looks as if it's been truncated -- the scrollbar indicator
> moves to the far right, and I can start rewinding and immediately see
> the pi regressing back to its initial state... but then it sticks in
> its initial state for hundreds of frames, and when it starts running
> forward again it turns out that the hundreds of stable frames at the
> end are still there after all.
>

I like the option you suggest.


> Well, I like the auto-reverse feature, myself.  Might be worth a
> toggle somewhere, like a "bidirectional" checkbox on the timeline
> toolbar?
>

I think it's real cute.  We could have a "cycle" "once-only" "bounceback"
3-state toggle.

Here's another round of notes about Caterpillars and timelines:

My first attempt to create a Caterpillar timeline failed due to memory
limitations.  The beta was set to use the default 300Mb instead of my
usual 1.5Gb; Golly used up the 300Mb in the first 30+ ticks, but
didn't get completely choked up until it tried to produce frame #88.
It didn't quite lock up, but it became less responsive, and it never
seemed to finish that frame and move on to the next.  Eventually I
just clicked the button to cancel the timeline generation, and after a
few seconds Golly went back to normal responsiveness again.

It might make sense to show some kind of out-of-memory warning in
cases like this, at least in the status bar or timeline bar if not in
a pop-up window -- assuming it's somehow possible to tell the
difference between a permanent choke-up and regular old
hard-work-for-hashlife. (?)

1.5Gb turns out to be plenty of memory to produce a full 270-tick
timeline, and it was certainly worthwhile to do it:  with an
appropriate speed setting you can see the Caterpillar evolve at a much
higher frame rate than hashlife can normally manage.  Speed
improvement is near a full order of magnitude on my system.  The
timeline saves out as a 571Mb macrocell file, which Golly can re-load
with no problems in a little under a minute.

I was thinking that it might be handy for a user to be able to
*reduce* that 32,000-frame limit -- for example, I could have set the
limit to 270 frames and just walked away and let Golly generate the
Caterpillar timeline.  As it was I had to keep an eye on it and stop
generating new frames at exactly the right time.  For smaller patterns
and faster computers an adjustable cutoff would make it much easier to
get exactly the frames you want into the timeline..

The first time I tried to load a Caterpillar, create a timeline, and
save and re-load the resulting macrocell file, I got an "Out of
Memory" crash-and-exit error during the re-loading process, well
before Golly used up the full 1.5 gigs it was theoretically entitled
to -- I think Windows XP was reporting Golly's memory use as being
around 600Mb at the time of the crash.

Before trying to re-load the saved .mc file, I had been changing my
memory-use preferences on the fly and cancelling timeline frame
generation when it got stuck and so forth.  Apparently this had
seriously confused the system somehow.  Haven't seen that error again
since I tried re-loading the .mc with a new instance of Golly.  I'll
try to find some steps to duplicate the problem.

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

My newest wildest feature request for timelines would be a
unidirectional playback option, with an optional dx,dy,dt offset to
smooth it out.  This is similar but not the same as an offset for
plain-vanilla layers, which would allow a viewport to track a moving
pattern automatically.  That feature request is in the TODO list under
Jason Summers:  to track a Caterpillar in a normal viewport, for
example, Golly would just have to do its best to move the viewport by
17/45 cells every tick.

A timeline offset would be something else again. To get a Caterpillar
timeline to look nice and smooth, *without* any tracking, Golly would
move the viewport by 102 cells along the y axis, just once every 270
ticks -- whenever it's just finished displaying one end of the
timeline and is about to jump back to the other end.  17c/45
micro-adjustments to the viewport would work fine in combination with
the big 102-cell jump, but the two offsets would work independently of
each other.

Scripts like heisenburp.py already move the viewport around to track
moving patterns, and there's a note in Jason's section of the TODO
file saying that layer offsets are easy to do with scripts... but I
don't think that approach is going to mix too well with timelines,
which I'm guessing won't have much of any scripting support (?).  It
would be very nice to be able to set up moving viewports without
having to have a script running, anyway.

-- Another scripting-support question:  might Golly 2.2 end up with
functions that could help a Caterpillar-maker.py script produce a
Caterpiller-timeline.mc that stores all 270 frames of the pattern?
Looks like that would be quite a bit of coding, as things stand now.
A possible exception might be a huge-stupid macrocell file, where the
phases of the Caterpillar are saved to normal .mc files, and those are
concatenated into a #FRAMEd macrocell file -- renumbering as
necessary, but without worrying about re-using quadtree subpatterns
between different frames.

Would Golly load a monstrosity like that okay, or would it take a lot
more memory?  A bigger file might not be too big a deal as long as it
got shrunk down to "normal" size when it was loaded -- especially if
the file could be optimized just by loading and re-saving it.

I'll have to set aside a good chunk of time sometime soon to work on a
sub-100K Caterpillar script, hopefully built with the assistance of my
"recognizer" utility -- something small enough to include in the main
Golly archive (as chrysalis.py, maybe?).  It might take a while for
the script to build a full Caterpillar pattern file on the first run,
but after that it can just quickly open a saved .mc file.

More later -- keep the cheer,


Dave