May 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Metacello questions
by Andreas Raab May 6, 2010

May 6, 2010

Hi - I've been trying to wet my feet with Metacello a little by writing a ConfigurationOfWebClient and in the process I've come across various things that I don't understand or don't know how to express. The configuration itself can be found here: http://www.squeaksource.com/MetacelloRepository Here are the questions I'm having: 1) #includes: vs. #requires: What is the difference between #includes: and #requires:? They sound entirely interchangeable, in particular after reading the tutorial which states: "When you use the #includes: directive, you are not only specifying that the listed packages should be loaded when the parent package is loaded, but that the #included: packages should be loaded _before_ any packages that require the parent package." I would expect that precise behavior for required packages, i.e., if Foo requires: Bar then Bar is loaded before Foo if some other package requires: Foo. What am I missing? 2) Why is HelpSystem not loaded? In my configuration, baseline specifies that HelpSystem is required for WebClient-Help: "Documentation doesn't require Core/Tests, but HelpSystem" spec package: 'WebClient-Help' with:[spec requires: 'HelpSystem']. spec project: 'HelpSystem' with:[ spec className: 'ConfigurationOfHelpSystem'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]. However, when executed, Metacello goes through the motions but doesn't actually *load* any version of HelpSystem (I can see it 'fetch' the packages but not load them). It even calls the postLoadDoIt on it (which fails since nothing was loaded). What am I doing wrong? 3) When exactly is HelpSystem loaded? What I'm wondering about in the above is that HelpSystem should only be loaded if WebClient-Help is being loaded. Is this implicitly part of specifying a 'project' instead of a 'package'? Or is there some other way of specifying that? I guess really the question here is what entities get loaded implicitly simply by declaring them (packages for sure, any others?) and what entities need to be 'required' in order to be loaded? 4) How does one define dependencies that differ based on platform? In WebClient, the WebClient-HTTP package requires WebClient-Core and -only for: #pharo- also WebClient-Pharo. How does one express that there's an additional dependency for WebClient-HTTP that only exists for: #pharo? The config currently specifies: spec for: #common do:[ " ... " spec package: 'WebClient-HTTP' with:[spec requires: 'WebClient-Core']. " ... " ]. spec for: #pharo do:[ "Just the fact it exists; no requirements here" spec package: 'WebClient-Pharo'. ]. Which means that WebClient-Pharo will be loaded on Pharo by default but it's missing the fact that WebClient-Pharo is in fact a requirement for WebClient-HTTP (but only on that platform). How is that best expressed? 5) Bootstrapping Metacello? I found that most of the ConfigurationsOfXXX include some code to 'bootstrap' Metacello in some form. There appear to be variants on the code; is there a "canonical bootstrap method" that should be used? 6) A standard Configuration template? The Metacello tutorial is very useful as far as the configuration goes but it falls short of getting into the details of what it means to provide a 'working' configuration. Testing the configuration isn't covered (is there a way to get back to a 'clean' state?); bootstrapping isn't covered; the meaning of #isMetacelloConfig, #metacelloVesion:loads:, #lastMetacelloVersionLoad and several other -seemingly random- methods that can be found on most -but not all- of the configurations. There is no indication on what these do, if they're required, recommended, or optional. Is there some 'standard' Configuration template that people can use to avoid guessing about which parts of the boilerplate to copy from some other configuration? That's it for now. Thanks for any insights on any of these issues. Cheers, - Andreas

1 0

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser
by Dale Henrichs May 5, 2010

May 5, 2010

