Life tag testing

[rowett]

The fact that the Viewer parsed the Python script into a pattern is clearly a bug, but on the other hand quite interesting. I wonder which other Python scripts result in a Life pattern...

I've seen several of these cases, I think, and of course I always tried the Show in Viewer link. What I get is a strange VIEWONLY-type display with a white background and no visible pattern.

Yes and it's already fixed.

[rowett]

It's a tiny link that is useful in 90% of cases, and is completely unobtrusive in the rest. It'd be nice if we could find some way to detect what rules his posts are using so that things are displayed correctly, but there's only so much guesswork we can do.

I did offer to help him and add support for his specific rules but that resulted in derogatory comments about my design skills. I could still do so but I fear it would be a waste of time. He'd still find a way to complain.

[dvgrn]

I did offer to help him and add support for his specific rules but that resulted in derogatory comments about my design skills. I could still do so but I fear it would be a waste of time. He'd still find a way to complain.

True enough -- it's important not to set a goal of no complaints... the probability of being able to declare success drops precipitously.

On the other hand, I've looked quite a bit at the families of rulesets that he tends to work with, and color schemes are copied and shared fairly widely between them. Supporting those rules better in the viewer would not be a very difficult task -- for the sake of other forum users who might appreciate it, let's say.

It's not my current highest priority, but if I have time at some point, I might make a quick collection of the common color schemes, which would probably make the colors accurate for the great majority of old posts.

[rowett]

It's not my current highest priority, but if I have time at some point, I might make a quick collection of the common color schemes, which would probably make the colors accurate for the great majority of old posts.

Well as I offered our good friend Brian, I'm more than happy to add extra colour sets to LifeViewer. It's a simple task and takes a brief moment to do.

[dvgrn]

Brian's bug report got me looking at opening and closing viewers. It looks as if there's a bug showing up, at least on Windows 7 / Google Chrome, that would be worth finding and fixing.

Start from any page with a "Show in Viewer" tag, like this one:

Code: Select all

#Life 1.05
#D Lightspeed wire and some simple signals
#D
#D Well known.
#D
#D No corners or branches have been found yet.
#D See also ZIP2, MAX.
#D [[ AUTOSTART HEIGHT 240 LOOP 80 ]]
#N
#P -38 -6
....*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
..******************************************************
.*
.*******************************************************
........................................*........*
.******.**.*..******..*****************....******....***
*......*...**......**........*........*.........*
.********..*..******..******....*******....******....***
............................*..........*.........*
.*******************************************************
.*
..******************************************************
....*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
#P 18 -6
..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
******************************************************
.
******************************************************
....*.................................................*
****...************************************************
.....*
****...************************************************
....*.................................................*
******************************************************
.
******************************************************
..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*

If I click to look at the pattern, then closer the viewer again, I mysteriously can't select text with the mouse on the same HTML page any more -- until I refresh the page anyway. Can still click with the mouse to place the cursor, and I can select with SHIFT and the arrow keys, but mouse click-and-drag is temporarily broken.

This has been showing up a lot when I add script commands to a pattern I'm posting, then retest the viewer with the new settings, then want to edit the script some more.

Separate question: when I add "PAUSE 5" to the above script string, why exactly does the pattern disappear?

Code: Select all

#Life 1.05
#D Lightspeed wire and some simple signals
#D
#D Well known.
#D
#D No corners or branches have been found yet.
#D See also ZIP2, MAX.
#D [[ AUTOSTART HEIGHT 240 LOOP 80 PAUSE 5 ]]
#N
#P -38 -6
....*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
..******************************************************
.*
.*******************************************************
........................................*........*
.******.**.*..******..*****************....******....***
*......*...**......**........*........*.........*
.********..*..******..******....*******....******....***
............................*..........*.........*
.*******************************************************
.*
..******************************************************
....*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
#P 18 -6
..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
******************************************************
.
******************************************************
....*.................................................*
****...************************************************
.....*
****...************************************************
....*.................................................*
******************************************************
.
******************************************************
..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*

[rowett]

Brian's bug report got me looking at opening and closing viewers.

Yes I've already fixed it (assuming we're talking about some Viewers popping up with all colours set to white).

It looks as if there's a bug showing up, at least on Windows 7 / Google Chrome, that would be worth finding and fixing.

Start from any page with a "Show in Viewer" tag, like this one:

Code: Select all

#Life 1.05
#D Lightspeed wire and some simple signals
#D
#D Well known.
#D
#D No corners or branches have been found yet.
#D See also ZIP2, MAX.
#D [[ AUTOSTART HEIGHT 240 LOOP 80 ]]
#N
#P -38 -6
....*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
..******************************************************
.*
.*******************************************************
........................................*........*
.******.**.*..******..*****************....******....***
*......*...**......**........*........*.........*
.********..*..******..******....*******....******....***
............................*..........*.........*
.*******************************************************
.*
..******************************************************
....*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
#P 18 -6
..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*
******************************************************
.
******************************************************
....*.................................................*
****...************************************************
.....*
****...************************************************
....*.................................................*
******************************************************
.
******************************************************
..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*..*

If I click to look at the pattern, then closer the viewer again, I mysteriously can't select text with the mouse on the same HTML page any more -- until I refresh the page anyway. Can still click with the mouse to place the cursor, and I can select with SHIFT and the arrow keys, but mouse click-and-drag is temporarily broken.

Yes I've managed to reproduce. Now to figure out why...

EDIT: OK so I know why. I've improved it to the extent that whilst the standalone Viewer is closed all returns to normal. However it's still causing the behaviour your describe while the Viewer is open.

EDIT 2: Fixed it.

...Hmm, and when I add "PAUSE 5" to the above script string, why exactly does the pattern disappear?

This is the same bug you reported before and already fixed in build 145:

-- Oh, and have a look at what happens when you leave out the initial "X 0 Y 0", which I was thinking would be the default. And in fact it is the default as long as I haven't defined any waypoints, I think. But when waypoints are defined, the default coordinates seem to be (512, 512).

[rowett]

Build 148 is now available on the lazyslug server.

Enhancements in this build:

• added some more colour sets
• the position of standalone Viewer is constrained so it is always visible in the browser window
  • window resize will also reposition the standalone Viewer if required

Fixes is this build:

• pattern decoder was not strict enough and in some cases was decoding python scripts as Life patterns
• some pattern rule names were causing colours to be set to all white
• the standalone Viewer was causing drag and select to be disabled

[dvgrn]

Build 148 is now available on the lazyslug server.

Looks good to me! (This is based on a somewhat perfunctory review of the test page -- haven't tried any live testing with my own HTML yet...)

Nathaniel, when you have a moment, could you please move Build 148 onto the conwaylife.com server? There are quite a few bug fixes now, so this seems like a good time for an update. It's definitely a bit lazy of me to want to do the rest of the testing for this build when it's already conveniently live on the server. Still, I can confidently say an update will greatly reduce the total number of bugs, even if a subtle new one or two have crept in...!

Also, I'm somewhat ashamed to mention it: the lowercase "v" on the "Viewer" button is still kind of hitting me in the eye, when I don't remember not to look at it.

[Nathaniel]

Build 148 has been uploaded.

Also, I'm somewhat ashamed to mention it: the lowercase "v" on the "Viewer" button is still kind of hitting me in the eye, when I don't remember not to look at it.

Believe it or not, this is actually *huge* pain in the ass to fix. For some reason, if I change the "viewer" button to "Viewer", then I also have to change the

Code: Select all

tag to [Viewer], even though the built-in phpBB tags don't behave this stupidly. Not sure what to do about it yet.

[dvgrn]

Build 148 has been uploaded.

Strange, I'm still seeing Build 144 -- guess I'll wait an hour and look again.

EDIT: Wait, now it's up to Build 147! I'm sure I saw a 148 on Chris's server...? Well, no, maybe I didn't. It says "147", but does in fact have the stated Build 148 fixes.

Also, I'm somewhat ashamed to mention it: the lowercase "v" on the "Viewer" button is still kind of hitting me in the eye, when I don't remember not to look at it.

Believe it or not, this is actually *huge* pain in the ass to fix.

Interesting! Well, if it's some phpBB thing, then I can just get used to it along with all the other phpBB things -- it's not nearly so painful if it's just The Way Things Are. (I've been fighting with Microsoft Access all day, so I feel as if maybe I should be counting my blessings -- things could be a lot worse...!)

[rowett]

