STBViewProxy error while applying PL4 to virgin image...
Locked
STBViewProxy error while applying PL4 to virgin image...
 
|
The following Error log was generated while applying PL4 via the LiveUpdate
program to a virgin image (It had been previously updated to the other patch levels). The error seems to have occurred while it was working on PackageBrowser. It seems that a view was not fully recovered from STB. I exited the image without saving and then applied the patch again, and it worked without any errors. Has anyone else experienced anything like this? I have applied PL4 to two images at work, and one at home without errors. The complete error log can be found here http://www.mitchellscientific.com/smalltalk/temp/virgin51errors.txt . The same error seems to have happened a few times in rapid succession. An excerpt has been pasted bellow. ================================= 1:13:25 AM, Friday, March 19, 2004: Unhandled exception - a MessageNotUnderstood('STBViewProxy does not understand #height') STBViewProxy(Object)>>doesNotUnderstand: BorderLayout>>layoutContainer: ShellView(ContainerView)>>layout ShellView(View)>>validateLayout ShellView(ContainerView)>>validateLayout [] in ViewComposerArena(ContainerView)>>validateLayout OrderedCollection>>do: ViewComposerArena(ContainerView)>>validateLayout [] in ContainerView>>validateLayout OrderedCollection>>do: ContainerView>>validateLayout [] in ScrollingDecorator(ContainerView)>>validateLayout OrderedCollection>>do: ScrollingDecorator(ContainerView)>>validateLayout [] in ContainerView>>validateLayout OrderedCollection>>do: ContainerView>>validateLayout ProportionalLayout>>layoutContainer: ContainerView>>layout ContainerView(View)>>validateLayout ================================= Chris |
Re: STBViewProxy error while applying PL4 to virgin image...
|
|
Chris,
I have occaisionally seen problems like this. The two things that come to mind are deferred actions that might occaisionally happen sooner/later than "expected", and (my lead theory) sluggish finalization. In my experience, NT and up still can be starved (and no, I can't really reconcile this with the high water mark) just like 9x. The differences are that NT/2k take a _lot_ more abuse before getting into trouble, and they will usually error and recover as you saw vs. crashing as 9x would probably have done. Do you have any of the animated (menu etc.) effects enabled? I mention it because my department has them enabled some win2k machines the are configured with Deep Freeze (so there is just so much damage one can do to them) and I have seen some strange behavior on those boxes. Some generally very stable Dolphin apps have done strange things on them, and I've seen screen scarring with just Windows Explorer and friends. Putting all of that together, I am forced to wonder whether the message queue gets a little confused (or perhaps confusing?). Even if the queue order is ok, some of the delays for pass over help, etc., might be enough to take away Dolphin's time for finalization. If that is the mechanism, you might have windows opening underneath the mouse cursor, with problem happening only if the alignmnent of a view and the cursor is just right, and the system is already a little hungry for resources at the time. > 1:13:25 AM :) Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Re: STBViewProxy error while applying PL4 to virgin image...
|
|
In reply to this post by Christopher J. Demers
I see exactly the same problem, but I get the same error log installing
PL2 via liveupdate into a freshly installed image. Running on WinXP SP1. Nick Christopher J. Demers wrote: > The following Error log was generated while applying PL4 via the LiveUpdate > program to a virgin image (It had been previously updated to the other patch > levels). The error seems to have occurred while it was working on > PackageBrowser. It seems that a view was not fully recovered from STB. I > exited the image without saving and then applied the patch again, and it > worked without any errors. Has anyone else experienced anything like this? > I have applied PL4 to two images at work, and one at home without errors. > > The complete error log can be found here > http://www.mitchellscientific.com/smalltalk/temp/virgin51errors.txt . The > same error seems to have happened a few times in rapid succession. An > excerpt has been pasted bellow. > > ================================= > 1:13:25 AM, Friday, March 19, 2004: Unhandled exception - a > MessageNotUnderstood('STBViewProxy does not understand #height') > > STBViewProxy(Object)>>doesNotUnderstand: > BorderLayout>>layoutContainer: > ShellView(ContainerView)>>layout > ShellView(View)>>validateLayout > ShellView(ContainerView)>>validateLayout > [] in ViewComposerArena(ContainerView)>>validateLayout > OrderedCollection>>do: > ViewComposerArena(ContainerView)>>validateLayout > [] in ContainerView>>validateLayout > OrderedCollection>>do: > ContainerView>>validateLayout > [] in ScrollingDecorator(ContainerView)>>validateLayout > OrderedCollection>>do: > ScrollingDecorator(ContainerView)>>validateLayout > [] in ContainerView>>validateLayout > OrderedCollection>>do: > ContainerView>>validateLayout > ProportionalLayout>>layoutContainer: > ContainerView>>layout > ContainerView(View)>>validateLayout > ================================= > > Chris > > |
Re: STBViewProxy error while applying PL4 to virgin image...
|
|
The problem with STBViewProxy seems to be due to trying to install the patch
through live update. I can consistently reproduce it in a clean image by installing PL1 and then PL2 through live update. If I save PL1 and PL2 as st files and file them into the image through the file menu, then I don't get the error. Nick "Nick Payne" <[hidden email]> wrote in message news:newscache$5tmyuh$o56$[hidden email]... > I see exactly the same problem, but I get the same error log installing > PL2 via liveupdate into a freshly installed image. Running on WinXP SP1. |
Re: STBViewProxy error while applying PL4 to virgin image...
|
|
"Nick Payne" <[hidden email]> wrote in message
news:406007ab$[hidden email]... > The problem with STBViewProxy seems to be due to trying to install the patch > through live update. I can consistently reproduce it in a clean image by > installing PL1 and then PL2 through live update. If I save PL1 and PL2 as st > files and file them into the image through the file menu, then I don't get > the error. I haven't seen this issue (and no one has previously reported this for PL2 in the 5 months that it has been available so I assume there is something about your setup that makes this more likely to happen than average, perhaps you have an unusually fast :-) or slow :-( machine for example), but given what you say I would speculate that it is caused by the way LiveUpdate runs the patching under the control of a progress dialog, which means it is actually run in a background process. This means that the view composer scripting is actually running in a background process. Generally speaking it is not safe to run UI operations from a background process because there is potential for the main UI process to pick up some events and cause synchronisation issues. In this case it could be picking up a paint message and painting a partially realised window. In the case of the patches we thought we would probably "get away with it" (and testing confirmed this), but it seems we may have to reconsider this policy and ship out view patches as direct overwrites. Alternatively it may be enough to ensure that the scripted view composer is not visible when modifying the view. Thanks for your help Blair |
Re: STBViewProxy error while applying PL4 to virgin image...
|
|
Well the machine is fairly slow by present day standards. It's a notebook
with a Crusoe 733Mhz processor and 384Mb RAM. A Crusoe processor is probably the equivalent of a Pentium of around half the speed. Nick "Blair McGlashan" <[hidden email]> wrote in message news:c3p927$29e6bp$[hidden email]... > > I haven't seen this issue (and no one has previously reported this for PL2 > in the 5 months that it has been available so I assume there is something > about your setup that makes this more likely to happen than average, perhaps > you have an unusually fast :-) or slow :-( machine for example), but given > what you say I would speculate that it is caused by the way LiveUpdate runs > the patching under the control of a progress dialog, which means it is > actually run in a background process. This means that the view composer > scripting is actually running in a background process. Generally speaking it > is not safe to run UI operations from a background process because there is > potential for the main UI process to pick up some events and cause > synchronisation issues. In this case it could be picking up a paint message > and painting a partially realised window. In the case of the patches we > thought we would probably "get away with it" (and testing confirmed this), > but it seems we may have to reconsider this policy and ship out view patches > as direct overwrites. Alternatively it may be enough to ensure that the > scripted view composer is not visible when modifying the view. |
Re: STBViewProxy error while applying PL4 to virgin image...
|
|
In reply to this post by Blair McGlashan
"Blair McGlashan" <[hidden email]> wrote in message
news:c3p927$29e6bp$[hidden email]... > "Nick Payne" <[hidden email]> wrote in message > news:406007ab$[hidden email]... > > The problem with STBViewProxy seems to be due to trying to install the > patch > > through live update. I can consistently reproduce it in a clean image by > > installing PL1 and then PL2 through live update. If I save PL1 and PL2 as > st > > files and file them into the image through the file menu, then I don't get > > the error. > > I haven't seen this issue (and no one has previously reported this for PL2 > in the 5 months that it has been available so I assume there is something > about your setup that makes this more likely to happen than average, perhaps > you have an unusually fast :-) or slow :-( machine for example), but given > what you say I would speculate that it is caused by the way LiveUpdate runs > the patching under the control of a progress dialog, which means it is .... > but it seems we may have to reconsider this policy and ship out view patches > as direct overwrites. Alternatively it may be enough to ensure that the > scripted view composer is not visible when modifying the view. Thanks for the explanation. I am glad this is a specialized Live Update problem and not something more generic. I think the visual activity of the view composer during a patch probably makes some people nervous if they do not expect it. It does look a bit like the computer is going nuts. ;) Chris |
Re: STBViewProxy error while applying PL4 to virgin image...
|
|
In reply to this post by Blair McGlashan
Blair McGlashan wrote:
> In > the case of the patches we thought we would probably "get away with it" > (and testing confirmed this), but it seems we may have to reconsider this > policy and ship out view patches as direct overwrites. Alternatively it > may be enough to ensure that the scripted view composer is not visible > when modifying the view. At one time you used to "ship" patches to Views by loading/modying/saving the resource directly rather than via the VC. I always wondered why you switched to scripting the VC instead, was there some technical reason, or is it just easier to drive the VC ? -- chris |
Re: STBViewProxy error while applying PL4 to virgin image...
|
|
"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]... > Blair McGlashan wrote: > > > In > > the case of the patches we thought we would probably "get away with it" > > (and testing confirmed this), but it seems we may have to reconsider this > > policy and ship out view patches as direct overwrites. Alternatively it > > may be enough to ensure that the scripted view composer is not visible > > when modifying the view. > > At one time you used to "ship" patches to Views by loading/modying/saving the > resource directly rather than via the VC. I always wondered why you switched > to scripting the VC instead, was there some technical reason, or is it just > easier to drive the VC ? Well there are a couple of reasons. It means that the patch can be applied without overwriting other view settings. Sometimes a patch level may include a number of updates to the same view. It's nice to avoid an order dependency between these individual patches. Also any unrelated user customisation of the view will be unaffected. The other reason is that it makes it easy to see what the modification actually is. Even should the view not be stored in binary form (such as in code, or XML, or as literal arrays), it would still be difficult to see what had changed without using a difference tool. Lastly it may help to keep the size of the patch down. This is particularly the case when the change involves a small modification to a number of view resources, such as the PL4 modification to the default heights of the text presenter single line views. Regards Blair |
Re: STBViewProxy error while applying PL4 to virgin image...
|
|
Blair
> > At one time you used to "ship" patches to Views by > > loading/modying/saving the resource directly rather than via the VC. I > > always wondered why you switched to scripting the VC instead, was there > > some technical reason, or is it just easier to drive the VC ? > > Well there are a couple of reasons. [snipped] I think you were telling me why you prefer not to ship a patch to a resource as a new STB-ed object that just replaces the existing one (and the reasons seem convincing to me). But what I was asking is why you switched from a scripting the changes to the resource directly, something like: ri := ResouceIdentifier class: SomeClass name: 'Some Name'. v := ri load. v someAspect: 42. ri save: v. It's not important, though, I was just curious about whether the above approach has technical limitations that loading a view into the VC will circumvent. -- chris |
Re: STBViewProxy error while applying PL4 to virgin image...
|
|
"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]... > Blair > > > > At one time you used to "ship" patches to Views by > > > loading/modying/saving the resource directly rather than via the VC. I > > > always wondered why you switched to scripting the VC instead, was there > > > some technical reason, or is it just easier to drive the VC ? > > > > Well there are a couple of reasons. [snipped] > > I think you were telling me why you prefer not to ship a patch to a resource as > a new STB-ed object that just replaces the existing one (and the reasons seem > convincing to me). But what I was asking is why you switched from a scripting > the changes to the resource directly, something like: > > ri := ResouceIdentifier class: SomeClass name: 'Some Name'. > v := ri load. > v someAspect: 42. > ri save: v. > > It's not important, though, I was just curious about whether the above approach > has technical limitations that loading a view into the VC will circumvent. To be honest, I can't remember if we ever did it like that. I have a vague recollection that loading the resources in the "context" of the desktop (i.e. with the desktop as the parent) does cause problems, but this may just be my imagination. Regards Blair |
«
Return to Dolphin Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |