ConwayLife.com

Posted: **September 15th, 2016, 7:13 pm**

Golly 2.8, Windows 64-bit.

Copying this RLE to clipboard

x = 61, y = 51, rule = B3/S23
27bo$25bobo$26b2o30bo$15bo41bo$16b2o39b3o$15b2o8$39bo$39bobo$2bo36b2o$
2bo$o2bo2$2o2b2o41bo$48bo$2bo2bo40b3o3bo$3bo47b2o$3bo47bobo$43b2o$42b2
o$44bo22$58b2o$58bobo$58bo!

And pasting into golly, I get this RLE instead (viewer demonstrates where the difference is)

Code: Select all

x = 61, y = 51, rule = B3/S23
27bo$25bobo$26b2o30bo$15bo41bo$16b2o39b3o$15b2o8$39bo$39bobo$2bo36b2o$
2bo$o2bo2$2o2b2o41bo$48bo$2bo2bo40b3o3bo$3bo47b2o$3bo47bobo$43b2o$42bo
$44bo22$58b2o$58bobo$58bo!

If I remove the linebreaks, I get the correct RLE.

Playing around more, I typed the RLEs below

Code: Select all

x = 12, y = 1, rule = B3/S23
bb8
obo!

versus

Code: Select all

x = 12, y = 1, rule = B3/S23
bb8obo!

And they display differently in my version of Golly. Namely, the above one is two dots, as if the 8 and o are disconnected. Are linebreaks now treated improperly, or is something corrupted on my end? Other users, please report if the same happens to you.

(Golly has already been acting strangely on my end lately, after running a number of large patterns, but this is the first real error I have encountered. Other behavior has just been intermittent unresponsiveness.)

Posted: **September 15th, 2016, 7:54 pm**

The Golly rle reader treats the pattern a line at a time and doesn't respect counts across line boundaries. In your small test case:

Code: Select all

x = 12, y = 1, rule = B3/S23
bb8
obo!

The line bb8 is causing the problem because when Golly reads that line the 8 isn't followed by anything so is ignored.
If you rewrite it as:

Code: Select all

x = 12, y = 1, rule = B3/S23
bb8o
bo!

... all is well.

Having said that Golly should be able to read counts across line endings so I've submitted a fix.

Posted: **September 15th, 2016, 8:07 pm**

I suspected that was the case, hence my focused test case. I really just wanted to type bb8..

I find it particularly interesting because when pasting code to the forums they insert linebreaks irrespective of the final character. It took surprisingly long for this conflict to actually show up, since I frequently paste from forums into Golly. The synthesis posted at the top of my message was the first time I had seen it. That combined with the fact that the lifeviewer does parse the forum-pasted code no matter where the linebreaks lie, it definitely is time for Golly to do the same.

rowett wrote:I've submitted a fix.

Thanks!

Posted: **September 15th, 2016, 9:50 pm**

biggiemac wrote:
rowett wrote:I've submitted a fix.
Thanks!

Does the fix work when you break a number in half, also, so that you can always split lines at a fixed width without worrying about breaking anything?

That will break with about a quarter-century-old tradition for RLE parsers. I never could figure out why the tradition was a good idea, but there are certainly a lot of parsers out there that assume that numbers are never broken or separated from what they're numbering.

It would probably be a bad idea for Golly to start generating fixed-width RLE itself, because that would cause subtle problems in a lot of people's pattern-handling code. But probably just being able to read broken numbers won't encourage people to generate fixed-width RLE all that much... right?

Posted: **September 15th, 2016, 10:46 pm**

dvgrn wrote:Does the fix work when you break a number in half, also, so that you can always split lines at a fixed width without worrying about breaking anything?

The fix just tells the rle reader to ignore new lines. So yes, a split number would also be valid (which, rightly or wrongly, is how LifeViewer works also). So the following pattern:

Code: Select all

x = 86, y = 1, rule = B3/S23
bb8
2obo!

... contains a single line with 2 dead cells, 82 live cells, one dead cell and one live cell.

dvgrn wrote:That will break with about a quarter-century-old tradition for RLE parsers. I never could figure out why the tradition was a good idea, but there are certainly a lot of parsers out there that assume that numbers are never broken or separated from what they're numbering.

So the original pattern would have been invalid for those parsers, or just misread as Golly did.

dvgrn wrote:It would probably be a bad idea for Golly to start generating fixed-width RLE itself, because that would cause subtle problems in a lot of people's pattern-handling code. But probably just being able to read broken numbers won't encourage people to generate fixed-width RLE all that much... right?

I didn't change the rle writer at all, just a one line change to the reader. If you think the fix might encourage unwise behavior then it's trivial to back out.

For reference, Golly's rle writer will keep lines less than 70 characters long and will never split a number.

ConwayLife.com

RLE linebreak parse error?

RLE linebreak parse error?

Re: RLE linebreak parse error?

Re: RLE linebreak parse error?

Re: RLE linebreak parse error?

Re: RLE linebreak parse error?