Announcement

Collapse
No announcement yet.

13298 Mystery mismatch

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • chrisjj
    replied
    Originally posted by Aaron
    That specific coloring is because BC3 does not color single character matches (checker-boarding). If it did match and color it, the "s\30s\Loud" would have a single black character in it
    For the record, that is exactly what I do see when BC is working better e.g. at the caret here:

    Leave a comment:


  • chrisjj
    replied
    Originally posted by Craig
    it says they're changes that "should" be considered unimportant, not "must".
    Cute.

    Originally posted by Chris
    Aha. I don't think keeping that info from users was a smart idea.
    Originally posted by Craig
    What, that we made a design decision?
    No - that BC may decide not to apply the user's Replacements.

    Leave a comment:


  • Zoë
    replied
    Originally posted by chrisjj
    Not according to the documentation, Craig.
    The documentation doesn't say one way or the other. At best, it says they're changes that "should" be considered unimportant, not "must".

    Originally posted by chrisjj
    Aha. I don't think keeping that info from users was a smart idea.
    What, that we made a design decision? We make thousands of decisions about how features should work; we aren't going to document all of the things we decided not to do.

    Originally posted by chrisjj
    That's a faithful execution of the Replacement the user asked for. That's exactly what I want as per "Replacements identify repetitive changes that should be considered unimportant."

    Craig, I cannot imagine when I would find it useful for BC to apply my replacements "optionally". Replacements are no use to me if I cannot trust BC to apply them consistently.
    As I said, we considered both approaches, and we believe that the current behavior is better in more cases. You're welcome to disagree, but you're not the only one we're designing BC for. In source code changes are frequently on a subroutine-by-subroutine basis, rather than over the entire file, so the current behavior is better since it isn't introducing differences that aren't there.

    I'm sorry the current behavior doesn't work for you, but adding the alternate approach is a fairly complex feature and I don't expect us to get to it soon. BC has find and replace support and updates the comparison as it does so, so you can do a global replacement yourself to eliminate them as differences.

    Leave a comment:


  • chrisjj
    replied
    Originally posted by Craig
    Replacements represent optional file changes.
    Not according to the documentation, Craig.

    Originally posted by Craig
    With the current behavior, you can add "apples => bananas" as a replacement and it will only affect the middle line
    Aha. I don't think keeping that info from users was a smart idea.

    Originally posted by Craig
    If, instead, we apply the replacements first, internally the files would be represented as:

    Code:
    bananas             | apples
    bananas             | bananas
    bananas             | bananas
    Which would cause problems with the first line.
    That's a faithful execution of the Replacement the user asked for. That's exactly what I want as per "Replacements identify repetitive changes that should be considered unimportant."

    Craig, I cannot imagine when I would find it useful for BC to apply my replacements "optionally". Replacements are no use to me if I cannot trust BC to apply them consistently.

    Originally posted by Aaron
    improving replacements is on our wishlist
    Thanks. Good luck.

    Leave a comment:


  • Zoë
    replied
    Originally posted by chrisjj
    Replacements represent file changes, so surely they must be applied first, if they are to work properly??
    Replacements represent optional file changes. When we were working on the feature we considered both approaches and decided on the current one.

    If you have these two files:

    Code:
    apples                 | apples
    apples                 | bananas
    bananas              | bananas
    The first and last lines should appear as exact matches.

    With the current behavior, you can add "apples => bananas" as a replacement and it will only affect the middle line.

    If, instead, we apply the replacements first, internally the files would be represented as:

    Code:
    bananas             | apples
    bananas             | bananas
    bananas             | bananas
    Which would cause problems with the first line. Doing replacements beforehand also causes problems if you have strings like:

    ababababab

    And you want to replace "aba" with "c". In that case you'll end up with something like:

    cbcbab

    The second and fourth "aba" substrings won't be replaced correctly because they've already matched a replacement. The current behavior allows the "c" replacement can occur for any of the "aba" substrings.

    We may support doing pre-replacements at some point, but the current behavior is intentional. On the other hand, the initial alignment should be improved to better group characters, and if it did you wouldn't have had any problems here.

    Leave a comment:


  • Aaron
    replied
    The alignment does occur before the replacement. Expanding and improving replacements is on our wishlist, but the replacement does not currently try to push the alignment.

    Leave a comment:


  • chrisjj
    replied
    Re http://img844.imageshack.us/img844/4...gnment0nor.png

    Aaron wrote*:
    Thanks, Chris. I added these to our test cases. In this specific
    example, the issue is that the alignment aligns the 0 in an unexpected
    location. The alignment step happens before the text replacement step,
    so by being misalighed, the text replacement does not match the text
    sections.

    Improving our intra-line alignment is on our wishlist. The only
    workaround available in this case would be to mark "\30s\Loud" as an
    unimportant grammar instead of using text replacements.
    Thanks.

    But re "The alignment step happens before the text replacement step, so by being misalighed", are you sure, Aaron? Replacements represent file changes, so surely they must be applied first, if they are to work properly??
    Last edited by chrisjj; 23-May-2011, 06:53 AM.

    Leave a comment:


  • chrisjj
    replied
    Originally posted by Aaron
    That specific coloring is because BC3 does not color single character matches (checker-boarding). If it did match and color it, the "s\30s\Loud" would have a single black character in it, which would make it harder to read.
    Whereas currently it is impossible to read as a match. Please record my request to remedy this failure to accord with documentation and common sense.

    Meanwhile, is there a workaround? I.e. a way to get BC to show all matches?

    PS It would have been useful to have received this information fifteen messages ago when I asked the question.

    Leave a comment:


  • Aaron
    replied
    Hello Chris,

    That specific coloring is because BC3 does not color single character matches (checker-boarding). If it did match and color it, the "s\30s\Loud" would have a single black character in it, which would make it harder to read. It is a design and presentation decision and intentional behavior.

    Leave a comment:


  • chrisjj
    replied
    Now, returning to my first question (i.e. regardless of the issues of a) failure of Unimportant marking and b) unexpected alignment), why does the left side shows the s as mismatched (red) as opposed to matched (black), here:



    Thanks.

    Leave a comment:


  • chrisjj
    replied
    At http://www.scootersoftware.com/vbull...40&postcount=5 Aaron wrote:

    This is the screenshot I was referring to, but now that I re-review it I see the trouble it is having:
    http://img846.imageshack.us/img846/1543/regionm.png

    The 0's alignment is probably the cause. If you send in sample files I can add them to our test cases.
    OK, I have made a stripped-down test case showing that same "0" unexpected alignment (with no Replacement):



    and emailed the BCsupport.zip and left and right files.
    Last edited by chrisjj; 20-May-2011, 11:00 AM.

    Leave a comment:


  • chrisjj
    replied
    Originally posted by Aaron
    Thanks for the easy to copy and paste text. Using the Open Clipboard to saving them to files I still see different text alignment results than your first screenshot.
    Apologies - I have confused the issue(s) by reporting a second bug in this same thread. I have rereported separately under an an accurate Subject at http://www.scootersoftware.com/vbull...9832#post29832

    Originally posted by Aaron
    ... Your initial screenshot, however, shows different alignment details where the first \ is aligned to the front. I would need the requested files in order to try and reproduce that behavior.
    OK... will do. Thanks.
    Last edited by chrisjj; 18-May-2011, 04:53 PM.

    Leave a comment:


  • Aaron
    replied
    Hello,

    Thanks for the easy to copy and paste text. Using the Open Clipboard to saving them to files I still see different text alignment results than your first screenshot. With this example, the first \ is not aligned at the front, so there is no "\" to match on. Your initial screenshot, however, shows different alignment details where the first \ is aligned to the front. I would need the requested files in order to try and reproduce that behavior.

    Leave a comment:


  • chrisjj
    replied
    I'm surprised Aaron. I get the fail with this simple test:

    1 Click Start New Session, Text Compare
    2 Enter in left \Curtain\2480002928225-1-5 and right R:\Curtain\30s\Loud\2480002928225-1-5
    3 In Session Settings, enter the Replacement right \30s\Loud\ to left \
    4 Inspect right \30s\Loud\

    Expected: Unimportant blue
    Observed: Important red - see http://img688.imageshack.us/img688/2293/regionv.png

    Leave a comment:


  • Aaron
    replied
    Hi Chrisjj,

    Thanks for the screenshot. I tried recreating your files manually by typing out that line, but I'm not seeing the same behavior (alignment details) as you are. Please email us:
    1) A pair of sample files
    2) Your current support.zip (Help menu -> Support; Export)
    3) A link back to this forum post for reference.

    Thanks.

    Leave a comment:

Working...
X
😀
🥰
🤢
😎
😡
👍
👎