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

Re: [Pharo-project] Roeltyper

by StÃ©phane Ducasse

On Dec 28, 2011, at 6:07 PM, Lukas Renggli wrote: >>>>> Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly. >>> >>> Maybe you should rather use RBRefactoryTyper? It is slower, because it >>> needs to parse all the involved source code; but it works correctly >>> and uses a similar (even more powerful) inferencing algorithm. >> >> This is true that roel only checked within a method (from my memory) so with short method this is difficult to get >> really good result. > > RoelTyper and RBRefactoryTyper do essentially the same: For class- and > inst-vars they look at all the compiled methods that refer to these > variables. RoelType does an abstract byte-code interpretation to > figure out the assignments and the messages sent to the variables; > RBRefactoryTyper parses the methods and figures out the assignments > and messages sent using the AST. Then they both run a very similar > algorithm to figure out the most likely kind of object hold in the > variables. They do not necessarily report the same classes in the end, > because the heuristics are different. Also RBRefactoryTyper goes a > step further and tries to figure out type of elements inside > collection types. > > For method arguments and temporaries they both only look at a single > method (there are obviously no other references to the temporaries and > arguments). Consequently they both deliver bad results for arguments > and temporaries. Yes when I looked at RB (in 99) I guess that they also used existing instances to try to get more information but mainly for instance variables. I would really like to see more work around practical tools that can help us. I have the work on type inference from francisco garau on my hard-disc. But this is a pity that nobody build on top of that. Stef > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Dec. 28, 2011

Re: [Pharo-project] Roeltyper

by Lukas Renggli

>>>> Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly. >> >> Maybe you should rather use RBRefactoryTyper? It is slower, because it >> needs to parse all the involved source code; but it works correctly >> and uses a similar (even more powerful) inferencing algorithm. > > This is true that roel only checked within a method (from my memory) so with short method this is difficult to get > really good result. RoelTyper and RBRefactoryTyper do essentially the same: For class- and inst-vars they look at all the compiled methods that refer to these variables. RoelType does an abstract byte-code interpretation to figure out the assignments and the messages sent to the variables; RBRefactoryTyper parses the methods and figures out the assignments and messages sent using the AST. Then they both run a very similar algorithm to figure out the most likely kind of object hold in the variables. They do not necessarily report the same classes in the end, because the heuristics are different. Also RBRefactoryTyper goes a step further and tries to figure out type of elements inside collection types. For method arguments and temporaries they both only look at a single method (there are obviously no other references to the temporaries and arguments). Consequently they both deliver bad results for arguments and temporaries. Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 28, 2011

Re: [Pharo-project] Pharo Launcher app

by Noury Bouraqadi

Sounds Cool. It's a pity that it's for Lion only. Noury -- http://twitter.com/#!/NouryBouraqadi On 28 dÃ©c. 2011, at 00:56, Fernando Olivero wrote: > Hi, i created an app for launching Pharo, which remembers the last > opened vm+image . > Maybe some of you find it useful (for MacOS X) > Fernando > pd:Working on a version with arguments entry also. > <pharococoaUI.png><PharoCocoaUI.app.zip>

Dec. 28, 2011

Re: [Pharo-project] Roeltyper

by StÃ©phane Ducasse

On Dec 28, 2011, at 11:56 AM, Lukas Renggli wrote: >> Did you publish the patch? > > I guess that was fixed a long time ago. At least it does not crash my > image, it just produces wrong results. > >> What is wrong? >> What would be good is to remove the VW compliant classes and layers because like that it should be really simple. > > It is highly complex, because it does an abstract interpretation of > the bytecodes and getting the offsets of the variables right is not > trivial. In fact in the past 2 years several people have tried to fix > (including me) and didn't get it to work. > >>> Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly. > > Maybe you should rather use RBRefactoryTyper? It is slower, because it > needs to parse all the involved source code; but it works correctly > and uses a similar (even more powerful) inferencing algorithm. This is true that roel only checked within a method (from my memory) so with short method this is difficult to get really good result. I wonder if he compared with RBtyper. I know that he did manual verification and build a system for doing that in VW. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Dec. 28, 2011

Re: [Pharo-project] changing the class of an existing object to a subclass

by Ben Coman

Henrik Sperre Johansen wrote: > On 28.12.2011 05:46, Ben Coman wrote: >> <snip> > adoptInstance: only works when the object shapes are the same. (It > only switches the class pointer in the object's header, and does not > touch any contents) This is no longer true when the class you switch > to have additional variables. I was hoping that adding an instance variable to a subclass did not change the shape from the perspective of the superclass methods accessing superclass instance variables. >> <snip> > You could act preemtively, and create an extension in your package: > ODBCRow >> #basicNew > ^EAPPackages basicNew I was trying to avoid tainting upstream code, but if I had to go there I'd rather replace the hardcoded "row := ODBCRow new: columns size." in method "ODBCResultSet>>fetchRow" with "row := theReturnClassLikeODBCRow new: columns size." and new method "ODBCStatement>>execute:args withReturnClass: theReturnClassLikeODBCRow" with existing method "ODBCStatement>>execute:args" changed to call "ODBCStatement>>execute:args withReturnClass: ODBCRow" > > I had tried copyFrom: but some of the instance variables inherited from ODBCRow were not filled in, > > generating exceptions in some of the inherited methods. I had also considered "become:" but that didn't seem appropriate. > I'm somewhat puzzled that the copyFrom:/become: strategy (while an > ugly approach imho) would fail though, do you think you could reduce > it to a simple test using classes in the base image? I've lost track of that code and I can't reproduce it so I must have been doing something wrong. However I had also been considering become: and copyFrom: independently and not as a combined strategy. Together they are sufficient. Thanks for the pointer Henry. To close this out, here is what worked... EAPPackages >> newFromConnection: connection | packages parent | packages := (connection query: 'select * from t_package;') execute asTable. "comes back as an ODBCResultTable" self adoptInstance: packages. "no additional instance variables in subclass" packages do: [ :pkg || tmppkg | tmppkg := EAPPackage new copyFrom: pkg. tmppkg become: pkg ]. ^packages. >> <snip> >> EAPPackages class >> newFromConnection: connection >> | packages parent | >> packages := (connection query: 'select * from t_package;') execute >> asTable. >> self adoptInstance: packages. >> packages do: [ :row | EAPPackage adoptInstance: row. ]. "this line >> replaced by copyFrom: & become:" >> ^packages. >> <snip> > > Cheers, > Henry Thanks for your assistance. cheers, Ben

Dec. 28, 2011

Re: [Pharo-project] changing the class of an existing object to a subclass

by Henrik Sperre Johansen

On 28.12.2011 05:46, Ben Coman wrote: > greetings all, > I am using ConfigurationOfODBC in Pharo 1.3. I have had success with > getting an ODBCResultTable(OrderedCollection) containing ODBCRow > containing about 30 fields. By default the fields are accessed by > "row at: #fieldName" but I wanted to add some convenience methods to > instead go "row fieldName." My searching and experimentation led me > to subclassing ODBCRow as EAPPackage and then using "adoptInstance:" > on each ODBCRow to convert it to the subclass. This was to avoid > having to having to understand and change any of the > ConfigurationOfODBC code. I had tried copyFrom: but some of the > instance variables inherited from ODBCRow were not filled in, > generating exceptions in some of the inherited methods. I had also > considered "become:" but that didn't seem appropriate. > > Using "adoptInstance:" worked fine until I added a new instance > variable to EAPPackage. Subsequently for "<primitive: 160 error: > ec>", ec = #'bad receiver'. The "adoptInstance:" method comment says > it follows the same rules as "primitiveChangeClassTo:" (yet note that > "primitiveChangeClassTo:" never worked) > The "primitiveChangeClassTo:" method comment says "The primitive will > fail in most cases that you think might work [...] The facility is > really provided for certain, very specific applications (mostly > related to classes changing shape) and not for casual use" so I > wondered if there was another way to achieve this. adoptInstance: only works when the object shapes are the same. (It only switches the class pointer in the object's header, and does not touch any contents) This is no longer true when the class you switch to have additional variables. > The full code is hopefully not too long to include for reference > below. The use of "adoptInstance:" in the last section listed. > ------ > ODBCRow subclass: #EAPPackage > instanceVariableNames: 'parent' "note adoptInstance works without > this instance variable, and not with" > classVariableNames: '' > poolDictionaries: '' > category: 'BTC-EA-Explore' > ------ > EAPPackage >> name > ^ self at: #Name > ------ > ODBCResultTable subclass: #EAPPackages > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'BTC-EA-Explore' > ------ > EAPPackages class >> newFromConnection: connection > | packages parent | > packages := (connection query: 'select * from t_package;') execute > asTable. > self adoptInstance: packages. > > packages do: [ :row | EAPPackage adoptInstance: row. ]. > > ^packages. > ------ > In a Workspace I successfully evaluate the following three lines > without : > connection := ODBCConnection dsn: 'CIM' user: '' password: ''. > packages := EAPPackages newFromConnection: connection. > connection close. > ------ > > I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One > alternative I've considered is to somehow pass through a custom > SomeClass in a variable to replace the hard reference to ODBCRow - but > I don't want to chase back all the cascading call references. > > Is there another way to change an existing object to another class, > such that it can be specialised with both additional methods and > instance variables? > I would appreciate any pointers. > > regards, Ben > You could act preemtively, and create an extension in your package: ODBCRow >> #basicNew ^EAPPackages basicNew I'm somewhat puzzled that the copyFrom:/become: strategy (while an ugly approach imho) would fail though, do you think you could reduce it to a simple test using classes in the base image? Cheers, Henry

