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

[pharo-project/pharo-core] cdf159: 50106

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: cdf1593f415e3d68410dc04b992fb195615bceeb https://github.com/pharo-project/pharo-core/commit/cdf1593f415e3d68410dc04b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-06-11 (Thu, 11 Jun 2015) Changed paths: M ConfigurationCommandLineHandler-Core.package/ConfigurationCommandLineHandler.class/instance/accessing/defaultRepositoryUrl.st M Reflectivity.package/HookGenerator.class/instance/result/preamble.st R Reflectivity.package/RFArg1ReificationNode.class/README.md R Reflectivity.package/RFArg1ReificationNode.class/definition.st R Reflectivity.package/RFArg1ReificationNode.class/instance/visiting/acceptVisitor_.st A Reflectivity.package/RFArgumentsReification.class/instance/generate/genForRBMessageNode.st R Reflectivity.package/RFArgumentsReification.class/instance/generate/genForRBProgramNode.st A Reflectivity.package/RFArgumentsReification.class/instance/generate/preamble_.st A Reflectivity.package/RFEReceiverReification.class/instance/generate/genForRBMessageNode.st A Reflectivity.package/RFEReceiverReification.class/instance/generate/preamble_.st R Reflectivity.package/RFNewValueReification.class/instance/generate/preamble.st A Reflectivity.package/RFNewValueReification.class/instance/generate/preamble_.st A Reflectivity.package/RFReceiverReificationNode.class/README.md A Reflectivity.package/RFReceiverReificationNode.class/definition.st A Reflectivity.package/RFReceiverReificationNode.class/instance/accessing/numargs.st A Reflectivity.package/RFReceiverReificationNode.class/instance/accessing/numargs_.st A Reflectivity.package/RFReceiverReificationNode.class/instance/visiting/acceptVisitor_.st R Reflectivity.package/RFReification.class/instance/as yet unclassified/genForRBTemporaryNode.st A Reflectivity.package/RFReification.class/instance/generate/genForRBTemporaryNode.st R Reflectivity.package/RFReification.class/instance/generate/preamble.st A Reflectivity.package/RFReification.class/instance/generate/preamble_.st A Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/declareVariableNode_.st A Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/visitArgumentsReificationNode_.st A Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/visitReceiverReificationNode_.st A Reflectivity.package/extension/CompiledMethod/instance/blockNodes.st A Reflectivity.package/extension/CompiledMethod/instance/instanceVariableReadNodes.st A Reflectivity.package/extension/CompiledMethod/instance/instanceVariableWriteNodes.st A Reflectivity.package/extension/CompiledMethod/instance/sendNodes.st A Reflectivity.package/extension/CompiledMethod/instance/variableNodes.st A Reflectivity.package/extension/CompiledMethod/instance/variableReadNodes.st A Reflectivity.package/extension/CompiledMethod/instance/variableWriteNodes.st A Reflectivity.package/extension/OCASTTranslator/instance/visitArgumentsReificationNode_.st A Reflectivity.package/extension/OCASTTranslator/instance/visitReceiverReificationNode_.st A Reflectivity.package/extension/RBMethodNode/instance/assignmenNodes.st A Reflectivity.package/extension/RBMethodNode/instance/blockNodes.st A Reflectivity.package/extension/RBMethodNode/instance/instanceVariableReadNodes.st A Reflectivity.package/extension/RBMethodNode/instance/instanceVariableWriteNodes.st A Reflectivity.package/extension/RBMethodNode/instance/sendNodes.st A Reflectivity.package/extension/RBMethodNode/instance/tempVariableReadNodes.st A Reflectivity.package/extension/RBMethodNode/instance/variableNodes.st A Reflectivity.package/extension/RBMethodNode/instance/variableReadNodes.st A Reflectivity.package/extension/RBMethodNode/instance/variableWriteNodes.st A Reflectivity.package/extension/RBVariableNode/instance/isDefinition.st A Reflectivity.package/extension/TClassDescription/instance/blockNodes.st A Reflectivity.package/extension/TClassDescription/instance/instanceVariableReadNodes.st A Reflectivity.package/extension/TClassDescription/instance/instanceVariableWriteNodes.st A Reflectivity.package/extension/TClassDescription/instance/sendNodes.st A Reflectivity.package/extension/TClassDescription/instance/variableNodes.st A Reflectivity.package/extension/TClassDescription/instance/variableReadNodes.st A Reflectivity.package/extension/TClassDescription/instance/variableWriteNodes.st A Reflectivity.package/extension/TClassDescription/instance/variables.st A Reflectivity.package/extension/TRBProgramNodeVisitor/instance/visitArgumentsReificationNode_.st A Reflectivity.package/extension/TRBProgramNodeVisitor/instance/visitReceiverReificationNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50105.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50106.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50105.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50106.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/README.md R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/class/accessing/title.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/class/instance creation/open.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/class/private accessing/configurationSearchList.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/class/registration/menuCommandOn_.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/class/specs/defaultSpec.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/definition.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/accessing/aboutText.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/accessing/configBrowserModel.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/accessing/configurationSearchAccept_.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/accessing/configurationSearchField.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/accessing/toolbarModel.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/actions/installConfiguration.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/actions/loadConfiguration.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/icons/taskbarIcon.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/initialization/initialExtent.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/initialization/initialize.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowser.class/instance/initialization/initializeWidgets.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/README.md R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/accessing/availableRepositories.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/accessing/pharoDistributionRepository.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/accessing/retrieveConfigurationsFrom_.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/accessing/title.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/defaults/defaultAvailableRepositories.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/example/example.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/initialization/reset.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/spec/defaultSpec.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/definition.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/accessing/configurationPattern_.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/accessing/configurations.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/accessing/repository.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/accessing/repository_.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/accessing/selectedConfiguration.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/accessing/selectedConfigurationClass.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/accessing/selectedConfigurationName.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/addRepository.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/browseConfiguration.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/defineAllRepositoriesInMCBrowser.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/defineRepositoryInMCBrowser.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/installConfiguration.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/loadConfiguration.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/refreshRepository.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/repositoryObjectFromURLString_.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/actions/switchRepository.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/initialization/initConfigurationList.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/initialization/initializeWidgets.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/menu/configurationListMenu_.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/private accessing/availableRepositories.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/private accessing/configurationList.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/private accessing/configurationList_.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/private testing/hasSelection.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/private/explicitTitleFromURLString_.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/private/loadConfigurationWithStable_.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/instance/updating/updateList.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/README.md R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/class/specs/defaultSpec.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/definition.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/instance/actions/installConfiguration.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/instance/actions/loadConfiguration.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/instance/initialization/initializeWidgets.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/instance/initialization/installModel.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/instance/initialization/loadModel.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/instance/initialization/setInstallModel.st R Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserToolbar.class/instance/initialization/setLoadModel.st Log Message: ----------- 50106 15745 add API to enumerate AST nodes https://pharo.fogbugz.com/f/cases/15745 15747 cleanup tools to get rid of undeclared https://pharo.fogbugz.com/f/cases/15747 15748 Reflectivity: fixes for reifications https://pharo.fogbugz.com/f/cases/15748 15703 integrate new Catalog Browser https://pharo.fogbugz.com/f/cases/15703 http://files.pharo.org/image/50/50106.zip