EDIT: Wait, now it's up to Build 147! I'm sure I saw a 148 on Chris's server...? Well, no, maybe I didn't. It says "147", but does in fact have the stated Build 148 fixes.

Sorry the *real* build 148 is now on the lazyslug server. The one you have is fine, it's build 147 plus all but one of the 148 fixes.

[dvgrn]

Sorry the *real* build 148 is now on the lazyslug server. The one you have is fine, it's build 147 plus all but one of the 148 fixes.

The viewer on conwaylife.com appears to have reverted back to Build 144. Did something interesting go wrong with build 147/148?

[rowett]

The viewer on conwaylife.com appears to have reverted back to Build 144. Did something interesting go wrong with build 147/148?

Nope, no change. Try refreshing your browser.

[rowett]

The real Build 148 (now with bonus extra fixes, free!) is now available on the lazyslug server.

Enhancements in this build:

• ensure that the initial position of the standalone viewer is all visible in the browser window
• increased the duration of error notifications

Fixes in this build:

• if the screenshot window (hotkey "O") could not be opened display an error notification (usually caused because popups are blocked by the browser)
• initial waypoints without position and zoom information were not resetting to default in the standalone viewer
• only display LOOP on and off messages at Pause and Reset if LOOP is actually defined
• hotkey "M" was toggling navigation menu when disabled
• prevent progress bar from drawing > 100% on systems that are not fast enough to keep up
• STEP slider was not being displayed in the standalone viewer if the previous pattern was VIEWONLY

Currently working on the new generation engine (to improve sparse pattern performance) and thinking about the ZOOM question.

[rowett]

Build 149 is available on the lazyslug server.

Enhancements in this build:

• new tile-based generation engine bringing significant performance benefits to sparse patterns
• increased maximum STEP to 32
• switching on or off waypoint playback (with hotkey "W") also turns on or off LOOP mode if defined

Dave this build needs some testing since the generation engine is new!

[dvgrn]

Build 149 is available on the lazyslug server...
Dave this build needs some testing since the generation engine is new!

Looks like a definite improvement so far.

When the script says something like [[ AUTOSTART LOOP 160 ]], previous builds would jump right back to T=0 with no appreciable pause, and keep on going. Now there's something like a half-second delay when the last generation is reached and when the first generation is shown.

One of my tests involves saving a copy of a conwaylife.com forum page, then substituting the new version of lv-plugin.js. When I do that, I end up with a page with code block headers that look like "CODE: SELECT ALL / SHOW IN VIEWER / SHOW IN VIEWER". Is it easy to check if there's already a "Show in Viewer" link, and replace it if so, instead of adding another one?

[I'm not absolutely sure that this is a good idea, really, but I don't see any harm in it offhand -- it will probably only happen in this strange test case, so it's definitely not very important... I don't quite understand why the HTML gets saved with "Show In Viewer" links point back to conwaylife.com but don't pop up a viewer when you get there -- but I can imagine very reasonable explanations.]

People have been posting a lot of glider guns lately, and they definitely keep running much better in Build 149 than in Build 147. In Build 147 they quickly got mired in molasses, to the point where any AUTOSTART viewers I posted would have a LOOP setting to restart the gun before it got too sluggish.

There's one subtle change that doesn't seem like an improvement: if you look at a posting like this one, you'll see that the periodic gun restart is very smooth -- you just see the background cells disappear, but the signals in the loop appear to keep going without a pause. If you switch over to Build 149, there's a very definite pause that goes along with the restart. It's barely noticeable for some looping-script patterns, and a fairly large fraction of a second for others. Might show up more on slow CPUs (?).

I noticed on this posting that the Step setting sticks to whatever value you set it to, between uses of the standalone viewer. It's probably a good idea to have the Step size be sticky -- seems like different step sizes might work better for different users, depending on their CPU speed and/or level of impatience... but is there a reason why other settings aren't also retained, such as the Theme setting? Seems like a user might also have a preferred theme, and it could maybe be kept if there's no THEME statement in the next pattern's script to say otherwise.

In this posting I put a STOP command in the script, so that signal trails would all be filled in but the viewers wouldn't all be running at once (except for a moment at the beginning). I noticed that the word "Pause" still shows up even in the thumbnail view. It actually fits on the screen in Build 149, whereas in Build 147 it used to say "...use" and then something parenthetical about loops. Should text be appearing at all in the thumbnail view? If so, then everything seems to be in working order now. But are there other messages that might still get displayed that would overflow the thumbnail view?

Finally, here are a couple of test patterns+scripts that showed up problems in Build 147. Haven't tested in build 149 yet -- I'll maybe edit in some comments shortly...

Yup, the first pattern below seems okay in Build 149 -- the progress-bar overflow goes away. The idea here was to zoom out to see the whole rest of the slow-salvo recipe, halfway through. It's slow at the beginning and very fast at the end and then jerks to a stop, but that's the zoom-level interpolation issue that has already been discussed.

There are some odd effects with 0.5 level zooms, like some objects and gliders disappearing while others are still visible. There's also the odd fact that when patterns get large enough, you can't zoom out to see the whole thing at once, so the Autofit function does strange things... hit F on a gun pattern that's been running for a while, for example, and you'll probably see just a line of gliders, with the gun off the screen.

Might be worth jumping to the original extents of the pattern at zoom level 0.5, just in the odd case where the whole pattern won't fit in the viewer any more...?

With the pattern below you get a little of the opposite problem -- the pattern is very autofit-compatible toward the end of its Life cycle, but at the beginning you see weird effects in the corners because the pattern is on a torus.

Code: Select all

x = 897, y = 903, rule = B3/S23
2o$2o4$3o$o$bo8$21b3o$21bo$22bo28$17b3o$17bo$18bo8$38b3o$38bo$39bo28$
34b3o$34bo$35bo8$55b3o$55bo$56bo28$72b3o$72bo$73bo8$91b3o$91bo$92bo8$
104b3o$104bo$105bo28$119b2o$118b2o$120bo8$149b2o$148b2o$150bo18$179b2o
$178b2o$180bo33$212b3o$212bo$213bo28$250b3o$250bo$251bo28$281b3o$281bo
$282bo28$285b3o$285bo$286bo28$315b3o$315bo$316bo28$360b3o$360bo$361bo
28$375b3o$375bo$376bo28$412b2o$411b2o$413bo28$435b2o$434b2o$436bo8$
493b3o$493bo$494bo28$519b3o$519bo$520bo28$551b3o$551bo$552bo28$574b3o$
574bo$575bo28$615b2o$614b2o$616bo48$654b3o$654bo$655bo28$687b3o$687bo$
688bo28$724b3o$724bo$725bo28$753b2o$752b2o$754bo28$787b3o$787bo$788bo
28$803b2o$802b2o$804bo28$836b2o$835b2o$837bo28$865b2o$864b2o$866bo28$
894b3o$894bo$895bo!
[[ AUTOSTART STEP 8 ZOOM 16 X 450 Y 450 PAUSE 5 "loaf2GtoG slow salvo\n35 gliders total" ]]
[[ T 1800 ZOOM 0.5 STEP 8 ]]
[[ T 3600 STEP 8 ]]
[[ LOOP 4000 ]]

With this next pattern the only problem I saw in Build 149 was a mysterious slowdown between T=3600 and T=4000. I'm guessing that the viewer is jumping back to its original default STEP 1 once it's done playing through the defined waypoints. I can't set a default of STEP 4 before the first waypoint; that throws an "overwrite" error. No doubt I could put an official waypoint at 4000 to solve the problem -- just wasn't expecting that that would be necessary. Apparently I thought that the last STEP setting should continue after the last waypoint.

Code: Select all

x = 897, y = 903, rule = B3/S23
2o$2o4$3o$o$bo8$21b3o$21bo$22bo28$17b3o$17bo$18bo8$38b3o$38bo$39bo28$
34b3o$34bo$35bo8$55b3o$55bo$56bo28$72b3o$72bo$73bo8$91b3o$91bo$92bo8$
104b3o$104bo$105bo28$119b2o$118b2o$120bo8$149b2o$148b2o$150bo18$179b2o
$178b2o$180bo33$212b3o$212bo$213bo28$250b3o$250bo$251bo28$281b3o$281bo
$282bo28$285b3o$285bo$286bo28$315b3o$315bo$316bo28$360b3o$360bo$361bo
28$375b3o$375bo$376bo28$412b2o$411b2o$413bo28$435b2o$434b2o$436bo8$
493b3o$493bo$494bo28$519b3o$519bo$520bo28$551b3o$551bo$552bo28$574b3o$
574bo$575bo28$615b2o$614b2o$616bo48$654b3o$654bo$655bo28$687b3o$687bo$
688bo28$724b3o$724bo$725bo28$753b2o$752b2o$754bo28$787b3o$787bo$788bo
28$803b2o$802b2o$804bo28$836b2o$835b2o$837bo28$865b2o$864b2o$866bo28$
894b3o$894bo$895bo!
[[ AUTOSTART GPS 10 T 0 STEP 8 ZOOM 16 X 450 Y 450 PAUSE 5 "loaf2GtoG slow salvo\n35 gliders total" ]]
[[ T 1000 ZOOM 8 X 445 Y 415 ]]
[[ T 3600 ZOOM 4 X 445 Y 415 ]]
[[ LOOP 4000 ]]

[rowett]

Thanks for the feedback.

When the script says something like [[ AUTOSTART LOOP 160 ]], previous builds would jump right back to T=0 with no appreciable pause, and keep on going. Now there's something like a half-second delay when the last generation is reached and when the first generation is shown.

OK I'll take a look.

One of my tests involves saving a copy of a conwaylife.com forum page, then substituting the new version of lv-plugin.js. When I do that, I end up with a page with code block headers that look like "CODE: SELECT ALL / SHOW IN VIEWER / SHOW IN VIEWER". Is it easy to check if there's already a "Show in Viewer" link, and replace it if so, instead of adding another one?

[I'm not absolutely sure that this is a good idea, really, but I don't see any harm in it offhand -- it will probably only happen in this strange test case, so it's definitely not very important... I don't quite understand why the HTML gets saved with "Show In Viewer" links point back to conwaylife.com but don't pop up a viewer when you get there -- but I can imagine very reasonable explanations.]

This is just an artifact of how the browsers save the page. Since the Viewer has modified the page on load (adding Show in Viewer, adjusting the Canvas element) these changes get saved too. What I do in this circumstance is manually go in and edit the saved page to remove these additions. It doesn't really make sense for the Viewer to do this since it's a strange test case

There's one subtle change that doesn't seem like an improvement: if you look at a posting like this one, you'll see that the periodic gun restart is very smooth -- you just see the background cells disapper, but the signals in the loop appear to keep going without a pause. If you switch over to Build 149, there's a very definite pause that goes along with the restart.

I presume this is the same problem you reported above (i.e. the delay before restart)?

I noticed on this posting that the Step setting sticks to whatever value you set it to, between uses of the standalone viewer. It's probably a good idea to have the Step size be sticky -- seems like different step sizes might work better for different users, depending on their CPU speed and/or level of impatience... but is there a reason why other settings aren't also retained, such as the Theme setting? Seems like a user might also have a preferred theme, and it could maybe be kept if there's no THEME statement in the next pattern's script to say otherwise.

This is a bug. The STEP should be reset. Will fix in the next build.

In this posting I put a STOP command in the script, so that signal trails would all be filled in but the viewers wouldn't all be running at once (except for a moment at the beginning). I noticed that the word "Pause" still shows up even in the thumbnail view. It actually fits on the screen in Build 149, whereas in Build 147 it used to say "...use" and then something parenthetical about loops. Should text be appearing at all in the thumbnail view? If so, then everything seems to be in working order now. But are there other messages that might still get displayed that would overflow the thumbnail view?

This is a bug. The messages should not be displayed in the thumbnail view. Will fix in the next build.

[rowett]

Finally, here are a couple of test patterns+scripts that showed up problems in Build 147. Haven't tested in build 149 yet -- I'll maybe edit in some comments shortly...

Yup, the first pattern below seems okay in Build 149 -- the progress-bar overflow goes away.

Yes I provided a quick fix to this in Build 149. It's caused when then Viewer can't keep up with "real time" because the machine isn't fast enough. The quick fix just caps the progress bar at 100%. I may provide a more elegant solution in a future build.

The idea here was to zoom out to see the whole rest of the slow-salvo recipe, halfway through. It's slow at the beginning and very fast at the end and then jerks to a stop, but that's the zoom-level interpolation issue that has already been discussed.

Exactly, and I'm still pondering the zoom question.

There are some odd effects with 0.5 level zooms, like some objects and gliders disappearing while others are still visible.

This is because the display routine doesn't super-sample the grid so when there is less than a cell per pixel things go missing (and at 0.5x zoom, on average things go missing 50% of the time). I could fix this but we would take a performance hit at zooms < 1x.

There's also the odd fact that when patterns get large enough, you can't zoom out to see the whole thing at once, so the Autofit function does strange things... hit F on a gun pattern that's been running for a while, for example, and you'll probably see just a line of gliders, with the gun off the screen.

That's because the minimum zoom is fixed to 0.5x. Autofit in this case will set the zoom to 0.5 and center the pattern on the display. So for the patterns you included above the center is the stream of gliders.

Might be worth jumping to the original extents of the pattern at zoom level 0.5, just in the odd case where the whole pattern won't fit in the viewer any more...?

Yes, interesting idea. I'll give it a try.

[rowett]

With this next pattern the only problem I saw in Build 149 was a mysterious slowdown between T=3600 and T=4000. I'm guessing that the viewer is jumping back to its original default STEP 1 once it's done playing through the defined waypoints. I can't set a default of STEP 4 before the first waypoint; that throws an "overwrite" error. No doubt I could put an official waypoint at 4000 to solve the problem -- just wasn't expecting that that would be necessary. Apparently I thought that the last STEP setting should continue after the last waypoint.

The last STEP setting does continue after the last waypoint. The behaviour you saw here was because in waypoint playback mode the Viewer will attempt to catch up if the machine is not fast enough whereas once the last waypoint has been reached it doesn't. I've changed this in the latest build so it's consistent.

[rowett]

When the script says something like [[ AUTOSTART LOOP 160 ]], previous builds would jump right back to T=0 with no appreciable pause, and keep on going. Now there's something like a half-second delay when the last generation is reached and when the first generation is shown.

OK I'll take a look.

Dave I'm having trouble reproducing this. Please can you point me at a pattern that demonstrates this behaviour.

EDIT: No need I've just figured it out.

[rowett]

Build 150 is now available on the lazyslug server.

Enhancements in this build:

• gps and STEP sliders background goes red if playback is not happening in "real time" due to machine performance
• Themes with no colour history perform better during playback than other Themes when STEP > 1 is used (Theme 0 and Theme 6 or any custom Theme with just an ALIVE and DEAD colour defined)
• zoom < 1 uses super-sample to ensure live-cells are displayed

Fixes in this build:

• only "Expand" notifications are displayed when in THUMBNAIL mode
• generations per step was not being reset when subsequent patterns were opened in the standalone Viewer
• more consistent handling of playback when machine performance is low
• vastly improved reset time
• display no longer appears to wrap at low zooms

[rowett]

Build 151 is now available on the lazyslug server.

Enhancements in this build:

• minimum ZOOM is now 0.25x
• 4x supersampling is used when 0.5x <= ZOOM < 1.0x
• 16x supersampling is used when 0.25x <= ZOOM < 0.5x
• switched to smaller tile size to improve performance
• decreased brightness of red background when performance targets not being met

Fixes in this build:

• waypoint playback was not performing smooth course correction after manual adjustment when at last waypoint
• it was possible to create a Viewer whose width was not a multiple of 8
• locking a UI item would not cancel any current interaction

Supersampling comes with a performance penalty but ensures live cells are always visible.

I believe this build addresses all of the recent comments except for the zoom interpolation discussion. Please let me know if I missed anything.

[rowett]

Hi Nathaniel,
If Dave is happy with Build 151 please could you upload it?

[Nathaniel]

Hi Nathaniel,
If Dave is happy with Build 151 please could you upload it?

Done!

[dvgrn]

Hi Nathaniel,
If Dave is happy with Build 151 please could you upload it?

Done!

Now Dave's happy. Once I'm past the initial run through the test page, it's a lot easier to check the subtle stuff directly on the forums where I have lots of old patterns I can go back and look at. It's a bit of an unorthodox test method, I'm afraid, but it seems to work nicely so far.

-- Thanks, Nathaniel and Chris! I've checked that Build 151 is live now, and that it fixes the things I was complaining about last time around. Haven't found any new bugs to complain about yet (but just give me a little time).