Dec. 28, 2011

Re: [Pharo-project] changing the class of an existing object to a subclass

by Mariano Martinez Peck

Ben: In CogVM you have #adoptInstance: MyClass adoptInstance: whateverObject. Before Cog, you had #primitiveChangeClassTo: whateverObject primitiveChangeClassTo: anotherOBJECT in this case, whateverObject will change its class to the class of anotherOBJECT cheers On Wed, Dec 28, 2011 at 12:08 PM, Ben Coman <btc(a)openinworld.com> wrote: > Schwab,Wilhelm K wrote: > >> Ben, >> >> That's a lot to read. If I'm getting the message, you want to subclass >> ODBCRow and are concerned about Metacello. >> > Point taken. In hindsight too much background info and a mixed message. > Actually it wasn't not a question about Metacello - though my other recent > mention of ConfigurationOfODBC was. I only mentioned ConfigurationOfODBC > here to distinguish it from the ODBC in DBXTalk - and in hindsight that is > not the core question. The short version is "how do I change the class of > existing object into one of its subclasses". I've got it working, but not > if I add an instance variable to the subclass. > > FWIW, I suspect I would make some type of wrapper class for the rows >> rather than subclass - the goal being to strive for uses-a vs. is-a. >> >> > I had considered that briefly but was concerned that the wrapped class > needed to understand every message that the wrapped-class understood. I > wanted to use the existing ODBCResultTable which holds the ODBCRows to > contain my new subclass of ODBCRow. I will think further about this. > > Idealistically (and perhaps naively) yours, >> >> > More than I would know. Thanks for your time. -Ben > > Bill >> >> >> ______________________________**__________ >> From: pharo-project-bounces(a)lists.**gforge.inria.fr<pharo-project-bounces(a)lists.gforge.inria.fr>[ >> pharo-project-bounces(a)lists.**gforge.inria.fr<pharo-project-bounces(a)lists.gforge.inria.fr>] >> on behalf of Ben Coman [btc(a)openInWorld.com] >> Sent: Tuesday, December 27, 2011 11:46 PM >> To: Pharo-project(a)lists.gforge.**inria.fr<Pharo-project(a)lists.gforge.inria.fr> >> Subject: [Pharo-project] changing the class of an existing object to a >> subclass >> >> greetings all, >> >> I am using ConfigurationOfODBC in Pharo 1.3. I have had success with >> getting an ODBCResultTable(**OrderedCollection) containing ODBCRow >> containing about 30 fields. By default the fields are accessed by "row >> at: #fieldName" but I wanted to add some convenience methods to instead >> go "row fieldName." My searching and experimentation led me to >> subclassing ODBCRow as EAPPackage and then using "adoptInstance:" on >> each ODBCRow to convert it to the subclass. This was to avoid having to >> having to understand and change any of the ConfigurationOfODBC code. I >> had tried copyFrom: but some of the instance variables inherited from >> ODBCRow were not filled in, generating exceptions in some of the >> inherited methods. I had also considered "become:" but that didn't seem >> appropriate. >> >> Using "adoptInstance:" worked fine until I added a new instance variable >> to EAPPackage. Subsequently for "<primitive: 160 error: ec>", ec = >> #'bad receiver'. The "adoptInstance:" method comment says it follows >> the same rules as "primitiveChangeClassTo:" (yet note that >> "primitiveChangeClassTo:" never worked) >> The "primitiveChangeClassTo:" method comment says "The primitive will >> fail in most cases that you think might work [...] The facility is >> really provided for certain, very specific applications (mostly related >> to classes changing shape) and not for casual use" so I wondered if >> there was another way to achieve this. >> >> The full code is hopefully not too long to include for reference below. >> The use of "adoptInstance:" in the last section listed. >> ------ >> ODBCRow subclass: #EAPPackage >> instanceVariableNames: 'parent' "note adoptInstance works without >> this instance variable, and not with" >> classVariableNames: '' >> poolDictionaries: '' >> category: 'BTC-EA-Explore' >> ------ >> EAPPackage >> name >> ^ self at: #Name >> ------ >> ODBCResultTable subclass: #EAPPackages >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'BTC-EA-Explore' >> ------ >> EAPPackages class >> newFromConnection: connection >> | packages parent | >> packages := (connection query: 'select * from t_package;') execute >> asTable. >> self adoptInstance: packages. >> >> packages do: [ :row | EAPPackage adoptInstance: row. ]. >> >> ^packages. >> ------ >> In a Workspace I successfully evaluate the following three lines without : >> connection := ODBCConnection dsn: 'CIM' user: '' password: ''. >> packages := EAPPackages newFromConnection: connection. >> connection close. >> ------ >> >> I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One >> alternative I've considered is to somehow pass through a custom >> SomeClass in a variable to replace the hard reference to ODBCRow - but I >> don't want to chase back all the cascading call references. >> >> Is there another way to change an existing object to another class, such >> that it can be specialised with both additional methods and instance >> variables? >> I would appreciate any pointers. >> >> regards, Ben >> >> >> >> >> > > > -- Mariano http://marianopeck.wordpress.com

