- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Extending the debugger inspector with a new presentation

by tdupriez＠ens-paris-saclay.fr

I've looked at it, but I can't get to reproduce it. I have trouble finding an entry point to start understanding. Quoting Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > > One possibility is to follow BytecodeDebugger approach. Try to look how it > is implemented > > 2017-05-12 9:53 GMT+02:00 <tdupriez(a)ens-paris-saclay.fr>: > >> Hello, >> >> I would like to extend the debugger with some context-dependent >> information. >> I am playing with metalinks and I would like to show, in the debugger, >> some information if my metalinks are in the selected method. >> This means that: >> - I need to add a new presentation in the debugger next to the "variable" >> and "evaluator" ones. >> - I need to filter that presentation to show it depending on which method >> is selected. >> >> I tried to extend ProtoObject with a method like: >> >> gtDebuggerExpressionMachinViewIn: composite >> <gtDebuggerPresentationOrder: 21> >> >> composite text >> title: 'My machin'; >> display: [ :browser :debugger | debugger asString] >> >> However, this did not add a presentation in the debugger. It only show up >> when selecting an object in the debugger inspector (see screenshot). >> >> How can I extend the debugger as I want? >> >> Thanks >> Thomas and Guille >> >

May 15, 2017

Esteban's ChangeLog week of 8 May 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 8 May 2017 to 14 May 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=8/5/2017&to=14/5/2017 ChangeLog ========= 10 May 2017: ------------ * I removed some remaining overrides on [iceberg](http://github.com/pharo-vcs/iceberg). NOW is ready for integration. I will submit an issue :) 9 May 2017: ----------- * Working for release: I spent some time working on the future [Pharo 7.0 download page](http://pharo.org/STAGE.download). It's still not finished (I need to see how to fix the linux distros), but is almost there. * I prepared [zeroconf](http://get.pharo.org) to serve also Pharo 7.0 images (and prepared it to declare a new stable/latest). This is ready but on hold for the momnent of release. * I fixed [iceberg](http://github.com/pharo-vcs/iceberg) remaining problems, merged +dev-0.4+ to +master+ and verify everything works more or less "as expected". With this, I think iceberg is ready to integration (in Pharo6, not enabled by default, but available anyway). cheers! Esteban

May 15, 2017

Re: [Pharo-dev] Idea of searcheability of Pharo project on git

by Peter Uhnak

Regarding project catalog on github... Rust has something similar there https://github.com/rust-lang/crates.io-index (and Rust's package manager is called Cargo too ;)) Peter On Sun, May 14, 2017 at 03:08:59PM +0200, Esteban Lorenzano wrote: > yes, is something I have in my TODO list for after release :) > > > On 14 May 2017, at 14:22, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Sat, May 13, 2017 at 9:38 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > >> > >>> On 13 May 2017, at 15:04, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > >>> > >>> Steph, > >>> > >>> As Thierry mentions you should create an umbrella project for Pharo where you can maintain a list of projects contributed by users --- something like I've done for GsDevKit_home[1]. > >> > >> there is already an umbrella project for pharo which is âpharo-projectâ. > >> we also promote some othe rmeta projects under the âpharoâ umbrella. > >> > >> pharo-project > >> pharo-graphics > >> pharo-vcs > >> pharo-nosql > >> > >> and probably some others will emerge. > > > > Would it make sense to have... > > pharo-catalog ? > > > > Having this data in STON format on github may make it easier for third > > parties to update missing package descriptions. > > > > cheers -ben > > > >> the reason why we donât concentrate all on one is just organisational, and we could review that on the future. > >> > >>> > >>> I strongly suggest that you use a "project load spec object"[2][3] as the unit of registration for your projects. In addition to the Metacello load instructions the "project load spec" can maintain a bunch of meta data about the project. > >>> > >>> The pharo image can scan the projects listed (similar to what you do with the Category Browser - I think) or better yet, the developer can make a local clone of the project site in a well-known location and then all images can look up projects in this the local clone and avoid having to hit the network to build the project list ... > >>> > >>> Take a look at the video or slides for my "Dangerous Liaisons: Smalltalk, files, and git"[4] for more details ... and of course I'm willing to discuss additional details/ideas over skype or email. > >>> > >>> Dale > >>> > >>> [1] http://gsdevkit.github.io/GsDevKit_home/ > >>> > >>> [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston > >>> > >>> [3] https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston > >>> > >>> [4] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git > >>> > >>> > >>> On 5/13/17 12:01 AM, Stephane Ducasse wrote: > >>>> Hi guys > >>>> > >>>> right now many people publish their software on SmalltalkHUB, SS3 and Squeaksource > >>>> and this is handy to find something. > >>>> > >>>> > >>>> I hope that we will release soon the package repository that christophe was developing but > >>>> now I'm wondering if we as a community should follow a pattern to help? > >>>> > >>>> git freaks do you have suggestions > >>>> > >>>> > >>>> Stef >

May 14, 2017

New booklet available

by Stephane Ducasse

A new booklet is joining the collection and it is on Voyage the object to document mapper developed by E. Lorenzano. Available in beta http://files.pharo.org/books/ and open to contributors at https://github.com/SquareBracketAssociates/Booklet-Voyage Enjoy Stef

May 14, 2017

Re: [Pharo-dev] 10/05/17 - Advancing in Pharo Code Quality Support - Myroslava Romaniuk

by Myroslava Romaniuk

Hey Cyril Sorry I couldn't get back to you earlier. This fixed the problem I was battling for weeks. Thanks very much! Myroslava On 11 May 2017 at 01:34, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Le 10/05/2017 Ã 21:14, Myroslava Romaniuk a Ã©crit : > > A. Work done: > > > > * converted a new rule and updated my git repository > > * read chapters 5 and 6 of the 'Pharo by Example' book > > * started collaborating with my mentors using a Trello board > > > > > > B. Next steps: > > > > * continue reading 'Pharo by Example' > > * update and convert more rules > > * watch more tutorials relating to my project (e.g. matchtool > > tutorial, etc) > > > > > > C. Help required: > > > > * I'm seeing other Pharo members also struggling with the same error > > in iceberg (LGit_GIT_ERROR: error authenticating: failed connecting > > agent), Ben Coman suggested notifying the pharo-dev community. I > > know you're all really busy with the upcoming Pharo 6 release but > > since this bug is kind of pertinent to the new release I thought > > maybe I should report it on fogbugz? If yes, what priority, whom > > should I notify? P.S. for me it's the same error when downloading > > both the stable and the latest versions of the Pharo 6 VM. For now > > I'm still making do with the 60450 version but would really like to > > upgrade to a newer one and can't find the one that wouldn't cause > > any errors. I'm on Win 7 (64 bit). Would appreciate some advice or > > help with this > > Hello! > > I can help for this one :) > > SSH-agent is not working well on Windows. A workaround is to set the ssh > keys before using Iceberg. > > To do so go to Settings -> Tools -> Software Configuration Management -> > Iceberg -> Use custom SSH keys > > You need to check the box and to give the path of your ssh keys. > > For example: > > C:\Users\YourName\.ssh\id_rsa.pub > > C:\Users\YourName\.ssh\id_rsa > > If you don't have any SSH key, check here: > https://help.github.com/articles/connecting-to-github-with-ssh/ > > > * also if there's any advice regarding what I should read or look at > > that's connected to the work I'm doing on my GSoC project, that > > would be great > > > > > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > > -- Ð Ð¿Ð¾Ð²Ð°Ð³Ð¾Ñ, ÐÐ¸ÑÐ¾ÑÐ»Ð°Ð²Ð° Ð Ð¾Ð¼Ð°Ð½ÑÐº.

May 14, 2017

Re: [Pharo-dev] Idea of searcheability of Pharo project on git

by Esteban Lorenzano

yes, is something I have in my TODO list for after release :) > On 14 May 2017, at 14:22, Ben Coman <btc(a)openInWorld.com> wrote: > > On Sat, May 13, 2017 at 9:38 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >>> On 13 May 2017, at 15:04, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> Steph, >>> >>> As Thierry mentions you should create an umbrella project for Pharo where you can maintain a list of projects contributed by users --- something like I've done for GsDevKit_home[1]. >> >> there is already an umbrella project for pharo which is âpharo-projectâ. >> we also promote some othe rmeta projects under the âpharoâ umbrella. >> >> pharo-project >> pharo-graphics >> pharo-vcs >> pharo-nosql >> >> and probably some others will emerge. > > Would it make sense to have... > pharo-catalog ? > > Having this data in STON format on github may make it easier for third > parties to update missing package descriptions. > > cheers -ben > >> the reason why we donât concentrate all on one is just organisational, and we could review that on the future. >> >>> >>> I strongly suggest that you use a "project load spec object"[2][3] as the unit of registration for your projects. In addition to the Metacello load instructions the "project load spec" can maintain a bunch of meta data about the project. >>> >>> The pharo image can scan the projects listed (similar to what you do with the Category Browser - I think) or better yet, the developer can make a local clone of the project site in a well-known location and then all images can look up projects in this the local clone and avoid having to hit the network to build the project list ... >>> >>> Take a look at the video or slides for my "Dangerous Liaisons: Smalltalk, files, and git"[4] for more details ... and of course I'm willing to discuss additional details/ideas over skype or email. >>> >>> Dale >>> >>> [1] http://gsdevkit.github.io/GsDevKit_home/ >>> >>> [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston >>> >>> [3] https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston >>> >>> [4] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git >>> >>> >>> On 5/13/17 12:01 AM, Stephane Ducasse wrote: >>>> Hi guys >>>> >>>> right now many people publish their software on SmalltalkHUB, SS3 and Squeaksource >>>> and this is handy to find something. >>>> >>>> >>>> I hope that we will release soon the package repository that christophe was developing but >>>> now I'm wondering if we as a community should follow a pattern to help? >>>> >>>> git freaks do you have suggestions >>>> >>>> >>>> Stef

May 14, 2017

Re: [Pharo-dev] Idea of searcheability of Pharo project on git

by Ben Coman

On Sat, May 13, 2017 at 9:38 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> On 13 May 2017, at 15:04, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: >> >> Steph, >> >> As Thierry mentions you should create an umbrella project for Pharo where you can maintain a list of projects contributed by users --- something like I've done for GsDevKit_home[1]. > > there is already an umbrella project for pharo which is âpharo-projectâ. > we also promote some othe rmeta projects under the âpharoâ umbrella. > > pharo-project > pharo-graphics > pharo-vcs > pharo-nosql > > and probably some others will emerge. Would it make sense to have... pharo-catalog ? Having this data in STON format on github may make it easier for third parties to update missing package descriptions. cheers -ben > the reason why we donât concentrate all on one is just organisational, and we could review that on the future. > >> >> I strongly suggest that you use a "project load spec object"[2][3] as the unit of registration for your projects. In addition to the Metacello load instructions the "project load spec" can maintain a bunch of meta data about the project. >> >> The pharo image can scan the projects listed (similar to what you do with the Category Browser - I think) or better yet, the developer can make a local clone of the project site in a well-known location and then all images can look up projects in this the local clone and avoid having to hit the network to build the project list ... >> >> Take a look at the video or slides for my "Dangerous Liaisons: Smalltalk, files, and git"[4] for more details ... and of course I'm willing to discuss additional details/ideas over skype or email. >> >> Dale >> >> [1] http://gsdevkit.github.io/GsDevKit_home/ >> >> [2] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside3.ston >> >> [3] https://github.com/dalehenrich/tode/blob/master/.smalltalk.ston >> >> [4] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git >> >> >> On 5/13/17 12:01 AM, Stephane Ducasse wrote: >>> Hi guys >>> >>> right now many people publish their software on SmalltalkHUB, SS3 and Squeaksource >>> and this is handy to find something. >>> >>> >>> I hope that we will release soon the package repository that christophe was developing but >>> now I'm wondering if we as a community should follow a pattern to help? >>> >>> git freaks do you have suggestions >>> >>> >>> Stef >> >> > >

May 14, 2017

Re: [Pharo-dev] How to be able to get a debugger inside DNU

by Stephane Ducasse

Yes this is super annoying because I get really confused On Sat, May 13, 2017 at 11:10 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I also have to scroll up to see the last frame (Pharo 5.0). > > Phil > > On Sat, May 13, 2017 at 9:27 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> In fact my test was broken an in addition the debugger does not show the >> top frame and it took me a while to see that I >> should always scroll to be the stack. >> And I was always only seeing this mustBeABoolean. >> >> On Sat, May 13, 2017 at 9:17 PM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> >>> Hi, >>> >>> I am not quite sure where the issue is because I cannot seem to >>> reproduce the problem. >>> >>> I try this Playground script: >>> >>> Object subclass: #ABC >>> instanceVariableNames: '' >>> classVariableNames: '' >>> package: 'ABC'. >>> >>> ABC compile: 'doesNotUnderstand: aMessage >>> "support sending message to access properties" >>> >>> | selector | >>> selector := aMessage selector. >>> self halt: aMessage selector. >>> ^ selector isUnary >>> ifTrue: [ (self hasPropertyAt: selector) >>> ifTrue: [ self propertyAt: aMessage >>> selector asSymbol ] >>> ifFalse: [ super doesNotUnderstand: >>> aMessage ] ] >>> ifFalse: [ selector numArgs = 1 >>> ifTrue: [ self propertyAt: aMessage >>> selector allButLast asSymbol put: aMessage argument ] >>> ifFalse: [ super doesNotUnderstand: >>> aMessage ] ]'. >>> >>> ABC new bla. >>> >>> >>> >>> And I get a debugger. What am I missing? >>> >>> Cheers, >>> Doru >>> >>> >>> >>> > On May 13, 2017, at 6:05 PM, Stephane Ducasse <stepharo.self(a)gmail.com> >>> wrote: >>> > >>> > Hi >>> > >>> > In the past it was possible to step throw such code and now we cannot >>> anymore >>> > because of a smart trick. I should say that I hate when we break the >>> reachibility and understandibility of the system. >>> > So why I cannot get a debugger opens after the halt: ? >>> > How do I get that ? >>> > >>> > Now I will put traces: super cool! >>> > >>> > Stef >>> > >>> > doesNotUnderstand: aMessage >>> > "support sending message to access properties" >>> > >>> > | selector | >>> > selector := aMessage selector. >>> > self halt: aMessage selector. >>> > ^ selector isUnary >>> > ifTrue: [ (self hasPropertyAt: selector) >>> > ifTrue: [ self propertyAt: aMessage >>> selector asSymbol ] >>> > ifFalse: [ super doesNotUnderstand: >>> aMessage ] ] >>> > ifFalse: [ selector numArgs = 1 >>> > ifTrue: [ self propertyAt: aMessage >>> selector allButLast asSymbol put: aMessage argument ] >>> > ifFalse: [ super doesNotUnderstand: >>> aMessage ] ] >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> âLive like you mean it." >>> >>> >>> >> >

May 14, 2017

Re: [Pharo-dev] Git breaks Monticello's version numbers

by Ben Coman

Could a pragmatic fix be simply... if the first-generated MC version number is greater than 10000, then re-generate the MC version number based off the latest version number in the MC repository. But the bigger question is for... v1(MC) --> v2(git) --> v3(git) --> v4(git) --> v5(MC) what about all the intermediate commits? Do v2, v3, v4 need to make it into MC? Its the same sort of problem if you were maintaining two separate MC repos in sync, not specifically an Iceberg problem. So as Joel describes in "Let me go Back" regarding the tipping point for Excel to overtake Lotus123, perhaps we a (separate) tool in the default Image that migrates from git back to MC, as well as from MC to git. https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… cheers -ben On Sat, May 13, 2017 at 10:42 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 13/05/2017 Ã 16:17, Esteban Lorenzano a Ã©crit : >> >> >>> On 13 May 2017, at 15:51, Thierry Goubier <thierry.goubier(a)gmail.com> >>> wrote: >>> >>> Le 13/05/2017 Ã 15:43, Esteban Lorenzano a Ã©crit : >>>> >>>> >>>> >>>>> On 13 May 2017, at 13:16, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>>>> wrote: >>>>> >>>>> Iâm not a bit expert, but if you donât use âmetadatalessâ format >>>>> everything works fine with monticello. I.e. each git commit >>>>> contains all the mc history. >>>> >>>> >>>> yes, but with iceberg we did another choice: we force metadataless >>>> and do not keep compatibility with monticello. this is like that by >>>> design: keeping the metadata was too much noise and generated a lot >>>> of conflicts we donât want. >>> >>> >>> The metadata-less format was experimented with before Iceberg because we >>> knew that recreation of MC-compatible metadata out of the vcs log was >>> already working. >>> >>> Then FileTree (and MC) was modified to make sure that the metadata-less >>> format would be compatible with MC. >>> >>> Now, Iceberg has decided to be non-compatible with MC. But this has >>> nothing to do with the underlying format. >> >> >> Iceberg uses filetree metadataless as file format (it uses even the same >> class to do the write) so what you are saying is not true ;) >> What changes is that instead adding a random cypress.1 we add the a number >> which is a timestamp of the commit. > > > I'd prefer to have the git short commit ID instead. But that is my opinion. > > Very little is needed in MC for that numbering to be compatible. > >>>> So, using iceberg is not using git as âjust another repository format >>>> as http, ftp, etc.â. If you want to keep both versions, then you >>>> need to save in mc format then save again in iceberg (or viceversa). >>> >>> >>> Which looks clumsy at best and at worse, will make the transition to >>> Iceberg a pain. >> >> >> I disagree. >> the cost of keeping eternal backward compatibility is not moving forward. > > > I said nothing about eternal backward compatibility. > > It's interesting however that you see 'eternal backward compatibility' > there. > >> And Peter did a very good tool to easy migrations that respect history. > > > What Peter did could make the infrastructure a lot better. His tool can do a > lot more than easing the migration. > >> Also, nobody is forced to use iceberg: you donât want it, do not use it. >> You still have monticello. > > > For the time being... > > Everyone will have to cope with the migration from mcz to Iceberg at one > point. Good luck to us, I guess. > > Regards, > > Thierry > > >> >>> >>> Thierry >>> >>>> Esteban >>>> >>>>> >>>>> Uko >>>>> >>>>>> On 13 May 2017, at 09:28, Thierry Goubier >>>>>> <thierry.goubier(a)gmail.com> wrote: >>>>>> >>>>>> Le 13/05/2017 Ã 08:58, Stephane Ducasse a Ã©crit : >>>>>>> >>>>>>> My gut feeling is that it will be better not to mix git and >>>>>>> MC. >>>>>> >>>>>> >>>>>> It is easy to make MC compatible with Git. >>>>>> >>>>>> It wasn't that hard in the past, but needed a community effort >>>>>> (MC being a core part of the system). Now, with the >>>>>> infrastructure underway (libgit, git fast-import) it looks very >>>>>> easy to implement. >>>>>> >>>>>> Thierry >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, May 12, 2017 at 11:09 PM, Oleksandr Zaytsev >>>>>>> <olk.zaytsev(a)gmail.com <mailto:olk.zaytsev@gmail.com>> wrote: >>>>>>> >>>>>>> Hello >>>>>>> >>>>>>> Two days ago I was trying to send the slice with my fix to >>>>>>> PolyMath using Monticello. But the version number got set to >>>>>>> 1494471195. Today I realized that all the packages to which I >>>>>>> commit are numbered like that. >>>>>>> >>>>>>> Cyril Ferlicot explained to me that this happens when I mix git >>>>>>> and Monticello commits. He suggested that I use a separate >>>>>>> image for committing to GitHub, or file out/file in if there is >>>>>>> a lot of changes to commit. >>>>>>> >>>>>>> Can this be considered a bug? Should I report it? >>>>>>> >>>>>>> I think it would be causing problems for many people. >>>>>>> >>>>>>> Oleks >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > >

May 14, 2017

Re: [Pharo-dev] How to be able to get a debugger inside DNU

by phil＠highoctane.be

I also have to scroll up to see the last frame (Pharo 5.0). Phil On Sat, May 13, 2017 at 9:27 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > In fact my test was broken an in addition the debugger does not show the > top frame and it took me a while to see that I > should always scroll to be the stack. > And I was always only seeing this mustBeABoolean. > > On Sat, May 13, 2017 at 9:17 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> I am not quite sure where the issue is because I cannot seem to reproduce >> the problem. >> >> I try this Playground script: >> >> Object subclass: #ABC >> instanceVariableNames: '' >> classVariableNames: '' >> package: 'ABC'. >> >> ABC compile: 'doesNotUnderstand: aMessage >> "support sending message to access properties" >> >> | selector | >> selector := aMessage selector. >> self halt: aMessage selector. >> ^ selector isUnary >> ifTrue: [ (self hasPropertyAt: selector) >> ifTrue: [ self propertyAt: aMessage >> selector asSymbol ] >> ifFalse: [ super doesNotUnderstand: >> aMessage ] ] >> ifFalse: [ selector numArgs = 1 >> ifTrue: [ self propertyAt: aMessage >> selector allButLast asSymbol put: aMessage argument ] >> ifFalse: [ super doesNotUnderstand: >> aMessage ] ]'. >> >> ABC new bla. >> >> >> >> And I get a debugger. What am I missing? >> >> Cheers, >> Doru >> >> >> >> > On May 13, 2017, at 6:05 PM, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> > >> > Hi >> > >> > In the past it was possible to step throw such code and now we cannot >> anymore >> > because of a smart trick. I should say that I hate when we break the >> reachibility and understandibility of the system. >> > So why I cannot get a debugger opens after the halt: ? >> > How do I get that ? >> > >> > Now I will put traces: super cool! >> > >> > Stef >> > >> > doesNotUnderstand: aMessage >> > "support sending message to access properties" >> > >> > | selector | >> > selector := aMessage selector. >> > self halt: aMessage selector. >> > ^ selector isUnary >> > ifTrue: [ (self hasPropertyAt: selector) >> > ifTrue: [ self propertyAt: aMessage >> selector asSymbol ] >> > ifFalse: [ super doesNotUnderstand: >> aMessage ] ] >> > ifFalse: [ selector numArgs = 1 >> > ifTrue: [ self propertyAt: aMessage >> selector allButLast asSymbol put: aMessage argument ] >> > ifFalse: [ super doesNotUnderstand: >> aMessage ] ] >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> âLive like you mean it." >> >> >> >

May 13, 2017