safeopenclip.lua usability issues

For scripts to aid with computation or simulation in cellular automata.
User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

safeopenclip.lua usability issues

Post by dvgrn » March 23rd, 2024, 7:58 pm

rowett wrote:
March 22nd, 2024, 5:34 pm
confocaloid wrote:
March 22nd, 2024, 3:52 pm
Suggestion: when the rule is changed from what was specified in the RLE, add the old rulename/rulestring in an additional autogenerated pattern comment line.
Done. Thanks for the suggestion!
This brought up another long-term Golly user-unfriendliness that's easy to improve on now, with this same script:

When a rule isn't available to Golly and needs to be installed, I think there isn't actually anything clear in the current Help files about the simplest way to do that. People sometimes end up creating text files in Golly's Rules folder, pasting rule contents from LifeWiki into them, renaming to .rule, possibly getting into trouble with not-quite-correct capitalization of the rule filename and getting weird errors, etc., etc.

The easy way to do a rule install is to copy the rule text to the clipboard and then hit Ctrl+Shift+O.

With the latest addition to safeopenclip.lua, the comments of the pattern that a user attempted to open with Alt+O will now include the most likely place to look for a rule definition, and also what to do once a rule definition has been copied to the clipboard.
#C Golly converted unsupported rule: TriRep
#C If you want Golly to support this rule, check for it at
#C https://conwaylife.com/w/index.php?titl ... action=raw
#C If the rule can be found there, copy the full text to your clipboard.
#C Load the rule into Golly by choosing File > Open Clipboard.
This seems to work pretty well for me now. The full set of steps is:

- copy unsupported-rule pattern to clipboard
- hit Alt+O in Golly
- click OK on the warning dialog
- hit 'i' to bring up pattern comments
- go to the URL given in the comments and copy out the rule definition
- hit Ctrl+Shift+O to load the rule.

The unsupported-rule pattern, which was successfully loaded and displayed in the "safe rule" Display256, will be cleanly converted back to the intended rule.

Next question
Where in Golly Help should we advertise this Alt+O behavior, so that there's some hope that new users would know to do all of this? Is this a new section under Hints and Tips, or possibly even a whole new page called something like "Loading and Converting Rules"?

It seems like it's probably a good idea to also advertise the Super-algo helper scripts better -- some kind of walkthrough outside of the algorithm sub-pages, about how to cleanly turn standard patterns into History, Super, or Investigator patterns, and vice versa.

User avatar
confocaloid
Posts: 3058
Joined: February 8th, 2022, 3:15 pm

Re: safeopenclip.lua usability issues

Post by confocaloid » March 23rd, 2024, 8:07 pm

dvgrn wrote:
March 23rd, 2024, 7:58 pm
With the latest addition to safeopenclip.lua, the comments of the pattern that a user attempted to open with Alt+O will now include the most likely place to look for a rule definition, and also what to do once a rule definition has been copied to the clipboard.
Unfortunately, as I understand this will also happen for unsupported rulestring notations that are not, and sometimes could not be, filenames.

Would there be a way to distinguish between cases when the specified string after "rule =" might plausibly be a filename for a ruletree/ruletable, versus cases when it is most likely a rulestring notation, and then show the additional advice only in the former case but not in latter case? Or just add a simpler generic advice always (i.e. mention the Rule: namespace on LifeWiki without trying to autogenerate URL which will be invalid anyway for rulestrings that aren't filenames)?
Last edited by confocaloid on March 24th, 2024, 8:57 am, edited 1 time in total.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.

User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: [Rule]Investigator support in Golly

Post by dvgrn » March 23rd, 2024, 8:52 pm

confocaloid wrote:
March 23rd, 2024, 8:07 pm
Would there be a way to distinguish between cases when the specified string after "rule =" might plausibly be a filename for a ruletree/ruletable, versus cases when it is most likely a rulestring notation, and then show the additional advice only in the former case but not in latter case? Or just add a simpler generic advice always (i.e. mention the Rule: namespace on LifeWiki without trying to autogenerate URL which will be invalid anyway for rulestrings that aren't filenames)?
If safeopenclip.lua were a Python script, it would be easy enough to check whether the auto-generated URL is valid -- and even download and install the rule semi-automatically (maybe after a yes/no prompt).

The embedded version of Lua doesn't have easy support for Internet access the way Python does -- Golly would have to include some additional libraries such as LuaSocket (I think).

So ... if there are known examples of rulestring notations that are likely to get opened with the new Alt+O, and especially if there are regular expressions that will match those rulestring notations but not match any existing rule names on the LifeWiki ... then we could certainly add some code to provide the advice only when it's likely to be needed.

Failing that, it's fairly simple to skip giving the advice when the rulestring includes any special characters like "/" that are never found in rule-table rule names. What's the full list of characters that would signal that the advice shouldn't be given?

Something that's not quite right yet...
#C If you want Golly to support this rule, check for it at
#C [https]://conwaylife.com/w/index.php?title=Rule:TriRep:T100,100&action=raw...
Bounded grids are handled elsewhere in the safeopenclip.lua code, but not in my addition. Will check in a fix for that shortly, and maybe throw in some kind of commonsense special-character exclusion while I'm at it.

EDIT: Here's the new commit.

User avatar
confocaloid
Posts: 3058
Joined: February 8th, 2022, 3:15 pm

Re: safeopenclip.lua usability issues

Post by confocaloid » March 23rd, 2024, 9:13 pm

dvgrn wrote:
March 23rd, 2024, 8:52 pm
Failing that, it's fairly simple to skip giving the advice when the rulestring includes any special characters like "/" that are never found in rule-table rule names.
Another usability issue is that "action=raw" should probably be changed to "action=edit". In your example, following the link index.php?title=Rule:TriRep&action=raw causes my web browser to download and save a file named 'index.php'.
(I know there must be a way to fix that somehow somewhere. But on the other hand, I also know that I can just replace 'raw' with 'edit' (the resulting link: index.php?title=Rule:TriRep&action=edit) and the browser will conveniently show the source code in a copyable form.)

Of course, URLs like this will not actually show as links in the "Pattern Info" window. So that's another usability issue.

Additionally, when a Golly user opens some pattern (e.g. via safeopenclip.lua), the pasted snippet may already have several lines of pattern comments which are actually related to the pasted pattern. So it might be undesirable to add too much autogenerated explanations to those already existing pattern comments.

So I think it would be a better solution to change safeopenclip.lua to add instead a short one-line suggestion (always the same, without any autogenerated links, whether "raw" or "edit") to go and look into a specific place in the Golly Help system, whenever the rule conversion failed. And then explain in the Golly Help all the details about how to deal with missing rules. That would also avoid complicating the source code and logic of the script, and also would avoid cluttering pattern comments when there are already relevant pattern comments copied from elsewhere.

I think a new section under Hints and Tips would work.
Last edited by confocaloid on March 24th, 2024, 8:58 am, edited 1 time in total.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.

User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: [Rule]Investigator support in Golly

Post by dvgrn » March 23rd, 2024, 10:21 pm

confocaloid wrote:
March 23rd, 2024, 9:13 pm
Another usability issue is that "action=raw" should probably be changed to "action=edit". In your example, following the link index.php?title=Rule:TriRep&action=raw causes my web browser to download and save a file named 'index.php'.
(I know there must be a way to fix that somehow somewhere. But on the other hand, I also know that I can just replace 'raw' with 'edit' (the resulting link: index.php?title=Rule:TriRep&action=edit) and the browser will conveniently show the source code in a copyable form.)
The "index.php" file that you download does contain the text of the rule file, so it should work pretty well to open that file in Notepad, Select All, and copy out the text.

I'm going to stick with "action=raw" at least for the moment, because that matches the LifeWiki's current standard links on every Rule page -- the "Click here to view this Rule without MediaWiki formatting, so that you can copy/paste it" links. They're intended to display the rule text, not download it, and every browser that I've tried except for Firefox does in fact display the rule text.

Firefox decided to do something different, only a couple of years ago, for security reasons. Maybe a good idea, but maybe not... there are certainly lots of hits on the Internet with people complaining about the change in 2022.

Now, "action=edit" is not really equivalent to "action=raw"; with "action=edit", anyone with a trusted flag will end up with a more complicated page that includes a "Save Changes" button -- functionality that we don't really want when the plan is just to retrieve the rule text. Whether they have a trusted flag or not, Ctrl-A or "Select All" will fail to select the correct text on an "action=edit" page, unless they click inside the text box ... whereas with "action=raw", they always get exactly the right text and no extraneous framing.
confocaloid wrote:
March 23rd, 2024, 9:13 pm
Of course, URLs like this will not actually show as links in the "Pattern Info" window. So that's another usability issue.
Agreed! I'd like to fix that -- there are a whole lot of "Reference" links in pattern comments now, and it would be very convenient to be able to just click on them. But that's a much bigger coding effort. It's something that I can't do anything about just by using this Lua prototyping method.

For Golly 4.3, we're in an early prototyping stage for this "safe open" functionality, showing what's possible, and/or showing what can be easily done that's much more convenient than what Golly natively does at the moment. It's possible that if this Lua prototype is enough of an improvement, a future Golly release will remove the need for the script by moving more of this functionality into Golly's native file-handling code.
confocaloid wrote:
March 23rd, 2024, 9:13 pm
So I think it would be a better solution to change safeopenclip.lua to add instead a short one-line suggestion (always the same, without any autogenerated links, whether "raw" or "edit")...
I suspect that it will be quite handy to have the URL all ready-built in the comments, for the use case where a missing rule is actually defined in the LifeWiki. I really think that that is going to be a very, very common use case. The advice only says

"If the rule can be found there, copy the full text to your clipboard."

That seems like a pretty good hint that the rule might or might not be found at that URL -- but that it's worth trying! Of course if people have another source for the rule, it's perfectly okay if they don't look in the pattern comments -- it's not like the advice is popping up in an annoying modal HTML window, getting in the way of what people really want to do. It's more something that can be there when people need it.
confocaloid wrote:
March 23rd, 2024, 9:13 pm
I think a new section under Hints and Tips would work.
This does seem like a good idea. It will take a bit of work to plan out -- it's not just the "safe open" functionality, it's the full story of all of these conversion scripts and key mappings. There's a lot that could be explained, e.g., about how to do the standard conversion to get rid of the blue cells in LifeHistory patterns. I know newcomers are often highly puzzled by this, and sometimes highly annoyed, if they think they have to manually erase blue cells one by one, before manually doing Control > Set Rule > B3/S23.

Most of the details that we have are currently hidden at the bottom of the Super algo Help document, which I think you can only get to inside Golly if you know to go to either Help > Algorithms or Control > Set Rule (counterintuitively, Control > Set Algorithm doesn't get you there.)

User avatar
confocaloid
Posts: 3058
Joined: February 8th, 2022, 3:15 pm

Re: safeopenclip.lua usability issues

Post by confocaloid » March 23rd, 2024, 10:42 pm

dvgrn wrote:
March 23rd, 2024, 10:21 pm
Now, "action=edit" is not really equivalent to "action=raw"; with "action=edit", anyone with a trusted flag will end up with a more complicated page [...]
Most Golly users are people without a LifeWiki account.
dvgrn wrote:
March 23rd, 2024, 10:21 pm
Whether they have a trusted flag or not, Ctrl-A or "Select All" will fail to select the correct text on an "action=edit" page, unless they click inside the text box ... whereas with "action=raw", they always get exactly the right text and no extraneous framing.
The way I see it, the "framing" is useful and not extraneous. The page says explicitly "You can view and copy the source of this page.", and there is an easy to see code box below, containing the code.
dvgrn wrote:
March 23rd, 2024, 10:21 pm
For Golly 4.3, we're in an early prototyping stage for this "safe open" functionality, showing what's possible, and/or showing what can be easily done that's much more convenient than what Golly natively does at the moment. It's possible that if this Lua prototype is enough of an improvement, a future Golly release will remove the need for the script by moving more of this functionality into Golly's native file-handling code.
Right. And specifically for this "early prototyping stage", I'm currently trying to understand the following things:
  • (a) whether or not I will be able to do reasonably comprehensive beta-testing of the resulting "safeopenclip.lua" script.
    (I did some testing of the "a15b84" version ("add original rule as pattern comment"), which was before these new changes with autogenerated links.)
    If the resulting script happens to have some complicated logic to make it hard to test comprehensively, well, no big deal, but it is something to keep in mind.
  • (b) whether or not I will want to use the resulting script myself, when the Golly 4.3 release appears. If the script becomes too complicated for me, well, no big deal again -- I'll just replace my copy with an older version of safeopenclip.lua which just shows the rulename/rulestring in comments and does nothing more complicated than that (because I already know anyway where to look for rules on LifeWiki).
dvgrn wrote:
March 23rd, 2024, 10:21 pm
confocaloid wrote:
March 23rd, 2024, 9:13 pm
I think a new section under Hints and Tips would work.
This does seem like a good idea. It will take a bit of work to plan out -- it's not just the "safe open" functionality, it's the full story of all of these conversion scripts and key mappings. There's a lot that could be explained, e.g., about how to do the standard conversion to get rid of the blue cells in LifeHistory patterns. I know newcomers are often highly puzzled by this, and sometimes highly annoyed, if they think they have to manually erase blue cells one by one, before manually doing Control > Set Rule > B3/S23.

Most of the details that we have are currently hidden at the bottom of the Super algo Help document, which I think you can only get to inside Golly if you know to go to either Help > Algorithms or Control > Set Rule (counterintuitively, Control > Set Algorithm doesn't get you there.)
This is exactly why I suggest to put this kind of explanations almost completely into Golly help, with only a brief suggestion regarding where to look for help left in the script. There are just too many details to be explained, unless you are already an experienced Golly user.
Last edited by confocaloid on March 24th, 2024, 8:59 am, edited 1 time in total.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.

User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: [Rule]Investigator support in Golly

Post by dvgrn » March 23rd, 2024, 11:06 pm

confocaloid wrote:
March 23rd, 2024, 10:42 pm
If the resulting script happens to have some complicated logic to make it hard to test comprehensively, well, no big deal, but it is something to keep in mind.
The added code is quite minimal -- it just generates the three extra comment lines that are quoted above. And now it seems to do it correctly for bounded grids.

Do you have any examples in mind of rule headers that will fail to load in Golly, but that do not refer to named rules found in the LifeWiki Rules namespace? If it turns out that the suggested URL is not going to be useful in the majority of cases, I'm perfectly happy to replace these comment lines with a reference to a Help document. (But I want to create the relevant Help document first -- and see what other use cases or bugs might turn up in the meantime).

For my own use of Golly over the past several years, where I've repeatedly hit this pain point where Golly refuses to open a pattern that I've copied to my clipboard and throws huge ugly errors ... that auto-generated URL would would have been useful to me something over 90% of the time, and wouldn't have gotten in the way in the slightest the other less-than-10% of the time. So I'm still thinking so far that I've got a good incremental improvement here.

For the Firefox-specific issue where the browser over-enthusiastically downloads things that shouldn't be downloaded, there does turn out to be an easy fix. The main one is the minor settings change described here -- in the hamburger menu, choose Settings, scroll down to Applications, and check the "Always ask" button instead of "Save files".

There's also a way to do a file association in Windows, which half works:
Firefox-settings-change.png
Firefox-settings-change.png (13.51 KiB) Viewed 554 times
Unfortunately the "Do this automatically" checkbox doesn't seem to have any effect in this particular case. I'm not sure why. But you can definitely get the "Open with Firefox" option to be the default, and when you click OK you get the relevant "action=raw" text displayed in Firefox, exactly the same as for any other browser (I checked Edge and Chrome on Windows 11).

User avatar
confocaloid
Posts: 3058
Joined: February 8th, 2022, 3:15 pm

Re: three extra comment lines

Post by confocaloid » March 24th, 2024, 2:28 am

It is useful to be able to view and copy the actual rulename/rulestring that was specified in the pasted pattern snippet. So, for example, a single-line message of the following form is useful for a human Golly user:

Code: Select all

#C Golly converted unsupported rule: R5,C0,S33-57,B34-45,NMHistory
From a human viewpoint, it is not hard to determine whether it was supposed to be a filename for a ruletable/ruletree, or a rulestring in some notation.

However, I don't consider the added "LifeWiki link advice" useful. It adds several more lines to comments (which may already contain other information that is actually relevant to the pattern); it gives a non-user-friendly "raw" link, instead of linking to a help page explaining what to do; it is an unnecessary dependency between Golly and the current LifeWiki rule storage system; it unnecessarily complicates the code.

---

If the "LifeWiki link advice" is considered useful, then I think it is cleaner to remove it by default, and then add the link only if the specified rule follows the conventions for rule names that are explained in Golly help:
Golly Help: File Formats wrote: When naming a new rule it's best to stick to the following conventions, especially if you'd like to share the .rule file with other Golly users:
  • Please capitalize all rule names and create files like Foo.rule rather than foo.rule. This helps to emphasize that rule names are important, especially on case-sensitive file systems. If the rule "foo" is specified inside a .rle or .mc file then Golly won't be able to find Foo.rule on a case-sensitive system like Linux.
  • To allow for possible future extensions in the way Golly handles rule names, it's best to use only letters and digits. Hyphens and underscores are also okay if you need some sort of separator. Hyphens can allow a set of related rules to share colors and/or icons (see below). Note in particular that spaces and colons must not be used.
^^ Instead of adding the LifeWiki link by default, and then trying to detect any of many situations when it should be removed/suppressed.

(There are many different unsupported rulestring notations. Someone certainly will invent a fresh new rulestring notation after Golly 4.3 is released.
There's just one recommended way to name rule files.
There are actual ruletables/ruletrees in the wild that don't follow those filename conventions. But I think there's no need to encourage breaking the conventions, by having the script link to various places like Rule:B1.;2;0,1,2,7,8 S1.;6,7,8-;;1,6,7,8 1T2.-;;1,6,7,8 S2.-;0,1,2,3,4,6,7 or R5,C0,S33-57,B34-45,NMHistory regardless of whether or not there is an actual rule posted there.)
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.

User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: three extra comment lines

Post by dvgrn » March 24th, 2024, 6:14 am

confocaloid wrote:
March 24th, 2024, 2:28 am
It is useful to be able to view and copy the actual rulename/rulestring that was specified in the pasted pattern snippet. So, for example, a single-line message of the following form is useful for a human Golly user:

Code: Select all

#C Golly converted unsupported rule: R5,C0,S33-57,B34-45,NMHistory
That line is still being generated and added. The only recent adjustment is that if there's a bounded-grid spec attached to the rule name, it isn't included (because the bounded grid presumably isn't the part that's unsupported).
confocaloid wrote:
March 24th, 2024, 2:28 am
If the "LifeWiki link advice" is considered useful, then I think it is cleaner to remove it by default, and then add the link only if the specified rule follows the conventions for rule names that are explained in Golly help...
That suggestion was implemented along with the bounded-grid adjustment, in the March 24 1:13AM UTC commit:
dvgrn wrote:
March 23rd, 2024, 8:52 pm
EDIT: Here's the new commit.

User avatar
confocaloid
Posts: 3058
Joined: February 8th, 2022, 3:15 pm

Re: safeopenclip.lua usability issues

Post by confocaloid » March 24th, 2024, 6:48 am

I suggest to move safeopenclip.lua-specific posts into a separate thread, to avoid cluttering this thread.
dvgrn wrote:
March 24th, 2024, 6:14 am
confocaloid wrote:
March 24th, 2024, 2:28 am
If the "LifeWiki link advice" is considered useful, then I think it is cleaner to remove it by default, and then add the link only if the specified rule follows the conventions for rule names that are explained in Golly help...
That suggestion was implemented along with the bounded-grid adjustment, in the March 24 1:13AM UTC commit:
dvgrn wrote:
March 23rd, 2024, 8:52 pm
EDIT: Here's the new commit.
To clarify: if the three-line "LifeWiki link advice" is still considered a useful addition, then I am suggesting to keep it disabled, unless the specified rule follows existing conventions for rule filenames. There should be just letters, digits, hyphens and underscores in the specified rule.

In the commit you linked to, the script does not do what I suggested, but instead attempts to do the reverse. It keeps the three-line extra advice enabled, unless the script can detect some kind of unsupported character. This kind of detection cannot be done in a satisfactory way, because there will always be unsupported rulestring notations not covered by the detection code.

I don't consider those three extra comment lines useful in any case. In my view, they are not an improvement.
  • The pattern comments may already contain multiple lines of other relevant useful information about the pattern. It is undesirable to add too much autogenerated lines to existing pattern comments.
  • The "raw" link is not user-friendly. It can become long; it requires several awkward steps ("copy the link", "paste into browser", and then either "understand how to deal with the browser downloading the file index.php" or "understand what to do with the opened gibberish"), which are hard to do correctly when you're a human Golly user without several years of experience.

    There should be instead a brief single-line link or mention of a help page in Golly help system. That mentioned page should explain all the details about what to do with unsupported rules.
  • The link is an unnecessary dependency between Golly and the current LifeWiki rule storage system.
  • Adding the functionality unnecessarily complicates the code of the script, making it hard to test and debug.
Last edited by confocaloid on March 24th, 2024, 9:01 am, edited 1 time in total.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.

User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: three extra comment lines

Post by dvgrn » March 24th, 2024, 7:07 am

confocaloid wrote:
March 24th, 2024, 6:48 am
In the commit you linked to, the script does not do what I suggested, but instead attempts to do the reverse. It keeps the three-line extra advice enabled, unless the script can detect some kind of unsupported character. This kind of detection cannot be done in a satisfactory way, because there will always be unsupported rulestring notations not covered by the detection code.
The extra link and advice will only appear if the rulestring doesn't contain any of these special characters:

/\<>,."'{}[]!@#$%^&*()+=

Could either add a few more characters to that list, like |~`? -- or else change the matching pattern to "[^%w%-_]" and limit rule names specifically to only alphanumeric characters plus hyphens and underscores.

In practice the two ways of doing that test will almost always give the same results -- e.g., the example rulestrings "R5,C0,S33-57,B34-45,NMHistory" and "B1.;2;0,1,2,7,8 S1.;6,7,8-;;1,6,7,8 1T2.-;;1,6,7,8 S2.-;0,1,2,3,4,6,7" won't generate the link advice.

The only odd exceptions I've found in a scan of rule names so far is Rule:ExtendedLife^2, and several rules containing plus signs such as Rule:Fireworld+. So maybe in practice it's better to leave out + and ^ from the list of characters that signal a non-name.
confocaloid wrote:
March 24th, 2024, 6:48 am
I don't consider those three extra comment lines useful in any case. In my view, they are not an improvement.
You have clearly stated your opinion on this point. I understand and acknowledge your opinion. However, the three extra comment lines -- or four now, counting the link -- will be very useful to me (and, I strongly suspect, to other users of Golly ranging from newcomers to oldtimers). It's not clear to me how those new comment lines will do you any measurable harm. If you don't want to use the links, then don't use them.

User avatar
confocaloid
Posts: 3058
Joined: February 8th, 2022, 3:15 pm

Re: safeopenclip.lua usability issues

Post by confocaloid » March 24th, 2024, 8:36 am

dvgrn wrote:
March 24th, 2024, 7:07 am
Could either add a few more characters to that list, like |~`? -- or else change the matching pattern to "[^%w%-_]" and limit rule names specifically to only alphanumeric characters plus hyphens and underscores.
I think it is simpler and cleaner to limit the rule filename to follow existing conventions, by stating the conventions directly.
If "+" and/or "^" are also considered acceptable in Golly rule filenames, then include them explicitly as well.
dvgrn wrote:
March 24th, 2024, 7:07 am
It's not clear to me how those three new comment lines will do you any measurable harm. If you don't want to use the links, then don't use them.
What I consider "harm" (i.e. significant disadvantages of adding those "instruction" comments and the raw wiki link) are
  • (a) these lines clutter pattern comments. The more is added, the harder it is to understand what is going on. The instructions belong to help system.
  • (b) this introduces an awkward workflow that would involve copy&pasting a long URL into a browser, followed sometimes by dealing with browser differences, followed by dealing with lack of any explanations on the opened "raw" page.
    As far as I can tell, that sequence of steps leads to bad user experience. Which is bad.
  • (c) Unnecessary dependency on the current LifeWiki rule storage system. A pattern may be copied from a page or post that already contains the ruletable. The ruletable may even be already present in the same snippet, appended to the RLE.
  • (d) Testability.
For getting the ruletable from LifeWiki, it feels much easier to open LifeWiki in the browser, enter "Rule:InsertTheRulenameHere" in the search bar, and if the rule exists, then go to the "view source" page and copy the ruletable/ruletree from there. (In particular, the short rule filename is easier to copy than the long URL.)

I'm not saying this sequence of steps is the best possibility (it is not). However I'm pretty sure it would be an improvement over bloating the pattern comments with autogenerated instructions and having to copy and open a long raw URL.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.

User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: safeopenclip.lua usability issues

Post by dvgrn » March 24th, 2024, 10:02 am

Just noticed that the "safeheader" definition in the current script doesn't preserve the bounded-grid suffix from the original rule, if there is one.

Any thoughts on appending the bounded-grid suffix, if any, to the "Display256" safe rule? Are there situations where the bounded grid will work for some other rule, but will fail for the Display256 rule?

There's certainly a possible case where it's actually the bounded-grid suffix that's causing the pattern load to fail. I'm thinking it should be workable to append the bounded-grid suffix to "Display256", try to open that version of the pattern -- and then, if that fails, just open the plain "Display256" version instead.

This extra step seems worthwhile to me, because for the usual situation where the rule is currently unsupported but the bounded-grid suffix is valid, opening a bounded-grid view gives a much better sense of what the pattern is supposed to look like.

Unfortunately, if the rule table is then loaded to Golly (following the support-advice comments, or by some other method) the bounded Display256 pattern won't directly convert to the correct intended form -- the bounded grid-view is lost when the rule table is applied to the current universe. However, the next time the original bounded pattern is loaded, either with Alt+O or with Ctrl+Shift+O or just plain File > Open, the bounded grid will show up correctly at that point.

(The disappearance of the bounded grid when the rule is applied... can't be affected by the Lua script, so it's beyond the scope of this current "safe open" Lua prototype. I'm thinking it's a fairly minor edge case anyway, with an easy workaround.)

Anyway, here's the latest checkin. The matching pattern is now "[^%w%-%^%+_]" -- i.e., the link advice won't show up unless the rule consists only of alphanumeric characters plus hyphens, carets, plus signs, and underscores. The comments now look like this (for an "ExtendedLife^2" rule example where that .rule file isn't loaded in local Golly):
#C {any original pattern comments here}
#C
#C COMMENT ADDED BY GOLLY: converted unsupported rule 'ExtendedLife^2'.
#C If you want Golly to support this rule, check for it at
#C https://conwaylife.com/w/index.php?titl ... action=raw
#C If the rule can be found there, copy the full text to your clipboard.
#C Then load the rule into Golly by choosing File > Open Clipboard.
Here's the full current script -- EDIT: updated to Chris Rowett's version 1.2 on 3/27/2024 -- in case anyone wants to test it out without extracting it from SourceForge:

Code: Select all

-- Safely open a pattern from the clipboard in a safe 256 state rule
-- If the pattern has a known legacy rule then convert it
--
-- Author: Chris Rowett, March 2024
--   some code adapted from toChangeState.lua by Dave Greene
--   v.1.1:  include in added comments a link to likely LifeWiki location for missing rule, when appropriate
--   v.1.2:  support bounded grids, detect invalid pattern data, help window with LifeWiki rule download link

local g = golly()
local gp = require "gplus"

local tempname = "safeopenclip.rle"   -- temporary pattern file name
local helpname = "safeopenclip.html"  -- rule help html file name
local saferule = "Display256"         -- safe 256 state rule

-- list of legacy rule to new rule mappings with optional list of state conversion pairs
--   [<legacy name>] = {rule = <new name>, map = {<from>, <to>, ...}}
-- note: <legacy name> must be in lower case
local mappings = {
    ["extendedlife"] = {rule = "B3/S23Investigator", map = {2, 9, 4, 14, 6, 4}},
    ["extendedtlife"] = {rule = "B3/S23-i34qInvestigator", map = {2, 9, 4, 14, 6, 4}},
    ["stateinvestigator"] = {rule = "B3/S23Investigator", map = {}},
    ["leapinvestigator"] = {rule = "B2n3/S23-qInvestigator", map = {}},
    ["eightinvestigator"] = {rule = "B3/S238Investigator", map = {}},
    ["pedestrianinvestigator"] = {rule = "B38/S23Investigator", map = {}},
    ["merryinvestigator"] = {rule = "B3-eq4ciqt5ky/S2-c3-k4yz5i8Investigator", map = {}}
}

-- help text used when the clipboard contains a pattern with an unsupported rule
local helptext =
[[
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFCE">
<title>Rule Help</title>
<h2>Unsupported Rule</h2>
<p>
The clipboard contains a pattern with an unsupported rule <b>RULENAME</b> so it has been opened in a safe rule.
</p>
<p>
If you want Golly to support this rule then it may already exist in the <a href="https://www.conwaylife.com/w/index.php?title=Special:AllPages&namespace=3794&from=">LifeWiki rule repository</a>.
</p>
<p>
Clicking the link below will download and install the rule if it exists or display "Web request failed" if it doesn't.
</p>
<p>
<a href=get:https://www.conwaylife.com/rules/RULENAME.rule>https://www.conwaylife.com/rules/RULENAME.rule</a>
</p>
</body>
</html>
]]

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

local function swapcells(rect, map)
    -- check if there are cells to change and a mapping
    if #rect > 0 and #map > 0 then
        -- build the map
        local i
        local newstate = {}
        for i = 0, 255 do
            newstate[i] = i
        end

        i = 1
        while i < #map do
            newstate[map[i]] = map[i + 1]
            i = i + 2
        end

        -- get the bounding box
        local minx, miny, sizex, sizey = table.unpack(rect)
        local maxx = minx + sizex - 1
        local maxy = miny + sizey - 1

        -- get the list of non-zero cells
        local cells = g.getcells(rect)
        local numcells = #cells
        local newstate0 = newstate[0]

        -- if state 0 has changed then need to use the gaps in the cell list
        if newstate0 ~= 0 then
            local x = minx
            local y = miny
            local nextx, nexty
            local total = sizex * sizey
            local oldsecs = os.clock()
            local newsecs

            for i = 1, numcells, 3 do
                -- get the next non-zero cell location
                nextx = cells[i]
                nexty = cells[i + 1]

                -- cell states are 0 until the next non-zero cell is reached
                while x < nextx or y < nexty do
                    g.setcell(x, y, newstate0)
                    x = x + 1
                    if x > maxx then
                        x = minx
                        y = y + 1

                        -- might be large pattern so show percentage done each second
                        newsecs = os.clock()
                        if newsecs - oldsecs >= 1.0 then
                            oldsecs = newsecs
                            g.show("Changing cell states: "..string.format("%.1f", 100 * ((y - miny) * sizex) / total).."%")
                            g.update()
                        end
                    end
                end

                -- convert the non-zero cell
                g.setcell(nextx, nexty, newstate[cells[i + 2]])
                x = x + 1
                if x > maxx then
                    x = minx
                    y = y + 1
                end
            end

            -- process any final state 0 cells on the last line
            if y <= maxy then
                while x <= maxx do
                    g.setcell(x, y, newstate0)
                    x = x + 1
                end
            end
        else
            -- no state 0 change so just convert each non-zero cell
            for i = 1, numcells, 3 do
                g.setcell(cells[i], cells[i + 1], newstate[cells[i + 2]])
            end
        end
    end
end

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

local function getclipboard()
    -- the optional non-zero parameter to g.getclip suppresses the Golly
    -- warning if the clipboard can not be opened
    g.getclip(1)
end

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

local function openrulehelp(rule)
    -- create an HTML page
    local filename = g.getdir("temp")..helpname
    local file, msg = io.open(filename, "w")
    if file == nil then
        g.note("Could not create temporary help file!n\n"..msg)
    else
        -- put the rule name into the help text and write to the HTML file
        helptext = helptext:gsub("RULENAME", rule)
        file:write(helptext)
        file:close()

        -- open temporary file containing rule help
        g.open(filename)
    end
end

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

local function openpattern(text, rule, bounded, message)
    -- write the contents out to a temporary file
    local filename = g.getdir("temp")..tempname
    local file, msg = io.open(filename, "w")
    if file == nil then
        g.note("Could not create temporary pattern file!n\n"..msg)
    else
        file:write(text)
        file:close()

        -- open temporary file containing pattern
        g.open(filename)

        -- if a rule was found then see if it is in the list to convert
        if rule ~= "" then
            -- see if there is a mapping for the rule
            local mapping = mappings[rule:lower()]
            if mapping ~= nil then
                -- mapping found so convert states and switch to new rule
                swapcells(g.getrect(), mapping.map)

                -- add back any bounded grid definition to the new rule
                g.setrule(mapping.rule..bounded)

                -- display the canonical name of the new rule
		    local newrule = g.getrule()
		    local boundedpos = newrule:find(":")
		    if newrule:find(":") ~= nil then
                    newrule = newrule:sub(1, boundedpos - 1)
		    end
                message = "Converted pattern from rule "..rule.." to "..newrule..".  "..message
            end
        end
    end

    -- update status if needed
    if message ~= "" then
        g.show(message)
    end
end

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

local function checkpattern(text, rule, bounded)
    local result = false
    local original = text

    -- check if the pattern contains a rule
    if rule ~= "" then
        -- create a safe pattern in the rule
        text = "x=1,y=1,rule="..rule..bounded.."\no!"

        -- set the clipboard to the modified pattern
        g.setclipstr(text)

        -- check if the clipboard can be opened
        if pcall(getclipboard) then
            result = true
        end

        -- restore the original clipboard contents
        g.setclipstr(original)
    end

    return result
end

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

local function trynewrule(text, rule, headerstartpos, headerendpos, rulepos)
    local result = false
    local original = text

    -- replace the original rule with the new one
    text = text:sub(1, headerstartpos + rulepos - 2).."rule="..rule..text:sub(headerendpos)

    -- set the clipboard to the modified pattern
    g.setclipstr(text)

    -- check if the clipboard can be opened
    if pcall(getclipboard) then
        result = true
    end

    -- restore the original clipboard contents
    g.setclipstr(original)

    return result
end

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

local function safeopen()
    -- get the clipboard text
    local text = g.getclipstr()
    local rulepos = nil
    local rule = ""
    local boundedpos = nil
    local bounded = ""
    local headerstartpos = nil
    local headerendpos = nil
    local header = ""

    -- remove leading blank lines
    text = text:gsub("^%s+", "")

    -- find the header line
    headerstartpos = text:find("x[= ]")
    if headerstartpos ~= nil then
        headerendpos = text:find("[\r\n]", headerstartpos)
        if headerendpos == nil then
            headerendpos = #text + 1
        end
        header = text:sub(headerstartpos, headerendpos - 1)

        -- find the rule in the header line
        rulepos = header:find("rule%s*=")
        if rulepos ~= nil then
            rule = header:sub(rulepos):gsub("rule%s*=%s*", ""):gsub(" *$", "")

            -- check for bounded grid
            boundedpos = rule:find(":")
            if boundedpos ~= nil then
                bounded = rule:sub(boundedpos)
                rule = rule:sub(1, boundedpos - 1)
            end

            header = header:sub(1, rulepos - 1)
        end
    end

    -- check if the clipboard can be loaded
    if not pcall(getclipboard) then
        -- check if the pattern data is valid
        if rule == "" or not checkpattern(text, saferule, "") then
            -- pattern data is invalid
            g.note("The pattern in the clipboard contains invalid data and can not be opened.\n\nClick OK to see details or Cancel to abort.")

            -- if the user didn't cancel then attempt to open the clipboard so the detailed Golly error can be seen
            openpattern(text, rule, bounded, "")
        else
            -- check if there is a mapping available for the rule
            local mapping = mappings[rule:lower()]
            if mapping ~= nil then
                -- check if the clipboard can be loaded with the mapping
                if trynewrule(text, mapping.rule..bounded, headerstartpos, headerendpos, rulepos) then
                    -- the pattern is valid with the mapping so open it
                    text = text:sub(1, headerstartpos + rulepos - 2).."rule="..mapping.rule..bounded..text:sub(headerendpos)
                    openpattern(text, rule, bounded, "")
                else
                    -- check if there was a bounded grid and if so attempt to open the clipboard without it
                    if bounded ~= "" and trynewrule(text, mapping.rule, headerstartpos, headerendpos, rulepos) then
                        -- the pattern is valid with the mapping but without the bounded grid so ask for permission to change
                        g.note("The pattern in the clipboard contains a legacy rule with an invalid bounded grid definition.\n\nRule: "..rule..bounded.."\n\nPress OK to convert to a supported rule without the bounded grid or Cancel to abort.")

                        -- if the user didn't cancel then open the pattern without the bounded grid
                        text = text:sub(1, headerstartpos + rulepos - 2).."rule="..mapping.rule..text:sub(headerendpos)
                        openpattern(text, rule, "", "Invalid bounded grid definition removed ("..bounded..").")
                    end
                end
           else
                -- no mapping available so check if the clipboard can be loaded without the bounded grid
                if bounded ~= "" and trynewrule(text, rule, headerstartpos, headerendpos, rulepos) then
                    -- the pattern is valid without the bounded grid so ask for permission to change
                    g.note("The pattern in the clipboard contains a rule with an invalid bounded grid definition\n\nRule: "..rule..bounded.."\n\nPress OK to open without the bounded grid or Cancel to abort.")

                    -- if the user didn't cancel then open the pattern without the bounded grid
                    text = text:sub(1, headerstartpos + rulepos - 2).."rule="..rule..text:sub(headerendpos)
                    openpattern(text, rule, "", "Invalid bounded grid definition removed ("..bounded..").")
                else
                    -- if there is a bounded grid definition then check the safe rule can be opened with it
                    if bounded ~= "" and not trynewrule(text, saferule..bounded, headerstartpos, headerendpos, rulepos) then
                        -- the pattern is valid with the mapping but without the bounded grid so ask for permission to change
                        g.note("The pattern in the clipboard contains an unsupported rule with an invalid bounded grid definition.\n\nRule: "..rule..bounded.."\n\nPress OK to convert to a safe rule without the bounded grid or Cancel to abort.")

                        -- if the user didn't cancel then open the pattern without the bounded grid
                        text = text:sub(1, headerstartpos + rulepos - 2).."rule="..saferule..text:sub(headerendpos)
                        openpattern(text, saferule, "", "Opened pattern in safe rule. Invalid bounded grid definition removed ("..bounded..").")
                    else
                        -- the clipboard can't be opened so ask for permission to convert to the safe rule
                        g.note("The pattern in the clipboard contains an unupported rule.\n\nRule: "..rule..bounded.."\n\nPress OK to open in a safe rule or Cancel to abort.")

                        -- if the user didn't cancel then open the pattern in the safe rule
                        text = text:sub(1, headerstartpos + rulepos - 2).."rule="..saferule..bounded..text:sub(headerendpos)
                        openpattern(text, saferule, bounded, "Opened pattern in safe rule.")
                    end

                    -- show Rule Help if the rule looks like a named rule rather than a rulestring
                    if rule ~= "" then
                        local ruleadvice = ""
                        if rule:find("[^%w%-%^%+_]") == nil then
                            -- make the allowable characters URL-safe
                            ruleurlsafe = rule:gsub("%+", "%%%%2B"):gsub("%^", "%%%%5E")

                            -- open the help page
                            openrulehelp(ruleurlsafe)
                        end
                    end
                end
            end
        end
    else
        -- clipboard contains a valid pattern so open it
        openpattern(text, rule, bounded, "")
    end
end

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

local status, err = xpcall(safeopen, gp.trace)
if err then g.continue(err) end
-- the following code is always executed

-- ensure the following code *completes*, even if user quits Golly
g.check(false)

User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: safeopenclip.lua usability issues

Post by dvgrn » March 24th, 2024, 12:39 pm

confocaloid wrote:
March 24th, 2024, 8:36 am
[*] (a) these lines clutter pattern comments. The more is added, the harder it is to understand what is going on. The instructions belong to help system.
The idea of cluttering pattern comments with extra added lines was originally yours, not mine. Once the script is adding a new comment line anyway, it doesn't seem to me like adding a few more will cause any additional confusion. Quite the opposite: the new lines will quite often contain very useful and relevant information.

However, people will still have to know to look in the pattern comments before any of this is even slightly relevant.

There's yet another ancient usability issue related to this: newcomers to Golly may quite often spend weeks or months looking through the pattern collection, without even realizing that there are associated comments to look at at all. It's not like the GUI changes in a very noticeable way when a pattern-with-comments has been opened -- the mysterious "i" button is greyed out for a pattern-without-comments, but that's not very noticeable given that the patterns in Golly's collection always have comments. There's not much that really pushes people toward clicking the "i" (if the toolbar is even visible) or hitting Ctrl+I, among all the other things the GUI is suggesting for them to do.

One thing we might do to partially address this would be to add a g.show() Lua command to leave a note in Golly's status bar after the script finishes executing, telling a user to try Ctrl+I / go look in the pattern comments ... maybe only if a link and instructions have been added there.

If the rulestring doesn't look like a named rule, then that status-bar readout might be a good (additional? alternative?) place to put the "safeopenclip.lua has converted the unsupported rule '{RULENAME}' to Display256" message.
confocaloid wrote:
March 24th, 2024, 8:36 am
I think it is simpler and cleaner to limit the rule filename to follow existing conventions, by stating the conventions directly.
If "+" and/or "^" are also considered acceptable in Golly rule filenames, then include them explicitly as well.
If nobody objects, then that will be an easy update to the existing conventions document that you pointed out. I'll just wait a week or two and see if anyone turns up any other special characters that it would make sense to specifically allow in rule names.

Another idea
Lua scripts can't affect the "Pattern Info" window, to make added link text into clickable text.

However, something that Lua scripts can do is to create and then open HTML files. They show up (usually) as pop-up windows. That's what the "h-to-h-collection-26Aug2017.lua" script does, inside the Patterns/Signal-Circuitry/h-to-h-collection-26Aug2017.zip file.

We've now got a safeopenclip.lua script that knows the difference between rulestrings that are probably going to turn out to be stored in the LifeWiki Rule namespace, versus rulestrings that aren't valid rule names.

For the "probably stored on LifeWiki" case -- given that this safe-open script is specifically intended as a better way of dealing with possibly problematic rulestrings in clipboard patterns... maybe the most useful thing that the script can do is to pop up an HTML window containing a probably-working link to the LifeWiki rule, plus a clear set of instructions about how to get the rule loaded into Golly.

That way there's no need to add any of that stuff to the pattern comments -- could leave them completely unchanged, unless it still seems like a good idea to add the "#C COMMENT ADDED BY GOLLY: converted unsupported rule 'ExtendedLife^2'." line to comments. (Theoretically that information could show up in an HTML pop-up instead ... though I might be inclined to skip the potentially annoying HTML pop-up unless there's some kind of likely URL and associated useful advice to give.)
confocaloid wrote:
March 24th, 2024, 8:36 am
(b) this introduces an awkward workflow that would involve copy&pasting a long URL into a browser, followed sometimes by dealing with browser differences, followed by dealing with lack of any explanations on the opened "raw" page.
As far as I can tell, that sequence of steps leads to bad user experience. Which is bad.
(c) Unnecessary dependency on the current LifeWiki rule storage system. A pattern may be copied from a page or post that already contains the ruletable. The ruletable may even be already present in the same snippet, appended to the RLE.
(d) Testability.
For completeness, I should maybe mention that I don't find any of these bullet points to be particularly compelling.

For (b), I totally agree that it's an imperfect user experience. The thing is, it's still a huge improvement over the existing Golly 4.2 bad user experience, which involves users not being given any information about where to find a missing rule, or what exactly to do once the missing file is found. The "obvious" thing to do -- manually create and populate a .rule file, and save it to Golly's Rules folder -- is several awkward steps longer than the quickest way, but it's extremely unlikely that anyone will figure that out from the existing Help documents.

For (c), we've collectively done a whole pile of work on the LifeWiki rule storage system. One of the effects of all of that good work is that the LifeWiki Rule namespace is a really highly likely place to find rules. People tend to make sure that rule definitions are added into the Rule namespace, because that way LifeViewer can simulate patterns posted to the forums that use those rules. It's an enormously more convenient system than, say, the old Rule Table Repository. We should be doing everything we can to nudge people toward the current rule storage system. Sure, maybe some future rule storage system will someday come along that's even better -- but it seems quite unlikely in the foreseeable future.
The time to think about that will be when it actually happens.

For (d), safeopenclip.lua represents new functionality, for sure. It needs to be tested. The script was already adding a comment line to the pattern being opened; all I did was add four more lines. There's pretty much zero net effect, unless someone decides to actually look at the comments and then try following the instructions.

Those added lines are more helpful than any instructions that the average user has any obvious way of obtaining otherwise.

Long story short: at least until somebody actually gets around to writing a whole new "Loading and Converting Rules" section and adding it to Golly's Help, I'm reasonably confident that those lines are good things to provide to users, one way or another.

User avatar
confocaloid
Posts: 3058
Joined: February 8th, 2022, 3:15 pm

Re: safeopenclip.lua usability issues

Post by confocaloid » March 24th, 2024, 1:55 pm

dvgrn wrote:
March 24th, 2024, 12:39 pm
Once the script is adding a new comment line anyway, it doesn't seem to me like adding a few more will cause any additional confusion. Quite the opposite: the new lines will quite often contain very useful and relevant information.
That is one of points where we disagree. I think adding one comment line to give the original rule name in a readable and copyable way is an improvement. I still think that adding several more comment lines giving detailed LifeWiki-rule-storage-related instructions and a "raw" wiki link is problematic.
dvgrn wrote:
March 24th, 2024, 12:39 pm
If the rulestring doesn't look like a named rule, then that status-bar readout might be a good (additional? alternative?) place to put the "safeopenclip.lua has converted the unsupported rule '{RULENAME}' to Display256" message.
"Alternative" certainly will not work, because the rulestring/rulename will not be copyable from the status bar.

"Additional" may be slightly helpful. But then again, the user may see that message and attempt to re-type the rulestring/rulename from the status bar, without knowing that they can just go to pattern comments and copy the original rule directly from there instead of retyping it manually.

Maybe instead add a status bar message along the lines "Unknown rule; the pattern is converted to a default 256-state rule; go to View -> Pattern Info to get the original rulestring".
dvgrn wrote:
March 24th, 2024, 10:02 am
[...] This extra step seems worthwhile to me, because for the usual situation where the rule is currently unsupported but the bounded-grid suffix is valid, opening a bounded-grid view gives a much better sense of what the pattern is supposed to look like. [...]
Currently I see one possible reason to avoid doing that (extra complexity), but that may be because I'm missing something one way or another.

Code: Select all

#C With 'FileHistory' changed to 'LifeHistory', this snippet
#C can be loaded correctly (either via Shift+Ctrl+O or via Alt+O).
#C When loaded via Alt+O as is, it gets converted to Display256
#C (without a bounded-grid suffix). Then going to "Set Rule"
#C and manually specifying the bounds 'Display256:T41,19'
#C results in an empty pattern, with message
#C "Pattern was truncated (live cells were outside grid)."
#C Reference:
#C https://conwaylife.com/forums/viewtopic.php?p=180969#p180969
x = 41, y = 19, rule = FileHistory:T41,19
7$24.D11.2A$36.2A6$31.A$31.A.A$31.3A$33.A!
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.

User avatar
confocaloid
Posts: 3058
Joined: February 8th, 2022, 3:15 pm

Re: safeopenclip.lua usability issues

Post by confocaloid » March 24th, 2024, 2:48 pm

dvgrn wrote:
March 24th, 2024, 12:39 pm
confocaloid wrote:
March 24th, 2024, 8:36 am
I think it is simpler and cleaner to limit the rule filename to follow existing conventions, by stating the conventions directly.
If "+" and/or "^" are also considered acceptable in Golly rule filenames, then include them explicitly as well.
If nobody objects, then that will be an easy update to the existing conventions document that you pointed out. I'll just wait a week or two and see if anyone turns up any other special characters that it would make sense to specifically allow in rule names.
I wrote "if". I have some doubts re: whether or not to accept "+" and/or "^" in rule filenames. E.g. those characters can have special meanings, and can affect selectability. Does it seem a particularly bright idea to encourage rule filenames like Rule:Long^3_boat++ or Rule:a^2+b^2-c^2? For these two examples, the generated "raw" URL become

Code: Select all

https://conwaylife.com/w/index.php?title=Rule:Long%5E3_boat%2B%2B&action=raw
https://conwaylife.com/w/index.php?title=Rule:a%5E2%2Bb%5E2-c%5E2&action=raw
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.

User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: safeopenclip.lua usability issues

Post by dvgrn » March 24th, 2024, 3:44 pm

confocaloid wrote:
March 24th, 2024, 1:55 pm
Maybe instead add a status bar message along the lines "Unknown rule; the pattern is converted to a default 256-state rule; go to View -> Pattern Info to get the original rulestring".
Yup, something along those lines seems like the important info to put in the status bar.

It might not be necessary, though; let's see what can be done with a pop-up HTML page with a clickable link.
confocaloid wrote:
March 24th, 2024, 1:55 pm
Currently I see one possible reason to avoid doing that (extra complexity)...
Code complexity? I'd say don't bother worrying about that for the moment. This is all fairly basic parsing and error-catching, nothing too terribly difficult. The complicated thing is coming up with all the different variations of rule headers and pattern types to test -- but we'll need as wide a set of test cases as we can think of, anyway, almost no matter what functionality we decide to add to the script.
#C With 'FileHistory' changed to 'LifeHistory', this snippet
#C can be loaded correctly (either via Shift+Ctrl+O or via Alt+O).
#C When loaded via Alt+O as is, it gets converted to Display256
#C (without a bounded-grid suffix). Then going to "Set Rule"
#C and manually specifying the bounds 'Display256:T41,19'
#C results in an empty pattern, with message
#C "Pattern was truncated (live cells were outside grid)."
I think I mostly understand this one -- I ran into something similar with

Code: Select all

x = 1, y = 1, rule = Display256:T10,10
9o!
versus

Code: Select all

x = 10, y = 10, rule = Display256:T10,10
9o!
It turns out that the x and y values that are given for a pattern will affect where the pattern is placed in a bounded grid. If the bounding-box numbers are smaller than the bounded-grid numbers, then the pattern gets centered (and may then get truncated). But if the bounding-box numbers match the bounded-grid numbers, then the pattern shows up starting in the upper left-hand corner of the bounded grid (and then it doesn't get truncated).

When Chris wrote the safeopenclip.lua script, he chose an "x = 1, y = 1, rule = Display256" header line for the "safe" RLE. Maybe when bounded grids are involved, that's not entirely safe after all? Have to do a bit more experimenting here. It's not clear yet what if anything we can reasonably do about that behavior.

User avatar
Andrew
Moderator
Posts: 935
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: safeopenclip.lua usability issues

Post by Andrew » March 25th, 2024, 1:48 am

dvgrn wrote:
March 24th, 2024, 3:44 pm
It might not be necessary, though; let's see what can be done with a pop-up HTML page with a clickable link.
I think it makes a lot of sense to do that. Gives you a lot more flexibility. For example, you could easily display any comments in the pattern file (see this script for example).

You could also use Golly's "get:url" feature to download a .rule file and switch to that rule. This requires the url to end in ".rule" so it might be necessary to ask Nathaniel to write a little script to periodically store all the current rule info in .rule files somewhere on conwaylife.com. Hopefully a simple modification of his script that builds all the .rle files for the LifeWiki Pattern Archive used by Golly. (As an aside, it would then be trivial to create a LifeWiki Rule Archive so Golly users could download and install any of those .rule files.)
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

User avatar
rowett
Moderator
Posts: 3823
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: safeopenclip.lua usability issues

Post by rowett » March 25th, 2024, 7:01 am

dvgrn wrote:
March 24th, 2024, 3:44 pm
When Chris wrote the safeopenclip.lua script, he chose an "x = 1, y = 1, rule = Display256" header line for the "safe" RLE. Maybe when bounded grids are involved, that's not entirely safe after all? Have to do a bit more experimenting here. It's not clear yet what if anything we can reasonably do about that behavior.
This is deliberate. If there is an error in the bounded grid definition and it's carried across to the safe rule then the pattern still won't open.

User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: safeopenclip.lua usability issues

Post by dvgrn » March 25th, 2024, 7:44 am

rowett wrote:
March 25th, 2024, 7:01 am
This is deliberate. If there is an error in the bounded grid definition and it's carried across to the safe rule then the pattern still won't open.
What do you think of the two-stage approach? Try opening the safe rule with the bounded-grid suffix, and then if that doesn't work, try the safe rule with no suffix?

User avatar
confocaloid
Posts: 3058
Joined: February 8th, 2022, 3:15 pm

Re: safeopenclip.lua usability issues

Post by confocaloid » March 25th, 2024, 7:47 am

Andrew wrote:
March 25th, 2024, 1:48 am
[...]
You could also use Golly's "get:url" feature to download a .rule file and switch to that rule. This requires the url to end in ".rule" so it might be necessary to ask Nathaniel to write a little script to periodically store all the current rule info in .rule files somewhere on conwaylife.com. Hopefully a simple modification of his script that builds all the .rle files for the LifeWiki Pattern Archive used by Golly. (As an aside, it would then be trivial to create a LifeWiki Rule Archive so Golly users could download and install any of those .rule files.)
Unless I'm missing something, that would imply restrictions on rule filenames that are analogous to existing restrictions on LifeWiki pnames. In particular, "+" and "^" would have to be rejected. Allowed rule filenames would be those allowed by existing conventions in "Help->File Formats->@RULE" (alphanumeric, hyphens, underscores).
dvgrn wrote:
February 23rd, 2019, 10:45 am
77topaz wrote:I think "long^3 boat" would be the best naming scheme/format for these pages. What do others think?
Fine by me. Along with this, the LifeWiki needs standard pnames -- lowercase alphanumeric-only names for the RLE and plaintext pattern files. The one good thing about the Arbitrary Adjective naming system was that it avoided the whole '"long<sup>10</sup> boat" / "Long%5E10_boat" mess and produced decent-looking pnames.
[...]
dvgrn wrote:
November 25th, 2023, 6:30 pm
[...]
As long as Unicode doesn't find its way into LifeWiki pnames -- and I don't see why it should -- this seems like a very workable change.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.

User avatar
rowett
Moderator
Posts: 3823
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: safeopenclip.lua usability issues

Post by rowett » March 25th, 2024, 7:48 am

dvgrn wrote:
March 25th, 2024, 7:44 am
rowett wrote:
March 25th, 2024, 7:01 am
This is deliberate. If there is an error in the bounded grid definition and it's carried across to the safe rule then the pattern still won't open.
What do you think of the two-stage approach? Try opening the safe rule with the bounded-grid suffix, and then if that doesn't work, try the safe rule with no suffix?
I was just testing the same idea... great minds 8)

User avatar
dvgrn
Moderator
Posts: 10693
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: safeopenclip.lua usability issues

Post by dvgrn » March 25th, 2024, 9:18 am

confocaloid wrote:
March 25th, 2024, 7:47 am
Unless I'm missing something, that would imply restrictions on rule filenames that are analogous to existing restrictions on LifeWiki pnames. In particular, "+" and "^" would have to be rejected. Allowed rule filenames would be those allowed by existing conventions in "Help->File Formats->@RULE" (alphanumeric, hyphens, underscores).
There's some code in the latest version of safeopenclip.lua that makes rule names with "+" and "^" URL-safe:

Code: Select all

            -- make the allowable characters URL-safe
            ruleurlsafe = rulenobounds:gsub("%+","%%%%2B"):gsub("%^","%%%%5E")
            ruleadvice = supportadvice1..rulelink:gsub("{RULENAME}",ruleurlsafe)..supportadvice2
When the Lua script builds a "get:url" link, it should be able to create a similar URL-safe address to use for rules containing "+" or "^", if we decide to support those characters in rule names.

I ran into quite a lot of "+" and "++" rule names in my informal survey, so it would definitely be nice to be able to support "+" -- and officially include that as an allowable character -- if that doesn't turn out to be too difficult. Basically, either supporting "+" or not supporting it will cause (different) difficulties.

Conversely, there was only one use of "^", so maybe it's not too late to negotiate a renaming of that one "ExtendedLife^2" rule -- maybe it could just be ExtendedLife_2.

As a side note on the analogy with pnames: we ended up officially allowing periods (".", not the oscillator concept...) as the "exception that proves the rule" for lowercase-alphanumeric-only pnames. Without some kind of separator, chunks of numeric text were getting stuck together in really confusing ways.

It certainly seems possible that Nathaniel might be okay with setting up a rule repository with an automatic nightly refresh, somwhere like https://conwaylife.com/rules/*.rule. I can ask.

EDIT: renamed "ExtendedLife^2" to "ExtendedLife-2", with permission from the rule's originator. Changed pattern rule headers and attached patterns accordingly.

User avatar
Nathaniel
Site Admin
Posts: 862
Joined: December 10th, 2008, 3:48 pm
Location: New Brunswick, Canada
Contact:

Re: safeopenclip.lua usability issues

Post by Nathaniel » March 25th, 2024, 9:32 am

Andrew wrote:
March 25th, 2024, 1:48 am
You could also use Golly's "get:url" feature to download a .rule file and switch to that rule. This requires the url to end in ".rule" so it might be necessary to ask Nathaniel to write a little script to periodically store all the current rule info in .rule files somewhere on conwaylife.com. Hopefully a simple modification of his script that builds all the .rle files for the LifeWiki Pattern Archive used by Golly. (As an aside, it would then be trivial to create a LifeWiki Rule Archive so Golly users could download and install any of those .rule files.)
Just to make sure that I understand the request properly: if I set URL redirects on the server so that, for example, https://conwaylife.com/rules/DoubleB3S23.rule displayed the exact same content as https://conwaylife.com/w/index.php?titl ... action=raw would that work? This wouldn't even require any scripting on my end -- I could set up a URL redirect rule to make this happen.

User avatar
confocaloid
Posts: 3058
Joined: February 8th, 2022, 3:15 pm

Re: safeopenclip.lua usability issues

Post by confocaloid » March 25th, 2024, 10:18 am

dvgrn wrote:
March 25th, 2024, 9:18 am
Conversely, there was only one use of "^", so maybe it's not too late to negotiate a renaming of that one "ExtendedLife^2" rule -- maybe it could just be ExtendedLife_2.
Seems to be a good idea to rename that rule (ask the author for a different name?) and avoid the caret in future rule filenames. Presence of the caret affects forum-searchability, so I don't know whether there are "non-meta" uses other than the two occurrences in viewtopic.php?f=11&t=597&start=125#p53586
Edit: good news is that I did not find other non-meta uses in the 173 matches with this forum search. Bad news is that I did not find those two uses by that search, either.

Post Reply