Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image
Locked
Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image
 
|
On Fri, Oct 1, 2010 at 8:26 AM, Igor Stasenko <[hidden email]> wrote:
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?
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image
|
|
On Fri, 1 Oct 2010, Mariano Martinez Peck wrote:
> On Fri, Oct 1, 2010 at 8:26 AM, Igor Stasenko <[hidden email]> wrote: > >> On 1 October 2010 08:48, Mariano Martinez Peck <[hidden email]> >> wrote: >>> >>> >>> On Thu, Sep 30, 2010 at 11:07 PM, Johan Fabry <[hidden email]> >> 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 >>>> [hidden email] - http://dcc.uchile.cl/~jfabry<http://dcc.uchile.cl/%7Ejfabry> >>>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-users mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-users mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image
|
|
>>
>> 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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image
|
|
2010/10/2 Igor Stasenko <[hidden email]>:
>>> >>> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |