[vwnc] Question about "Publish as Parcel" for VisualWorks Packages

I have seen a bug in one VisualWorks version that was based on bad sync state of parcel and package. It was possible that the package did not broadcast all changes to the related parcel. To make it more complicated: A related parcel does not necessarily exist, and when saving a package as parcel, the system creates one on the fly, if necessary. But if the parcel exists, the system uses that parcel to save. When filing out, the system never consults the parcel, so this would explain why the file-out is perfect.

I do not know whether this bug is tricking you but before diving deeper into that matter it's worth having a look and check whether the parcel has the same list as the package has. You can switch to parcel viewing mode in the Refactoring Browser with menu item "Browser> Parcel" and then look up in the list.
If you find inconsistencies, you could fix that manually by moving the missing elements into the parcel. An alternative is destroying the parcel with Parcel List menu item "Discard...". This destroys the parcel without damage to the source. The next "Publish as Parcel" should use a scratch parcel built from the package.
Hope that helps...

Holger Guhl
--
Senior Consultant * Certified Scrum Master * [hidden email]
Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20
Georg Heeg eK Dortmund
Handelsregister: Amtsgericht Dortmund  A 12812


Les Tyrrell schrieb:

Hi all,

I've come across an apparent problem when creating .pst files from a VisualWorks package that we have.  This package contains a large number of extensions to existing VisualWorks base classes.  When I "publish as parcel" this package, methods for *some* of these extended classes end up in the .pst, while others are apparently ignored.  It appears that *all* of the extension methods do end up as part of the .pcl file.

I've been looking at CodeWriter to try to figure out what is going on, but have discovered that this is not an easily understood object.  Would anyone have some idea  of where I should consider looking to find out why some methods do make it into the .pst, while others don't?  It appears to be done on a per-class basis- either all of the extended methods for a given class are written, or they are not.

Another point to consider- if I file out the package, it will properly include all of the methods.

I'm very interested in this as we have been including .pst files in our various software releases.  As part of a code review, I've been taking these .pst files and have been generating differences reports.  An earlier version of the .pst file for this package *did* include all of the extension methods- but more recent versions do not.

This would lead me to think that we must have recently changed something in a way that we now generate partial .pst files.  However, to figure out if this is the case, I've got to find the place where CodeWriter ( or its companions ) ends up not writing so many of these methods into the .pst file.

I'm using VisualWorks 7.5, the behavior is the same whether I use it in Windows or in Linux.  We are storing source in XML format.

Thanks!

- Les

------------------------------------------------------------------------

_______________________________________________
vwnc mailing list
[hidden email]
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.cs.uiuc.edu/mailman/listinfo/vwnc" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/vwnc