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

Re: [Pharo-dev] Announcements & inter-thread communication

by stepharo

Thanks for your questions. My take is - I would minimize thread and fork. I have the feeling that some people forgot or never knew that when we fork a process we have to pay attention to sync points and race condition. - About Announcements - Ideally we would like to remove the changed:/update: and replace it by annoucements. Now it will take time because the widgets are not expecting Annoucements. Now to your point! "Now you might say that the programmer should know enough about the structure of their threaded code to wrap the action in as critical section, but Announcements are a DECOUPLING mechanism, and maybe a THIRD PARTY library subscribes to an Announcement that later someone else wraps in a fork, and no-one notices possible race conditions created." Yes!!! I like your ideas: " With this arrangement, a third party subscribed to someone else's announcement, that is quietly changed to be wrapped by forked thread, the third party's code now fails EARLY and OBVIOUS, rather than letting subtle race conditions occur at random times. " This is the kind of vision I like :) Thanks for putting this on the table. Let us see what others will say. Stef Le 5/12/14 22:10, Ben Coman a Ã©crit : > _BACKGROUND_ > > In relation to... > https://pharo.fogbugz.com/default.asp?13182 > "Refactor MCFileRepositoryInspector >> versionSearchAccept:" > > I am reviewing... > https://pharo.fogbugz.com/default.asp?13007 > "Cannot integrate a slice with monticello (red square in the UI)" > > and in general considering how Monticello uses multiple threads to > allow you to type in the filter while its downloading info from the > remote repository (which would be good to have more of this sort thing). > > Looking back at build 30814 just prior to slice 13007 being integrated, > I notice that MCFileRepositoryInspector>>setRepository:workingCopy: [1] > forks and sends #refresh, which sends #changed: #packageList. > > and MCFileRepositoryInspector>>packageSearchAccept: [2] > also forks and sends #changed: #packageList > > So there were three threads (including UI [3]) modifying object state, > which was compounded by #packageList method doing a lot of work. > Issue 13007 worked around this by moving the work of #packageList out > to #packageListUpdate, and moved the #changed: sends from [1] & [2] > also out into #packageListUpdate (and wrapped in a #defer:). > > > _QUESTIONS_ > > Now I am considering doing the same for issue 13182 > #versionSearchAccept:, and considering Pharo's goal is to replace all > Dependents/#changed: mechanisms with Announcements. > > 1. So I am wondering if that would be a better direction to address this? > > Then I wonder about how Announcements interact with threads. I see > that SubscriptionRegistry>>deliver: #protect's the generation of > /interestedSubscriptions/, but the actual announcement delivery occurs > in the open, in AnnoucemenSubscription>>delvier:, > in the sender's thread. > > So for an example... > > action := [ :it | self inform: 'removing child'.]. > announcer on: RemoveChild do: action. > > /action/ might be executed from different concurrent threads. > > Now you might say that the programmer should know enough about the > structure of their threaded code to wrap the action in as critical > section, but Announcements are a DECOUPLING mechanism, and maybe a > THIRD PARTY library subscribes to an Announcement that later someone > else wraps in a fork, and no-one notices possible race conditions > created. > > 2. So, is there something reasonable we can do to make the > common/easier/safer single-threaded case the default, and make people > work a bit harder to shoot themselves in the foot with multiple threads? > > We could introduce Announcer>>onOtherThread:do: > with the purpose of making use of inter-thread announcements more > explicit in a self documenting way. > > Announcements accidentally passed between threads to Announcer>>on:do: > would generate an exception advising "use #onOtherThread:do: " > with the reasonable expectation that use of #onOtherThread:do: > would follow the pattern... > > announcer onOtherThread: RemoveChild do: [ :it | > myMutex critical: [ self inform: 'removing child' ]. > ]. > > With this arrangement, a third party subscribed to someone else's > announcement, that is quietly changed to be wrapped by forked thread, > the third party's code now fails EARLY and OBVIOUS, rather than > letting subtle race conditions occur at random times. > > > _PROPOSED IMPLEMENTATION_ > > "------------------" > > Announcer>>subscribe: anAnnouncementClass do: aValuable > ^ registry add: ( > AnnouncementSubscription new > announcer: self; > process: Processor activeProcess > announcementClass: anAnnouncementClass; > valuable: aValuable) > "------------------" > > AnnouncementSubscription>>deliver: anAnnouncement > process ~= Processor activeProcess ifTrue: [ > self error: [ 'Cross thread announcements should subscribe > using #onOtherThread:do: ' ]. > ^ (self handlesAnnouncement: anAnnouncement ) ifTrue: [ > [action cull: anAnnouncement cull: announcer] > on: UnhandledError fork: [:ex | ex pass ]] > "------------------" > > Announcer>>threadedSubscribe: anAnnouncementClass do: aValuable > ^ registry add: ( > ThreadedAnnouncementSubscription new > announcer: self; > process: Processor activeProcess > announcementClass: anAnnouncementClass; > valuable: aValuable) > "------------------" > > where ThreadedAnnouncementSubscription essentially functions the same > as the existing AnnoucementSubscription . > > > >

Dec. 7, 2014

Re: [Pharo-dev] RBSmalllintContext>>primitiveComputerLiterals

by stepharo

Rename it: basicComputeLiterals sounds good. > I just noticed RBSmalllintContext>>primitiveComputerLiterals > doesn't seem to follow the typical pattern for that naming convention. > > Without digging to really understand it, I just wondered if it maybe > should be called #computeLiteralsForPrimitive, > or #basicComputerLiterals, or something else... > > cheers -ben > >

Dec. 7, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] e1a077: 40402

by stepharo

+1 Log Message: ----------- 40402 14566 ShoreLine Reporter Integration https://pharo.fogbugz.com/f/cases/14566 > Great work, Marcus, this was a difficult one. > Thanks for your persistence. > > Sven > >

Dec. 7, 2014

Re: [Pharo-dev] Slow TreeListMorph

by stepharo

You know this is not that I like polymorph but I could not stand the look that the people sent me each time (and I did many probably far too many) I did a Squeak presentation. So this is why we should clean Polymorph and may be at the end throw it away with Morphic. Bloc is stabilizing but this is not there. Thanks for helping us. Setf > 2014-12-06 0:27 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>>: > > Anyone knows for what this is used: > > TreeListMorph>> > addSubmorphsAfter: parentMorph fromCollection: aCollection > allowSorting: sortBoolean > "Update the font on each morph." > > |answer| > answer := super addSubmorphsAfter: parentMorph > fromCollection: aCollection allowSorting: sortBoolean. > > "---- THIS TAKES TIME ----" > self scroller submorphsDo: [:i | > i > font: self font; > extent: i minWidth @ i minHeight]. > "---- XXXXX ----" > > ^answer > > > setting the font and extent on all scroller submorphs is extremly > slow. > Try to merge a package with many changes, it takes up to > several minutes until > the DiffMorph shows up. > Removing the above lines makes the DiffMorph much faster and I > can not see > any visual difference. > > nicolai > > > Yeah, try to merge in Squeak, it's quite fast... > > Polymorph is good looking, but if it's superslow, then it totally > misses the point. > I used to disallow this Preference (err... Setting) until it > disappeared... > I just don't understand how people can stand it. > I can't, merge is so essential... > Or I understand a bit more why some git tools are perceived as SO > superior ;) > > But if you found the major contributor, it's a great news ! > > > > > > I'll remove that code, and then we will see what breaks :) > > nicolai

Dec. 7, 2014

Re: [Pharo-dev] Slow TreeListMorph

by Nicolai Hess

2014-12-06 1:26 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2014-12-06 0:27 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > >> Anyone knows for what this is used: >> >> TreeListMorph>> >> addSubmorphsAfter: parentMorph fromCollection: aCollection allowSorting: >> sortBoolean >> "Update the font on each morph." >> >> |answer| >> answer := super addSubmorphsAfter: parentMorph fromCollection: >> aCollection allowSorting: sortBoolean. >> >> "---- THIS TAKES TIME ----" >> self scroller submorphsDo: [:i | >> i >> font: self font; >> extent: i minWidth @ i minHeight]. >> "---- XXXXX ----" >> >> ^answer >> >> >> setting the font and extent on all scroller submorphs is extremly >> slow. >> Try to merge a package with many changes, it takes up to several minutes >> until >> the DiffMorph shows up. >> Removing the above lines makes the DiffMorph much faster and I can not see >> any visual difference. >> >> nicolai >> >> > Yeah, try to merge in Squeak, it's quite fast... > > Polymorph is good looking, but if it's superslow, then it totally misses > the point. > I used to disallow this Preference (err... Setting) until it disappeared... > I just don't understand how people can stand it. > I can't, merge is so essential... > Or I understand a bit more why some git tools are perceived as SO superior > ;) > > But if you found the major contributor, it's a great news ! > > > > I'll remove that code, and then we will see what breaks :) nicolai

Dec. 6, 2014

Re: [Pharo-dev] [Vm-dev] [ANN] ARM Stack VMs available

by Chris Muller

On Fri, Dec 5, 2014 at 11:39 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Juan, > > > On Dec 5, 2014, at 4:56 AM, "J. Vuletich (mail lists)" > <juanlists(a)jvuletich.org> wrote: > >> Hi Folks, >> >> The Squeak process scheduler usually preempts a process only by another one of higher priority. And when the scheduler is ready to go back at the lower priority, it will always resume the same process that was last suspended. The only way for two or more processes of the same priority to share the processor is when the running process calls #wait or #yield. > > No. According to the blue book preempting sends the preempted process > to the back if its run queue so preempting forces a yield. Obviously > this is wrong, but that's the way it was defined. The ObjectWorks & > VisualWorks VMs changed this to work as you describe. Why is that wrong? By sending it to the back, one gets task-switching that acts like real "multitasking" as one would expect in a real multitasking system, without the developer having to put in explicit sends to #yield. Keeping it at the front "enables" multi-processing code to be developed incorrectly so that, one day, when it might ever get to a real multitasking environment, it won't work and it'll be harder to debug since by then its old and probably more complex. #yield is not a good synchronization tool..

Dec. 6, 2014

Re: [Pharo-dev] Repeatable VM crash

by Eliot Miranda

Hi Hilaire, I see you found me :-). Thanks, I'll take a look asap. Probably Monday. On Sat, Dec 6, 2014 at 12:05 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > Le 05/12/2014 22:37, Eliot Miranda a Ã©crit : > > Hi Hilaire, > > > > can you try and concoct an image that crashes from start-up without > > operator intervention? What I mean is that if the expression that > > crashes is the one you give then in a workspace evaluate > > > > Please, give me an email to send privately an URL? > > Thanks > > Hilaire > > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > > -- best, Eliot

Dec. 6, 2014

Re: [Pharo-dev] Repeatable VM crash

by Eliot Miranda

Hi Esteban, plausibly the fix to the latest VM might fix your crash. You might test? Fingers crossed. On Fri, Dec 5, 2014 at 11:26 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yes, but the first step is to be sure you have the latest vm version :) > > Esteban > > > On 05 Dec 2014, at 22:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Hilaire, > > can you try and concoct an image that crashes from start-up without > operator intervention? What I mean is that if the expression that crashes > is the one you give then in a workspace evaluate > > Smalltalk snapshot: true andQuit: true. > (CGDonator firstname: 'Eric' lastname: 'Dupont') = (CGParticipant firstname: > 'Eric' lastname: 'Dupont') > > and then run the saved image. If it crashes then its really easy to debug > because it will be repeatable. If one has to interact with the image > debugging is much more difficult. > > On Fri, Dec 5, 2014 at 1:07 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > >> Hi again, >> >> I must add it occurs from a test or when comparing something like this >> in the Workspace: >> >> (CGDonator firstname: 'Eric' lastname: 'Dupont') = (CGParticipant >> firstname: 'Eric' lastname: 'Dupont') >> >> I get a false returned value printed in the Workspace, then VM crash. >> >> Thanks >> >> Hilaire >> >> >> Le 05/12/2014 21:35, Hilaire a Ã©crit : >> > When playing with equality in a class hierarchy I have repeatable VM >> crash. >> > It is today Pharo VM 3.9-7 from Jenkins and Pharo3. >> > >> > Am I using an out of date VM? >> > >> > Crashdump enclosed >> > >> > Hilaire >> > >> > >> >> >> -- >> Dr. Geo - http://drgeo.eu >> iStoa - http://istoa.drgeo.eu >> >> >> > > > -- > best, > Eliot > > > -- best, Eliot

Dec. 6, 2014

New Cog VMs available

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3163/. CogVM binaries as per VMMaker.oscog-eem.972/r3163 Fix a devilishly tricky bug with 32-bit Spur and PICs in the Cogit. In 32-bit Spur only zero is a valid cache tag, that for Characters, due to SmallIntegers having both 2r11 and 2r01 as valid tags. The cache check prolog collapses these down onto 1 by anding with 1 and hence collapses Character's 2r10 to 0. The cache tag is also tested in the PIC abort routine to distinguish between an MNU abort and an interpret abort. A PIC MNU entry jumps to code that first zeros the cache tag (held in ClassReg) before calling the abort routine, which tests ClassReg and selects the relevant abort processing. Hence in 32-bit Spur if a send site is linked for Character and later extended to a PIC with an interpret case, that interpret case will instead invoke MNU processing. This is rare; first there needs to be a send to a CHaracter, then a send to something else which binds to something that must be interpreted. Ouch. The fix is simple; if a send site that was linked with a zero cache tag (which can only happen in 32-bit Spur) link to an open PIC instead of to a closed PIC, or in the case of an MNU do not link. Add a debug lookup routine that only looks up (and follows forwarding pointers). Add a -breakmnu vm argument that calls warning on an mnu of a specific selector. Fix SmartSyntaxPlugin code generation for Spur of - asOop: old code assumed 4 byte oops & headers - Unsigned old code assumed 32-bit oops Affects AsyncFilePlugin, BochsIA32Plugin & FT2Plgin. Avoid duplication of effort in special selector send forwarding fault handling. Improve stack trace printing for Newspeak and Glue by providing something that assumes the penultimate literal is the selector or an AdditionalMethodState-like thing containing it. Reimplement primitiveCopyObject to work for both pointer and bits objects. This to support a good Object>>clone for Spur. Fix Spur's isWordsOrBytes[NonImm]:. Old code answered true for CompiledMethods. -- best, Eliot

Dec. 6, 2014

Re: [Pharo-dev] How can I specify the bindings when evaluating an expression?

by Nicolai Hess

2014-12-06 11:18 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 05 Dec 2014, at 15:18, stepharo <stepharo(a)free.fr> wrote: > > > > I would like to be able to express > > > > Compiler new > > bindings: { a -> 3. b -> 4}; > > evaluate: 'a + b'; > > result > > and get 7 > > > > How can I do that? > > > > Not directly, as evaluate is just a doitâ¦ but it can be added > as the machinery is there for evaluating in context in the debugger. > > I will have a look but not this weekend. > > Marcus > > > The easiest solution I have found: Smalltalk compiler evaluate:'a+b' notifying: (Dictionary newFrom:{ WorkspaceVariable key:#a value:3. WorkspaceVariable key:#b value:4}) logged:nil The dictionary is used as the receiver for the call to #bindingOf: and WorkspaceVariable acts like a LiteralVariable that implements emitValue/emitStore nicolai

Dec. 6, 2014