----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | Apparently the bug remains. When I load the last version of | 'ConfigurationOfPharo project' in a fresh and updated Core 1.1, then | | OB-Standard.lr.442 is loaded and initialized. | | So, the problem persists :-) Alexandre, The short answer is that this isn't really a bug. ConfigurationOfAutomaticMethodCategorizer calls for version 1.1 of ConfigurationOfOmniBrowser which references OB-Standard-lr.442. Version 1.1.3 of ConfigurationOfOmniBrowser (which references OB-Standard-lr.463) is listed after ConfigurationOfAutomaticMethodCategorizer in 1.1-baseline so OB-Standard-lr.442 is loaded first, then OB-Standard-lr.463 will be loaded later. This implies that ConfigurationOfAutomaticMethodCategorizer will not load correctly into Pharo 1.1, so the solution is to create a new version ConfigurationOfAutomaticMethodCategorizer that will load into Pharo 1.1 (i.e. referencing version 1.1.3 of ConfigurationOfOmniBrowser) and then update ConfigurationOfPharo accordingly... I'll give the long answer here so that folks can have an example of debugging a load issue in Metacello. The first thing I do is find the top MetacelloLoaderPolicy on the debugger stack and inspect loadDirective instance variable. Here's the printString: linear load : explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfOCompletion-Alexandre_Bergel.17 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfProfStef-DaleHenrichs.8 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfOmniBrowser-MarianoMartinezPeck.41 explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfPharoNonCore-MarianoMartinezPeck.2 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfRefactoringBrowser-MarianoMartinezPeck.22 explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfShout-DaleHenrichs.11 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfNile-MarianoMartinezPeck.11 explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfAutomaticMethodCategorizer-MarianoMartinezPeck.4 explicit load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfPharo] load : ConfigurationOfNewInspector-MarianoMartinezPeck.5 explicit load : 1.1 [ConfigurationOfPharo] preload : 1.1 [ConfigurationOfPharo] >> preloadForPharo linear load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.458 load : OB-Morphic-lr.112 load : OB-Standard-lr.442 postload : OB-Standard >> postLoadOBStandard load : AutomaticMethodCategorizer-DF.25 load : AutomaticMethodCategorizerOB-DF.1 linear load : 1.0 [ConfigurationOfShout] load : Shout-nice.83 load : ShoutWorkspace.1-tween.4 linear load : 1.0 [ConfigurationOfShout] load : ShoutTests-tween.9 linear load : 1.1.1 [ConfigurationOfOCompletion] load : RoelTyper-DamienCassou.80 load : Ocompletion-RomainRobbes.58 linear load : 1.1.1 [ConfigurationOfOCompletion] load : OcompletionTests-MarianoMartinezPeck.3 explicit load : 1.1.0 [ConfigurationOfPharoNonCore] load : ConfigurationOfPharoSound-MarianoMartinezPeck.8 explicit load : 1.1.0 [ConfigurationOfPharoNonCore] load : ConfigurationOfPharoMorphicExtras-MarianoMartinezPeck.10 preload : 1.1.0 [ConfigurationOfPharoNonCore] >> preloadForPharo linear load : 1.1.0 [ConfigurationOfPharoNonCore] linear load : 2.0 [ConfigurationOfPharoSound] load : Sound-MarianoMartinezPeck.49 load : SoundMorphicUserInterface-MarianoMartinezPeck.9 explicit load : 2.0 [ConfigurationOfPharoMorphicExtras] linear load : 2.0 [ConfigurationOfPharoMorphicExtras] load : MorphExamplesAndDemos-DamienCassou.5 load : LED-StephaneDucasse.1 load : ArchiveViewer-MarianoMartinezPeck.3 postload : 1.1.0 [ConfigurationOfPharoNonCore] >> postloadForPharo linear load : 1.1 [ConfigurationOfNewInspector] load : NewInspector-FredericPluquet.64 linear load : 1.2.1 [ConfigurationOfRefactoringBrowser] load : AST-Core-lr.67 load : Refactoring-Core-lr.115 load : Refactoring-Spelling-lr.19 linear load : 1.2.1 [ConfigurationOfRefactoringBrowser] load : AST-Tests-Core-lr.9 load : Refactoring-Tests-Core-lr.36 load : Refactoring-Tests-Spelling-lr.4 linear load : 1.1 [ConfigurationOfNile] load : Nile-Base-DamienCassou.81 linear load : 1.1 [ConfigurationOfNile] load : Nile-Tests-DamienCassou.75 load : Nile-Clients-MarianoMartinezPeck.178 explicit load : 1.1.3 [ConfigurationOfOmniBrowser] linear load : 1.1.3 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.469 load : OB-Morphic-lr.116 load : OB-Standard-lr.463 postload : OB-Standard >> postLoadOBStandard load : OB-SUnitIntegration-lr.24 load : OB-Shout-lr.5 load : OB-Refactory-lr.203 load : OB-Regex-lr.22 load : OCForOB-rr.2 explicit load : 1.1.3 [ConfigurationOfOmniBrowser] linear load : 1.1.3 [ConfigurationOfOmniBrowser] load : OB-Tests-Core-lr.81 load : OB-Tests-Morphic-lr.26 load : BogusInfo-lr.18 load : OB-Fake-lr.14 load : OB-Tests-Standard-lr.110 linear load : 1.0 [ConfigurationOfProfStef] load : ProfStef-Core-LaurentLaffont.2 linear load : 1.0 [ConfigurationOfProfStef] load : ProfStef-Tests-LaurentLaffont.2 load : ImageForDevelopers-pharo-MarianoMartinezPeck.224 postload : 1.1 [ConfigurationOfPharo] >> postloadForPharo Since OB-Standard is the problem package you can search for the package in the printString. The first occurrence is here: linear load : 1.1 [ConfigurationOfPharo] explicit load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfAutomaticMethodCategorizer] linear load : 1.1 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.458 load : OB-Morphic-lr.112 load : OB-Standard-lr.442 postload : OB-Standard >> postLoadOBStandard and the second occurrence is here: linear load : 1.1.3 [ConfigurationOfOmniBrowser] load : OmniBrowser-lr.469 load : OB-Morphic-lr.116 load : OB-Standard-lr.463 postload : OB-Standard >> postLoadOBStandard The nesting level for '1.1.3 [ConfigurationOfOmniBrowser]' and '1.1 [ConfigurationOfAutomaticMethodCategorizer]' are the same which means that they are both referenced in '1.1 [ConfigurationOfPharo]'. That was enough to solve this particular problem, but in an Inspector, you can dive into the directives themselves and actually get to the MetacelloSpec that was used to create the directive... Dale

3 7

[Pharo-project] [update 1.1] #11336
by StÃ©phane Ducasse May 5, 2010

May 5, 2010

11336 ----- - Issue 2386: milliSeconds: milliCount bad comment -> removed - Issue 2385: Compression missing primitivecall - Issue 2384: DurationTests - Issue 2378: ConfigurationOfPharoCore first try

1 0

[Pharo-project] Help System
by Torsten Bergmann May 5, 2010

May 5, 2010

Hi Lukas, "it is a design flaw" "Being forced to have strong references ... " "makes it impossible to just include some documentation" "This doesn't encourage me at all" "..." So many negative statements in one post, look like you had a bad day today ;) My comments below: a) If you want to provide API help (reference docu) you DONT HAVE ANY reference or dependency since you can comment your classes and methods in the usual Smalltalk way using class/method comments. No need for "HelpSystem-Core" to be around, NO REFERENCES, and NO EXCUSE NOT TO document your code ;) b) If you want to provide similar tutorials help (books/system help) that should appear in the "SystemHelp" then the answer is YES, HERE WE HAVE A DEPENDENCY since you subclass "CustomHelp" and reference "HelpTopic". But this is intended since after a few experiments with other solutions this was a very natural way to define the book contents. Would you call it a design flaw of SUnit to create tests by subclassing the class "TestCase" so that it is known to the system as test case and also shows up in the TestRunner? Does the dependency on SUnit make it impossible for you to write tests? Or does it even encourage you not to write tests? So please revise your statements. And yes, in the scenario I'm up to you typically provide a separate help package that can be separately loaded/unloaded. It depends on your deployment scenario if you want to keep it in the image or not. So a separate package makes sense for these tutorials. Either you ship with tests and docu or just with the code. If you deploy and ship an end user app for instance you would just need "SQLite-Core" and may unload "SQLite-Tests" and "SQLite-Help". If someone works with code (for instance SQLite) he can - either use the known API help (either in the Class browser or the HelpBrowser, see a) - or load the additional package with mostyl more generalized tutorials/manuals/books, its up to you to provide such an additional help package ("SQLite-Help" for instance) However - these two scenarios are provided by DEFAULT. You have a different scenario since where (if I understand you correctly) you want: c) Provide documentation that - is not defined in usual class/method comments - should be packaged with your code package instead of a separate one - should not be dependent on any class in the HelpSystem-Core package - may already be defined Here I would suggest you to find an appropriate way to write and store your documentation (for instance in methods with pragmas) the way you want AND INDEPENDENT from the current help system. If you want to have it shown later in the help system/help browser too you need to provide at least an (extension) method #asHelpTopic or use an own builder (see HelpBuilder and subclasses) to convert your documentation style to the generalized help topic hierarchy the browser is able to display. When you talk about an extensibility of the help system similar to preferences/menu building then you mainly talk about a pragma solution here: I already experimented with this in the early help system (see HelpSystem-Core-tbn.4) for instance and later switched to the subclassesing solution (similar to SUnit) mainly for the following reasons: 1. it is more intentional to directly map the book structure to the class hierarchy 2. You can use the usual ST tools to manage or refactor your books (the class hierarchy browse even shows you the topic hierarchy) 3. It is hard to describe a complete book structure (with page order, nested books and the like) in pragmas If you have a good solution then I'm all ears here. 4. By using pragmas (loose coupling) you have to deal with the problem that by your parent topic may not be there/not be loaded since it can be defined somewhere else in the class hierarchy. By mapping to the class hierarchy you cant run into the problem since you need the superclass (parent topic definition) for the subclass (subtopic definition) to be loaded. So I was pragmatic and used Plain old Smalltalk classes and method to define the books (POSCAM). But Help System does not limit you, currently we have a) and b) to define and bring help into the help system/help browser. If you have a good solution for defining complete books with structure using pragmas then we can include it... Meanwhile Lukas wrote: >Yes, I imagine something along ... > >PPParser class>>helpOn: aBuilder > <help> > Attached is a simple (rough)example that it is easy to extend the help system the way you may want (with a builder similar to system settings and your above example) Just load it into an up to date core 1.1. image and evaluate: HelpBrowser openOn: PragmaHelp Look at class Foo and Bar to see that there is no dependency and PragmaHelp/PragmaHelpBuilder to see how it is done. HelpSystem is flexible, you can also have external help sources as I've shown with the IRC example. It just depends on how you want to describe and structure your documentation... Bye Torsten P.S: I'm still in favour of well structured books in separate packages than mixed code/docu in one package since you may wish to unload docu for deployment/runtime scenarios. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

5 5

Re: [Pharo-project] [squeak-dev] Overrides. Evil. Need to do something with it.
by Igor Stasenko May 5, 2010

May 5, 2010

2010/5/5 StÃ©phane Rollandin <lecteur(a)zogotounga.net>: >> myMethod >> Â <doNotOverride> > >> What you think? > > It seems to me that this is half-way from proper defining of an API. > Why not be more explicit by specifying which API relies on that method, > like: > I don't think so. A method, which should not be overridden belongs to a class where its defined. And a class belongs to certain package. So, there is already enough information what API owns that method. And if you are talking about overriding an extension provided by another external package... i.e. when original method has category: *Foo-extensions and installed package tries to override with with own *Bar-extensions it should be prohibited at all, without giving any chances to load this package into a system. > myMethod > Â <API: myGreatApp> > > This would imply that it should not be overidden, but then if the user wants > to override it nonetheless he would know what API he is messing up with. > > Stef > -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] Pharo sprint in Brussels
by Johan Brichau May 5, 2010

May 5, 2010

Hi! We are organizing a Pharo sprint in Brussels on June 11 & 12th. An entry has been added to the page http://code.google.com/p/pharo/wiki/PharoSprints Please, add your name if you wish to participate. Some more info on practical issues to follow soon... ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

1 0

[Pharo-project] Overrides. Evil. Need to do something with it.
by Igor Stasenko May 5, 2010

May 5, 2010

Hello, there is a certain critial places in system, which should not be overridden by external packages. Otherwise, it becomes a mess and usually leads to malfunction in key system parts: compiler, special objects etc. I'd like to propose to introduce a special marker pragma for methods, which should _never_ be overridden by external package. myMethod <doNotOverride> an MC code loader should honor this pragma, and do not attempt to override this method when installing a package or at least ask user that there is a risk of getting serious problems, if you override this method. What you think? -- Best regards, Igor Stasenko AKA sig.

2 1

May 5, 2010

please distribute widely 18th International Smalltalk Joint Conference - Call for Contributions Barcelona, Spain September 13 - 17, 2010; Camp Smalltalk September 11-12 http://www.esug.org/conferences/2010/ This call includes: Developer program Free ESUG tickets Business day 16th of September (sponsored by Cincom Smalltalk) International Workshop http://www.esug.org/Conferences/2010/International+Workshop+on+Smalltalk+Te… Student Volunteer http://www.esug.org/Conferences/2010/Student+Volunteers+program Camp Smalltalk 11-12 September 2010 ---------------------------------------------------------------------- For the past 18 years, the European Smalltalk User Group (ESUG) has organised the International Smalltalk Conference, a lively forum on cutting edge software technologies that attract people from both academia and industry for a whole week. The attendees are both engineers using Smalltalk in business and students and teachers using Smalltalk both for research and didactic purposes. As every year, this year's edition of the largest European Smalltalk event will include the regular Smalltalk developers conference with renowned invited speakers, a Smalltalk camp that proves fruitful for interactions and discussions. Besides, this year will be held the - 6th edition of the Innovation Technology Awards where prizes will be awarded to authors of best pieces of Smalltalk-related projects - an international workshop on Smalltalk and dynamic languages http://www.esug.org/Conferences/2010/International+Workshop+on+Smalltalk+Te… * New this year: - There will be a business day: thursday 16th of September 2010. The focus will be on "Agile Development Processes and Smalltalk" - ESUG will offer 10 free entrance tickets. To get a free ticket you should send a mail to the esug board (board(a)esug.org) Subject: [ESUG 2010 Free entrance] + your name And you should write a small motivation. You can support the ESUG conference in many different ways: * Sponsor the conference. New sponsoring packages are described at http://www.esug.org/supportesug/becomeasponsor/ * Submit a talk, a software or a paper to one of the events. See below. * Attend the conference. We'd like to beat the previous record of attendance (156 participants at Brest and 170 people at Amsterdam)! * Students can get free registration and hosting if they enroll into the the Student Volunteers program. See below. Developers Forum: International Smalltalk Developers Conference ------------------------------------------------------------------------ This year we are looking for YOUR experience on using Smalltalk. In addition, we are looking for tutorials. The list of topics includes, but is not limited to the following: * XP practices * Development tools * Experience reports * Model driven development * Web development * Team management * Meta-Modeling * Security * New libraries & frameworks * Educational material * Embedded systems and robotics * SOA and Web services * Interaction with other programming languages Submissions due on 1 July 2010 Notification of acceptance on 15 of July 2010 More information at http://www.esug.org/conferences/2010 How to submit? ------------------ Pay attention: the places are limited so do not wait till the last minute to apply. Prospective presenters should submit a request to board(a)esug.org AND stephane.ducasse(a)free.fr following the template below. Please use this template since the emails will be automatically processed! Subject: [ESUG 2010 Developers] + your name First Name: Last Name: Email where you can always be reached: Title: Abstract: Bio: Any presentation not respecting this form will be discarded automatically Innovation Technology Award ------------------------------------------------------------------------ We are proud to announce the 6th Innovation Technology Awards. The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros during an awards ceremony at the conference. Developers of any Smalltalk-based software are welcome to compete. This year we will request 3-5min videos. More information at http://www.esug.org/Conferences/2010/Innovation+Technology+Awards Student Volunteer Program ------------------------------------------------------------------------ If you are a student wanting to attend ESUG, have you considered being a student volunteer? Student volunteers help keep the conference running smoothly; in return, they have free accommodations, while still having most of the time to enjoy the conference. More information at http://www.esug.org/conferences/2010 http://www.esug.org/Conferences/2010/Student+Volunteers+program We hope to see you there and have fun together. Ze ESUG board_______________________________________________ Board mailing list Board(a)lists.esug.org

1 0

[Pharo-project] Help System
by Torsten Bergmann May 5, 2010

May 5, 2010

>But it got loaded when I updated a core 1.1. Is this help system really >part of the Core? Yes, the help system is now part of the core to help documenting the system. It's also in Squeak trunk. >I suspect a duplication of effort between Glamour and HelpBrowser. No, I dont think so. The minimalistic HelpBrowser is too simple to make it dependent on Glamour. Otherwise you would have to bring Glamour into core or dev-images and rebase all kinds of browsers on it (Monticello Browser, Class browser, ...) The class "HelpBrowser" is like an interface so you can write HelpBrowser open HelpBrowser openOn: Integer and has only the minimal support to display the contents. We can easily implement a mechanism so that you can register another custom (enhanced/glamour based) help browser class that is loaded afterwards. I already have this in squeaksource/HelpSystem - have to merge tomorrow. Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

5 8

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser
by Dale Henrichs May 4, 2010

May 4, 2010

----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | > The nesting level for '1.1.3 [ConfigurationOfOmniBrowser]' and '1.1 | > [ConfigurationOfAutomaticMethodCategorizer]' are the same which | means that | > they are both referenced in '1.1 [ConfigurationOfPharo]'. That was | enough to | > solve this particular problem, but in an Inspector, you can dive | into the | > directives themselves and actually get to the MetacelloSpec that was | used to | > create the directive... | > | > | > | Here is what I don't understand. If you have that directive, and you | have | ALL that information, can't you guess that if you need to load the N | version | of a package and then the version M, where M > N, then you can skip to | load | N and just load M directly ? | | In this example, can you DO NOT load OmniBrowser-lr.458 as you know | that | after you will load OmniBrowser-lr.469 ? | Or maybe directly about conf: Do not load 1.1 | [ConfigurationOfOmniBrowser] if you know that then you will need to | load | 1.1.3 [ConfigurationOfOmniBrowser] Mariano, If you were using #atomic loads then what you are suggesting would happen ... Metacello would recognize that OmniBrowser-lr.469 was later and would use that instead of the older mcz file. With #linear loads it isn't necessarily safe to substitute a newer version of an mcz file earlier into the load sequence, because the newer version may have dependencies that wouldn't necessarily be satisfied this early in the load sequence...The only safe way is to explicitly move the project earlier in the sequence. Moving the specification of OmniBrowser before the spec for AutomaticMethodCategorizer does result in the correct mcz file for OB-Standard to be loaded, however, other issues are exposed: SHOUT uses the deprecated registerMenu API Refactoring Browser needs to be moved earlier to avoid double loading. I didn't notice any ill effects of loading earlier version of Refactoring Browser. Nile-Clients-MarianoMartinezPeck.178 has an issue with #isInMemory not understood Perhaps the MNU is due to the fact that I haven't updated PharoCore-1.1-11326-UNSTABLE. My tests to this point were done with Metacello 1.0-beta.26.1 (in development) to eliminate any (known) Metacello bugs from the equation. At this point I don't think 1.0-beta.26.1 is needed, but I will run an additional test and let you know... Dale

2 2