[Pharo-dev] Which tests should be run in CI?

Marcus Denker marcus.denker at inria.fr
Thu Dec 12 03:15:53 EST 2013


On 12 Dec 2013, at 08:22, Marcus Denker <marcus.denker at inria.fr> wrote:

> 
> On 12 Dec 2013, at 08:14, Tudor Girba <tudor at tudorgirba.com> wrote:
> 
>> Hi,
>> 
>> 
>> On Thu, Dec 12, 2013 at 7:59 AM, Marcus Denker <marcus.denker at inria.fr> wrote:
>> 
>> On 12 Dec 2013, at 06:31, Tudor Girba <tudor at tudorgirba.com> wrote:
>> 
>> > Hi Stephan,
>> >
>> > Thanks for pushing the #packages problem.
>> >
>> >
>> > But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo?
>> >
>> the test tests that there is no #packages in Pharo on the class side other than the one that returns the
>> rpackage istance.
>> —> this is the case, the test is green.
>> 
>> Oh, so the API classes were fixed. I should have checked before (I just did). Great.
>>  
> But *Grease* still is  the problem: in the tradition of the wonderful philosophy “Lets keep all smalltalk crappy
> and provide some layer on top”, it redefines #package and therefore requires that no Smalltalk ever
> implements #packages on the class side to return the system concept of package. 
> 
> What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class?
> What is it’s responsibility? wouldn’t it be good enough to have a #gpackage method?

Another idea: if there is #package in Grease, there should be a class GreasePackage (or Package?).
Maybe the API of the class is actually good (grease apis tend to be good). So maybe that API
makes sense to be provided by RPackage? 

The real question is: what is the implementation of #package in Grease, what does it return and
what does that object do?

	Marcus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131212/44e0bbbb/attachment-0002.html>


More information about the Pharo-dev mailing list