golly-test Mailing List for Golly

>
> One thing you could try: enter some unused ctrl-key combo (eg. Ctrl-J) for
> Next Step.
> Golly should show that combo in the Control menu in preference to Tab (but
> you'll still
> be able to use Tab).  That should avoid the Debug message the next time
> Golly starts.
>

Yes, that worked - thanks.


> It may well be that Chris is building Golly with a later wx version.
>

True: wx-config reports 3.1.3

Jon:

What DE are you using? ...
>

MATE 1.16.0.  I'm currently building Golly with wxWidgets 3.0.5 (the latest
stable release)
which uses GTK2 by default.  That's what we currently recommend in
docs/Build.html.
It may well be that Chris is building Golly with a later wx version.  I
think the latest
development version (3.1.4) uses GTK3 by default.

I guess at some stage we should switch Golly to GTK3 but I'm reluctant to
do that now,
especially if it's going to cause spurious messages like the one Chris is
seeing.
I'd prefer to wait until the wx devs release a *stable* 3.2(?) version.

Andrew

Andrew, 
What DE are you using? Mint 18 uses Ubuntu 16.04 as a base, so if you're using MATE or Xfce you've probably still got GTK2 (both DEs had changed to GTK3 by the time 18.04 rolled around, because nobody's maintaining GTK2 anymore).
There's are a ton of regressions/slimmed down functionality (depending on which side of the MATE/GNOME holy war you take) between GTK2 and GTK3, so I wouldn't be surprised if the difference between what you're seeing and what Chris is seeing is functionality that's been deprecated or removed between GTK2 and whatever version of GTK3 he's got. 

-------- Original message --------
From: Andrew Trevorrow <and...@gm...> 
Date: 9/26/2020  18:37  (GMT-06:00) 
To: golly test list <gol...@li...> 
Subject: Re: [Golly-test] Linux warning 

Chris: When I run Golly on Ubuntu I get the following warning as it starts:
19:23:02: Debug: "Tab" is not supported as a keyboard accelerator with GTK
Don't see that on my Linux Mint 18 system. However, Tab does seem to be special insome way.  If I go to Golly's Keyboard prefs I can enter Tab but not Ctrl-Tab.
One thing you could try: enter some unused ctrl-key combo (eg. Ctrl-J) for Next Step.Golly should show that combo in the Control menu in preference to Tab (but you'll stillbe able to use Tab).  That should avoid the Debug message the next time Golly starts.
Andrew

Chris:


> When I run Golly on Ubuntu I get the following warning as it starts:
>
> 19:23:02: Debug: "Tab" is not supported as a keyboard accelerator with GTK
>

Don't see that on my Linux Mint 18 system. However, Tab does seem to be
special in
some way.  If I go to Golly's Keyboard prefs I can enter Tab but not
Ctrl-Tab.

One thing you could try: enter some unused ctrl-key combo (eg. Ctrl-J) for
Next Step.
Golly should show that combo in the Control menu in preference to Tab (but
you'll still
be able to use Tab).  That should avoid the Debug message the next time
Golly starts.

Andrew

When I run Golly on Ubuntu I get the following warning as it starts:

19:23:02: Debug: "Tab" is not supported as a keyboard accelerator with GTK

Doesn't seem to affect Golly since the Tab key works fine and advances the
pattern.

I'm running Golly 4.0b1 on Ubuntu 20.04 using Xfce Desktop under WSL 2.

Any ideas how to get rid of the warning?

>
> Really, we should change all that rule code to use std::string instead of
> C++
> char* and explicit memory management.  That change probably would
> actually not be that hard, except it's not something we should do the week
> before a release.
>

Agreed on both counts.


> For now a bump to say 2000 is not unreasonable, if you think that would
> make things more useful.  But of course at that length we are no longer
> talking about human-usable rule strings anyway.
>

Yes that's good enough for now. The specific use case is that there is a new
script, create-custom-ltl.lua, that generates HROT Custom neighborhood
rule strings from pattern selections. Andrew spotted it was breaking Golly.

Chris

Hmm.  How big do you need?

Really, we should change all that rule code to use std::string instead of
C++
char* and explicit memory management.  That change probably would
actually not be that hard, except it's not something we should do the week
before a release.

For now a bump to say 2000 is not unreasonable, if you think that would
make things more useful.  But of course at that length we are no longer
talking about human-usable rule strings anyway.

-tom

On Fri, Sep 25, 2020 at 10:24 PM Chris Rowett <cr...@gm...> wrote:

> With the new HROT format rules and Custom and Weighted neighborhoods it is
> simple to generate rule strings, via scripts or otherwise, that are much
> longer than the current maximum 500 characters defined by MAXRULESIZE.
>
> For example the longest canonical range 5 HROT rule string with the
> default Moore neighborhood is 523 characters. Note that the algo supports
> ranges up to 500.
>
>
> R5,C256,S0,2-3,5-6,8-9,11-12,14-15,17-18,20-21,23-24,26-27,29-30,32-33,35-36,38-39,41-42,44-45,47-48,50-51,53-54,56-57,59-60,62-63,65-66,68-69,71-72,74-75,77-78,80-81,83-84,86-87,89-90,92-93,95-96,98-99,101-102,104-105,107-108,110-111,113-114,116-117,119-120,B0,2-3,5-6,8-9,11-12,14-15,17-18,20-21,23-24,26-27,29-30,32-33,35-36,38-39,41-42,44-45,47-48,50-51,53-54,56-57,59-60,62-63,65-66,68-69,71-72,74-75,77-78,80-81,83-84,86-87,89-90,92-93,95-96,98-99,101-102,104-105,107-108,110-111,113-114,116-117,119-120:T10000,10000
>
> If you're using a Custom or Weighted neighborhood then the rule string is
> even longer.
>
> Are there any issues in increasing MAXRULESIZE?
> If it can safely be increased then what would be a reasonable limit?
>
> Chris
>
>
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>


-- 
--  http://cube20.org/  --  http://golly.sf.net/  --

With the new HROT format rules and Custom and Weighted neighborhoods it is
simple to generate rule strings, via scripts or otherwise, that are much
longer than the current maximum 500 characters defined by MAXRULESIZE.

For example the longest canonical range 5 HROT rule string with the default
Moore neighborhood is 523 characters. Note that the algo supports ranges up
to 500.

R5,C256,S0,2-3,5-6,8-9,11-12,14-15,17-18,20-21,23-24,26-27,29-30,32-33,35-36,38-39,41-42,44-45,47-48,50-51,53-54,56-57,59-60,62-63,65-66,68-69,71-72,74-75,77-78,80-81,83-84,86-87,89-90,92-93,95-96,98-99,101-102,104-105,107-108,110-111,113-114,116-117,119-120,B0,2-3,5-6,8-9,11-12,14-15,17-18,20-21,23-24,26-27,29-30,32-33,35-36,38-39,41-42,44-45,47-48,50-51,53-54,56-57,59-60,62-63,65-66,68-69,71-72,74-75,77-78,80-81,83-84,86-87,89-90,92-93,95-96,98-99,101-102,104-105,107-108,110-111,113-114,116-117,119-120:T10000,10000

If you're using a Custom or Weighted neighborhood then the rule string is
even longer.

Are there any issues in increasing MAXRULESIZE?
If it can safely be increased then what would be a reasonable limit?

Chris

Scorbie:

* The stable ABI doesn't support Python3 versions < 3.3; Is it worth using
> it?
>

I don't see any problem requiring people to use 3.3 or later with Golly, as
long as
we make sure the docs (changes.html and python.html) mention that.


> Question: Would you accept PRs for converting the macros to
> function(pointer)s?
>
>> <" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/golly-test>
>
>
I'd rather you make changes directly to wxpython.cpp in the repo on sf.
I've stored a copy of the current (working) version so we can easily revert
if the
stable ABI changes don't work out.  I don't really mind what changes you
end up
making, as long as the final result compiles (and works!) on all 3
platforms.

One thing has me slightly worried: The version of wxpython.cpp you linked to
looks quite old compared with the latest version on sf.  For example, it
contains
these lines:

#ifdef __WXMAC__
    #define LOAD_PYTHON_STATIC
#endif

But the Mac app now loads the Python lib at runtime, just like on
Windows/Linux.
Hopefully you can merge the stable ABI changes into the latest version.

Andrew

Apologies for the not-so-short inactivity.
I have not been able to get my hands on the stable ABI for some time,
but I think I can work on it if the following directions are set:

* The stable ABI doesn't support Python3 versions < 3.3; Is it worth using
it?
(The stable ABI is introduced in Python 3.2, but that doesn't include
PyArg_ParseTuple)
https://gist.github.com/Scorbie/9f139d24b33173696397350a901b9e8d#file-wxpython-cpp-L56-L63

* I've experienced some issues with macros in the current wxpython.cpp when
converting the code to use the stable ABI; When adding new functions, even
if you don't define a new macro for that function (i.e. #define Py_Function
G_Py_Function), it will be masked by the macro in Python.h, and the errors
come out on runtime when loading the DLL, AFAIR.
Question: Would you accept PRs for converting the macros to
function(pointer)s?
(Declaring and using G_Py_Functions when embedding code)
The downside of this would be that it's a little more cumbersome to prepend
G_ to every function.

Thank you.

Best wishes to you, Scorbie (Dongook Lee)


On Wed, Sep 23, 2020 at 12:31 AM Chris Rowett <cr...@gm...> wrote:

> On Sun, Sep 20, 2020 at 5:32 AM Andrew Trevorrow <
> and...@gm...> wrote:
>
>> Here is a list of the tasks we need to complete (in brackets are the
>> people who will most likely have to do them!):
>>
>> * Write the docs for the new LtL rules. (Chris?)
>>
>
> Initial documentation committed for review.
>
> Chris
>
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

> A message from a satisfied customer:
>
> Symbiosis Promotes Fitness Improvements in the Game of Life
> https://www.mitpressjournals.org/doi/pdfplus/10.1162/artl_a_00326

Hm, somebody out there is trying to use genetic algorithms to evolve
Game of Life patterns after all!

"We conjecture that the entities that evolve in Model-S will show
increasing degrees of autopoiesis
 as the number of generations in the simulation increases, but we have
not yet tested this hypothesis."

Autopoesis is defined as "self-production and self-maintenance", but
for the sizes of patterns they're dealing with I think that just means

"a spacefiller that defends its boundaries would be great, but more
realistically a big explosion would be okay, or maybe a multi-glider
gun like Jason's p156."

Seems like that hypothesis might not work out too well in practice --
unworkably large sizes would be needed.

It's not clear if the various mutation and selection processes
produced anything that Lifenthusiasts might consider interesting.  I
wouldn't think that anything like a glider gun would be likely to
evolve with those intergenerational transition rules and the number of
CPU-hours devoted to the experiments, unless the experiment started
with intact pieces of a glider gun somehow.


Dave

A message from a satisfied customer:

---------- Forwarded message ---------
From: Peter Turney <pet...@gm...>
Date: Wed, Sep 23, 2020 at 7:51 AM
Subject: Re: Modeling Major Transitions in Evolution with the Game of Life
To: Andrew Trevorrow <an...@tr...>


Hi Andrew,

The paper I've been working on for two years has finally been published in
the MIT journal, *Artificial Life*:

   - Symbiosis Promotes Fitness Improvements in the Game of Life
   - https://www.mitpressjournals.org/doi/pdfplus/10.1162/artl_a_00326

In the paper, I acknowledge the Golly team for their help:

Acknowledgments

Thanks to Tim Taylor and Martin Brooks for helpful discussion and advice.
Thanks to Andrew Trevorrow, Tom Rokicki, Tim Hutton, Dave Greene, Jason
Summers, Maks Verver, Robert Munafo, Brenton Bostick, and Chris Rowett for
developing Golly, which made this research more productive and enjoyable.

Thanks to the Artificial Life reviewers for their very thoughtful and
helpful comments.


I don't have the email addresses for the Golly team. Could I ask you to
please forward my thanks to them?

I'm continuing to use Golly in my latest project, and it continues to make
my work so much faster, easier, and more enjoyable than it would be without
Golly.

Cheers,
Peter.

On Sun, Sep 20, 2020 at 5:32 AM Andrew Trevorrow <and...@gm...>
wrote:

> Here is a list of the tasks we need to complete (in brackets are the
> people who will most likely have to do them!):
>
> * Write the docs for the new LtL rules. (Chris?)
>

Initial documentation committed for review.

Chris

> Having said that if you feel it would be helpful and
> less confusing to add an optional M parameter to the
> HROT format let me know.

No, as long as the algorithm supports other formats that use neighbor counts like the published ones, I think it should be OK.  It would be helpful if the documentation discusses this.

Dean

Having said that if you feel it would be helpful and less confusing to add
an optional M parameter to the HROT format let me know.

R<range>,C<states>,(M<middle>,)S<list>,B<list>,N<neighborhood>

Chris

>
> Does this mean that the neighbor count for survival does not include the
> central cell?  If so, that's likely to cause confusion, since published
> articles about LtL do include it.  For example, some of Kellie Evans's
> papers discuss "Bosco's rule", which is described by range 5, survival
> range 34-58, and birth range 34-45.  In outer totalistic form it would have
> to be entered as "R5,C0,S33-57,B34-45".
>

Yes. However the algo supports 3 formats:

1. Mirek Wojtowicz's MCell original LtL format which can be outer
totalistic or totalistic:
R<range>,C<states>,M<middle>,S<smin>..<smax>,B<bmin>..<bmax>,N<neighborhood>

R5,C0,M1,S34..58,B34..45  (totalistic)
or
R5,C0,M0,S33..57,B34..45  (outer totalistic)

2. Kellie Evan's original format from her thesis:
<range>,<bmin>,<bmax>,<smin>,<smax>  (totalistic)

5,34,45,34,58

3. LifeViewer's HROT (Higher Range *Outer* Totalistic) format:
R<range>,C<states>,S<survival list>,B<birth list>,N<neighborhood>

R5,C0,S33-57,B34-45

If people are looking at the original LtL publications then they can use
formats 1 or 2 above (format 1 is used in Golly's LtL Pattern examples).

For people coming from range 1 outer totalistic rules the HROT format can
be more intuitive:

B3/S23 -> R1,C0,S2-3,B3

Chris

Chris Rowett wrote:

> I've recently committed several improvements to Golly's Larger than
> Life algo. I'm still testing but it's now in a state where I'd
> appreciate feedback.
>
> What's new?
> 1. Support for HROT format rule strings
>
> R<range>,C<states>,S<survival counts>,B<birth counts>,N<neighborhood>
>
> Differences from LtL format:
> a) There is no M (for middle cell) parameter so rules are always outer-totalistic

Does this mean that the neighbor count for survival does not include the central cell?  If so, that's likely to cause confusion, since published articles about LtL do include it.  For example, some of Kellie Evans's papers discuss "Bosco's rule", which is described by range 5, survival range 34-58, and birth range 34-45.  In outer totalistic form it would have to be entered as "R5,C0,S33-57,B34-45".

Dean Hickerson

October will be the 50th anniversary of Martin Gardner's Sci Am article
announcing CGOL, so it would be nice if we could release Golly 4.0
during that month.  (For an added bonus, Oct 21st is MG's birthdate.)

Here is a list of the tasks we need to complete (in brackets are the
people who will most likely have to do them!):

* Change wxpython.cpp to use Python 3's stable API.  (Scorbie?
Are you still working on this? I've got Python 3 working with Golly
on all three platforms so this doesn't seem all that critical.)

* Update the Python-related docs: Build.html, License.html, python.html,
changes.html.  (Scorbie? Anybody else who wanted Python 3!)

* Update the configure build for Python 3. (Maks?  My inclination is to
remove the configure stuff.  Too many people have reported problems
trying to use it.  Building via makefile-gtk seems much simpler.)

* Write the docs for the new Super algo. (Dave and/or Chris?)

* Write the docs for the new LtL rules. (Chris?)

* Update the version number to 4.0b1, do 64-bit builds for each platform
and announce in the forums. (Me)

* Let forum users test 4.0b1 for at least a week, then do 4.0 builds
and upload to sourceforge. (Me)

Any other tasks I've forgotten?

Andrew

>
> I've recently committed several improvements to Golly's Larger than Life
> algo. ...
>

Fantastic stuff -- thanks Chris!


> Neighborhood examples can be seen here:
> https://lazyslug.com/lifeview/plugin/neighbourhoods.html
>

Not 100% sure this is a bug but Golly fails to load the custom R11 pattern
at the bottom of that page.  LtL reports "missing S values".

Andrew

I've recently committed several improvements to Golly's Larger than Life
algo. I'm still testing but it's now in a state where I'd appreciate
feedback.

What's new?
1. Support for HROT format rule strings

R<range>,C<states>,S<survival counts>,B<birth counts>,N<neighborhood>

Differences from LtL format:
a) There is no M (for middle cell) parameter so rules are always
outer-totalistic
b) You can specify arbitrary ranges of counts for S and B (e.g.
S2,4,6-11,15-21,33)
c) You can omit ,NM if the neighborhood is Moore (the default)

Canonical form will be in the same format that the rule was specified (LtL
or HROT).

2. Many new <neighborhoods> (valid both for LtL and HROT format rules):
a) Square grid neighborhoods:
i) 'B' for Checkerboard
ii) '+' for Cross
iii) '2' for Euclidean (L2)
iv) 'G' for Gaussian
v) '#' for Hash
vi) 'X' for Saltire
vii) '*' for Star
b) Hexagonal grid neighborhoods:
i) 'A' for Asterisk
ii) 'H' for Hexagonal
iii) 'T' for Tripod
c) Triangular grid neighborhoods:
i) 'L' for Triangular
d) All grids types:
i) '@' for Custom
ii) 'W' for Weighted (with optional state weights)

Neighborhood examples can be seen here:
https://lazyslug.com/lifeview/plugin/neighbourhoods.html

Custom neighborhood is 'N@' followed by hex digits in the CoordCA format
without the leading 1:
https://www.conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=1600#p99638

Explanation of Weighted neighborhood is here:
https://www.conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=1675#p102131
and here for state weights:
https://www.conwaylife.com/forums/viewtopic.php?f=3&t=1622&start=1675#p102966

3. B0 emulation
All rules now support B0 emulation (bounded and unbounded grids) for
non-strobing simulation.

Thanks,
Chris

Chris:

In general the canonical form of a rule string is always less than or equal
> to the length of the original rule string.
>
> One exception is if a bounded grid has been defined in an abbreviated
> form: e.g. ":T100" which would then be expanded to ":T100,100".
>
> 1) Are there any other exceptions?
>

Not that I can think of.

2) Would it make sense that the canonical form of a bounded grid is ":Tn"
> where the definition is ":Tn,n" (and likewise for other topologies)?
>

Probably too late to change that now -- it would break existing scripts
that assume the canonical
form specifies both bounds (I know I have a few such scripts).  In fact the
decision to explicitly
specify both bounds was made precisely because it's easier for scripts to
parse. (That's also
why the canonical form of all rules is case sensitive.)

Andrew

In general the canonical form of a rule string is always less than or equal
to the length of the original rule string.

One exception is if a bounded grid has been defined in an abbreviated form:
e.g. ":T100" which would then be expanded to ":T100,100".

1) Are there any other exceptions?

2) Would it make sense that the canonical form of a bounded grid is ":Tn"
where the definition is ":Tn,n" (and likewise for other topologies)?

Chris

>
> Makes sense to me, though maybe some testing should be done first.  If
>>> there's a defined SomethingHistory or SomethingSuper rule in the Rules
>>> folder, will Golly use that rule definition in preference to the
>>> standard History/Super algo behavior?
>>>
>>
Also it depends on "Something" being a valid QuickLife rule.
For example if the rule is called "[R]History" then the Super
algo will ignore it. But if it's called "B36S23History" then
either the Super algo or RuleLoader algo can run it.


>> No, it will use the Super algo in preference to any .rule file. ...
>>
>
> That's not quite correct -- it depends on whether or not the current algo
> is
> RuleLoader at the time Golly loads a pattern or sets a rule.  Golly always
> tries to load a pattern (or set a rule) using the *current* algo first.
> If that fails then it tries all the other algos in the order they appear
> in the
> Set Algorithm menu.
>

Ah! This would explain some of the behaviour I saw during testing. Thanks :)

PS. We should definitely remove LifeHistory.rule from Rules.
>

OK will do.

Oops -- replace "LIfeSuper" with LifeSuper.

Andrew

>
>
> Makes sense to me, though maybe some testing should be done first.  If
>> there's a defined SomethingHistory or SomethingSuper rule in the Rules
>> folder, will Golly use that rule definition in preference to the
>> standard History/Super algo behavior?
>>
>
> No, it will use the Super algo in preference to any .rule file. ...
>

That's not quite correct -- it depends on whether or not the current algo is
RuleLoader at the time Golly loads a pattern or sets a rule.  Golly always
tries to load a pattern (or set a rule) using the *current* algo first.
If that fails then it tries all the other algos in the order they appear in
the
Set Algorithm menu.

For example, let's say you have a pattern that specifies LIfeSuper as the
rule.
If the current algo is QuickLife when you open the pattern, Golly will
automatically switch to the Super algo.  If, however, the current algo is
RuleLoader when you open the pattern, Golly will look for LifeSuper.rule
in your rules folder first, then in the Rules folder.  So there is the
potential
for confusion if a user has some xxxSuper.rule that specifies different
behavior to the Super algo.

I've no idea how likely such problems might be.  If they *are* likely to
occur then we should definitely warn people.  And maybe supply a script
that scans a user's rules folder and lists any xxxSuper.rule files that
contain a TABLE/TREE section.  (There's no problem if xxxSuper.rule
has no TABLE/TREE section and is just being used to override the
default colors or icons.)

PS. We should definitely remove LifeHistory.rule from Rules.

Andrew