- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] New Cog VMs available

by Eliot Miranda

Oops, for http://www.mirandabanda.org/files/Cog/VM/VM.r3163/ read http://www.mirandabanda.org/files/Cog/VM/VM.r3164 On Sat, Dec 6, 2014 at 1:53 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > ... 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 > -- best, Eliot

Dec. 7, 2014

Re: [Pharo-dev] Duration year

by stepharo

I love Chalten :) But you know it :) Stef Le 2/12/14 11:53, Maximiliano Taborda a Ã©crit : > Hi all. > > The same examples using ChaltÃ©n: > February twentyninth, 2012 next: 1 yearMeasure. "=> February > 28th, 2013" > March first, 2011 next: 1 yearMeasure. "=> March 1st, 2012" > March first, 2011 next: 12 monthsMeasure. "=> March 1st, 2012" > > Hilaire, In ChaltÃ©n a year is a year so you don't need to care about > of the number of days in it. > > Regards. > Maxi > > > 2014-12-02 16:37 GMT-03:00 Chris Cunningham <cunningham.cb(a)gmail.com > <mailto:cunningham.cb@gmail.com>>: > > GenericYear does this. The generic Year will take > '2/29/2000' asDate + 1 year "=> 28 February 2001" > In other words, we want it at the same time next year; more > importantly the same month and close to what we have now. > Also: > '3/1/2001' asDate - 1 year "=> 1 March 2000" > Still, same month - we want to be at the beginning of the month > the previous year. > > Basically, my idea (and, more importantly, what I expect - hence > my code) is that I want to pretend that we do have a field-based > representation and make it work that way. except better (since > there is no 2/29/2001). > > > Ej, which one of the followings is OK? > > '2011-03-01' asDate + 1 year "=> 2012-02-29" > > Well, I have a bug here. That needs to be fixed. > > -cbc > > > On Tue, Dec 2, 2014 at 8:34 AM, Sean P. DeNigris > <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > Esteban A. Maringolo wrote > > Ej, which one of the followings is OK? > > '2012-02-29' asDate + 1 year "=> 2013-02-28" > > '2011-03-01' asDate + 1 year "=> 2012-02-29" > > One solution (just ignore the source ha ha) - > http://msdn.microsoft.com/en-us/library/system.datetime.addyears%28v=vs.110… > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Duration-year-tp4791727p4793656.html > Sent from the Pharo Smalltalk Developers mailing list archive > at Nabble.com. > > >

Dec. 7, 2014

Re: [Pharo-dev] Monticello and Fuel

by stepharo

Thanks Mariano. If we could optimize common case = no change in superclass shape change and get that one fast it would be so great. Stef

Dec. 7, 2014

Re: [Pharo-dev] Monticello and Fuel

by stepharo

> What is your use case for needing it faster? > * Just every day developer use? > * CI automation? > * Something in production? Everything :) > cheers -ben > >

Dec. 7, 2014

Re: [Pharo-dev] Monticello and Fuel

by stepharo

There was a Tanker prototype. Now Levente did long time ago an analysis and he mentioned that the compilation was not that slow. Now I would love to have a binary format (fuel) as part of the mcz. because when we started Fuel it was the goal (I remember being shocked by the speed of Parcels 30 min to load RB in VW25 and 3 seconds in VW 30) Stef > Hi all, > > I'm just wondering. > > Would it work to have a package format based on Fuel? > > Would that make loading faster? > > Does it already exist? > > Thanks, > > Thierry

Dec. 7, 2014

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