[Pharo-project] Newbie observations on use of Metacello
Some observations from the perspective of as a newbie on Pharo Package Management. I'm likely to me missing in the philosophy of the design, but from the narrow view of my own usage.... 1. When I read about Metacello being the package management system, I expected there to be a "command"(*) Metacallo but instead I see Gopher being used. This is a mixed message that lowers my comfort level feeling I understand the system as I'm trying to pick up a bundle of new ideas. As I now understand it Metacello is more about a system of backend configuration than a front end user interface. I am now more comfortable using Gopher direct - but I reflect on how I felt the first time. (*) While technically a "command" is like a verb, and Gopher is like a noun rather than a verb - I can't yet completely disengage my prior learning that considers the first part of the statement to be a "command" - and I expect other newbies might find the same. 2. The strong convention of naming things ConfigurationOfXXXX is somewhat redundant from a user perspective. 3. If copy-paste into the Workspace from a web site a sample package load (for example b> below) and then highlight the whole thing and execute, it tells me "Unknown variable: ConfigurationOfSqueakDBX, please correct, or cancel" Duh! What? Oh, I need to execute it in two parts. No one wrote that down anywhere.... The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds further complexity in the eyes of a newbie. Based on the above points, it would be nice to have... a> Metacello configuration: 'SqueakDBX' load rather than... b> Gofer new b> squeaksource: 'MetacelloRepository'; b> package: 'ConfigurationOfSqueakDBX'; b> load. b> ConfigurationOfSqueakDBX project latestVersion load. While only a small saving in typing, I think it significant for newbies in terms of polish and the marketing message that Metacello really is the chosen package management system. A very rough implementation (with much of the syntax likely wrong) might be just... c> Metacello class >> package: aPackage c> | packageConfig | c> packageConfig := 'ConfigurationOf', aPackage; c> Gopher new c> squeaksource: 'MetacelloRepository'; c> package: packageConfig c> load c> ^((Smalltalk at: (packageConfig asSymbol)) Now after I've written the above I contemplate that there must have been an early design decision to not implement a separate Metacello class to avoid duplication/overlap with Monticello. However perhaps now that the system is implemented as it is, a thin shim can be put over the top to assist getting the ConfigurationOfXXX files downloaded. Additional things this Metacello class might later provide: a. Improved reliability by downloading from a system of package repository mirrors. SqueakSource was having some issues and I found [1] a fortunate backup. b. A GUI for browsing package versions c. A GUI for browsing compatibility tables from a continuous integration system that tries different permutations of Montecello packages together. 4. It seems that every ConfigurationOfXXX has its own category in the SystemBrowser. Each of these categories has only one class. This seems to me like unneeded clutter of the System Browser. It would be neater if Metacello specified its configurations to be grouped under a single category "MetacelloConfigurations" or similar. 5. The sample Metacello PBE is very good in the detail for developers to provide configurations. However there is not much directed clearly at a 'mere' user. Even though Smalltalk makes us all developers, newbies all start as mere users while exploring the system. [1] Gofer new url: 'http://dsal.cl/squeaksource/MonticelloRedirect'; package: 'MontiRedirect'; load. MRManager redirectFrom: 'http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'. Cheers, Ben
ben thanks for your feedback. Normally we should use the monticello repository browser and just click on a ConfigurationOf than did you read the forthcoming chapter? https://gforge.inria.fr/frs/download.php/28462/Metacello.pdf (old version) Stef On Dec 19, 2011, at 5:15 AM, Ben Coman wrote:
Some observations from the perspective of as a newbie on Pharo Package Management. I'm likely to me missing in the philosophy of the design, but from the narrow view of my own usage....
1. When I read about Metacello being the package management system, I expected there to be a "command"(*) Metacallo but instead I see Gopher being used. This is a mixed message that lowers my comfort level feeling I understand the system as I'm trying to pick up a bundle of new ideas. As I now understand it Metacello is more about a system of backend configuration than a front end user interface. I am now more comfortable using Gopher direct - but I reflect on how I felt the first time.
(*) While technically a "command" is like a verb, and Gopher is like a noun rather than a verb - I can't yet completely disengage my prior learning that considers the first part of the statement to be a "command" - and I expect other newbies might find the same.
2. The strong convention of naming things ConfigurationOfXXXX is somewhat redundant from a user perspective.
3. If copy-paste into the Workspace from a web site a sample package load (for example b> below) and then highlight the whole thing and execute, it tells me "Unknown variable: ConfigurationOfSqueakDBX, please correct, or cancel" Duh! What? Oh, I need to execute it in two parts. No one wrote that down anywhere.... The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds further complexity in the eyes of a newbie.
Based on the above points, it would be nice to have...
a> Metacello configuration: 'SqueakDBX' load
rather than...
b> Gofer new b> squeaksource: 'MetacelloRepository'; b> package: 'ConfigurationOfSqueakDBX'; b> load. b> ConfigurationOfSqueakDBX project latestVersion load.
While only a small saving in typing, I think it significant for newbies in terms of polish and the marketing message that Metacello really is the chosen package management system. A very rough implementation (with much of the syntax likely wrong) might be just...
c> Metacello class >> package: aPackage c> | packageConfig | c> packageConfig := 'ConfigurationOf', aPackage; c> Gopher new c> squeaksource: 'MetacelloRepository'; c> package: packageConfig c> load c> ^((Smalltalk at: (packageConfig asSymbol))
Now after I've written the above I contemplate that there must have been an early design decision to not implement a separate Metacello class to avoid duplication/overlap with Monticello. However perhaps now that the system is implemented as it is, a thin shim can be put over the top to assist getting the ConfigurationOfXXX files downloaded. Additional things this Metacello class might later provide: a. Improved reliability by downloading from a system of package repository mirrors. SqueakSource was having some issues and I found [1] a fortunate backup. b. A GUI for browsing package versions c. A GUI for browsing compatibility tables from a continuous integration system that tries different permutations of Montecello packages together.
4. It seems that every ConfigurationOfXXX has its own category in the SystemBrowser. Each of these categories has only one class. This seems to me like unneeded clutter of the System Browser. It would be neater if Metacello specified its configurations to be grouped under a single category "MetacelloConfigurations" or similar.
5. The sample Metacello PBE is very good in the detail for developers to provide configurations. However there is not much directed clearly at a 'mere' user. Even though Smalltalk makes us all developers, newbies all start as mere users while exploring the system. [1] Gofer new url: 'http://dsal.cl/squeaksource/MonticelloRedirect'; package: 'MontiRedirect'; load. MRManager redirectFrom: 'http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'.
Cheers, Ben
Hi, ages ago I did an extension for gofer, the "Gofer project loader", who does what Ben is asking for: Gofer project load: 'Seaside30'. it was incomplete, but working. I stopped working on this because no one (except Dale) showed interest on it, so I prefer to assign my time to things more useful for community (hehe, this sounds as a complain, but it is not: just a description of why I stopped working on that :) cheers, Esteban El 19/12/2011, a las 5:43a.m., Stéphane Ducasse escribió:
ben thanks for your feedback.
Normally we should use the monticello repository browser and just click on a ConfigurationOf
than did you read the forthcoming chapter? https://gforge.inria.fr/frs/download.php/28462/Metacello.pdf (old version)
Stef
On Dec 19, 2011, at 5:15 AM, Ben Coman wrote:
Some observations from the perspective of as a newbie on Pharo Package Management. I'm likely to me missing in the philosophy of the design, but from the narrow view of my own usage....
1. When I read about Metacello being the package management system, I expected there to be a "command"(*) Metacallo but instead I see Gopher being used. This is a mixed message that lowers my comfort level feeling I understand the system as I'm trying to pick up a bundle of new ideas. As I now understand it Metacello is more about a system of backend configuration than a front end user interface. I am now more comfortable using Gopher direct - but I reflect on how I felt the first time.
(*) While technically a "command" is like a verb, and Gopher is like a noun rather than a verb - I can't yet completely disengage my prior learning that considers the first part of the statement to be a "command" - and I expect other newbies might find the same.
2. The strong convention of naming things ConfigurationOfXXXX is somewhat redundant from a user perspective.
3. If copy-paste into the Workspace from a web site a sample package load (for example b> below) and then highlight the whole thing and execute, it tells me "Unknown variable: ConfigurationOfSqueakDBX, please correct, or cancel" Duh! What? Oh, I need to execute it in two parts. No one wrote that down anywhere.... The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds further complexity in the eyes of a newbie.
Based on the above points, it would be nice to have...
a> Metacello configuration: 'SqueakDBX' load
rather than...
b> Gofer new b> squeaksource: 'MetacelloRepository'; b> package: 'ConfigurationOfSqueakDBX'; b> load. b> ConfigurationOfSqueakDBX project latestVersion load.
While only a small saving in typing, I think it significant for newbies in terms of polish and the marketing message that Metacello really is the chosen package management system. A very rough implementation (with much of the syntax likely wrong) might be just...
c> Metacello class >> package: aPackage c> | packageConfig | c> packageConfig := 'ConfigurationOf', aPackage; c> Gopher new c> squeaksource: 'MetacelloRepository'; c> package: packageConfig c> load c> ^((Smalltalk at: (packageConfig asSymbol))
Now after I've written the above I contemplate that there must have been an early design decision to not implement a separate Metacello class to avoid duplication/overlap with Monticello. However perhaps now that the system is implemented as it is, a thin shim can be put over the top to assist getting the ConfigurationOfXXX files downloaded. Additional things this Metacello class might later provide: a. Improved reliability by downloading from a system of package repository mirrors. SqueakSource was having some issues and I found [1] a fortunate backup. b. A GUI for browsing package versions c. A GUI for browsing compatibility tables from a continuous integration system that tries different permutations of Montecello packages together.
4. It seems that every ConfigurationOfXXX has its own category in the SystemBrowser. Each of these categories has only one class. This seems to me like unneeded clutter of the System Browser. It would be neater if Metacello specified its configurations to be grouped under a single category "MetacelloConfigurations" or similar.
5. The sample Metacello PBE is very good in the detail for developers to provide configurations. However there is not much directed clearly at a 'mere' user. Even though Smalltalk makes us all developers, newbies all start as mere users while exploring the system. [1] Gofer new url: 'http://dsal.cl/squeaksource/MonticelloRedirect'; package: 'MontiRedirect'; load. MRManager redirectFrom: 'http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'.
Cheers, Ben
+1 Dale ----- Original Message ----- | From: "Esteban Lorenzano" <estebanlm@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Monday, December 19, 2011 3:42:38 AM | Subject: Re: [Pharo-project] Newbie observations on use of Metacello | | Hi, | | ages ago I did an extension for gofer, the "Gofer project loader", | who does what Ben is asking for: | | Gofer project load: 'Seaside30'. | | it was incomplete, but working. I stopped working on this because no | one (except Dale) showed interest on it, so I prefer to assign my | time to things more useful for community (hehe, this sounds as a | complain, but it is not: just a description of why I stopped working | on that :) | | cheers, | Esteban | | El 19/12/2011, a las 5:43a.m., Stéphane Ducasse escribió: | | > ben thanks for your feedback. | > | > Normally we should use the monticello repository browser and just | > click on a ConfigurationOf | > | > than did you read the forthcoming chapter? | > https://gforge.inria.fr/frs/download.php/28462/Metacello.pdf (old | > version) | > | > Stef | > | > | > | > On Dec 19, 2011, at 5:15 AM, Ben Coman wrote: | > | >> Some observations from the perspective of as a newbie on Pharo | >> Package Management. I'm likely to me missing in the philosophy | >> of the design, but from the narrow view of my own usage.... | >> | >> 1. When I read about Metacello being the package management | >> system, I expected there to be a "command"(*) Metacallo but | >> instead I see Gopher being used. This is a mixed message that | >> lowers my comfort level feeling I understand the system as I'm | >> trying to pick up a bundle of new ideas. As I now understand it | >> Metacello is more about a system of backend configuration than a | >> front end user interface. I am now more comfortable using Gopher | >> direct - but I reflect on how I felt the first time. | >> | >> (*) While technically a "command" is like a verb, and Gopher is | >> like a noun rather than a verb - I can't yet completely disengage | >> my prior learning that considers the first part of the statement | >> to be a "command" - and I expect other newbies might find the | >> same. | >> | >> 2. The strong convention of naming things ConfigurationOfXXXX is | >> somewhat redundant from a user perspective. | >> | >> 3. If copy-paste into the Workspace from a web site a sample | >> package load (for example b> below) and then highlight the whole | >> thing and execute, it tells me | >> "Unknown variable: ConfigurationOfSqueakDBX, please correct, or | >> cancel" Duh! What? Oh, I need to execute it in two parts. No | >> one wrote that down anywhere.... | >> The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds | >> further complexity in the eyes of a newbie. | >> | >> Based on the above points, it would be nice to have... | >> | >> a> Metacello configuration: 'SqueakDBX' load | >> | >> rather than... | >> | >> b> Gofer new | >> b> squeaksource: 'MetacelloRepository'; | >> b> package: 'ConfigurationOfSqueakDBX'; | >> b> load. | >> b> ConfigurationOfSqueakDBX project latestVersion load. | >> | >> While only a small saving in typing, I think it significant for | >> newbies in terms of polish and the marketing message that | >> Metacello really is the chosen package management system. | >> A very rough implementation (with much of the syntax likely wrong) | >> might be just... | >> | >> c> Metacello class >> package: aPackage | >> c> | packageConfig | | >> c> packageConfig := 'ConfigurationOf', aPackage; | >> c> Gopher new c> squeaksource: | >> 'MetacelloRepository'; | >> c> package: packageConfig | >> c> load | >> c> ^((Smalltalk at: (packageConfig asSymbol)) | >> | >> | >> Now after I've written the above I contemplate that there must | >> have been an early design decision to not implement a separate | >> Metacello class to avoid duplication/overlap with Monticello. | >> However perhaps now that the system is implemented as it is, a | >> thin shim can be put over the top to assist getting the | >> ConfigurationOfXXX files downloaded. Additional things this | >> Metacello class might later provide: a. Improved reliability by | >> downloading from a system of package repository mirrors. | >> SqueakSource was having some issues and I found [1] a fortunate | >> backup. b. A GUI for browsing package versions | >> c. A GUI for browsing compatibility tables from a continuous | >> integration system that tries different permutations of | >> Montecello packages together. | >> | >> | >> 4. It seems that every ConfigurationOfXXX has its own category in | >> the SystemBrowser. Each of these categories has only one class. | >> This seems to me like unneeded clutter of the System Browser. | >> It would be neater if Metacello specified its configurations to | >> be grouped under a single category "MetacelloConfigurations" or | >> similar. | >> | >> 5. The sample Metacello PBE is very good in the detail for | >> developers to provide configurations. However there is not much | >> directed clearly at a 'mere' user. Even though Smalltalk makes | >> us all developers, newbies all start as mere users while | >> exploring the system. | >> [1] Gofer new url: | >> 'http://dsal.cl/squeaksource/MonticelloRedirect'; package: | >> 'MontiRedirect'; load. MRManager redirectFrom: | >> 'http://www.squeaksource.com/' to: | >> 'http://dsal.cl/squeaksource/'. | >> | >> Cheers, Ben | >> | > | > | | |
Stéphane Ducasse wrote: > ben thanks for your feedback. > > Normally we should use the monticello repository browser and just click on a ConfigurationOf > I've been lurking this mail list for 6 - 9 months and had not picked that up. That is a big miss. I'm not usually so slow. Can you point me to the documentation that describes that process? In the meantime, I unzip a fresh Pharo-1.3-OneClick, open Monticello Browser and look for ConfigurationOfSqueakDBX. I can't see it. I expected to since you seemed to indicate it was that simple. So I GUESS* my way through. I <Open> the http://www.squeaksource.com/MetacelloRepository repository (which actually requires a bit of fore knowledge about the url - which not all newbies will have) This did show ConfigurationOfSqueakDBX but the are many versions and so many buttons to choose from. A bit scary for a newbie. Anyhow, I'll ASSUME* to select the latest one ConfigurationOfSqueakDBX-MarianoMartinezPeck.27 and click <Load>. I still can't see any SqueakDBX or OpenDBX classes in System Browser. Do I need to follow up manually doing "ConfigurationOfSqueakDBX project latestVersion load." ? A mixed procedure part GUI and part non-GUI is not the best - and I've not seen it documented anywhere. I would have liked to have loaded the package with "just a single click on a ConfigurationOf" but there seems to be more to it than that. The following still seems easier: > Metacello package: 'SqueakDBX' load or perhaps some alternatives using existing tools... 1. To the Monticello Browser add a <Metacello> button that opens http://www.squeaksource.com/MetacelloRepository. If Metacello is "THE" package management tool then it should have a higher profile than just one of the 23 listed repositories, of which two others have "Metacello" in their title. 2. To the World Menu, add a <Metacello Browser> item that jumps straight to the Monticello Repository Browser for http://www.squeaksource.com/MetacelloRepository. 3. The Welcome Text of a fresh pharo-oneclick image should describe how to do either 1. or 2. above. cheers, Ben > than did you read the forthcoming chapter? > https://gforge.inria.fr/frs/download.php/28462/Metacello.pdf (old version) > > Yes I refer to it in point 4 below. Can you point me to where in that pdf it specifically describes that loading procedure using Monticello Browser. All the examples I can see are code b> below, except using (Smalltalk at:.....) rather than the class itself. Further, the Pharo-1.3-OneClick opening documentation says to execute the following line... > DEVImageWorkspaces openExternalProjectWorkspace. which shows several examples all of the same form as the code b> below. Also, from memory the examples given throughout this mail list tend to be of the same form as code b> below - rather than directing people to the GUI Monticello Browser - or I probably would have picked that up sooner. > Stef > > > > On Dec 19, 2011, at 5:15 AM, Ben Coman wrote: > > >> Some observations from the perspective of as a newbie on Pharo Package Management. I'm likely to me missing in the philosophy of the design, but from the narrow view of my own usage.... >> >> 1. When I read about Metacello being the package management system, I expected there to be a "command"(*) Metacallo but instead I see Gopher being used. This is a mixed message that lowers my comfort level feeling I understand the system as I'm trying to pick up a bundle of new ideas. As I now understand it Metacello is more about a system of backend configuration than a front end user interface. I am now more comfortable using Gopher direct - but I reflect on how I felt the first time. >> >> (*) While technically a "command" is like a verb, and Gopher is like a noun rather than a verb - I can't yet completely disengage my prior learning that considers the first part of the statement to be a "command" - and I expect other newbies might find the same. >> >> 2. The strong convention of naming things ConfigurationOfXXXX is somewhat redundant from a user perspective. >> >> 3. If copy-paste into the Workspace from a web site a sample package load (for example b> below) and then highlight the whole thing and execute, it tells me >> "Unknown variable: ConfigurationOfSqueakDBX, please correct, or cancel" Duh! What? Oh, I need to execute it in two parts. No one wrote that down anywhere.... >> The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds further complexity in the eyes of a newbie. >> >> Based on the above points, it would be nice to have... >> >> a> Metacello configuration: 'SqueakDBX' load >> >> rather than... >> >> b> Gofer new >> b> squeaksource: 'MetacelloRepository'; >> b> package: 'ConfigurationOfSqueakDBX'; >> b> load. >> b> ConfigurationOfSqueakDBX project latestVersion load. >> >> While only a small saving in typing, I think it significant for newbies in terms of polish and the marketing message that Metacello really is the chosen package management system. >> A very rough implementation (with much of the syntax likely wrong) might be just... >> >> c> Metacello class >> package: aPackage >> c> | packageConfig | >> c> packageConfig := 'ConfigurationOf', aPackage; >> c> Gopher new c> squeaksource: 'MetacelloRepository'; >> c> package: packageConfig >> c> load >> c> ^((Smalltalk at: (packageConfig asSymbol)) >> >> >> Now after I've written the above I contemplate that there must have been an early design decision to not implement a separate Metacello class to avoid duplication/overlap with Monticello. However perhaps now that the system is implemented as it is, a thin shim can be put over the top to assist getting the ConfigurationOfXXX files downloaded. Additional things this Metacello class might later provide: a. Improved reliability by downloading from a system of package repository mirrors. SqueakSource was having some issues and I found [1] a fortunate backup. b. A GUI for browsing package versions >> c. A GUI for browsing compatibility tables from a continuous integration system that tries different permutations of Montecello packages together. >> >> >> 4. It seems that every ConfigurationOfXXX has its own category in the SystemBrowser. Each of these categories has only one class. This seems to me like unneeded clutter of the System Browser. It would be neater if Metacello specified its configurations to be grouped under a single category "MetacelloConfigurations" or similar. >> >> 5. The sample Metacello PBE is very good in the detail for developers to provide configurations. However there is not much directed clearly at a 'mere' user. Even though Smalltalk makes us all developers, newbies all start as mere users while exploring the system. >> [1] Gofer new url: 'http://dsal.cl/squeaksource/MonticelloRedirect'; package: 'MontiRedirect'; load. MRManager redirectFrom: 'http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'. >> >> Cheers, Ben >> >> > > > >
On 19 Dec 2011, at 17:04, Ben Coman wrote:
I've been lurking this mail list for 6 - 9 months and had not picked that up. That is a big miss. I'm not usually so slow. Can you point me to the documentation that describes that process?
I agree, the UX is not (yet) perfect; so your comments are valid. Metacello was written with many different design goals: one of them is that it solve the 'chicken/egg' problem by allowing configurations to be loadable in images that do not yet contain anything related to Metacello ! That is why you always see this boilerplate with Gofer and the Smalltalk at: #ConfigurationOf.. Sven
On Dec 19, 2011, at 5:04 PM, Ben Coman wrote: > Stéphane Ducasse wrote: >> ben thanks for your feedback. >> >> Normally we should use the monticello repository browser and just click on a ConfigurationOf >> > I've been lurking this mail list for 6 - 9 months and had not picked that up. That is a big miss. I'm not usually so slow. Can you point me to the documentation that describes that process? The problem is that we did not push it to the point the repository for 1.0, contains only 1.0 configuration. We will check that when esteban will arrive. > > In the meantime, I unzip a fresh Pharo-1.3-OneClick, open Monticello Browser and look for ConfigurationOfSqueakDBX. I can't see it. I expected to since you seemed to indicate it was that simple. > > So I GUESS* my way through. I <Open> the http://www.squeaksource.com/MetacelloRepository repository > (which actually requires a bit of fore knowledge about the url - which not all newbies will have) > This did show ConfigurationOfSqueakDBX but the are many versions and so many buttons to choose from. A bit scary for a newbie. > Anyhow, I'll ASSUME* to select the latest one ConfigurationOfSqueakDBX-MarianoMartinezPeck.27 and click <Load>. > > I still can't see any SqueakDBX or OpenDBX classes in System Browser. > Do I need to follow up manually doing "ConfigurationOfSqueakDBX project latestVersion load." ? > A mixed procedure part GUI and part non-GUI is not the best - and I've not seen it documented anywhere. > > I would have liked to have loaded the package with "just a single click on a ConfigurationOf" but there seems to be more to it than that. > > The following still seems easier: > > Metacello package: 'SqueakDBX' load > or perhaps some alternatives using existing tools... > 1. To the Monticello Browser add a <Metacello> button that opens http://www.squeaksource.com/MetacelloRepository. If Metacello is "THE" package management tool then it should have a higher profile than just one of the 23 listed repositories, of which two others have "Metacello" in their title. > 2. To the World Menu, add a <Metacello Browser> item that jumps straight to the Monticello Repository Browser for http://www.squeaksource.com/MetacelloRepository. > 3. The Welcome Text of a fresh pharo-oneclick image should describe how to do either 1. or 2. above. > > cheers, Ben >> than did you read the forthcoming chapter? >> https://gforge.inria.fr/frs/download.php/28462/Metacello.pdf (old version) >> >> > Yes I refer to it in point 4 below. Can you point me to where in that pdf it specifically describes that loading procedure using Monticello Browser. All the examples I can see are code b> below, except using (Smalltalk at:.....) rather than the class itself. > > Further, the Pharo-1.3-OneClick opening documentation says to execute the following line... > > DEVImageWorkspaces openExternalProjectWorkspace. > which shows several examples all of the same form as the code b> below. > > Also, from memory the examples given throughout this mail list tend to be of the same form as code b> below - rather than directing people to the GUI Monticello Browser - or I probably would have picked that up sooner. > >> Stef >> >> >> >> On Dec 19, 2011, at 5:15 AM, Ben Coman wrote: >> >> >>> Some observations from the perspective of as a newbie on Pharo Package Management. I'm likely to me missing in the philosophy of the design, but from the narrow view of my own usage.... >>> >>> 1. When I read about Metacello being the package management system, I expected there to be a "command"(*) Metacallo but instead I see Gopher being used. This is a mixed message that lowers my comfort level feeling I understand the system as I'm trying to pick up a bundle of new ideas. As I now understand it Metacello is more about a system of backend configuration than a front end user interface. I am now more comfortable using Gopher direct - but I reflect on how I felt the first time. >>> >>> (*) While technically a "command" is like a verb, and Gopher is like a noun rather than a verb - I can't yet completely disengage my prior learning that considers the first part of the statement to be a "command" - and I expect other newbies might find the same. >>> >>> 2. The strong convention of naming things ConfigurationOfXXXX is somewhat redundant from a user perspective. >>> >>> 3. If copy-paste into the Workspace from a web site a sample package load (for example b> below) and then highlight the whole thing and execute, it tells me >>> "Unknown variable: ConfigurationOfSqueakDBX, please correct, or cancel" Duh! What? Oh, I need to execute it in two parts. No one wrote that down anywhere.... >>> The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds further complexity in the eyes of a newbie. >>> >>> Based on the above points, it would be nice to have... >>> >>> a> Metacello configuration: 'SqueakDBX' load >>> >>> rather than... >>> >>> b> Gofer new >>> b> squeaksource: 'MetacelloRepository'; >>> b> package: 'ConfigurationOfSqueakDBX'; >>> b> load. >>> b> ConfigurationOfSqueakDBX project latestVersion load. >>> While only a small saving in typing, I think it significant for newbies in terms of polish and the marketing message that Metacello really is the chosen package management system. >>> A very rough implementation (with much of the syntax likely wrong) might be just... >>> >>> c> Metacello class >> package: aPackage >>> c> | packageConfig | >>> c> packageConfig := 'ConfigurationOf', aPackage; >>> c> Gopher new c> squeaksource: 'MetacelloRepository'; >>> c> package: packageConfig >>> c> load >>> c> ^((Smalltalk at: (packageConfig asSymbol)) >>> >>> >>> Now after I've written the above I contemplate that there must have been an early design decision to not implement a separate Metacello class to avoid duplication/overlap with Monticello. However perhaps now that the system is implemented as it is, a thin shim can be put over the top to assist getting the ConfigurationOfXXX files downloaded. Additional things this Metacello class might later provide: a. Improved reliability by downloading from a system of package repository mirrors. SqueakSource was having some issues and I found [1] a fortunate backup. b. A GUI for browsing package versions >>> c. A GUI for browsing compatibility tables from a continuous integration system that tries different permutations of Montecello packages together. >>> >>> >>> 4. It seems that every ConfigurationOfXXX has its own category in the SystemBrowser. Each of these categories has only one class. This seems to me like unneeded clutter of the System Browser. It would be neater if Metacello specified its configurations to be grouped under a single category "MetacelloConfigurations" or similar. >>> >>> 5. The sample Metacello PBE is very good in the detail for developers to provide configurations. However there is not much directed clearly at a 'mere' user. Even though Smalltalk makes us all developers, newbies all start as mere users while exploring the system. [1] Gofer new url: 'http://dsal.cl/squeaksource/MonticelloRedirect'; package: 'MontiRedirect'; load. MRManager redirectFrom: 'http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'. >>> >>> Cheers, Ben >>> >>> >> >> >> >> > >
Hi Ben. Some offtopic, but be aware that ConfigurationOfSqueakDBX is deprecated. The whole project has been renamed to DBXTalk and what was SqueakDBX is now DBXTalkOpenDBXDriver. You can find ConfigurationOfOpenDBXDriver in DBXTalk repo or MetacelloRepository. On Mon, Dec 19, 2011 at 6:11 PM, Stéphane Ducasse <stephane.ducasse@inria.fr > wrote: > > On Dec 19, 2011, at 5:04 PM, Ben Coman wrote: > > > Stéphane Ducasse wrote: > >> ben thanks for your feedback. > >> > >> Normally we should use the monticello repository browser and just click > on a ConfigurationOf > >> > > I've been lurking this mail list for 6 - 9 months and had not picked > that up. That is a big miss. I'm not usually so slow. Can you point me to > the documentation that describes that process? > > > The problem is that we did not push it to the point the repository for > 1.0, contains only 1.0 configuration. > We will check that when esteban will arrive. > > > > > In the meantime, I unzip a fresh Pharo-1.3-OneClick, open Monticello > Browser and look for ConfigurationOfSqueakDBX. I can't see it. I expected > to since you seemed to indicate it was that simple. > > > > So I GUESS* my way through. I <Open> the > http://www.squeaksource.com/MetacelloRepository repository > > (which actually requires a bit of fore knowledge about the url - which > not all newbies will have) > > This did show ConfigurationOfSqueakDBX but the are many versions and so > many buttons to choose from. A bit scary for a newbie. > > Anyhow, I'll ASSUME* to select the latest one > ConfigurationOfSqueakDBX-MarianoMartinezPeck.27 and click <Load>. > > > > I still can't see any SqueakDBX or OpenDBX classes in System Browser. > > Do I need to follow up manually doing "ConfigurationOfSqueakDBX project > latestVersion load." ? > > A mixed procedure part GUI and part non-GUI is not the best - and I've > not seen it documented anywhere. > > > > I would have liked to have loaded the package with "just a single click > on a ConfigurationOf" but there seems to be more to it than that. > > > > The following still seems easier: > > > Metacello package: 'SqueakDBX' load > > or perhaps some alternatives using existing tools... > > 1. To the Monticello Browser add a <Metacello> button that opens > http://www.squeaksource.com/MetacelloRepository. If Metacello is "THE" > package management tool then it should have a higher profile than just one > of the 23 listed repositories, of which two others have "Metacello" in > their title. > > 2. To the World Menu, add a <Metacello Browser> item that jumps straight > to the Monticello Repository Browser for > http://www.squeaksource.com/MetacelloRepository. > > 3. The Welcome Text of a fresh pharo-oneclick image should describe how > to do either 1. or 2. above. > > > > cheers, Ben > >> than did you read the forthcoming chapter? > >> https://gforge.inria.fr/frs/download.php/28462/Metacello.pdf (old > version) > >> > >> > > Yes I refer to it in point 4 below. Can you point me to where in that > pdf it specifically describes that loading procedure using Monticello > Browser. All the examples I can see are code b> below, except using > (Smalltalk at:.....) rather than the class itself. > > > > Further, the Pharo-1.3-OneClick opening documentation says to execute > the following line... > > > DEVImageWorkspaces openExternalProjectWorkspace. > > which shows several examples all of the same form as the code b> below. > > > > Also, from memory the examples given throughout this mail list tend to > be of the same form as code b> below - rather than directing people to the > GUI Monticello Browser - or I probably would have picked that up sooner. > > > >> Stef > >> > >> > >> > >> On Dec 19, 2011, at 5:15 AM, Ben Coman wrote: > >> > >> > >>> Some observations from the perspective of as a newbie on Pharo Package > Management. I'm likely to me missing in the philosophy of the design, but > from the narrow view of my own usage.... > >>> > >>> 1. When I read about Metacello being the package management system, I > expected there to be a "command"(*) Metacallo but instead I see Gopher > being used. This is a mixed message that lowers my comfort level feeling > I understand the system as I'm trying to pick up a bundle of new ideas. As > I now understand it Metacello is more about a system of backend > configuration than a front end user interface. I am now more comfortable > using Gopher direct - but I reflect on how I felt the first time. > >>> > >>> (*) While technically a "command" is like a verb, and Gopher is like > a noun rather than a verb - I can't yet completely disengage my prior > learning that considers the first part of the statement to be a "command" - > and I expect other newbies might find the same. > >>> > >>> 2. The strong convention of naming things ConfigurationOfXXXX is > somewhat redundant from a user perspective. > >>> > >>> 3. If copy-paste into the Workspace from a web site a sample package > load (for example b> below) and then highlight the whole thing and execute, > it tells me > >>> "Unknown variable: ConfigurationOfSqueakDBX, please correct, or > cancel" Duh! What? Oh, I need to execute it in two parts. No one wrote > that down anywhere.... > >>> The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds > further complexity in the eyes of a newbie. > >>> > >>> Based on the above points, it would be nice to have... > >>> > >>> a> Metacello configuration: 'SqueakDBX' load > >>> > >>> rather than... > >>> > >>> b> Gofer new > >>> b> squeaksource: 'MetacelloRepository'; > >>> b> package: 'ConfigurationOfSqueakDBX'; > >>> b> load. > >>> b> ConfigurationOfSqueakDBX project latestVersion load. > >>> While only a small saving in typing, I think it significant for > newbies in terms of polish and the marketing message that Metacello really > is the chosen package management system. > >>> A very rough implementation (with much of the syntax likely wrong) > might be just... > >>> > >>> c> Metacello class >> package: aPackage > >>> c> | packageConfig | > >>> c> packageConfig := 'ConfigurationOf', aPackage; > >>> c> Gopher new c> squeaksource: > 'MetacelloRepository'; > >>> c> package: packageConfig > >>> c> load > >>> c> ^((Smalltalk at: (packageConfig asSymbol)) > >>> > >>> > >>> Now after I've written the above I contemplate that there must have > been an early design decision to not implement a separate Metacello class > to avoid duplication/overlap with Monticello. However perhaps now that the > system is implemented as it is, a thin shim can be put over the top to > assist getting the ConfigurationOfXXX files downloaded. Additional things > this Metacello class might later provide: a. Improved reliability by > downloading from a system of package repository mirrors. SqueakSource was > having some issues and I found [1] a fortunate backup. b. A GUI for > browsing package versions > >>> c. A GUI for browsing compatibility tables from a continuous > integration system that tries different permutations of Montecello packages > together. > >>> > >>> > >>> 4. It seems that every ConfigurationOfXXX has its own category in the > SystemBrowser. Each of these categories has only one class. This seems to > me like unneeded clutter of the System Browser. It would be neater if > Metacello specified its configurations to be grouped under a single > category "MetacelloConfigurations" or similar. > >>> > >>> 5. The sample Metacello PBE is very good in the detail for developers > to provide configurations. However there is not much directed clearly at a > 'mere' user. Even though Smalltalk makes us all developers, newbies all > start as mere users while exploring the system. [1] Gofer new url: ' > http://dsal.cl/squeaksource/MonticelloRedirect'; package: > 'MontiRedirect'; load. MRManager redirectFrom: ' > http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'. > >>> > >>> Cheers, Ben > >>> > >>> > >> > >> > >> > >> > > > > > > > -- Mariano http://marianopeck.wordpress.com
Thanks for the tip. I was aware of the rename to DBXTalk, but not the change to ConfigurationOfOpenDBXDriver. The new site [1] says "Welcome to SqueakDBX", and [2] refers only to ConfigurationOfSqueakDBX. Further offtopic but perhaps of interest to others... The DBXTalk site was difficult to find. For me google results only show it on the second page. I lament for your sake the loss of the squeakdbx.org domain. You may have had better better results holding on to it for a couple of years coupled with a 301 redirect [3][4]. As well as losing the immediate redirects from the existing links on other web sites, including your own [5], the cybersquatter now on squeakdbx.org may compromise the ranking of your new site, along with additional "content duplication/spam" reasons discussed at [3]. [1] http://dbxtalk.smallworks.com.ar/ [2] http://dbxtalk.smallworks.com.ar/Installation [3] http://www.bigoakinc.com/seo-articles/301-direct-Google.php [4] http://support.google.com/webmasters/bin/answer.py?hl=en&answer=93633 [5] http://marianopeck.wordpress.com/tag/dbxtalk/ cheers, Ben Mariano Martinez Peck wrote:
Hi Ben. Some offtopic, but be aware that ConfigurationOfSqueakDBX is deprecated. The whole project has been renamed to DBXTalk and what was SqueakDBX is now DBXTalkOpenDBXDriver. You can find ConfigurationOfOpenDBXDriver in DBXTalk repo or MetacelloRepository.
On Mon, Dec 19, 2011 at 6:11 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
On Dec 19, 2011, at 5:04 PM, Ben Coman wrote:
Stéphane Ducasse wrote:
ben thanks for your feedback.
Normally we should use the monticello repository browser and just click
on a ConfigurationOf
I've been lurking this mail list for 6 - 9 months and had not picked
that up. That is a big miss. I'm not usually so slow. Can you point me to the documentation that describes that process?
The problem is that we did not push it to the point the repository for 1.0, contains only 1.0 configuration. We will check that when esteban will arrive.
In the meantime, I unzip a fresh Pharo-1.3-OneClick, open Monticello
Browser and look for ConfigurationOfSqueakDBX. I can't see it. I expected to since you seemed to indicate it was that simple.
So I GUESS* my way through. I <Open> the
http://www.squeaksource.com/MetacelloRepository repository
(which actually requires a bit of fore knowledge about the url - which
not all newbies will have)
This did show ConfigurationOfSqueakDBX but the are many versions and so
many buttons to choose from. A bit scary for a newbie.
Anyhow, I'll ASSUME* to select the latest one
ConfigurationOfSqueakDBX-MarianoMartinezPeck.27 and click <Load>.
I still can't see any SqueakDBX or OpenDBX classes in System Browser. Do I need to follow up manually doing "ConfigurationOfSqueakDBX project
latestVersion load." ?
A mixed procedure part GUI and part non-GUI is not the best - and I've
not seen it documented anywhere.
I would have liked to have loaded the package with "just a single click
on a ConfigurationOf" but there seems to be more to it than that.
The following still seems easier:
Metacello package: 'SqueakDBX' load
or perhaps some alternatives using existing tools... 1. To the Monticello Browser add a <Metacello> button that opens
http://www.squeaksource.com/MetacelloRepository. If Metacello is "THE" package management tool then it should have a higher profile than just one of the 23 listed repositories, of which two others have "Metacello" in their title.
2. To the World Menu, add a <Metacello Browser> item that jumps straight
to the Monticello Repository Browser for http://www.squeaksource.com/MetacelloRepository.
3. The Welcome Text of a fresh pharo-oneclick image should describe how
to do either 1. or 2. above.
cheers, Ben
than did you read the forthcoming chapter? https://gforge.inria.fr/frs/download.php/28462/Metacello.pdf (old
version)
Yes I refer to it in point 4 below. Can you point me to where in that
pdf it specifically describes that loading procedure using Monticello Browser. All the examples I can see are code b> below, except using (Smalltalk at:.....) rather than the class itself.
Further, the Pharo-1.3-OneClick opening documentation says to execute
the following line...
DEVImageWorkspaces openExternalProjectWorkspace.
which shows several examples all of the same form as the code b> below.
Also, from memory the examples given throughout this mail list tend to
be of the same form as code b> below - rather than directing people to the GUI Monticello Browser - or I probably would have picked that up sooner.
Stef
On Dec 19, 2011, at 5:15 AM, Ben Coman wrote:
Some observations from the perspective of as a newbie on Pharo Package
Management. I'm likely to me missing in the philosophy of the design, but from the narrow view of my own usage....
1. When I read about Metacello being the package management system, I
expected there to be a "command"(*) Metacallo but instead I see Gopher being used. This is a mixed message that lowers my comfort level feeling I understand the system as I'm trying to pick up a bundle of new ideas. As I now understand it Metacello is more about a system of backend configuration than a front end user interface. I am now more comfortable using Gopher direct - but I reflect on how I felt the first time.
(*) While technically a "command" is like a verb, and Gopher is like
a noun rather than a verb - I can't yet completely disengage my prior learning that considers the first part of the statement to be a "command" - and I expect other newbies might find the same.
2. The strong convention of naming things ConfigurationOfXXXX is
somewhat redundant from a user perspective.
3. If copy-paste into the Workspace from a web site a sample package
load (for example b> below) and then highlight the whole thing and execute, it tells me
"Unknown variable: ConfigurationOfSqueakDBX, please correct, or
cancel" Duh! What? Oh, I need to execute it in two parts. No one wrote that down anywhere....
The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds
further complexity in the eyes of a newbie.
Based on the above points, it would be nice to have...
a> Metacello configuration: 'SqueakDBX' load
rather than...
b> Gofer new b> squeaksource: 'MetacelloRepository'; b> package: 'ConfigurationOfSqueakDBX'; b> load. b> ConfigurationOfSqueakDBX project latestVersion load. While only a small saving in typing, I think it significant for
newbies in terms of polish and the marketing message that Metacello really is the chosen package management system.
A very rough implementation (with much of the syntax likely wrong)
might be just...
c> Metacello class >> package: aPackage c> | packageConfig | c> packageConfig := 'ConfigurationOf', aPackage; c> Gopher new c> squeaksource:
'MetacelloRepository';
c> package: packageConfig c> load c> ^((Smalltalk at: (packageConfig asSymbol))
Now after I've written the above I contemplate that there must have
been an early design decision to not implement a separate Metacello class to avoid duplication/overlap with Monticello. However perhaps now that the system is implemented as it is, a thin shim can be put over the top to assist getting the ConfigurationOfXXX files downloaded. Additional things this Metacello class might later provide: a. Improved reliability by downloading from a system of package repository mirrors. SqueakSource was having some issues and I found [1] a fortunate backup. b. A GUI for browsing package versions
c. A GUI for browsing compatibility tables from a continuous
integration system that tries different permutations of Montecello packages together.
4. It seems that every ConfigurationOfXXX has its own category in the
SystemBrowser. Each of these categories has only one class. This seems to me like unneeded clutter of the System Browser. It would be neater if Metacello specified its configurations to be grouped under a single category "MetacelloConfigurations" or similar.
5. The sample Metacello PBE is very good in the detail for developers
to provide configurations. However there is not much directed clearly at a 'mere' user. Even though Smalltalk makes us all developers, newbies all start as mere users while exploring the system. [1] Gofer new url: ' http://dsal.cl/squeaksource/MonticelloRedirect'; package: 'MontiRedirect'; load. MRManager redirectFrom: ' http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'.
Cheers, Ben
On Wed, Dec 21, 2011 at 3:56 PM, Ben Coman <btc@openinworld.com> wrote:
Thanks for the tip. I was aware of the rename to DBXTalk, but not the change to ConfigurationOfOpenDBXDriver. The new site [1] says "Welcome to SqueakDBX", and [2] refers only to ConfigurationOfSqueakDBX.
Well, it is NOT a new site, it is just a backup of the previous in the meanwhile until we have the new one. The new website (for DBXTalk is in progress and we will ANN it soon)
Further offtopic but perhaps of interest to others... The DBXTalk site was difficult to find. For me google results only show it on the second page. I lament for your sake the loss of the squeakdbx.org domain. You may have had better better results holding on to it for a couple of years coupled with a 301 redirect [3][4]. As well as losing the immediate redirects from the existing links on other web sites, including your own [5], the cybersquatter now on squeakdbx.org may compromise the ranking of your new site, along with additional "content duplication/spam" reasons discussed at [3].
Thanks Ben for the advice. Unfortunately it is too late :(
[1] http://dbxtalk.smallworks.com.**ar/<http://dbxtalk.smallworks.com.ar/> [2] http://dbxtalk.smallworks.com.**ar/Installation<http://dbxtalk.smallworks.com.ar/Installation> [3] http://www.bigoakinc.com/seo-**articles/301-direct-Google.php<http://www.bigoakinc.com/seo-articles/301-direct-Google.php> [4] http://support.google.com/**webmasters/bin/answer.py?hl=** en&answer=93633<http://support.google.com/webmasters/bin/answer.py?hl=en&answer=93633> [5] http://marianopeck.wordpress.**com/tag/dbxtalk/<http://marianopeck.wordpress.com/tag/dbxtalk/>
cheers, Ben
Mariano Martinez Peck wrote:
Hi Ben. Some offtopic, but be aware that ConfigurationOfSqueakDBX is deprecated. The whole project has been renamed to DBXTalk and what was SqueakDBX is now DBXTalkOpenDBXDriver. You can find ConfigurationOfOpenDBXDriver in DBXTalk repo or MetacelloRepository.
On Mon, Dec 19, 2011 at 6:11 PM, Stéphane Ducasse < stephane.ducasse@inria.fr
wrote:
On Dec 19, 2011, at 5:04 PM, Ben Coman wrote:
Stéphane Ducasse wrote:
ben thanks for your feedback.
Normally we should use the monticello repository browser and just click
on a ConfigurationOf
I've been lurking this mail list for 6 - 9 months and had not picked
that up. That is a big miss. I'm not usually so slow. Can you point me to the documentation that describes that process?
The problem is that we did not push it to the point the repository for 1.0, contains only 1.0 configuration. We will check that when esteban will arrive.
In the meantime, I unzip a fresh Pharo-1.3-OneClick, open Monticello
Browser and look for ConfigurationOfSqueakDBX. I can't see it. I expected to since you seemed to indicate it was that simple.
So I GUESS* my way through. I <Open> the
(which actually requires a bit of fore knowledge about the url - which
not all newbies will have)
This did show ConfigurationOfSqueakDBX but the are many versions and so
many buttons to choose from. A bit scary for a newbie.
Anyhow, I'll ASSUME* to select the latest one
ConfigurationOfSqueakDBX-**MarianoMartinezPeck.27 and click <Load>.
I still can't see any SqueakDBX or OpenDBX classes in System Browser. Do I need to follow up manually doing "ConfigurationOfSqueakDBX project
latestVersion load." ?
A mixed procedure part GUI and part non-GUI is not the best - and I've
not seen it documented anywhere.
I would have liked to have loaded the package with "just a single click
on a ConfigurationOf" but there seems to be more to it than that.
The following still seems easier:
Metacello package: 'SqueakDBX' load
or perhaps some alternatives using existing tools... 1. To the Monticello Browser add a <Metacello> button that opens
http://www.squeaksource.com/**MetacelloRepository<http://www.squeaksource.com/MetacelloRepository>. If Metacello is "THE" package management tool then it should have a higher profile than just one of the 23 listed repositories, of which two others have "Metacello" in their title.
2. To the World Menu, add a <Metacello Browser> item that jumps straight
to the Monticello Repository Browser for http://www.squeaksource.com/**MetacelloRepository<http://www.squeaksource.com/MetacelloRepository> .
3. The Welcome Text of a fresh pharo-oneclick image should describe how
to do either 1. or 2. above.
cheers, Ben
than did you read the forthcoming chapter? https://gforge.inria.fr/frs/**download.php/28462/Metacello.**pdf<https://gforge.inria.fr/frs/download.php/28462/Metacello.pdf>(old
version)
Yes I refer to it in point 4 below. Can you point me to where in that
pdf it specifically describes that loading procedure using Monticello Browser. All the examples I can see are code b> below, except using (Smalltalk at:.....) rather than the class itself.
Further, the Pharo-1.3-OneClick opening documentation says to execute
the following line...
DEVImageWorkspaces openExternalProjectWorkspace.
which shows several examples all of the same form as the code b> below.
Also, from memory the examples given throughout this mail list tend to
be of the same form as code b> below - rather than directing people to the GUI Monticello Browser - or I probably would have picked that up sooner.
Stef
On Dec 19, 2011, at 5:15 AM, Ben Coman wrote:
Some observations from the perspective of as a newbie on Pharo Package
Management. I'm likely to me missing in the philosophy of the design,
but from the narrow view of my own usage....
1. When I read about Metacello being the package management system, I
expected there to be a "command"(*) Metacallo but instead I see Gopher being used. This is a mixed message that lowers my comfort level feeling I understand the system as I'm trying to pick up a bundle of new ideas. As I now understand it Metacello is more about a system of backend configuration than a front end user interface. I am now more comfortable using Gopher direct - but I reflect on how I felt the first time.
(*) While technically a "command" is like a verb, and Gopher is like
a noun rather than a verb - I can't yet completely disengage my prior learning that considers the first part of the statement to be a "command" - and I expect other newbies might find the same.
2. The strong convention of naming things ConfigurationOfXXXX is
somewhat redundant from a user perspective.
3. If copy-paste into the Workspace from a web site a sample package
load (for example b> below) and then highlight the whole thing and execute, it tells me
"Unknown variable: ConfigurationOfSqueakDBX, please correct, or
cancel" Duh! What? Oh, I need to execute it in two parts. No one wrote that down anywhere....
The alternative "(Smalltalk at: #ConfigurationOfSqueakDBX)" adds
further complexity in the eyes of a newbie.
Based on the above points, it would be nice to have...
a> Metacello configuration: 'SqueakDBX' load
rather than...
b> Gofer new b> squeaksource: 'MetacelloRepository'; b> package: 'ConfigurationOfSqueakDBX'; b> load. b> ConfigurationOfSqueakDBX project latestVersion load. While only a small saving in typing, I think it significant for
newbies in terms of polish and the marketing message that Metacello really is the chosen package management system.
A very rough implementation (with much of the syntax likely wrong)
might be just...
c> Metacello class >> package: aPackage
c> | packageConfig | c> packageConfig := 'ConfigurationOf', aPackage; c> Gopher new c> squeaksource:
'MetacelloRepository';
c> package: packageConfig
c> load c> ^((Smalltalk at: (packageConfig asSymbol))
Now after I've written the above I contemplate that there must have
been an early design decision to not implement a separate Metacello class to avoid duplication/overlap with Monticello. However perhaps now that the system is implemented as it is, a thin shim can be put over the top to assist getting the ConfigurationOfXXX files downloaded. Additional things this Metacello class might later provide: a. Improved reliability by downloading from a system of package repository mirrors. SqueakSource was having some issues and I found [1] a fortunate backup. b. A GUI for browsing package versions
c. A GUI for browsing compatibility tables from a continuous
integration system that tries different permutations of Montecello packages together.
4. It seems that every ConfigurationOfXXX has its own category in the
SystemBrowser. Each of these categories has only one class. This seems to me like unneeded clutter of the System Browser. It would be neater if Metacello specified its configurations to be grouped under a single category "MetacelloConfigurations" or similar.
5. The sample Metacello PBE is very good in the detail for developers
to provide configurations. However there is not much directed clearly at a 'mere' user. Even though Smalltalk makes us all developers, newbies all start as mere users while exploring the system. [1] Gofer new url: ' http://dsal.cl/squeaksource/**MonticelloRedirect<http://dsal.cl/squeaksource/MonticelloRedirect>'; package: 'MontiRedirect'; load. MRManager redirectFrom: ' http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'**.
Cheers, Ben
-- Mariano http://marianopeck.wordpress.com
i'd like to comment the parts i like (not all) :)
Based on the above points, it would be nice to have...
a> Â Metacello configuration: 'SqueakDBX' load
rather than...
b> Gofer new b> Â Â squeaksource: 'MetacelloRepository'; b> Â Â package: 'ConfigurationOfSqueakDBX'; b> Â Â load. b> ConfigurationOfSqueakDBX project latestVersion load.
yes , that would be nice. except from one thing: your image must have metacello installed. While things is done in a way, that you don't need to have it in order to load a project from your configuration. i.e. one can load ConfigurationOfXYZ into image without metacello and then run it, without caring if Metacello installed or not (because configuration takes care of it). But i think there could be a compromise. We may add an extension method to be able to do something like: Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject' and/or: Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject' version: 'x.y.z' like that, we can have a cake and eat it too. -- Best regards, Igor Stasenko.
Noooooooooooooooooooo ! Horrible ugly terrible, Don;t touch our SmalltalkImage :)
But i think there could be a compromise. We may add an extension method to be able to do something like:
Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject'
and/or:
Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject' version: 'x.y.z'
like that, we can have a cake and eat it too.
Why don't you take another look to Gofer Project Loader? (http://www.squeaksource.com/Loader.html) Maybe it needs to be integrated with Gofer to be really useful (as long as it is "yet another configuration", no one will use it), and maybe it needs some work on it... but it is already there :) Also I think: Gofer project load: 'Blah'. is far better than: Smalltalk loadMetacelloProject: 'Blah' best, Esteban El 20/12/2011, a las 5:39a.m., Stéphane Ducasse escribió:
Noooooooooooooooooooo !
Horrible ugly terrible, Don;t touch our SmalltalkImage :)
But i think there could be a compromise. We may add an extension method to be able to do something like:
Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject'
and/or:
Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject' version: 'x.y.z'
like that, we can have a cake and eat it too.
+1 On 20 Dec 2011, at 12:53, Esteban Lorenzano wrote:
Why don't you take another look to Gofer Project Loader? (http://www.squeaksource.com/Loader.html) Maybe it needs to be integrated with Gofer to be really useful (as long as it is "yet another configuration", no one will use it), and maybe it needs some work on it... but it is already there :)
Also I think:
Gofer project load: 'Blah'.
is far better than:
Smalltalk loadMetacelloProject: 'Blah'
S, Esteban Lorenzano piše:
Why don't you take another look to Gofer Project Loader? (http://www.squeaksource.com/Loader.html) Maybe it needs to be integrated with Gofer to be really useful (as long as it is "yet another configuration", no one will use it), and maybe it needs some work on it... but it is already there :)
Also I think:
Gofer project load: 'Blah'.
is far better than:
Smalltalk loadMetacelloProject: 'Blah'
Well, from a newbie standpoint not really. Who knows what Gofer is? Even I have still this problem. A word Installer or some other intent revealing word is needed for such important function as package management is. Maybe simply: Packager load: 'Blah' This one should look into default Monticello repository, search first for ConfigurationOfBlah in http:/mc.default.org/Blah, then in /MetacelloRepository and if not found load plain package Blah-byme.99.mcz Best regards Janko
best, Esteban
El 20/12/2011, a las 5:39a.m., Stéphane Ducasse escribió:
Noooooooooooooooooooo !
Horrible ugly terrible, Don;t touch our SmalltalkImage :)
But i think there could be a compromise. We may add an extension method to be able to do something like:
Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject'
and/or:
Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject' version: 'x.y.z'
like that, we can have a cake and eat it too.
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
http://www.lukas-renggli.ch/blog/gofer?_s=_m0YKWZKianpTQgX&_k=vLSxwQt5&_n&15 2011/12/20 Janko Mivšek <janko.mivsek@eranova.si>
Well, from a newbie standpoint not really. Who knows what Gofer is? Even I have still this problem.
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
Hi, A newbie also does not know anything about Smalltalk object, what metacello is or even what is a Package... At some point we need to stop lowering the level and expect our newbies have capability of learning and willing to do it... If we define Gofer as the "access point for every loadable artifact in Pharo", is easier for a newbie to look there when he wants to load something... much easier than split the functionality in different conceptual issues like Smalltalk, Packager or "Monticello Packager (Gofer)" anyway... you can call it as you want... what I'm just asking is: please, don't doit again... it is already there, waiting to be integrated :) cheers, Esteban El 20/12/2011, a las 9:59a.m., Janko Mivšek escribió:
S, Esteban Lorenzano piše:
Why don't you take another look to Gofer Project Loader? (http://www.squeaksource.com/Loader.html) Maybe it needs to be integrated with Gofer to be really useful (as long as it is "yet another configuration", no one will use it), and maybe it needs some work on it... but it is already there :)
Also I think:
Gofer project load: 'Blah'.
is far better than:
Smalltalk loadMetacelloProject: 'Blah'
Well, from a newbie standpoint not really. Who knows what Gofer is? Even I have still this problem. A word Installer or some other intent revealing word is needed for such important function as package management is. Maybe simply:
Packager load: 'Blah'
This one should look into default Monticello repository, search first for ConfigurationOfBlah in http:/mc.default.org/Blah, then in /MetacelloRepository and if not found load plain package Blah-byme.99.mcz
Best regards Janko
best, Esteban
El 20/12/2011, a las 5:39a.m., Stéphane Ducasse escribió:
Noooooooooooooooooooo !
Horrible ugly terrible, Don;t touch our SmalltalkImage :)
But i think there could be a compromise. We may add an extension method to be able to do something like:
Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject'
and/or:
Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject' version: 'x.y.z'
like that, we can have a cake and eat it too.
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
Esteban Lorenzano wrote:
Hi,
A newbie also does not know anything about Smalltalk object, what metacello is or even what is a Package... At some point we need to stop lowering the level and expect our newbies have capability of learning and willing to do it...
If we define Gofer as the "access point for every loadable artifact in Pharo", is easier for a newbie to look there when he wants to load something... much easier than split the functionality in different conceptual issues like Smalltalk, Packager or "Monticello Packager (Gofer)"
But having one tool for "_every_ loadable artifact" clutters up the higher level package management. I LIKE the segregation defined in the PBE2 Metacello sample chapter: * Monticello - managing source code versioning * Gofer - Moniticello Scripting API * Metacello - package dependency manager On further consideration of the PBE2 Metacello chapter I note that Metacello is a "Package Management System" and not a "Package Management Tool." Significantly what I expected to find as a newbie is The Tool, not The System. Consider that The Tool is for users and The System is for developers. While with Smalltalk we all end up developers, people being introduced to Pharo start as users.
anyway... you can call it as you want... what I'm just asking is: please, don't doit again... it is already there, waiting to be integrated :)
GopherProjectLoader particularly aligns with what I expected a class Metacello would do. Here are some significant ones... GopherProjectLoader class >> createRepositories "I answer a list of all pre-defined repositories on system" ^OrderedCollection with: (GoferProjectRepository location: 'http://www.squeaksource.com/MetacelloRepository') GoferProject class >> projectPrefix ^'ConfigurationOf' GopherProject >> toProjectList: aCollection "I collect all package names (with the form 'ConfigurationOf*' and transform them into project names)" ^(aCollection collect: [ :each | self toProjectName: each ]) asSet asOrderedCollection GopherProjectLoader>list "Lists all available projects, scanning all repositories" ^self repositories inject: OrderedCollection new into: [ :packageNames :each | packageNames, each list ]
cheers, Esteban
El 20/12/2011, a las 9:59a.m., Janko Mivšek escribió:
S, Esteban Lorenzano piše:
Why don't you take another look to Gofer Project Loader? (http://www.squeaksource.com/Loader.html) Maybe it needs to be integrated with Gofer to be really useful (as long as it is "yet another configuration", no one will use it), and maybe it needs some work on it... but it is already there :)
Also I think:
Gofer project load: 'Blah'.
is far better than:
Smalltalk loadMetacelloProject: 'Blah'
Well, from a newbie standpoint not really. Who knows what Gofer is? Even I have still this problem. A word Installer or some other intent revealing word is needed for such important function as package management is. Maybe simply:
Packager load: 'Blah'
+1 but not Installer or Packager, but Metacello!!! - the "defined" package management tool for Pharo.
This one should look into default Monticello repository, search first for ConfigurationOfBlah in http:/mc.default.org/Blah, then in /MetacelloRepository and if not found load plain package Blah-byme.99.mcz
Best regards Janko
best, Esteban
El 20/12/2011, a las 5:39a.m., Stéphane Ducasse escribió:
Noooooooooooooooooooo !
Horrible ugly terrible, Don;t touch our SmalltalkImage :)
But i think there could be a compromise. We may add an extension method to be able to do something like:
Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject'
and/or:
Smalltalk loadMetacelloProject: #ConfigurationOfXYZ fromRepository: 'http://squeaksource.com/XYZProject' version: 'x.y.z'
like that, we can have a cake and eat it too.
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
Igor Stasenko wrote:
i'd like to comment the parts i like (not all) :)
Based on the above points, it would be nice to have...
a> Metacello configuration: 'SqueakDBX' load
rather than...
b> Gofer new b> squeaksource: 'MetacelloRepository'; b> package: 'ConfigurationOfSqueakDBX'; b> load. b> ConfigurationOfSqueakDBX project latestVersion load. yes , that would be nice. except from one thing: your image must have metacello installed. While things is done in a way, that you don't need to have it in order to load a project from your configuration. i.e. one can load ConfigurationOfXYZ into image without metacello and then run it, without caring if Metacello is installed or not (because configuration takes care of it).
Sven Van Caekenberghe wrote:
On 19 Dec 2011, at 17:04, Ben Coman wrote:
I've been lurking this mail list for 6 - 9 months and had not picked that up. That is a big miss. I'm not usually so slow. Can you point me to the documentation that describes that process?
I agree, the UX is not (yet) perfect; so your comments are valid.
Metacello was written with many different design goals: one of them is that it solve the 'chicken/egg' problem by allowing configurations to be loadable in images that do not yet contain anything related to Metacello ! That is why you always see this boilerplate with Gofer and the Smalltalk at: #ConfigurationOf..
Sven
Preface: I imagine what I discuss below has been thrashed out in the original design and discarded, but I'd like to learn this topic better. I understand wanting a lean core image, but once a single ConfigurationOfXXX is loaded, Metacello ends up installed. So the independence is only important for the very first loaded ConfigurationOfXXX. If you are using an lean-image that does not have any ConfigurationOfXXX loaded, then you are likely an advanced user who knows how to resolve the Metacello dependency. A pre-requisite of example b> above is Gofer. I notice that PharoCore-1.3-13315.zip there is no Gopher and in Pharo-1.3-13315 there is but also ConfigurationOfGofer. Since example b> ends up with Metacello fully installed, is there any common use case where ConfigurationOfGofer would not be installed first? At which point, can we assume that Metacello is installed for example b> ? Now I assume my following proposal is flawed with respect either good practice and/or the Pharo design goals - but since (from my perspective) Metacello is a critical part of Pharo, I am interested for my learning why it would be evil to include just the following stub in PharoCore... ---8<---snip Metacello class >> doesNotUnderstand: aSymbol self ensureMetacello Metacello class >> ensureMetacello [as per the Metacello template] ---8<---snip
participants (9)
-
Ben Coman -
Bernardo Ezequiel Contreras -
Dale Henrichs -
Esteban Lorenzano -
Igor Stasenko -
Janko Mivšek -
Mariano Martinez Peck -
Stéphane Ducasse -
Sven Van Caekenberghe