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

How to delete an obsolete class ?

by Olivier Auverlot

Hi, In my project, my code has a strange behavior when I'm reading all subclasses of an another class. The following code must visit all the subclasses of PVEStatus but I get a bad result. PVEStatus allSubclasses do: [ :statusDatatype | (aRawStatus at: 'type') = statusDatatype type ifTrue: [ ^ statusDatatype getStatus: aRawStatus callback: self ] ] The answer contains #AnObsoletePVENodeStatus and this class doesn't exist. She doesn't appear in the class browser. I suppose that it's a rest of refactoring. How can I delete this obsolete class ? Best regards Olivier ;-)

Oct. 9, 2013

Re: [Pharo-dev] Please try to reproduce this bug

by Damien Cassou

On Tue, Oct 8, 2013 at 11:40 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > BTW, I had issues w/ ppa this week end during a Hackathon. I wanted my > teammate to install pharo on his Wheezy 7 Debian and it failed. what did you try? If you tried my PPA, then this was a bad idea. The PPA is for Ubuntu only. If someone wants to push Pharo to Debian, I can help. > Now, we had to enable multiarch to get things running. Pretty out of reach > for basic users. multiarch is enabled by default on Debian. And I can't imagine someone using Debian be named a "basic user" :-). > As I had to put stuff on a Wheezy 7 server down the line, the get.pharo.org > thing worked better as I had no admin rights. For sure! -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 9, 2013

Re: [Pharo-dev] Metacello preview in Pharo 2.0

by StÃ©phane Ducasse

> Hi guys, > > because I had problems with Metacello for loading > ConfigurationOfPierVoyage in Pharo 2.0, I tried Metacello Preview > following an advice from Dale. Metacello Preview worked perfectly for > my complex use case. It looks like the Metacello embedded in Pharo 2.0 > is quite buggy. Dale proposes us to include Metacello Preview in Pharo > 2.0 so we don't run into these bugs anymore. > > What do you think? lot of work from what we saw. It took us a lot of time to get Preview in 3.0 > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Oct. 9, 2013

Re: [Pharo-dev] Monticello requiring network access to save a package in a local repository?

by phil＠highoctane.be

Here is the preference for doing just that: http://www.smalltalkhub.com/#!/~philippeback/HOExtras/packages/Settings-Met… In fact, I noticed there was no Settings-Metacello and I created one, along with that single pref in it. Maybe will be useful for future things The metacelloPlatformAttributes has been changed like this and put in a *settings-metacello protocol instead of being in "miscellaneous". metacelloPlatformAttributes "Returns the tags for the conditional platform loading in Metacello. Pay attention the order is important: from most to least general." "For release integrators, we should not have #'pharo1.3x' **and** #'pharo1.4.x'" ^ SmalltalkImage Pharo2Compatible ifTrue: [ #(#squeakCommon #pharo #'pharo2.x' #'pharo2.0.x') ] ifFalse: [ #(#squeakCommon #pharo #'pharo3.x' #'pharo3.0.x') ] . Feel free to integrate :-) Phil

Oct. 9, 2013

Metacello preview in Pharo 2.0

by Damien Cassou

Hi guys, because I had problems with Metacello for loading ConfigurationOfPierVoyage in Pharo 2.0, I tried Metacello Preview following an advice from Dale. Metacello Preview worked perfectly for my complex use case. It looks like the Metacello embedded in Pharo 2.0 is quite buggy. Dale proposes us to include Metacello Preview in Pharo 2.0 so we don't run into these bugs anymore. What do you think? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 9, 2013

Re: [Pharo-dev] external semaphoresâ¦again

by phil＠highoctane.be

Just a note: in a Pharo20, the number is 256, no matter if in OSX or Windows (8 here). In Pharo30 with vmLatest I get the Smalltalk vm maxExternalSemaphores 10000000 indeed. Phil On Tue, Oct 8, 2013 at 11:15 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 7 October 2013 18:01, Henrik Johansen <henrik.s.johansen(a)veloxit.no>wrote: > >> >> On Oct 7, 2013, at 5:40 , Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> >> On 7 October 2013 17:25, Henrik Johansen <henrik.s.johansen(a)veloxit.no>wrote: >> >>> >>> On Oct 7, 2013, at 4:36 , Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> > 1 thing. >>> > >>> > can you tell me what given expression yields for your VM/image: >>> > >>> > Smalltalk vm maxExternalSemaphores >>> > >>> > (if it gives you number less than 10000000 then i think i know what is >>> your problem :) >>> > >>> >>> Uhm, I didn't read your implementation, but the proper thing to do for a >>> VM which doesn't care about the external objects table (splObjs at: 39) >>> growing, is returning nil from maxExternalSemaphores, like it will for >>> pre-Cog VM's. >>> >> >> or.. release VM + image, where image aware of current VM capabilities, >> and refuses to run on older ones, and get rid of all this stuff altogether. >> >> i changed the low-level implementation (C level), but not primitive >> level. sure thing more cleanup & polishing can be done, >> but the changes i made never get reviewed and properly tested (though, >> there was no problems reported since year from when it was introduced, >> except from last unfortunate rollback to Eliot's original >> implementation). >> >> >> I know, which is why I thought you might like the feedback :P >> AFAICT, it would be nice to couple the changes you made with changing >> parameterAt: 49 back to returning nil, as well as returning an error for >> parameterAt: 49 put: that the section is not in use/obsolete, instead of >> returning bogus values. >> >> Though, sounds a bit strange how parameterAt: 49 can return a huge number >> without any changes to the related code (which would then still be reading >> from a 16bit field :P) >> >> >> >> >>> Otherwise, you'll get a domain error when you eventually (yes,yes, it'll >>> take awhile) run out, and maxExternalSemaphoresSilently: tries to set the >>> new max to a value that won't fit in the 16bit header field where it >>> expects to put itâ¦ >>> >>> yes.. theoretically.. but i have gut feeling that your image/setup will >> experience a lot of other different problems (memory consumption/amount of >> available OS handles etc), before you get to that point. And at that point, >> you will need to modify VM/OS/image anyways (or figure how to work around >> limits in other way).. >> >> >> >> Yap, I guess you could say changing to a nil return would be more a >> change to play by established conventions when reporting capabilities/needs >> of the VM than anything with practical impact. >> >> i agree. i will create a bug entry for it then.. > > >> >> Cheers, >> Henry >> > > > > -- > Best regards, > Igor Stasenko. >

Oct. 9, 2013

[pharo-project/pharo-core] 4ac391: 30464

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 4ac39149fd226cfce8204908aeb9a8212a912832 https://github.com/pharo-project/pharo-core/commit/4ac39149fd226cfce8204908… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-08 (Tue, 08 Oct 2013) Changed paths: R Polymorph-Widgets-Themes.package/MorphicUIManager.class/instance/ui requests/messageNames_inMorphicWindowWithInitialSearchString_.st R Polymorph-Widgets-Themes.package/MorphicUIManager.class/instance/ui requests/messageSet_inMorphicWindowLabeled_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script119.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30464.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Tools-VersionBrowser.package/NewVersionBrowser.class/class/protocol/browseVersionsForClass_selector_.st R Tools-Base.package/AbstractTool.class/instance/class/browseCommentVersionsOf_.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/README.md R Tools-Changes.package/ClassCommentVersionsBrowser.class/class/instance creation/browseCommentOf_.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/class/menu/classCommentVersionsListMenu_.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/class/utilities/commentRecordsOf_.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/class/utilities/timeStampFor_class_reverseOrdinal_.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/class/window color/patchworkUIThemeColor.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/definition.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/basic function/diffedVersionContents.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/basic function/reformulateList.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/basic function/scanVersionsOf_.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/basic function/updateListsAndCodeIn_.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/menu/compareToCurrentVersion.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/menu/offerVersionsHelp.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/menu/versionsMenu_.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/misc/classCommentIndicated.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/misc/contentsSymbolQuints.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/misc/priorSourceOrNil.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/misc/selectedClass.st R Tools-Changes.package/ClassCommentVersionsBrowser.class/instance/shout/shoutAboutToStyle_.st M Tools.package/extension/StringHolder/instance/browseVersions.st Log Message: ----------- 30464 11822 remove ClassCommentVersionBrowser https://pharo.fogbugz.com/f/cases/11822 11824 NewVersionBrowser: add #browseVersionsForClass: selector: https://pharo.fogbugz.com/f/cases/11824 11823 remove unneded builder methods (messagenames, messageset) from MorphicUIManager https://pharo.fogbugz.com/f/cases/11823 http://files.pharo.org/image/30/30464.zip

Oct. 9, 2013

Re: [Pharo-dev] external semaphoresâ¦again

by StÃ©phane Ducasse

