RunTimePackager problems
Locked
 
|
I was wondering if anybody has these issues: I am unable to run the test application in the Runtime Packager anymore.
What happens is that opening my app results in a flush of references found, many of them instanceBehavior methods in almost all classes in the system. This always results in a crashing the image on saving the final image. Does this sound familiar?
Rob Vens
|
|
|
I haven't seen anything like that, and in 7.4, if I run the test mode with SimpleWorkspace open as the startup code I don't see any problems. I'm not sure what you mean about flushing references. Flushing bindings happens quite frequently in the system, but shouldn't cause a problem, as they are lazily rebound when needed. But that wouldn't apply to instanceBehavior methods anyway, which just return an instance variable from the metaclass. And when you say "anymore", what has changed from when you were able to do it previously? Have you switched VisualWorks versions, or is this just a new version of your application?
At 04:25 AM 1/27/2006, Rob Vens wrote: >I was wondering if anybody has these issues: I am unable to run the test application in the Runtime Packager anymore. >What happens is that opening my app results in a flush of references found, many of them instanceBehavior methods in almost all classes in the system. This always results in a crashing the image on saving the final image. Does this sound familiar? > >Rob Vens -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
|
|
Alan,
thanks for responding but I think the origin of the problem lies in the parcel framework. Packaging in an image without any Store or PostgreSQL created similar problems, referencing deleted classes. I re-wrote my apps not to use parcels as their persistency mechanism, but BOSS instead, and voilá: the problem disappeared. It seems to me that parcels have dependencies all over the system on a meta-level, as such escaping the message tracing facilities of RuntimePackager. What exactly happens is not clear to me, and that is annoying (not to understand fully why), but it seems the parcel mechanism is not very useful as a persistency mechanism in an application you want to package. Back to the good old BOSS!
Any enlightening thoughts on this problem are appreciated by me.
2006/1/27, Alan Knight <[hidden email]>:
At 12:45 PM 1/27/2006, you wrote: |
Re: [Bulk] Re: RunTimePackager problems
|
|
The problem you described originally is not that the application
references deleted classes, or that things escape the message tracing
facilities. The problem is that all of the classes are kept, but messages
that are required in those classes, specifically on system startup. This
happens because your application code dynamically iterates over all
classes in the system, and if you do that during the dynamic references
test, then runtime packager will keep all classes in the system. However,
it will not have kept any messages associated with it, unless they were
also sent during the dynamic phase. So, in the example you sent, the
PostgreSQLEXDIConnection class was kept, but the #install method that
would only be sent to it at startup wasn't traced, because the only
reference to that class happened during the dynamic trace, and startup
wasn't so traced.
I don't think there is anything intrinsic to the parcel mechanism, but rather that something in the parcel code, or in your code that uses it, was causing all classes in the system to be referenced. It would probably be fairly easy to find out where. At 07:38 AM 1/31/2006, Rob Vens wrote: Alan, --
Alan Knight [|], Cincom Smalltalk Development
"The Static Typing Philosophy: Make it fast. Make it right.
Make it run." - Niall Ross
|
|
|
You are right of course, Alan, I did not mean to critisise the parcel framework, just that as I tried to use it had some drawbacks. I will look into it and maybe fixing the cause of referencing all system classes when using parcels is easy to fix. I will let you know.
I am wondering if more people use the parcel framework to store their domain objects in? Did you encounter issues when packaging?
I was trying the Omnibase dbms, but stopped when it MNU-ed encountering multicurrency signs which required Unicode support. So BOSS or parcels are my poor-man's persistency right now...
2006/1/31, Alan Knight <[hidden email]>:
The problem you described originally is not that the application references deleted classes, or that things escape the message tracing facilities. The problem is that all of the classes are kept, but messages that are required in those classes, specifically on system startup. This happens because your application code dynamically iterates over all classes in the system, and if you do that during the dynamic references test, then runtime packager will keep all classes in the system. However, it will not have kept any messages associated with it, unless they were also sent during the dynamic phase. So, in the example you sent, the PostgreSQLEXDIConnection class was kept, but the #install method that would only be sent to it at startup wasn't traced, because the only reference to that class happened during the dynamic trace, and startup wasn't so traced. |
Re: [Bulk] Re: RunTimePackager problems
|
|
Rob,
At 06:17 AM 2/1/2006, Rob Vens wrote: >I was trying the Omnibase dbms, but stopped when it MNU-ed encountering >multicurrency signs which required Unicode support. So BOSS or parcels are >my poor-man's persistency right now... OmniBase for VisualWorks currently does not support double-byte characters, but this is something we would like and have started to modify it. It's really a question of about four or five methods, and we have a start on that code. If this is something of interest to you, perhaps we could work on it together. Best, M. Roberts |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |