golly-test Mailing List for Golly

Tom/Jason,

I've committed the Preferences dialog changes.  Let me know if there
are any glitches on XP.  If you see poor spacing or other cosmetic
problems, please send me a screenshot of the dialog.

I decided to plonk it in the File menu -- the prefs are saved in a file
so that's a good a reason as any!  Hitting comma opens the dialog.

Oh, and note that I had to add another wx lib (adv) to the Mac/Win
makefiles, so the exe has grown even fatter. :(

Andrew

>Mostly to Alan Hensel:
>I suspect you may be even shorter of spare time than I am these days.  Any immediate plans for sorting through and updating lifebc/lifep, or should I consider those fair game as well?
>  
>
That's true, I'm very short on time, and it's going to get worse before 
it gets better. I'm preparing for my 2-week vacation, Nov 3 - 15. I 
suspect I won't be collecting any Life patterns in London or Paris. (I 
can just see myself walking through the Louvre, thinking that if these 
French people had more refined taste, they'd hang some Life patterns. 
Heh. It's funny cuz it's true.)

Don't forget that Primes update that was recently posted to the Life 
mailing list. I'd like to make things as different as possible, to 
encourage biodiversity.

Alan

> On the Mac there is a standard place for the "Preferences..."
>  item (in the app menu) and a standard shortcut (cmd-comma).
>
> Where's the normal place in a Win/Linux app?

Can't speak for Linux, but on Windows I'm trained to look for Tools > Op=
tions if there's a Tools menu (Microsoft Office, IE, Firefox, etc.) If t=
hat doesn't pan out, I might check for File > Preferences (Lotus Notes h=
as this, but then it puts most things where no one would think of lookin=
g for them) or for a completely separate Preferences / Settings / Config=
ure menu, with separate menu items for different classes of preferences.=


I wouldn't think to look at the end of the Edit menu for quite a while..=
. obviously preferences are generally editable, but I think of the Edit =
menu as a gathering of possible operations *on application documents* --=
 patterns in this case.  Undo, redo, cut, copy, paste, delete, select al=
l, find, replace, etc. are standard fare for an Edit menu, but I'd have =
to mentally re-define "Edit" before "Preferences" would make sense there=
.

Keep the cheer,


Dave


P.S.  I haven't forgotten about my pattern-collecting responsibilities, =
but a couple of extra-busy weeks have just gone by.  I'll take another r=
un at the project sometime this week and/or next week.

Mostly to Alan Hensel:
I suspect you may be even shorter of spare time than I am these days.  A=
ny immediate plans for sorting through and updating lifebc/lifep, or sho=
uld I consider those fair game as well?

On the Mac there is a standard place for the "Preferences..." item
(in the app menu) and a standard shortcut (cmd-comma).

Where's the normal place in a Win/Linux app?  At the end of the
Edit menu?  Is there a standard ctrl-<key> for it?  (Hopefully
one we haven't already assigned!)

Andrew

> Gabriel's the only one who caught it, but there was a subtle
> bug in the hashlife stuff where if the user attempted to change
> speeds, *while* a change speed request was being executed,
> *and* this change speed request met certain conditions, the
> hashlife algorithm would get confused and advance at the
> incorrect speed.
> 
> This is now fixed.

Excellent!

> I have two more bugs to fix . . . I hope we can roll out a
> release within the next week or two so these go out.

Yep, we have plenty of nice new features to offer, and some
important bug fixes.  When I finish the Preferences dialog
(hopefully in a few days) I'll be happy to do a release,
so maybe this weekend if all goes well.

Andrew

>>>* On Windows at least, window titles normally have the filename
>>> first, and the application last. E.g. instead of:
>>>  "Golly: broke-lines.rle [B3/S23]"
>>>it should be:
>>>  "broke-lines.rle [B3/S23] - Golly"
>> Hmm, it doesn't seem to be a well-supported standard, at least not on my
>> Win2000 box.  Life32 and Acrobat Reader put the file after the app name.
>> But again, I'm happy to go along with what the majority of Win users
>> think is best.
> 
>> On the Mac there's no need for the app name in window titles because it's
>> always in the menu bar.  I've no idea what the convention is on Linux.
> 
> I guess this is a little less standardized than I thought. Prior to Windows95, the app name always went first, but the order was changed in Win95 so that the document name would be visible on the taskbar. This is important for applications where you might want to open multiple simultaneous instances.
> 
> The large majority of Microsoft apps put the document name first, but inexplicably there are a few, such as Excel, that still put the application name first.
> 
> I'll probably plan to change it for Windows and Linux, and let you decide what it should be for Mac.

Ok by me.  If we get complaints from Win/Linux users it will be easy
enough to change back.  Heck, we could even make it a preference,
although my personal preference would be to remove the app name
completely -- seems a bit unnecessary given that the app icon is
already in the title bar (and task bar).

Andrew

Gabriel's the only one who caught it, but there was a subtle
bug in the hashlife stuff where if the user attempted to change
speeds, *while* a change speed request was being executed,
*and* this change speed request met certain conditions, the
hashlife algorithm would get confused and advance at the
incorrect speed.

This is now fixed.

I have two more bugs to fix . . . I hope we can roll out a
release within the next week or two so these go out.

Thanks!

-tom

Andrew Trevorrow wrote:
> 
> 
>>and for using the mouse wheel to zoom in and out (no matter
>> what the cursor mode).
> 
> Not so sure about this -- isn't the wheel meant to be used for scrolling?
> But again, I've never used one, so do what you think is best!

It's not unusual for the wheel to be used for zooming, in cases like 
this where the document has no single obvious scrolling direction. (The 
wheel is one-dimensional, so you'd only be able to scroll up and down 
anyway.) But if it bothers someone, we could require you to hold down 
the Ctrl key in order to zoom, or have a user preference for what to do 
with the wheel.

[ A minor note about programming mousewheel support in MSWindows: I find 
it difficult to get the wheel to work with complete reliability, when 
the relevant window has scroll bars (as it does in Golly). The problem 
is over-zealous mouse drivers, which will steal the wheel messages and 
convert them to scroll messages if they think your app doesn't 
understand wheel messages. The Intellipoint driver I'm using seems to be 
okay as long as Golly does <<something>> in response to every wheel 
message, but I'm not sure exactly what qualifies as <<something>>. 
Repainting a window? A sure fix is for the user to configure the mouse 
driver to disable its special wheel support for golly.exe. If I can't 
find a way to make it more reliable, we might want to suggest this in 
the documentation. ]


>>* On Windows at least, window titles normally have the filename
>> first, and the application last. E.g. instead of:
>>  "Golly: broke-lines.rle [B3/S23]"
>>it should be:
>>  "broke-lines.rle [B3/S23] - Golly"
> 
> Hmm, it doesn't seem to be a well-supported standard, at least not on my
> Win2000 box.  Life32 and Acrobat Reader put the file after the app name.
> But again, I'm happy to go along with what the majority of Win users
> think is best.

> On the Mac there's no need for the app name in window titles because it's
> always in the menu bar.  I've no idea what the convention is on Linux.

I guess this is a little less standardized than I thought. Prior to 
Windows95, the app name always went first, but the order was changed in 
Win95 so that the document name would be visible on the taskbar. This is 
important for applications where you might want to open multiple 
simultaneous instances.

The large majority of Microsoft apps put the document name first, but 
inexplicably there are a few, such as Excel, that still put the 
application name first.

I'll probably plan to change it for Windows and Linux, and let you 
decide what it should be for Mac.

-- 
Jason Summers
ja...@po...  http://entropymine.com/jason/

Tom Rokicki wrote:
> Cleanup code:  i'm against unnecessary global cleanup code.
> 
> That is, code called when the application exits, only to clean up
> things that the system will clean up for you anyway.
> 
> The reason is it's just more code and more potential for bugs,
> and keeping it consistent with everything allocated can be
> difficult.
> 
> I'm not sure why someone would want to write such code.
> Can you clarify why this would be a good thing?

I think this is one of those things that you will never get everyone to 
agree on. Some discussion here:
<" rel="nofollow">http://blogs.msdn.com/oldnewthing/archive/2005/10/14/481043.aspx>

Note that the issue for normal memory may be different from the issue 
for other system resources like cursors.

Not freeing memory on exit is okay, and may be a good thing sometimes, 
but it does mean that your code can't easily be converted and used in an 
environment where it is not in its own stand-alone application, such as 
an ActiveX control or similar component.


> In particular, what sort of debugger would complain about
> memory leaks on an "exit*'routine---when the program is
> going to go away anyway?

In C/C++ that's really the only time it can do it. When the program is 
still running, it's impossible to tell whether the program has forgotten 
about a particular resource. (You could still argue that it shouldn't do 
it at all.)

-- 
Jason Summers
ja...@po...  http://entropymine.com/jason/

Cleanup code:  i'm against unnecessary global cleanup code.

That is, code called when the application exits, only to clean up
things that the system will clean up for you anyway.

The reason is it's just more code and more potential for bugs,
and keeping it consistent with everything allocated can be
difficult.

I'm not sure why someone would want to write such code.
Can you clarify why this would be a good thing?

In particular, what sort of debugger would complain about
memory leaks on an "exit*'routine---when the program is
going to go away anyway?

-tom

STRINGIFYSIZE . . .

Make it 20; that's safest.  :-)  It will be more robust against future
changes.

The pingponging is in case we do something like:

   sprintf("x %s y %s somethingelse %s\n",
         stringify(x), stringify(y), stringify(z)) ;

-tom

On 10/23/05, Jason Summers <ja...@po...> wrote:
> I should probably split this into separate messages, but I'm lazy.
>
>
> * My builds from CVS are crashing when I zoom very deeply (to the point
> where coordinates are displayed in exponential notation) and move the
> mouse around. It doesn't happen with version 0.91. I found that
> increasing STRINGIFYSIZE --
>    wxgolly.cpp:1567: const int STRINGIFYSIZE =3D 11;
> from 11 to 12 seems to prevent the crash, but I'm not sure if that's the
> right fix.
>
>
> * If it's okay, I'd like to add support for using the right mouse button
> to zoom in the opposite direction (when the cursor is in a zoom mode),
> and for using the mouse wheel to zoom in and out (no matter what the
> cursor mode).
>
> Using the wheel to zoom will probably require a user preference setting
> for deciding the direction in which to zoom. Is there going to be a
> preferences dialog for rarely-changed settings like this?
>
>
> * I noticed this in the TODO file:
>
> A - Need white crosshair cursor for Win app when white-on-black.
>      Or does Win support an XOR cursor mode?
>
> MSWindows definitely supports XOR in cursors. In fact, the standard
> system crosshair cursor (IDC_CROSS) uses it. The question is, why
> doesn't wx use the standard system crosshair cursor? This was easy to
> trace to wx's cursor.cpp file, which contains:
>
>          // Displays as an I-beam on XP, so use a cursor file
> //        {  true, IDC_CROSS                   }, // WXCURSOR_CROSS
>          {  false, _T("WXCURSOR_CROSS")       }, // WXCURSOR_CROSS
>
> This is puzzling. Contrary to the comment, IDC_CROSS does not display as
> an I-beam on XP, at least not under any normal circumstances. I changed
> it to use the commented-out line instead, and now it works fine, and
> uses the standard crosshair cursor, which is visible on both black and
> white backgrounds. (But we probably don't want to be patching wxWindows..=
.)
>
>
> * On Windows at least, window titles normally have the filename first,
> and the application last. E.g. instead of:
>    "Golly: broke-lines.rle [B3/S23]"
> it should be:
>    "broke-lines.rle [B3/S23] - Golly"
>
> That's trivial to change, but I'm not sure what it should be for each
> platform.
>
>
> * My debugger has been complaining about memory leaks, and it doesn't
> look to me like Golly ever tries to free much of the memory and other
> resources (like cursors) it uses. That may not be much of a problem,
> since the OS will probably clean up everything when Golly exits, but
> it's still bad form. I started to write an OnExit function to free
> resources, but this is definitely incomplete:
>
> int MyApp::OnExit()
> {
>         delete pen_ltgray;
>         delete pen_dkgray;
>         delete pen_verydark;
>         delete pen_notsodark;
>         delete brush_yellow;
>         delete brush_blue;
>         delete brush_dkgray;
>         delete curs_pencil;
>         delete curs_cross;
>         delete curs_hand;
>         delete curs_zoomin;
>         delete curs_zoomout;
>         if (statbitmap) delete statbitmap;
>         if (selbitmap) delete selbitmap;
> #ifndef __WXMAC__
>         if(viewbitmap) delete viewbitmap;
> #endif
>         if (curralgo) delete curralgo;
>         return 1;
> }
>
>
> --
> Jason Summers
> ja...@po...  http://entropymine.com/jason/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

Jason:

> * My builds from CVS are crashing when I zoom very deeply (to the point where coordinates are displayed in exponential notation) and move the mouse around. It doesn't happen with version 0.91. I found that increasing STRINGIFYSIZE --
>   wxgolly.cpp:1567: const int STRINGIFYSIZE = 11;
> from 11 to 12 seems to prevent the crash, but I'm not sure if that's the right fix.

Me neither!  Tom wrote the 1st version of that code and I made a few
changes for 0.92 so it's quite possible I clobbered his good intentions!
(I don't really understand why we do that ping-pong buffering.)

Actually, I think STRINGIFYSIZE should be set to 13 because in my Mac app
I can see XY numbers like -8.12345e+307 (ie. 13 chars).  I'm also puzzled
why I can't get the Mac app to crash -- I can zoom right out until the
scale becomes 2^1015:1 and the XY numbers are "nan" (not a number).

Jason, unless Tom recommends otherwise, go ahead and set STRINGIFYSIZE
to 13, just to be safe.


> * If it's okay, I'd like to add support for using the right mouse button to zoom in the opposite direction (when the cursor is in a zoom mode),

Sounds like a good idea to me, although my mouse only has one button
so give more weight to feedback from your fellow Windows users.

> and for using the mouse wheel to zoom in and out (no matter what the cursor mode).

Not so sure about this -- isn't the wheel meant to be used for scrolling?
But again, I've never used one, so do what you think is best!

> Using the wheel to zoom will probably require a user preference setting for deciding the direction in which to zoom. Is there going to be a preferences dialog for rarely-changed settings like this?

Yes, in fact I hope to start on that later today.  There's a nice
wxPropertySheetDialog class that makes it easy to create a multi-panel
prefs dialog (see example app in samples/dialogs).  I recently added
some new prefs parameters (to specify grid spacing, etc) so we really
need a nice way to change these sort of parameters, and soon.


> * I noticed this in the TODO file:
> 
> A - Need white crosshair cursor for Win app when white-on-black.
>     Or does Win support an XOR cursor mode?
> 
> MSWindows definitely supports XOR in cursors. In fact, the standard system crosshair cursor (IDC_CROSS) uses it. The question is, why doesn't wx use the standard system crosshair cursor? This was easy to trace to wx's cursor.cpp file, which contains:
> 
>         // Displays as an I-beam on XP, so use a cursor file
> //        {  true, IDC_CROSS                   }, // WXCURSOR_CROSS
>         {  false, _T("WXCURSOR_CROSS")       }, // WXCURSOR_CROSS
> 
> This is puzzling. Contrary to the comment, IDC_CROSS does not display as an I-beam on XP, at least not under any normal circumstances.

Maybe there was a bug in early releases of XP?

> I changed it to use the commented-out line instead, and now it works fine, and uses the standard crosshair cursor, which is visible on both black and white backgrounds.

Wow, excellent!  You should report that to the wxusers mailing list.
If you can't be bothered subscribing then I'm happy to do it for you.

> (But we probably don't want to be patching wxWindows...)

Sadly, I think we *will* have to do more of that.  wxWidgets is much buggier
than I would prefer and I've had only mixed success when reporting bugs -- some
have been fixed almost immediately and others haven't generated any response.
Fortunately I've been able to find workarounds for most bugs (except in the
X11 app -- we really need an X11 guru on the team!).

For now, I recommend we make the above change and rebuild our wxMSW libs.
Tom, the lines are in <wxdir>/src/msw/cursor.cpp.


> * On Windows at least, window titles normally have the filename first, and the application last. E.g. instead of:
>   "Golly: broke-lines.rle [B3/S23]"
> it should be:
>   "broke-lines.rle [B3/S23] - Golly"

Hmm, it doesn't seem to be a well-supported standard, at least not on my
Win2000 box.  Life32 and Acrobat Reader put the file after the app name.
But again, I'm happy to go along with what the majority of Win users
think is best.

> That's trivial to change, but I'm not sure what it should be for each platform.

On the Mac there's no need for the app name in window titles because it's
always in the menu bar.  I've no idea what the convention is on Linux.


> * My debugger has been complaining about memory leaks, and it doesn't look to me like Golly ever tries to free much of the memory and other resources (like cursors) it uses.

Hmm, I have tried to ensure that memory is freed when it needs to be.
My understanding of the wx docs is that it is NOT necessary to delete
certain objects created by "new".  In particular:

- All child windows (which includes buttons and other controls) in a
  top-level window (ie. frame or dialog) are automatically deleted
  when the frame/dialog is closed.

- All menus (and submenus) are automatically deleted when the menu bar
  to which they are attached is destroyed (ie. when Golly quits).

However, it's quite possible there are memory leaks due to my poor
understanding of wx and/or C++ usage.  In fact I don't even know how
to check for memory leaks using wx and gcc!  Hopefully you can narrow
down when or where the memory leaks might be occurring.

> That may not be much of a problem, since the OS will probably clean up everything when Golly exits, but it's still bad form.

Yep, we have been assuming that the OS will free all memory allocated
by Golly when it quits.  That's certainly the case on the Mac and
(other) Unix platforms.  Isn't it also true on Windows?

I've read elsewhere that it's "bad form" to do this but I've never
seen an explanation!  The only reason I can think of is that it makes
it more difficult to embed the app's code in a larger app -- are
there other reasons?

> I started to write an OnExit function to free resources, but this is definitely incomplete:
> 
> int MyApp::OnExit()
> {
> 	delete pen_ltgray;
> 	delete pen_dkgray;
> 	delete pen_verydark;
> 	delete pen_notsodark;
> 	delete brush_yellow;
> 	delete brush_blue;
> 	delete brush_dkgray;
> 	delete curs_pencil;
> 	delete curs_cross;
> 	delete curs_hand;
> 	delete curs_zoomin;
> 	delete curs_zoomout;
> 	if (statbitmap) delete statbitmap;
> 	if (selbitmap) delete selbitmap;
> #ifndef __WXMAC__
> 	if(viewbitmap) delete viewbitmap;
> #endif
> 	if (curralgo) delete curralgo;
> 	return 1;
> }

Please add this routine if you think it's best.  It actually looks
quite complete to me.

Thanks Jason!

Andrew

I should probably split this into separate messages, but I'm lazy.


* My builds from CVS are crashing when I zoom very deeply (to the point 
where coordinates are displayed in exponential notation) and move the 
mouse around. It doesn't happen with version 0.91. I found that 
increasing STRINGIFYSIZE --
   wxgolly.cpp:1567: const int STRINGIFYSIZE = 11;
from 11 to 12 seems to prevent the crash, but I'm not sure if that's the 
right fix.


* If it's okay, I'd like to add support for using the right mouse button 
to zoom in the opposite direction (when the cursor is in a zoom mode), 
and for using the mouse wheel to zoom in and out (no matter what the 
cursor mode).

Using the wheel to zoom will probably require a user preference setting 
for deciding the direction in which to zoom. Is there going to be a 
preferences dialog for rarely-changed settings like this?


* I noticed this in the TODO file:

A - Need white crosshair cursor for Win app when white-on-black.
     Or does Win support an XOR cursor mode?

MSWindows definitely supports XOR in cursors. In fact, the standard 
system crosshair cursor (IDC_CROSS) uses it. The question is, why 
doesn't wx use the standard system crosshair cursor? This was easy to 
trace to wx's cursor.cpp file, which contains:

         // Displays as an I-beam on XP, so use a cursor file
//        {  true, IDC_CROSS                   }, // WXCURSOR_CROSS
         {  false, _T("WXCURSOR_CROSS")       }, // WXCURSOR_CROSS

This is puzzling. Contrary to the comment, IDC_CROSS does not display as 
an I-beam on XP, at least not under any normal circumstances. I changed 
it to use the commented-out line instead, and now it works fine, and 
uses the standard crosshair cursor, which is visible on both black and 
white backgrounds. (But we probably don't want to be patching wxWindows...)


* On Windows at least, window titles normally have the filename first, 
and the application last. E.g. instead of:
   "Golly: broke-lines.rle [B3/S23]"
it should be:
   "broke-lines.rle [B3/S23] - Golly"

That's trivial to change, but I'm not sure what it should be for each 
platform.


* My debugger has been complaining about memory leaks, and it doesn't 
look to me like Golly ever tries to free much of the memory and other 
resources (like cursors) it uses. That may not be much of a problem, 
since the OS will probably clean up everything when Golly exits, but 
it's still bad form. I started to write an OnExit function to free 
resources, but this is definitely incomplete:

int MyApp::OnExit()
{
	delete pen_ltgray;
	delete pen_dkgray;
	delete pen_verydark;
	delete pen_notsodark;
	delete brush_yellow;
	delete brush_blue;
	delete brush_dkgray;
	delete curs_pencil;
	delete curs_cross;
	delete curs_hand;
	delete curs_zoomin;
	delete curs_zoomout;
	if (statbitmap) delete statbitmap;
	if (selbitmap) delete selbitmap;
#ifndef __WXMAC__
	if(viewbitmap) delete viewbitmap;
#endif
	if (curralgo) delete curralgo;
	return 1;
}


-- 
Jason Summers
ja...@po...  http://entropymine.com/jason/

Welcome aboard Jason -- I've added your name to the Golly Gang list
in the About box.  Much thanks for those VC6 changes!

> BTW, I hope you guys won't be too upset if I check in something that breaks the build for some platforms or compilers. ...

Nah, shouldn't be a problem.  I usually compile all versions at least
once a day so any build problems will be noticed (and fixed) quickly.

A minor request (ie. feel free to ignore it!)...
Whenever you make a significant change, especially to the UI,
please record it in the CHANGES file.  A brief, 1 line description
is enough.  I can then copy that info to Help/changes.html when
a new release is ready.  (Yeah, I know cvs allows comments to be
added when you commit a change, but I find it too slow and
cumbersome to extract those comments from the sf pages.)

Andrew

Check them in, we can't wait.  Broken builds are no problem.

On 10/22/05, Jason Summers <ja...@po...> wrote:
>
> As I've already suggested to Andrew, I'd like to check in some changes
> to make it easier to compile Golly using older compilers like MSVC++ 6.
> There are two issues.
>
> 1. "long long" is a recent standard, and not all compilers support it,
> even if they support 64-bit integers.
>
> I propose to replace "long long" with a macro, say G_INT64, which can be
> defined as needed on different platforms. There doesn't appear to be a
> single header file that is #included by all of Golly's source files, but
> all the files that currently use "long long" do ultimately include
> bigint.h, so I could put the definition there. Something like this:
>
> #ifdef _MSC_VER
> #if _MSC_VER < 1300  // 12xx =3D VC6; 13xx =3D VC7
> #define G_INT64          __int64
> #define G_MAKEINT64(x)   x ## i64
> #define G_INT64_FMT      "I64d"
> #endif
> #endif
>
> #ifndef G_INT64
> #define G_INT64          long long
> #define G_MAKEINT64(x)   x ## LL
> #define G_INT64_FMT      "lld"
> #endif
>
> Files that this will affect are bigint.h, bigint.cpp, qlifealgo.h,
> qlifealgo.cpp.
>
>
> 2. The scope of a variable declared inside a "for" statement is
> different for different compilers. This is a problem when the same
> variable is declared multiple times in the same function, which is done
> in qlifedraw.cpp and hlifedraw.cpp.
>
> So I want to replace code like this:
>
>    for (int i=3D0; i<8; i++) ...
>    ...
>    for (int i=3D0; i<256; i++) ...
>
> with code like this:
>
>    int i;
>    for (i=3D0; i<8; i++) ...
>    ...
>    for (i=3D0; i<256; i++) ...
>
>
> Any objections or comments?
>
> BTW, I hope you guys won't be too upset if I check in something that
> breaks the build for some platforms or compilers. I'll be careful, but
> it's easy to do that in a cross-platform project like this, and I lack
> the expertise and resources needed to ensure that it doesn't happen.
>
> --
> Jason Summers
> ja...@po...  http://entropymine.com/jason/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>

As I've already suggested to Andrew, I'd like to check in some changes 
to make it easier to compile Golly using older compilers like MSVC++ 6. 
There are two issues.

1. "long long" is a recent standard, and not all compilers support it, 
even if they support 64-bit integers.

I propose to replace "long long" with a macro, say G_INT64, which can be 
defined as needed on different platforms. There doesn't appear to be a 
single header file that is #included by all of Golly's source files, but 
all the files that currently use "long long" do ultimately include 
bigint.h, so I could put the definition there. Something like this:

#ifdef _MSC_VER
#if _MSC_VER < 1300  // 12xx = VC6; 13xx = VC7
#define G_INT64          __int64
#define G_MAKEINT64(x)   x ## i64
#define G_INT64_FMT      "I64d"
#endif
#endif

#ifndef G_INT64
#define G_INT64          long long
#define G_MAKEINT64(x)   x ## LL
#define G_INT64_FMT      "lld"
#endif

Files that this will affect are bigint.h, bigint.cpp, qlifealgo.h, 
qlifealgo.cpp.


2. The scope of a variable declared inside a "for" statement is 
different for different compilers. This is a problem when the same 
variable is declared multiple times in the same function, which is done 
in qlifedraw.cpp and hlifedraw.cpp.

So I want to replace code like this:

   for (int i=0; i<8; i++) ...
   ...
   for (int i=0; i<256; i++) ...

with code like this:

   int i;
   for (i=0; i<8; i++) ...
   ...
   for (i=0; i<256; i++) ...


Any objections or comments?

BTW, I hope you guys won't be too upset if I check in something that 
breaks the build for some platforms or compilers. I'll be careful, but 
it's easy to do that in a cross-platform project like this, and I lack 
the expertise and resources needed to ensure that it doesn't happen.

-- 
Jason Summers
ja...@po...  http://entropymine.com/jason/

Dave,

Lots of excellent ideas -- I've added a summary to the TODO file.
A few comments:

> 1) About the start/stop toggle:  my experience has been that you want a way to say STOP that won't accidentally mean START -- the Esc key is good for that.  But you also want a way to run a pattern in short bursts (when you've turned off hyperspeed and can control the speed, and you're waiting let's say a few thousand generations for a Unit Cell's counting gun to fire.)  And for that you need a single START/STOP toggle key like RETURN.

Due to popular demand, the recent 0.91 release allows return
to be used to start/stop, and the space bar can be used to stop.

> If the system might ever go from START to STOP by itself -- let's say, if you can ask it to run an arbitrary number of ticks [not limited to powers of 8 or 10], a handy feature shared by MCell, Life32, and Xlife ...

And LifeLab. :)  There's a heap of features from LifeLab (and other Life
apps) I'd like to add to Golly eventually.  I haven't bothered listing
all of them in the TODO file because I wanted to concentrate on the more
important stuff.  It's nice to get user suggestions so I have an idea
on what's important to other people.

> 2) I expected the Delete key to clear a selected pattern ...

Yep, good idea.  We could also use shift-delete as a shortcut for
clearing everything outside the selection (one of your later ideas).

> 3) Shift-clicking to alter a selection is a nice feature, and being able to move either a corner or an edge is theoretically nice, too; but I think it might be better to restrict the movement to a single edge at a time.  Or maybe the selection could show 'handles' (just if you hold down the Shift key?) that would give you feedback about what a click would do?  Not sure what would be best here.  The problem is that you don't want to accidentally move a boundary that you had already set correctly, just by clicking a _little_ too close to a corner.  (Right now, you can't see onscreen whether edge movement or corner movement is going to happen with a given click.)

Good point.  I'd like to keep the ability to move the corner,
so I'll do one or both of these:
- Draw arrows or something to indicate which edges will move.
- Allow escape key to cancel change and restore original selection.

> 4) On the F-for-autofit:  MCell also uses 'F' for the same operation.  Life32 has an equivalent feature, Z-for-zoom, but with a very handy difference:  if there's no selection it autofits the entire pattern to the screen, but if there is a selection it zooms to that instead.

Yep, Stephen Silver also suggested a "Fit Selection" item.  We could
use "F" (ie. shift-f) as the shortcut key (I don't want to use z/Z
because that's the standard shortcut for Undo, which we'll have one day).

> 5)  Dockable (?) non-modal info window, so you can load several patterns in succession and automatically see the comments on each, without having to open and close separate info windows.  ...It would be handy to have a text field somewhere inside Golly anyway, just to paste broken patterns into, fix up the headers or whatever is wrong with them, and then cut and re-paste into the Life universe without having to change applications.

Hmm, sounds a pig to implement.  Probably makes sense only if/when
Golly supports multiple pattern windows.

> 6) ... Add isolated glider deletion as an option ...

LifeLab supports this so I already have the code.  (One minor prob
is that Golly's setcell/getcell routines are currently limited to
32-bit int coords. I think Tom said he's planning to change that
eventually.)

> 7) It's extra annoying when junk gliders escape beyond the editing boundary and you can't even delete them. One solution might be a "clear outside selection" feature ...

Yep, it should be quite easy to implement a "Clear Outside" item.

> 8) Actually Life32 does a little better than I described, even:  when you make a selection it zooms to the bounding box of the ON cells in the selection...

Yep, we could provide that somehow.  Maybe as a "Shrink Selection" item
in the Edit menu.

> 9) Animate just the selection for T ticks (Xlife has this ability, sort of, when you're building structured patterns out of subpatterns), or else freeze the selection and animate the rest of the universe ...

Is T likely to be very large?  LifeLab allows you to hit shift-space
to advance just the selection by 1 gen, or control-space to advance
everything outside the selection, so I could add that to Golly.

> Longer-term/more-crackpot feature requests follow --
> 
> 10) ... support a split-screen view of the universe.

That would be a great feature!  And maybe not all that hard to
implement using Tom's nice viewport interface.

> -- Boy, that would save me a lot of time.  Maybe I'd better stop all this feature-requesting and start looking for something in wxWidgets, myself.

I could do with some help on the wxWidgets side, especially if you
want to see all your ideas implemented before the decade ends. :)

> 11) Extending some of Jason Summers' ideas from the TODO list:
>> - More available zoom scales would be nice, e.g. 1:3 and 1:6.
>> - For better viewing of patterns that move, have a way to,
>>   while animating, automatically move the viewport X cells
>>   horizontally and Y cells vertically every Z generations.
> 
> Golly's pattern format should make it possible to record a "hint" for how to translate the view window over time when the pattern is running -- e.g., have a view focusing on the line-of-eaters output of the programmable constructor, so zoom stays the same but view window moves smoothly north-northeast -- (+8, -12) every 118442 ticks -- or, better, (+1, -3/2) every 118442/8 ticks (round to the nearest), or even smaller increments! ...

Definitely a long-term idea!  Ditto for 12) to 15). :)

Andrew

Paul Chapman wrote (to the Life List):
> ...
> (2) Combine the start and stop toolbar buttons into a single toggle.
> (3) Make RETURN the key to start animating, rather than ctrl-G.
>  Make both RETURN and SPACE stop animation if it's running.

Couldn't resist putting my oar in on a couple of these, and adding several more while I was at it.  Apologies for the length -- but you folks _have_ been saying, "Keep the ideas coming"...  I'll give a quick summary at the top, and then anyone who's actually interested can look up the details in the extended use-case text below.

1)  Start/Stop toggle vs. separate keys and buttons
2)  Single key needed to clear the current selection
3)  Suggested change for shift-click selection:  just one edge at a time (the nearest edge to the mouse click)
4)  Option to autofit a selection, not just the whole pattern
5)  Editable info window that can remain open without locking the Life universe

Dealing with widely-separated subpatterns:
6)  Isolated glider deletion
7)  Clear outside selection
8)  For some purposes, automatically reduce selection to bounding box of ON cells
9)  Animate just the selection and freeze the rest of the universe, or vice versa

Crackpot long-term ideas:
10)  Split screen:  two frames, maybe even four frames? -- showing different views of the same universe
11)  Moving view window recorded in pattern format and/or guessed by a smart Autofit algorithm
12) Multiple defined views
13) Arbitrary fractional zoom levels for non-hash mode
14) Tag an active pattern and get a view to follow it
15) support for reading and writing annotated pattern format 

Okay, here we go:

1) About the start/stop toggle:  my experience has been that you want a way to say STOP that won't accidentally mean START -- the Esc key is good for that.  But you also want a way to run a pattern in short bursts (when you've turned off hyperspeed and can control the speed, and you're waiting let's say a few thousand generations for a Unit Cell's counting gun to fire.)  And for that you need a single START/STOP toggle key like RETURN.

A togglable button is fine, for them as likes mouses, but that's more for pure pattern viewing.  If you're doing any editing, you're probably poised to do some editing operation as soon as you reach the right tick, and having to wander off with the mouse to muck around with buttons is an unwelcome diversion.

With separate START and STOP keys you inevitably fumble somehow when moving from the START to the STOP key while looking at the screen, and the critical moment rushes madly past and you have to reload and start over (until backward stepping gets implemented, anyway...)

If the system might ever go from START to STOP by itself -- let's say, if you can ask it to run an arbitrary number of ticks [not limited to powers of 8 or 10], a handy feature shared by MCell, Life32, and Xlife -- I'm not sure it makes as much sense to mix the START and STOP buttons.  It then becomes possible to hit the STOP button just as it turns back into a START button, thus sending it off on another N ticks worth of exactly what you didn't want it to do any more of.  And if Golly is doing something challenging and response time slows down, you similarly need to avoid having the system save up two STOP request and convert them into a START request. In that case you certainly want an unambiguous STOP key like the current Esc -- but then maybe it doesn't matter so much what you do with the GUI buttons.

The space bar should definitely get you out of run-full-speed mode; at least that's an easy key to hit when you're aiming for it in a panic (though really Esc is pretty good too.)  But anyway a user hitting the space bar when a pattern is running probably means *something* by it, so it's not good manners to just ignore the keystroke.

2) I expected the Delete key to clear a selected pattern -- it's awfully awkward to have to use the menu system for this operation, because the odds are that the mouse cursor will be needed back in the pattern immediately afterwards.  For example, I often find myself trimming away several rectangles' worth of junk from around a pattern before I select it.  I suppose that use case would be handled nicely by a polygon-select tool, though...

3) Shift-clicking to alter a selection is a nice feature, and being able to move either a corner or an edge is theoretically nice, too; but I think it might be better to restrict the movement to a single edge at a time.  Or maybe the selection could show 'handles' (just if you hold down the Shift key?) that would give you feedback about what a click would do?  Not sure what would be best here.  The problem is that you don't want to accidentally move a boundary that you had already set correctly, just by clicking a _little_ too close to a corner.  (Right now, you can't see onscreen whether edge movement or corner movement is going to happen with a given click.)

4) On the F-for-autofit:  MCell also uses 'F' for the same operation.  Life32 has an equivalent feature, Z-for-zoom, but with a very handy difference:  if there's no selection it autofits the entire pattern to the screen, but if there is a selection it zooms to that instead.  Enormously handy for getting to the exact area of a pattern that you want to examine, without fighting your way through several powers of two in between while recentering the pattern occasionally as the part you're interested in wanders off the screen.

[The worst part is having to switch between tools too much.  If I'm building a pattern out of existing pieces, I mostly want to stay in Select mode and do a series of copies and pastes with various translations... and not have to go hunting around for the Zoom button halfway through.  Thus I'm a huge fan of zooming with the center mouse wheel -- another feature of MCell.]

In Life32, though, I often wish I didn't have to clear the selection to be able to zoom out to an entire-pattern view again; possibly I'd be happier if these two functions were separate keys, or if a modifier key (e.g., Shift-Z) could zoom to the entire pattern instead of the selection.

5)  Dockable (?) non-modal info window, so you can load several patterns in succession and automatically see the comments on each, without having to open and close separate info windows.  ...It would be handy to have a text field somewhere inside Golly anyway, just to paste broken patterns into, fix up the headers or whatever is wrong with them, and then cut and re-paste into the Life universe without having to change applications.

6) Response to something from the TODO list:

>  - Add isolated glider deletion as an option -- why bother???

Chasing down escaped gliders is even more annoying in Golly than in Life32, which was more annoying than in MCell -- just because MCell was slow enough that they didn't get very far!  And anyway in MCell there's an edge effect by default.  Sometimes you _want_ to be working in a relatively small box -- might be something to consider when you get around to supporting toruses:  wouldn't necessarily want to have escaped gliders attack a pattern from the other side of the universe, either, so again it might be worth having an isolated-glider-killing zone.

I'd love to be able to turn on isolated-glider deletion for most gun patterns, come to think of it, beyond some reasonable boundary -- strings of millions of gliders, with the gun as a miniscule blob at one end, aren't really all that interesting to look at.  Do a selection, maybe, and then choose "remove isolated gliders beyond this area"?

7) It's extra annoying when junk gliders escape beyond the editing boundary and you can't even delete them. One solution might be a "clear outside selection" feature, or some way to quickly get rid of everything outside the editable area.

Try running something like a single Deep Cell for a 2-to-the-unreasonable-N generations with Autofit turned on -- then (a) try to delete all the escaped gliders, or (b) try to use the Zoom tool to get back to the central area and look at what the original pattern is doing.  It takes unreasonable-N annoyingly careful clicks on the central spot to get back to the area of interest.  Sure, users will eventually figure out that it's better to hit F and then hold down the right bracket -- but what if gliders have escaped in only two directions?  Well, use M instead of F...  but what if you want to look at the glider salvo that has escaped to the southwest?  If you let Golly run for a few seconds too many, you can spend quite a bit of time chasing barely-visible flecks around with the Zoom tool.  A zoom-to-selection tool or option would make this kind of thing a good bit more efficient.

8) Actually Life32 does a little better than I described, even:  when you make a selection it zooms to the bounding box of the ON cells in the selection.  I find this automatic reduction of the selection fairly annoying when I want to grab a small pattern and move it -- I have to hit the reduced selection area exactly with the mouse, or I end up unselecting it (whereas I feel as if I should be able to click and drag anywhere in the area that I actually selected -- the bounding box remains visible.)  But when I'm zooming to a selection, I usually like the automatic reduction a lot -- again, it saves working down through several zoom levels.  Occasionally I'm selecting just one glider, and autofit zooms in a little _too_ close (like in the introduction to _Aladdin_) but that's a small problem by comparison.

If the bounding box of the ON cells can be found efficiently, this might also speed up Clear operations on large selections -- e.g. when I'm trying to get rid of escaped gliders with ambitious selections of huge areas...

9) Animate just the selection for T ticks (Xlife has this ability, sort of, when you're building structured patterns out of subpatterns), or else freeze the selection and animate the rest of the universe (MCell and Life32 do it this way.)  I find I need both of these options regularly, but I always have to simulate the one I don't have by dropping the selection, saving the pattern, running the whole pattern for T ticks, re-making the selection, copying it, reloading the pattern, and finally pasting it where I want it (!).

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

Longer-term/more-crackpot feature requests follow --

10) Another way of avoiding zoom-level problems -- i.e., where you have to zoom in somewhere to carefully select a subpattern, then zoom way out to find a faraway spot where you want to paste a copy, then zoom back in to the faraway spot to place it precisely -- would be to support a split-screen view of the universe.  Many programs allow for at least a single split by providing a draggable split-screen marker above the right-side scrollbar -- even TextPad, which I'm writing this with...

This would be a very handy alternative to Life32-like multiple tabs containing separate universes -- which are really about as awkward as just running multiple copies of the editor; with tabs, you can only see one universe at a time, where with multiple windows at least you can tile them if you really want to.

-- Boy, that would save me a lot of time.  Maybe I'd better stop all this feature-requesting and start looking for something in wxWidgets, myself.

11) Extending some of Jason Summers' ideas from the TODO list:
> - More available zoom scales would be nice, e.g. 1:3 and 1:6.
> - For better viewing of patterns that move, have a way to,
>   while animating, automatically move the viewport X cells
>   horizontally and Y cells vertically every Z generations.

Golly's pattern format should make it possible to record a "hint" for how to translate the view window over time when the pattern is running -- e.g., have a view focusing on the line-of-eaters output of the programmable constructor, so zoom stays the same but view window moves smoothly north-northeast -- (+8, -12) every 118442 ticks -- or, better, (+1, -3/2) every 118442/8 ticks (round to the nearest), or even smaller increments!  This could also be built into Autofit functionality, where Golly could catch on after following a spaceship through repeated Autofits, and start guessing smaller increments to get rid of the jerkiness in the view changes.

12) The pattern format might be allowed to set up multiple definable views for a single pattern:  for future structured-format patterns, this might simply be a treeview of the structure by default.  But additional views could also be defined, with a (dx, dy, dt, dzoom) for each.  dt=1 might be the most common, but I could imagine dt={bignumber} to refocus the view only every now and then, or even dt={fraction} for close-up zooms and slow simulation speeds, to make the scrolling smoother.