Hi eliot > that just means your VM don't have external object size cap. > I changed the implementation to not have hard limit (the arbitrary large number > is there just to be "compatible" with previous implementation). > > If you've really done this why haven't you pushed changes back to me? He did. I remember that he asked you for review on the code multiple times. I know because I was asking him to know what we should do. And in addition the code was issue was documented on the Cog bug tracker. > You think I like the limit ?!? ;-). But is your new implementation lock-free? I went to some lengths to make sure that the Cog implementation is thread-safe, by making signalling lock-free. But making it lock-free while allowing growing was too much work. If your new implementation isn't lock-free and/or isn't thread-safe then IMO the cure is worse than the disease, because signals can get lost and that's much harder to diagnose than deal with a limit that can only be set at startup. I will let igor reply for the technical part. But we did some tests with companies doing web dev for a while before pushing this fix in Pharo. Stef

Oct. 9, 2013

Re: [Pharo-dev] about creating Morphic-Widgets

by Pavel Krivanek

Strange, it worked few days ago, I need to contact the admin. However it's not really important because Morphic changed a lot from that time. I tried to reproduce the way how I created the uMorhpic and this is the first outcome. In the first step we should move only classes to a separate package (Morphic-Core) or packages and do not look at methods. For displaying a simple Morph and work with him (moving, clicking...) we need this classes: BorderStyle BorderedMorph Canvas ColorMappingCanvas DamageRecorder DropEvent FormCanvas GrafPort HandMorph KMBuffer KeyboardEvent Morph MorphAnnouncement MorphChanged MorphChangedWithArguments MorphDeleted MorphExtension MorphGotFocus MorphLostFocus MorphOpened MorphicEvent MorphicEventDispatcher MouseButtonEvent MouseEvent MouseMoveEvent MouseOverHandler PasteUpMorph ShadowDrawingCanvas UserInputEvent WorldMorph WorldState You can look at the changeset in the contents browser. No method or class definition is modified. Cheers -- Pavel 2013/10/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I could not download it. > On Oct 7, 2013, at 10:41 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> What about to try to make an update of the uMorphic experiment and >> place selected classes to the standalone package? >> >> http://forum.world.st/little-uMorphic-progress-td3762931.html >> >> We firstly needed to rename Morphic package to Morphic-Base but it is >> already done. >> >> Cheers, >> >> -- Pavel >> >> 2013/10/6 Tudor Girba <tudor(a)tudorgirba.com>: >>> +1 >>> >>> Doru >>> >>> >>> On Sun, Oct 6, 2013 at 10:28 PM, Benjamin >>> <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >>>> >>>> I am in for splitting Morphic in more that one package. >>>> >>>> It makes things really boring to have every thing in one MC Package :( >>>> >>>> Ben >>>> >>>> On Oct 6, 2013, at 8:54 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>> wrote: >>>> >>>> Hi guys >>>> >>>> I started to play with sorting a bit Morphic :) >>>> So I would like to create a new Package Morphics-Widgets with the >>>> following contents. >>>> >>>> >>>> Morphic-Widgets-Basic >>>> SimpleSwitchMorph >>>> MulticolumnLazyListMorph >>>> SimpleButtonMorph >>>> LazyListMorph >>>> IconicButton >>>> ThreePhaseButtonMorph >>>> CalendarMorph >>>> Morphic-Widgets-Pluggable >>>> PluggableTabButtonMorph >>>> PluggableButtonMorph >>>> PluggableTextMorph >>>> PluggableMultiColumnListMorph >>>> PluggableTextMorphWithLimits >>>> PluggableTabBarMorph >>>> PluggableListMorph >>>> Morphic-Widgets-NewList >>>> NewList >>>> NewListRenderer >>>> NewListAdapter >>>> Morphic-Widgets-Tab >>>> >>>> Morphic-Widget-MorphTreeWidget >>>> Morphic-Widget-MorphTreeWidget-Pagination >>>> >>>> I would promote Morphic-Base-ProgressBar -> Morphic-ProgressBar >>>> >>>> So what do you think? >>>> >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> > >

Oct. 9, 2013

Re: [Pharo-dev] external semaphoresâ¦again

by Eliot Miranda

Hi Igor, On Tue, Oct 8, 2013 at 2:27 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 7 October 2013 18:36, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 07.10.2013 um 16:36 schrieb Igor Stasenko <siguctua(a)gmail.com>: >> >> 1 thing. >> >> can you tell me what given expression yields for your VM/image: >> >> Smalltalk vm maxExternalSemaphores >> >> (if it gives you number less than 10000000 then i think i know what is >> your problem :) >> >> It is 10000000 >> >> What would be the problem if it would be smaller? >> >> > that just means your VM don't have external object size cap. > I changed the implementation to not have hard limit (the arbitrary large > number > is there just to be "compatible" with previous implementation). > If you've really done this why haven't you pushed changes back to me? You think I like the limit ?!? ;-). But is your new implementation lock-free? I went to some lengths to make sure that the Cog implementation is thread-safe, by making signalling lock-free. But making it lock-free while allowing growing was too much work. If your new implementation isn't lock-free and/or isn't thread-safe then IMO the cure is worse than the disease, because signals can get lost and that's much harder to diagnose than deal with a limit that can only be set at startup. > > This means, that you can actually change in your image the check and > completely ignore limits > and just keep growing if it necessary. > > Now, since you using VM which don't have a limit, but problem still > persists, > it seems like it somewhere else.. :/ > > i just found that after one merge, my changes get lost > we're just plugged them back in, and it should be back again with newer > VMs.. > but the problem could be more than just semaphores.. if merge broken this, > it may break > many other things, so we need time to check > > I try to look at it some more time. I'm using the pharo-vm from the > launchpad build. Are the changes supposed to be in this one? > > Norbert > > Launchpad? You mean ppa? I can't say i remember all the details how > changes to VM source > gets into ppa distro, and how fast they get there. @Damien, can you > enlighten us? > > > Well, the VM which i downloaded recently using zero-conf script, having > limit back to 256. Just some merge mistake, which now is fixed.. means that > couple builds will use limit-based implementation.. but then > it will be back to my implementaiton. > > > > > > > On 7 October 2013 12:31, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 07.10.2013 um 11:28 schrieb Henrik Johansen < >> henrik.s.johansen(a)veloxit.no>: >> >> >> On Oct 7, 2013, at 11:16 , Norbert Hartl <norbert(a)hartl.name> wrote: >> >> As I need an image that runs longer than 24 hours I'm looking at some >> stuff and wonder. Can anybody explain me the rationale for a code like this >> >> maxExternalSemaphores: aSize >> "This method should never be called as result of normal program >> execution. If it is however, handle it differently: >> - In development, signal an error to promt user to set a bigger size >> at startup immediately. >> - In production, accept the cost of potentially unhandled interrupts, >> but log the action for later review. >> See comment in maxExternalObjectsSilently: why this behaviour is >> desirable, " >> "Can't find a place where development/production is decided. >> Suggest Smalltalk image inProduction, but use an overridable temp >> meanwhile. " >> | inProduction | >> self maxExternalSemaphores >> ifNil: [^ 0]. >> inProduction := false. >> ^ inProduction >> ifTrue: [self maxExternalSemaphoresSilently: aSize. >> self crTrace: 'WARNING: Had to increase size of semaphore signal >> handling table due to many external objects concurrently in use'; >> crTrace: 'You should increase this size at startup using >> #maxExternalObjectsSilently:'; >> crTrace: 'Current table size: ' , self maxExternalSemaphores >> printString] >> ifFalse: ["Smalltalk image" >> self error: 'Not enough space for external objects, set a larger size >> at startup!' >> "Smalltalk image"] >> >> I have reported this once but got no feedback so I like to have a few >> opinions. >> >> The report is here: https://pharo.fogbugz.com/f/cases/10839/ >> >> Norbert >> >> >> The rationale is that inProduction would be some global setting, not yet >> in place when the code was writtenâ¦ >> Excessive simultaneous Semaphore usage is something that should be caught >> during development, in which case it's better to get an active >> notification, than having it logged somewhere. >> >> >> Agreed. But didn't work in my case because it needed roughly 20 hours and >> an instable remote backend to trigger the problem. And somehow I forgot to >> install my logger as Transcript so there is no warning message. I saw only >> dead images in the morning. >> This not satisfactory but on the other hand this type of problems are >> hard to solve anyway. My feeling tells me there is more to discover. >> Sockets resources get unregistered at finalization time but this didn't >> work either. I would have said that the unlikely situation that no garbage >> collection ran could be the case. But it can't because in >> ExternalSemaphoreTable>>#freedSlotsIn:ratherThanIncreaseSizeTo: there is >> explicit garbage collection. >> >> If I've understood correctly, it's moot on newer Pharo VM's, where >> there's no limit on the semtable size, but for legacy code a startup item >> setting size using maxExternalObjectsSilently: (as suggested in the Warning >> text), is still a more proper fix than setting inProduction to true and >> crossing your fingers hoping no signals will be lost during table growth. >> >> >> Ah, I didn't know about the risk of loosing signals while resizing the >> table. Thanks for that. Don't get me wrong I wasn't proposing to set >> inProduction in effect. I don't think that automatically growing resource >> management is a proper way to design a system. There is always a range of >> resources you need for your use case. Not setting an upper bound for this >> just covers leaking behavior. >> >> Norbert >> >> >> > > > -- > Best regards, > Igor Stasenko. > > > > > > -- > Best regards, > Igor Stasenko. > -- best, Eliot

Oct. 8, 2013