October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] AspectS, PHANtom - Aspects in Pharo

by phil＠highoctane.be

I am interested in aspects as for crosscutting concerns they are useful. I am now using Traits in my code and it works well indeed. The problem with them is that I have to pepper them around in classes where with aspects, I could define pointcuts in a single place with definitions (I used that in Java with Spring for example). I am not interested in performance, this is mostly for development activities and the final code may well use Traits that I could put in the classes with some source code generation and recompiles. One key aspect would be to do accounting of the system usage in order to bill the users according to their usage of the features. Something like AspectS looked quite integrated language wise. Some reference work I use conceptually speaking: http://www.amazon.com/Aspect-Oriented-Software-Development-Use-Cases/dp/032… http://aosd.net/archive/2003/*jacobson*-aosd-2003.ppt Regards, Phil

Oct. 25, 2013

Re: [Pharo-dev] Pharo-V20.sources

by Johan Brichau

Hey Sven, Thanks for these alternatives. I guess Iâm an old-fashioned website user :-) cheers Johan On 25 Oct 2013, at 23:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Johan, > > On 25 Oct 2013, at 22:55, Johan Brichau <johan(a)inceptive.be> wrote: > >> Hi guys, >> >> Just a small note that the sources file for Pharo2.0 (and 3.0) is not easy to get when downloading the VM and the image from the website. >> >> I had to finally download the âone clickâ and extract the sources file from its resources. >> >> I believe they used to be included with the image zips. >> >> cheers >> Johan > > They are in the vm directory when the vm is downloaded using get.pharo.org > > There is also a #downloadSources method in the image. > > Sven > >

Oct. 25, 2013

Re: [Pharo-dev] Pharo-V20.sources

by Sven Van Caekenberghe

Hi Johan, On 25 Oct 2013, at 22:55, Johan Brichau <johan(a)inceptive.be> wrote: > Hi guys, > > Just a small note that the sources file for Pharo2.0 (and 3.0) is not easy to get when downloading the VM and the image from the website. > > I had to finally download the âone clickâ and extract the sources file from its resources. > > I believe they used to be included with the image zips. > > cheers > Johan They are in the vm directory when the vm is downloaded using get.pharo.org There is also a #downloadSources method in the image. Sven

Oct. 25, 2013

Pharo-V20.sources

by Johan Brichau

Hi guys, Just a small note that the sources file for Pharo2.0 (and 3.0) is not easy to get when downloading the VM and the image from the website. I had to finally download the âone clickâ and extract the sources file from its resources. I believe they used to be included with the image zips. cheers Johan

Oct. 25, 2013

[pharo-project/pharo-core]

by GitHub

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

Oct. 25, 2013

[pharo-project/pharo-core] 9e65f1: 30526

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 9e65f148f79b2b0c5c30be76e1b30818bae4003e https://github.com/pharo-project/pharo-core/commit/9e65f148f79b2b0c5c30be76… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-25 (Fri, 25 Oct 2013) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/private/rootsOfGroup_.st M Nautilus.package/AbstractNautilusUI.class/instance/private/rootsOf_.st M Nautilus.package/AbstractNautilusUI.class/instance/system announcements/packageRenamed_.st M Nautilus.package/AbstractNautilusUI.class/instance/system announcements/packageUnregistred_.st M Nautilus.package/Nautilus.class/instance/browser compatibility/labelString.st M RPackage-Core.package/RPackage.class/instance/class tags/classNamesForClassTag_.st M RPackage-Tests.package/RPackageReadOnlyCompleteSetupTest.class/instance/test tag class/testAddTag.st M RPackage-Tests.package/RPackageReadOnlyCompleteSetupTest.class/instance/test tag class/testAddTagNames.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script181.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30526.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Sound.package/SoundSystem.class/instance/accessing/soundEnabled_.st Log Message: ----------- 30526 11521 Error with soundEnabled: https://pharo.fogbugz.com/f/cases/11521 12010 trivial cleanup in Nautilus https://pharo.fogbugz.com/f/cases/12010 11968 failing tests in RPackageReadOnlyCompleteSetupTest https://pharo.fogbugz.com/f/cases/11968/ http://files.pharo.org/image/30/30526.zip

Oct. 25, 2013

Re: [Pharo-dev] Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

by Chris Muller

We should not continue this old discussion. We've already debated this ad naseum. Thank you Pharo guys for exploring what can be done when all constraints are removed! Thank you Squeak guys for advancing in a way that caters to legacy applications. On Fri, Oct 25, 2013 at 1:25 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 25 Oct 2013, StÃ©phane Ducasse wrote: > >> >>> I'm sorry if you guys didn't get my message, but it was as serious as it >>> could be. >> >> >> Ok fair :) >> >>> I understand that you don't what to be backwards compatible, because it >>> makes it easier to change stuff. >>> As I see, people need various levels of backwards compatibility. >> >> >> Indeed but the right level is important ;) >> I help maintaining Moose and its several couple of tenth of packages as >> well as the pharoExtras packages >> so I think that I'm exposed to API changes. Just today I fixed the >> PharoSound package (full of ugly code BTW) > > > That's nice, but AFAIK Moose is Pharo-only, so you only have to follow your > own changes. > > >> >>> Currently the package maintainers are the most affected, who would like >>> to provide the same codebase for various versions of Pharo, and/or other >>> Smalltalk dialects. >> >> >> there is a bit of utopia there but why not. I prefer to see a system >> getting better than my code just loading in >> a system slowly improving. I can control when I want to migrate my apps. > > > This is where the level of backwards compatibility comes into the picture. > For example the official release of Seaside is still based on Pharo 1.3, and > the reason for that is the frequent changes of core functionality. > > >> >>> As time passes, and the number of users increases, you'll have to give >>> in, and provide it some way. >> >> >> What I was thinking for example (and I will build it) is an automatic stub >> creation to support the >> loading of package where a class is missing in the existing system. > > > I don't see how this is benefical, or how it addresses the increasing demand > for backwards compatibility. > > >> I also love the evolution analysis made by andre that generates rules to >> check migration >> we should add automatic code transformation. I would like to keep >> refactoring that we can apply >> when people want to migrate. And we will get there because we start to >> have a good infrastructure. >> So once the infrastructure does not suck all our time then we will build >> the next generation tools. >> And this is starting :) >> >> >>>> We are all committed to build a robust and clean system that people can >>>> use to >>>> create their own wealth and feed their family. We are >>>> making HUGE progress. I mean REALLY HUGE and the space it opens is >>>> LARGE. >>> >>> >>> I'm not following the developement of Pharo closely anymore, mainly >>> because it's not transparent enough for my taste. >> >> You will complain about the fogbuz stuff and we will answer that we hate >> that google forced us >> to move. And this is like that. > > > Well, fogbugz is just part of it, and somewhat less important than actual > code changes. > There are two kind of diffs posted to this mailing list. One for the changes > on smalltalkhub, and the other is from github. The latter is totally > useless, because it contains no code, just the name of the methods in the > changed packages. The former is totally broken, because smalltalkhub can't > create the diff, if the direct ancestor of the package is missing, and in > 90%+ of the cases, you jump more than one mcz versions. > > >> >>> I see that you're making big changes, but I still haven't seen the >>> breakthrough: I don't see the advantage of using Pharo over another open >>> source Smalltalk dialect, from business point of view. >> >> >> It is just a question of view. For me a new compiler, debugger, inspector, >> filesystem, http >> server and many more is enough. And in addition the consortium means that >> slowly >> we will give an autonomous live to Pharo not based on free time of people. > > > I can only repeat myself; these changes are great, but it's not a > breakthrough. > > > Levente > >> >> Stef >> >> >

Oct. 25, 2013

Re: [Pharo-dev] Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

by Levente Uzonyi

On Fri, 25 Oct 2013, StÃ©phane Ducasse wrote: > >> I'm sorry if you guys didn't get my message, but it was as serious as it could be. > > Ok fair :) > >> I understand that you don't what to be backwards compatible, because it makes it easier to change stuff. >> As I see, people need various levels of backwards compatibility. > > Indeed but the right level is important ;) > I help maintaining Moose and its several couple of tenth of packages as well as the pharoExtras packages > so I think that I'm exposed to API changes. Just today I fixed the PharoSound package (full of ugly code BTW) That's nice, but AFAIK Moose is Pharo-only, so you only have to follow your own changes. > >> Currently the package maintainers are the most affected, who would like to provide the same codebase for various versions of Pharo, and/or other Smalltalk dialects. > > there is a bit of utopia there but why not. I prefer to see a system getting better than my code just loading in > a system slowly improving. I can control when I want to migrate my apps. This is where the level of backwards compatibility comes into the picture. For example the official release of Seaside is still based on Pharo 1.3, and the reason for that is the frequent changes of core functionality. > >> As time passes, and the number of users increases, you'll have to give in, and provide it some way. > > What I was thinking for example (and I will build it) is an automatic stub creation to support the > loading of package where a class is missing in the existing system. I don't see how this is benefical, or how it addresses the increasing demand for backwards compatibility. > I also love the evolution analysis made by andre that generates rules to check migration > we should add automatic code transformation. I would like to keep refactoring that we can apply > when people want to migrate. And we will get there because we start to have a good infrastructure. > So once the infrastructure does not suck all our time then we will build the next generation tools. > And this is starting :) > > >>> We are all committed to build a robust and clean system that people can use to >>> create their own wealth and feed their family. We are >>> making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE. >> >> I'm not following the developement of Pharo closely anymore, mainly because it's not transparent enough for my taste. > You will complain about the fogbuz stuff and we will answer that we hate that google forced us > to move. And this is like that. Well, fogbugz is just part of it, and somewhat less important than actual code changes. There are two kind of diffs posted to this mailing list. One for the changes on smalltalkhub, and the other is from github. The latter is totally useless, because it contains no code, just the name of the methods in the changed packages. The former is totally broken, because smalltalkhub can't create the diff, if the direct ancestor of the package is missing, and in 90%+ of the cases, you jump more than one mcz versions. > >> I see that you're making big changes, but I still haven't seen the breakthrough: I don't see the advantage of using Pharo over another open source Smalltalk dialect, from business point of view. > > It is just a question of view. For me a new compiler, debugger, inspector, filesystem, http > server and many more is enough. And in addition the consortium means that slowly > we will give an autonomous live to Pharo not based on free time of people. I can only repeat myself; these changes are great, but it's not a breakthrough. Levente > > Stef > > >

Oct. 25, 2013

Re: [Pharo-dev] AspectS, PHANtom - Aspects in Pharo

by StÃ©phane Ducasse

Not really and frankly I would not use that. What is your case? Stef > Hello, > > I was wondering what the state of Aspect programming was in Pharo. > > Googling a bit turned the title mentioned projects. > > Do we anything loadable and more or less stable for Pharo2.x? > > I'd like to use some of that. > > TIA > Phil

Oct. 25, 2013

[update 3.0] #30525

by StÃ©phane Ducasse

Oct. 25, 2013