[squeak-dev] Re: AndreasSystemProfiler Released MIT

H. Hirzel hannes.hirzel at gmail.com
Sat Jan 26 11:12:44 UTC 2013


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 -
>>>
>>>
>>>
>>>
>>
>
>
>
>
>


More information about the Squeak-dev mailing list