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

Re: [Pharo-dev] [pharo-project/pharo-core] c479c0: 40073

by Pavel Krivanek

Hi Stef, I checked how and where the KeyChain package was used in the system and my result was that it makes more sense to try to clean it and adapt into the kernel than to remove it complete. Because its basic idea is not totally wrong, the evil was only in the implementation ;-) UserManager-Core is not nice name but more fitting than KeyChain. And I expect that UserManager-Tests will follow. It should be removed from all image version or merged with Author class. Cheers, -- Pavel 2014-07-09 21:08 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi guys > > I do not like this name > > UserManager-Core > > and I would remove from the image the UserManager-core package and just > keep the hooks. > > Stef > > 13498 rename KeyChain package to UserManager-Core >> https://pharo.fogbugz.com/f/cases/13498 >> > > >

July 9, 2014

Re: [Pharo-dev] [Article] Elegant Pharo Code

by stepharo

On 8/7/14 00:21, Sven Van Caekenberghe wrote: > Hi, > > I have written a new article presenting Pharo using a list of 23 short examples. > > Elegant Pharo Code > > Beautiful & Powerful One-liners, Expressions and Snippets > > https://medium.com/@svenvc/elegant-pharo-code-bb590f0856d0 > > As mentioned at the end of the article, I welcome feedback, remarks, comments, alternative solutions and other examples. The idea is to create yet another way to lure people into exploring Pharo while explaining by example why we like Pharo. Cool Some ideas MethodFinder methodFor: #( (4 3) 7 (0 5) 5 (5 5) 10). something with intervals could be fun :) > > Enjoy! > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > >

July 9, 2014

Re: [Pharo-dev] [Pharo4] CachingMorph: anyone ever used it?

by Sven Van Caekenberghe

On 09 Jul 2014, at 21:23, stepharo <stepharo(a)free.fr> wrote: > > On 9/7/14 14:38, Stephan Eggermont wrote: >> To get better at answering these questions, it would be nice to be able to >> check the repositories. I've put a proof of concept in DeprecationFinder >> on smalltalkhub. > > What do you mean? Because this is unclear to me. What he means is: before we say something has no users (in the image), we should also check (some) external packages. >> >> Stephan >> > >

July 9, 2014

Re: [Pharo-dev] [Pharo4] CachingMorph: anyone ever used it?

by stepharo

On 9/7/14 14:38, Stephan Eggermont wrote: > To get better at answering these questions, it would be nice to be able to > check the repositories. I've put a proof of concept in DeprecationFinder > on smalltalkhub. What do you mean? Because this is unclear to me. > > Stephan > >

July 9, 2014

Re: [Pharo-dev] About the *-Settings packages

by Marcus Denker

On 09 Jul 2014, at 21:05, stepharo <stepharo(a)free.fr> wrote: > Marcus you should not stress about extra packages. > Because we will have deadcode if you unload the setting core and the settings methods are in the same package. Yes, one method with 5 lines of code. Nobody *ever* unloaded a setting package. Ever. > I think that they are more problem with fonts for example and it would be better to focus on them. > In the evening I do what needs no thinkingâ¦ Marcus

July 9, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] c479c0: 40073

by stepharo

Hi guys I do not like this name UserManager-Core and I would remove from the image the UserManager-core package and just keep the hooks. Stef > 13498 rename KeyChain package to UserManager-Core > https://pharo.fogbugz.com/f/cases/13498

July 9, 2014

Re: [Pharo-dev] About the *-Settings packages

by stepharo

Marcus you should not stress about extra packages. Because we will have deadcode if you unload the setting core and the settings methods are in the same package. I think that they are more problem with fonts for example and it would be better to focus on them. did you read these: https://github.com/pharo-project/pharo-workingRoadmaps Stef > Hi, > > The Settings framework is very nice: there are no dependencies to the framework itself anywhere, so you can run > with both the Setting Browser and *the framework itself* unloaded. > > All the settings definitions are in their own packages, so you can even unload *those*. But I wonder if that is not one > thing too much: > > -> the definition itself does not create dependencies at all > -> the definitions are *tiny* (5-30 line methods) > -> the packages contains just one class with (often) just one method, managing a complete package for that should pay of, > and I would say it does not (âI can save 500 bytes of dead code by not shipping the settings definition in my deployment image!"). > I guess nobody ever unloaded a settings package for deployment! (#cleanUpForProduction does not) > > I would like to move the definitions of settings close to the code that the settings manipulate (and from itâs own class > just to the main class of that package, class side). > > - you can still unload the settings framework after > - the only âuselessâ things staying in the system after unloading the settings framework is a method that is not used > (but that does not introduce dependencies) > - managing the code base in turn gets simpler > - less classes and packages to manage > > > Marcus >

July 9, 2014

Re: [Pharo-dev] Contributing to Spec

by stepharo

Hi > Hi, > > how can I contribute to Spec? Should I open a pull request on github? I do not know the difference between the github version and the one on pharo. You can open a bug entry on the pharo bug tracker and send slice. Like that we will integrate it. And Ben can merge back if he wants. Stef > > Uko > >

July 9, 2014

Re: [Pharo-dev] [Article] Elegant Pharo Code

by Norbert Hartl

> Am 09.07.2014 um 16:21 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > >> On 08 Jul 2014, at 16:36, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: >> >> Thanks!!!! tomorrow will be holliday in my country. I will read tomorrow. >> Before the semifinal of FIFA world cup. >> Go Argentina!!!! > > I don't know which side to support: on one hand, they beat Belgium (we were not good enough, but they were not that great either) so if our neighbours beat them that would be nice, but on the other hand, there is also some healthy rivalry between us, so if the Netherlands lose from Argentina, that would teach them (they didn't play that well against Costa Rico, penalties are a lottery) - but it makes no difference, Germany will/should win the final, they play way too well ;-) I'd wish you were right. But winning so high makes you closer to loose the next game. That is my fear. So we'll see. Norbert

July 9, 2014

Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo

by Stephan Eggermont

355 still has the problem. I should probably bring it up before we have to play against the germans :) Stephan

July 9, 2014