- Pharo-dev - lists.pharo.org

[Ann] Phratch 4.1 is here !

by jannik laval

Based on Phratch 4.0 we made some bug fixes and added new small features. Phratch is now on top of Pharo 4.0. The new features are: - languages are more stable. Thanks to the community for the feedback and the enhancement of the language files. - Add a "follow" option that allows one to see which block is currently executed. Phratch 4.1 is already available on phratch.com. If you detect an issue, you can submit a description on https://github.com/janniklaval/phratch/issues And you can always download the latest build on the continuous integration server: https://ci.inria.fr/pharo-contribution/view/Phratch/ See you on phratch.com -- ~~Jannik Laval~~ Enseignant-chercheur IUT LumiÃ¨re <http://iut.univ-lyon2.fr/>, UniversitÃ© Lyon LumiÃ¨re <http://www.univ-lyon2.fr/> laboratoire DISP <http://disp-lab.fr/> http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info

Sept. 16, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 16, 2015

[pharo-project/pharo-core] 313e4a: 50327

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 313e4a2da2d22b03bcd18e80acf64a1692cc0250 https://github.com/pharo-project/pharo-core/commit/313e4a2da2d22b03bcd18e80… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-16 (Wed, 16 Sep 2015) Changed paths: M Announcements-Tests-Core.package/AnnouncerTest.class/instance/testing/testSubscribeSend.st M Announcements-Tests-Core.package/AnnouncerTest.class/instance/testing/testUnsubscribeSend.st M Announcements-Tests-Core.package/WeakAnnouncerTest.class/instance/testing/testWeakObject.st M Nautilus.package/AbstractNautilusUI.class/instance/build ui text/buildNewCommentText.st M Nautilus.package/AbstractNautilusUI.class/instance/build ui/addAll_.st M Nautilus.package/NautilusAnnotationDisplayer.class/instance/submorphs-accessing/noteNewOwner_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50326.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50327.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50326.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50327.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/TabManagerModel.class/instance/api/addTab_.st M Spec-Core.package/TabManagerModel.class/instance/private/basicRemoveTab_.st M Spec-Core.package/TabModel.class/README.md M Spec-Core.package/TabModel.class/instance/api/model_.st A Spec-Tests.package/TabManagerModelTest.class/README.md A Spec-Tests.package/TabManagerModelTest.class/definition.st A Spec-Tests.package/TabManagerModelTest.class/instance/running/setUp.st A Spec-Tests.package/TabManagerModelTest.class/instance/running/tearDown.st A Spec-Tests.package/TabManagerModelTest.class/instance/tabs creation/redMorphTab.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testAddTabOpened.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testAddTabSetOwner.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testAddTabUnopened.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testInitialSelectedTab.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testRemoveTab.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testRemoveTabFromManager.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testRemoveTabFromManager2.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testRemoveTabFromMorphic.st A Spec-Tests.package/TabManagerModelTest.class/instance/tests/testRemoveTabUnsetOwner.st A Spec-Tests.package/TabManagerModelTest.class/instance/utility/morphicTabsFor_.st R Spec-Tests.package/TabModelTest.class/instance/tests/testAddTabOpened.st R Spec-Tests.package/TabModelTest.class/instance/tests/testAddTabUnopened.st R Spec-Tests.package/TabModelTest.class/instance/tests/testInitialSelectedTab.st R Spec-Tests.package/TabModelTest.class/instance/tests/testRemoveTab.st R Spec-Tests.package/TabModelTest.class/instance/tests/testRemoveTabFromManager.st R Spec-Tests.package/TabModelTest.class/instance/tests/testRemoveTabFromManager2.st R Spec-Tests.package/TabModelTest.class/instance/tests/testRemoveTabFromMorphic.st A Spec-Tests.package/TabModelTest.class/instance/tests/testSetOwner.st R Spec-Tests.package/TabModelTest.class/instance/utility/morphicTabsFor_.st M Tool-FileList.package/FileList.class/instance/user interface/morphicFileContentsPane.st M Tool-Workspace.package/Workspace.class/instance/view/textView.st Log Message: ----------- 50327 16500 Remove senders of subscribe:send:to: in the image https://pharo.fogbugz.com/f/cases/16500 16564 Remove senders of Announcer>>#subscribe:send:to: in Tool-Workspace https://pharo.fogbugz.com/f/cases/16564 16562 Remove senders of Announcer>>#subscribe:send:to: in Tool-FileList https://pharo.fogbugz.com/f/cases/16562 16553 TabModel/TabModelManager are not setting owner: https://pharo.fogbugz.com/f/cases/16553 http://files.pharo.org/image/50/50327.zip

