The Trunk: Morphic-laza.489.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

The Trunk: Morphic-laza.489.mcz

commits-2
Alexander Lazarević uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-laza.489.mcz

==================== Summary ====================

Name: Morphic-laza.489
Author: laza
Time: 8 December 2010, 2:00:22.014 pm
UUID: 0a444f28-0d28-5f4c-8d31-511261f7a98c
Ancestors: Morphic-laza.488

Provide a recipe for loading OCompletion in the "Extending the system" workspace

=============== Diff against Morphic-laza.488 ===============

Item was changed:
  ----- Method: TheWorldMainDockingBar>>extendingTheSystem (in category 'submenu - help') -----
  extendingTheSystem
  ^'"Note: Please edit this workspace and add your own contributions.
  To submit it to the inbox open the Monticello browser and submit it from there.
  Save the package ''* Morphic'' to the inbox."
 
  "Updating your system:
  The following will set the default update URL to receive development updates.
  For developers and dare-devils only."
 
  MCMcmUpdater defaultUpdateURL: ''http://source.squeak.org/trunk''.
 
  "Installing new packages:
  The following expression show how to load many interesting packages into Squeak."
 
  "FFI: http://source.squeak.org/FFI.html"
  (Installer repository: ''http://source.squeak.org/FFI'')
  install: ''FFI-Pools'';
  install: ''FFI-Kernel'';
  install: ''FFI-Tests'';
  install: ''FFI-Win32'';
  install: ''FFI-MacOS'';
  install: ''FFI-Unix''.
 
+ "OCompletion provides source code completion as you type"
+ (Installer ss project: ''OCompletion'') install: ''Ocompletion''.
+ (Smalltalk at: #ECToolSet) register.
+ (Smalltalk at: #ToolSet) default: (Smalltalk at: #ECToolSet).
+
  "Omnibrowser, including Refactoring engine"
  (Installer ss project: ''MetacelloRepository'') install: ''ConfigurationOfOmniBrowser''.
  ((Smalltalk at: #ConfigurationOfOmniBrowser) project perform: #lastVersion) load: #( Dev ).
 
  "Seaside 2.8 http://www.seaside.st"
  (Installer ss project: ''MetacelloRepository'') install: ''ConfigurationOfSeaside28''.
  "WAKom startOn: 9090"
 
  "Seaside 2.8 Examples http://www.seaside.st"
  (Installer ss project: ''MetacelloRepository'') install: ''ConfigurationOfSeaside28Examples''.
  (Smalltalk at: #ConfigurationOfSeaside28Examples) load.
 
  "Seaside 3.0 http://www.seaside.st"
  (Installer ss project: ''MetacelloRepository'') install: ''ConfigurationOfSeaside30''.
  (Smalltalk at: #ConfigurationOfSeaside30) load.
  (Smalltalk at: #WAPharoServerAdaptorBrowser) open.
 
  "Pier CMS: http://www.piercms.com"
  (Installer ss project: ''MetacelloRepository'') install: ''ConfigurationOfPier2''.
  (Smalltalk at: #ConfigurationOfPier2) load.
 
  (Installer lukas project: ''pier2'') install: ''Pier-Blog''.
  (Installer lukas project: ''pier2'') install: ''Pier-Book''.
  (Installer lukas project: ''pier2addons'') install: ''Pier-Setup''.
  (Smalltalk at: #PRDistribution)  new register.
  !!
+ ]style[(189 2 139 15 17 1 32 3 108 2 40 12 11 1 30 3 8 1 11 3 8 1 12 3 8 1 11 3 8 1 11 3 8 1 11 3 8 1 10 3 57 12 2 1 8 1 13 2 8 1 13 13 3 1 10 2 8 13 3 1 8 2 8 12 3 1 10 4 44 11 2 1 8 1 21 2 8 1 28 14 3 1 1 28 7 11 11 2 5 4 3 5 35 12 2 1 8 1 21 2 8 1 26 2 21 2 44 12 2 1 8 1 21 2 8 1 34 13 3 1 33 2 4 3 35 12 2 1 8 1 21 2 8 1 26 13 3 1 25 2 4 13 3 1 28 2 4 3 34 12 2 1 8 1 21 2 8 1 22 13 3 1 21 2 4 14 5 1 8 1 7 2 8 1 11 13 5 1 8 1 7 2 8 1 11 13 5 1 8 1 13 2 8 1 12 13 3 1 15 3 3 1 8 2)c000122122,cblack;,c000122122,cblack;,c000000122,cblack;,c122000122,cblack;,c000122122,cblack;,c000122122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000127127,cblack;,c000000127,cblack;,c000000127,cblack;,c127000127,cblack;,c000000127,cblack;,c127000127,cblack;,c000000127,cblack;,c000000127,cblack;,c000000127,cblack;,c000000127,cblack;,c000000127,cblack;,c000000127,cblack;,c000000127,cblack;,c000000127,cblack;,c000122122,cblack;,c000000125,cblack;,c000000125,cblack;,c125000125,cblack;,c000000125,cblack;,c125000125,cblack;,c000000122,cblack;,c000000122,cblack;,c000000125,cblack;,c000000125,cblack;,c000000125,cblack;,c000000125,cblack;,c000122122,cblack;,c000000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000122122,cblack;,c000122122,cblack;,c000000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000122122,cblack;,c000000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000122122,cblack;,c000000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c122000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000000122,cblack;,c000000122,cblack;!!' readStream nextChunkText!
- ]style[(189 2 139 15 17 1 32 3 108 2 40 12 11 1 30 3 8 1 11 3 8 1 12 3 8 1 11 3 8 1 11 3 8 1 11 3 8 1 10 3 44 11 2 1 8 1 21 2 8 1 28 14 3 1 1 28 7 11 11 2 5 4 3 5 35 12 2 1 8 1 21 2 8 1 26 2 21 2 44 12 2 1 8 1 21 2 8 1 34 13 3 1 33 2 4 3 35 12 2 1 8 1 21 2 8 1 26 13 3 1 25 2 4 13 3 1 28 2 4 3 34 12 2 1 8 1 21 2 8 1 22 13 3 1 21 2 4 14 5 1 8 1 7 2 8 1 11 13 5 1 8 1 7 2 8 1 11 13 5 1 8 1 13 2 8 1 12 13 3 1 15 3 3 1 8 2)c000123123,cblack;,c000123123,cblack;,c000000123,cblack;,c123000123,cblack;,c000123123,cblack;,c000123123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000123123,cblack;,c000000126,cblack;,c000000126,cblack;,c126000126,cblack;,c000000126,cblack;,c126000126,cblack;,c000000123,cblack;,c000000123,cblack;,c000000126,cblack;,c000000126,cblack;,c000000126,cblack;,c000000126,cblack;,c000123123,cblack;,c000000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000123123,cblack;,c000123123,cblack;,c000000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000123123,cblack;,c000000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000123123,cblack;,c000000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c123000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000000123,cblack;,c000000123,cblack;!!' readStream nextChunkText!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

Tobias Pape
Hi,

Am 2010-12-08 um 13:00 schrieb [hidden email]:

> Alexander Lazarević uploaded a new version of Morphic to project The Trunk:
> http://source.squeak.org/trunk/Morphic-laza.489.mcz
>
> ==================== Summary ====================
>
> Name: Morphic-laza.489
> Author: laza
> Time: 8 December 2010, 2:00:22.014 pm
> UUID: 0a444f28-0d28-5f4c-8d31-511261f7a98c
> Ancestors: Morphic-laza.488
>
> Provide a recipe for loading OCompletion in the "Extending the system" workspace
>
> =============== Diff against Morphic-laza.488 ===============
>

>
> + "OCompletion provides source code completion as you type"
> + (Installer ss project: ''OCompletion'') install: ''Ocompletion''.
> + (Smalltalk at: #ECToolSet) register.
> + (Smalltalk at: #ToolSet) default: (Smalltalk at: #ECToolSet).
> +


Shouldn't we stick to the Metacello Configuration, here?

So Long,
        -Tobias
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

laza
You tell me. The benefit I see of just using installer is, that only one package gets installed. Using a Metacello Config I get all the Metacello mambo jumbo + Gofer + RoelTyper. I don't know if OCompletion benefits a great deal by having RoelTyper installed. Maybe someone else could answer this.
And with installer it loads about eight times faster. So if OCompletion will not be an integrated part of 4.2, this seems to be a quick way to get it into such an image.
One could see how complex the OCompletion installtion will be in the future and switch to a Metacello Config then, no?

Alex

2010/12/8 Tobias Pape <[hidden email]>
Hi,

Am 2010-12-08 um 13:00 schrieb [hidden email]:
> Alexander Lazarevi&#263; uploaded a new version of Morphic to project The Trunk:
> http://source.squeak.org/trunk/Morphic-laza.489.mcz
>
> ==================== Summary ====================
>
> Name: Morphic-laza.489
> Author: laza
> Time: 8 December 2010, 2:00:22.014 pm
> UUID: 0a444f28-0d28-5f4c-8d31-511261f7a98c
> Ancestors: Morphic-laza.488
>
> Provide a recipe for loading OCompletion in the "Extending the system" workspace
>
> =============== Diff against Morphic-laza.488 ===============
>

>
> + "OCompletion provides source code completion as you type"
> + (Installer ss project: ''OCompletion'') install: ''Ocompletion''.
> + (Smalltalk at: #ECToolSet) register.
> + (Smalltalk at: #ToolSet) default: (Smalltalk at: #ECToolSet).
> +


Shouldn't we stick to the Metacello Configuration, here?

So Long,
       -Tobias



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

Tobias Pape
Am 2010-12-09 um 10:17 schrieb Alexander Lazarević:
>
> You tell me. The benefit I see of just using installer is, that only one package gets installed. Using a Metacello Config I get all the Metacello mambo jumbo + Gofer + RoelTyper. I don't know if OCompletion benefits a great deal by having RoelTyper installed. Maybe someone else could answer this.
> And with installer it loads about eight times faster. So if OCompletion will not be an integrated part of 4.2, this seems to be a quick way to get it into such an image.
> One could see how complex the OCompletion installtion will be in the future and switch to a Metacello Config then, no?
>

Actually, RoleTyper seems to be a requirement of
OCompletion.
  FWIW, The Metacello Config is meant to be Installable
at any future point in time, your installer Doit + the
two other doits may change. For example, if the developers
of OCompletion just put another _non-working_ version
into their repo, your doit will miraculously result in
a non-working OCompletion, while a Metacello-installation
would still work. Or consider a rename of the packages
from Ocompletion to OCompletion. The metacello-config
can immediately be updated, while the 'Extending the System'-
Workspace cannot as fast be updated.

My rationale: Why shouldn't we use Metacello Configs if
they are there and doing what we want: Installing the
software.

So Long,
        -Toibas


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

Levente Uzonyi-2
In reply to this post by laza
On Thu, 9 Dec 2010, Alexander Lazarević wrote:

> You tell me. The benefit I see of just using installer is, that only one
> package gets installed. Using a Metacello Config I get all the Metacello
> mambo jumbo + Gofer + RoelTyper. I don't know if OCompletion benefits a
> great deal by having RoelTyper installed. Maybe someone else could answer
> this.

RoelTyper is optional for OCompletion. It's used by ECompletion which is
used as a fallback by OCompletion. There's also a preference that allows
you to switch to ECompletion from OCompletion. This is possible, because
the Ocompletion package includes ECompletion, so when you load
OCompletion you have ECompletion too "for free".


Levente

> And with installer it loads about eight times faster. So if OCompletion will
> not be an integrated part of 4.2, this seems to be a quick way to get it
> into such an image.
> One could see how complex the OCompletion installtion will be in the future
> and switch to a Metacello Config then, no?
>
> Alex
>
> 2010/12/8 Tobias Pape <[hidden email]>
>
>> Hi,
>>
>> Am 2010-12-08 um 13:00 schrieb [hidden email]:
>>> Alexander Lazarevi&#263; uploaded a new version of Morphic to project The
>> Trunk:
>>> http://source.squeak.org/trunk/Morphic-laza.489.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Morphic-laza.489
>>> Author: laza
>>> Time: 8 December 2010, 2:00:22.014 pm
>>> UUID: 0a444f28-0d28-5f4c-8d31-511261f7a98c
>>> Ancestors: Morphic-laza.488
>>>
>>> Provide a recipe for loading OCompletion in the "Extending the system"
>> workspace
>>>
>>> =============== Diff against Morphic-laza.488 ===============
>>>
>>
>>>
>>> + "OCompletion provides source code completion as you type"
>>> + (Installer ss project: ''OCompletion'') install: ''Ocompletion''.
>>> + (Smalltalk at: #ECToolSet) register.
>>> + (Smalltalk at: #ToolSet) default: (Smalltalk at: #ECToolSet).
>>> +
>>
>>
>> Shouldn't we stick to the Metacello Configuration, here?
>>
>> So Long,
>>         -Tobias
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

Chris Muller-3
In reply to this post by Tobias Pape
> My rationale: Why shouldn't we use Metacello Configs if
> they are there and doing what we want: Installing the
> software.

-1.  My preference is to stay simple.  Just use Installer scripts to
load a configuration of exact-versions that work together.

A separate Installer script could be used to "merge the latest
versions" if people want that.

I don't see the need to introduce Metacello for these simple requirements.

 - Chris

On Thu, Dec 9, 2010 at 4:13 AM, Tobias Pape <[hidden email]> wrote:

> Am 2010-12-09 um 10:17 schrieb Alexander Lazarević:
>>
>> You tell me. The benefit I see of just using installer is, that only one package gets installed. Using a Metacello Config I get all the Metacello mambo jumbo + Gofer + RoelTyper. I don't know if OCompletion benefits a great deal by having RoelTyper installed. Maybe someone else could answer this.
>> And with installer it loads about eight times faster. So if OCompletion will not be an integrated part of 4.2, this seems to be a quick way to get it into such an image.
>> One could see how complex the OCompletion installtion will be in the future and switch to a Metacello Config then, no?
>>
>
> Actually, RoleTyper seems to be a requirement of
> OCompletion.
>  FWIW, The Metacello Config is meant to be Installable
> at any future point in time, your installer Doit + the
> two other doits may change. For example, if the developers
> of OCompletion just put another _non-working_ version
> into their repo, your doit will miraculously result in
> a non-working OCompletion, while a Metacello-installation
> would still work. Or consider a rename of the packages
> from Ocompletion to OCompletion. The metacello-config
> can immediately be updated, while the 'Extending the System'-
> Workspace cannot as fast be updated.
>
> My rationale: Why shouldn't we use Metacello Configs if
> they are there and doing what we want: Installing the
> software.
>
> So Long,
>        -Toibas
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

Nicolas Cellier
2010/12/9 Chris Muller <[hidden email]>:

>> My rationale: Why shouldn't we use Metacello Configs if
>> they are there and doing what we want: Installing the
>> software.
>
> -1.  My preference is to stay simple.  Just use Installer scripts to
> load a configuration of exact-versions that work together.
>
> A separate Installer script could be used to "merge the latest
> versions" if people want that.
>
> I don't see the need to introduce Metacello for these simple requirements.
>
>  - Chris
>

As I understand it, with Metacello you can specify something like:
"take the last stable version known to work in trunk 4.2"
It could seem like an advantage.
But there is no magic, someone has to hardcode some version numbers somewhere.

The right question is whether we should maintain two different
versions of these informations (Metacello + trunk/Installer) or a
single one ?

Nicolas

> On Thu, Dec 9, 2010 at 4:13 AM, Tobias Pape <[hidden email]> wrote:
>> Am 2010-12-09 um 10:17 schrieb Alexander Lazarević:
>>>
>>> You tell me. The benefit I see of just using installer is, that only one package gets installed. Using a Metacello Config I get all the Metacello mambo jumbo + Gofer + RoelTyper. I don't know if OCompletion benefits a great deal by having RoelTyper installed. Maybe someone else could answer this.
>>> And with installer it loads about eight times faster. So if OCompletion will not be an integrated part of 4.2, this seems to be a quick way to get it into such an image.
>>> One could see how complex the OCompletion installtion will be in the future and switch to a Metacello Config then, no?
>>>
>>
>> Actually, RoleTyper seems to be a requirement of
>> OCompletion.
>>  FWIW, The Metacello Config is meant to be Installable
>> at any future point in time, your installer Doit + the
>> two other doits may change. For example, if the developers
>> of OCompletion just put another _non-working_ version
>> into their repo, your doit will miraculously result in
>> a non-working OCompletion, while a Metacello-installation
>> would still work. Or consider a rename of the packages
>> from Ocompletion to OCompletion. The metacello-config
>> can immediately be updated, while the 'Extending the System'-
>> Workspace cannot as fast be updated.
>>
>> My rationale: Why shouldn't we use Metacello Configs if
>> they are there and doing what we want: Installing the
>> software.
>>
>> So Long,
>>        -Toibas
>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

laza
In reply to this post by Tobias Pape
Hi Tobias!

2010/12/9 Tobias Pape <[hidden email]>
 FWIW, The Metacello Config is meant to be Installable
at any future point in time, your installer Doit + the
two other doits may change. For example, if the developers
of OCompletion just put another _non-working_ version
into their repo, your doit will miraculously result in
a non-working OCompletion, while a Metacello-installation
would still work. Or consider a rename of the packages
from Ocompletion to OCompletion.

In general you may be right, that installing software via Metacello is more robust, but in the current situation (Metacello not being an integral part of Squeak) I just feel it is overkill for installing just one package. And after all: I see everything in the "Extending the system" workspace just as a suggestion on how to (quickly) get additional software into the image. You are always free to chose another way like using Metacello configs.
 
The metacello-config
can immediately be updated, while the 'Extending the System'-
Workspace cannot as fast be updated.

I guess that depends on the point of view. Every trunk developer can immediately change and update the workspace if there is a problem. The Metacello config can only be changed by the owners or developers of that repo.
 
My rationale: Why shouldn't we use Metacello Configs if
they are there and doing what we want: Installing the
software.

So why not use jumbo jets to visit your neighbors if they are there and doing what you want: Doing transportation ;)

Alex



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

laza
In reply to this post by Levente Uzonyi-2
Levente,

thanks for the explanation! I guess I have to read a bit more about it to see what this means in practice.

Alex 

2010/12/9 Levente Uzonyi <[hidden email]>
On Thu, 9 Dec 2010, Alexander Lazarević wrote:

You tell me. The benefit I see of just using installer is, that only one
package gets installed. Using a Metacello Config I get all the Metacello
mambo jumbo + Gofer + RoelTyper. I don't know if OCompletion benefits a
great deal by having RoelTyper installed. Maybe someone else could answer
this.

RoelTyper is optional for OCompletion. It's used by ECompletion which is used as a fallback by OCompletion. There's also a preference that allows you to switch to ECompletion from OCompletion. This is possible, because the Ocompletion package includes ECompletion, so when you load OCompletion you have ECompletion too "for free".


Levente


And with installer it loads about eight times faster. So if OCompletion will
not be an integrated part of 4.2, this seems to be a quick way to get it
into such an image.
One could see how complex the OCompletion installtion will be in the future
and switch to a Metacello Config then, no?

Alex

2010/12/8 Tobias Pape <[hidden email]>

Hi,

Am 2010-12-08 um 13:00 schrieb [hidden email]:
Alexander Lazarevi&#263; uploaded a new version of Morphic to project The
Trunk:
http://source.squeak.org/trunk/Morphic-laza.489.mcz

==================== Summary ====================

Name: Morphic-laza.489
Author: laza
Time: 8 December 2010, 2:00:22.014 pm
UUID: 0a444f28-0d28-5f4c-8d31-511261f7a98c
Ancestors: Morphic-laza.488

Provide a recipe for loading OCompletion in the "Extending the system"
workspace

=============== Diff against Morphic-laza.488 ===============



+ "OCompletion provides source code completion as you type"
+ (Installer ss project: ''OCompletion'') install: ''Ocompletion''.
+ (Smalltalk at: #ECToolSet) register.
+ (Smalltalk at: #ToolSet) default: (Smalltalk at: #ECToolSet).
+


Shouldn't we stick to the Metacello Configuration, here?

So Long,
       -Tobias







Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

Tobias Pape
In reply to this post by laza
Hi Alexander

Am 2010-12-10 um 08:51 schrieb Alexander Lazarević:

>
> Hi Tobias!
>
>> 2010/12/9 Tobias Pape <[hidden email]>
>>  FWIW, The Metacello Config is meant to be Installable
>> at any future point in time, your installer Doit + the
>> two other doits may change. For example, if the developers
>> of OCompletion just put another _non-working_ version
>> into their repo, your doit will miraculously result in
>> a non-working OCompletion, while a Metacello-installation
>> would still work. Or consider a rename of the packages
>> from Ocompletion to OCompletion.
>>
> In general you may be right, that installing software via Metacello is more robust, but in the current situation (Metacello not being an integral part of Squeak) I just feel it is overkill for installing just one package. And after all: I see everything in the "Extending the system" workspace just as a suggestion on how to (quickly) get additional software into the image. You are always free to chose another way like using Metacello configs.

Right. Personally, I'd like to see Metacello integrated into Squeak;
if not in a minimal image then in the ‘next bigger iteration’.

>  
>> The metacello-config
>> can immediately be updated, while the 'Extending the System'-
>> Workspace cannot as fast be updated.
>>
> I guess that depends on the point of view. Every trunk developer can immediately change and update the workspace if there is a problem. The Metacello config can only be changed by the owners or developers of that repo.
>  

No, Anybody can update the Metacello-Configuration.
The Metacello-Repository has a 'all read-and-write'-policy.

>> My rationale: Why shouldn't we use Metacello Configs if
>> they are there and doing what we want: Installing the
>> software.
>>
> So why not use jumbo jets to visit your neighbors if they are there and doing what you want: Doing transportation ;)

Point taken.
Probably I said that because I think Installer should cease to be used.

So Long,
        -Tobias
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

Chris Muller-3
In reply to this post by Nicolas Cellier
> As I understand it, with Metacello you can specify something like:
> "take the last stable version known to work in trunk 4.2"

My problem with this concept is that we are beating ourselves with our
own English ambiguity.  What, exactly, does "stable" and "known to
work" mean?  Honestly, the only meaning I take from those phrases is
just, "compatible," (as in, these set of package-versions are
compatible with each other) which is exactly what I already get with a
simple MC Configuration or SAR.

So whether I load a simplistic MC Configuration named, "4.2
Compatible" or a complex Metacello configuration declared as, "last
stable version known to work in trunk 4.2", I'm still likely to go
looking at merging newer versions if I care to; or not if I don't.  In
either case, Metacello didn't save me anything, but it did bring bulk
and complexity to my packaging system.

> It could seem like an advantage.
> But there is no magic, someone has to hardcode some version numbers somewhere.

Right, but even Berts original MC Configurations UI takes the tedium
out of that.  It's basically one-click..

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Morphic-laza.489.mcz

Ken G. Brown
In reply to this post by Tobias Pape
At 9:44 AM +0100 12/10/10, Tobias Pape apparently wrote:

>Hi Alexander
>
>Am 2010-12-10 um 08:51 schrieb Alexander Lazareviç:
>>
>> Hi Tobias!
>>
> >> 2010/12/9 Tobias Pape <[hidden email]>
>>>  FWIW, The Metacello Config is meant to be Installable
>>> at any future point in time, your installer Doit + the
>>> two other doits may change. For example, if the developers
>>> of OCompletion just put another _non-working_ version
>>> into their repo, your doit will miraculously result in
>>> a non-working OCompletion, while a Metacello-installation
> >> would still work. Or consider a rename of the packages
>>> from Ocompletion to OCompletion.
>>>
>> In general you may be right, that installing software via Metacello is more robust, but in the current situation (Metacello not being an integral part of Squeak) I just feel it is overkill for installing just one package. And after all: I see everything in the "Extending the system" workspace just as a suggestion on how to (quickly) get additional software into the image. You are always free to chose another way like using Metacello configs.
>
>Right. Personally, I'd like to see Metacello integrated into Squeak;
>if not in a minimal image then in the 'next bigger iteration'.
>
>>
>>> The metacello-config
>>> can immediately be updated, while the 'Extending the System'-
>>> Workspace cannot as fast be updated.
>>>
>> I guess that depends on the point of view. Every trunk developer can immediately change and update the workspace if there is a problem. The Metacello config can only be changed by the owners or developers of that repo.
>>
>
>No, Anybody can update the Metacello-Configuration.
>The Metacello-Repository has a 'all read-and-write'-policy.
>
>>> My rationale: Why shouldn't we use Metacello Configs if
>>> they are there and doing what we want: Installing the
>>> software.
>>>
>> So why not use jumbo jets to visit your neighbors if they are there and doing what you want: Doing transportation ;)
>
>Point taken.
>Probably I said that because I think Installer should cease to be used.

I for one do not want to see Installer disappear.
Can anyone explain to me what advantage GoFer has over Installer?
Seem to me they are doing more or less the same thing.

Ken G. Brown

>
>So Long,
> -Tobias


bpi
Reply | Threaded
Open this post in threaded view
|

Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

bpi
Hi Ken,

If you ask... ;-)

Am 13.12.2010 um 18:21 schrieb Ken G. Brown:
> I for one do not want to see Installer disappear.
> Can anyone explain to me what advantage GoFer has over Installer?
> Seem to me they are doing more or less the same thing.
I like Gofer better than Installer for the following reasons:
- Gofer has an active maintainer, the original author still maintains it.
- Lukas writes top quality Smalltalk code IMO. I find the code cleaner. (That, of course, may just be my personal preference.)
- Gofer is much smaller than Installer - 640 lines of code versus 1703 - thus the image would be smaller if we replaced Installer with Gofer.
- At the same time Gofer has more functionality which I find quite useful, committing, fetching and pushing. See http://www.lukas-renggli.ch/blog/gofer for a short description.
- Installer has a lot of code which is rarely used.
- Installation code for packages which are compatible between Squeak and Pharo could be the same in many cases, which I find less confusing.
- This brings Squeak and Pharo closer together again, which would be a good thing IMO.

Enough reasons in my opinion. Of course, reasonable people might disagree. ;-)

Cheers,
Bernhard
Reply | Threaded
Open this post in threaded view
|

Re: Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

Edgar De Cleene



On 12/13/10 6:23 PM, "Bernhard Pieber" <[hidden email]> wrote:

> Hi Ken,
>
> If you ask... ;-)
>
> Am 13.12.2010 um 18:21 schrieb Ken G. Brown:
>> I for one do not want to see Installer disappear.
>> Can anyone explain to me what advantage GoFer has over Installer?
>> Seem to me they are doing more or less the same thing.
> I like Gofer better than Installer for the following reasons:
> - Gofer has an active maintainer, the original author still maintains it.
> - Lukas writes top quality Smalltalk code IMO. I find the code cleaner. (That,
> of course, may just be my personal preference.)
> - Gofer is much smaller than Installer - 640 lines of code versus 1703 - thus
> the image would be smaller if we replaced Installer with Gofer.
> - At the same time Gofer has more functionality which I find quite useful,
> committing, fetching and pushing. See http://www.lukas-renggli.ch/blog/gofer
> for a short description.
> - Installer has a lot of code which is rarely used.
> - Installation code for packages which are compatible between Squeak and Pharo
> could be the same in many cases, which I find less confusing.
> - This brings Squeak and Pharo closer together again, which would be a good
> thing IMO.
>
> Enough reasons in my opinion. Of course, reasonable people might disagree. ;-)
>
> Cheers,
> Bernhard


We should upload all Installer, SqueakMap, ScriptLoader, ReleaseBuilder,
etc.
Monticello is enough if good practice was adopted.

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

Ken G. Brown
In reply to this post by bpi
At 9:23 PM +0100 12/13/10, Bernhard Pieber apparently wrote:

>Hi Ken,
>
>If you ask... ;-)
>
>Am 13.12.2010 um 18:21 schrieb Ken G. Brown:
>> I for one do not want to see Installer disappear.
>> Can anyone explain to me what advantage GoFer has over Installer?
>> Seem to me they are doing more or less the same thing.
>I like Gofer better than Installer for the following reasons:
>- Gofer has an active maintainer, the original author still maintains it.
>- Lukas writes top quality Smalltalk code IMO. I find the code cleaner. (That, of course, may just be my personal preference.)
>- Gofer is much smaller than Installer - 640 lines of code versus 1703 - thus the image would be smaller if we replaced Installer with Gofer.
>- At the same time Gofer has more functionality which I find quite useful, committing, fetching and pushing. See http://www.lukas-renggli.ch/blog/gofer for a short description.
>- Installer has a lot of code which is rarely used.

Installer docs <http://installer.pbworks.com/w/page/19997682/Installer>

Thx for your response.

I agree, bringing Pharo and Squeak closer together could be a good thing.

Ken


>- Installation code for packages which are compatible between Squeak and Pharo could be the same in many cases, which I find less confusing.
>- This brings Squeak and Pharo closer together again, which would be a good thing IMO.
>
>Enough reasons in my opinion. Of course, reasonable people might disagree. ;-)
>
>Cheers,
>Bernhard


Reply | Threaded
Open this post in threaded view
|

Re: Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

Chris Muller-3
In reply to this post by bpi
Does Gofer support all legacy formats?  ChangeSets, SqueakMap,
Universes, Monticello, Monticello Configurations?

I have nothing against aesthetics and compactness, but functionality
is a important criteria to me than lines of code.  I want an installer
utility to just work for me, not be a work of art to admire.  :-)

If Gofer only supports a subset of the Installer types, maybe
Installer could be stripped of its functions that overlap with Gofer
and employ Gofer for those parts.  That way, "Installer" can also
support Gofer scripts..?

 - Chris



On Mon, Dec 13, 2010 at 2:23 PM, Bernhard Pieber <[hidden email]> wrote:

> Hi Ken,
>
> If you ask... ;-)
>
> Am 13.12.2010 um 18:21 schrieb Ken G. Brown:
>> I for one do not want to see Installer disappear.
>> Can anyone explain to me what advantage GoFer has over Installer?
>> Seem to me they are doing more or less the same thing.
> I like Gofer better than Installer for the following reasons:
> - Gofer has an active maintainer, the original author still maintains it.
> - Lukas writes top quality Smalltalk code IMO. I find the code cleaner. (That, of course, may just be my personal preference.)
> - Gofer is much smaller than Installer - 640 lines of code versus 1703 - thus the image would be smaller if we replaced Installer with Gofer.
> - At the same time Gofer has more functionality which I find quite useful, committing, fetching and pushing. See http://www.lukas-renggli.ch/blog/gofer for a short description.
> - Installer has a lot of code which is rarely used.
> - Installation code for packages which are compatible between Squeak and Pharo could be the same in many cases, which I find less confusing.
> - This brings Squeak and Pharo closer together again, which would be a good thing IMO.
>
> Enough reasons in my opinion. Of course, reasonable people might disagree. ;-)
>
> Cheers,
> Bernhard
>

Reply | Threaded
Open this post in threaded view
|

Re: Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

Igor Stasenko
+1

Gofer has 'more', as well as it has 'less' comparing to installer.
With Installer i can easily point to a .cs file for file-in.
Can i do same thing with Gofer?

For example, this is what i using for ensuring some fixes are
incorporated into image

installPrerequisites: installer
       
        (CompiledMethodTrailer trailerKinds includes: #NativeCodeTrailer) ifFalse: [
                installer installUrl:
'http://nativeboost.googlecode.com/files/000-NativeCodeTrailers.cs' ].

        "Make sure an image having this crucial fix "
        (Object>>#perform:withArguments: ) frameSize > CompiledMethod smallFrameSize
        ifFalse: [
                installer installUrl:
'http://nativeboost.googlecode.com/files/001-perform-framesize.cs'.
        ].

of course, i could create a separate package, which includes all this stuff.
But sometimes nothing is better than good old changeset :)

On 14 December 2010 20:13, Chris Muller <[hidden email]> wrote:

> Does Gofer support all legacy formats?  ChangeSets, SqueakMap,
> Universes, Monticello, Monticello Configurations?
>
> I have nothing against aesthetics and compactness, but functionality
> is a important criteria to me than lines of code.  I want an installer
> utility to just work for me, not be a work of art to admire.  :-)
>
> If Gofer only supports a subset of the Installer types, maybe
> Installer could be stripped of its functions that overlap with Gofer
> and employ Gofer for those parts.  That way, "Installer" can also
> support Gofer scripts..?
>
>  - Chris
>
>
>
> On Mon, Dec 13, 2010 at 2:23 PM, Bernhard Pieber <[hidden email]> wrote:
>> Hi Ken,
>>
>> If you ask... ;-)
>>
>> Am 13.12.2010 um 18:21 schrieb Ken G. Brown:
>>> I for one do not want to see Installer disappear.
>>> Can anyone explain to me what advantage GoFer has over Installer?
>>> Seem to me they are doing more or less the same thing.
>> I like Gofer better than Installer for the following reasons:
>> - Gofer has an active maintainer, the original author still maintains it.
>> - Lukas writes top quality Smalltalk code IMO. I find the code cleaner. (That, of course, may just be my personal preference.)
>> - Gofer is much smaller than Installer - 640 lines of code versus 1703 - thus the image would be smaller if we replaced Installer with Gofer.
>> - At the same time Gofer has more functionality which I find quite useful, committing, fetching and pushing. See http://www.lukas-renggli.ch/blog/gofer for a short description.
>> - Installer has a lot of code which is rarely used.
>> - Installation code for packages which are compatible between Squeak and Pharo could be the same in many cases, which I find less confusing.
>> - This brings Squeak and Pharo closer together again, which would be a good thing IMO.
>>
>> Enough reasons in my opinion. Of course, reasonable people might disagree. ;-)
>>
>> Cheers,
>> Bernhard
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

Ramon Leon-5
On 12/14/2010 12:23 PM, Igor Stasenko wrote:
> Can i do same thing with Gofer?

Gofer is all about Monticello packages, different design goal than
installer, just the read doc...

http://www.lukas-renggli.ch/blog/gofer

--
Ramon Leon

Reply | Threaded
Open this post in threaded view
|

Re: Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

Igor Stasenko
On 14 December 2010 20:36, Ramon Leon <[hidden email]> wrote:
> On 12/14/2010 12:23 PM, Igor Stasenko wrote:
>>
>> Can i do same thing with Gofer?
>
> Gofer is all about Monticello packages, different design goal than
> installer, just the read doc...
>
it was a rhetoric question :)

> http://www.lukas-renggli.ch/blog/gofer
>
> --
> Ramon Leon
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Gofer versus Installer was: The Trunk: Morphic-laza.489.mcz

Ramon Leon-5
On 12/14/2010 12:41 PM, Igor Stasenko wrote:
> On 14 December 2010 20:36, Ramon Leon<[hidden email]>  wrote:
>> On 12/14/2010 12:23 PM, Igor Stasenko wrote:
>>>
>>> Can i do same thing with Gofer?
>>
>> Gofer is all about Monticello packages, different design goal than
>> installer, just the read doc...
>>
> it was a rhetoric question :)

:)

12