Warning 98 load the subapplication

[Carl Gundel]

Hi,

 

I'm confused about why VA Smalltalk tells me to do this:

 

Warning: 98   Load the subapplication SubApp(3/27/2015 2:43:43 PM) into App,
 because someone has added SubApp(3/27/2015 2:43:43 PM) to App.

 

It does this when I unload SubApp from App and then try to version App.

 

It tells me to load the subapplication that I unloaded.  But I don't want to.

 

Errr.  What am I missing?

 

Thanks,

 

-Carl

[John O'Keefe]

Carl -

You need to remove SubApp from App's Config Expressions before trying to version App.

John

[Richard Sargent]

On Friday, March 27, 2015 at 12:07:13 PM UTC-7, Carl Gundel wrote:

It does this when I unload SubApp from App and then try to version App.

 

It tells me to load the subapplication that I unloaded.  But I don't want to.

It sounds like you may be using "unload" rather than SubApplication/Delete.

If you want to retain the sub-application, envy cannot version the parent unless it is loaded (or uses a configuration expression for another environment).
If you want to get rid of it, you need to do more than just unload it.

(And see John's reply)

[Carl Gundel]

Thanks Richard.

 

Seems like an arbitrary limitation that could perhaps be removed.

 

-Carl

[Richard Sargent]

On Tuesday, March 31, 2015 at 9:38:19 AM UTC-7, Carl Gundel wrote:

Thanks Richard.

 

Seems like an arbitrary limitation that could perhaps be removed.

In my opinion, that would be an error. ENVY tries to provide a safe environment so that you cannot get unloadable conditions. If you say the sub-application is part of your application, it should be loaded and ENVY should be allowed to verify that it is good. If you don't want the sub-application, delete it.

Since you think it would be desirable to version with unloaded code, perhaps you could elaborate on your use case. Tell us why you want to or need to do this. What benefit would it yield or what problem with it allow you to bypass (or whatever makes you want it added as a feature)?

 

[Carl Gundel]

Okay, here's what happened to me.

I created a subapplication.  Then some months later I rearranged the classes and put them in different subapplications.  Now I have one or more empty subapplications and want to remove them.

 

-Carl

[Richard Sargent]

Carl,

The thing to bear in mind is that ENVY is a specification-based version control system. Others are code-based (as in the code in the image is all there is).

This means that there is a specification of which edition of each method belongs in a class, which edition of each class belongs in an application or sub-application, which edition of each sub-application belongs in ... Well, I think you get the picture.

If you only "unload" an artefact, you have not adjusted the specification. If you don't want a sub-application any longer, delete it from its parent's line up. The operative word is delete, rather than unload.

[Louis LaBrunda]

Hi Carl,

You may need to "purge" it from an applications editions browser.  I'm not %100 sure so you should be careful.

Lou

[Carl Gundel]

Richard,

 

Deleting is not the same as purging then?  Unload, delete, purge.  Too many similar words.  To much ambiguity IMHO.

 

I seem to remember when I tried to do this.  I unloaded a subapplication.  Then I atttempted to version the application and it complained that I could not because the subapplication was not loaded.  When I tried to load the subapplication back in but couldn't figure out how.  Finally I had to load another edition of the application and proceed with another plan.

 

I think that calling it specification-based is an easy out.  ENVY has always been hard to use.  I think it doesn't make sense to justify the way it is designed.  At the very least the tools should be carefully reworked to make the process easier to understand.

 

Thanks,

 

-Carl

[Richard Sargent]

On Thursday, April 9, 2015 at 2:21:20 PM UTC-7, Carl Gundel wrote:

Richard,

 

Deleting is not the same as purging then?  Unload, delete, purge.  Too many similar words.  To much ambiguity IMHO.

Purging is not something one would normally do. When you see that term with respect to ENVY, start thinking of human ailments like bulimia.

I don't think those three words are similar. Unloading means to take something out of the image and that's as far as it goes. Delete means to actually delete the thing, whether you delete a class from the app or a sub-app from its parent. Purge means to eliminate any record of its existence in the repository (except it doesn't actually do that).

 

I seem to remember when I tried to do this.  I unloaded a subapplication.  Then I atttempted to version the application and it complained that I could not because the subapplication was not loaded.  When I tried to load the subapplication back in but couldn't figure out how.  Finally I had to load another edition of the application and proceed with another plan.

The error message reflects a programmer who chose to guess, based on one possible use case, rather than describe the facts.
Warning: 98   Load the subapplication SubCrap(2015-04-09 14:23:10) into Crap,
 because someone has added SubCrap(2015-04-09 14:23:10) to Crap.

He assumed that you would not unload the sub-application, so as a consequence, if there is (now) a sub-application in the application's edition specification, it "must be" because someone else added it.

Browse Editions of your application. From that browser, you can delete the sub-application. A little surprisingly, you can then version the application without reloading it. I hadn't expected that, and it certainly isn't that way in the general case. But you don't need to worry about that; it's one of the pretty advanced ENVY management techniques.

 

I think that calling it specification-based is an easy out.  ENVY has always been hard to use.  I think it doesn't make sense to justify the way it is designed.  At the very least the tools should be carefully reworked to make the process easier to understand.

I must disagree with you here. It is not "an easy out"; that is what it is.

ENVY is not the simplest possible version control, I will admit. It's far more powerful than that. I think you will find few people who agree with the remainder of your assertion. It has been a long time (20+ years!) since I read the original documentation on using ENVY. Back then, it definitely needed work. Have you read the current documentation? Some of the concepts in ENVY are sufficiently complex that re-reading the documentation after using it for a while is definitely a worthwhile exercise and highly recommended.

[Carl Gundel]

Richard, respectfully I must disagree.  ENVY violates at least a couple of important design principles such as:

 

1) Least surprise - the software should do what the user expects it will do

2) Don't make the user feel stupid

 

Having said that, I do like VA Smalltalk.  It's a great product in many ways.

 

-Carl

 

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/N-I-2zH6e1Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to va-sma...@googlegroups.com.
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.