February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Building images

by Nicolas Cellier

2012/2/7 Frank Shearar <frank.shearar(a)gmail.com>: > On 7 February 2012 16:12, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Friends, >> >> I know it's not a popular position, but I consider Metacello to be poorly >> factored, unstable, and a bit confusing. > > Would you please expand a bit on the above? Confusing, I'll happily > agree with, but then configuration management is not pretty at the > best of times. It's no worse than Maven's pom.xml files, except for > the Turing-completeness of the DSL. > > The issues I've had with Metacello have either been addressed in the > not-yet-released latest release (beta32, IIRC), or not the fault of > Metacello: many folks write their specs assuming an available network. > Instead, one should always attempt the package-cache > (MCCacheRepository default, in other words) FIRST, and IF the package > isn't already there, then try load it. > I suspect a nasty side effect is that an erroneous network address in the Metacello configuration will get undetected. This can happen easily because you previously loaded some package with Monticello, but then edited your Metacello configuration by hand. There is also a more subtle possible problem if names match but GUID don't. That easily happens, I created such mess when noob working with multiple images and local repositories. At least, the configuration needs to be validated with an available network. And the validation process shall check these two potential problems. Nicolas > Metacello's next release will be able to bootstrap itself without > relying on the network, but there are many configurations out there > that won't be able to. (I must still submit a fix to > MetacelloBaseConfiguration (if I remember the name correctly - > whatever MetacelloToolBox [1] uses ) to fix the issue for new > configurations. Bad me.) > > [1] https://gist.github.com/1438930 > >>Â How many times do we type things >> like: >> >> Â Gofer new >> Â Â Â Â squeaksource: 'Fuel'; >> Â Â Â Â package: 'ConfigurationOfFuel'; >> Â Â Â Â load. >> Â (Smalltalk at: #ConfigurationOfFuel) load. > > Well, I don't ever type that, but that's because Squeak doesn't ship > with Gofer, so I use Installer instead :) > >> This is concise, but it is also arguably syntactic sugar.Â I have been >> trying to condense the redundant information, and have been (trying to) >> capture the details in a tool I call Migrate. > > Which redundant information? There isn't any in the above, except > maybe 'ConfigurationOfFuel', or 'Fuel'. If you ASSUME that you only > want to use SqueakSource, you could say > > [:packageName | | confName | > Â confName := 'ConfigurationOf', packageName. > Â Gofer new > Â Â squeaksource: packageName; > Â Â package: confName; > Â Â load. > Â (Smalltalk at: confName asSymbol) load] value: 'Fuel'. > > Not exactly what I'd call clear and concise, but it does remove > redundancies.It looks like you're trying to do something vaguely > similar in Migrate - #loadMetacelloPackage:name:version: in > particular. > > But I _don't_ see much of Metacello in any of this. Well, let me be > clearer: I don't see any talk of specs, and that's pretty much most of > Metacello right there. A properly written Metacello spec will also > take care of pulling in transitive dependencies, which #web looks like > it's doing by hand. > > You can't have a common base class for configurations because that > would be part of Metacello, and you would need to have Metacello in > your image in order to load Metacello! > > frank > >>Â I have filed out the main >> class (attached).Â The idea is that one can save the Migrate package, load >> that into a new image, and quickly configure the new image.Â At least that's >> the plan. >> >> Of interest now are the helper-metacello methods.Â What do you think?Â I'm >> trying to help here... >> >> Bill >> >> >> >> >> >> >

Feb. 7, 2012

Re: [Pharo-project] Building images

by Sven Van Caekenberghe

On 07 Feb 2012, at 18:42, Schwab,Wilhelm K wrote: > Frank nailed it by saying that the network should be last resort. I am *really* flailing out here, ok :) Nothing works, and the ability to download and use from a local cache would be a HUGE(!!!!) help, I suspect. Frank took the words right out of my keyboard (and said it better than I would have). I agree that better caching behavior would be good, but really this is inherently a network related operation: loading remotely stored code. I fail to see how updating let's say Ubuntu would work with a failing network. SqueakSource has been failing today and was maybe slow before that, that would kill your whole experience, especially if you do big builds. Sven

Feb. 7, 2012

Re: [Pharo-project] Building images

by Sven Van Caekenberghe

On 07 Feb 2012, at 17:58, Dale Henrichs wrote: > With the next release of Metacello I am planning to include a scripting API where you will write scripts like the following: > > Metacello new > project: 'Seaside30'; > load. > > or: > > Metacello new > project: 'Seaside30'; > squeaksource: 'MetacelloRepository'; > version: '3.0.6; > load: #('Base'). > > for more examples and some discussion see[1]. The API is still under development and if you (or anyone else) would like to comment, I suggest that you join the metacello group[2] and join the discussion. > > The Metacello class is intended to be included in the base image of Pharo, GemStone and Squeak, which would allow for cross-platform scripting. Looking forward to all that, Dale! Sven

Feb. 7, 2012

[Pharo-project] Resource Descriptor Framework

by Ben Coman

Is there much being done with Resource Description Framework in Squeak/Pharo? I have some RDF data files that I need to load for my masters project and am seeking advice on how to approach this. I am only just learning about RDF for the first time. For anyone else interested the best short overview I found so far is [ http://logicerror.com/semanticWeb-webdev ] Apparently it this is a Simplified RDF Syntax as described at [ http://www.langdale.com.au/CIMXML/PSModelExchange.pdf ] A data file looks like like this... <?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cim="http://iec.ch/TC57/2007/CIM-schema-cim12#"> <cim:ACLineSegment rdf:ID="_7814201"> <cim:Conductor.length>95</cim:Conductor.length> <cim:IdentifiedObject.name>AMHE400MARCLINE</cim:IdentifiedObject.name> <cim:ConductingEquipment.BaseVoltage rdf:resource="#_400000302"/> <cim:Equipment.MemberOf_EquipmentContainer rdf:resource="#_487038201"/> </cim:ACLineSegment> The most obvious project on Squeaksource is Rakaiko [a] which says "RDF is an essential part of the new web technologies and a fundamental layer of the semantic Web 2.0 [...] This API, compliant with the W3C RDF specification will allow a developer to handle an RDF graph in its various forms (RDF/XML, N3, abstract graph). In other words, it would be the Squeak equivalent of the Jena Java RDF API." However there has been no activity on Rakaiko since 2007 and there is no apparent documentation. Has anyone used this and/or is this abandoned? Page 20 of "ESUG 2006 Welcome" mentions a "RDF Framework for Smalltalk." Did anything come of this? Alternatively I could fake it and learn just how to parse the XML directly and manually translate it into the class model. (It seems processing an a RDF Schema might be able to automatically create the class definition as well as the instance creation ) There is PetitXML, which however is not included by ConfigurationOfPetitParser.24 loaded on Moose 4.6. What is the status of PetitXML ? Also Moose 4.6 has XML-Parser. Which of XML-Parser or PetitXML would be the better approach ? I've watched http://www.tudorgirba.com/blog/simple-xml-browser-with-glamour but not sure whether than will help me actually load the data into a model. You opinion of these various approaches would be appreciated, and of course pointers to any examples/documentation.

Feb. 7, 2012

Re: [Pharo-project] Building images

by Schwab,Wilhelm K

Frank nailed it by saying that the network should be last resort. I am *really* flailing out here, ok :) Nothing works, and the ability to download and use from a local cache would be a HUGE(!!!!) help, I suspect. Frank took the words right out of my keyboard (and said it better than I would have). Otherwise, my primary comment is that the "incantations" are sugary. And yes, I am hoping to have Migrate reduce some of that, but mostly, I'd like it to work. Frank's comments about the inability to have a common base class are interesting. I would like to think that we could have a quick file-in or something, or just use indirect references to classes to get around it, but I admit he probably is correct in his statement. In fact, Migrate has a weirdness to it, and this might be helpful, maybe?? Migrate is the base class; there are some methods, #homegrownPackages, #me, #meFull and maybe others that must be defined in a subclass. I have a subclass called GatorAid (UF humor), that tells the Migrate what to do, or maybe more accurately, what it is expected to manipulate. The expression Migrate default looks for a single subclass, and instantiates that. That way, we share Migrate, I have GatorAid, you and others would have any subclass you choose as the real workhorse. I package Migrate in a single mcz, but that does not work well because it captures my configuration. So, I share it with a file out, and install it in new images using my own package. You would do the same: Migrate default saveMigrate saves the entire package. Make any sense? Feel free to steal any good ideas therein. Any progress on caching code for Metacello would be a HUGE help. Thanks, Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenrich(a)vmware.com] Sent: Tuesday, February 07, 2012 11:58 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Building images Bill, With the next release of Metacello I am planning to include a scripting API where you will write scripts like the following: Metacello new project: 'Seaside30'; load. or: Metacello new project: 'Seaside30'; squeaksource: 'MetacelloRepository'; version: '3.0.6; load: #('Base'). for more examples and some discussion see[1]. The API is still under development and if you (or anyone else) would like to comment, I suggest that you join the metacello group[2] and join the discussion. The Metacello class is intended to be included in the base image of Pharo, GemStone and Squeak, which would allow for cross-platform scripting. Dale [1] http://forum.world.st/Metacello-Scripting-API-strawman-td4334979.html [2] http://groups.google.com/group/metacello ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, February 7, 2012 8:12:14 AM | Subject: [Pharo-project] Building images | | | Friends, | | I know it's not a popular position, but I consider Metacello to be | poorly factored, unstable, and a bit confusing. How many times do we | type things like: | | Gofer new | squeaksource: 'Fuel' ; | package: 'ConfigurationOfFuel' ; | load . | ( Smalltalk at: # ConfigurationOfFuel ) load . | This is concise, but it is also arguably syntactic sugar. I have been | trying to condense the redundant information, and have been (trying | to) capture the details in a tool I call Migrate. I have filed out | the main class (attached). The idea is that one can save the Migrate | package, load that into a new image, and quickly configure the new | image. At least that's the plan. | | Of interest now are the helper-metacello methods. What do you think? | I'm trying to help here... | | Bill | | | | | | | | | |

Feb. 7, 2012

Re: [Pharo-project] It would be me first

by Steve Wart

Isn't there a mirror somewhere? Seems like it's always down. On Tue, Feb 7, 2012 at 7:58 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 7 February 2012 15:08, Igor Stasenko <siguctua(a)gmail.com> wrote: > > saying that SqueakSource down. > > > > or it is down only for me , such an unlucky guy? :) > > Looks like it's dead. The machine's alive, and the HTTP server's alive > though. > > frank > >

Feb. 7, 2012

Re: [Pharo-project] Building images

by Dale Henrichs

Bill, With the next release of Metacello I am planning to include a scripting API where you will write scripts like the following: Metacello new project: 'Seaside30'; load. or: Metacello new project: 'Seaside30'; squeaksource: 'MetacelloRepository'; version: '3.0.6; load: #('Base'). for more examples and some discussion see[1]. The API is still under development and if you (or anyone else) would like to comment, I suggest that you join the metacello group[2] and join the discussion. The Metacello class is intended to be included in the base image of Pharo, GemStone and Squeak, which would allow for cross-platform scripting. Dale [1] http://forum.world.st/Metacello-Scripting-API-strawman-td4334979.html [2] http://groups.google.com/group/metacello ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, February 7, 2012 8:12:14 AM | Subject: [Pharo-project] Building images | | | Friends, | | I know it's not a popular position, but I consider Metacello to be | poorly factored, unstable, and a bit confusing. How many times do we | type things like: | | Gofer new | squeaksource: 'Fuel' ; | package: 'ConfigurationOfFuel' ; | load . | ( Smalltalk at: # ConfigurationOfFuel ) load . | This is concise, but it is also arguably syntactic sugar. I have been | trying to condense the redundant information, and have been (trying | to) capture the details in a tool I call Migrate. I have filed out | the main class (attached). The idea is that one can save the Migrate | package, load that into a new image, and quickly configure the new | image. At least that's the plan. | | Of interest now are the helper-metacello methods. What do you think? | I'm trying to help here... | | Bill | | | | | | | | | |

Feb. 7, 2012

Re: [Pharo-project] Building images

by Frank Shearar

On 7 February 2012 16:12, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Friends, > > I know it's not a popular position, but I consider Metacello to be poorly > factored, unstable, and a bit confusing. Would you please expand a bit on the above? Confusing, I'll happily agree with, but then configuration management is not pretty at the best of times. It's no worse than Maven's pom.xml files, except for the Turing-completeness of the DSL. The issues I've had with Metacello have either been addressed in the not-yet-released latest release (beta32, IIRC), or not the fault of Metacello: many folks write their specs assuming an available network. Instead, one should always attempt the package-cache (MCCacheRepository default, in other words) FIRST, and IF the package isn't already there, then try load it. Metacello's next release will be able to bootstrap itself without relying on the network, but there are many configurations out there that won't be able to. (I must still submit a fix to MetacelloBaseConfiguration (if I remember the name correctly - whatever MetacelloToolBox [1] uses ) to fix the issue for new configurations. Bad me.) [1] https://gist.github.com/1438930 >Â How many times do we type things > like: > > Gofer new > squeaksource: 'Fuel'; > package: 'ConfigurationOfFuel'; > load. > (Smalltalk at: #ConfigurationOfFuel) load. Well, I don't ever type that, but that's because Squeak doesn't ship with Gofer, so I use Installer instead :) > This is concise, but it is also arguably syntactic sugar.Â I have been > trying to condense the redundant information, and have been (trying to) > capture the details in a tool I call Migrate. Which redundant information? There isn't any in the above, except maybe 'ConfigurationOfFuel', or 'Fuel'. If you ASSUME that you only want to use SqueakSource, you could say [:packageName | | confName | confName := 'ConfigurationOf', packageName. Gofer new squeaksource: packageName; package: confName; load. (Smalltalk at: confName asSymbol) load] value: 'Fuel'. Not exactly what I'd call clear and concise, but it does remove redundancies.It looks like you're trying to do something vaguely similar in Migrate - #loadMetacelloPackage:name:version: in particular. But I _don't_ see much of Metacello in any of this. Well, let me be clearer: I don't see any talk of specs, and that's pretty much most of Metacello right there. A properly written Metacello spec will also take care of pulling in transitive dependencies, which #web looks like it's doing by hand. You can't have a common base class for configurations because that would be part of Metacello, and you would need to have Metacello in your image in order to load Metacello! frank >Â I have filed out the main > class (attached).Â The idea is that one can save the Migrate package, load > that into a new image, and quickly configure the new image.Â At least that's > the plan. > > Of interest now are the helper-metacello methods.Â What do you think?Â I'm > trying to help here... > > Bill > > > > > >

Feb. 7, 2012

[Pharo-project] Building images

by Schwab,Wilhelm K

Friends, I know it's not a popular position, but I consider Metacello to be poorly factored, unstable, and a bit confusing. How many times do we type things like: Gofer new squeaksource: 'Fuel'; package: 'ConfigurationOfFuel'; load. (Smalltalk at: #ConfigurationOfFuel) load. This is concise, but it is also arguably syntactic sugar. I have been trying to condense the redundant information, and have been (trying to) capture the details in a tool I call Migrate. I have filed out the main class (attached). The idea is that one can save the Migrate package, load that into a new image, and quickly configure the new image. At least that's the plan. Of interest now are the helper-metacello methods. What do you think? I'm trying to help here... Bill

Feb. 7, 2012

Re: [Pharo-project] It would be me first

by Frank Shearar

On 7 February 2012 15:08, Igor Stasenko <siguctua(a)gmail.com> wrote: > saying that SqueakSource down. > > or it is down only for me , such an unlucky guy? :) Looks like it's dead. The machine's alive, and the HTTP server's alive though. frank

Feb. 7, 2012