On Jul 7, 2011, at 10:52 AM, Pavel Krivanek wrote:

> 
> 
> On Thu, Jul 7, 2011 at 10:19 AM, Marcus Denker <[email protected]> wrote:
> 
> On Jul 6, 2011, at 10:56 PM, Pavel Krivanek wrote:
> 
> > Hi Marcus,
> >
> > add this line to the initCore.st script on CI server:
> >
> > ActiveHand instVarNamed: #targetOffset put: 0@0.
> >
> Done and build started:
> 
>        https://ci.lille.inria.fr/pharo/job/Pharo%ckages now have already two 
> sets of du20Kernel%20Reload/
> 
> 
> > this will fix the testTargetPoint. The second and last failing tests is 
> > related to compressed unicode tables in the kernel image. I will prepare 
> > the code that will regenerate this tables.
> >
> > The second option is to disable call of privShrinkUnicodeTables method in 
> > privShrinkingProcess. The resultant kernel and gofer images will be bigger. 
> > The question is if we will shrink this tables by default.
> 
> I am in general not happy how resources are right now stored in the image... 
> the only way right now is to either have them just there as objects, 
> non-recreateble or people store stuff (fonts, bitmaps)
> as strings (or ByteArrays) in methods. This is not nice... but of course MC 
> can store it and so its the only option.
> 
> We should think about having an in-image, virtual file-system with all the 
> static stuff... maybe this could even be per package and serialized with MC 
> as part of the package?
> 
> It is quite easy to extend data stored in MC packages, for example for the 
> original versions of the KernelImage I extended packages with preamble and 
> postcript files. The only problem was with versioning of this extensions. 
> Life would me more easy if MC would provide general interface for versioning 
> of all kinds of files in the package.


Yes!

>  The MC packages now have already two sets of duplicated data: source (in the 
> .st file) and the MC History data... which should not be underestimated: MC 
> wastes right now 4MB of 13.5 MB in 1.4,
> In addtion, the fact that we have to wirite to .changes when loading a 
> package is far from nice... it would be better of packages would be 
> self-contained and the system would get the source
> from them.
> 
> Interesting idea. The good start would be introduction of general pluggable 
> source managers.
> 
> -- Pavel
>  
> 
>        Marcus
> 
> 
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
> 
> 
> 


Reply via email to