Reading Stephan's BotIncs progresses is encouraging about using etoys image as a base for additional Smalltalk application. Last November, related to DrGeo we had a thread about fast loading of compiled code in an existing image. The discussion went over my understanding and I am not sure if it lead to workable solution. What is the state of affair?
Hilaire
where can i read "Stephan's BotIncs progresses"? i am intrested in loading croquet image (wich is a smalltalk -squeak aplication) and i am realy intrested in that! could you give me any links related to this? i would appreciate your help! thanx in advance!
O/H Hilaire Fernandes έγραψε:
Reading Stephan's BotIncs progresses is encouraging about using etoys image as a base for additional Smalltalk application. Last November, related to DrGeo we had a thread about fast loading of compiled code in an existing image. The discussion went over my understanding and I am not sure if it lead to workable solution. What is the state of affair?
Hilaire _______________________________________________ Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
where can i read "Stephan's BotIncs progresses"? i am intrested in loading croquet image (wich is a smalltalk -squeak aplication) and i am realy intrested in that! could you give me any links related to this? i would appreciate your help! thanx in advance!
Since the different between Croquet image is vastly different from the Etoys image (loading whole Croquet packages onto the vanilla 3.8 image would take many minutes on my Pentium-M computer. It would take half hour or such, probably on XO), you would probably make/download a pre-configured image on another computer and use it on XO.
-- Yoshiki
Reading Stephan's BotIncs progresses is encouraging about using etoys image as a base for additional Smalltalk application. Last November, related to DrGeo we had a thread about fast loading of compiled code in an existing image. The discussion went over my understanding and I am not sure if it lead to workable solution. What is the state of affair?
There is not much progress since then. And I don't remember to see a viable solution proposed.
-- Yoshiki
Yoshiki Ohshima wrote:
Reading Stephan's BotIncs progresses is encouraging about using etoys image as a base for additional Smalltalk application. Last November, related to DrGeo we had a thread about fast loading of compiled code in an existing image. The discussion went over my understanding and I am not sure if it lead to workable solution. What is the state of affair?
There is not much progress since then. And I don't remember to see a viable solution proposed.
I looked at the code and could not see a solution within my grasp. Image segments needs references for symbols from the image and the only viable way is compiling the classes as far as I can see.
Karl
On Jan 3, 2008, at 0:16 , Karl wrote:
Yoshiki Ohshima wrote:
Reading Stephan's BotIncs progresses is encouraging about using etoys image as a base for additional Smalltalk application. Last November, related to DrGeo we had a thread about fast loading of compiled code in an existing image. The discussion went over my understanding and I am not sure if it lead to workable solution. What is the state of affair?
There is not much progress since then. And I don't remember to see a viable solution proposed.
I looked at the code and could not see a solution within my grasp. Image segments needs references for symbols from the image and the only viable way is compiling the classes as far as I can see.
Why wouldn't it work to do a forward-become of all the symbols from the segment to the ones in the image?
- Bert -
Bert Freudenberg wrote:
On Jan 3, 2008, at 0:16 , Karl wrote:
Yoshiki Ohshima wrote:
Reading Stephan's BotIncs progresses is encouraging about using etoys image as a base for additional Smalltalk application. Last November, related to DrGeo we had a thread about fast loading of compiled code in an existing image. The discussion went over my understanding and I am not sure if it lead to workable solution. What is the state of affair?
There is not much progress since then. And I don't remember to see a viable solution proposed.
I looked at the code and could not see a solution within my grasp. Image segments needs references for symbols from the image and the only viable way is compiling the classes as far as I can see.
Why wouldn't it work to do a forward-become of all the symbols from the segment to the ones in the image?
You read the 'within my grasp' ? ;-) I'm pretty sure someone with more knowledge than me could make this work.
Also in DrGeo there are several classes not in the image so a become would get into trouble.
Karl
Bert Freudenberg wrote:
I looked at the code and could not see a solution within my grasp. Image segments needs references for symbols from the image and the only viable way is compiling the classes as far as I can see.
Folks, If I remember correctly, a normal project load (of a .pr file) handles this perfectly well. It does not need to recompile classes. All symbols are in the "Outpointers" table, and are resolved to existing or new symbols when the ImageSegment is loaded. This is done for each literal frame of each method. It is just an object, afterall. Currently, only UniClasses (subclasses of Player) are allowed into a project file as objects. But, we could change this for something we wanted to load quickly. I assume you want the source code of the new class to be appended to the .changes file? That is what takes the time. We may be able to speed that up, or have these classes be without sources (decompiled but with comments).
--Ted.
Ted Kaehler wrote:
Bert Freudenberg wrote:
I looked at the code and could not see a solution within my grasp.
Image segments needs references for symbols from the image and the only viable
way is compiling the classes as far as I can see.
Folks, If I remember correctly, a normal project load (of a .pr file) handles this perfectly well. It does not need to recompile classes. All symbols are in the "Outpointers" table, and are resolved to existing or new symbols when the ImageSegment is loaded. This is done for each literal frame of each method. It is just an object, afterall. Currently, only UniClasses (subclasses of Player) are allowed into a project file as objects. But, we could change this for something we wanted to load quickly. I assume you want the source code of the new class to be appended to the .changes file? That is what takes the time. We may be able to speed that up, or have these classes be without sources (decompiled but with comments).
--Ted.
Ted, this is good news and I hope it's possible to make these changes. I tried to change the logic to include other objects than player but the objects became zombies.
karl
I don't understand much about the solution you are talking about. But I am sure it will be very useful to deploy third party Squeak application.
Hilaire
2008/1/3, karl karl.ramberg@comhem.se:
Ted Kaehler wrote:
Bert Freudenberg wrote:
If I remember correctly, a normal project load (of a .prfile) handles this perfectly well. It does not need to recompile classes. All symbols are in the "Outpointers" table, and are resolved to existing or new symbols when the ImageSegment is loaded. This is done for each literal frame of each method. It is just an object, afterall. Currently, only UniClasses (subclasses of Player) are allowed into a project file as objects. But, we could change this for something we wanted to load quickly. I assume you want the source code of the new class to be appended to the .changes file? That is what takes the time. We may be able to speed that up, or have these classes be without sources (decompiled but with comments).
--Ted.
Ted, this is good news and I hope it's possible to make these changes. I tried to change the logic to include other objects than player but the objects became zombies.
karl
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Hilaire Fernandes wrote:
I don't understand much about the solution you are talking about. But I am sure it will be very useful to deploy third party Squeak application.
Hilaire
I must say Hilaire, DrGeo is _very_ cool and it should be high priority include on the XO Karl
2008/1/3, karl karl.ramberg@comhem.se:
Ted Kaehler wrote:
Bert Freudenberg wrote:
If I remember correctly, a normal project load (of a .prfile) handles this perfectly well. It does not need to recompile classes. All symbols are in the "Outpointers" table, and are resolved to existing or new symbols when the ImageSegment is loaded. This is done for each literal frame of each method. It is just an object, afterall. Currently, only UniClasses (subclasses of Player) are allowed into a project file as objects. But, we could change this for something we wanted to load quickly. I assume you want the source code of the new class to be appended to the .changes file? That is what takes the time. We may be able to speed that up, or have these classes be without sources (decompiled but with comments).
--Ted.
Ted, this is good news and I hope it's possible to make these changes. I tried to change the logic to include other objects than player but the objects became zombies.
karl
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
etoys-dev@lists.squeakfoundation.org
-
Alex Asimakopoulos -
Bert Freudenberg -
Hilaire Fernandes -
karl -
Karl
-
Ted Kaehler -
Yoshiki Ohshima