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/<https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%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. > 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. > > >
