November 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Pharo Images before 1.0

by Oscar E A CallaÃº

Hi guys, I was wondering where I can find/download versions of pharo images below 1.0 ? Why I need this? Because I have a compilation of Smalltalk projects that are from Dic-2009, and I need to load/run them. Cheers.

Nov. 20, 2012

[Pharo-project] smalltalkhub

by Camillo Bruni

what's the status? can we switch to emergency mode?

Nov. 20, 2012

Re: [Pharo-project] Beeper

by Henrik Sperre Johansen

On 20.11.2012 13:33, Mariano Martinez Peck wrote: > > > And why it is a AppRegistry. AppRegistry > associates some application, tool. It is very confusing to > use it for > a sound provider. > > More the name of AppRegistry being confusing, what it does is > provide infrastructure for registering providers of a service, and > switching which is currently in use. > In other words, SoundService (due to being an ApprRegistry) can > switch between using multiple SoundSystems. > > > Would it make sense to rename AppRegistry to ServiceRegistry therefore? In my mind it would at least. :) That or ServiceProvider, depending on whether one feels the focus should be on its role in registering multiple implementors, or its role in accessing/using those implementors. Cheers, Henry

Nov. 20, 2012

Re: [Pharo-project] Beeper

by Mariano Martinez Peck

> >> And why it is a AppRegistry. AppRegistry >>> associates some application, tool. It is very confusing to use it for >>> a sound provider. >>> >> More the name of AppRegistry being confusing, what it does is provide > infrastructure for registering providers of a service, and switching which > is currently in use. > In other words, SoundService (due to being an ApprRegistry) can switch > between using multiple SoundSystems. > > Would it make sense to rename AppRegistry to ServiceRegistry therefore? > Then I do not understand why it is named >>> AbstractSoundSystem and not simply SoundSystem (remember >>> AbstractString). >>> >> Yes let us clean all that :) >> Can you take the lead on that? >> We could include the sound package in the release. >> > Because AbstractSoundSystem provides the common interface that is expected > to be supported by a given entry in the SoundService providers . Whether > that warrants including Abstract in the name is debatable I guess :) > > On Sat, Nov 17, 2012 at 9:33 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>> >>>> Hi pavel >>>> >>>> In fact the registration default sound system is broken and we should >>>> fix it. >>>> I forgot what is the problem :) >>>> >>>> Hi, >>>>> >>>>> I would like to discuss the Beeper class a little bit. The main >>>>> purpose of this class is to provide Beeper beep message and use >>>>> SoundService with respect to current sound enabled settings or VM >>>>> implemented primitive for beeping. >>>>> >>>> Yes this was the idea and to remove it from smalltalk. >>>> >>> Outright removal is a bit harsh considering what external users may > exist. > It probably deserves either being put in a deprecated package, or moved to > a loadable compat package. > > Cheers, > Henry > > -- Mariano http://marianopeck.wordpress.com

Nov. 20, 2012

Re: [Pharo-project] Beeper

by Henrik Sperre Johansen

