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! |
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 |
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-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 |
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ć 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 >> > |
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 > > > |
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 >> >> >> > > |
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 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 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 So why not use jumbo jets to visit your neighbors if they are there and doing what you want: Doing transportation ;) Alex |
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]>
|
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 |
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.. |
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 |
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 |
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 |
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 |
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 > |
+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. |
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 |
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. |
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 :) :) |
Free forum by Nabble | Edit this page |