Andy,
For some reason, I suddenly found my self unable to deploy anything. The problem seemed to always strike in #stripDevelopmentResourcesNotifying:, failing due to ResourceListPresenter does not understand #onResourceRemoved: which (according to the stripping log) had been trapped many times before the offending line. The modified method below _appears_ to result in a stable executable. What do you think? Beyond this, I get into trouble trying to remove the class builder; the walkback there points to #onClassRemoved: - is this perhaps more of the same? Have a good one, Bill !ImageStripper methodsFor! stripDevelopmentResourcesNotifying: notifier "Private - Remove development classes resources. We can't actually remove the classes themselves yet since some are required by the remainder of the stripping process. By removing the resources we give the class/method strip that follows the best chance of isolating redundant items." | resman | resman := SessionManager current resourceManager. #wksDangerous. "This kept blowing up when the same thing appears to be safely ignored earlier???? developmentClasses do: [:each | resman onClassRemoved: each]." [ developmentClasses do: [:each | resman onClassRemoved: each]. ] on:Error do:[ :e | ]. self developmentResources do: [:ri | resman remove: ri]. self finishedWith: #developmentResources ! ! !ImageStripper categoriesFor: #stripDevelopmentResourcesNotifying:!operations!private! ! -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Bill
You wrote in message news:9143qe$2sjhb$[hidden email]... > > For some reason, I suddenly found my self unable to deploy anything. The > problem seemed to always strike in #stripDevelopmentResourcesNotifying:, > failing due to > ResourceListPresenter does not understand #onResourceRemoved: > > which (according to the stripping log) had been trapped many times before > the offending line. The modified method below _appears_ to result in a > stable executable. What do you think? The error is indicating that an instance of RLP still exists in your image, perhaps a zombie. The stripper takes care to close all development views and relies on them being GC'd. If they are not, then you may experience such errors, although I have never seen this particular problem. I don't think it would be a good idea to suppress such errors, as then you'll loose important evidence as to the source of unexpected content in the resulting executable. If anything can be done here to make this more robust, it is probably to have RLP trap onViewClosed and remove the events it has registered against the resource manager, but although that might remove the DNUs, you may still end up with RLP in the deployed executable or other associated problems. > > Beyond this, I get into trouble trying to remove the class builder; the > walkback there points to #onClassRemoved: - is this perhaps more of the > same? Perhaps. I would suggest investigating to see if you have development views hanging around in the image for some reason. There may be further information in the stripping log, perhaps error reports about failure to remove classes in the development packages. Regards Blair |
Blair,
> The error is indicating that an instance of RLP still exists in your image, > perhaps a zombie. The stripper takes care to close all development views and > relies on them being GC'd. If they are not, then you may experience such > errors, although I have never seen this particular problem. Sounds like a panic is in my near future. I was wondering how it was that deployments worked just an hour or so before the meltdown - thanks fior you've explaining it. I _thought_ that I exited w/o saving the image after encountering some problems with older image strippers (STB conversion problems during Lagoon startup), but, perhaps I created and saved some zombies. > I don't think it > would be a good idea to suppress such errors, as then you'll loose important > evidence as to the source of unexpected content in the resulting executable. If possible, I'd prefer to see something more along the lines of how Lagoon reports other references to the development system: the app deploys but with a warning that there's more to do. Perhaps the log could have a notice at the bottom indicating whether or not Lagoon is happy, or the warning message box could move to the end of the strip? Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
In reply to this post by Blair McGlashan
Blair McGlashan <[hidden email]> wrote in message
news:914spk$2t47i$[hidden email]... > The error is indicating that an instance of RLP still exists in your image, > perhaps a zombie. The stripper takes care to close all development views and ... I have had trouble with zombie views in deployed applications. Not the kind of trouble Bill had, but rather simply seeing the size of my deployed applications increase in strange ways. I now habbitually do a panic before I deploy. However that can be a little inconvienient since I loose all my browsers and workspaces. Would it make sense to do an "inteligent" panic after the pre-strip image save that could check to see if there was really a window open or not? That way it could kill zombies while leaving any real windows open. Maybe I am over looking something, but it might be a handy feature. My experiance is in D3, but I assume it applies to D4 as well unless there is already a pre-deployment zombie killer. Chris |
Christopher
You wrote in message news:916fqa$2to9p$[hidden email]... >... > I have had trouble with zombie views in deployed applications. Not the kind > of trouble Bill had, but rather simply seeing the size of my deployed > applications increase in strange ways. I now habbitually do a panic before > I deploy. However that can be a little inconvienient since I loose all my > browsers and workspaces. Would it make sense to do an "inteligent" panic > after the pre-strip image save that could check to see if there was really a > window open or not? That way it could kill zombies while leaving any real > windows open. Maybe I am over looking something, but it might be a handy > feature. My experiance is in D3, but I assume it applies to D4 as well > unless there is already a pre-deployment zombie killer. There is - D4's ImageStripper is significantly more robust in this respect. I'd be surprised if doing a "panic" made any significant difference, since more similar actions are already taken by the D4 stripper. When zombies cause D4 deployment problems it is likely to be because of other sources of references than invisible views that are still registered in the handle table (which is really the only type killed off by a "panic"). Those references will have to be tracked down - dead processes that are hanging around for some reason are one possible cause, and these can be located using the ProcessMonitor. Regards Blair |
By the way, why is the image saved before deploying? I never save the image
and instead I keep all my work in packages that I install whenever I start Dolphin. Therefore, it is slightly inconvenient that the image is saved automatically. Not that it matters a lot, but if it is only a feature and not an essential part of the deployment process, perhaps it could become an option in some future version of Dolphin? Thanks a lot for 4.0 which is a great product! Mikael [hidden email] |
In reply to this post by Blair McGlashan
Blair,
> The error is indicating that an instance of RLP still exists in your image, > perhaps a zombie. The stripper takes care to close all development views and > relies on them being GC'd. If they are not, then you may experience such > errors, although I have never seen this particular problem. I don't think it > would be a good idea to suppress such errors, as then you'll loose important > evidence as to the source of unexpected content in the resulting executable. > > If anything can be done here to make this more robust, it is probably to > have RLP trap onViewClosed and remove the events it has registered against > the resource manager, but although that might remove the DNUs, you may still > end up with RLP in the deployed executable or other associated problems. Your focus on the RLP was the key. The problem turned out to be caused by a (now obsolete) feature of SuiteBuilder. I added a make shift redundant package stripping system and closed development views prior to invoking it. For 4.0, I removed the package stripping because Lagoon does a (much) nicer job of it, but, didn't think to remove the view closing. The result was that the views were closed, but, not completely excised using Lagoon's more complete approach to that problem. With the view closing left to Lagoon, all appears to be well so far - thanks! Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
In reply to this post by Blair McGlashan
Blair McGlashan <[hidden email]> wrote in message
news:917mn0$39fm8$[hidden email]... > There is - D4's ImageStripper is significantly more robust in this respect. > I'd be surprised if doing a "panic" made any significant difference, since ... Excellent! I look forward to using the new lagoon deployment system. I just got Dolphin 4 installed in the office. I also think the pre-strip scripts in D4 will be very usefull as well. Chris |
In reply to this post by Mikael Svane
Mikael Svane wrote:
> By the way, why is the image saved before deploying? I never save the image > and instead I keep all my work in packages that I install whenever I start > Dolphin. Therefore, it is slightly inconvenient that the image is saved > automatically. Not that it matters a lot, but if it is only a feature and > not an essential part of the deployment process, perhaps it could become an > option in some future version of Dolphin? I'd like to see something like this too. I use a dedicated, minimal and clean, image for deployment -- I just load the packages I want into it and deploy. It's not a big deal (as Mikael says) but it'd be nice if I didn't have to restore it from backup after every deployment. -- chris |
Free forum by Nabble | Edit this page |