Feature - Implemented Add case-sensitivity for string comparisons in ASH

By the way - I submitted it in revision 16180. I'll take responsibility for this.

I expect that there will be repercussions in various scripts, which will have to be fixed in the scripts themselves, not in KoLmafia. But, I'll leave this open in case there are additional things we need to do here...
 
Veracity said:
Well, the purpsose of the exercise was to see if there would be widespread script problems with this change.
Click to expand...

I could have been clearer. I ran my usual characters and between then Universal Recovery, WHAM, BBS, ZLIB, BCC_ASCEND and ED_ASCEND (plus some of mine) got exercised. While that is hardly comprehensive it opens up the possibility that there will not be widespread problems. I'm sure if there is some kind of importance measure that is related to number of users and frequency of use then I'm guessing that list has at least three or four of the top five in importance. Moot point since this is checked in now, but that was what I was recommending, so...
 
fronobulax said:
I had a lot of trouble with Ed_Ascend but that could have been me and not the script reacting to the patch.
Click to expand...
fronobulax said:
I could have been clearer. I ran my usual characters and between then Universal Recovery, WHAM, BBS, ZLIB, BCC_ASCEND and ED_ASCEND (plus some of mine) got exercised.
Click to expand...
OK, good. Since, near as I could tell from what you first posted, Ed_Ascend was the only script you ran, you WERE a little unclear. Ed_Ascend might very well be the only script with issues from this patch - and if so, I'm sure we'll hear about it. :)
 
Can this be changed back? Guide is thirty-eight thousand lines of code, all string heavy, and trying to fix the issues this creates is not easy. Lots of subtle, hard to detect bugs.

An example issue: The space elves quest uses the image name "spooky little girl". But, in KOLImages.ash, I defined it as "Spooky little girl". When the update hit, this meant the image lookup manager was unable to find that name - but it did use its automatic item lookup code and found a match. So, the effect was replacing the correct image with the item image - an extremely subtle bug that worked its way through several layers of code over several files, and hard to find without actively testing the content. Only reason I noticed is because someone mentioned it in chat.

A case-sensitive string comparison function could provide the same functionality without disruption.
 
Ezandora said:
But, in KOLImages.ash, I defined it as "Spooky little girl".
Click to expand...

Why? File names in URLs are case sensitive. What makes you sure that kol will never use two images that differ only in capitalization?
(or perhaps, now that I think about it, image names with capital letters at al)

ETA: wait, no. That's just your internal name, and your fault for retrieving an item with wrong key. Those should be CONSTANTs, not the same string repeated every time (possibly introducing different typos every time - constants get compile time errors when they don't match their definitions ...)!
 
Last edited:
xKiv said:
Why? File names in URLs are case sensitive. What makes you sure that kol will never use two images that differ only in capitalization?
(or perhaps, now that I think about it, image names with capital letters at al)
Click to expand...
Actually that depends on the webserver, as I discovered having been casual about it, when my web host migrated my website to a new server. I'd been told there would be no impact, but it broke lots of links!

Edit - I think it depends on the O/S, UNIX variants, including Linux, are case sensitive, Windows is not.
 
Darzil said:
Actually that depends on the webserver, as I discovered having been casual about it, when my web host migrated my website to a new server. I'd been told there would be no impact, but it broke lots of links!

Edit - I think it depends on the O/S, UNIX variants, including Linux, are case sensitive, Windows is not.
Click to expand...

Technically, it depends on filesystem setting. Even *nixen can have case-insensitive filenames, and NTFS can be set to be case-sensitive. What you wrote are the defaults (which are left unchanged virtually every time).
/pedant away!

The important bit is, kol's images are case-sensitive (according to my test on one randomly picked image just now).
 
Is this still open? I had some personal scripts that were affected by this also, and I'm just wondering whether it's possible we could get separate case-insensitive operator, maybe something like "~=". Fixing the scripts right now means hunting through them for every == comparison and manually adding .to_lower_case() where appropriate; in some scripts that could be an awful lot of places. If there was a separate operator, they could be brought back with a quick replace.
 
This has been closed for more than 2 weeks. There were, literally, no comments from the user base during the "request for feedback" period before it was submitted. There was one request after it was submitted to simply roll it back. But, other than that, there has been literally no feedback on this thread from people who might be affected - until your post, 2+ weeks after this was submitted.

I am not automatically opposed to adding a new operator. "~=" looks like the "modify and assign" operators. So:

Code: 
a += b;
is like

Code: 
a = a +b;
which might lead one to think that

Code: 
a ~= b;
would be syntactic sugar for

Code: 
a = a ~ b;
except "~" is a unary operator, so obviously not.

I can see using
Code: 
a ~= b
to mean "a is sort-of equals to b", except, the way you say you WANT to use it - simply replacing every instance of "==" with "~=" tells me that that is not, in fact, how you intend to use it. You intend to simply replace every single instance of "==" with "~=" - whether or not you really require the new semantic - out of pure laziness, rather than using the new operator exactly when you need the new semantic.

Can't say I feel motivated to spend my precious time to enable that.
 
Veracity said:
This has been closed for more than 2 weeks. There were, literally, no comments from the user base during the "request for feedback" period before it was submitted. There was one request after it was submitted to simply roll it back. But, other than that, there has been literally no feedback on this thread from people who might be affected - until your post, 2+ weeks after this was submitted.
Click to expand...

The feedback period was less than a week. I can see how some people might have missed it. There was commentary, but none of it negative. I followed along and agreed with the flow of conversation. I considered my own issues and looked over a few of my scripts to decide how hard it would be to adapt to the change. I believe that this is generally a good change for ASH and since there was no dissenting opinion I felt no need to post.


Veracity said:
I can see using
Code: 
a ~= b
to mean "a is sort-of equals to b", except, the way you say you WANT to use it - simply replacing every instance of "==" with "~=" tells me that that is not, in fact, how you intend to use it. You intend to simply replace every single instance of "==" with "~=" - whether or not you really require the new semantic - out of pure laziness, rather than using the new operator exactly when you need the new semantic.

Can't say I feel motivated to spend my precious time to enable that.
Click to expand...

Let's be fair. There's a difference between not wanting to check 7 instances of string comparison to see if to_lower_case() needs to be added or not wanting to check 177 instances. The first might just be laziness, but the second is exhausting. I don't see anything wrong with this, as long as ~= is exclusively for string comparison. Wondering what sort of "sort-of equals" would be relevant for other sorts of data types could keep me up at night and shouldn't be enabled until there is an actual use for it some day.

I'm sure that better string comparison practices will be followed in future scripts, but there's nothing wrong with offering a shortcut to allow someone to update a lot of old scripts to the new standards. He can do a search and replace for == to ~= and then change it back to == wherever there's a compiler error. It's a little bit of work, but it's a much saner amount of time to spend.
 
Last edited:
Or you could just replace " ==" with ".to_lower_case() ==" and if you wrote up all of your comparisons as lower case before, it just works. *shrugs*
 
Theraze said:
Or you could just replace " ==" with ".to_lower_case() ==" and if you wrote up all of your comparisons as lower case before, it just works. *shrugs*
Click to expand...

That doesn't work. You'd need to add the to_lower_case() function to the second part of the comparison also and that is a tougher search-replace.

Code: 
string alph = "Alphabet";

if(alph.to_lower_case() == "Alphabet")
   print("This is impossible!");
 
Bale said:
That doesn't work. You'd need to add the to_lower_case() function to the second part of the comparison also and that is a tougher search-replace.
Click to expand...

Not to mention that any comparison that wasn't a string comparison would be broken. My thought was just to have it only affect string comparisons and be equivalent to "==" for everything else. I'm not familiar with other uses for the tilde so if that's an inappropriate sign to use it really wouldn't matter to me what else it would be.

In any case, it's not a huge deal, I just thought it wouldn't hurt to ask.

Sorry that "Is this still open" was a dumb question, the green tag means it's closed doesn't it. Derp.
 
Last edited:
Is there some kind of diagnostic that could be added to mafia that would allow the change to remain but help a script writer?

I am thinking of a session long entry that might look like:

String compare "xxxx" to "XxXx" in scriptname.ash at line ZZ returns false.

I can also see a diagnostic that triggers on (a == b) and logs something when

(a == b) != (a.toLowerCase() != b.toLowerCase())

such as:

Case sensitive compare "a" == "b" in script.ash at line ZZ

That might help effected users pin down what needs to change.

There is precedent for this kind of diagnostic although I have no idea whether adding it is more or less effort than fixing scripts by blind editing.
 
Veracity said:
Code: 
a ~= b;
would be syntactic sugar for

Code: 
a = a ~ b;
except "~" is a unary operator, so obviously not.

I can see using
Code: 
a ~= b
to mean "a is sort-of equals to b"
Click to expand...

Also, on the "sort-of equals" note, perl uses =~ for regex matching (and the quoted reason is why it has to be =~ and not ~=). This could also confuse some people.


(ETA: if I was adding a ignore-case-comparison, it would be ==/i)
 
xKiv said:
(ETA: if I was adding a ignore-case-comparison, it would be ==/i)
Click to expand...
Unfortunately, I think that is ugly. ;)

How about Unicode 2248 (hex) = 8776 (hex) = HTML ≈? That is "almost equals to".

Here it is pasted in from the Character Viewer: ≈

Huh. Option-X on my keyboard: ≈

I'll code it up as a proof of concept.
 
I don't have Option-X on my PC keyboard. I suppose I can copy/paste it in from character map if I need to do so.

Smelltastic, is that satisfying?
 
Interesting. I remember when Unicode in KoL was giving us all sorts of problems and now we're using it in ash. Yeah progress!
 
You must log in or register to reply here.
Back
Top