Hi,
I uploaded the new version of PharoKernel #12121: https://gforge.inria.fr/frs/download.php/27438/PharoKernel-1.2-12121.zip The shrinking process is now based on packages. Cheers -- Pavel _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Very impressive. Can't wait to see Pharo built from such a small image.
Lukas On 2 September 2010 23:02, Pavel Krivanek <[hidden email]> wrote: > Hi, > > I uploaded the new version of PharoKernel #12121: > > https://gforge.inria.fr/frs/download.php/27438/PharoKernel-1.2-12121.zip > > The shrinking process is now based on packages. > > Cheers > -- Pavel > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
for me this is simple
- I would like to use a metacello configuration to reload everything in between this kernel image and the current 12121 but I do not have the time. So ... On Sep 2, 2010, at 11:08 PM, Lukas Renggli wrote: > Very impressive. Can't wait to see Pharo built from such a small image. > > Lukas > > On 2 September 2010 23:02, Pavel Krivanek <[hidden email]> wrote: >> Hi, >> >> I uploaded the new version of PharoKernel #12121: >> >> https://gforge.inria.fr/frs/download.php/27438/PharoKernel-1.2-12121.zip >> >> The shrinking process is now based on packages. >> >> Cheers >> -- Pavel >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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 |
In reply to this post by Lukas Renggli
I got an idea: I will ask gabriel to help me producing a metacello config for pharo core and once this is working we can start to
work on migrating to use PharoKernel as a basis. Stef On Sep 2, 2010, at 11:08 PM, Lukas Renggli wrote: > Very impressive. Can't wait to see Pharo built from such a small image. > > Lukas > > On 2 September 2010 23:02, Pavel Krivanek <[hidden email]> wrote: >> Hi, >> >> I uploaded the new version of PharoKernel #12121: >> >> https://gforge.inria.fr/frs/download.php/27438/PharoKernel-1.2-12121.zip >> >> The shrinking process is now based on packages. >> >> Cheers >> -- Pavel >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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 |
Hi,
it will require some additional work. I tried to load Monticello to PharoKernel and here are some notes: - some classes still need FileList for the service registration. - initialization order at the end of source files doesn't reflect class hierarchy order - whole class-based initialization problematic, it should be replaced by package-based initialization - we need a general mechanism that will enable to put versioned text files into MC packages (like current source.st), so we will be able to store initialization scripts, general package help etc. - Fonts need some refactorings. Some sort of AbstractFont only with capabilities required only by Text class should be part of the kernel. etc. etc. etc.... :-) Cheers, -- Pavel On Fri, Sep 3, 2010 at 12:50 PM, Stéphane Ducasse <[hidden email]> wrote: > I got an idea: I will ask gabriel to help me producing a metacello config for pharo core and once this is working we can start to > work on migrating to use PharoKernel as a basis. > > Stef > > On Sep 2, 2010, at 11:08 PM, Lukas Renggli wrote: > >> Very impressive. Can't wait to see Pharo built from such a small image. >> >> Lukas >> >> On 2 September 2010 23:02, Pavel Krivanek <[hidden email]> wrote: >>> Hi, >>> >>> I uploaded the new version of PharoKernel #12121: >>> >>> https://gforge.inria.fr/frs/download.php/27438/PharoKernel-1.2-12121.zip >>> >>> The shrinking process is now based on packages. >>> >>> Cheers >>> -- Pavel >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Pavel Krivanek-3
Is it morphic image? Or it is headless? I cant run it as usual image
2010/9/3 Pavel Krivanek <[hidden email]> Hi, _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Hi,
2010/9/3 Denis Kudriashov <[hidden email]>: > Is it morphic image? Or it is headless? I cant run it as usual image It is headless image. You have to use start-up scripts. See the file "build_image.sh". Cheers, -- Pavel _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/9/3 Pavel Krivanek <[hidden email]>:
> It is headless image. You have to use start-up scripts. See the file > "build_image.sh". So, why do you need this one: > - Fonts need some refactorings. Some sort of AbstractFont only with > capabilities required only by Text class should be part of the kernel. ? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants
<[hidden email]> wrote: > 2010/9/3 Pavel Krivanek <[hidden email]>: >> It is headless image. You have to use start-up scripts. See the file >> "build_image.sh". > > So, why do you need this one: > >> - Fonts need some refactorings. Some sort of AbstractFont only with >> capabilities required only by Text class should be part of the kernel. > Because we need Text in the kernel and this class has ugly dependencies on fonts. But this class does need only basic information about used fonts like name, size etc. It is not the only problematic part of the Text class. For example it is dependent on URLs. -- Pavel > ? > > _______________________________________________ > 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 |
Could you explain why Text is not part of ui system? And why it should be in kernel?
2010/9/3 Pavel Krivanek <[hidden email]>
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/9/3 Denis Kudriashov <[hidden email]>:
> Could you explain why Text is not part of ui system? And why it should be in > kernel? In fact some time ago I had a headless image without Text but it needed a lot of modifications. Pharo can use text formatting for the source codes. That is the main reason why Text should be in the kernel. -- Pavel > 2010/9/3 Pavel Krivanek <[hidden email]> >> >> On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants >> <[hidden email]> wrote: >> > 2010/9/3 Pavel Krivanek <[hidden email]>: >> >> It is headless image. You have to use start-up scripts. See the file >> >> "build_image.sh". >> > >> > So, why do you need this one: >> > >> >> - Fonts need some refactorings. Some sort of AbstractFont only with >> >> capabilities required only by Text class should be part of the kernel. >> > >> >> Because we need Text in the kernel and this class has ugly >> dependencies on fonts. But this class does need only basic information >> about used fonts like name, size etc. It is not the only problematic >> part of the Text class. For example it is dependent on URLs. >> >> -- Pavel >> >> > ? >> > >> > _______________________________________________ >> > 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 > > > _______________________________________________ > 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 |
On Sep 3, 2010, at 15:03 , Pavel Krivanek wrote: > 2010/9/3 Denis Kudriashov <[hidden email]>: >> Could you explain why Text is not part of ui system? And why it should be in >> kernel? > > In fact some time ago I had a headless image without Text but it > needed a lot of modifications. Pharo can use text formatting for the > source codes. That is the main reason why Text should be in the > kernel. oh, shouldn't we better remove the text formatting in source code feature? I assume almost nobody uses it and it is more annoying than helpful (e.g., if I copy code from a mail, I never want to style my code). Adrian > > -- Pavel > >> 2010/9/3 Pavel Krivanek <[hidden email]> >>> >>> On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants >>> <[hidden email]> wrote: >>>> 2010/9/3 Pavel Krivanek <[hidden email]>: >>>>> It is headless image. You have to use start-up scripts. See the file >>>>> "build_image.sh". >>>> >>>> So, why do you need this one: >>>> >>>>> - Fonts need some refactorings. Some sort of AbstractFont only with >>>>> capabilities required only by Text class should be part of the kernel. >>>> >>> >>> Because we need Text in the kernel and this class has ugly >>> dependencies on fonts. But this class does need only basic information >>> about used fonts like name, size etc. It is not the only problematic >>> part of the Text class. For example it is dependent on URLs. >>> >>> -- Pavel >>> >>>> ? >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
>> In fact some time ago I had a headless image without Text but it
>> needed a lot of modifications. Pharo can use text formatting for the >> source codes. That is the main reason why Text should be in the >> kernel. > > oh, shouldn't we better remove the text formatting in source code feature? Yes, this complicates everything and is not used anywhere. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Pavel Krivanek-3
> <[hidden email]> wrote:
>> 2010/9/3 Pavel Krivanek <[hidden email]>: >>> It is headless image. You have to use start-up scripts. See the file >>> "build_image.sh". >> >> So, why do you need this one: >> >>> - Fonts need some refactorings. Some sort of AbstractFont only with >>> capabilities required only by Text class should be part of the kernel. > > Because we need Text in the kernel and this class has ugly > dependencies on fonts. But this class does need only basic information > about used fonts like name, size etc. It is not the only problematic > part of the Text class. For example it is dependent on URLs. :) I think that we should go slowly. The tool that nicolas is building will help us on that because we can browse dependencies and mark them as blacklisted He will start to push on us things to fix. Jannik also asked to use DSM on the complete Pharo image and to qualify dependencies. I have 800 references to qualify and I started to write log now I will open tickets. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Lukas Renggli
I sent an email on this topics a while ago if I remember correctly but I got not
real feedback. We can always add another layer later to do hypertext navigation but not on the source code. >>> In fact some time ago I had a headless image without Text but it >>> needed a lot of modifications. Pharo can use text formatting for the >>> source codes. That is the main reason why Text should be in the >>> kernel. >> >> oh, shouldn't we better remove the text formatting in source code feature? > > Yes, this complicates everything and is not used anywhere. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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 |
In reply to this post by Adrian Lienhard
El vie, 03-09-2010 a las 15:24 +0200, Adrian Lienhard escribió:
> On Sep 3, 2010, at 15:03 , Pavel Krivanek wrote: > > > 2010/9/3 Denis Kudriashov <[hidden email]>: > >> Could you explain why Text is not part of ui system? And why it should be in > >> kernel? > > > > In fact some time ago I had a headless image without Text but it > > needed a lot of modifications. Pharo can use text formatting for the > > source codes. That is the main reason why Text should be in the > > kernel. > > oh, shouldn't we better remove the text formatting in source code feature? > > I assume almost nobody uses it and it is more annoying than helpful (e.g., if I copy code from a mail, I never want to style my code). +1 It can be added as an external packege for development images later. > > Adrian > > > > > > -- Pavel > > > >> 2010/9/3 Pavel Krivanek <[hidden email]> > >>> > >>> On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants > >>> <[hidden email]> wrote: > >>>> 2010/9/3 Pavel Krivanek <[hidden email]>: > >>>>> It is headless image. You have to use start-up scripts. See the file > >>>>> "build_image.sh". > >>>> > >>>> So, why do you need this one: > >>>> > >>>>> - Fonts need some refactorings. Some sort of AbstractFont only with > >>>>> capabilities required only by Text class should be part of the kernel. > >>>> > >>> > >>> Because we need Text in the kernel and this class has ugly > >>> dependencies on fonts. But this class does need only basic information > >>> about used fonts like name, size etc. It is not the only problematic > >>> part of the Text class. For example it is dependent on URLs. > >>> > >>> -- Pavel > >>> > >>>> ? > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
I added a ticket:
http://code.google.com/p/pharo/issues/detail?id=2908 Cheers, Adrian On Sep 3, 2010, at 17:20 , Miguel Enrique Cobá Martínez wrote: > El vie, 03-09-2010 a las 15:24 +0200, Adrian Lienhard escribió: >> On Sep 3, 2010, at 15:03 , Pavel Krivanek wrote: >> >>> 2010/9/3 Denis Kudriashov <[hidden email]>: >>>> Could you explain why Text is not part of ui system? And why it should be in >>>> kernel? >>> >>> In fact some time ago I had a headless image without Text but it >>> needed a lot of modifications. Pharo can use text formatting for the >>> source codes. That is the main reason why Text should be in the >>> kernel. >> >> oh, shouldn't we better remove the text formatting in source code feature? >> >> I assume almost nobody uses it and it is more annoying than helpful (e.g., if I copy code from a mail, I never want to style my code). > > +1 > > It can be added as an external packege for development images later. > >> >> Adrian >> >> >>> >>> -- Pavel >>> >>>> 2010/9/3 Pavel Krivanek <[hidden email]> >>>>> >>>>> On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants >>>>> <[hidden email]> wrote: >>>>>> 2010/9/3 Pavel Krivanek <[hidden email]>: >>>>>>> It is headless image. You have to use start-up scripts. See the file >>>>>>> "build_image.sh". >>>>>> >>>>>> So, why do you need this one: >>>>>> >>>>>>> - Fonts need some refactorings. Some sort of AbstractFont only with >>>>>>> capabilities required only by Text class should be part of the kernel. >>>>>> >>>>> >>>>> Because we need Text in the kernel and this class has ugly >>>>> dependencies on fonts. But this class does need only basic information >>>>> about used fonts like name, size etc. It is not the only problematic >>>>> part of the Text class. For example it is dependent on URLs. >>>>> >>>>> -- Pavel >>>>> >>>>>> ? >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > _______________________________________________ > 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 |
In reply to this post by Stéphane Ducasse
On Fri, Sep 3, 2010 at 11:22 AM, Stéphane Ducasse <[hidden email]> wrote: for me this is simple I was just thinking if this really makes sense or not...Suppose I have the PharoCore image 12121. From that image, I can shrink it and generate PharoKernel 12121. If I then have a configuration to load the core again, I will have again PharoCore 12121, which I already have, and which I can directly use. So...what is the sense of creating again PharoCore from PharoKernel? A different story is if PharoCore 12121 DOES NOT exist before...so you start from PharoKernel 12121 and THEN create PharoCore....but PharoKernel is a shrink from PharoCore...soo...? I am confused :( cheers mariano So ... _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Hi,
2010/9/3 Mariano Martinez Peck <[hidden email]>: > > > On Fri, Sep 3, 2010 at 11:22 AM, Stéphane Ducasse > <[hidden email]> wrote: >> >> for me this is simple >> - I would like to use a metacello configuration to reload >> everything in between >> this kernel image and the current 12121 but I do not have the time. >> > > I was just thinking if this really makes sense or not...Suppose I have the > PharoCore image 12121. > > From that image, I can shrink it and generate PharoKernel 12121. > > If I then have a configuration to load the core again, I will have again > PharoCore 12121, which I already have, and which I can directly use. > So...what is the sense of creating again PharoCore from PharoKernel? > > A different story is if PharoCore 12121 DOES NOT exist before...so you start > from PharoKernel 12121 and THEN create PharoCore....but PharoKernel is a > shrink from PharoCore...soo...? > > I am confused :( Original KernelImage used a Morphic image as the starting point too. The build-server updated the image, shrinked to the kernel and then he created a set of various headless and GUI-containing images (kernel, base, seaside, seasidexul, morhpiccore, tools, etoys...) where the original starting image was only one of many. Plus: - you can create updated kernel image without need of MC and network support in the kernel - you have better control about content of the image - the initialization process of the packages (like Morphic) is described well - you can create a build & test server easily with a lot of output images - requires good modularization - you have direct feedback if the shrink&build process is not broken Minus: - changes file is bigger because it stores all code above the level of the kernel as the new code Note that the shrinking process will be replaced with direct image bootstrapping. Cheers -- Pavel > > cheers > > mariano > > >> >> So ... >> >> On Sep 2, 2010, at 11:08 PM, Lukas Renggli wrote: >> >> > Very impressive. Can't wait to see Pharo built from such a small image. >> > >> > Lukas >> > >> > On 2 September 2010 23:02, Pavel Krivanek <[hidden email]> >> > wrote: >> >> Hi, >> >> >> >> I uploaded the new version of PharoKernel #12121: >> >> >> >> >> >> https://gforge.inria.fr/frs/download.php/27438/PharoKernel-1.2-12121.zip >> >> >> >> The shrinking process is now based on packages. >> >> >> >> Cheers >> >> -- Pavel >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> [hidden email] >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > >> > >> > -- >> > Lukas Renggli >> > www.lukas-renggli.ch >> > >> > _______________________________________________ >> > 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 > > > _______________________________________________ > 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 |
In reply to this post by Mariano Martinez Peck
> I was just thinking if this really makes sense or not...Suppose I have the PharoCore image 12121.
> > From that image, I can shrink it and generate PharoKernel 12121. > > If I then have a configuration to load the core again, I will have again PharoCore 12121, which I already have, and which I can directly use. So...what is the sense of creating again PharoCore from PharoKernel? > > A different story is if PharoCore 12121 DOES NOT exist before...so you start from PharoKernel 12121 and THEN create PharoCore....but PharoKernel is a shrink from PharoCore...soo...? > > I am confused :( > > cheers > > mariano > > > So ... listen little jedi - if we do not have an infrastructure in place to manage lot of packages then there is no need to push to get a little core. - I would be already really happy if I can take pharoKernel + MCloader -> loading metacello and loading all the packages and get 12121 - Now when we are in step 2 we will be able to - cut packages change the map and snap out fingers or think about the forces and produce better packaged system - iterate - I'm not a big believer of shrinking and I would like to have a bootstrap but this is the path to go. so ideally at the end of the process we should be able to even recreate bootstrappedpharoKernel from itself of another image. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |