January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Henrik Johansen

On 30 Jan 2014, at 6:14 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Soâ¦ that. > > Is super cool to remove poolDictionaries from the default class template. > What is not cool *at all* is the fact that now my low level projects, who uses them intensively, does not work anymore. > The reason? the classes are created without poolDictionaries. > > So, pleaseâ¦ whoever pushed this change. Please fix it. > > thanks, > Esteban Sooo, since Iâm curios, anyone care to explain how a change intended to affect whether Nautilus displays pool Dicts end up breaking how theyâre loaded from Monticello? Did Nautilus pick up on the class load announcement from RPackage and end up recompiling the class with itâs own (lacking) default definition or something similarly crazy? Cheers, Henry

Jan. 31, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Johan Fabry

Hi Torsten, I think it is a design decision / tradeoff, and therefore there is no fundamentally "right way" to do it. For me, it is the same case as the uses: message for Traits. It's not in the template by default because it is used very infrequently. So for language simplicity it should not be there. For me, simplicity is one of the core points of Smalltalk so this is why I feel strongly about it. When I say "very infrequently", this is of course a fuzzy metric, I know. And I understand that you do not agree with this design decision. But on the other hand, I don't think that it is too hard to remember where to add the pooldictionaries: line if you need it, and the old message with this line still works, so all old examples still work. The fix I proposed was integrated today, so everything should work now. If there still is a problem I will provide a fix as soon as I get notified of the issue (as I did yesterday). My apologies to all for the mess, I promise I won't cause such a mess again in the future. On Jan 31, 2014, at 9:54 AM, "Torsten Bergmann" <astares(a)gmx.de> wrote: > Hi Johan, > > Still I really do not understand what particular problem that is solved by changing > the template from > > MySuperclass subclass: #Foo > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Bar-Core' > > to > > MySuperclass subclass: #Foo > instanceVariableNames: '' > classVariableNames: '' > category: 'Bar-Core' > > other than some of your student had problem not yet knowning what pool dictionaries are > and you want to hide pools therefore. A weak argument since some students may not yet > know about class variables - so why not hiding them in the first place too? > > Another teacher may argue that his students got problems because the template was changed > and nearly all ST, Seaside and Pharo books used for teaching include the extended variant > of the message. > > IMHO a class template is (as the name says) a "template" and a template should be > something one just has to fill out. The idea of a template is to avoid too much typing afterwards. > So the idea is one just should fill out the template without much hazzle. > If I require an ivar, a class variable, a pool or a category I just put it in. > > By now reducing the template people who require pools have to do more typing and > they have to remember the order of words in the keyword message... > > I stand at my point I think there is not much real value in this change of the default > template, but are fine if community agrees on the reduced version. > > Thanks > T. > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Jan. 31, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Torsten Bergmann

Hi Johan, Still I really do not understand what particular problem that is solved by changing the template from MySuperclass subclass: #Foo instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Bar-Core' to MySuperclass subclass: #Foo instanceVariableNames: '' classVariableNames: '' category: 'Bar-Core' other than some of your student had problem not yet knowning what pool dictionaries are and you want to hide pools therefore. A weak argument since some students may not yet know about class variables - so why not hiding them in the first place too? Another teacher may argue that his students got problems because the template was changed and nearly all ST, Seaside and Pharo books used for teaching include the extended variant of the message. IMHO a class template is (as the name says) a "template" and a template should be something one just has to fill out. The idea of a template is to avoid too much typing afterwards. So the idea is one just should fill out the template without much hazzle. If I require an ivar, a class variable, a pool or a category I just put it in. By now reducing the template people who require pools have to do more typing and they have to remember the order of words in the keyword message... I stand at my point I think there is not much real value in this change of the default template, but are fine if community agrees on the reduced version. Thanks T.

Jan. 31, 2014

[pharo-project/pharo-core]

by GitHub

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

Jan. 31, 2014

