Or better

remove the 50+ classes of Universe (see
http://lists.squeakfoundation.org/pipermail/beginners/2013-January/008500.html)
and add the AndreasSystemProfiler as a second profiler.

--Hannes

On 1/26/13, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Developers work with the Non-Core image daily. The Pharo-Kernel is a
> subset of it. So problems get detected.
>
> In the end this is the same approach which we have here in Squeak with
>
>      SmalltalkImage unloadAllKnownPackages
>
>      (We actually would need a integration server process which does this).
>
> But this does not answer the question which SystemProfiler should be
> included in the Non-Core image which people use daily.....
>
> We might just put a load script in the 'Extending the system' workspace.
>
> --Hannes
>
> On 1/26/13, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>
>> On 26.01.2013, at 12:04, "H. Hirzel" <hannes.hirzel at gmail.com> wrote:
>>
>>> There is the Pharo 2.0 image which is the developer image and a
>>> smaller one called 'Pharo Kernel'.
>>>
>>> https://ci.inria.fr/pharo/view/Pharo-Kernel-2.0/
>>>
>>> Both have various builds with various packages.
>>>
>>> --Hannes
>>
>> How does that deal with the problem Yanni described?
>>
>> - Bert -
>>
>>
>>> On 1/26/13, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>> On 26.01.2013, at 04:58, Yanni Chiu <yanni at rogers.com> wrote:
>>>>
>>>>> On 25/01/13 1:48 PM, H. Hirzel wrote:
>>>>>>
>>>>>> So this might be a good opportunity to start building another
>>>>>> distribution/release with what Frank proposes. So besides the current
>>>>>> one at http://www.squeakci.org/job/ReleaseSqueakTrunk/ we would have
>>>>>> a
>>>>>> "developer's release' with additional packages....
>>>>>
>>>>> +1/-1
>>>>>
>>>>> Don't forget the Pharo experience. There used to be a Pharo-Core-1.3
>>>>> and
>>>>> Pharo-1.3 (a.k.a. Pharo-dev).
>>>>>
>>>>> There was a ton of confusion when people reported a bug in "Pharo" -
>>>>> sometimes that meant Core, sometimes not.
>>>>>
>>>>> With Pharo-1.4, the distinction between Core and non-Core was
>>>>> abandoned.
>>>>> IIUC, the reason was that developers worked day-to-day with the
>>>>> non-Core
>>>>> image - refactoring and so on - then had to make sure the changes
>>>>> worked
>>>>> in Core too. Going the other way, when working only in Core, if code
>>>>> is
>>>>> refactored or eliminated (because it looks like no senders in Core),
>>>>> then
>>>>> the problems would show up later when the non-Core image is built or
>>>>> run.
>>>>
>>>>
>>>> So what is their solution now?
>>>>
>>>> - Bert -
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>