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

Re: [Pharo-project] Issue 1644: BrowserEnvironment(Object)>>doesNotUnderstand: #forPackage:

by Stan Shepherd

Stan Shepherd wrote: > > VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: > #10074] > Image: PharoCore1.0rc1 [Latest update: #10500] > actually: pharo1.0-10500-rc1web09.12.1 > Class browser used (if applicable):O2PackageBrowserAdaptor > > Steps to reproduce: > 1.Open O2PackageBrowserAdaptor > 2.Right click (Linux) on a class > 3.Refactoring scope, package > > > BrowserEnvironment(Object)>>doesNotUnderstand: #forPackage: > Receiver: Smalltalk > Arguments and temporary variables: > aMessage: forPackage: a PackageInfo(Morphic) > exception: MessageNotUnderstood: BrowserEnvironment>>forPackage: > resumeValue: nil > Receiver's instance variables: > label: nil > searchStrings: nil > > OR2CmdPackageEnvironment>>environment > Receiver: an OR2CmdPackageEnvironment > Arguments and temporary variables: > package: a PackageInfo(Morphic) > Receiver's instance variables: > target: O2ClassNode<Morph> > requestor: an O2EnhancementColumn(Morph) > > ... > DavidRoethlisberger wrote: > > I fixed this in latest O2-Refactory-DavidRoethlisberger.8 at > http://www.squeaksource.com/EnhancedOB > Hi, this did fix that bug. Now it opens a OR2PackageBrowser that: OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols (left click on a class) OBClassCategoryNode(Object)>>doesNotUnderstand: #isPackage (right click package) Is this: Simon Denier wrote: > > However, the primary annoyance right now is the dichotomy between the OB > new framework and the O2 derived for David's work. The problem is that > now, whenever the tools changed in OB (especially refactoring support), O2 > can not follow and it breaks the tools in the package browser. > ? > i.e. is it sensible to report each bug in this area? ...Stan -- View this message in context: http://n2.nabble.com/Issue-1644-BrowserEnvironment-Object-doesNotUnderstand… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 23, 2009

[Pharo-project] Exploiting a new method trailer format(s)

by Igor Stasenko

Hello guys, i am a dreamer. Did i say that? Yesterday i started coding a new class, called a SourceCodeManager which will eventually replace the old stuff with SourceFileArray, RemoteString manual parsing preambles , like (stephaneducasse 2/4/2006 20:32 Â· accessing Â· 2 implementors Â· in no change set Â· ) etc etc.. Initially, this facility will be responsible for retrieving a preamble info + source by given sourcePointer. But this is not all. There is a basic class, BasicSourceCodeManager which declares protocol, so you can make a subclass of it. Also, it doesn't forcing you to use sourcePointer to be only integer values. This means, that by fusing a new trailer formats + new, more flexible, source code manager we can make a great leap towards the future: use a remote storage for our source code, publicly available. Use it in a fashion, envisioned by Goran (DeltaStreams) + techniques, used by git (add, commit, push ), easily migrate the code, browse other's update streams , diff , merge etc etc.. These thoughts can't leave my mind once i started thinking how small the efforts needed to make things rolling: - JSON (already there http://www.squeaksource.com/JSON) + CouchDB (alredy there http://www.squeaksource.com/CouchDB, but have to be revised... no idea why it using curl, while squeak has own means to use HTTP stuff) + write CouchDBCodeManager (to be implemented) you know what it means? It means that any code which you accepting in browser, could be automatically posted on server. And you can even configure image to not use local files at all! CouchDB is extremely easy to use and fits for version-tracking, because its inherently supports document versioning. -- Best regards, Igor Stasenko AKA sig.

Dec. 23, 2009

Re: [Pharo-project] What is the status of the methodTrailer

by Nicolas Cellier

Hi Alexandre, I missed that probably... which changes ? Can you re-send at my gmail address? 'nicolas cellier aka nice' replaceAll: Character space with: $. ifrance is not that reliable... Nicolas 2009/12/23 Alexandre Bergel <alexandre(a)bergel.eu>: > I also contacted Nicolas C about his changes. > > Alexandre > > > On 23 Dec 2009, at 13:33, StÃ©phane Ducasse wrote: > >> Igor >> >> I saw that method trailer were pushed into squeak. >> Do you plan to provide us a version for pharo? >> Or will we have to dig into squeak? >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2009

Re: [Pharo-project] What is the status of the methodTrailer

by StÃ©phane Ducasse

Thanks a lot. On Dec 23, 2009, at 2:25 PM, Igor Stasenko wrote: > 2009/12/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> i made a changesets which should work ok on both forks. >>>> Lying over there >>>> http://bugs.squeak.org/view.php?id=7428 >>>> >>>> you can pick them up and see if they work for you.. >> >> >> Ok I did not see this mail. >> I do not read squeak-dev. >> >>>> Generally, after applying >>>> >>>> CompiledMethodTrailer-classes.3.cs >>>> trailers-utf8.1.cs >>>> trailers-phase1.1.cs >>>> trailers-phase2.1.cs >>>> trailers-phase3.2.cs >>>> pharo-phase4.1.cs >>>> >>>> check if you still having senders >>>> >>>> generate: #(0 0 0 0) >>>> >>>> and change them to just >>>> >>>> generate >>>> >>>> >>>> then , when you ready to convert, load : >>>> trailers-converting.1.cs >>>> >>>> and finally load: >>>> >>>> trailers-cleanup.1.cs >>>> >>>> after that, you could get DNUs, only if some obscure code still using >>>> a collection (usually #(0 0 0 0)) as trailer, instead of >>>> CompiledMethodTrailer instance. >>>> >>>> Alternatively, if you don't want to get an image into unusable state, >>>> before running a conversion, put halt in ArrayedCollection>>createMethod:header: >>>> >>> Clarification: do not run conversion untill you fix every place which >>> using old format. >>> Load some code from MC, play with traits etc.. and see if it will halt >>> in this method. >>> If not, then you are ready for conversion. >> >> Ok can you help doing that? ie If we have problems be present :) >> Because I have no problem getting that in pharo but I do not want to do it >> blindly. > > I will try loading .cs in the latest code image, once i get home today. > And will tell you if there something more needs to be fixed. > > >> So >> >>>> to trap all of the places which still need to be fixed for using a new trailers. >>>> >>>>> Stef >>>>> >>>>> _______________________________________________ >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 23, 2009

Re: [Pharo-project] What is the status of the methodTrailer

by Igor Stasenko

2009/12/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> i made a changesets which should work ok on both forks. >>> Lying over there >>> http://bugs.squeak.org/view.php?id=7428 >>> >>> you can pick them up and see if they work for you.. > > > Ok I did not see this mail. > I do not read squeak-dev. > >>> Generally, after applying >>> >>> CompiledMethodTrailer-classes.3.cs >>> trailers-utf8.1.cs >>> trailers-phase1.1.cs >>> trailers-phase2.1.cs >>> trailers-phase3.2.cs >>> pharo-phase4.1.cs >>> >>> check if you still having senders >>> >>> generate: #(0 0 0 0) >>> >>> and change them to just >>> >>> generate >>> >>> >>> then , when you ready to convert, load : >>> Â trailers-converting.1.cs >>> >>> and finally load: >>> >>> Â trailers-cleanup.1.cs >>> >>> after that, you could get DNUs, only if some obscure code still using >>> a collection (usually #(0 0 0 0)) as trailer, instead of >>> CompiledMethodTrailer instance. >>> >>> Alternatively, if you don't want to get an image into unusable state, >>> before running a conversion, put halt in ArrayedCollection>>createMethod:header: >>> >> Clarification: do not run conversion untill you fix every place which >> using old format. >> Load some code from MC, play with traits etc.. and see if it will halt >> in this method. >> If not, then you are ready for conversion. > > Ok can you help doing that? ie If we have problems be present :) > Because I have no problem getting that in pharo but I do not want to do it > blindly. I will try loading .cs in the latest code image, once i get home today. And will tell you if there something more needs to be fixed. > So > >>> to trap all of the places which still need to be fixed for using a new trailers. >>> >>>> Stef >>>> >>>> _______________________________________________ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Dec. 23, 2009

Re: [Pharo-project] What is the status of the methodTrailer

by StÃ©phane Ducasse

>> i made a changesets which should work ok on both forks. >> Lying over there >> http://bugs.squeak.org/view.php?id=7428 >> >> you can pick them up and see if they work for you.. Ok I did not see this mail. I do not read squeak-dev. >> Generally, after applying >> >> CompiledMethodTrailer-classes.3.cs >> trailers-utf8.1.cs >> trailers-phase1.1.cs >> trailers-phase2.1.cs >> trailers-phase3.2.cs >> pharo-phase4.1.cs >> >> check if you still having senders >> >> generate: #(0 0 0 0) >> >> and change them to just >> >> generate >> >> >> then , when you ready to convert, load : >> trailers-converting.1.cs >> >> and finally load: >> >> trailers-cleanup.1.cs >> >> after that, you could get DNUs, only if some obscure code still using >> a collection (usually #(0 0 0 0)) as trailer, instead of >> CompiledMethodTrailer instance. >> >> Alternatively, if you don't want to get an image into unusable state, >> before running a conversion, put halt in ArrayedCollection>>createMethod:header: >> > Clarification: do not run conversion untill you fix every place which > using old format. > Load some code from MC, play with traits etc.. and see if it will halt > in this method. > If not, then you are ready for conversion. Ok can you help doing that? ie If we have problems be present :) Because I have no problem getting that in pharo but I do not want to do it blindly. So >> to trap all of the places which still need to be fixed for using a new trailers. >> >>> Stef >>> >>> _______________________________________________

Dec. 23, 2009

Re: [Pharo-project] What are MethodDictionary faults?

by StÃ©phane Ducasse

> Hi folks: I am trying to understand ImageSegment methods like activeClasses, swapOutInactiveClasses, discoverActiveClasses among others. One of the comments of those methods says: > > "NOTE: discoverActiveClasses uses Squeak's ability to detect and recover from faults due to a nil method dictionary. It staches the method dict in with the organization during the time when discovery is in progress (Gag me with a spoon). This is why the faults need to be cleared promptly before resuming normal work with the system. It is also important that classes *do not* refer directly to their method dictionary, but only via the accessor message." > > So, it seems to HACK (it forces a fault) this MD fault recover to discover inactive classes and other things. Ok, forget that hack for a moment. > > What questions is, what are these faults? Why a method dictionary can be in nil ? How is this produced ? And how is it fixed? > > I saw for example this: > > Behaviour>>methodDict > methodDict == nil ifTrue: [self recoverFromMDFaultWithTrace]. > ^ methodDict > > > But again...how can that be nil ??? VM code put it to nil. The idea is that the methodDict is stored in the class or method cat and nil is put in place of the methodDict. Then when the VM detects that the methodDict is nil then it copies the methodDict stored into the category This way you know which class has been used during your interaction. We tried to use it with mathieu but we often got all the classes back on place. And it crashed a lot :) Stef > > Thank you very much. > > Marian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 23, 2009

[Pharo-project] What are MethodDictionary faults?

by Mariano Martinez Peck

Hi folks: I am trying to understand ImageSegment methods like activeClasses, swapOutInactiveClasses, discoverActiveClasses among others. One of the comments of those methods says: "NOTE: discoverActiveClasses uses Squeak's ability to detect and recover from faults due to a nil method dictionary. It staches the method dict in with the organization during the time when discovery is in progress (Gag me with a spoon). This is why the faults need to be cleared promptly before resuming normal work with the system. It is also important that classes *do not* refer directly to their method dictionary, but only via the accessor message." So, it seems to HACK (it forces a fault) this MD fault recover to discover inactive classes and other things. Ok, forget that hack for a moment. What questions is, what are these faults? Why a method dictionary can be in nil ? How is this produced ? And how is it fixed? I saw for example this: Behaviour>>methodDict methodDict == nil ifTrue: [self recoverFromMDFaultWithTrace]. ^ methodDict But again...how can that be nil ??? Thank you very much. Marian

Dec. 23, 2009

Re: [Pharo-project] What is the status of the methodTrailer

by Igor Stasenko

2009/12/23 Igor Stasenko <siguctua(a)gmail.com>: > 2009/12/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Igor >> >> I saw that method trailer were pushed into squeak. >> Do you plan to provide us a version for pharo? >> Or will we have to dig into squeak? >> > > i made a changesets which should work ok on both forks. > Lying over there > http://bugs.squeak.org/view.php?id=7428 > > you can pick them up and see if they work for you.. > > Generally, after applying > > CompiledMethodTrailer-classes.3.cs > trailers-utf8.1.cs > trailers-phase1.1.cs > trailers-phase2.1.cs > trailers-phase3.2.cs > pharo-phase4.1.cs > > check if you still having senders > > generate: #(0 0 0 0) > > and change them to just > > generate > > > then , when you ready to convert, load : > Â trailers-converting.1.cs > > and finally load: > > Â trailers-cleanup.1.cs > > after that, you could get DNUs, only if some obscure code still using > a collection (usually #(0 0 0 0)) as trailer, instead of > CompiledMethodTrailer instance. > > Alternatively, if you don't want to get an image into unusable state, > before running a conversion, put halt in ArrayedCollection>>createMethod:header: > Clarification: do not run conversion untill you fix every place which using old format. Load some code from MC, play with traits etc.. and see if it will halt in this method. If not, then you are ready for conversion. > to trap all of the places which still need to be fixed for using a new trailers. > >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Dec. 23, 2009

Re: [Pharo-project] Fwd: A design question

by StÃ©phane Ducasse

>> > > I was thinking more of the annoyance it poses when recovering lost changes after you've ran tests, but sure, the performance boost is nice to have as well :) > > Btw, I took a short look at the RPackage code, cool > looked to me like quite a few of the add / addNamed: methods could be rewritten so one uses the other. > Eases maintanance if the actual adding is only defined in one place :) Yes it was like that but I changed because I do not remember why. I duplicated the code because I could not find a nice way to layer it. The version because the internal representation was layered. > Some API inconsistencies I'd like to see fixed: > > - for adding classes, if you pass in metaclass, it will add the class. Yes this is the invariant of a RPackage: the list of classes only contain class not metaclasses. I always keep class to avoid to have 'Point class' symbol or think like that. This is like that in RBEnvironment. Now the methods can be from the class and the metaclass. > - for adding classes by name, if you pass in a metaclass name, it will raise an error. Yes this is by design. :) No metaclass name: I do not want to have to do string submatching ' class' kind of stuff > - IIRC, atm it's sort of mix and match of what sort of argument is allowed for the different things you can add by name. Can you tell me which ones? > - define a consistent expected argument type for the name: methods. Either require them to implement the asSymbol method, or require them to be symbols. > > One last question - As far as I can see, there's no automatic removal of definitions from other packages if they exist when you add something to a package. > Is this supposed to be the resonsibility of the tools using them? Yes because like that we can have methods belonging to multiple packages > Either way, please, please, please, also implement Announcements for the different kind of changes. If you want to help on that please do.

Dec. 23, 2009