Thus for the programmable constructor an "Output" view could be defined as described above, but you could also look at the "Tape-reader" or the "Ladder Circuit".

These would be very handy in displaying many of the sample patterns -- why not have a view that stays with a spaceship stamp collection, instead of having the dratted thing zip off the screen in one direction or another and being forced to chase it?  The only problem is that some  patterns might end up looking kind of jerky, the way they do now with Autofit at certain zoom levels:  to follow a 2c/5 pattern, for example, you really want to move .4 cells per generation (which could be approximated quite well at higher zoom levels) -- rather than waiting five generations and then suddenly jumping two cells.

13) Once I get this far, of course, I look at "(dx, dy, dt, dzoom)" again and realize that dzoom really needs to be able to take on any value, too, not just powers of two -- to get rid of jerkiness in displaying a *growing* pattern.  This is a limitation common to all current pattern viewers, and it would be a real coup to have an option to get rid of it!  (Well, MCell will do various odd-integer numbers of pixels per cell, but that doesn't help when you get to the big jump between 2 and 1 pixels per cell.)

Presumably fractional zooms would only be available when hashing was turned off and/or Golly wasn't running at maximum speed -- how much of a performance hit would there be in running each generation of pattern image through an anti-aliasing resizing algorithm?

14) Another incredibly useful (but also incredibly annoying to implement) feature would be a view that tracks the active cells in the current selection -- so you could pick a glider and have the view follow it around.  If the glider were split into two gliders, ideally the zoom level would automatically expand smoothly to let you keep track of both gliders (or you could select just one again and continue from there).

15) Floating annotations:  read HK's annotation format in initial display mode (not so important when running), and ideally allow labels and other annotations to be added in the GUI.  A few arrows and labels could be awfully handy in figuring out how a pattern works...  The current format is described at http://cranemtn.com/life/blog/RLEFormat.htm (though it might be a bit out of date -- have to recheck and update it sometime soon.)  http://pentadecathlon.com/cgi-bin/lifeview.acgi?form can be used to generate PNGs from this format.

Keep the cheer,


Dave

> So many good suggestions!  We need a way to manage them.
> Should we enter them all into the sourceforge system?  Or
> should we instead just edit in a text file or something?

SF is too slow -- I've added a "User suggestions" section to
the TODO file (just committed).

> I want to put out 0.91 very soon if we can manage to duplicate
> the hash bug that Gabriel reported, just as an interim bug-fix
> release.  Is that okay?

Sure, although I'm not convinced it's a show-stopping bug (only
Gabriel has seen it so far, and it seems difficult to reproduce).

> I plan to work on it today some and
> hopefully find/fix the problem, and then we can make a build
> and put it up Saturday/Sunday.  If other things sneak in there
> that's okay as long as they are minor (not very risky).

Ok, I'm currently testing a few minor changes:
- added CR+LF to clipboard data on Windows
- return key can be used to start/stop generating
- space bar can be used to stop generating
I'll avoid starting on anything major.

Andrew

So many good suggestions!  We need a way to manage them.
Should we enter them all into the sourceforge system?  Or
should we instead just edit in a text file or something?

I want to put out 0.91 very soon if we can manage to duplicate
the hash bug that Gabriel reported, just as an interim bug-fix
release.  Is that okay?  I plan to work on it today some and
hopefully find/fix the problem, and then we can make a build
and put it up Saturday/Sunday.  If other things sneak in there
that's okay as long as they are minor (not very risky).

-tom

Great!  I can write that Perl script pretty quickly; no problem.

I asked Stephen for permission, I think, a long time ago,
but it's been so long it's probably good to ask again.

It would be really neat if wxHtml supported buttons or
links that call back into the program; that's really what
we need . . .

-tom

> Just a thought:  for simple patterns, why not put the entire
> Stephen Silver Life Lexicon on there?

Excellent idea!  A preliminary test indicates the multi-page
version should work very nicely, but because wxWidgets supports
only a subset of HTML (eg. no css support) we'll need to make
a few minor changes:

- add some HTML code to set the font size and background color
- remove all tabs from the start of pattern picture lines
- replace "×" with "x"
- replace "ó" with "o"
- and probably a few more changes like the above two

We'll need a script to do all these changes so we can apply them
to new Lexicon releases.  My Unix scripting skills are almost
non-existent so could someone write a simple perl/sed script
that does this:

for each *.htm file do
	remove tab at start of line
	replace all "×" with "x"
end

I can then modify the script to do the other changes.

I've written to Stephen asking if this is all ok.  It should be,
based on his copyright info, but always better to ask!

> If we could adopt the HTML version so that clicking on a
> pattern opens it in golly or something that would be even
> cooler.

This could be tricky.  I think we need to allow normal clicking
and selecting so people can copy a Lexicon pattern (via ctrl-C)
and then they can decide to use Open Clipboard or Paste.
But it would be nice if we also allow control-clicking as a
shortcut for one of those tasks (probably Open Clipboard).
I'll have to look at wxHTML again to see if it lets me do that
sort of thing.

Andrew

Just a thought:  for simple patterns, why not put the entire
Stephen Silver Life Lexicon on there?  It's not large (84K
compressed), has probably thousands of patterns with
interesting commentary, and is browsable and cross-linked.

If we could adopt the HTML version so that clicking on a
pattern opens it in golly or something that would be even
cooler.

-tom

> Would it be okay for me to put the golly built-in help directly on the
> website, and also in the Docs section of the sourceforge page?

Fine by me -- excellent idea!

> For example, see
> 
>    http://tomas.rokicki.com/golly/src/Help

For some reason I get redirected to a Network Solutions domain name
renewal page.  Maybe it's time to stop writing code and pay some bills. :)

Andrew

Would it be okay for me to put the golly built-in help directly on the
website, and also in the Docs section of the sourceforge page?
This will give casual users a quick and easy way to look at the
features of the product.

For example, see

   http://tomas.rokicki.com/golly/src/Help

This is what it would look like.  It's very impressive, thanks to
Andrew!

-tom