Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20
  1. #11
    Join Date
    Mar 2016
    Posts
    12

    Thumbs down

    Quote Originally Posted by Aaron View Post
    To reiterate: we know why it is crashing, but the fix is not quickly deployable to keep up with the shifts present in the MacOS beta release. We're tracking it, anticipate it will resolve itself, while also having a patch ready for the Release Candidate once that is made available. If you need to use BC4 during this time period, please use the most recent release of MacOS instead of the beta.
    You act like it's a choice. Do you know who makes up your user base? I don't, but my semi-educated guess is that it includes a lot of software developers. Who need to update their products for Mojave. And therefore have to run the beta. And on that machine, they need their tools. Including BC.

    The whole thread shows a lack of understanding of several things that ought to be clear to any developer.

    First, what an OS beta is for, and who the predominant users of that beta are. The primary reason is for the OS vendor to find and fix bugs, but the secondary reason is for the vendor's developers to find and fix bugs in their programs prior to the OS' release. And the secondary reason supports the primary reason; the more developers hitting on the beta, the more things they'll exercise and find bugs for that can be (hopefully) fixed, (hopefully) prior to GM. That means every developer has to be running the beta, or they're not doing their job.

    Those software developers (which should include you) are fixing problems before the final OS release. I'm not running the Mojave beta, but I've already had several of the programs I use updated to fix problems with the beta. Those developers are doing what they're supposed to be doing — running the beta and fixing problems in their programs. Might they have to fix more at final release? Absolutely. But their (other developer) users have to be able to use their programs in the meantime.

    Second, it shows a lack of understanding of both BC as a product and its users. BC isn't a game, where it doesn't matter whether it works before the final release. It is a tool, one used extensively by developers. You're acting like it's the former, when it's clearly the latter.

    Ultimately, the attitude expressed here, i.e. the lack of interest in helping your users, is disturbing.

  2. #12
    Join Date
    Jun 2018
    Posts
    3

    Default

    Quote Originally Posted by macandrice View Post
    You act like it's a choice. Do you know who makes up your user base? I don't, but my semi-educated guess is that it includes a lot of software developers. Who need to update their products for Mojave. And therefore have to run the beta. And on that machine, they need their tools. Including BC.

    The whole thread shows a lack of understanding of several things that ought to be clear to any developer.

    First, what an OS beta is for, and who the predominant users of that beta are. The primary reason is for the OS vendor to find and fix bugs, but the secondary reason is for the vendor's developers to find and fix bugs in their programs prior to the OS' release. And the secondary reason supports the primary reason; the more developers hitting on the beta, the more things they'll exercise and find bugs for that can be (hopefully) fixed, (hopefully) prior to GM. That means every developer has to be running the beta, or they're not doing their job.

    Those software developers (which should include you) are fixing problems before the final OS release. I'm not running the Mojave beta, but I've already had several of the programs I use updated to fix problems with the beta. Those developers are doing what they're supposed to be doing ó running the beta and fixing problems in their programs. Might they have to fix more at final release? Absolutely. But their (other developer) users have to be able to use their programs in the meantime.

    Second, it shows a lack of understanding of both BC as a product and its users. BC isn't a game, where it doesn't matter whether it works before the final release. It is a tool, one used extensively by developers. You're acting like it's the former, when it's clearly the latter.

    Ultimately, the attitude expressed here, i.e. the lack of interest in helping your users, is disturbing.
    They're hopeless. I'm going to switch to other product, money wasted.

  3. #13
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    2,516

    Default

    To everyone frustrated by our response to this issue:

    You're right. We screwed up. We're working on a 4.2.6 release that will have the crash fixed and are planning on getting it out as soon as possible.

    This is ultimately a failure on my part, and it doesn't represent our official policy, now or going forward. It does, unfortunately, highlight an uncomfortable position that we're currently in. To put it bluntly, yes, we're doing something that we aren't supposed to. We did it the way we did because of architecture decisions made well before we started the macOS port, and at the time we released v4, it looked like the solution we used was officially supported. The approach we took has been slowly breaking. We've worked around the breaks so far, but a proper fix requires a major overhaul of our codebase. That overhaul is in progress and we're working it as fast as possible, but it's not usable yet, even as a beta.

    The workaround requires significant effort to redo if/when it breaks, and any time we spend on that is time we aren't spending on a proper fix. During the High Sierra beta we fixed the workaround for each release, but the rate of releases meant many customers weren't able to use the fix, and in the end the stable release reverted the changes that broke BC, rendering the effort wasted. We incorrectly thought that that's what was happening again, and Aaron and Chris's responses were based on that. Right now we're also working on updating BC to Cocoa and 64-bit, and we don't know when Apple will kill 32-bit support entirely. We just don't have the resources to chase transient fixes that might break a release later and definitely won't be used long term.

    Fortunately, in this case, further research showed that the crash was caused by something else and we can fix it quickly.

    We know and respect that you need Beyond Compare on whatever OS you're using. We try to fix crashes quickly, even if they're introduced in a beta. This is an unusual crunch for us to be in, made worse by some unexpected personnel issues that have slipped the schedule. BC is a tool you rely on, and we don't take that responsibility lightly.
    Last edited by ZoŽ; 05-Jul-2018 at 11:17 AM.
    ZoŽ P Scooter Software

  4. #14
    Join Date
    Apr 2008
    Posts
    27

    Default

    Quote Originally Posted by ZoŽ View Post
    Right now we're also working on updating BC to Cocoa and 64-bit, and we don't know when Apple will kill 32-bit support entirely.
    At the 2018 developer conference, Apple clearly stated that next year's new version (probably macOS 10.15 in late 2019) will not run 32-bit code at all. They also gave two years warning at the 2017 developer conference, so the timeline has not changed. Both announcements were in the Platforms State of the Union presentation. For the most recent statement, jump to just after 0:19:40 in the 2018 presentation.

    macOS 10.14 will run 32-bit code "with compromises". The compromises have not been explained in public documentation, and details may change during the beta anyway.

    Thanks for the explanation of the issues, and the update coming soon.

  5. #15
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    2,516

    Default

    Quote Originally Posted by dempson View Post
    For the most recent statement, jump to just after 0:19:40 in the 2018 presentation.
    Thanks for the info. We were aware of the "with compromises" bit, and have been assuming 10.15 was going to be the hard cutoff, but it's good to have concrete facts. We have been working on the Cocoa 64-bit build since 2016, and I've been trying to get rid of the thing we're doing wrong for even longer, but it's taking a lot more time and effort than we'd like. BC is a relatively large codebase, with a lot of low level code to do things our development environment wasn't designed for, so it doesn't change directions quite as easily anymore.
    ZoŽ P Scooter Software

  6. #16
    Join Date
    Jul 2018
    Posts
    1

    Default

    Quote Originally Posted by ZoŽ View Post
    Fortunately, in this case, further research showed that the crash was caused by something else and we can fix it quickly.
    Glad to see this... How quick is "quickly"? Any way we can help test 4.2.6?

  7. #17
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,742

    Default

    We've got a build in QA now, that we're running through our checks/tests for stability, and we'll try to roll it out soon.
    Aaron P Scooter Software

  8. #18
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    4,656

    Default

    Beyond Compare 4.2.6 is now available on the download page. It should fix the macOS 10.14 Mojave beta crashes.
    Chris K Scooter Software

  9. #19
    Join Date
    Jul 2018
    Posts
    1

    Default Beyond Compare 4.2.6 crash on Mojave 10.14 Beta (18A336e)

    Process: BCompare [19296]
    Path: /private/var/folders/*/Beyond Compare.app/Contents/MacOS/BCompare
    Identifier: com.ScooterSoftware.BeyondCompare
    Version: 4.2.6.23150 (4020.63.15)
    Code Type: X86 (Native)
    Parent Process: ??? [1]
    Responsible: BCompare [19296]
    User ID: 501

    Date/Time: 2018-07-18 21:22:41.624 -0700
    OS Version: Mac OS X 10.14 (18A336e)
    Report Version: 12
    Anonymous UUID: 7B2BC2E9-216E-8698-99A6-0C9781E5B7A8


    Time Awake Since Boot: 13000 seconds

    System Integrity Protection: enabled

    Notes: Translocated Process

    Crashed Thread: 0 Dispatch queue: com.apple.main-thread

    Exception Type: EXC_BAD_ACCESS (SIGSEGV)
    Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000bf7fffb8
    Exception Note: EXC_CORPSE_NOTIFY

    Termination Signal: Segmentation fault: 11
    Termination Reason: Namespace SIGNAL, Code 0xb
    Terminating Process: exc handler [19296]

  10. #20
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    4,656

    Default

    rlfl7086,

    Thank you for sharing the crash.

    Did Beyond Compare crash on startup, or during a specific action in the software?

    Does the crash happen every time, or only some of the time?
    Chris K Scooter Software

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •