[squeak-dev] Towards SqueakCore

Pavel Krivanek squeak1 at continentalbrno.cz
Mon Feb 11 14:25:50 UTC 2013


On Mon, Feb 11, 2013 at 1:05 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Hello Pavel
>
> Thank you for your recommendation. As not having followed closely what
> you and others  did in Pharo, may I ask you to give a short summary
> where you have reached now with Pharo core effort.
>
> I have seen quite a number of smaller Pharo images on the Pharo
> integration server but I am not sure what the status of them is.
>
>    https://ci.inria.fr/pharo/view/Pharo-Kernel-2.0/
>
> Please let me ask very basic questions.
>
> 1. Are they all derived from the the main current "full" Pharo2.0?

Yes, they are, the generation of this images is based on set of
scripts that we modify to reflect latests changes in Pharo.

> 2. What is the quality of them?

For the Pharo Kernel we have 3 Undeclared, no obsolete classes, 117
unimplemented calls and 7 failing tests. There is still a lot of space
for improvements. Others are more dirty.

> 3. How are they used by people?

I do not know about any real-life usage except usages by me. But we
used them a lot for testing and improving of projects like Fuel/Tanker
and bootstrapping. So we was able to produce full Morphic image
generated by bootstrapping. Because we have a CI setting, we can see
if some update has bad effect on modularity and UI independency of
Pharo.

Primary goal is not to have minimal system but to have clean and modular system.

Cheers,
-- Pavel

>
> Thank you in advance
>
> --Hannes
>
> On 2/11/13, Pavel Krivanek <squeak1 at continentalbrno.cz> wrote:
>> Hi,
>>
>> I recommend to follow the same way we use in Pharo:
>> - firstly prepare the SqueakCore and clean it a bit.
>> - make basic packages like Network and Monticello loadable.
>> - make the rest of the system loadable using Monticello at once,
>> ensure everything is working well
>> - start to improve granularity of that bundle
>>
>> Unfortunately, I have to say that Squeak is eons back from the point
>> of modularity.
>>
>> Cheers,
>> -- Pavel
>>
>> On Sun, Feb 10, 2013 at 12:51 AM, Frank Shearar <frank.shearar at gmail.com>
>> wrote:
>>> In the interests of revisiting Pavel Krivanek's work, and a long term
>>> goal of this community, I thought I'd use the Dependency Browser and
>>> dig out interpackage dependencies.
>>>
>>> By scraping the DependencyBrowser's contents together with a bit of UI
>>> scripting I've constructed a dotfile of Trunk (attached). Turning this
>>> into a PNG results in an 11MB image! [1] Nodes near the top are nodes
>>> that aren't used by many things.
>>>
>>> For instance, ReleaseBuilder's right at the top because nothing depends on
>>> it.
>>>
>>> One thing to note is that XML-Parser and Nebraska are only used by
>>> Universes, and that Universes isn't used by anything else.
>>>
>>> It occurs to me that we could thus remove these 3 packages from trunk
>>> and add the loading of these to ReleaseBuilderFor4dot5 [2], and still
>>> end up with a 4.5 that while apparently unchanged, actually has a
>>> smaller core.
>>>
>>> What do you think of trying this out as an experiment? How would we
>>> unload these packages? (I should note: I've nothing against these
>>> packages. They're just packages that aren't woven into the guts of the
>>> image, and are thus easily removable.)
>>>
>>> frank
>>>
>>> [1] If you have dot installed, `dot -Tpng -o trunk-deps.dot
>>> trunk-deps.png` will do the trick.
>>> [2] Installer squeak
>>>         package: 'trunk';
>>>         install: '39Deprecated-ar.19';
>>>         install: '311Deprecated-nice.2';
>>>         install: 'XML-Parser-ael.35';
>>>         install: 'Nebraska-ul.35';
>>>         install: 'Universes-nice.45'.
>>>
>>>
>>>
>>
>>
>


More information about the Squeak-dev mailing list