About RPackage

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

About RPackage

Stéphane Ducasse
Hi cyrille/doru and others.

I do not understand why
        RPackage organizer packages contains System?

In fact all the categories are mapped to packages and I wonder why.
I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
but it means that in such a case we should merge categories to get back the package we have right now
else we will end up with loading/saving problems.


Stef
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Tudor Girba
Hi Stef,

This was the decisions that two of us (I mean me and you) took :).

Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system.

The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages.

The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package.

Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way.

Cheers,
Doru



On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote:

> Hi cyrille/doru and others.
>
> I do not understand why
> RPackage organizer packages contains System?
>
> In fact all the categories are mapped to packages and I wonder why.
> I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
> but it means that in such a case we should merge categories to get back the package we have right now
> else we will end up with loading/saving problems.
>
>
> Stef

--
www.tudorgirba.com

"Presenting is storytelling."


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Stéphane Ducasse
In reply to this post by Stéphane Ducasse
Another point

RPackage>>named: aString

        | newPackage |
        newPackage := self new name: aString ;yourself.
        "self organizer registerPackage: newPackage."
        ^ newPackage

does not register the package and this looks suspicion to me.


In addition I do not remember the exact logic but the pattern with PackageInfo is that

PackageInfo named: #foo  creates the package if it does exist

PackageInfo class>>named: aString
        ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register]

So do you remember because it may be better to have the same creation protocol.

Stef


> Hi cyrille/doru and others.
>
> I do not understand why
> RPackage organizer packages contains System?
>
> In fact all the categories are mapped to packages and I wonder why.
> I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
> but it means that in such a case we should merge categories to get back the package we have right now
> else we will end up with loading/saving problems.
>
>
> Stef


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Tudor Girba
This was the main problem in the original implementation because the logic of the organizer also depended on this. So, we took it out and I find this way better :).

Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this.

Cheers,
Doru


On 1 Mar 2011, at 22:59, Stéphane Ducasse wrote:

> Another point
>
> RPackage>>named: aString
>
> | newPackage |
> newPackage := self new name: aString ;yourself.
> "self organizer registerPackage: newPackage."
> ^ newPackage
>
> does not register the package and this looks suspicion to me.
>
>
> In addition I do not remember the exact logic but the pattern with PackageInfo is that
>
> PackageInfo named: #foo  creates the package if it does exist
>
> PackageInfo class>>named: aString
> ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register]
>
> So do you remember because it may be better to have the same creation protocol.
>
> Stef
>
>
>> Hi cyrille/doru and others.
>>
>> I do not understand why
>> RPackage organizer packages contains System?
>>
>> In fact all the categories are mapped to packages and I wonder why.
>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
>> but it means that in such a case we should merge categories to get back the package we have right now
>> else we will end up with loading/saving problems.
>>
>>
>> Stef
>
>

--
www.tudorgirba.com

"Be rather willing to give than demanding to get."




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Stéphane Ducasse
In reply to this post by Tudor Girba

On Mar 1, 2011, at 10:57 PM, Tudor Girba wrote:

> Hi Stef,
>
> This was the decisions that two of us (I mean me and you) took :).

Yes I remember :)

> Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system.
>
> The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages.

a path is probably to evaluate the current categories and merged/reorganize them to look like packages.
Of course some people will cry but this is the way to go.

> The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package.
>
> Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way.

yes

>
> Cheers,
> Doru
>
>
>
> On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote:
>
>> Hi cyrille/doru and others.
>>
>> I do not understand why
>> RPackage organizer packages contains System?
>>
>> In fact all the categories are mapped to packages and I wonder why.
>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
>> but it means that in such a case we should merge categories to get back the package we have right now
>> else we will end up with loading/saving problems.
>>
>>
>> Stef
>
> --
> www.tudorgirba.com
>
> "Presenting is storytelling."
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Stéphane Ducasse
In reply to this post by Tudor Girba

On Mar 1, 2011, at 11:06 PM, Tudor Girba wrote:

> This was the main problem in the original implementation because the logic of the organizer also depended on this. So, we took it out and I find this way better :).

Ok I do not remember the protocol.
        we should ask the PackageOrganizer to create a package?
        or just to register it.
I have the impression that making sure that a package is registered wen created makes sense since the client does not have to do it and forget to do it.
So in the PackageInfo logic there are two points;
        - registration
        - query/creation

I have no problem to discard - query/creation
So to which of these two aspects are you referring to.

Stef

>
> Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this.
>
> Cheers,
> Doru
>
>
> On 1 Mar 2011, at 22:59, Stéphane Ducasse wrote:
>
>> Another point
>>
>> RPackage>>named: aString
>>
>> | newPackage |
>> newPackage := self new name: aString ;yourself.
>> "self organizer registerPackage: newPackage."
>> ^ newPackage
>>
>> does not register the package and this looks suspicion to me.
>>
>>
>> In addition I do not remember the exact logic but the pattern with PackageInfo is that
>>
>> PackageInfo named: #foo  creates the package if it does exist
>>
>> PackageInfo class>>named: aString
>> ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register]
>>
>> So do you remember because it may be better to have the same creation protocol.
>>
>> Stef
>>
>>
>>> Hi cyrille/doru and others.
>>>
>>> I do not understand why
>>> RPackage organizer packages contains System?
>>>
>>> In fact all the categories are mapped to packages and I wonder why.
>>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
>>> but it means that in such a case we should merge categories to get back the package we have right now
>>> else we will end up with loading/saving problems.
>>>
>>>
>>> Stef
>>
>>
>
> --
> www.tudorgirba.com
>
> "Be rather willing to give than demanding to get."
>
>
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Tudor Girba
Hi,

On 2 Mar 2011, at 09:12, Stéphane Ducasse wrote:

>
> On Mar 1, 2011, at 11:06 PM, Tudor Girba wrote:
>
>> This was the main problem in the original implementation because the logic of the organizer also depended on this. So, we took it out and I find this way better :).
>
> Ok I do not remember the protocol.
> we should ask the PackageOrganizer to create a package?
> or just to register it.

The RPackage class>>named: is an internal method used only by the RPackageOrganizer for creating a package.

If you want to ensure a package, you should use (I do not like the name :)):

RPackageOrganizer>>registerPackageNamed: aSymbol
        ^ packages at: aSymbol asSymbol ifAbsentPut: [RPackage named: aSymbol]

You can get to the default organizer via "RPackage organizer".

So, something like: RPackage organizer registerPackageNamed: 'MyPackage' should do it.

> I have the impression that making sure that a package is registered wen created makes sense since the client does not have to do it and forget to do it.
> So in the PackageInfo logic there are two points;
> - registration
> - query/creation
>
> I have no problem to discard - query/creation
> So to which of these two aspects are you referring to.

In the current RPackage implementation, #named: is a method meant to be used only internally. The problem with tying creation to registration is that you cannot use multiple Organizers easily (this was the reason why we decoupled the two).

What we could do is to rename #named: to #newWithName: and have named: be only a compatibility method that does:

named: aString
        ^ RPackage organizer registerPackageNamed: aString


Cheers,
Doru



> Stef
>
>>
>> Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this.
>>
>> Cheers,
>> Doru
>>
>>
>> On 1 Mar 2011, at 22:59, Stéphane Ducasse wrote:
>>
>>> Another point
>>>
>>> RPackage>>named: aString
>>>
>>> | newPackage |
>>> newPackage := self new name: aString ;yourself.
>>> "self organizer registerPackage: newPackage."
>>> ^ newPackage
>>>
>>> does not register the package and this looks suspicion to me.
>>>
>>>
>>> In addition I do not remember the exact logic but the pattern with PackageInfo is that
>>>
>>> PackageInfo named: #foo  creates the package if it does exist
>>>
>>> PackageInfo class>>named: aString
>>> ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register]
>>>
>>> So do you remember because it may be better to have the same creation protocol.
>>>
>>> Stef
>>>
>>>
>>>> Hi cyrille/doru and others.
>>>>
>>>> I do not understand why
>>>> RPackage organizer packages contains System?
>>>>
>>>> In fact all the categories are mapped to packages and I wonder why.
>>>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
>>>> but it means that in such a case we should merge categories to get back the package we have right now
>>>> else we will end up with loading/saving problems.
>>>>
>>>>
>>>> Stef
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Be rather willing to give than demanding to get."
>>
>>
>>
>>
>
>

--
www.tudorgirba.com

"Being happy is a matter of choice."




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Stéphane Ducasse
>>
>> Ok I do not remember the protocol.
>> we should ask the PackageOrganizer to create a package?
>> or just to register it.
>
> The RPackage class>>named: is an internal method used only by the RPackageOrganizer for creating a package.
>
> If you want to ensure a package, you should use (I do not like the name :)):

yes this is more than registering.
this is ensurePackageNamed:

> RPackageOrganizer>>registerPackageNamed: aSymbol
> ^ packages at: aSymbol asSymbol ifAbsentPut: [RPackage named: aSymbol]
>
> You can get to the default organizer via "RPackage organizer".
>
> So, something like: RPackage organizer registerPackageNamed: 'MyPackage' should do it.
>
>> I have the impression that making sure that a package is registered wen created makes sense since the client does not have to do it and forget to do it.
>> So in the PackageInfo logic there are two points;
>> - registration
>> - query/creation
>>
>> I have no problem to discard - query/creation
>> So to which of these two aspects are you referring to.
>
> In the current RPackage implementation, #named: is a method meant to be used only internally. The problem with tying creation to registration is that you cannot use multiple Organizers easily (this was the reason why we decoupled the two).
>
> What we could do is to rename #named: to #newWithName: and have named: be only a compatibility method that does:
>
> named: aString
> ^ RPackage organizer registerPackageNamed: aString

Yes good idea.

>
>
> Cheers,
> Doru
>
>
>
>> Stef
>>
>>>
>>> Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 1 Mar 2011, at 22:59, Stéphane Ducasse wrote:
>>>
>>>> Another point
>>>>
>>>> RPackage>>named: aString
>>>>
>>>> | newPackage |
>>>> newPackage := self new name: aString ;yourself.
>>>> "self organizer registerPackage: newPackage."
>>>> ^ newPackage
>>>>
>>>> does not register the package and this looks suspicion to me.
>>>>
>>>>
>>>> In addition I do not remember the exact logic but the pattern with PackageInfo is that
>>>>
>>>> PackageInfo named: #foo  creates the package if it does exist
>>>>
>>>> PackageInfo class>>named: aString
>>>> ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register]
>>>>
>>>> So do you remember because it may be better to have the same creation protocol.
>>>>
>>>> Stef
>>>>
>>>>
>>>>> Hi cyrille/doru and others.
>>>>>
>>>>> I do not understand why
>>>>> RPackage organizer packages contains System?
>>>>>
>>>>> In fact all the categories are mapped to packages and I wonder why.
>>>>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
>>>>> but it means that in such a case we should merge categories to get back the package we have right now
>>>>> else we will end up with loading/saving problems.
>>>>>
>>>>>
>>>>> Stef
>>>>
>>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Be rather willing to give than demanding to get."
>>>
>>>
>>>
>>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Being happy is a matter of choice."
>
>
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Stéphane Ducasse
In reply to this post by Tudor Girba

On Mar 1, 2011, at 10:57 PM, Tudor Girba wrote:

> Hi Stef,
>
> This was the decisions that two of us (I mean me and you) took :).
>
> Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system.


Doru I'm afraid that it will not work because it means that suddenly people will have to change all the configurationOf.
We should come up with a smooth transition phase (now this is true that if we could get rid of categories it would be good)

> The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages.
>
> The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package.


the problem is that it implies that we will have to change all the configurationOfXXX (or we should shrink all the packages

>
> Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way.
>
> Cheers,
> Doru
>
>
>
> On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote:
>
>> Hi cyrille/doru and others.
>>
>> I do not understand why
>> RPackage organizer packages contains System?
>>
>> In fact all the categories are mapped to packages and I wonder why.
>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
>> but it means that in such a case we should merge categories to get back the package we have right now
>> else we will end up with loading/saving problems.
>>
>>
>> Stef
>
> --
> www.tudorgirba.com
>
> "Presenting is storytelling."
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

abergel
>> This was the decisions that two of us (I mean me and you) took :).
>>
>> Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system.
>
>
> Doru I'm afraid that it will not work because it means that suddenly people will have to change all the configurationOf.
> We should come up with a smooth transition phase (now this is true that if we could get rid of categories it would be good)

PackageInfo and RPackage cannot coexist?

In any case, it will not be a problem for me to update all my config with this new schema.

Alexandre



>
>> The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages.
>>
>> The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package.
>
>
> the problem is that it implies that we will have to change all the configurationOfXXX (or we should shrink all the packages
>
>>
>> Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way.
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote:
>>
>>> Hi cyrille/doru and others.
>>>
>>> I do not understand why
>>> RPackage organizer packages contains System?
>>>
>>> In fact all the categories are mapped to packages and I wonder why.
>>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
>>> but it means that in such a case we should merge categories to get back the package we have right now
>>> else we will end up with loading/saving problems.
>>>
>>>
>>> Stef
>>
>> --
>> www.tudorgirba.com
>>
>> "Presenting is storytelling."
>>
>>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Henrik Sperre Johansen

On Mar 3, 2011, at 2:01 52PM, Alexandre Bergel wrote:

This was the decisions that two of us (I mean me and you) took :).

Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system.


Doru I'm afraid that it will not work because it means that suddenly people will have to change all the configurationOf.
We should come up with a smooth transition phase (now this is true that if we could get rid of categories it would be good)

PackageInfo and RPackage cannot coexist?
It's been awhile since I looked at RPacakge, but...
Not if you want a clean transition, you either use one, or the other.
Trying to maintain the package structure in two systems at a time can only lead to trouble, especially when they do not have the same constraints. (RPackage is not tied/derived from to category classification like PackageInfo is)


In any case, it will not be a problem for me to update all my config with this new schema.

Alexandre

I'm not sure what you mean by configs.
The contents of a Monticello package is simply a collection of definitions, and will stay the same.
The browser will probably need updating though, since extensions no longer necessarily have to be in a *packagename category .
Loading a Monticello package stored from an RPackage-based system into a system still using PackageInfo might cause false dirties , for the same reason.
As long as there is no package browser as standard (like there is in VW), and people still specify extensions by using * categories in a system browser, that's not likely to be a big issue though. RPackage does make it much easier to create a performant package browser though :)

Cheers,
Henry

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Miguel Cobá
In reply to this post by abergel
Same for me.
Lets avoid make's issues with tabulator in unix, now that are few users.

Cheers

El jue, 03-03-2011 a las 10:01 -0300, Alexandre Bergel escribió:

> >> This was the decisions that two of us (I mean me and you) took :).
> >>
> >> Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system.
> >
> >
> > Doru I'm afraid that it will not work because it means that suddenly people will have to change all the configurationOf.
> > We should come up with a smooth transition phase (now this is true that if we could get rid of categories it would be good)
>
> PackageInfo and RPackage cannot coexist?
>
> In any case, it will not be a problem for me to update all my config with this new schema.
>
> Alexandre
>
>
>
> >
> >> The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages.
> >>
> >> The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package.
> >
> >
> > the problem is that it implies that we will have to change all the configurationOfXXX (or we should shrink all the packages
> >
> >>
> >> Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way.
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >>
> >> On 1 Mar 2011, at 22:44, Stéphane Ducasse wrote:
> >>
> >>> Hi cyrille/doru and others.
> >>>
> >>> I do not understand why
> >>> RPackage organizer packages contains System?
> >>>
> >>> In fact all the categories are mapped to packages and I wonder why.
> >>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo,
> >>> but it means that in such a case we should merge categories to get back the package we have right now
> >>> else we will end up with loading/saving problems.
> >>>
> >>>
> >>> Stef
> >>
> >> --
> >> www.tudorgirba.com
> >>
> >> "Presenting is storytelling."
> >>
> >>
> >
> >
>

--
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

abergel
In reply to this post by Henrik Sperre Johansen
>> In any case, it will not be a problem for me to update all my config with this new schema.

> I'm not sure what you mean by configs.
> The contents of a Monticello package is simply a collection of definitions, and will stay the same.
> The browser will probably need updating though, since extensions no longer necessarily have to be in a *packagename category .
> Loading a Monticello package stored from an RPackage-based system into a system still using PackageInfo might cause false dirties , for the same reason.
> As long as there is no package browser as standard (like there is in VW), and people still specify extensions by using * categories in a system browser, that's not likely to be a big issue though. RPackage does make it much easier to create a performant package browser though :)

For example, currently, ConfigurationOfMetacelloBrowser loads one package, MetacelloBrowser. But the package itself has many categories (-Core, -Test, ...). So, if each class category is a package, then I will have to update the category. But I am for it!
The cost of updating configurations is much less than what we are all spending because PackageInfo (just think how many times you have press '+Package' in the Monticello browser).

Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: About RPackage

Stéphane Ducasse
In reply to this post by Henrik Sperre Johansen
henrik and others


We are making sure that the IDE generates information so that the new organizer deals well with *notation
even if internally he does not use that.

The problem is that in PackageInfo

        Kernel-Text
        Kernel-Foo
       
are both in Kernel package.
Now in RPackage
        Kernel-Text
        Kernel-Foo
are two different packages and this is why I'm saying that we should find a path because we will break
existing configurationOf....

Stef




Loading...