Hi, Milan,

This kind of issue sometimes comes up, unfortunately, when one tries 
to author and publish a project using one version of Squeak and then 
load that project into a different version of Squeak.

The best chance to avoid such problems is to author the project using 
the same version of Squeak which you expect your target audience to 
use.  In the case you describe, that would imply using Squeakland 
image.  Note that there is a "development version" of the Squeakland 
image, complete with .changes file, available.  This is a full 
Squeak, *very* similar to Squeak 3.8g, and it also includes the full 
and latest Connectors corpus.  So this is a great image to use to 
develop content intended for Squeakland users.

Or, if you are really intent on using a Squeak.org image, you'll do 
best to use a lean Squeak 3.8g image, one that doesn't have VMMaker 
or other non-Squeakland packages loaded into it.

Theoretically there should be no problem exchanging projects between 
Squeakland 3.8 and Squeak 3.8 images, or among multiple Squeak 3.8 
images that have different sets of packages loaded, but for this to 
work easily you need to be sure there are no objects referenced by 
anything in the project that will be unknown to another image.

In your "Game" project, evidently, there are, somehow, references to 
some of the classes you mention, such as "VMMakerTool".   It's 
possible, but strenuous, to track down and eliminate such references. 
Perhaps they're lurking in properties belonging to the PasteUpMorph 
that serves as the project's world, or perhaps in its corresponding 
WorldState.  Or perhaps in the trashcan.

Perhaps someone who is an expert in the internals of the 
ReferenceStream mechanism used for project export -- I am not -- can 
comment further on the issues involve here.

In any case, such problems are tedious to deal with, and so, once 
again, I advise you to develop projects using an image as much like 
the one you want your target users to be using as possible.  For 
Squeakland users, publish from a Squeakland image.

Cheers,

  -- Scott


At 8:08 AM -0500 12/22/04, Milan Zimmermann wrote:
>Hi Scott,
>
>Thanks for your explanation. I opened the changes-set that has the name of my
>project, selected "make changes go to me" and imported the "other" change-set
>i think the game is using, and I see how classes from there are added to the
>changeset (and I assume eventually to my "Game.pr" after "export").
>
>However, I have a problem of not understanding something deeper. I tried to
>"save on file"(export) my "Game.pr" project several times, copy it to my web
>site, and try to load from a Web Browser (http...). For every "save on file"
>I get a different error when loading the project from the Web Browser. So far
>I saw these:
>
>         Error: VMMakerTool is missing
>         Error: BalloonHelp is missing
>         Error: LanguageEditor is missing
>         Error: Wonderland is missing
>
>I have no idea why, apart from thinking the exported project somehow maintains
>pointers to classes in the image (v. 3.7) from which I export. I never
>developed in Smalltalk so this is a mysterious area to me. I would like to
>have some way , when still in the original image, to look at where the
>classes referenced in the errors are pointed to in my Game, or perhaps
>ability to examine the exported "Game.pr".
>
>There is one thing I have to mention. During "save on file" I get this error:
>
>'Some block(s) which reference instance variables
>are included in this segment. These may fail when
>the segment is loaded if the class has been reshaped.
>What would you like to do?'
>                                 trueChoice: 'keep going'
>                                 falseChoice: 'stop and take a look'.
>
>Is there perhaps anything I can do if I stop (this just takes me to the
>debugger, but I am not clear what I could do to remove those "referenced
>instance variables".
>
>Sorry this is long, I am just trying to summarize, in case someone had a
>similar problem and can give me some help for the next step,
>
>Thanks Milan
>
>PS: Scott sorry I originally sent  to you not the list
>On December 21, 2004 11:21 pm, Scott Wallace wrote:
>>  Hi, Milan,
>>
>>  Yes, this is easy to do.  Just have make certain that the change-set
>>  that is "current" in the project bears the code changes that you want
>>  to have "travel" with the project.  Use a change-sorter for this, if
>>  necessary, to copy the additional changes you want into the Demo
>>  project's change-set before publishing it.
>>
>>  If, upon publishing, a project's change-set is found to be non-empty,
>>  you are presented with a prompt asking whether you want those changes
>>  included in the .pr file; simply answer yes.
>>
>>  Each time a user opens a project using the browser plugin, it
>>  involves a fresh launch of the squeak VM, retrieving a fresh, clean
>>  copy of the plug-in image from disk, so you don't need to worry about
>>  a project's errant code changes corrupting anything other than the
>>  project itself.
>>
>>  Cheers,
>>
>>     -- Scott
>>
>>  At 8:16 PM -0500 12/21/04, Milan Zimmermann wrote:
>>  >As a follow-up, I'd like to ask how to do following: Let's say I have a
>>  >project Demo.pr that I want to publish on the web, but I know it uses a
>>  >changeset that I imported to an image from which Demo.pr was exported
>>  > ("Saved on File").
>>  >
>>  >Is there a way, during Project->Save On File, to ensure that changeset
>>  > will be exported along with Demo.pr? (I assume that inside the browser
>>  > plugin this would be implemented by copying the image as to not allow
>>  > ill-constructed projects to damage the "Browser Plugin image")