The architecture involved in SoundService/AbstractSoundSystem might seem like overkill for what is provided/used in the base image. An external package does exist however, which provides a more capable soundsystem when installed. (http://www.squeaksource.com/PharoSound) On 18.11.2012 09:47, StÃ©phane Ducasse wrote: >> Hi Stef, >> >> firstly I do not understand why we have SoundService at all when we >> have AbstractSoundSystem. > Yes me too :) > >> And why it is a AppRegistry. AppRegistry >> associates some application, tool. It is very confusing to use it for >> a sound provider. More the name of AppRegistry being confusing, what it does is provide infrastructure for registering providers of a service, and switching which is currently in use. In other words, SoundService (due to being an ApprRegistry) can switch between using multiple SoundSystems. >> Then I do not understand why it is named >> AbstractSoundSystem and not simply SoundSystem (remember >> AbstractString). > Yes let us clean all that :) > Can you take the lead on that? > We could include the sound package in the release. Because AbstractSoundSystem provides the common interface that is expected to be supported by a given entry in the SoundService providers . Whether that warrants including Abstract in the name is debatable I guess :) >> On Sat, Nov 17, 2012 at 9:33 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Hi pavel >>> >>> In fact the registration default sound system is broken and we should fix it. >>> I forgot what is the problem :) >>> >>>> Hi, >>>> >>>> I would like to discuss the Beeper class a little bit. The main >>>> purpose of this class is to provide Beeper beep message and use >>>> SoundService with respect to current sound enabled settings or VM >>>> implemented primitive for beeping. >>> Yes this was the idea and to remove it from smalltalk. Outright removal is a bit harsh considering what external users may exist. It probably deserves either being put in a deprecated package, or moved to a loadable compat package. Cheers, Henry

Nov. 20, 2012

[Pharo-project] [update 2.0] #20412

by Marcus Denker

20412 ----- Issue 7007: Package System-Change Notification is empy http://code.google.com/p/pharo/issues/detail?id=7007 -- Marcus Denker -- http://marcusdenker.de

Nov. 20, 2012

Re: [Pharo-project] method wrappers package name problem

by StÃ©phane Ducasse

MIT Stef On Nov 19, 2012, at 5:12 PM, Noury Bouraqadi wrote: > Hi, > > I tried MethodWrappers42 under Pharo 2.0-20370. > I've got many tests turn green by simply adding CompiledMetod>>#isMwMethodWrapper that return true. > Attached the mcz file. > > BTW, what is the license of this project? > > Noury > > > > > Afin de contribuer au respect de l'environnement, > > > merci de n'imprimer ce courriel qu'en cas de necessite > > > > > > Please consider the environment before you print > > > > > > <MethodWrappers42-NouryBouraqadi.2.mcz> > On 16 nov. 2012, at 10:43, Tudor Girba wrote: > >> Hi, >> >> Thanks a lot. I now created another package named MethodWrappers42 (instead of MethodWrappers4.2). >> >> Cheers, >> Doru >> >> >> On 15 Nov 2012, at 19:03, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On Nov 15, 2012, at 2:34 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>>> Hi, >>>> >>>> We have a little problem with MethodWrappers. Currently, the package is called MethodWrappers4.2 which completely messes up Monticello in Pharo 1.4. >>>> >>>> So, we (me and Stef) would like to rename it to MethodWrappers42, but for that we need access to the repository. Marcus, could you provide this access? >>>> >>> >>> I actually don't know what state MW is in... there are multiple ports using multiple strategies. The 42 one is for Squeak, I think. >>> >>> I added you, after fighting with SqueakSource (Stef I could not find in the list) >>> >>> Marcus >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >> >> -- >> www.tudorgirba.com >> >> "Don't give to get. Just give." >> >> >> >> >> >> > > Noury Bouraqadi > Ecole des Mines de Douai > http://car.mines-douai.fr/noury > -- > > >

Nov. 20, 2012

Re: [Pharo-project] SortedCollection>>=

by Hernan Wilkinson

I completely agree.... your explanation is far much better than mine :-) On Tue, Nov 20, 2012 at 2:28 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > hmm, imo block comparison is superfluous. > at the point of comparison, if two sorted collections happen to > contain same elements with same order, i think, it is safe to assume > them equal. > > the point is that block behavior influencing only the way how you add > or remove elements from collection, > as for the rest, collections will behave similar for all messages > except from adding/deleting elements. > but adding or deleting elements will immediately make them different, > no matter what sort block is used. > > > On 19 November 2012 16:59, Hernan Wilkinson > <hernan.wilkinson(a)10pines.com> wrote: > > Hi, > > I'm a little surprised with the current SortedCollection #= > > implementation... it is: > > > > = aSortedCollection > > "Answer true if my and aSortedCollection's species are the same, > > and if our blocks are the same, and if our elements are the same." > > > > self species = aSortedCollection species ifFalse: [^ false]. > > sortBlock = aSortedCollection sortBlock > > ifTrue: [^ super = aSortedCollection] > > ifFalse: [^ false] > > > > and my surprise is because it compares the sortBlocks that makes the > > simplest case to fail like this one: > > > > (SortedCollection sortBlock: [ :a :b | a > sortBlock: [ :a :b | a > > > One could argue that if we remove the sortBlock comparison then : > > > > (SortedCollection sortBlock: [ :a :b | a > sortBlock: [ :a :b | a > b ]) > > > > would return true... but is that wrong? ... or is the philosophy to use > the > > message #hasEqualElements: on this cases? > > > > BTW, VisualWorks implementation is the same as pharo, but the > > BlockClosure>>= is different and that's why it works as at least I > expected > > :-) > > > > Bye, > > Hernan > > > > -- > > HernÃ¡n Wilkinson > > Agile Software Development, Teaching & Coaching > > Phone: +54 - 011 - 6091 - 3125 > > Mobile: +54 - 911 - 4470 - 7207 > > email: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > > > > > > -- > Best regards, > Igor Stasenko. > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Nov. 20, 2012

Re: [Pharo-project] [ANN] Limbo: a simple shell wrapper for NativeBoost

by Max Leske

On 19.11.2012, at 21:48, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 19 November 2012 17:45, Max Leske <maxleske(a)gmail.com> wrote: >> >> On 19.11.2012, at 21:37, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Okay, after i saw C code in limbo.c >>> i can clearly tell, that read_buffers() function can be implemented >>> purely on smalltalk using nativeboost. >>> >>> as for run_command() function, you should try to also implement it as >>> a series of system calls using nativeboost ffi. >>> it is possible. >>> >>> The most issues would be is to account for scheduler to make sure that >>> no-one can interrupt the process between critical parts of code (like >>> VM scheduler). >> >> :-/ sounds trickyâ¦ >> > nope. this part is actually easy: > > [ something which should not interrupt] forkAt: Processor highestPriority. Sweet. I'll give it a try. > >>> >>> You should really consider avoiding having C code at all.. because at >>> the end it doesn't makes things any simpler comparing to having extra >>> VM plugin (and knowing how to deal with it - compile/copy/distribute >>> with VM) for users. >>> >> >> Good to know! >> Now that I have a working version in C I think that it should be a lot easier to write the equivalent NativeBoost code since I know what actually to code :) > > Indeed. :) > >> It's also pretty easy to just replace the call to the library with the NB code in Limbo, so any code using the library will keep on working. >> >> Anybody willing to write this in NativeBoost is more than welcome, I'll have to stop working on it for the moment. >> >>> But anyways, good to see there's brave people who don't fear to swim >>> in those waters :) >>> >> >> Thanks :) >> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Nov. 20, 2012

Re: [Pharo-project] SortedCollection>>=

by Igor Stasenko

hmm, imo block comparison is superfluous. at the point of comparison, if two sorted collections happen to contain same elements with same order, i think, it is safe to assume them equal. the point is that block behavior influencing only the way how you add or remove elements from collection, as for the rest, collections will behave similar for all messages except from adding/deleting elements. but adding or deleting elements will immediately make them different, no matter what sort block is used. On 19 November 2012 16:59, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: > Hi, > I'm a little surprised with the current SortedCollection #= > implementation... it is: > > = aSortedCollection > "Answer true if my and aSortedCollection's species are the same, > and if our blocks are the same, and if our elements are the same." > > self species = aSortedCollection species ifFalse: [^ false]. > sortBlock = aSortedCollection sortBlock > ifTrue: [^ super = aSortedCollection] > ifFalse: [^ false] > > and my surprise is because it compares the sortBlocks that makes the > simplest case to fail like this one: > > (SortedCollection sortBlock: [ :a :b | a sortBlock: [ :a :b | a > One could argue that if we remove the sortBlock comparison then : > > (SortedCollection sortBlock: [ :a :b | a sortBlock: [ :a :b | a > b ]) > > would return true... but is that wrong? ... or is the philosophy to use the > message #hasEqualElements: on this cases? > > BTW, VisualWorks implementation is the same as pharo, but the > BlockClosure>>= is different and that's why it works as at least I expected > :-) > > Bye, > Hernan > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > -- Best regards, Igor Stasenko.

Nov. 20, 2012