hane.duca...@inria.fr]
> Date d'envoi : dimanche 5 août 2012 17:47
> À : Pharo-project@lists.gforge.inria.fr
> Objet : Re: [Pharo-project] About the migration from PackageInfo to RPackage
>
> On Aug 5, 2012, at 2:54 PM, GOUBIER Thierry wrote:
>
>> Is this the reason wh
Mariano
I would suggest not to add the system Tanker but to develop it outside for now.
Else we will have to change it all the time.
Stef
On Aug 5, 2012, at 3:18 PM, Mariano Martinez Peck wrote:
>
>
> On Sun, Aug 5, 2012 at 2:33 PM, Stéphane Ducasse
> wrote:
>
> On Aug 5, 2012, at 2:27 PM
On Aug 5, 2012, at 3:18 PM, Mariano Martinez Peck wrote:
>
>
> On Sun, Aug 5, 2012 at 2:33 PM, Stéphane Ducasse
> wrote:
>
> On Aug 5, 2012, at 2:27 PM, Guillermo Polito wrote:
>
> > What Mariano means is that you can have MCPackage(X) containing categories
> > X-A, X-B, X-C. When that pa
On Aug 5, 2012, at 2:54 PM, GOUBIER Thierry wrote:
> Is this the reason why when I built my package tree in the AltBrowser, I get
> four packages (X, X-A, X-B, X-C) but X contains all the classes of X-A, X-B
> and X-C ?
Which package classes?
because MC use a pattern matching based on category
On Sun, Aug 5, 2012 at 2:33 PM, Stéphane Ducasse
wrote:
>
> On Aug 5, 2012, at 2:27 PM, Guillermo Polito wrote:
>
> > What Mariano means is that you can have MCPackage(X) containing
> categories X-A, X-B, X-C. When that package is loaded today, three
> RPackages are created: X-A, X-B, X-C. So RP
AFAIK, we decided (because that was the best migration path possible), when you
have packages X, X-A, X-B, X-C, just to keep package "X", then add class tags
(A, B, C) to corresponding classes. Of course that also means that we need to
update tools (nautilus) to show that tags, but thats no so d
On Aug 5, 2012, at 2:27 PM, Guillermo Polito wrote:
> What Mariano means is that you can have MCPackage(X) containing categories
> X-A, X-B, X-C. When that package is loaded today, three RPackages are
> created: X-A, X-B, X-C. So RPackages are more mapped from categories that
> from MCPackag
I do not get why do you use MCPackage
There is ring for that and MCPackage one day will disappear.
MCPAckage is just an internal abstraction of Monticello to represent a
bunch a classes.
You confused me.
Fuel should be concerned about RPackage not MCPackage. MC should deal and build
its
Date d'envoi : dimanche 5 août 2012 13:28
> À : Pharo-project@lists.gforge.inria.fr Development
> Objet : [Pharo-project] About the migration from PackageInfo to RPackage
>
> Hi guys
>
> PackageInfo has a large APi that is often not used.
> So I would suggest that we reduce th
What Mariano means is that you can have MCPackage(X) containing categories
X-A, X-B, X-C. When that package is loaded today, three RPackages are
created: X-A, X-B, X-C. So RPackages are more mapped from categories that
from MCPackages.
On Sun, Aug 5, 2012 at 2:24 PM, Stéphane Ducasse
wrote:
> >
>
> On Sun, Aug 5, 2012 at 1:28 PM, Stéphane Ducasse
> wrote:
> Hi guys
>
> PackageInfo has a large APi that is often not used.
> So I would suggest that we reduce the PackageInfo API first because it will
> lower the stress on RPackage to be offer a
> compatible interface.
> All the methods i
On Sun, Aug 5, 2012 at 1:48 PM, Guillermo Polito
wrote:
>
> On Sun, Aug 5, 2012 at 1:41 PM, Mariano Martinez Peck <
> marianop...@gmail.com> wrote:
>
>>
>>
>> On Sun, Aug 5, 2012 at 1:28 PM, Stéphane Ducasse <
>> stephane.duca...@inria.fr> wrote:
>>
>>> Hi guys
>>>
>>> PackageInfo has a large APi
On Sun, Aug 5, 2012 at 1:41 PM, Mariano Martinez Peck wrote:
>
>
> On Sun, Aug 5, 2012 at 1:28 PM, Stéphane Ducasse <
> stephane.duca...@inria.fr> wrote:
>
>> Hi guys
>>
>> PackageInfo has a large APi that is often not used.
>> So I would suggest that we reduce the PackageInfo API first because i
On Sun, Aug 5, 2012 at 1:28 PM, Stéphane Ducasse
wrote:
> Hi guys
>
> PackageInfo has a large APi that is often not used.
> So I would suggest that we reduce the PackageInfo API first because it
> will lower the stress on RPackage to be offer a
> compatible interface.
> All the methods in the comp
Hi guys
PackageInfo has a large APi that is often not used.
So I would suggest that we reduce the PackageInfo API first because it will
lower the stress on RPackage to be offer a
compatible interface.
All the methods in the compatibility should somehow disappear or only serve as
purpose to help
15 matches
Mail list logo
