can't drag etoys project into etoys-dev image
Bryan Berry
I get the following message when I drag and drop one of the .pr files
into the etoys-dev.image 2.2
Reading an instance of RipoffPatchMorph
Which Modern class should it translate to?
options: let me type the name now
let me think about it
let me find the conversion file
I reckon that some of the code needed for this project is still in
the .image file. Is there a way that I can save all the needed classes
into a project file so I can share the project w/ people who just have
the regular etoys.image on their XO?
--
Bryan W. Berry
External Relations Manager
OLE Nepal, http://www.olenepal.org
Luke Gorrie
> I reckon that some of the code needed for this project is still in
> the .image file
Right!
> Is there a way that I can save all the needed classes
> into a project file so I can share the project w/ people who just have
> the regular etoys.image on their XO?
What I do in this case is to save out the Smalltalk code in a 'change
set' (.cs) file that can be loaded into a stock image to make it
epaati-compatible. This is done via the Monticello browser somewhere
(I can't check exact step right now due to dead MacBook).. You can
download and old-ish versionh here that may be good enough:
http://fresh.homeunix.net/~luke/misc/etoys/week1/OLE-26.st
If you drag'n'drop that into an image (and choose 'filein entire file'
when prompted) then you have the Smalltalk code as of a couple of
months ago.
It should also be possible to embed the Smalltalk code in the project
file but I've avoided that up to now for various reasons (like
potential for conflict ifeach project file contains a differnet
version of the whole Smalltalk codebase).
Any help?
surendra
>>
-Surendra
surendra
> hey guys,
>
> I get the following message when I drag and drop one of the .pr files
> into the etoys-dev.image 2.2
>
> Reading an instance of RipoffPatchMorph
> Which Modern class should it translate to?
> options: let me type the name now
> let me think about it
> let me find the conversion file
>
> I reckon that some of the code needed for this project is still in
> the .image file. Is there a way that I can save all the needed classes
> into a project file so I can share the project w/ people who just have
> the regular etoys.image on their XO?
>
>
Yes, you are right. Some of the projects like action verb needs some
additional code to be there in Image. So, to solve the problem you have
to update your image from Menticello repository. There are basically two
aspect of writing everything in a project and making it image independent
pros
It makes project easily transferable.
Cons
We have to repeat Common code for all the projects.
Personally I prefer image dependent rather than image independent if
the code is shared by many projects. However, RipoffPatchMorph class
does not seem to be added by the guys in our team.
One approach to solve the problem is placing both source code(.st) as
well as project file(.pr) in our web server so that it can be easily
downloaded and other is to update the code from Menticello repository.
Some of the project are facing the problem of dangling reference. So,
Let us know in which project you are facing this problem.
--
_____________________________________
Surendra Sedhai
Content Developer
*Open Learning Exchange*
Website: http://www.olenepal.org
Bryan Berry
control would be much easier that way. It would also be easier to share
individual activities as .xo bundles
Putting each activity in a separate bundle will make it easier for
outside developers to assist us.
Have we uploaded our e-paati bundle into OLPC's git repository yet?
Luke Gorrie
>
> I would actually prefer each etoys activity have its own image. Version
> control would be much easier that way. It would also be easier to share
> individual activities as .xo bundles
The thing about images is that they're big. To have one for each
activity is like having a separate complete copy of Squeak (20+ MB).
And it makes version control easier for some user-cases (the
activities are self-contained) but possibly harder for developers:
each activity is essentially a 'fork' of Squeak. It's a bit like
distributing programs complete with their own operating systems.
The alternative is project files. Each project file is essentially one
screen-full of objects, which is a good match for an activity. The
projects can also include other resources like sound clips, Smalltalk
code, and so on. Projects are a lot like the executable files of
applications.
So far the approach we've taken is to create a single consistent
collection of activities, without much support for distributing
activities individually. More technically:
1. We create a custom image, epaati-<date>.image, which is based on
the standard Squeak image but includes extra stuff: the latest version
of our Smalltalk codebase, common sound clips, devanagari font, and so
on.
2. We create one project file for each activity. The project files are
independent of each other but they require our custom image to run in
-- and it has to be an up-to-date version of that image.
The problem that I see people having is taking one of the activities
as a project file and loading it into some image other than an
epatti-<date>.image that's at least as new as the activity itself.
This use case isn't supported by the way we're doing things now.
What I want to do right now (this week) is to public a single .xo
bundle that contains all of our activities and runs smoothly on the
XO. I've done some hacking in the past couple of days to fix the
problem with the menu system and the memory growth when lots of
activities were opened (now they unload when you exit). To public this
will be an excellent little milestone.
Once that's done we have the option of investigating other ways to
distribute activities. For example, it could be interesting to
"statically link" the project files by adding any necessary code,
fonts, sounds, etc directly into the project file. Then the activities
would work in the standard etoys image and should be very stand-alone
-- but this will take some effort to investigate and may have other
side-effects (larger project files, slower to start, that sort of
thing).
So let's first create the stable .xo bundle and then talk about how to
improve on it.
> Have we uploaded our e-paati bundle into OLPC's git repository yet?
No, Bert recommended against using git for binary files -- he said
that there was a huge problem that doing 'checkout' will download all
revisions of all the files and take a phenomonally large amount of
time and bandwidth.
In our application to OLPC I'd actually asked for: trac, svn, joyride.
They gave us none of those but only git. I'll mail them again and ask
them to fix this up.