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

fly-by-helph on icons do not work anymore on the catalog

by stepharo

Hi I have the impression that after 16496 Provide context menu icons in Catalog browser https://pharo.fogbugz.com/f/cases/16496 the fly-by-help on the icons in the toolbard does not work anymore and this is really a problem. Stef

Sept. 8, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50313 Home: https://github.com/pharo-project/pharo-core

Sept. 8, 2015

[pharo-project/pharo-core] 13ac63: 50313

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 13ac639a4883cfa47974ac3f74d11dab8d52031f https://github.com/pharo-project/pharo-core/commit/13ac639a4883cfa47974ac3f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-08 (Tue, 08 Sep 2015) Changed paths: A Collections-Streams.package/ManifestCollectionsStreams.class/class/meta-data - dependency analyser/ignoredDependencies.st M Collections-Streams.package/ManifestCollectionsStreams.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st M FileSystem-Core.package/FileReference.class/instance/utility/nextVersion.st M FontChooser.package/FontChooser.class/definition.st R FontChooser.package/FontChooser.class/instance/accessing/announcer.st M Kernel.package/ManifestKernel.class/class/meta-data - dependency analyser/ignoredDependencies.st M MonticelloGUI.package/MCTool.class/definition.st R MonticelloGUI.package/MCTool.class/instance/accessing/announcer.st A MonticelloGUI.package/MCTool.class/instance/utils/interactionModel.st M Morphic-Core.package/WorldState.class/class/world menu items/saveAs.st M Morphic-Widgets-Tree.package/MorphTreeModel.class/definition.st R Morphic-Widgets-Tree.package/MorphTreeModel.class/instance/accessing/announcer.st M PragmaCollector.package/PragmaCollector.class/definition.st R PragmaCollector.package/PragmaCollector.class/instance/accessing/announcer.st M PragmaCollector.package/PragmaCollector.class/instance/initialization/initialize.st A PragmaCollector.package/PragmaCollector.class/instance/initialization/reset.st R PragmaCollector.package/PragmaCollector.class/instance/initializing/reset.st M PragmaCollector.package/PragmaCollector.class/instance/subscription/announce_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50312.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50313.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50312.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50313.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Versionner-Core-DependenciesModel.package/MTProject.class/definition.st R Versionner-Core-DependenciesModel.package/MTProject.class/instance/accessing/announcer.st M Versionner-Core-Model.package/MBConfigurationRoot.class/definition.st R Versionner-Core-Model.package/MBConfigurationRoot.class/instance/accessing/announcer.st R Versionner-Core-Model.package/MBConfigurationRoot.class/instance/initialize-release/initialize.st Log Message: ----------- 50313 16512 "Save As" should increment a version number https://pharo.fogbugz.com/f/cases/16512 16517 Update manifest for the bootstrap https://pharo.fogbugz.com/f/cases/16517 16411 implementors of announcer not subclass of Model should be subclass of Model https://pharo.fogbugz.com/f/cases/16411 http://files.pharo.org/image/50/50313.zip

Sept. 8, 2015

Re: [Pharo-dev] Nautilus strange pattern

by Nicolai Hess

a new one. 2015-09-08 1:50 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > On Tue, Sep 8, 2015 at 5:32 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > We should make sure to unregister to all announcement when the window is > > closed. > > +1. Nautilus seems to leak announcements. Sorry I forgot to log an > issue already for this... > https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg31953.html > > So should I log a new issue now, or do you want to pick it up under > existing work? > > cheers -ben > > > (Or is there any reason or situation in which nautilus can properly work > > after the window is closed?) > > > > 2015-09-06 10:41 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> > >> Hi > >> > >> I'm trying to understand what there is a need for this window ifNil: [^ > >> self ] > >> And I wonder is this is not problem due to a global announcer that > would > >> keep announcer even when the nautilus widget > >> has been deleted. > >> Any other suggestions? > >> > >> Stef > >> > >> classRemoved: anAnnouncement > >> | class oldPackage | > >> window ifNil: [ ^ self ]. > >> window isDisplayed > >> ifFalse: [ ^ self ]. > >> class := anAnnouncement classRemoved. > >> (self classWidget getClassesList includes: class) > >> ifTrue: > >> [ > >> > >> classRecategorized: anAnnouncement > >> > >> window ifNil: [ ^ self ]. > >> window isDisplayed ifFalse: [ ^ self ]. > >> self selectedPackage ifNotNil:[:selection | > >> ({ anAnnouncement oldCategory. anAnnouncement newCategory } > >> anySatisfy: [ :each | selection includesCategory: each ]) > >> ifTrue: [ self updatePackageGroupAndClassList ]] > >> > >> > >> classRemoved: anAnnouncement > >> | class oldPackage | > >> window ifNil: [ ^ self ]. > >> window isDisplayed > >> ifFalse: [ ^ self ]. > >> class := anAnnouncement classRemoved. > >> (self classWidget getClassesList includes: cla > >> > > >

Sept. 8, 2015

Two new help topics

by Alexandre Bergel

Hi! I made two contribution in the Pharo inbox: 16521 - Help topic for contributing to the catalog 16520 - Help topic for how to contribute to Pharo basecode I think they are good candidates for an inclusion in the base image. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 8, 2015

Re: [Pharo-dev] Did no find yet a way to reproduce QA concurrent access

by Yuriy Tymchuk

Iâm happy to get feedback. Just wanted to know that I care about the issues :) > On 07 Sep 2015, at 22:07, stepharo <stepharo(a)free.fr> wrote: > > I'm not complaining. I know that there is a good chance that we break the system when improving it. > I have no problem with that and I prefer a living system with some bugs for a while than a dead system with no bug :) > I'm just trying to help handling this problem. > This is alpha with all the risks. > Stef > > Le 7/9/15 00:46, Yuriy Tymchuk a Ã©crit : >> I think that it is related to how I was working with Nautilus announcements. Now as announcements are changed, I can improve that. Just give me a bit of time :) >> >> Uko >> >>> On 06 Sep 2015, at 22:17, stepharo <stepharo(a)free.fr> wrote: >>> >>> I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method >>> but I failed. >>> I got again this bug. >>> What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. >>> But I cannot reproduce it. >>> >>> Stef >>> >> >> > >

Sept. 8, 2015

Re: [Pharo-dev] WhatsUp from: 2015-09-07 until: 2015-09-20

by phil＠highoctane.be

> > Le 7/9/15 07:00, seaside(a)rmod.lille.inria.fr a Ã©crit : > >> Hi! We're sending this automatic email twice a month, to give the >> community an opportunity to easily know what's happening and to coordinate >> efforts. Just answer informally, and feel free to spawn discussions >> thereafter! >> >> ### Here's what I've been up to since the last WhatsUp: >> > > Provided Cable-eXpertise success story. Continued development of the app, some more elements with DataTables using JQuery. Paid my consortium fee (about time...) > >> ### What's next, until 2015-09-20 (*): >> >> >> Looking for a new development opportunity. Getting into Pharo 4. > >> (*) we'll be expecting results by then ;) >> >> >> > >

Sept. 8, 2015

[ANN] The next Pharo Sprints at Lille

by Marcus Denker

Hello, We looked at the calendar and fixed the dates for all public sprints that we will do this year here locally. These are all Fridays: Sept 11 Oct 23 Nov 27 Dec 18 Here is the invitation for this Friday: âââââââââââââââââââââââ We will organize a Pharo sprint / Moose dojo Friday, 11th September, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on the official IRC channel #pharo on irc.freenode.net server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come.

Sept. 8, 2015

Re: [Pharo-dev] WhatsUp from: 2015-09-07 until: 2015-09-20

by Stephan Eggermont

On 07-09-15 07:00, seaside(a)rmod.lille.inria.fr wrote: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: - a few bugfixes all over the place - a lot of bug entries - improvements to PetitDelphi > ### What's next, until 2015-09-20 (*): Looking at improved/other LayoutPolicies Stephan

Sept. 8, 2015

Re: [Pharo-dev] [Pharo-users] Modifying the AST of a method

by Marcus Denker

> On 08 Sep 2015, at 03:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > From GÃ¼nter Khyo: > > GÃ¼nter Khyo wrote >> Hello! >> >> I want to replace particular nodes of an AST (such as Assignments or Self >> sends) with my own nodes. >> Is there an easy (high-level) way to do this without being familiar with >> the entire compiler infrastructure? >> >> The problem I am having is that AST nodes maintain internal state such as >> parent links and, in the case of RBVariables, links to scopes and >> bindings. There might be many other dependencies I am missing and missing >> one of them can trigger exceptions with stack traces buried deep in the IR >> Code-Generator and visitor calls. >> >> For example, if I want to replace an assignment such as >> >> Morph>>position: aPoint >> >> "box := self fullBounds." >> >> with something like >> >> "self assignAndNotifiyDependents: self fullBounds to: 'box' " >> >> Btw: I know there is a rewrite tool, but I want to do it programmatically. Hello, With Pharo5 there are two mechanism that can help you. 1) MetaLinks (aka reflectivity). ======================= They allow you to reflectively define that a meta object to be called before/after or instead of an AST node. as you want to do something in addition here, you can add the notification as a #before link: link := MetaLink new metaObject: #object; selector: #assignAndNotifiyDependents:; arguments: #(newValue). this is a link that when installed on an AssignmentNode, will call #assignAndNotifiyDependents on the object with the new value (the to be assigned value) as the argument. To install this on all ivar assignments, do: MyClass assignmentNodes do: [ :each | each variable isInstance ifTrue: [each link: link ]]. to get rid of the link: link uninstall But MetaLinks are very hidden: you do not see them in your design. So they should be used with care. 2) First class Instance variable (aka Slots). ================================= In your example, what you really want is a âspecialâ kind of variable that always notifies depends. Wouldnât it be nice if you could define such a special kind of Variable and, in the class definition of you class, specify that the ivar âboxâ is that special kind? In Pharo5, you can do just that. 1) define your special variable. IndexedSlot subclass: #NotifyDependsSlot slots: { } classVariables: { } category: 'Demoâ change what it means to write these kind of variables by implementing: write: aValue to: anObject super write: aValue to: anObject. anObject assignAndNotifiyDependents: aValue. Now change the class definition of your class to make âboxâ into this special kind of variable: Object subclass: #MyClass slots: { #box => NotifyDependsSlot } classVariables: { } category: âDemo' DONE. Ah, but reflective slot write is slow, so if you use this a lot, add these two method: emitValue: methodBuilder methodBuilder pushInstVar: index. emitStore: methodBuilder | tempName | tempName := Object new. methodBuilder addTemp: tempName; storeTemp: tempName; pushReceiver; pushTemp: tempName; send: #assignAndNotifiyDependents:; popTop; storeInstVar: index. These generate byte code inline for the read and write instead of calling the #write:to: method. (I attach a fillout of MyClass that i used to test this)

Sept. 8, 2015