8 replies to this topic

[QuietOne]

I’m a new user so I may have something setup wrong but SC X consistently gripes about “misspellings” when I type ANY word combinations with forward slashes.

This occurs with word pairs such as (sans quotes) “either/or”, “and/or”, “once/twice/thrice“ or any other pair of words no matter what the words are. And this is true regardless of whether the individual words themselves are spelled correctly or not.

How do I get SC X to recognize that the word combinations are CORRECTLY spelled?? It‘s constant griping about these errors is slowing me down tremendously as I have to constantly dismiss it! This as you can imagine is very aggro!

Thanks for your attention to my plight.

[Evan Gross]

QuietOne, on 21 July 2010 - 12:30 PM, said:

I’m a new user so I may have something setup wrong but SC X consistently gripes about “misspellings” when I type ANY word combinations with forward slashes.

This occurs with word pairs such as (sans quotes) “either/or”, “and/or”, “once/twice/thrice“ or any other pair of words no matter what the words are. And this is true regardless of whether the individual words themselves are spelled correctly or not.

How do I get SC X to recognize that the word combinations are CORRECTLY spelled?? It‘s constant griping about these errors is slowing me down tremendously as I have to constantly dismiss it! This as you can imagine is very aggro!

Thanks for your attention to my plight.

We are aware of this - the best option is to deselect the preference in Spell Catcher’s Preferences, Spelling pane, Checking tab to Ignore internet addresses.

[QuietOne]

OK, I’ll do that but are you working on and/or do you have a target date for a fix anytime soon???

And -- Thanks for the reply Evan.

[Evan Gross]

QuietOne, on 21 July 2010 - 07:08 PM, said:

OK, I’ll do that but are you working on and/or do you have a target date for a fix anytime soon???

And -- Thanks for the reply Evan.

Sorry to say, nothing definite. It's actually a far more difficult problem than you might think…

[QuietOne]

Well, being a retired system programmer I’d start by testing on the absence of a beginning string of both “http://” and/or “www.”. Then parse the End of String to see if it consists of any of the defined standard country domain identifiers (.uk, .au, ....) and then domain names (.com, info, .biz, .org, ......) which further eliminates any web addresses. Admittedly this part has recently gotten a bit more complex with the addition of international alphabets to the acceptable address space but that’s just one more hurdle and can be successfully navigated with due preparation. At this point, your clients could turn web address spell checking back on.

From that point on you parse the substring as follows (keeping cognizant of @ symbols and/or embedded periods which could signify, but not definitely, an email address). There are a variety of other valid email address characters you’ll have to watch out for but just check the RFC’s for the latest updates on the standards. Meanwhile, if you parse either of these (or any of the other valid email address characters) then you have to investigate these possibilities before you go on to just plain words. Then after that ...

Parse everything from the first character up to but NOT including the first forward slash and spell check that string; then
Throw away the forward slash; then
Parse everything from the first character AFTER the slash you just 86’d until the next forward slash and/or end of string; etc. etc.

You may have to parse the strings several times like that unless you‘re tricky enough to parse them one way and then another in consecutive passes but it’d work.

I used to do that type of string parsing all day long when I was writing “C” Compilers and I did it for years. I therefore must beg to differ with you, Evan. It’s NOT that hard! Yes, it takes some work but it only takes a little time if you put your head down and get to it. So I’m sorry to have to say this but I reject your notion that “It's actually a far more difficult problem than you might think…”. I don’t agree.

Not sure what language you’re writing SC in but if it’s “C” or “C++” then a Case Statement would do nicely.

[Evan Gross]

QuietOne, on 21 July 2010 - 09:30 PM, said:

Well, being a retired system programmer I’d start by testing on the absence of a beginning string of both “http://” and/or “www.”. Then parse the End of String to see if it consists of any of the defined standard country domain identifiers (.uk, .au, ....) and then domain names (.com, info, .biz, .org, ......) which further eliminates any web addresses. Admittedly this part has recently gotten a bit more complex with the addition of international alphabets to the acceptable address space but that’s just one more hurdle and can be successfully navigated with due preparation. At this point, your clients could turn web address spell checking back on.

From that point on you parse the substring as follows (keeping cognizant of @ symbols and/or embedded periods which could signify, but not definitely, an email address). There are a variety of other valid email address characters you’ll have to watch out for but just check the RFC’s for the latest updates on the standards. Meanwhile, if you parse either of these (or any of the other valid email address characters) then you have to investigate these possibilities before you go on to just plain words. Then after that ...

