You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a few custom VAST attributes such as vaParent, vaPrerequisites, vaCategories etc. at all different types: methods, classes and packages. When these attributes are read in other Smalltalk dialects, they are ignored, and when written back to disk they are lost. Therefore, when you import back in VAST, you lost them.
One possible way to deal with this is to have all our custom metadata stored in separate files/directories so that other Smalltalks would just ignore it but we don't loose it. Could be:
All our metadata in another file but rather than .st a .vast or vst where the file is together with the original. For example, TFDevice.class.st and TFDevice.class.vast.
We could still use .st (or .vast or vst) but store these files in a separate directory of the root. Just like in .project we specify the source we could have another attribute that specifies the VAST metadata directory. Could be something like /vast.
I think Rowan does this as well so that all his metadata is not lost between Pharo and GemStone
The text was updated successfully, but these errors were encountered:
We have a few custom VAST attributes such as
vaParent
,vaPrerequisites
,vaCategories
etc. at all different types: methods, classes and packages. When these attributes are read in other Smalltalk dialects, they are ignored, and when written back to disk they are lost. Therefore, when you import back in VAST, you lost them.One possible way to deal with this is to have all our custom metadata stored in separate files/directories so that other Smalltalks would just ignore it but we don't loose it. Could be:
All our metadata in another file but rather than
.st
a.vast
orvst
where the file is together with the original. For example,TFDevice.class.st
andTFDevice.class.vast
.We could still use
.st
(or.vast
orvst
) but store these files in a separate directory of the root. Just like in.project
we specify thesource
we could have another attribute that specifies the VAST metadata directory. Could be something like/vast
.I think Rowan does this as well so that all his metadata is not lost between Pharo and GemStone
The text was updated successfully, but these errors were encountered: