[vw78] Disappearing Store Windows
Locked
[vw78] Disappearing Store Windows
 
|
Well, we had a new surprise: If you save your image and restart it
several windows will just not reappear. It turns out that this is deliberately coded that way.... So here's a heads up: if you do mechanized builds and rely on 'Unloadable Definitions' windows to be available when you start your freshly built image ... don't, they're gone. If you are busy in the merge tool and want to save its state along with the image... don't. For those who want to hack this: see implementers of #windowEvent:from: on the store hierarchies see senders of #terminateBrowser Additionaly I note that the implementers of #terminateBrowser are buggy: they release their parts *before* closing the window which is not robust in the face of multithreading. And some senders are buggy too: they do not rendez-vous with the windowmanager processes. Cincom: please do not just close tools, that is a step backward. Instead give us the option to reconnect to the database. R - _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vw78] Disappearing Store Windows
|
|
Reinout:
> Cincom: please do not just close tools, that is a step backward. Instead > give us the option to reconnect to the database. These objects contain references to StorePackage objects. These in turn hold on to Glorp session objects. These session objects are not able to not survive across image startups, even if you reconnect. These are external resources that are not simply reify-able, thus anything that holds on to them must be shut down. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, Store Project Smalltalk Enables Success -- What Are YOU Using? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vw78] Disappearing Store Windows
|
|
Or, instead of shutting down, they could acquire a new session on returnFromSnapshot. Dave Stevenson[hidden email] From: Samuel S. Shuster <[hidden email]> To: Reinout Heeck <[hidden email]> Cc: VWNC <[hidden email]> Sent: Wed, November 9, 2011 12:19:28 PM Subject: Re: [vwnc] [vw78] Disappearing Store Windows Reinout: > Cincom: please do not just close tools, that is a step backward. Instead > give us the option to reconnect to the database. These objects contain references to StorePackage objects. These in turn hold on to Glorp session objects. These session objects are not able to not survive across image startups, even if you reconnect. These are external resources that are not simply reify-able, thus anything that holds on to them must be shut down. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, Store Project Smalltalk Enables Success -- What Are YOU Using? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vw78] Disappearing Store Windows
|
|
Dave: Or, instead of shutting down, they could acquire a new session on returnFromSnapshot. Were it so simple we would have done it. Sessions have caches that guarantee the uniqueness of objects. Toss a session, you toss the cache. Now if you go out and try to get an object that is related to another which was in the cache, it will get a new one, and they will not be identical, and indeed, you'll now have two. Additionally, sessions have references to external connection objects, which contain resources that are managed in ways not in our control... Oracle being much more nasty than PostGreSQL's streams for instance. Frankly, managing DeviceContexts in the GUI world was more coherent. And So It Goes Sames ______________________________________________________________________ Samuel S. Shuster [|] VisualWorks Engineering, Store Project Smalltalk Enables Success -- What Are YOU Using? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vw78] Disappearing Store Windows
|
|
There's more than one way to skin a cat.
I've recently worked on some UIs with domain dependencies so complex that I couldn't reach into the house of cards and replace one of the foundation pieces without breaking something, and resource constraints prevented a proper refactoring of the app. So instead I rebuild the house of cards with the new piece.
The old UI still has useful state. If you can't get the caches to sync properly in the old UI on returnFromSnapshot or reconnect, then the old UI with invalid caches can rebuild the house of cards. Let it spawn a new UI, which will build its own caches as it goes. Let the old UI drive the new UI until its state matches that of the old UI before closing the old UI. In the end the user more or less sees what he last saved.
[hidden email] From: Samuel S. Shuster <[hidden email]> To: Dave Stevenson <[hidden email]> Cc: Reinout Heeck <[hidden email]>; VWNC <[hidden email]> Sent: Wed, November 9, 2011 1:48:11 PM Subject: Re: [vwnc] [vw78] Disappearing Store Windows Dave: Or, instead of shutting down, they could acquire a new session on returnFromSnapshot. Were it so simple we would have done it.
Sessions have caches that guarantee the uniqueness of objects. Toss a session, you toss the cache. Now if you go out and try to get an object that is related to another which was in the cache, it will get a new one, and they will not be identical, and indeed, you'll now have two.
Additionally, sessions have references to external connection objects, which contain resources that are managed in ways not in our control... Oracle being much more nasty than PostGreSQL's streams for instance.
Frankly, managing DeviceContexts in the GUI world was more coherent. And So It Goes
Sames
______________________________________________________________________
Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vw78] Disappearing Store Windows
|
|
In reply to this post by Samuel S. Shuster-2
I think this is doable, at
least in some cases, and can be dealt with in the others. The closing
of the windows was just the simplest thing which consistently avoids
either erroneous data or walkbacks. To do it better it seems to me there
are 3 cases
a) When the image comes up it's connected to a different database. b) When the images comes up it's connected to the same database. c) When the image comes up it's not connected to a database at all. And within those there are two sub-cases i) The window has all the information it will need. For example, a merge tool probably has looked at everything it will need already and has it in cache. ii) The window will, or may, need more information from the database. For example, a package browser may have only read in the source for the methods that is actually has displayed so far. Something that's in case (i) is relatively easy. You could leave it open and it wouldn't attempt to access the database. The only trick is being sure that that's the case. In case (ii)(c) we could simply re-establish the connection to the database, verifying that it's the same, and the window could continue to run. In case (ii)(a) and (ii)(b) any attempt to access the database will fail. We could reasonably do something like replace the session or its internals with one that would do something useful when you attempted to access data not in the image. The easiest thing would be to defer window closing to the point where such an access was detected, and close the window then. Or put up a dialog with a cancel/close/connect to the correct database choice.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vw78] Disappearing Store Windows
|
|
On 11/10/2011 7:49 PM, Alan Knight wrote:
I think this is doable, at least in some cases, and can be dealt with in the others. The closing of the windows was just the simplest thing which consistently avoids either erroneous data or walkbacks. To do it better it seems to me there are 3 cases I am troubled by the analyses being made here, they revolve around solutions without stating the problem. They seem to be induced by a mindset of keeping the mechanical system 'happy' instead of keeping the human workflow possible. They are bottom-up instead of top-down. In the case of the 'Unloadable definitions' windows: they must survive our automated build. Closing them at image restart violates that principle (even before a human can eyeball them!). Furthermore in some cases it would be benificial to be able to load definitions after rectifying the situation but without having the original repository available. This yields roughly: The window should survive image save&restart. The window should render its information after restart (without a store connection) The window should tell which package it pertains to The window should tell why a definition failed to 'load' (not available in old & new VW versions) The window allows to 'load' individual definitions (without a store connection!) The window shows which definitions have been 'loaded' by now (not available in old & new VW versions) Looking at it this way it seems that a Store connection is not needed, any reasoning around stale caches and such looks like an implementation design error to this end user. In the case of the merge tool trying to think top-down quickly induces an important realization: store connections don't go away at image restart, instead they can go away *any* time (by way of the Internet's design). Q: what do you do when a store connection 'goes away'? A: you inform the user and give him a chance to save his work some way (by saving the image or by changing unapplied resolutions to a change set or by changing unapplied resolutions to a Refactoring or... or...). Finally I want to bring the following under your attention: our nightly build 'bot' connects to store as one specific user, when the image is started it will be reconnected as a different user. The analyses below seem to consider the single-user case only. HTH, Reinout -------
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |