[Pharo-project] Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image
On Fri, Oct 1, 2010 at 8:26 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 1 October 2010 08:48, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Sep 30, 2010 at 11:07 PM, Johan Fabry <jfabry@dcc.uchile.cl>
wrote:
Hi all,
I am planning to put online a minimal image that contains AspectMaps,
with
some models pre-loaded. Two questions: - Is there an easy way to strip this image of dev tools et cetera?
Not really. The easiest way is to have a Configuration of Metacello that takes care of loading all your code with all your dependencies. Then, take a PharoCore and load your code there. In addition, you may want to evaluate "ScriptLoader cleanUpForProduction" at the end. Check the method to see what it does.
- How can I make it so that I can distribute it without the changes
file?
(Right now the image complains of a missing changes file if it is not there ...)
I am aware of "Smalltalk abandonSources" to avoid using .sources. You won't see things like the temp names, and stuff will be decompiled instead.
With a little effort, you can embed source code into method trailers. Then you won't need .sources nor .chanes to see the real source instead of decompiling it. But you will loose method stamps.
I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, if I will improve performance since I don't need to fetch a .sources file. what would be awesome is if we can have both, this is: for the dev image, I would like to have the sources in the image, but not for PharoCore. Or maybe also in PharoCore but to be sure to be able to remove them, and use .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction or similar. thoughts?
For the .changes you can start the image without them, there will raise a popup at the beginning. The problem is if you then do sometthing that should be written there. Not sure here...
yeah.
cheers
Mariano
Thanks in advance! -- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry<http://dcc.uchile.cl/%7Ejfabry> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
On Fri, 1 Oct 2010, Mariano Martinez Peck wrote:
On Fri, Oct 1, 2010 at 8:26 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 1 October 2010 08:48, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Thu, Sep 30, 2010 at 11:07 PM, Johan Fabry <jfabry@dcc.uchile.cl>
wrote:
Hi all,
I am planning to put online a minimal image that contains AspectMaps,
with
some models pre-loaded. Two questions: - Is there an easy way to strip this image of dev tools et cetera?
Not really. The easiest way is to have a Configuration of Metacello that takes care of loading all your code with all your dependencies. Then, take a PharoCore and load your code there. In addition, you may want to evaluate "ScriptLoader cleanUpForProduction" at the end. Check the method to see what it does.
- How can I make it so that I can distribute it without the changes
file?
(Right now the image complains of a missing changes file if it is not there ...)
I am aware of "Smalltalk abandonSources" to avoid using .sources. You won't see things like the temp names, and stuff will be decompiled instead.
With a little effort, you can embed source code into method trailers. Then you won't need .sources nor .chanes to see the real source instead of decompiling it. But you will loose method stamps.
I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, if I will improve performance since I don't need to fetch a .sources file. what would be awesome is if we can have both, this is: for the dev image, I would like to have the sources in the image, but not for PharoCore. Or maybe also in PharoCore but to be sure to be able to remove them, and use .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction or similar.
thoughts?
You'd also lose versioning, since a trailer can only hold one version of the source code. Btw, do you really have a performance issue reading the sources? With Cog and Squeak 4.2, I get: methods := CompiledMethod allInstances shuffle. [ methods do: #getSource ] timeToRun "===> 1162" So it takes ~25 microseconds to fetch the source of a method on average. That's more than 39000 methods per second. It should be enough IMHO. Levente
For the .changes you can start the image without them, there will raise a popup at the beginning. The problem is if you then do sometthing that should be written there. Not sure here...
yeah.
cheers
Mariano
Thanks in advance! -- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry<http://dcc.uchile.cl/%7Ejfabry> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, if I will improve performance since I don't need to fetch a .sources file. what would be awesome is if we can have both, this is: for the dev image, I would like to have the sources in the image, but not for PharoCore. Or maybe also in PharoCore but to be sure to be able to remove them, and use .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction or similar.
thoughts?
You'd also lose versioning, since a trailer can only hold one version of the source code. Btw, do you really have a performance issue reading the sources? With Cog and Squeak 4.2, I get:
methods := CompiledMethod allInstances shuffle. [ methods do: #getSource ] timeToRun "===> 1162"
So it takes ~25 microseconds to fetch the source of a method on average. That's more than 39000 methods per second. It should be enough IMHO.
Well, you can always change the trailer(s) to hold additional info. As i told before, we need a source management layer, which allows multiple different implementations, then its not quite important how/where we persisting sources, since we could switch between them, or use different source manager on a per-method basis.
Levente
-- Best regards, Igor Stasenko AKA sig.
2010/10/2 Igor Stasenko <siguctua@gmail.com>:
I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, if I will improve performance since I don't need to fetch a .sources file. what would be awesome is if we can have both, this is: for the dev image, I would like to have the sources in the image, but not for PharoCore. Or maybe also in PharoCore but to be sure to be able to remove them, and use .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction or similar.
thoughts?
You'd also lose versioning, since a trailer can only hold one version of the source code. Btw, do you really have a performance issue reading the sources? With Cog and Squeak 4.2, I get:
methods := CompiledMethod allInstances shuffle. [ methods do: #getSource ] timeToRun "===> 1162"
So it takes ~25 microseconds to fetch the source of a method on average. That's more than 39000 methods per second. It should be enough IMHO.
Well, you can always change the trailer(s) to hold additional info. As i told before, we need a source management layer, which allows multiple different implementations, then its not quite important how/where we persisting sources, since we could switch between them, or use different source manager on a per-method basis.
Sure, I was thinking of it, but removed methods will hardly have a trailer for example. And reconstructing the history will be difficult too. Nicolas
Levente
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Igor Stasenko -
Levente Uzonyi -
Mariano Martinez Peck -
Nicolas Cellier