Parse everything from the first character up to but NOT including the first forward slash and spell check that string; then
Throw away the forward slash; then
Parse everything from the first character AFTER the slash you just 86’d until the next forward slash and/or end of string; etc. etc.

You may have to parse the strings several times like that unless you‘re tricky enough to parse them one way and then another in consecutive passes but it’d work.

I used to do that type of string parsing all day long when I was writing “C” Compilers and I did it for years. I therefore must beg to differ with you, Evan. It’s NOT that hard! Yes, it takes some work but it only takes a little time if you put your head down and get to it. So I’m sorry to have to say this but I reject your notion that “It's actually a far more difficult problem than you might think…”. I don’t agree.

Not sure what language you’re writing SC in but if it’s “C” or “C++” then a Case Statement would do nicely.

Well, not having any idea that you were a developer, I might have overstated things.

But you have it more-or-less right. The real problem comes when trying to integrate that approach with the way that the Proximity Linguistic System (our linguistic engine) parsing subsystems work. It truly is somewhat hairy to do something like you propose with their APIs.

And yes, the current problems annoy me as much as it does you. So I certainly want to fix it, and every time I need to do a maintenance update I take another look at it. Problem is, it's just proven too risky a thing to do - risky in that it would be easy to break something. I have to re-strucuture and clean things up in a number of areas (especially check selection) to really do it right.

[QuietOne]

Evan Gross, on 21 July 2010 - 10:10 PM, said:

Well, not having any idea that you were a developer, I might have overstated things.

But you have it more-or-less right. The real problem comes when trying to integrate that approach with the way that the Proximity Linguistic System (our linguistic engine) parsing subsystems work. It truly is somewhat hairy to do something like you propose with their APIs.

And yes, the current problems annoy me as much as it does you. So I certainly want to fix it, and every time I need to do a maintenance update I take another look at it. Problem is, it's just proven too risky a thing to do - risky in that it would be easy to break something. I have to re-strucuture and clean things up in a number of areas (especially check selection) to really do it right.

Sorry Evan, didn’t mean to ambush you but when you insinuated it was “a far more difficult problem than you might think” I just couldn’t resist. Anyway, I’m not familiar with the PLS API’s (never used them myself since I was and still am an old Unix lover) God save/love the $ sign! That’s the old Unix prompt for you youngsters who never computed without a GUI. Thus I’ll have to take your word for it about that part of the problem. However, that said the problem still remains and the solution is as follows ...

