September 2017 - Pharo-users

Re: [Pharo-users] Pharo 6.0 Generating Ruby-on-Rails Applications

by H. Hirzel

Thank you for sharing, Peter. Good that you 'rediscovered' Smalltalk! Most interesting point of what you write <citation> Ruby-on-Rails, of course, has built-in generators that can create data models, controllers, views, etc. And there are also more sophisticated application generators such as Yeoman. These generators are based on templates and are great as far as they go. Where my Smalltalk approach is different is the level of abstraction. The Smalltalk models are not bound to any particular target language and could just as easily be used to generate PHP Laravel, NodeJS, or Java applications. </citation> This is similar to a Pillar document object model. A object model (an app or a document) may be inspected in the dynamic Smalltalk environment and rendered in different ways. Regards Hannes On 9/1/17, Peter Fisk <peter.fisk(a)gmail.com> wrote: > Hi everyone,The latest version of my "Rails Express" rapid application > development environment is built in Pharo 6.0.Here is a blog post with a > few > screenshots and some explanation. > https://railsexpress.quora.com/Pharo-6-Generating-Ruby-on-Rails-Applications > <https://railsexpress.quora.com/Pharo-6-Generating-Ruby-on-Rails-Applications> > > I mostly programmed in Smalltalk from 1987 until 1997 using ParcPlace > VisualWorks and then IBM VisualAge.Pharo is now better than either of those > two frameworks.Congratulations to the Pharo team for all your great > work!Regards,-- Peter Fisk > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 1, 2017

Pharo 6.0 Generating Ruby-on-Rails Applications

by Peter Fisk

Hi everyone,The latest version of my "Rails Express" rapid application development environment is built in Pharo 6.0.Here is a blog post with a few screenshots and some explanation. https://railsexpress.quora.com/Pharo-6-Generating-Ruby-on-Rails-Applications <https://railsexpress.quora.com/Pharo-6-Generating-Ruby-on-Rails-Applications> I mostly programmed in Smalltalk from 1987 until 1997 using ParcPlace VisualWorks and then IBM VisualAge.Pharo is now better than either of those two frameworks.Congratulations to the Pharo team for all your great work!Regards,-- Peter Fisk -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 1, 2017

Re: [Pharo-users] Usability issues with Calypso

by Stephane Ducasse

Hi KMO thanks for your feedback. Calypso is still an enfant and this is IMPORTANT that people tell what they do not like so that we can improve. Stef On Fri, Sep 1, 2017 at 2:26 PM, kmo <voxkmp(a)gmail.com> wrote: > I have been keen to use Calypso (I love the way it shows inherited methods) > as my browser but I am finding some usability issues. It may be just me but > some things I find off-putting. > > I don't really like the way that adding a new class is done by a new tab > that appears now and then in the editing area. To my mind the Nautilus way > of launching a dialog to create a class seems more natural - and opens the > way in future for a class creation wizard - something that can't be done in > a code window. If we have to do it in a code tab then it would be better if > the tab remained there all the time - I don't like the way it appears and > disappears. It takes a while to learn what to click to do this. > > Also, all class creation presumes a subclass of Object in Calypso. i miss > the ability in Nautilus to select a class and immediately create a subclass > of it. Am I missing something here? Is there a way? > > On the topic of my ignorance - what is a /project /in Calypso? How do you > create one? > > And what does realize do? > > Also I think that the pop up menus could be subdivided into categories > rather than present all the options in an unbroken list. And the order of > options seems odd. To my mind/ senders /and /implementers /are two menu > options that should always go together - not be separated by/ rename/ and > /move to class side/ et cetera. > > Just my two cents. > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Sept. 1, 2017

Re: [Pharo-users] Code mystery

by Richard Sargent

On Fri, Sep 1, 2017 at 11:39 AM, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > But surely all the code critic does is to ask a question â it is actually > displayed with the question mark. In many cases the answer is âYes, it is > OKâ â e.g. if the comment is âExcessive number of methods?â In the case > under discussion, it seems legitimate to ask: âDid you really mean to > declare the argument and then not use it?â The programmer will presumably > know if the complex situation you describe applies here, and then ignore > the message. > I don't know if you are writing as if the code critic does exist and doesn't work as you would wish or doesn't exist. However, from observation, I've concluded that Brant and Roberts tried to avoid too low of signal to noise ratio. They may have never considered this scenario. Obviously, Pharo is free to do as they wish. Feel free to add the missing code critic. As you suggest, you might be able to use the existing Unused Temporary Variable code critic as your basis. (But do create a new one, rather than make the existing one responsible for two different things.) > > Peter Kenny > > > > *From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *On > Behalf Of *Richard Sargent > *Sent:* 01 September 2017 15:04 > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject:* Re: [Pharo-users] Code mystery > > > > I think the answer my lie in the general case and no one tried to address > the complexity of the problem. > > > > Consider an API that's implemented in a number of classes, classes which > may not be in a hierarchy. Let's use #ifNil: as an example. > > > > Some implementers use the argument and others don't, so you cannot > criticise the methods that don't. > > > > It's much more difficult to recognize whether methods with the same name > actually implement the same API or are entirely independent of each other. > > > > That being said, one could quite easily create a criticized for the > special case of a single method, lacking any other implementations, that > doesn't use it's argument. > > > > On Aug 31, 2017 11:55, "PBKResearch" <peter(a)pbkresearch.co.uk> wrote: > > Stef > > Done - https://pharo.fogbugz.com/f/cases/20363/ThemeIcons- > downloadTo-has-an-argument-which-is-never-referenced-in-code > > What really puzzled me is that this situation was not picked up by a code > critic. 'Local variable declared and not referenced' is a common critic > message, and this looks like a parallel situation. But I don't think this > can be called a bug in the code critic system - can it? > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf > Of Stephane Ducasse > Sent: 31 August 2017 19:16 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Code mystery > > Can you open a bug entry? > I can tell you that we clean a lot but human activity will always leads to > glitches. > > On Tue, Aug 29, 2017 at 1:23 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > You are not going crazy that's an ugly method. Probably the author > > intended to use dir and the forgot about it and instead hard coded the > > dir path inside a class method. A mistake that can happen to anyone. > > > > The method will have to be updated anyway because name is to be > > removed, so it won't work. > > > > As always too much code too few people. If you think that's bad > > embrace yourself if you try to read Morphic code. Huge suffering for > > me when I tried to learn how the task bar works and apparently using > > it wrong it freezes the image. > > > > Tons of Pharo code needs a clean but needs also a lot more people. > > On Tue, 29 Aug 2017 at 01:52, PBKResearch <peter(a)pbkresearch.co.uk> > wrote: > >> > >> Hello All > >> > >> > >> > >> Following the discussion on dark mode, I was browsing the code on > >> themes (in Moose 6.1 = Pharo 6.0, Latest update: #60486). In Class > >> ThemeIcons, I found this method: > >> > >> > >> > >> downloadTo: dir > >> > >> | zipArchive | > >> > >> > >> > >> zipArchive := self class destinationPath / (self name, > >> '.zip'). > >> > >> zipArchive exists > >> > >> ifFalse: [ > >> > >> ZnClient new > >> > >> url: self > >> url; > >> > >> downloadTo: > >> zipArchive ]. > >> > >> > >> > >> ^ zipArchive > >> > >> > >> > >> The mystery is that the argument dir is not referred to anywhere in > >> the code. It probably works, because the only invocation of the > >> method is from > >> ThemeIcons>>downloadFromUrl, which sets the argument from self class > >> destinationPath, and the code above recreates this as the path to > >> zipArchive. > >> > >> > >> > >> I thought I understood Smalltalk coding fairly well, but this really > >> puzzles me. Why would anyone code like this? Shouldnât it be picked > >> up by a code critic? Or am I going crazy? > >> > >> > >> > >> Any help gratefully received > >> > >> > >> > >> Peter Kenny > >

Sept. 1, 2017

Re: [Pharo-users] Code mystery

by PBKResearch

But surely all the code critic does is to ask a question â it is actually displayed with the question mark. In many cases the answer is âYes, it is OKâ â e.g. if the comment is âExcessive number of methods?â In the case under discussion, it seems legitimate to ask: âDid you really mean to declare the argument and then not use it?â The programmer will presumably know if the complex situation you describe applies here, and then ignore the message. Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Richard Sargent Sent: 01 September 2017 15:04 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Code mystery I think the answer my lie in the general case and no one tried to address the complexity of the problem. Consider an API that's implemented in a number of classes, classes which may not be in a hierarchy. Let's use #ifNil: as an example. Some implementers use the argument and others don't, so you cannot criticise the methods that don't. It's much more difficult to recognize whether methods with the same name actually implement the same API or are entirely independent of each other. That being said, one could quite easily create a criticized for the special case of a single method, lacking any other implementations, that doesn't use it's argument. On Aug 31, 2017 11:55, "PBKResearch" <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk> > wrote: Stef Done - https://pharo.fogbugz.com/f/cases/20363/ThemeIcons-downloadTo-has-an-argume… What really puzzled me is that this situation was not picked up by a code critic. 'Local variable declared and not referenced' is a common critic message, and this looks like a parallel situation. But I don't think this can be called a bug in the code critic system - can it? Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> ] On Behalf Of Stephane Ducasse Sent: 31 August 2017 19:16 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Subject: Re: [Pharo-users] Code mystery Can you open a bug entry? I can tell you that we clean a lot but human activity will always leads to glitches. On Tue, Aug 29, 2017 at 1:23 AM, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com> > wrote: > You are not going crazy that's an ugly method. Probably the author > intended to use dir and the forgot about it and instead hard coded the > dir path inside a class method. A mistake that can happen to anyone. > > The method will have to be updated anyway because name is to be > removed, so it won't work. > > As always too much code too few people. If you think that's bad > embrace yourself if you try to read Morphic code. Huge suffering for > me when I tried to learn how the task bar works and apparently using > it wrong it freezes the image. > > Tons of Pharo code needs a clean but needs also a lot more people. > On Tue, 29 Aug 2017 at 01:52, PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk> > wrote: >> >> Hello All >> >> >> >> Following the discussion on dark mode, I was browsing the code on >> themes (in Moose 6.1 = Pharo 6.0, Latest update: #60486). In Class >> ThemeIcons, I found this method: >> >> >> >> downloadTo: dir >> >> | zipArchive | >> >> >> >> zipArchive := self class destinationPath / (self name, >> '.zip'). >> >> zipArchive exists >> >> ifFalse: [ >> >> ZnClient new >> >> url: self >> url; >> >> downloadTo: >> zipArchive ]. >> >> >> >> ^ zipArchive >> >> >> >> The mystery is that the argument dir is not referred to anywhere in >> the code. It probably works, because the only invocation of the >> method is from >> ThemeIcons>>downloadFromUrl, which sets the argument from self class >> destinationPath, and the code above recreates this as the path to >> zipArchive. >> >> >> >> I thought I understood Smalltalk coding fairly well, but this really >> puzzles me. Why would anyone code like this? Shouldnât it be picked >> up by a code critic? Or am I going crazy? >> >> >> >> Any help gratefully received >> >> >> >> Peter Kenny

Sept. 1, 2017

Re: [Pharo-users] Code mystery

by Richard Sargent

I think the answer my lie in the general case and no one tried to address the complexity of the problem. Consider an API that's implemented in a number of classes, classes which may not be in a hierarchy. Let's use #ifNil: as an example. Some implementers use the argument and others don't, so you cannot criticise the methods that don't. It's much more difficult to recognize whether methods with the same name actually implement the same API or are entirely independent of each other. That being said, one could quite easily create a criticized for the special case of a single method, lacking any other implementations, that doesn't use it's argument. On Aug 31, 2017 11:55, "PBKResearch" <peter(a)pbkresearch.co.uk> wrote: > Stef > > Done - https://pharo.fogbugz.com/f/cases/20363/ThemeIcons- > downloadTo-has-an-argument-which-is-never-referenced-in-code > > What really puzzled me is that this situation was not picked up by a code > critic. 'Local variable declared and not referenced' is a common critic > message, and this looks like a parallel situation. But I don't think this > can be called a bug in the code critic system - can it? > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf > Of Stephane Ducasse > Sent: 31 August 2017 19:16 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Code mystery > > Can you open a bug entry? > I can tell you that we clean a lot but human activity will always leads to > glitches. > > On Tue, Aug 29, 2017 at 1:23 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > You are not going crazy that's an ugly method. Probably the author > > intended to use dir and the forgot about it and instead hard coded the > > dir path inside a class method. A mistake that can happen to anyone. > > > > The method will have to be updated anyway because name is to be > > removed, so it won't work. > > > > As always too much code too few people. If you think that's bad > > embrace yourself if you try to read Morphic code. Huge suffering for > > me when I tried to learn how the task bar works and apparently using > > it wrong it freezes the image. > > > > Tons of Pharo code needs a clean but needs also a lot more people. > > On Tue, 29 Aug 2017 at 01:52, PBKResearch <peter(a)pbkresearch.co.uk> > wrote: > >> > >> Hello All > >> > >> > >> > >> Following the discussion on dark mode, I was browsing the code on > >> themes (in Moose 6.1 = Pharo 6.0, Latest update: #60486). In Class > >> ThemeIcons, I found this method: > >> > >> > >> > >> downloadTo: dir > >> > >> | zipArchive | > >> > >> > >> > >> zipArchive := self class destinationPath / (self name, > >> '.zip'). > >> > >> zipArchive exists > >> > >> ifFalse: [ > >> > >> ZnClient new > >> > >> url: self > >> url; > >> > >> downloadTo: > >> zipArchive ]. > >> > >> > >> > >> ^ zipArchive > >> > >> > >> > >> The mystery is that the argument dir is not referred to anywhere in > >> the code. It probably works, because the only invocation of the > >> method is from > >> ThemeIcons>>downloadFromUrl, which sets the argument from self class > >> destinationPath, and the code above recreates this as the path to > >> zipArchive. > >> > >> > >> > >> I thought I understood Smalltalk coding fairly well, but this really > >> puzzles me. Why would anyone code like this? Shouldnât it be picked > >> up by a code critic? Or am I going crazy? > >> > >> > >> > >> Any help gratefully received > >> > >> > >> > >> Peter Kenny > > >

Sept. 1, 2017

Usability issues with Calypso

by kmo

I have been keen to use Calypso (I love the way it shows inherited methods) as my browser but I am finding some usability issues. It may be just me but some things I find off-putting. I don't really like the way that adding a new class is done by a new tab that appears now and then in the editing area. To my mind the Nautilus way of launching a dialog to create a class seems more natural - and opens the way in future for a class creation wizard - something that can't be done in a code window. If we have to do it in a code tab then it would be better if the tab remained there all the time - I don't like the way it appears and disappears. It takes a while to learn what to click to do this. Also, all class creation presumes a subclass of Object in Calypso. i miss the ability in Nautilus to select a class and immediately create a subclass of it. Am I missing something here? Is there a way? On the topic of my ignorance - what is a /project /in Calypso? How do you create one? And what does realize do? Also I think that the pop up menus could be subdivided into categories rather than present all the options in an unbroken list. And the order of options seems odd. To my mind/ senders /and /implementers /are two menu options that should always go together - not be separated by/ rename/ and /move to class side/ et cetera. Just my two cents. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 1, 2017

Re: [Pharo-users] #parseMethod:onError: isn't as obvious as expected - is it me?

by Tim Mackinnon

Thanks Thierry - this is proving an interesting problem domain ... I too am using #bestNodeFor: although I don't find it always gives the best node (it does if you are clearly in the target range, but if you are on the outer boundary like the next position after a selector or next to a "." or ";" it favours the parent and not the closest node. So in usage I find I need to tweak it a bit. I'll look at smacc though - also there is that experimental setting to allow parse errors, I don't know if it helps in any way. All this said, I think I have a workable suggestion that is not much code that might be open to scrutiny from those wiser than me. Looking at the keyboard handling in the system - it's quite sprawling and tricky to follow. I think there is lots of room for refactoring. I'm also not sure if I like the pragma usage either - I find it quite difficult to follow what's calling what. Tim Sent from my iPhone > On 1 Sep 2017, at 09:18, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Tim, > > The RB ast has a specific method for finding the right node: in AltBrowser, I use ast bestNodeFor: aTarget selectionInterval. > > For the second case (parse what is selected), you may want to look into SmaCC: it has specific entry points (used for refactoring) to try all possible starts in a parser for a given piece of text and returning all the possible correct asts. As a hand-writen parser, the RBParser can't do that unless you add the necessary entry points by hand and hack around the error handling, because most of the parse attempts end on an error (as they should). > > Regards, > > Thierry > > 2017-09-01 8:50 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >> Marcus - I'd be interested in how you thought to solve this. >> >> My solution seems to work - but it's not the most elegant. Retrying lots of different ways like I show, smacks a bit of desperation (this said, it is quite compact). >> >> Apart from that - I was actually interested in thoughts on the parse method - the onError naming is a bit misleading compared to other methods in the image. I wonder if it should be called something like "onErrorMerge:" to signal that it's going to reuse the results? >> >> Stef - with regards to broken source, my proposed solution reuses what is already there - thus if you highlight specific code, it reverts to the original strategy and tries to compile just that code. This bugs me however - so if you highlight nothing, it tries to compile the source multiple ways, I drop down to chopping the source up to where your cursor is - which seems like a decent cheap strategy. >> >> I don't know if our parser is able to recover from simple errors and just have error nodes in the ast, and whether the #bestNodeFor method then ignored error nodes... this is what I think Dolphin used to do. >> >> Tim >> >> Sent from my iPhone >> >> > On 31 Aug 2017, at 19:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> > >> > >> >> On 31 Aug 2017, at 19:07, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> >> >> On Wed, Aug 30, 2017 at 9:50 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> >>> Iâm looking for some feedback on the usage of RBParser>>#parseMethod:onError:. >> >>> >> >>> I am looking at ways of improving the way we edit code - and making things work (as least for me - but maybe for everyone) a bit more like IntelliJ where they have some great code operations and very good keyboard support. We are certainly close, but at times feel a bit clumsy - which is a shame as we have far better infrastructure to support equivalent features. So I thought I would have a go. >> >> >> >> Excellent!!! >> >> >> >> >> >>> Anyway - step one (which I think Iâve come close on), was to teach senders/implementors to look at the AST so you donât have to highlight exactly what you want to search on - instead it can infer from your cursorâ¦ however my next step was to improve how we can select code to ease refactoring, bracketing etcâ¦ >> >> >> >> Yes but we have to handle broken code then. >> >> Did you check how smart suggestions did it for code that compiled? >> >> >> > >> > I looked some weeks ago and made some notes what to doâ¦ but I fear this has to wait for next week, >> > there is no way that I can do anything till ESUGâ¦ >> > >> > Marcus >> >> >

Sept. 1, 2017

Re: [Pharo-users] [Pillar][editor][Pharo 6.1] How do I get to work 'Transform code snippets to new format'?

by Tudor Girba

