Help with opening a file with lines of RLE in Golly?

[Scorbie]

I'm currently working on a catalyst search program that currently outputs files like this:

Code: Select all

18$21bobo$22b2o$22bo4$36bo$35bobo$36bo3$36b2o$36b2o2$32b2o$32b2o31$
18$21bobo$22b2o$22bo4$35b2o$35bobo$36bo3$36b2o$36b2o2$32b2o$32b2o31$
18$21bobo$22b2o$22bo4$36b2o$35bobo$36bo3$36b2o$36b2o2$32b2o$32b2o31$
18$21bobo$22b2o$22bo2$36b2o$35bobo$35bo$34b2o4$36b2o$36b2o2$32b2o$32b2o31$
18$21bobo$22b2o$22bo2$32bo$32b3o$35bo$34b2o4$36b2o$36b2o2$32b2o$32b2o31$
18$21bobo$22b2o11bob2o$22bo10b3obo$32bo4bobo$32bob2ob2obo$33bobo4bo$35bob3o$34b2obo4$36b2o$36b2o2$32b2o$32b2o31$

Opening this from Linux works, and the pattern updates whenever the file updates.
However, on Windows, I can't get Golly to read this file, which makes it slightly inconvenient.
Any advice would be thankful. Thanks.

[dvgrn]

Opening this from Linux works, and the pattern updates whenever the file updates.
However, on Windows, I can't get Golly to read this file, which makes it slightly inconvenient.

Very odd! I can't duplicate this immediately. With Golly 3.3 on Windows 10 I can Open From Clipboard the text in the code box, or save it and Open it, or change the line endings to Linux-style line endings and it still opens without any apparent damage.

I seem to remember having run into some strange behavior with mixed line endings, though. Can you attach a sample file that won't open for you on Windows, instead of quoting it?

[Scorbie]

Opening this from Linux works, and the pattern updates whenever the file updates.
However, on Windows, I can't get Golly to read this file, which makes it slightly inconvenient.

Very odd! I can't duplicate this immediately. With Golly 3.3 on Windows 10 I can Open From Clipboard the text in the code box, or save it and Open it, or change the line endings to Linux-style line endings and it still opens without any apparent damage.

I seem to remember having run into some strange behavior with mixed line endings, though. Can you attach a sample file that won't open for you on Windows, instead of quoting it?

Thank you! Here's the file, and I can reproduce the behavior:

output.rle

(58.99 KiB) Downloaded 180 times

[dvgrn]

Here's the file, and I can reproduce the behavior...

Yup, that clears things up pretty well. Every other byte is an ASCII zero, pretty much:

Hex-listing-for-output-rle-file.png (48.9 KiB) Viewed 4554 times

So this is a UTF-16 little-endian Unicode text file. Find out why your code is saving data in that format instead of plain ASCII, and the mystery will be solved.

Please tell me when you figure it out. Maybe this is an encoding that will be showing up more and more often now -- e.g., maybe Python 3.x produces it it some circumstances? -- and we should figure out how to support it better in Golly. You're right that Golly doesn't open that file, either with or without the leading byte-order mark (FF FE). I just get a single ON cell at (0,0), either way. But when I copy and paste the text out of TextPad and into Golly, it works just fine.

[Scorbie]

Aha, thank you for clearing that up. Hopefully we won't be seeing that format often, as it was generated from C++ search code using `std::cout`. I'll try to find out how to make that code utf-8 - friendly. Thank you very much!!

Edit: a quick google search seems to reveal that on Windows, `std::cout` will tend to output UTF-16 in most circumstances, so I guess I'll stop using that...

Edit2: I think my terminal's code page was cp65001 (Windows' emulation of utf-8) Piping the output to `iconv -f cp65001 -t utf-8 -o output.rle` worked, but then the windows code page somehow became cp949, which somehow solved the problem by letting me not need the piping thing.
Anyway this could be useful for future reference, so just writing it down.