[pharo-project/pharo-core] f9646c: 30732

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: f9646c28c8894ed09c36f4847da5fae306d6f147 https://github.com/pharo-project/pharo-core/commit/f9646c28c8894ed09c36f484… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-31 (Fri, 31 Jan 2014) Changed paths: M Nautilus.package/PackageTreeNautilusUI.class/instance/accessing/selected_.st M Nautilus.package/extension/Class/instance/definitionForNautilus.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script385.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30732.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/SmalltalkImage.class/instance/sources%2C change log/licenseString.st A System-Support.package/SmalltalkImage.class/instance/sources%2C change log/licenseStringTemplate.st M Text-Core.package/TextAction.class/README.md M Text-Core.package/TextClassLink.class/README.md M Text-Core.package/TextConstants.class/README.md M Text-Core.package/TextDoIt.class/README.md M Text-Core.package/TextLink.class/README.md M Text-Core.package/TextMethodLink.class/README.md M Text-Core.package/TextPrintIt.class/README.md M Text-Core.package/TextVariableLink.class/README.md M Text-Edition.package/EditorFindReplaceDialogWindow.class/README.md M Text-Edition.package/FindReplaceService.class/README.md M Text-Tests.package/RunArrayTest.class/README.md M Text-Tests.package/TextAlignmentTest.class/README.md M Text-Tests.package/TextEmphasisTest.class/README.md M Text-Tests.package/TextFontChangeTest.class/README.md M Text-Tests.package/TextFontReferenceTest.class/README.md M Text-Tests.package/TextKernTest.class/README.md M Tools.package/ImageCleaner.class/instance/api/cleanUpForProduction.st Log Message: ----------- 30732 12757 #cleanUpForProduction should not unload Deprecated and Jenkins https://pharo.fogbugz.com/f/cases/12757 12755 Licensestring still shows 2013 instead of current year https://pharo.fogbugz.com/f/cases/12755 12734 Nautilus accept changes shows prompt for cancel dialog https://pharo.fogbugz.com/f/cases/12734 12764 Class comments missing in Text package https://pharo.fogbugz.com/f/cases/12764 12752 Non-Empty list of pooldictionaries is still cut from the class description in Nautilus https://pharo.fogbugz.com/f/cases/12752 http://files.pharo.org/image/30/30732.zip

Jan. 31, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Esteban Lorenzano

just to be clear: Iâm not agains this change, I think is a good one. I just was (and I still am) pissed with the fact that we do not fully understand the signification of âfrozenâ version, and sometimes I feel like nobody notices the HUGE effort that means to close a version in a reliable and stable way :) Said soâ¦ I still does not understand why this particular change couldnât wait for pharo 4. But wellâ¦ now is there, so it needs to work fine. Esteban On 31 Jan 2014, at 12:55, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > I don't see why there needs to be a configuration for that. You can still add them, just put pooldictionaries: 'foo bar' on the next-to-last line as it was before, et voilÃ¡ â¦ you have them in your class. > > This is the same behavior as traits and the uses: message. There is not configuration option present for that, AFAIK. > > On Jan 31, 2014, at 4:42 AM, "Torsten Bergmann" <astares(a)gmx.de> wrote: > >> Please make it a setting - so one can see the creation message with poolDictionaries in Nautilus >> as before in the browser and is able to fill out the template. >> >> When using NB one requires them. >> >> Thx >> T. >> >> >> > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Jan. 31, 2014

Re: [Pharo-dev] xpath?

by Esteban Lorenzano

probablyâ¦ honestly when I did it I had a very concrete problem at hands and I just implemented what I needed to solve it :S On 31 Jan 2014, at 11:44, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks. I actually looked for it, but I could not find it. I now checked it and it works fine. > > However, it provides a similar but not quite the same functionality as XPath. For example, I did not find support for matching against attributes with @. > > Doru > > > On Thu, Jan 30, 2014 at 8:43 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Have a look at Pastell > > http://vimeo.com/38760554 > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 31, 2014

Seaside extensions and lowercase package names in Pharo

by Torsten Bergmann

Now that Pharo uses real packages beside categories I see some lowercase "ghost" packages in Monticello Browser list after loading Seaside. To reproduce just load Seaside using config browser and check in Monticello browser. I guess this is coming from methods in lowercase extension categories like "*seaside-pharo-core" which do not really match "Seaside-Pharo-Core" package. Any comments? Thx T.

Jan. 31, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Johan Fabry

I don't see why there needs to be a configuration for that. You can still add them, just put pooldictionaries: 'foo bar' on the next-to-last line as it was before, et voilÃ¡ â¦ you have them in your class. This is the same behavior as traits and the uses: message. There is not configuration option present for that, AFAIK. On Jan 31, 2014, at 4:42 AM, "Torsten Bergmann" <astares(a)gmx.de> wrote: > Please make it a setting - so one can see the creation message with poolDictionaries in Nautilus > as before in the browser and is able to fill out the template. > > When using NB one requires them. > > Thx > T. > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Jan. 31, 2014

Re: [Pharo-dev] [ANN] GitFileTree with no git command line at all

by Pharo4Stef

It uses OS Process. > How does it interact with git? Does it shell out, call a library or have a full git implementation in Smalltalk? > > Cheers > Philippe > > >

Jan. 31, 2014