June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pratt Parsers for PetitParser

by Camille

> On 10 Jun 2015, at 20:31, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > camille teruel wrote >>> On 10 Jun 2015, at 19:11, Chris Cunningham < > >> cunningham.cb@ > >> > wrote: >>> >>> Inteteresting.... >>> >>> On Wed, Jun 10, 2015 at 9:36 AM, Camille < > >> camille.teruel@ > >> <mailto: > >> camille.teruel@ > >> >> wrote: >>> Hello Pharoers and Moosers, >>> >>> I did a Pratt parser extension for PetitParser. >>> >>> >> <snip> >> >>> @PP Devs: >>> I had trouble with the PPContext furthestFailure that is taken into >>> account instead of the failures I return, so I had to redefine >>> #parseWithContext: to return the failures I want. The results given by >>> furthestFailure were not very meaningful in my case (the same is true for >>> PPExpressionParser btw). >>> But I guess it was introduced because it gives good results in other >>> cases. >>> So would it be possible to change this behavior to let the parser decide >>> if it returns the furthestFailure or the original failure? >>> >>> The intent behind the furthestFailure is that it give the failure that >>> gets the furthest into the source stream. It is most useful when there >>> are embedded choice operators in the parser - the original/pre furthest >>> behaviour would return the last failure, which depending on the incoming >>> stream and the order of the choice options could be significantly not >>> useful. >>> >>> I ran into this when working with the sql parser, which started off with >>> the outer choice of (by memory): >>> ^ selectStatement / insertStatement / updateStatement / >>> deleteStatement >>> If I was trying to part a select statement that had an error at the very >>> end of the statement, the parser would return an error talking about how >>> the incoming stream failed in deleteStatement. Not useful. >>> >>> I would be saddened if this further failure was not available. >> >> Yes in that case returning the furthest failure gives better results. >> However, this donât give meaningful messages in all cases. >> For exemple with the calculator I gave in my previous message, if I parse >> â1+â I want to get âexpression expected at: 2â but instead it returns â$- >> expected at 2'. >> Iâm not proposing to remove this feature but to let parsers decide to use >> it or not. >> Something like (changes in bold): >> >> PPParser>>parseWithContext: context >> | result | >> context initializeFor: self. >> result := self parseOn: context. >> >> "Return the furthest failure, it gives better results than the last >> failure" >> (result isPetitFailure and: [ self wantsFurthestFailure and: [ context >> furthestFailure notNil ] ]) >> ifTrue: [ ^ context furthestFailure ]. >> ^ result > > This screams at me. Why not just delegate to the context and use a context > that returns the preferred failure? e.g. end with: > ^context preferredResultFor: result. Because the same context is passed around by many parsers. So if you let the context decide, you get the same behavior for all the parsers. > > >> >> PPParser>>wantsFurthestFailure >> ^ true >> >> Like this, one can return the failures he wants. >> >> PPPrattParser>>wantsFurthestFailure >> ^ false >> >> >> Camille >> >>> >>> -cbc > > > > > > -- > View this message in context: http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html <http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html> > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.

June 11, 2015

Re: [Pharo-dev] Pratt Parsers for PetitParser

by Jan KurÅ¡

