golly-test Mailing List for Golly

On Tue, 29 Nov 2011 14:27:56 +0000
Tim Hutton <tim...@gm...> wrote:

> I can build 64-bit Golly.exe using CMake with Visual Studio. It seems
> to configure everything correctly, and it runs. But I can't make a
> bindist from CMake yet (it's on my tasklist!).

The point is probably moot, but I'd like to point out that the
autoconf stuff also works on Windows with the GNU toolchain, so that's
always an option.

(I don't know if there are any material differences between the
binaries produced by different toolchains on Windows.)

 - Maks.

On Thu, 1 Dec 2011 09:02:34 +1100
Andrew Trevorrow <an...@tr...> wrote:

> Oops, I just noticed that CMakeLists.txt is missing because
> it wasn't included in the SRCFILES list in makefile-*.
> I've committed the corrected makefiles so can you please build
> the tar ball again.

Ah, good point!  I use the autotools to create the source tarball (that
was the point of having me do it, right?) so the SRCFILES in the static
Makefiles don't apply.  Instead, it's autogen.sh that builds a list of
files to include in the distribution.  I've updated it to include
CMakeLists.txt and checked that all relevant files from CVS are indeed
included in the tarball.

I also noticed you bumped the version number to 2.3 in all files except
configure.ac.  It's not a problem for me to do it, but I thought I
should mention it in case you didn't realize there was a version number
in this file too.

Anyway, I've updated the file at:

  http://hell.student.utwente.nl/files/golly-2.3-src.tar.gz

New MD5: 20495bafe63f4f3f1807a5c52a280ba5.

 - Maks.

Maks:

> Here you go: 
> 
>   http://hell.student.utwente.nl/files/golly-2.3-src.tar.gz

Oops, I just noticed that CMakeLists.txt is missing because
it wasn't included in the SRCFILES list in makefile-*.
I've committed the corrected makefiles so can you please build
the tar ball again.  Sorry about that!

Andrew

Tim:

> I can build 64-bit Golly.exe using CMake with Visual Studio. It seems
> to configure everything correctly, and it runs. But I can't make a
> bindist from CMake yet (it's on my tasklist!). I could switch this
> working Golly.exe for the one in the bindist generated from nmake I
> suppose. Is that worth doing, as a temporary solution?

Yep, good idea.

Tim has sent me his 64-bit build and it's available here if anybody
wants to try it:

http://www.trevorrow.com/golly/golly-2.3-win-x64.zip

Andrew

I can attest, the flashing (or "strobing") is pretty ghastly. You can see
what it would look like by holding down the space bar in Golly.

It would be easy to write a script that takes a rule like "B023/S345" and
generates a RuleTable with 3 states that properly displays the evolution of
a pattern that "flashes". Just turn states 0 and 1 into states 1 and 2, and
don't use state 0 for anything.

As an added bonus, in RuleTable you can edit the colours to something with
less contrast (like maybe blue and green) to the strobing is less severe.

On Sat, Nov 26, 2011 at 04:47, Dean Hickerson <dea...@ya...>wrote:

> > One of the main reasons we emulate B0 rules is to avoid the horrible
> strobing effect that would
> > result from doing the above.
>
> Yeah, that would be annoying when watching a pattern evolve for a while.
>  When I was trying to find an example of that oscar bug, I was only looking
> at a few generations and kept having to think "that cell looks dead, but
> this in gen 1, so it's really alive", etc.  Finally I gave up on trying to
> construct an example myself and wrote a script to search for one instead.
>
> Oh well, I can always write a script to advance 1 gen and change the
> colors if I ever need it.


-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

I've built the 64-bit Linux version. I'll send it to you. On a 64-bit
OS it builds by default.

timhutton@deb2:~/golly/Golly-2.3-src/src$ uname -m
x86_64
timhutton@deb2:~/golly/Golly-2.3-src/src$ make -f makefile-gtk BUILD=Release
...
timhutton@deb2:~/golly/Golly-2.3-src/src$ file golly
golly: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not
stripped
timhutton@deb2:~/golly/Golly-2.3-src/src$ make -f makefile-gtk
BUILD=Release bindist
...

I haven't had so much luck on Windows. I followed these instructions,
which were useful:
http://software.intel.com/en-us/articles/configuring-microsoft-visual-studio-for-64-bit-applications/
http://software.intel.com/en-us/articles/building-intel-64-architecture-applications-in-microsoft-visual-studio/

Then from a Win64 Visual Studio command prompt:
(after updating the python perl and wx folders to their 64 bit versions)
nmake -f makefile-win BUILD=release WIN64=1
nmake -f makefile-win BUILD=release WIN64=1 bindist

These commands succeed, but the resulting exe files don't run,
complaining of 0xc000007b which is something to do with mixed 32-bit
and 64-bit DLLs. Dependency Walker tells me that Golly is trying to
load a 32-bit version of comctl32.dll. I'm stuck now - any ideas?

I can build 64-bit Golly.exe using CMake with Visual Studio. It seems
to configure everything correctly, and it runs. But I can't make a
bindist from CMake yet (it's on my tasklist!). I could switch this
working Golly.exe for the one in the bindist generated from nmake I
suppose. Is that worth doing, as a temporary solution?

Tim

On 29 November 2011 09:38, Tim Hutton <tim...@gm...> wrote:
> Thanks Andrew. I haven't found any problems with the Windows build.
>
> I'm on 64-bit Windows, I'll see if I can make a 64 bit build.
>
> On 29 November 2011 06:35, Andrew Trevorrow <an...@tr...> wrote:
>> Here are the Golly 2.3 release candidates:
>>
>> http://www.trevorrow.com/golly/golly-2.3-win.zip      (for Windows)
>> http://www.trevorrow.com/golly/golly-2.3-gtk.tar.gz   (for Linux)
>> http://www.trevorrow.com/golly/golly-2.3-mac.zip      (for Mac OS 10.6/7)
>> http://www.trevorrow.com/golly/golly-2.3-mac104.zip   (for Mac OS 10.4/5)
>>
>> If there are no major problems I'll upload these to sf in a couple of days.
>>
>> Maks, can you please build a source distribution?
>>
>> I'm wondering if we should also provide 64-bit builds for Win & Linux.
>> Someone on conwaylife recently asked for a 64-bit Golly (didn't say
>> which platform but I'm guessing Windows).  It's going to become
>> increasingly common for people to have systems with more than 8GB of
>> RAM so now might be a good time to provide a 64-bit Golly.
>> The only problem is I'm not quite sure how to create 64-bit builds
>> on Win/Linux, so if someone could do that it would be nice!
>>
>> Andrew
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Golly-test mailing list
>> Gol...@li...
>> https://lists.sourceforge.net/lists/listinfo/golly-test
>
>
>
> --
> Tim Hutton - http://www.sq3.org.uk - http://profiles.google.com/tim.hutton/



-- 
Tim Hutton - http://www.sq3.org.uk - http://profiles.google.com/tim.hutton/

Thanks Andrew. I haven't found any problems with the Windows build.

I'm on 64-bit Windows, I'll see if I can make a 64 bit build.

On 29 November 2011 06:35, Andrew Trevorrow <an...@tr...> wrote:
> Here are the Golly 2.3 release candidates:
>
> http://www.trevorrow.com/golly/golly-2.3-win.zip      (for Windows)
> http://www.trevorrow.com/golly/golly-2.3-gtk.tar.gz   (for Linux)
> http://www.trevorrow.com/golly/golly-2.3-mac.zip      (for Mac OS 10.6/7)
> http://www.trevorrow.com/golly/golly-2.3-mac104.zip   (for Mac OS 10.4/5)
>
> If there are no major problems I'll upload these to sf in a couple of days.
>
> Maks, can you please build a source distribution?
>
> I'm wondering if we should also provide 64-bit builds for Win & Linux.
> Someone on conwaylife recently asked for a 64-bit Golly (didn't say
> which platform but I'm guessing Windows).  It's going to become
> increasingly common for people to have systems with more than 8GB of
> RAM so now might be a good time to provide a 64-bit Golly.
> The only problem is I'm not quite sure how to create 64-bit builds
> on Win/Linux, so if someone could do that it would be nice!
>
> Andrew
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test



-- 
Tim Hutton - http://www.sq3.org.uk - http://profiles.google.com/tim.hutton/

Here are the Golly 2.3 release candidates:

http://www.trevorrow.com/golly/golly-2.3-win.zip      (for Windows)
http://www.trevorrow.com/golly/golly-2.3-gtk.tar.gz   (for Linux)
http://www.trevorrow.com/golly/golly-2.3-mac.zip      (for Mac OS 10.6/7)
http://www.trevorrow.com/golly/golly-2.3-mac104.zip   (for Mac OS 10.4/5)

If there are no major problems I'll upload these to sf in a couple of days.

Maks, can you please build a source distribution?

I'm wondering if we should also provide 64-bit builds for Win & Linux.
Someone on conwaylife recently asked for a 64-bit Golly (didn't say
which platform but I'm guessing Windows).  It's going to become
increasingly common for people to have systems with more than 8GB of
RAM so now might be a good time to provide a 64-bit Golly.
The only problem is I'm not quite sure how to create 64-bit builds
on Win/Linux, so if someone could do that it would be nice!

Andrew

I'm sorry about this unsolicited and irrelevant email.

Google+ made it look like golly-test was already on Google+ and I could
follow it. What it was actually doing was suggesting I sent an invitation
to an item in my email contacts list. When I clicked the link, it sent this
message to the list.

Again, I apologize

- Robert

On Mon, Nov 28, 2011 at 13:42, Google+ <nor...@pl...>
wrote:
> Robert Munafo added you to his circles and invited you to join Google+.
> Join Google+
> Google+ makes sharing on the web more like sharing in real life.
> Circles
> [...]

--
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Robert Munafo added you to his circles and invited you to join Google+.

Click here to get started with Google+:  
https://plus.google.com/_/notifications/ngemlink?&emid=CODBhvL92awCFYm-5godpUsAAA&path=%2Fwelcome%3Fgpinv%3DAMIXal_TMTQgopUXaf47DHETi4i8W0c8vIeOQcuY45mu5bL7tF5s8pbgbkpBgLKLtR_n_p2fGJxWdqwD6d30HKIUb68KoXWsK_ZC45EU6-4u2q0abDfgm3g&dt=1322505763661

Google+ makes sharing on the web more like sharing in real life.
------------------------
You received this message because Robert Munafo invited  
gol...@li... to join Google+. Click here to unsubscribe  
from these emails:  
https://plus.google.com/_/notifications/ngemlink?&emid=CODBhvL92awCFYm-5godpUsAAA&path=%2F_%2Fnonplus%2Femailsettings%3Fgpinv%3DAMIXal_TMTQgopUXaf47DHETi4i8W0c8vIeOQcuY45mu5bL7tF5s8pbgbkpBgLKLtR_n_p2fGJxWdqwD6d30HKIUb68KoXWsK_ZC45EU6-4u2q0abDfgm3g%26est%3DADH5u8UaXsK9eCHl5jqhNUFmWkOlLRaR2KSieI3Kj9NBCrZrI6D3cfct9SGYDJGn99_kz985ugNG11PF1p6sLnxUPKCq-VxQYFqelON4O7KlOmYYEc2Xn5NPJ98g9j45SU6Lh7B3K5jYcBRHrnK_ApkwuqltPILeekv-T1Gq8jpJBnMY4ZHFfSg%26hl%3Den&dt=1322505763661

I've just committed changes that should prevent any crashes due to
a table/tree file being deleted or becoming invalid in some way.
It was a lot messier than I thought -- there were quite a few places
where I had assumed it was safe to call setrule() and not check for
an error message.  If an error does occur then Golly will now switch
to the current algo's default rule.

Maks, I've left in the changes you made to ruletable_algo.cpp.
They are probably no longer necessary but it won't hurt to
leave them in as an extra precaution.  I did however remove
the UpdateAlgo() call you added to wxrule.cpp as there's no real
need to check the current rule's validity when the Set Rule dialog
opens.  It's more important to ensure the rule is valid when
the dialog closes (even if the user hits Cancel).

Later today or maybe tomorrow I'll build the final 2.3 candidates.

Andrew

> One of the main reasons we emulate B0 rules is to
> avoid the horrible strobing effect that would
> result from doing the above.

Yeah, that would be annoying when watching a pattern evolve for a while.  When I was trying to find an example of that oscar bug, I was only looking at a few generations and kept having to think "that cell looks dead, but this in gen 1, so it's really alive", etc.  Finally I gave up on trying to construct an example myself and wrote a script to search for one instead.

Oh well, I can always write a script to advance 1 gen and change the colors if I ever need it.

Dean:

> Speaking of B0 rules, I thought of something that might make them easier to view:  Golly lets you choose whether to display white on black or black on white.  If B0 rules could be displayed one way in even gens and the other way in odd gens, it might be easier to see which cells are alive.  (But I haven't spent much time with such rules; maybe someone who has can point out why that would be a bad idea.)

One of the main reasons we emulate B0 rules is to avoid the horrible
strobing effect that would result from doing the above.
It would also cause confusion when editing, and the population count
would no longer make sense (unless we display "infinity" on odd gens).

The B0 emulation *is* an ugly hack, but I still think it's the least
ugly way to let people explore such rules.

Andrew

> Appended below is a new version of oscar.py that should
> fix both bugs.  Give it a try and let me know how it goes

It seems fine.  Thanks.


Speaking of B0 rules, I thought of something that might make them easier to view:  Golly lets you choose whether to display white on black or black on white.  If B0 rules could be displayed one way in even gens and the other way in odd gens, it might be easier to see which cells are alive.  (But I haven't spent much time with such rules; maybe someone who has can point out why that would be a bad idea.)

Dean:

> I've noticed two bugs in the scripts oscar.py and oscar.pl that result from their handling of outer-totalistic rules with B0.
> 
> First, to check for such rules, the script just looks at the beginning and end of the rule name, so if I create a rule table and give it a name that starts with "B0" and doesn't end with "8", oscar will claim that a still-life has period 2 instead of 1.

Yep, we can fix that by checking for "/" (that character cannot exist in
a table/tree file name).

> Second, it's possible for a pattern in an actual B0 rule to look the same in generations G and G+m, where m is odd, without being periodic.  ...

Good catch.  Appended below is a new version of oscar.py that should
fix both bugs.  Give it a try and let me know how it goes -- if no
probs then I'll make similar changes to oscar.pl.

(PS. I haven't time to do much work on Golly over the last couple of
weeks but I hope to soon fix that other problem you reported about
crashes due to errors in a rule table.)

Andrew

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

# Oscar is an OSCillation AnalyzeR for use with Golly.
# Author: Andrew Trevorrow (an...@tr...), March 2006.
# Modified to handle B0-and-not-S8 rules, August 2009.

# This script uses Gabriel Nivasch's "keep minima" algorithm.
# For each generation, calculate a hash value for the pattern.  Keep all of
# the record-breaking minimal hashes in a list, with the oldest first.
# For example, after 5 generations the saved hash values might be:
# 
#   8 12 16 24 25,
# 
# If the next hash goes down to 13 then the list can be shortened:
# 
#   8 12 13.
# 
# When the current hash matches one of the saved hashes, it is highly likely
# the pattern is oscillating.  By keeping a corresponding list of generation
# counts we can calculate the period.  We also keep lists of population
# counts and bounding boxes; they are used to reduce the chance of spurious
# oscillator detection due to hash collisions.  The bounding box info also
# allows us to detect moving oscillators (spaceships/knightships).

import golly as g
from glife import rect, pattern
from time import time

# --------------------------------------------------------------------

# initialize lists
hashlist = []        # for pattern hash values
genlist = []         # corresponding generation counts
poplist = []         # corresponding population counts
boxlist = []         # corresponding bounding boxes

# --------------------------------------------------------------------

def show_spaceship_speed(period, deltax, deltay):
   # we found a moving oscillator
   if period == 1:
      g.show("Spaceship detected (speed = c)")
   elif (deltax == deltay) or (deltax == 0) or (deltay == 0):
      speed = ""
      if (deltax == 0) or (deltay == 0):
         # orthogonal spaceship
         if (deltax > 1) or (deltay > 1):
            speed += str(deltax + deltay)
      else:
         # diagonal spaceship (deltax == deltay)
         if deltax > 1:
            speed += str(deltax)
      g.show("Spaceship detected (speed = " + speed + "c/" +str(period) + ")")
   else:
      # deltax != deltay and both > 0
      speed = str(deltay) + "," + str(deltax)
      g.show("Knightship detected (speed = " + speed + "c/" + str(period) + ")")

# --------------------------------------------------------------------

def oscillating():
   # return True if the pattern is empty, stable or oscillating
   
   # first get current pattern's bounding box
   prect = g.getrect()
   pbox = rect(prect)
   if pbox.empty:
      g.show("The pattern is empty.")
      return True
   
   # get current pattern and create hash of "normalized" version -- ie. shift
   # its top left corner to 0,0 -- so we can detect spaceships and knightships
   ## currpatt = pattern( g.getcells(prect) )
   ## h = hash( tuple( currpatt(-pbox.left, -pbox.top) ) )

   # use Golly's hash command (3 times faster than above code)
   h = g.hash(prect)

   # check if outer-totalistic rule has B0 but not S8
   rule = g.getrule().split(":")[0]
   hasB0notS8 = rule.startswith("B0") and (rule.find("/") > 1) and not rule.endswith("8")
   
   # determine where to insert h into hashlist
   pos = 0
   listlen = len(hashlist)
   while pos < listlen:
      if h > hashlist[pos]:
         pos += 1
      elif h < hashlist[pos]:
         # shorten lists and append info below
         del hashlist[pos : listlen]
         del genlist[pos : listlen]
         del poplist[pos : listlen]
         del boxlist[pos : listlen]
         break
      else:
         # h == hashlist[pos] so pattern is probably oscillating, but just in
         # case this is a hash collision we also compare pop count and box size
         if (int(g.getpop()) == poplist[pos]) and \
            (pbox.wd == boxlist[pos].wd) and \
            (pbox.ht == boxlist[pos].ht):
            period = int(g.getgen()) - genlist[pos]
            
            if hasB0notS8 and (period % 2 > 0) and (pbox == boxlist[pos]):
               # ignore this hash value because B0-and-not-S8 rules are
               # emulated by using different rules for odd and even gens,
               # so it's possible to have identical patterns at gen G and
               # gen G+p if p is odd
               return False
            
            if period == 1:
               if pbox == boxlist[pos]:
                  g.show("The pattern is stable.")
               else:
                  show_spaceship_speed(1, 0, 0)
            elif pbox == boxlist[pos]:
               g.show("Oscillator detected (period = " + str(period) + ")")
            else:
               deltax = abs(boxlist[pos].x - pbox.x)
               deltay = abs(boxlist[pos].y - pbox.y)
               show_spaceship_speed(period, deltax, deltay)
            return True
         else:
            # look at next matching hash value or insert if no more
            pos += 1
   
   # store hash/gen/pop/box info at same position in various lists
   hashlist.insert(pos, h)
   genlist.insert(pos, int(g.getgen()))
   poplist.insert(pos, int(g.getpop()))
   boxlist.insert(pos, pbox)

   return False

# --------------------------------------------------------------------

def fit_if_not_visible():
   # fit pattern in viewport if not empty and not completely visible
   r = rect(g.getrect())
   if (not r.empty) and (not r.visible()): g.fit()

# --------------------------------------------------------------------

g.show("Checking for oscillation... (hit escape to abort)")

oldsecs = time()
while not oscillating():
   g.run(1)
   newsecs = time()
   if newsecs - oldsecs >= 1.0:     # show pattern every second
      oldsecs = newsecs
      fit_if_not_visible()
      g.update()

fit_if_not_visible()

I've noticed two bugs in the scripts oscar.py and oscar.pl that result from their handling of outer-totalistic rules with B0.

First, to check for such rules, the script just looks at the beginning and end of the rule name, so if I create a rule table and give it a name that starts with "B0" and doesn't end with "8", oscar will claim that a still-life has period 2 instead of 1.

Second, it's possible for a pattern in an actual B0 rule to look the same in generations G and G+m, where m is odd, without being periodic.  The script deals with the case m=1, but not with larger m.  For example, oscar says that the pattern below has period 3, because gens 0 and 3 look alike.  In fact the pattern has period 2 starting in gen 2.

x = 3, y = 3, rule = B08/S0
3o$obo$3o!

(I'm not actually studying B0 rules.  I was modifying my copy of oscar.py so it would tell me the direction of a spaceship along with its speed, and happened to notice the B0 stuff.  I thought there might be a problem, but it took me a few hours to find an example where it failed.)

Dean Hickerson

ty

A Computer Science (including CA) or Gaming topic.


On 15 November 2011 12:16, Mark Jeronimus <mar...@gm...> wrote:

> Dear Alan,
>
> This literature review, does it havve to be about a certain subject? Just
> asking out of the blue doesn't help much. Does it have to be about cellular
> automata, or can it also be another computing science subject, or
> psychology for that matter?
>
> -Mark
>
> On Tue, Nov 15, 2011 at 1:08 PM, Alan Tennant <ala...@gm...> wrote:
>
>> I've got to do a literature review of a paper published in a journal.
>> Anyone here got anything interesting?
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> Golly-test mailing list
>> Gol...@li...
>> https://lists.sourceforge.net/lists/listinfo/golly-test
>>
>>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>
>

Dear Alan,

This literature review, does it havve to be about a certain subject? Just
asking out of the blue doesn't help much. Does it have to be about cellular
automata, or can it also be another computing science subject, or
psychology for that matter?

-Mark

On Tue, Nov 15, 2011 at 1:08 PM, Alan Tennant <ala...@gm...> wrote:

> I've got to do a literature review of a paper published in a journal.
> Anyone here got anything interesting?
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>
>

I've got to do a literature review of a paper published in a journal.
Anyone here got anything interesting?

> I assume there's some fancy automated way of unsubscribing, but I don't
> know what it is.

The info is in each message header.

Either visit this page and follow the instructions:
<" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/golly-test>

Or even easier, send this message from your subscribed address:
<mailto:gol...@li...?subject=unsubscribe>

Andrew

I assume there's some fancy automated way of unsubscribing, but I don't
know what it is.

Dean:

> So what I described as a bug is actually the correct behaviour;
> sorry about that!

No probs -- phantom bugs are much easier to fix!

> Maybe you could change the text in the Prefs > File window to say
> "On opening a pattern file or the clipboard:". ...

Good suggestion -- will do.

Andrew

Andrew Trevorrow wrote:

> I can't reproduce this problem, so maybe it was related to the
> shift key bug.  Does it happen if you select Open Clipboard from
> the File menu, or only when you type shift-cmd-O?

It happens in both cases.

> Also, what is your preferred cursor on opening a pattern file
> (set in Prefs > File)?  The initial setting is Zoom In so I
> assume you must have changed that?

It was still set to Zoom In; I'm embarrassed to say that I'd never noticed that I could change that.  Now I've set it to No Change, and the problem that I described has gone away.

So what I described as a bug is actually the correct behaviour; sorry about that!

Maybe you could change the text in the Prefs > File window to say "On opening a pattern file or the clipboard:".  I wouldn't have guessed that it applies to both, even if I had been aware that I could change it.

Dean Hickerson

Dean:

> The Open Clipboard command sometimes sets the cursor mode to Zoom In.
> I think it only happens in cases when the command brings up the
> "Save changes" dialog box.

I can't reproduce this problem, so maybe it was related to the
shift key bug.  Does it happen if you select Open Clipboard from
the File menu, or only when you type shift-cmd-O?

Also, what is your preferred cursor on opening a pattern file
(set in Prefs > File)?  The initial setting is Zoom In so I assume
you must have changed that?

Andrew

Tom:

> This can be fixed in one of two ways:
> 
> 1.  Adding a "validaterule()" that does not update any of the fields, but
>      checks that the rule is valid and returns go/no-go.
> 
> 2.  Making the "setrule" create a new temporary ruletable and try the
>      setrule() on that (setrule_internal()); if it succeeds, copy over the
>      relevant fields and return, else delete the temporary rule table and
>      return the error message.

Hmm, I don't think we need these extra complications.  setrule() already
does the necessary validation -- we just need to make sure we check its
return value in a few cases where it's possible a once-valid table/tree
file might have been deleted or incorrectly edited.

BTW, I found a new rule-related bug while testing things.
It turned out to be due to another case where I forgot that qlife/hlife
share global rule tables, so I'm going to remove the global_liferules
stuff as we discussed a while back.  It means that every qlife/hlife
instance will have its own 128K of rule data which is a bit of a waste,
but it's much safer and simpler.

Andrew