WRT your current hesitation, (i.e. “Problem is, it's just proven too risky a thing to do - risky in that it would be easy to break something.”). Doesn’t matter whether you’re doing a maintenance release or a major update/rewrite. There’s ALWAYS that problem so again, your reasoning doesn’t “Pass Muster.“

So:

• If your code needs a major rewrite (as in starting over from scratch) then just get to it albeit on a separate development partition so your files don’t get intermixed with your production files;
  
• If your code simply needs a good Clorox job, well then go to a different partition (for the same reasons) but just start your overhaul instead of your scratch rewrite.

In either case, it’ll never get done unless you just get after it and do it! If you need help, then go find it but these kinds of BUGS! (and that’s what they are), need to be addressed instead of feared and perpetually put off just because they’re a daunting task and thus never getting fixed at all. NOT fixing BUGS!, especially daunting ones will lose you customers/clients and ruin the reputation of your application faster than acknowledging that it exists (as you have) but ALSO acknowledging that you are working on the fix even though it will take some time to complete.

I (along with about 10 other beta-testers around the world) just completed Beta-testing a new version of a Windows app that was in rewrite (from the ground up) for the last two years! So like I said, if it needs doing ... then get busy and get it done.

Oh, and one last pat on the back ... If “I have to re-strucuture and clean things up in a number of areas (especially check selection)“ as you’ve said it’ll take is what’s necessary “to really do it right.“ you are definitely approaching it with the right attitude! So, Thumbs up to ya and good luck!!!

[Evan Gross]

QuietOne, on 21 July 2010 - 11:52 PM, said:

Sorry Evan, didn’t mean to ambush you but when you insinuated it was “a far more difficult problem than you might think” I just couldn’t resist. Anyway, I’m not familiar with the PLS API’s (never used them myself since I was and still am an old Unix lover) God save/love the $ sign! That’s the old Unix prompt for you youngsters who never computed without a GUI.

I'm well familiar with GUI-less development and the $ prompt. That was back in my University days, though, and became (mostly) a thing of the past back in 1985 when I started developing for the Mac.

Quote

Thus I’ll have to take your word for it about that part of the problem. However, that said the problem still remains and the solution is as follows …
WRT your current hesitation, (i.e. “Problem is, it's just proven too risky a thing to do - risky in that it would be easy to break something.”). Doesn’t matter whether you’re doing a maintenance release or a major update/rewrite. There’s ALWAYS that problem so again, your reasoning doesn’t “Pass Muster.“

I'll have to disagree with you on this point, however. There's a big difference between tackling this sort of thing in a maintenance release vs. a major upgrade - at least IMO and experience. Maintenance releases are always time-critical. And (for me) are always done to fix much more serious problems than this one. This means crashing bugs, compatibility with major Mac OS X changes (64-bit on Snow Leopard for example), and regressions due to something that got broken in a previous update. Time pressure forces prioritization, and being very careful not to do anything that might introduce new regressions.

Quote

So:

• If your code needs a major rewrite (as in starting over from scratch) then just get to it albeit on a separate development partition so your files don’t get intermixed with your production files;
  
• If your code simply needs a good Clorox job, well then go to a different partition (for the same reasons) but just start your overhaul instead of your scratch rewrite.

Oh my! We don't do that sort of thing (using different partitions or the like) any more! Source control systems like Subversion make this easy. Just create a new branch, work on it and the main "trunk" at the same time. Merge changes as/when appropriate.

Quote

In either case, it’ll never get done unless you just get after it and do it! If you need help, then go find it but these kinds of BUGS! (and that’s what they are), need to be addressed instead of feared and perpetually put off just because they’re a daunting task and thus never getting fixed at all. NOT fixing BUGS!, especially daunting ones will lose you customers/clients and ruin the reputation of your application faster than acknowledging that it exists (as you have) but ALSO acknowledging that you are working on the fix even though it will take some time to complete.

I certainly don't fear solving this problem, but it needs to be done right, and there simply hasn't been an opportunity to do it for a maintenance release. But now that I am working on the next major upgrade, I have that opportunity and will be able to.

Quote

I (along with about 10 other beta-testers around the world) just completed Beta-testing a new version of a Windows app that was in rewrite (from the ground up) for the last two years! So like I said, if it needs doing ... then get busy and get it done.

Two years is a pretty luxurious amount of time! No maintenance release is allowed to take that long!

Quote

Oh, and one last pat on the back ... If “I have to re-strucuture and clean things up in a number of areas (especially check selection)“ as you’ve said it’ll take is what’s necessary “to really do it right.“ you are definitely approaching it with the right attitude! So, Thumbs up to ya and good luck!!!

[QuietOne]

Evan Gross, on 22 July 2010 - 12:39 AM, said:

I'm well familiar with GUI-less development and the $ prompt. That was back in my University days, though, and became (mostly) a thing of the past back in 1985 when I started developing for the Mac.


I'll have to disagree with you on this point, however. There's a big difference between tackling this sort of thing in a maintenance release vs. a major upgrade - at least IMO and experience. Maintenance releases are always time-critical. And (for me) are always done to fix much more serious problems than this one. This means crashing bugs, compatibility with major Mac OS X changes (64-bit on Snow Leopard for example), and regressions due to something that got broken in a previous update. Time pressure forces prioritization, and being very careful not to do anything that might introduce new regressions.


Oh my! We don't do that sort of thing (using different partitions or the like) any more! Source control systems like Subversion make this easy. Just create a new branch, work on it and the main "trunk" at the same time. Merge changes as/when appropriate.


I certainly don't fear solving this problem, but it needs to be done right, and there simply hasn't been an opportunity to do it for a maintenance release. But now that I am working on the next major upgrade, I have that opportunity and will be able to.


Two years is a pretty luxurious amount of time! No maintenance release is allowed to take that long!

True enough all. Times, my how they do/are a-changin’. And you are certainly right about maintenance releases not waiting for two years etc. But then I wasn’t the one with the checkbook. I didn’t cash a single check for all the time I put in. Remember, I’m retired. In any case, enough sparring and banter. Good luck in your major upgrade and I look forward to using the fruits of your labors. Best wishes in all you do. Cheers!