[Pharo-project] PharoKernel #12121
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
Very impressive. Can't wait to see Pharo built from such a small image. Lukas On 2 September 2010 23:02, Pavel Krivanek <pavel.krivanek@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
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 <pavel.krivanek@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Sep 3, 2010 at 11:22 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
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 :( 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 <pavel.krivanek@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi, 2010/9/3 Mariano Martinez Peck <marianopeck@gmail.com>:
On Fri, Sep 3, 2010 at 11:22 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 <pavel.krivanek@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 <pavel.krivanek@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 <pavel.krivanek@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Is it morphic image? Or it is headless? I cant run it as usual image 2010/9/3 Pavel Krivanek <pavel.krivanek@gmail.com>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/9/3 Pavel Krivanek <pavel.krivanek@gmail.com>:
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.
?
On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants <george.herolyants@gmail.com> wrote:
2010/9/3 Pavel Krivanek <pavel.krivanek@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr 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 <pavel.krivanek@gmail.com>
On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants <george.herolyants@gmail.com> wrote:
2010/9/3 Pavel Krivanek <pavel.krivanek@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/9/3 Denis Kudriashov <dionisiydk@gmail.com>:
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 <pavel.krivanek@gmail.com>
On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants <george.herolyants@gmail.com> wrote:
2010/9/3 Pavel Krivanek <pavel.krivanek@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 <dionisiydk@gmail.com>:
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 <pavel.krivanek@gmail.com>
On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants <george.herolyants@gmail.com> wrote:
2010/9/3 Pavel Krivanek <pavel.krivanek@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <dionisiydk@gmail.com>:
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 <pavel.krivanek@gmail.com>
On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants <george.herolyants@gmail.com> wrote:
2010/9/3 Pavel Krivanek <pavel.krivanek@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
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 <dionisiydk@gmail.com>:
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 <pavel.krivanek@gmail.com>
On Fri, Sep 3, 2010 at 2:11 PM, George Herolyants <george.herolyants@gmail.com> wrote:
2010/9/3 Pavel Krivanek <pavel.krivanek@gmail.com>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
<george.herolyants@gmail.com> wrote:
2010/9/3 Pavel Krivanek <pavel.krivanek@gmail.com>:
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
participants (8)
-
Adrian Lienhard -
Denis Kudriashov -
George Herolyants -
Lukas Renggli -
Mariano Martinez Peck -
Miguel Enrique Cobá MartÃnez -
Pavel Krivanek -
Stéphane Ducasse