Sept. 16, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Thierry Goubier

Nicolai, can you try with the RBParser directly? I believe Opal uses the RBParser. RBParser parseMethod: 'createRedMorph ^ (self new color:Color red); yourself' Oh, RBParser sees it as: self new color: Color red; yourself :) Thierry 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > The following method compiles with Opal: > > createRedMorph > ^ (self new color:Color red); yourself > > but gives a syntax error with the old compilers parser > > createRedMorph > ^ (self new color:Color red)End of block expected -> ; yourself > > > removing the parenthesis of course works for both. > Who is right ? > > > (for those who understand the ParseTreeSearcher syntax, how would > a search expression look, for finding code like: > > "(some expression);yourself" > > > nicolai > >

Sept. 16, 2015

Re: [Pharo-dev] System-Announcements: add a ProtocolRenamed announcement

by Thierry Goubier

2015-09-16 11:05 GMT+02:00 Skip Lentz <skip.lentz(a)inria.fr>: ... > > One more thing. I hope that when renaming the protocol, the relevant > MethodRecategorized are sent, because many things depend on that one. > > > Yes, those are already sent. ProtocolRenamed, if implemented, should be > announced in addition to those. > > I need to check AltBrowser behavior on this one. Renaming a protocol is > not what I expected. It looks harmless, but it has important consequences > if the protocol is an extension or an override. > > > Alright, let me know. > I think you can go forward. If the MethodRecategorized is sent, then it should be OK. > > > >> >> Thanks for your reply :) >> >> PS: Thereâs something else related to System-Announcements, namely that >> when I rename a category I get no CategoryRenamed announcement. >> I will send an e-mail about that later. >> > > Hum, SystemOrganizer>>#renameCategory:toBe: sends it (in Pharo4). > > > Indeed it does, but RPackageTag>>#renameTo:category: suspends the > SystemAnnouncer while it sends SystemOrganizer>>#renameCategory:toBe:. > I donât know why, Iâm interested to know. Because > RPackageTag>>#renameTo:category: is used when you rename a category (in > Nautilus, at least). > I would heed Esteban advice on that. If the system announcer is suspended, then this is probably because we may have some kind of infinite loop and / or a incoherent state while renaming the system category. I'll have a look too. Thierry > > Skip >

Sept. 16, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Sven Van Caekenberghe

Interesting. I think that for a cascade you need more than one message send. > On 16 Sep 2015, at 10:56, Nicolai Hess <nicolaihess(a)web.de> wrote: > > The following method compiles with Opal: > > createRedMorph > ^ (self new color:Color red); yourself > > but gives a syntax error with the old compilers parser > > createRedMorph > ^ (self new color:Color red)End of block expected -> ; yourself > > > removing the parenthesis of course works for both. > Who is right ? > > > (for those who understand the ParseTreeSearcher syntax, how would > a search expression look, for finding code like: > > "(some expression);yourself" > > > nicolai >

Sept. 16, 2015

Re: [Pharo-dev] System-Announcements: add a ProtocolRenamed announcement

by Skip Lentz

> On Sep 16, 2015, at 10:36 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-09-16 10:18 GMT+02:00 Skip Lentz <skip.lentz(a)inria.fr <mailto:skip.lentz@inria.fr>>: > > As far as I know, you canât compare to the old class organization because it is already changed to the new one.. > > Yes but: the receiver of the announcement may have a copy of the old one. For example, when AltBrowser receives that, it clears its current knowledge of the class organisation and rebuilts it. Ah yes, that way it is possible. > > > > I'm not sure your ProtocolRenamed solves that. > > While it may not solve the problem of ClassReorganized lacking information, it does give extra information as to what happened. Right now you simply donât know when a protocol was renamed. > > Because, up to know, we managed by either: rebuilding what depends on the organisation, or use it for something else. > > For example, usually in Smalltalk, protocols are ordered and a user may reorder them by hand -> ClassReorganized. Nautilus takes a different view (order alphabetically, add a all protocol), hence Pharo protocols have integrated the Nautilus viewpoint (the 'all' protocol), and AltBrowser disregard this (the 'all' protocol and the ordering) because I prefer a different way of ordering. > > > > But it won't do much harm... Unless Nautilus overeacts and refresh itself 20 times, that it :) > > If Nautilus does not subscribe to ProtocolRenamed then nothing happens, no? > I am willing to create an issue, propose a slice, etc. > > One more thing. I hope that when renaming the protocol, the relevant MethodRecategorized are sent, because many things depend on that one. Yes, those are already sent. ProtocolRenamed, if implemented, should be announced in addition to those. > I need to check AltBrowser behavior on this one. Renaming a protocol is not what I expected. It looks harmless, but it has important consequences if the protocol is an extension or an override. Alright, let me know. > > > Thanks for your reply :) > > PS: Thereâs something else related to System-Announcements, namely that when I rename a category I get no CategoryRenamed announcement. > I will send an e-mail about that later. > > Hum, SystemOrganizer>>#renameCategory:toBe: sends it (in Pharo4). Indeed it does, but RPackageTag>>#renameTo:category: suspends the SystemAnnouncer while it sends SystemOrganizer>>#renameCategory:toBe:. I donât know why, Iâm interested to know. Because RPackageTag>>#renameTo:category: is used when you rename a category (in Nautilus, at least). Skip

Sept. 16, 2015

SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Nicolai Hess

The following method compiles with Opal: createRedMorph ^ (self new color:Color red); yourself but gives a syntax error with the old compilers parser createRedMorph ^ (self new color:Color red)End of block expected -> ; yourself removing the parenthesis of course works for both. Who is right ? (for those who understand the ParseTreeSearcher syntax, how would a search expression look, for finding code like: "(some expression);yourself" nicolai

Sept. 16, 2015

Reflectivity: Links that de-install themselves (oneShot)

by Marcus Denker

Hi, This is just a one-liner to add to the framework, but that makes it even more fun: One-Shot links. A link now can have the #optionOneShot, which means that it will de-install itself when activated for the first time: link := MetaLink new metaObject: self; options: #(optionOneShot); selector: #tagExec. The full test looks like this: testLinkOneShot | sendNode link | sendNode := (ReflectivityExamples>>#exampleMethod) sendNodes first. link := MetaLink new metaObject: self; options: #(optionOneShot); selector: #tagExec. sendNode link: link. self assert: sendNode hasMetalink. self assert: tag isNil. self assert: (ReflectivityExamples new exampleMethod = 5). self assert: (tag = #yes). self deny: sendNode hasMetalink. tag := nil. self assert: (ReflectivityExamples new exampleMethod = 5). self assert: tag isNil. https://pharo.fogbugz.com/f/cases/16581/one-shot-links Marcus

Sept. 16, 2015

Re: [Pharo-dev] System-Announcements: add a ProtocolRenamed announcement

by Thierry Goubier

2015-09-16 10:18 GMT+02:00 Skip Lentz <skip.lentz(a)inria.fr>: > > > On Sep 15, 2015, at 4:40 PM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Hi Martin, Skip, > > > > it makes sense, sort of. > > > > ClassReorganized could be handled already by just either discarding > whatever cache you would have on the protocols of the class (for example, > in a browser) or comparing the new class organisation with the old one. > > As far as I know, you canât compare to the old class organization because > it is already changed to the new one.. > Yes but: the receiver of the announcement may have a copy of the old one. For example, when AltBrowser receives that, it clears its current knowledge of the class organisation and rebuilts it. > > > You may be pointing to, however, another issue: ClassReorganized not > carrying enough information (i.e. not the old set of protocols). > > Yesâ¦ it only has the class which has been affected. No way to compare it. > This is it. But ClassReorganized can be used for reordering the protocols. > > > I'm not sure your ProtocolRenamed solves that. > > While it may not solve the problem of ClassReorganized lacking > information, it does give extra information as to what happened. Right now > you simply donât know when a protocol was renamed. > Because, up to know, we managed by either: rebuilding what depends on the organisation, or use it for something else. For example, usually in Smalltalk, protocols are ordered and a user may reorder them by hand -> ClassReorganized. Nautilus takes a different view (order alphabetically, add a all protocol), hence Pharo protocols have integrated the Nautilus viewpoint (the 'all' protocol), and AltBrowser disregard this (the 'all' protocol and the ordering) because I prefer a different way of ordering. > > > But it won't do much harm... Unless Nautilus overeacts and refresh > itself 20 times, that it :) > > If Nautilus does not subscribe to ProtocolRenamed then nothing happens, no? > I am willing to create an issue, propose a slice, etc. > One more thing. I hope that when renaming the protocol, the relevant MethodRecategorized are sent, because many things depend on that one. I need to check AltBrowser behavior on this one. Renaming a protocol is not what I expected. It looks harmless, but it has important consequences if the protocol is an extension or an override. > > Thanks for your reply :) > > PS: Thereâs something else related to System-Announcements, namely that > when I rename a category I get no CategoryRenamed announcement. > I will send an e-mail about that later. > Hum, SystemOrganizer>>#renameCategory:toBe: sends it (in Pharo4). Thierry

Sept. 16, 2015