Hi, Indeed, this depends on PetitIslands. But, anyway, this feature was a transformation for migrating old Pier line-based sources (starting with =) to newer Pillar-based one (with [[[ ]]]). I will remove this feature because it is not really needed anymore. Cheers, Doru > On Sep 1, 2017, at 12:00 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > Hello > > In a pristine Pharo 6.0/6.1 image I installed Pillar [1]. The editor > for Pillar code works fine. It includes a menu entry > > 'Transform code snippets to new format' > > If I choose this entry a debug window appears [2]. It seems that I > need to install an additional package. > > Which one and how do I do that? > > Thank you in advance > > Hannes > > > > > > > > > > [1] Not through the catalog but with > > Metacello new > smalltalkhubUser: 'Pier' project: 'Pillar'; > configuration: 'Pillar'; > version: #stable; > load. > > This version comes with a Pillar editor. > The version in the catalog seems to be older and does not contain a > Pillar editor. > > > > [2] PPActionParser(Object)>>doesNotUnderstand: #island > GTOldCodeSnippet>>start > [ :class :parser | > parser setParser: (parser perform: parser children first name). > parser productionNames > keysAndValuesDo: > [ :key :value | (parser instVarAt: key) setParser: (parser perform: > value) ] ] in GTOldCodeSnippet class(PPCompositeParser > class)>>newStartingAt: > [ :assoc | aBlock value: assoc key value: assoc value ] in > IdentityDictionary(Dictionary)>>keysAndValuesDo: > [ :each | each ifNotNil: [ aBlock value: each ] ] in > IdentityDictionary(Dictionary)>>associationsDo: > Array(SequenceableCollection)>>do: > IdentityDictionary(Dictionary)>>associationsDo: > IdentityDictionary(Dictionary)>>keysAndValuesDo: > GTOldCodeSnippet class(PPCompositeParser class)>>newStartingAt: > GTOldCodeSnippet class(PPCompositeParser class)>>new > [ :rub | > | newContents | > newContents := GTOldCodeSnippet new parse: self contents. > self > ensureDelete; > writeStreamDo: [ :s | s nextPutAll: newContents ]. > rub update ] in FileReference>>gtInspectorPillarIn: > BlockClosure>>glamourValueWithArgs: > GLMGenericAction(GLMAction)>>actOn: > GLMGenericAction(GLMAction)>>morphicActOn: > [ | selArgCount | > "show cursor in case item opens a new MVC window" > (selArgCount := selector numArgs) = 0 > ifTrue: [ target perform: selector ] > ifFalse: [ selArgCount = arguments size > ifTrue: [ target perform: selector withArguments: arguments ] > ifFalse: [ target perform: selector withArguments: (arguments > copyWith: evt) ]. > self showShortcut ]. > self changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > BlockClosure>>ensure: > CursorWithMask(Cursor)>>showWhile: > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: > .... > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

Sept. 1, 2017

[Pillar][editor][Pharo 6.1] How do I get to work 'Transform code snippets to new format'?

by H. Hirzel

Hello In a pristine Pharo 6.0/6.1 image I installed Pillar [1]. The editor for Pillar code works fine. It includes a menu entry 'Transform code snippets to new format' If I choose this entry a debug window appears [2]. It seems that I need to install an additional package. Which one and how do I do that? Thank you in advance Hannes [1] Not through the catalog but with Metacello new smalltalkhubUser: 'Pier' project: 'Pillar'; configuration: 'Pillar'; version: #stable; load. This version comes with a Pillar editor. The version in the catalog seems to be older and does not contain a Pillar editor. [2] PPActionParser(Object)>>doesNotUnderstand: #island GTOldCodeSnippet>>start [ :class :parser | parser setParser: (parser perform: parser children first name). parser productionNames keysAndValuesDo: [ :key :value | (parser instVarAt: key) setParser: (parser perform: value) ] ] in GTOldCodeSnippet class(PPCompositeParser class)>>newStartingAt: [ :assoc | aBlock value: assoc key value: assoc value ] in IdentityDictionary(Dictionary)>>keysAndValuesDo: [ :each | each ifNotNil: [ aBlock value: each ] ] in IdentityDictionary(Dictionary)>>associationsDo: Array(SequenceableCollection)>>do: IdentityDictionary(Dictionary)>>associationsDo: IdentityDictionary(Dictionary)>>keysAndValuesDo: GTOldCodeSnippet class(PPCompositeParser class)>>newStartingAt: GTOldCodeSnippet class(PPCompositeParser class)>>new [ :rub | | newContents | newContents := GTOldCodeSnippet new parse: self contents. self ensureDelete; writeStreamDo: [ :s | s nextPutAll: newContents ]. rub update ] in FileReference>>gtInspectorPillarIn: BlockClosure>>glamourValueWithArgs: GLMGenericAction(GLMAction)>>actOn: GLMGenericAction(GLMAction)>>morphicActOn: [ | selArgCount | "show cursor in case item opens a new MVC window" (selArgCount := selector numArgs) = 0 ifTrue: [ target perform: selector ] ifFalse: [ selArgCount = arguments size ifTrue: [ target perform: selector withArguments: arguments ] ifFalse: [ target perform: selector withArguments: (arguments copyWith: evt) ]. self showShortcut ]. self changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: ....

Sept. 1, 2017