June 11, 2015

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

by Thierry Goubier

2015-06-11 16:49 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > Just a *very* divergent thought that I'm not sure is a good idea... > maybe the parent announcement could hold the announcer of its > children. > The problem is then that all tools which are not interested in the parent announcement because they only deal with the low level stuff (system browser, RPackageOrganizer and friends: MessageList, Spotter, Critics browser, Finder, Versionner, Inspector, anything which listen to a code change basically) have to still listen to the parent and, on reception, subscribe to the low-level announcement, and then unsubscribe on the parent end announcement. Another issue is, when introducing a new class of activity such as SprintInRMOD, you then need to rewrite all the listeners to add the relevant: ... on: SprintInRMOD do: [:a | a childAnnouncer on: MethodChange do: ... ] Kind of messy. For me, what Martin is trying to do is currently handled in a way by MC and RB: write all your code operations as abstract operations on a model of the code, group them into a composite (RBCompositeChange or something like that), and apply them all in one go. But all this structure is flattened in the change set, and may be interleaved with other changes happening at the same time. I'd take Martin's job idea :) plus specific announcements for the start and end. Thierry > cheers -ben > > > > > 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 11, 2015

Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0

by Esteban Lorenzano

> On 11 Jun 2015, at 16:42, Ben Coman <btc(a)openInWorld.com> wrote: > > On Thu, Jun 11, 2015 at 2:55 PM, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: >> 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 > > Just had a quick try. Its nice to get descriptions, like for > "TaskIT". However I think there should be a confirmation dialog > before actually loading a Configuration, which is a potentially > destructive/undoable action. Its too easy that habits pressing > <enter> for other functions assert themselves and load a configuration > accidentally. Perhaps an alternative is to open a window with more > information from the other fields of the catalog that has a button to > load the Configuration. > > >> >> 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. > > I don't think its a total replacement for the Configuration Browser. > The new function suits the case of searching for a configuration you > already know about, bu tmany times I like catalog browsers when I'm > not searching for something. That is, when I don't know what is there > and I'm *browsing*. Indeed, if you are searching for a particular > configuration then you probably already know what it is and the > additional info is then not needed. But is a superset. We do not want to keep two tools with same functionality (we already did this a lot in the past, but we are like alcoholics in recovery nowâ¦ :P) Esteban ps: when you already know what you want, most probably you just load through a command line (or a script)â¦ at least thatâs what I do :) > cheers -ben > >> >> 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] Detecting the context/producer of code change announcements

by Ben Coman

On Thu, Jun 11, 2015 at 2: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, > > I'm writing you to discuss about a new feature for Pharo. I would like to > know your opinions and ideas. Thanks in advance. > > My point is that there are operations like "MC version load", "change set > file in", "RB refactoring execution", or "class copy" that produce code > change announcements (e.g. ClassAdded or MethodAdded), but subscribers can't > know that. I mean, a subscriber that listens a ClassAdded can't know if it > is product of a "high-level" operation, or if it was manually performed by > the user in the Nautilus browser. > > I think Pharo should provide a way to detect this information, because it > can be very useful. For example, I can tell you about a tool I work on: > Epicea. Epicea logs code changes while developer works (like traditionally > done with the .changes file), and the user can browse, undo and redo > changes. Now, imagine that your vm crashed and then you want to recover > "lost" changes... you don't want to see hundreds of changes produced by > Monticello when loading packages: in this case, such changes are noise and > make you waste time when selecting what to redo. In Epicea package I have a > workaround for detecting some "high-level" operations, but Epicea would need > support from Pharo for a nice implementation. > > Brainstorming on implementations. > > I think announcements are a good mechanism to implement this feature. A > simple approach is to provide begin and end announcements (e.g. > MCVersionLoadBegin and MCVersionLoadEnd). Then, somebody that subscribes to > such announcements can have a stack or state machine to know the context > where each code change announcement is produced. It would look like: > > MCVersionLoader >> load > ... > SystemAnnouncer uniqueInstance announce: (MCVersionLoadBegin versionName: > ...). > [ ... produce code changes ... ] ensure: [ > SystemAnnouncer uniqueInstance announce: (MCVersionLoadEnd > versionName: ...) ]. > > which may be re-written with a convenience method as: > ... > SystemAnnouncer uniqueInstance > announceBefore: (MCVersionLoadBegin versionName: ...) > announceAfter: (MCVersionLoadEnd versionName: ...) > do: [ ... produce code changes ... ] > > but, going one step further, we could reify the concept of announcement > begin and end like: > ... > announcement := (MCVersionLoad versionName: ...). > SystemAnnouncer uniqueInstance > announceBefore: (AnnouncementBegin of: announcement) > announceAfter: (AnnouncementEnd of: announcement) > do: [ ... produce code changes ... ] > > which could be re-written as: > ... > SystemAnnouncer uniqueInstance > announceBeforeAndAfter: (MCVersionLoad versionName: ...) > do: [ ... produce code changes ... ] > > I think any approach can work, but I'd love to have some feedback. > > > I like the idea. What Iâm afraid of is however, that the dependency between > begin and end announcements is implicit in your examples. The only things > that tell you that they belong together are the convenience implementation > on SystemAnnouncer and the naming. Iâm not familiar enough with > announcements to post example code. > The other thing would maybe be to force subscribers to subscribe to both > announcements (again, not sure how). > My point is, I want to look at one of the announcements and see that I have > to work with a set of announcements. > > Benâs idea of hierarchichal announcements sounds pretty interesting. Maybe > this is too restricting but how about saying: there exists a dependency > between two announcements A and B such that whenever A is being announced, B > has to have been announced before (Iâll leave the implementation to others > :p). > > 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. Just a *very* divergent thought that I'm not sure is a good idea... maybe the parent announcement could hold the announcer of its children. cheers -ben > > 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 11, 2015

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

by Stephan Eggermont

On 11/06/15 07:52, Yuriy Tymchuk wrote: > Once Stef mentioned that there is some project for dependency checking. What was it? Maybe we can use that? What I've done is get all latest versions out of smalltalkhub and collect the signatures that are used. That can provide upper and lower limits of possible versions. Stephan

June 11, 2015

Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0

by Ben Coman

On Thu, Jun 11, 2015 at 2:55 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > 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 Just had a quick try. Its nice to get descriptions, like for "TaskIT". However I think there should be a confirmation dialog before actually loading a Configuration, which is a potentially destructive/undoable action. Its too easy that habits pressing <enter> for other functions assert themselves and load a configuration accidentally. Perhaps an alternative is to open a window with more information from the other fields of the catalog that has a button to load the Configuration. > > 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. I don't think its a total replacement for the Configuration Browser. The new function suits the case of searching for a configuration you already know about, bu tmany times I like catalog browsers when I'm not searching for something. That is, when I don't know what is there and I'm *browsing*. Indeed, if you are searching for a particular configuration then you probably already know what it is and the additional info is then not needed. cheers -ben > > 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 Paul DeBruicker

The 'fix' for Pharo40 is in the Pharo40Inbox as Slice-14387. It formats code on accept and/or display using the RBConfigurableFormatter. Marcus Denker-4 wrote >> On 11 Jun 2015, at 08:16, Peter UhnÃ¡k < > i.uhnak@ > > 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 -- View this message in context: http://forum.world.st/Pharo-4-format-on-accept-display-tp4831485p4831720.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 11, 2015

Pharo PPA doesn't seem to work on ubuntu vivid (15.04)

by Javier PimÃ¡s

Hi there, after adding the ppa to the system I cannot install the vm. Only pharo-launcher is available but it can't be installed because the pharo-vm-core-i386 is not installable. What I tried was this: sudo apt-add-repository ppa:pharo/stable sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install pharo-launcher looking at https://launchpad.net/~pharo/+archive/ubuntu/stable it seems like packages are too old (before 15.04 came out), maybe they need to be updated? cheers, Javier -- Javier PimÃ¡s Ciudad de Buenos Aires

June 11, 2015

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

by Thierry Goubier

Hi Martin, I believe your job example express better what you need, so what I would propose would be a notion of parent in the normal code announcements, containing, in a hierarchical way, the higher level context information. But implementing that parent in the announcements will be difficult, so I'd take either your job solution, or a notification (RequestContextNotification); the notification handler would then be able to provide the context when this notification is signaled (and, of course, this would be hierarchical). A pre/post announcement doesn't work: you cannot guarantee that things happening between those two belongs to this context because it may be done in different processes. Regards, Thierry Le 11 juin 2015 14:05, "Martin Dias" <tinchodias(a)gmail.com> a Ã©crit : > > @Max: I watched the presentation but I'm not sure how to apply it in this case. (Last exam!? good!) > > @Ben: I agree that there are not only 2 levels, high-level and low-level announcements but a hierarchy. For example, a "MCVersionLoad" could have a "MetacelloProjectLoad" as a parent. > > @Chris (and all): Thanks for your feedback. I'm in for any solution that can be implemented fast and be integrated soon in Pharo 5, because I want to use this feature without my workarounds that override the system in a nasty way. > > Before I didn't mention that I considered Job as a possible solution. Job represents a task to run. For example: > > [ :bar | > bar increment. > (Delay forSeconds: 1) wait. > bar increment. > (Delay forSeconds: 1) wait. > ] asJob > title: 'Loading'; > min: 1; > max: 3; > run > > But, additionally to that basic function: > > - Each Job knows its parent. > - Job class implements #current which looks up the next job in the execution stack (using Exception), or nil if none. > > The current (but fixable) limitation of Job is that it only holds a title string, but not a more complex object for describing itself. I mean, when a listener receives a ClassAdded, it could lookup parent jobs for one with a high-level operation associated. > > MCVersionLoader >> load > ... > [ ... produce code changes ... ] asJob > title: 'Loading'; > description: (MCVersionLoad versionName: ...) > run. > > MyListener >> classAdded: > ... > Job lookupParent: [ :job | job description isHighLevelOperation ] > ifPresent: [ ... ] > ifAbsent: [ ... ] > > Regards, > Martin > > > On Wed, Jun 10, 2015 at 11:33 PM, Chris Cunningham < cunningham.cb(a)gmail.com> wrote: >> >> >> 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 11, 2015

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

by Martin Dias

@Max: I watched the presentation but I'm not sure how to apply it in this case. (Last exam!? good!) @Ben: I agree that there are not only 2 levels, high-level and low-level announcements but a hierarchy. For example, a "MCVersionLoad" could have a "MetacelloProjectLoad" as a parent. @Chris (and all): Thanks for your feedback. I'm in for any solution that can be implemented fast and be integrated soon in Pharo 5, because I want to use this feature without my workarounds that override the system in a nasty way. Before I didn't mention that I considered Job as a possible solution. Job represents a task to run. For example: [ :bar | bar increment. (Delay forSeconds: 1) wait. bar increment. (Delay forSeconds: 1) wait. ] asJob title: 'Loading'; min: 1; max: 3; run But, additionally to that basic function: - Each Job knows its parent. - Job class implements #current which looks up the next job in the execution stack (using Exception), or nil if none. The current (but fixable) limitation of Job is that it only holds a title string, but not a more complex object for describing itself. I mean, when a listener receives a ClassAdded, it could lookup parent jobs for one with a high-level operation associated. MCVersionLoader >> load ... [ ... produce code changes ... ] asJob title: 'Loading'; description: (MCVersionLoad versionName: ...) run. MyListener >> classAdded: ... Job lookupParent: [ :job | job description isHighLevelOperation ] ifPresent: [ ... ] ifAbsent: [ ... ] Regards, Martin On Wed, Jun 10, 2015 at 11:33 PM, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > > 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 11, 2015