- Pharo-dev - lists.pharo.org

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

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

by StÃ©phane Ducasse

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. 8, 2013

Re: [Pharo-dev] cog svn tracker setup

by StÃ©phane Ducasse

If I fully understand what you did this is cool :) Stef On Oct 8, 2013, at 8:28 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I spent some time setting up a git tracker for the cog svn repository. > This should help us reducing the merge errors for the pharo-vm, when picking changes > from eliot's branch on http://squeakvm.org/svn/squeak/branches/Cog > > It takes a prepared zip with the proper meta information for git-svn from here > http://files.pharo.org/vm/src/cog-git-svn-track.zip > and updates the separate repositories from the github squeakvm project > http://github.com/squeakvm/ > > > Currently this is a very fragile setup, since git and svn:externals are not very > compatible. However, it does the trick for our purposes. > > > The following steps are run on a daily basis: > --------------------------------------------- > > https://ci.inria.fr/pharo/view/Helper/job/Cog-SVN-Tracker/ > > 1. update both of the commonly shared plugin directories > 2. fetch on the latest svn version on the 'svn' for cog > 3. load the plugin repositories in with 'git subtree' on the 'master' branch on cog > 4. merge the 'master' branch with the 'svn' branch > 5. push > > > Steps to do > ----------- > - setup a proper mergepoint somewhere in the past of pharo-vm (that requires git black magic) > - pharo-vm has to merge with the latest changes from cog (that requires VM knowledge)

Oct. 8, 2013

Re: [Pharo-dev] Pharo Sprint Lille 18th October

by Erwan Douaille

count me in :) (afternoon) 2013/10/8 Noury Bouraqadi <bouraqadi(a)gmail.com> > I'll be traveling, so I won't make it. > Hope to attend next time. > > Noury > On 8 oct. 2013, at 15:40, Marcus Denker wrote: > > > What? Pharo Sprint > > When? Friday, 18th October, slowly starting at 9:30am > > > > Where? > > RMoD, Inria Lille, Building B, third floor > > http://rmod.lille.inria.fr/web/pier/contact > > > > As the building is not open, please contact us before if you plan to > come. > > > > <IMG_1118.jpeg> > > > > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Oct. 8, 2013

Re: [Pharo-dev] Pharo Sprint Lille 18th October

by Noury Bouraqadi

I'll be traveling, so I won't make it. Hope to attend next time. Noury On 8 oct. 2013, at 15:40, Marcus Denker wrote: > What? Pharo Sprint > When? Friday, 18th October, slowly starting at 9:30am > > Where? > RMoD, Inria Lille, Building B, third floor > http://rmod.lille.inria.fr/web/pier/contact > > As the building is not open, please contact us before if you plan to come. > > <IMG_1118.jpeg>

Oct. 8, 2013

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

by Pavel Krivanek

I'm quite close to have an updated list of Morphic core classes and methods. Stay tunned :-) -- Pavel 2013/10/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > thanks I will have a look. > > 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. 8, 2013