Re: possible supercrash?

From: Chuck Hill (chil..lobal-village.net)
Date: Mon Jun 16 2008 - 12:18:37 EDT

  • Next message: JIRA: "[OS-JIRA] Created: (WOL-831) Veogen: Unexpected behaviour of ${attribute.uppercaseUnderscoreName}"

    Very cool!

    On Jun 15, 2008, at 10:23 PM, Mike Schrag wrote:

    > If you install a nightly after .... well ... this instant ... there
    > is a new feature (that hopefully will move into Eclipse core). If
    > you run OS X Leopard, the implementation of the workspace refresh
    > provider has switched from the default polling to one based on the
    > Leopard File System Events API (this is basically the same API that
    > lets Finder refresh immediately when you make a change to your
    > files). This should result in vastly better performance (no more
    > polling = less laptop fan :) ) and refreshing should be very fast.
    > The implementation currently has a 1 second max delay (to allow for
    > coalescing), though I might drop this lower after some testing.
    > This means that after touching the filesystem, it will be at most 1
    > second before the change appears (and possibly nearly immediate).
    > There is a little more work to do, however, because the default
    > eclipse implementation of responding to a refresh command is to do a
    > subtree scan, whereas with FSEvents we actually know whether or not
    > we have to do that (at best, and usually the case, we only need to
    > do a single container scan). This is going to take some API changes
    > in Eclipse to support this change, though. Even without that, it's
    > still pretty good, though, as most of your time is spent changing
    > files in packages and components (which tend to not be deep trees).
    > The worst case of this is if you change a file in the project root,
    > which will essentially be no worse than the previous implementation
    > (well, better because it doesn't CONSTANTLY do it).
    >
    > So the downside of this is that there's a new hunk of JNI code in
    > there, written by a mostly-Java-guy, so there's potential for a
    > series of explosions. I've been using it for a little while now
    > without any problems, and the high-risk points are usually startup
    > and shutdown, so you'll probably know pretty fast if it breaks. So
    > if you install the new build and your Eclipse dies on you .... I
    > might be partially responsible. Let me know.
    >
    > Next up is to start looking at the build process ... On systems that
    > support symbolic links, I believe it will substantially increase the
    > build speed to change the build process to use symlinks instead of
    > copies. In fact, if you use fluffy bunny, WebServerResources (as an
    > example) can be symlinked in a single step. The nice thing about
    > switching to symlinks is that it also means that files like
    > d2wmodels will be "live" so that changes will reflect immediately
    > and will also be available to the assistant for editing.
    >
    > ms
    >
    >

    -- 
    

    Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects



    This archive was generated by hypermail 2.0.0 : Mon Jun 16 2008 - 12:20:22 EDT