That sounds really cool and useful extension. Regarding the furthest failure, the core of the problem is the distinction between an error and a failure. Error reports on a problem in the input, while failure is information for choice parser combinator. In general, the furthest failure is a better approximation of an error than the last failure, so we use it. I am not sure what exactly is the problem in case of PrattParser. I guess the last failure gives better results for a user? One has to consider a pratt parser included in the normal parser, e. g. Expressions parsed by pratt in a Java Grammar. Depending where an error occurs, different strategy for choosing the proper failure is necessary :-/ Regarding tokenization, there is a message token, that returns PPTokenParser, which transforms a parsed input into the PPToken object. Perhaps this might be helpful? Cheers Jan On Wed, Jun 10, 2015, 20:52 Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > camille teruel wrote > >> On 10 Jun 2015, at 19:11, Chris Cunningham < > > > cunningham.cb@ > > > > wrote: > >> > >> Inteteresting.... > >> > >> On Wed, Jun 10, 2015 at 9:36 AM, Camille < > > > camille.teruel@ > > > <mailto: > > > camille.teruel@ > > > >> wrote: > >> Hello Pharoers and Moosers, > >> > >> I did a Pratt parser extension for PetitParser. > >> > >> > > <snip> > > > >> @PP Devs: > >> I had trouble with the PPContext furthestFailure that is taken into > >> account instead of the failures I return, so I had to redefine > >> #parseWithContext: to return the failures I want. The results given by > >> furthestFailure were not very meaningful in my case (the same is true > for > >> PPExpressionParser btw). > >> But I guess it was introduced because it gives good results in other > >> cases. > >> So would it be possible to change this behavior to let the parser decide > >> if it returns the furthestFailure or the original failure? > >> > >> The intent behind the furthestFailure is that it give the failure that > >> gets the furthest into the source stream. It is most useful when there > >> are embedded choice operators in the parser - the original/pre furthest > >> behaviour would return the last failure, which depending on the incoming > >> stream and the order of the choice options could be significantly not > >> useful. > >> > >> I ran into this when working with the sql parser, which started off with > >> the outer choice of (by memory): > >> ^ selectStatement / insertStatement / updateStatement / > >> deleteStatement > >> If I was trying to part a select statement that had an error at the very > >> end of the statement, the parser would return an error talking about how > >> the incoming stream failed in deleteStatement. Not useful. > >> > >> I would be saddened if this further failure was not available. > > > > Yes in that case returning the furthest failure gives better results. > > However, this donât give meaningful messages in all cases. > > For exemple with the calculator I gave in my previous message, if I parse > > â1+â I want to get âexpression expected at: 2â but instead it returns â$- > > expected at 2'. > > Iâm not proposing to remove this feature but to let parsers decide to use > > it or not. > > Something like (changes in bold): > > > > PPParser>>parseWithContext: context > > | result | > > context initializeFor: self. > > result := self parseOn: context. > > > > "Return the furthest failure, it gives better results than the last > > failure" > > (result isPetitFailure and: [ self wantsFurthestFailure and: [ > context > > furthestFailure notNil ] ]) > > ifTrue: [ ^ context furthestFailure ]. > > ^ result > > This screams at me. Why not just delegate to the context and use a context > that returns the preferred failure? e.g. end with: > ^context preferredResultFor: result. > > > > > > PPParser>>wantsFurthestFailure > > ^ true > > > > Like this, one can return the failures he wants. > > > > PPPrattParser>>wantsFurthestFailure > > ^ false > > > > > > Camille > > > >> > >> -cbc > > > > > > -- > View this message in context: > http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

June 11, 2015

New Tool: Catalog Browser in Pharo 5.0

by Torsten Bergmann

Hi, maybe you already noticed. The latest update for Pharo 5 which is 50103 (see [1]). includes a new tool called "Catalog Browser". Where to go =========== You will find it under "Tools" -> "Catalog Browser" and it will display the configs together with the catalog metadata like project description. The code is managed with a configuration similar to what we have for a few other packages/projects. The tool was written by Esteban Lorenzano with small improvements like spotter integration from my side. Feel free to contribute more features. The repository can be found on SmalltalkHub [2]. This new tool basically gives you access to all available configurations aggregated at [3]. You can use a small UI to search and load the configs (see world menu -> "Tools" -> "Catalog Browser". But you can also use Spotter to load a config. Example on how to load ScriptManager config: ============================================ - open Spotter (SHIFT + ENTER on Windows, ...) - type in "Script" and you will find a spotter category "Catalog Projects" with "ScriptManager" in it - just hit enter and the config is loaded Same for all others, so try with "Seaside", "MongoTalk", ... In the short/mid-term this new tool should replace the existing config browser as it gives more informations about the projects. What to do next: ================ - give feedback - we should update all our configs with catalog descriptions - it would be nice if the spotter integration would include also a preview of the project description - ... If you want to contribute just tell Esteban so he can add you to the project. Thanks Esteban & Torsten [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-June/110964… [2] http://www.smalltalkhub.com/#!/~estebanlm/CatalogBrowser [3] http://catalog.pharo.org/catalog/json

June 11, 2015

Re: [Pharo-dev] Pharo 4, format on accept/display

by stepharo

Le 10/6/15 20:47, Paul DeBruicker a Ã©crit : > Hi > > I've hacked together an implementation of format on accept & display. > > > I know someone is redoing that functionality to better suit future needs. > > > Should I publish what I've got as a slice to the Pharo40Inbox for people to use that may miss it now that do not want to wait for the new hotness? Yes it is cool :) :) new text editor new pretty printer :) print on read print on accept :) > > > > Thanks > > > Paul >

June 11, 2015

Re: [Pharo-dev] Pharo 4, format on accept/display

by Marcus Denker

> On 11 Jun 2015, at 08:16, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > If my understanding of Pharo's release management is correct, then no new features are added after a release, only bugfixes. > Yes, but we do make exceptionsâ¦ e.g. I added format on display and accept to Pharo3 after the release, because it is indeed a nice thing to have. So in that sense not having it in Pharo4 is kind of a bug. The version we get in Pharo5 will come with a new pretty printer, we will not back port that, so doing a âminimally intrusiveâ version for Pharo4 makes sense. Marcus

June 11, 2015

Re: [Pharo-dev] Pharo 4, format on accept/display

by Peter UhnÃ¡k

If my understanding of Pharo's release management is correct, then no new features are added after a release, only bugfixes. So from this perspective I would suggest to publish it to Pharo50Inbox instead, including creating a new issue in Pharo bugtracker where you describe what is it changing. If you need in Pharo 4 it may be preferable to create a new repository for it (at smalltalkhub) and pushing it's configuration to http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo40, so people can install it manually via Configuration Browser without affecting Pharo 4 release. Peter On Thu, Jun 11, 2015 at 7:25 AM, Ben Coman <btc(a)openinworld.com> wrote: > By "publish a slice" do you also mean to ask it to be integrated into > Pharo4? > > The general issue is that every new fix for the released Pharo40 has > the *chance* of introducing some other problem, or adversely affecting > someone else's idea of how the system should operate. Even with > minimal quaility assurance for a release it takes effort to integrate > fixes, so each needs to be evaluated for impact. So the options for > Pharo 4 are: > 1. Continually integrate fixes as they arise ==> ++effort > 2. Continually integrate critical fixes only, hold all others for the > next point release. > 3. Hold all fixes for next point release. > > I don't see this as a critical fix :), so you'd be asking for (1.), > when probably (2.) should be the rule. > > Now I had the idea that fixes for a release that were not immediately > integrated might be published as a "hotfix" - taking Microsoft's > terminology for an update fixing a specific issue without having gone > through full quality control with all other fixes, so kind of "use at > own risk". I'm not sure if that was popular or the best way to go > about it. Possibly just adding "hotfix" in the mcz file name would > provide enough to find them by filtering. > > cheers -ben > > On Thu, Jun 11, 2015 at 2:47 AM, Paul DeBruicker <pdebruic(a)gmail.com> > wrote: > > Hi > > > > I've hacked together an implementation of format on accept & display. > > > > > > I know someone is redoing that functionality to better suit future needs. > > > > > > Should I publish what I've got as a slice to the Pharo40Inbox for people > to use that may miss it now that do not want to wait for the new hotness? > > > > > > > > Thanks > > > > > > Paul > >

June 11, 2015

Re: [Pharo-dev] Probably Metacello sucksâ¦

by Yuriy Tymchuk

Once Stef mentioned that there is some project for dependency checking. What was it? Maybe we can use that? Uko > On 31 May 2015, at 19:42, Stephan Eggermont <stephan(a)stack.nl> wrote: > > It is not going to get much easier than Metacello. > Referring to #stable should probably stop, at least for > configurations that are being developed or use > dependencies that are being developed. > And we need better tool support for groups. > Configuration Management is never going to be easy. > > The Woden script looks broken, it depends on a > numbered version of a dependency. > > Stable version of NBOpenGL is 3.1, not 3.0 > That depends on version 3.0 of NBXLib > NBXLib defines no symbolic versions > OSWindow stable refers to NBXLib-Core-RonieSalgado.13 that doesn't > exist in PharoExtras/NBOpenGL > > Looks like a good moment to draw some dependency diagrams > > Stephan > >

June 11, 2015

Re: [Pharo-dev] Pharo 4, format on accept/display

by Ben Coman

By "publish a slice" do you also mean to ask it to be integrated into Pharo4? The general issue is that every new fix for the released Pharo40 has the *chance* of introducing some other problem, or adversely affecting someone else's idea of how the system should operate. Even with minimal quaility assurance for a release it takes effort to integrate fixes, so each needs to be evaluated for impact. So the options for Pharo 4 are: 1. Continually integrate fixes as they arise ==> ++effort 2. Continually integrate critical fixes only, hold all others for the next point release. 3. Hold all fixes for next point release. I don't see this as a critical fix :), so you'd be asking for (1.), when probably (2.) should be the rule. Now I had the idea that fixes for a release that were not immediately integrated might be published as a "hotfix" - taking Microsoft's terminology for an update fixing a specific issue without having gone through full quality control with all other fixes, so kind of "use at own risk". I'm not sure if that was popular or the best way to go about it. Possibly just adding "hotfix" in the mcz file name would provide enough to find them by filtering. cheers -ben On Thu, Jun 11, 2015 at 2:47 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Hi > > I've hacked together an implementation of format on accept & display. > > > I know someone is redoing that functionality to better suit future needs. > > > Should I publish what I've got as a slice to the Pharo40Inbox for people to use that may miss it now that do not want to wait for the new hotness? > > > > Thanks > > > Paul

June 11, 2015

Re: [Pharo-dev] Detecting the context/producer of code change announcements

by Chris Cunningham

On Wed, Jun 10, 2015 at 11:29 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 10 Jun 2015, at 17:13, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi everybody, > > <snip> > > The other thing would be to clean up the announcer situationâ¦ Maybe the > announcers should be hierarchical, not the announcements. Doru did a > presentation at ESUG about an idea for a logging framework that uses > announcements by using different announcers for different levels of > interest (https://youtu.be/keqdqFu1ejk?t=10m55s) That way, if youâre > interested in what MC does in the abyss of MC hell you can subscribe to the > MCAbyssAnnouncer, if you want high level change events you subscribe to the > MCInterestingChangeAnnouncer. > > I'm not sure how the hierarchical announcers would help Ben's issue (as I see it). I would think the logging would like to know that an MC install is happening, and log the MC install (and parameters, probably - like what was decided on a MERGE), and then ignore all of the actual class/method/doit's that come out of that load. EXCEPT, of course, and Syntax fixes done by the users during that load - those would want to be caught as non-MC derived. And a nice playback would be constructed to automatically apply them next time. (Wish list....) If you have two announcers, you'd need to detect the beginning of the MC install, and ignore the class/method announcements until you get the end of the MC install. And you'd have to make sure the MC install always signals an end - else you could ignore all manual changes afterwards. And, if the user could be saving other code while the MC is loading, you'd loose those changes - since you are ignoring them. That said, I'm unclear on how you'd signal the hiercarchical announcements that Ben mentions. Class/Method announcements not originated by MC would be base change announcements; those originated from MC would be the MCChange Announcement sub-classes + the MC generated announcement (started load, etc). Just thoughts. -cbc > I hope you can make some use of my ramblings (last exam tomorrow, just > taking a break here :) ) > > Cheers, > Max > > > > Kind regards, > MartÃn > > >

June 10, 2015

[pharo-project/pharo-core] 0d0d0a: 50103

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 0d0d0a541b3c43ec1e82666265f38b88b45a2787 https://github.com/pharo-project/pharo-core/commit/0d0d0a541b3c43ec1e826662… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-10 (Wed, 10 Jun 2015) Changed paths: A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/README.md A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/class/accessing/project.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/class/development support/DevelopmentSupport.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/class/development support/validate.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/class/loading/load.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/class/loading/loadBleedingEdge.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/class/loading/loadDevelopment.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/class/metacello tool support/isMetacelloConfig.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/class/private/baseConfigurationClassIfAbsent_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/class/private/ensureMetacello.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/class/private/ensureMetacelloBaseConfiguration.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/definition.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/accessing/customProjectAttributes.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/accessing/project.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/baselines/baseline01_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/baselines/baseline02_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/baselines/baseline03_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/baselines/baseline04_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/development_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/stable_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version011_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version01_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version021_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version02_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version031_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version03_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version04_.st A Files.package/MultiByteFileStream.class/instance/fileIn%2FOut/nextPreamble.st R Kernel.package/Time.class/instance/converting/asTimeStamp.st R Kernel.package/Timespan.class/instance/conversion/asTimeStamp.st A Monticello-Tests.package/MCAnnouncementTest.class/README.md A Monticello-Tests.package/MCAnnouncementTest.class/definition.st A Monticello-Tests.package/MCAnnouncementTest.class/instance/tests/testMCVersionSaved.st M Monticello.package/MCRepository.class/instance/storing/storeVersion_.st R Monticello.package/MCVersionCreated.class/README.md R Monticello.package/MCVersionCreated.class/class/instance creation/name_message_version_.st R Monticello.package/MCVersionCreated.class/class/instance creation/name_nameString_version_.st R Monticello.package/MCVersionCreated.class/definition.st R Monticello.package/MCVersionCreated.class/instance/accessing/nameString.st R Monticello.package/MCVersionCreated.class/instance/accessing/nameString_.st R Monticello.package/MCVersionCreated.class/instance/accessing/version.st R Monticello.package/MCVersionCreated.class/instance/accessing/version_.st A Monticello.package/MCVersionSaved.class/README.md A Monticello.package/MCVersionSaved.class/class/instance creation/version_repository_.st A Monticello.package/MCVersionSaved.class/definition.st A Monticello.package/MCVersionSaved.class/instance/accessing/repository.st A Monticello.package/MCVersionSaved.class/instance/accessing/version.st A Monticello.package/MCVersionSaved.class/instance/comparing/=.st A Monticello.package/MCVersionSaved.class/instance/comparing/hash.st A Monticello.package/MCVersionSaved.class/instance/initialize-release/initializeWithVersion_repository_.st A Monticello.package/MCVersionSaved.class/instance/printing/printOn_.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/instance/initialization/registerToAnnouncer.st M Nautilus.package/AbstractNautilusUI.class/instance/announcement registration/registerToMCAnnouncements.st R Nautilus.package/AbstractNautilusUI.class/instance/monticello announcements/newMCVersion_.st R Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - reifications/testLinkWithMetaArg.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - reifications/testReifyGlobalName.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - reifications/testReifyIvarName.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - reifications/testReifyIvarValue.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - reifications/testReifyMethodSelector.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - reifications/testReifyNode.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - reifications/testReifyObject.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - reifications/testReifySendSelector.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - reifications/testReifySendThisContext.st M Reflectivity-Tests.package/ReflectivityExamples.class/definition.st A Reflectivity-Tests.package/ReflectivityExamples.class/instance/examples/exampleIvarRead.st A Reflectivity-Tests.package/ReflectivityExamples.class/instance/initialization/initialize.st M Reflectivity.package/RFThisContextReification.class/instance/generate/genForRBProgramNode.st M Reflectivity.package/RFValueReification.class/instance/generate/genForRBAssignmentNode.st R Reflectivity.package/RFValueReification.class/instance/generate/genForRBTempVariableNode.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50102.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50103.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50102.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50103.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Changes.package/extension/PositionableStream/instance/nextPreamble.st M System-Sources.package/SourceFileArray.class/instance/source code management/changeRecordsFrom_className_isMeta_do_.st A Tool-Catalog.package/CatalogBrowser.class/README.md A Tool-Catalog.package/CatalogBrowser.class/class/accessing/title.st A Tool-Catalog.package/CatalogBrowser.class/class/showing/open.st A Tool-Catalog.package/CatalogBrowser.class/class/utilities/iconFor_.st A Tool-Catalog.package/CatalogBrowser.class/class/world menu/menuCommandOn_.st A Tool-Catalog.package/CatalogBrowser.class/definition.st A Tool-Catalog.package/CatalogBrowser.class/instance/accessing/provider.st A Tool-Catalog.package/CatalogBrowser.class/instance/actions/installStableVersion_onSuccess_.st A Tool-Catalog.package/CatalogBrowser.class/instance/actions/loadConfiguration_onSuccess_.st A Tool-Catalog.package/CatalogBrowser.class/instance/actions/refresh.st A Tool-Catalog.package/CatalogBrowser.class/instance/building/buildBrowser.st A Tool-Catalog.package/CatalogBrowser.class/instance/private - events/onInstallFrom_.st A Tool-Catalog.package/CatalogBrowser.class/instance/private - events/onLoadFrom_.st A Tool-Catalog.package/CatalogBrowser.class/instance/private - events/onRefreshFrom_.st A Tool-Catalog.package/CatalogBrowser.class/instance/private - utilities/iconFor_.st A Tool-Catalog.package/CatalogBrowser.class/instance/showing/open.st A Tool-Catalog.package/CatalogProject.class/README.md A Tool-Catalog.package/CatalogProject.class/class/accessing/repositoryNames.st A Tool-Catalog.package/CatalogProject.class/class/accessing/unknownRepository.st A Tool-Catalog.package/CatalogProject.class/class/instance creation/fromDictionary_.st A Tool-Catalog.package/CatalogProject.class/class/private/createRepositoryNames.st A Tool-Catalog.package/CatalogProject.class/definition.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/allKeywords.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/contactInfo.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/description.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/fullDescription.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/keywords.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/name.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/packageName.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/repository.st A Tool-Catalog.package/CatalogProject.class/instance/accessing/repositoryUrl.st A Tool-Catalog.package/CatalogProject.class/instance/initialization/fromDictionary_.st A Tool-Catalog.package/CatalogProject.class/instance/installing/installStableVersion.st A Tool-Catalog.package/CatalogProject.class/instance/installing/loadConfiguration.st A Tool-Catalog.package/CatalogProject.class/instance/printing/printOn_.st A Tool-Catalog.package/CatalogProject.class/instance/private/matches_with_.st A Tool-Catalog.package/CatalogProject.class/instance/spotting/spotterPreviewIn_.st A Tool-Catalog.package/CatalogProject.class/instance/testing/isAvailableForCurrentPharo.st A Tool-Catalog.package/CatalogProject.class/instance/testing/matches_.st A Tool-Catalog.package/CatalogProvider.class/README.md A Tool-Catalog.package/CatalogProvider.class/definition.st A Tool-Catalog.package/CatalogProvider.class/instance/accessing/projects.st A Tool-Catalog.package/CatalogProvider.class/instance/accessing/refresh.st A Tool-Catalog.package/CatalogProvider.class/instance/private/loadProjects.st A Tool-Catalog.package/extension/GTSpotter/instance/spotterCatalogProjectsFor_.st A Tool-Catalog.package/extension/ThemeIcons/instance/catalogIcon.st A Tool-Catalog.package/extension/ThemeIcons/instance/catalogIconContents.st A Tool-Catalog.package/extension/ThemeIcons/instance/configIcon.st A Tool-Catalog.package/extension/ThemeIcons/instance/configIconContents.st A Tool-Catalog.package/extension/ThemeIcons/instance/configIconLoaded.st A Tool-Catalog.package/extension/ThemeIcons/instance/configIconLoadedContents.st R Tool-ConfigurationBrowser.package/extension/ThemeIcons/instance/configIcon.st R Tool-ConfigurationBrowser.package/extension/ThemeIcons/instance/configIconContents.st R Tool-ConfigurationBrowser.package/extension/ThemeIcons/instance/configIconLoaded.st R Tool-ConfigurationBrowser.package/extension/ThemeIcons/instance/configIconLoadedContents.st Log Message: ----------- 50103 Tool-ConfigurationBrowser http://files.pharo.org/image/50/50103.zip

June 10, 2015