Dec. 28, 2011

Re: [Pharo-project] Fwd: DrGeo in Greek

by Henrik Sperre Johansen

On 26.12.2011 11:15, Hilaire Fernandes wrote: > I try to copy and paste in a Worksapce some greek word taken from web > content , it only produces garbadge, although pasting in a Terminal is fine. > When searching for alternate font in the system I can get some > meaningful characters. Which means the copy is fine at least, there's just not fonts to display them correctly :) > > However, depending on the locale of the system, it means switching to > alternate font in Pharo. I don't think we have some sort of mechanism to > switch to other fonts depending on the locale, do we? Without to mention > we will have it to be plateform neutral. > > Hilaire I'd think finding a system font (with a reasonable glyph coverage, and acceptable aesthetics) for each platform would be a decent comprimise. Then you'd only need a startup class to check which platform you're on when starting, and switch accordingly. The alternative is to include TT fonts with the distribution, which will work cross-platform for the glyphs it covers, but bloat the size immensely for any font with decent coverage. I believe it was done for the 1.0/1.1 full images, so check one of those for details. Cheers, Henry

Dec. 28, 2011

Re: [Pharo-project] changing the class of an existing object to a subclass

by Ben Coman

Schwab,Wilhelm K wrote: > Ben, > > That's a lot to read. If I'm getting the message, you want to subclass ODBCRow and are concerned about Metacello. Point taken. In hindsight too much background info and a mixed message. Actually it wasn't not a question about Metacello - though my other recent mention of ConfigurationOfODBC was. I only mentioned ConfigurationOfODBC here to distinguish it from the ODBC in DBXTalk - and in hindsight that is not the core question. The short version is "how do I change the class of existing object into one of its subclasses". I've got it working, but not if I add an instance variable to the subclass. > FWIW, I suspect I would make some type of wrapper class for the rows rather than subclass - the goal being to strive for uses-a vs. is-a. > I had considered that briefly but was concerned that the wrapped class needed to understand every message that the wrapped-class understood. I wanted to use the existing ODBCResultTable which holds the ODBCRows to contain my new subclass of ODBCRow. I will think further about this. > Idealistically (and perhaps naively) yours, > More than I would know. Thanks for your time. -Ben > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Ben Coman [btc(a)openInWorld.com] > Sent: Tuesday, December 27, 2011 11:46 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] changing the class of an existing object to a subclass > > greetings all, > > I am using ConfigurationOfODBC in Pharo 1.3. I have had success with > getting an ODBCResultTable(OrderedCollection) containing ODBCRow > containing about 30 fields. By default the fields are accessed by "row > at: #fieldName" but I wanted to add some convenience methods to instead > go "row fieldName." My searching and experimentation led me to > subclassing ODBCRow as EAPPackage and then using "adoptInstance:" on > each ODBCRow to convert it to the subclass. This was to avoid having to > having to understand and change any of the ConfigurationOfODBC code. I > had tried copyFrom: but some of the instance variables inherited from > ODBCRow were not filled in, generating exceptions in some of the > inherited methods. I had also considered "become:" but that didn't seem > appropriate. > > Using "adoptInstance:" worked fine until I added a new instance variable > to EAPPackage. Subsequently for "<primitive: 160 error: ec>", ec = > #'bad receiver'. The "adoptInstance:" method comment says it follows > the same rules as "primitiveChangeClassTo:" (yet note that > "primitiveChangeClassTo:" never worked) > The "primitiveChangeClassTo:" method comment says "The primitive will > fail in most cases that you think might work [...] The facility is > really provided for certain, very specific applications (mostly related > to classes changing shape) and not for casual use" so I wondered if > there was another way to achieve this. > > The full code is hopefully not too long to include for reference below. > The use of "adoptInstance:" in the last section listed. > ------ > ODBCRow subclass: #EAPPackage > instanceVariableNames: 'parent' "note adoptInstance works without > this instance variable, and not with" > classVariableNames: '' > poolDictionaries: '' > category: 'BTC-EA-Explore' > ------ > EAPPackage >> name > ^ self at: #Name > ------ > ODBCResultTable subclass: #EAPPackages > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'BTC-EA-Explore' > ------ > EAPPackages class >> newFromConnection: connection > | packages parent | > packages := (connection query: 'select * from t_package;') execute > asTable. > self adoptInstance: packages. > > packages do: [ :row | EAPPackage adoptInstance: row. ]. > > ^packages. > ------ > In a Workspace I successfully evaluate the following three lines without : > connection := ODBCConnection dsn: 'CIM' user: '' password: ''. > packages := EAPPackages newFromConnection: connection. > connection close. > ------ > > I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One > alternative I've considered is to somehow pass through a custom > SomeClass in a variable to replace the hard reference to ODBCRow - but I > don't want to chase back all the cascading call references. > > Is there another way to change an existing object to another class, such > that it can be specialised with both additional methods and instance > variables? > I would appreciate any pointers. > > regards, Ben > > > >

Dec. 28, 2011

Re: [Pharo-project] Roeltyper

by Lukas Renggli

> Did you publish the patch? I guess that was fixed a long time ago. At least it does not crash my image, it just produces wrong results. > What is wrong? > What would be good is to remove the VW compliant classes and layers because like that it should be really simple. It is highly complex, because it does an abstract interpretation of the bytecodes and getting the offsets of the variables right is not trivial. In fact in the past 2 years several people have tried to fix (including me) and didn't get it to work. >> Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly. Maybe you should rather use RBRefactoryTyper? It is slower, because it needs to parse all the involved source code; but it works correctly and uses a similar (even more powerful) inferencing algorithm. Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 28, 2011