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

Re: [Pharo-project] Classes referenced in code string

by Lukas Renggli

Can be easily done with RB: You parse it (RBParser parseExpression: aString) and do a semantic analysis (see the tests in AST-Tests-Semantics for examples). Lukas On Thursday, December 29, 2011, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > How would I programmatically find out what classes are referenced in a > string. For example: > 'Object new. String new' "would return { Object. String }" > > -- > View this message in context: http://forum.world.st/Classes-referenced-in-code-string-tp4244214p4244214.h… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Lukas Renggli (mobile) http://www.lukas-renggli.ch

Dec. 29, 2011

[Pharo-project] Classes referenced in code string

by Sean P. DeNigris

How would I programmatically find out what classes are referenced in a string. For example: 'Object new. String new' "would return { Object. String }" -- View this message in context: http://forum.world.st/Classes-referenced-in-code-string-tp4244214p4244214.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 29, 2011

Re: [Pharo-project] TWM bug when deleting a snapshot

by laurent laffont

On Thu, Dec 29, 2011 at 4:57 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Snapshots are cool! > Still needs some work but something nice seems possible :) > But try this: > 1. create two snapshots > 2. navigate to the last one > 3. delete it > > Although it is shown removed from the list (i.e. "1/1"), you are not > automatically navigated back to the first one. You stay on the deleted one, > and when you navigate back to the first with the arrow, the deleted one > reappears in the list (i.e. "1/2") > OK thanks for the report. I will take a look. Laurent > > Sean > > -- > View this message in context: > http://forum.world.st/TWM-bug-when-deleting-a-snapshot-tp4243197p4243197.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Dec. 29, 2011

[Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Torsten Bergmann

>> So we should care for 1.3 and not yet for 1.4. since >> this is what people use. > >Yes but I use 1.4 for my private projects and this is good to know >what works. Yes - but dont use the squeaksource.com/MetaRepoForPharo14 for that. Otherwise we have to clean it up again and again depending on Pharos progress in 1.4. The "official" squeaksource.com/MetaRepoForPharo14 should be filled when Pharo 1.4 is out with all the configs that are known to work (and tested) for 1.4 But you can use the browser for your pet projects also. Just point him to another repo (maybe a local one): (MetacelloConfigurationBrowser new) repository: 'http://www.squeaksource.com/MyPetConfigs'; open thats all you have to do. And remember: the browser itself is just a start - it could be improved to mark configs already loaded, ... later Bye T. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurÃ¼ck-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

Dec. 29, 2011

Re: [Pharo-project] Help: #pointersTo broken (and fix, but I don't understand why it fixes)

by Eliot Miranda

Hi Mariano, just a tangent for now... On Thu, Dec 29, 2011 at 2:02 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys. #pointersTo is broken and that's why some tests of > PointerFinderTest are yellow. Few weeks ago, I changed #pointsTo: so that > it does not perform primitive 142 but it delegates to a new method > #instVarsInclude: which has the primitive 132 now. > primitiveObjectPointsTo is primitive number 132. primitiveVMPath is primitive 142 primitive numbers 146 & 147 are AFAICT unused. > Before this change, if I open a workspace and execute the following: > > | aDate | > aDate := Date new. > aDate pointersTo > > if you execute that several times, it is ALWAYS empty. After the change, > in different executions answer not only empty but some MethodContext > instances whose method is (ProtoObject>>#pointsTo: "a > CompiledMethod(220463104)"). Most of the times, in these MethodContext > instances, the receiver are the instance variables of aDate > So #pointersTo answer, for example, an > Array(CompiledMethod(ProtoObject)>>pointsTo: Time(ProtoObject)>>pointsTo: > Duration(ProtoObject)>>pointsTo:) > > This causes #pointersToExcept: to have a different behavior. If in > #pointersToExcept: I replace #pointsTo: with #instVarsInclude: it > works perfect. The only difference is that one includes the class and the > other one doesn't. BUT, in this example, the receiver is aDate, hence, > there shouldn't be any object which class is #aDate. In fact, if I put a > "(anObj class == self) ifTrue: [ self halt. ]" it NEVER HALT. That makes > sense. But I don't understand then why with #pointsTo: it doesnt work and > with #instVarsInclude: it works perfect. > > Any idea? > Write a test case and I'll take a look. > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Dec. 29, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by StÃ©phane Ducasse

Did you delete it > You should delete your "MetaReportForPharo14" since this is > the wrong name (Report instead of Repo)! because I cannot find it.

Dec. 29, 2011

Re: [Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by StÃ©phane Ducasse

On Dec 29, 2011, at 11:22 PM, Torsten Bergmann wrote: > Hi Stef, > >> I created MetaReportForPharo14 > > I already created "MetaRepoForPharo14" on squeaksource today > with Markus and me as admins. I can add you as admin too > but the repo is read/write already. > > > You should delete your "MetaReportForPharo14" since this is > the wrong name (Report instead of Repo)! Excellent :) I'm too tired > > >> I would like to load your browser in 1.4. Does it make sense? > > The Config browser is already in 1.4, but empty since > the http://www.squeaksource.com/MetaRepoForPharo14/ > repo that I created today still has no configs. > > See world menu "Tools" -> "Configuration Browser" Yes I saw :) > IMHO we should fill the repo once a Pharo version has > a first release candidate or is released. > > So we should care for 1.3 and not yet for 1.4. since > this is what people use. Yes but I use 1.4 for my private projects and this is good to know what works. > > Bye > T. > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

Dec. 29, 2011

Re: [Pharo-project] Help: #pointersTo broken (and fix, but I don't understand why it fixes)

by Mariano Martinez Peck

Moreover, Squeak does anObj isInMemory ifTrue: [((anObj instVarsInclude: self) or: [anObj class == self]) ifTrue: [pointers add: anObj]]. anObj := anObj nextObject]. and it works fine. grrrrr On Thu, Dec 29, 2011 at 11:11 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Dec 29, 2011, at 11:02 PM, Mariano Martinez Peck wrote: > > > Hi guys. #pointersTo is broken and that's why some tests of > PointerFinderTest are yellow. Few weeks ago, I changed #pointsTo: so that > it does not perform primitive 142 but it delegates to a new method > #instVarsInclude: which has the primitive 132 now. > > > > Before this change, if I open a workspace and execute the following: > > > > | aDate | > > aDate := Date new. > > aDate pointersTo > > > > if you execute that several times, it is ALWAYS empty. After the change, > in different executions answer not only empty but some MethodContext > instances whose method is (ProtoObject>>#pointsTo: "a > CompiledMethod(220463104)"). Most of the times, in these MethodContext > instances, the receiver are the instance variables of aDate > > So #pointersTo answer, for example, an > Array(CompiledMethod(ProtoObject)>>pointsTo: Time(ProtoObject)>>pointsTo: > Duration(ProtoObject)>>pointsTo:) > > I saw that too and I was confused. > Thanks for taking the time to look at it. > We often had a debugger open so I thought it was the reason. > > > > > This causes #pointersToExcept: to have a different behavior. If in > #pointersToExcept: I replace #pointsTo: with #instVarsInclude: it > works perfect. The only difference is that one includes the class and the > other one doesn't. BUT, in this example, the receiver is aDate, hence, > there shouldn't be any object which class is #aDate. In fact, if I put a > "(anObj class == self) ifTrue: [ self halt. ]" it NEVER HALT. That makes > sense. But I don't understand then why with #pointsTo: it doesnt work and > with #instVarsInclude: it works perfect. > > > > Any idea? > > > > Thanks in advance, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 29, 2011

[Pharo-project] Packages and Pharo and Portability : the 3 Ps !

by Torsten Bergmann

Hi Stef, >I created MetaReportForPharo14 I already created "MetaRepoForPharo14" on squeaksource today with Markus and me as admins. I can add you as admin too but the repo is read/write already. You should delete your "MetaReportForPharo14" since this is the wrong name (Report instead of Repo)! >I would like to load your browser in 1.4. Does it make sense? The Config browser is already in 1.4, but empty since the http://www.squeaksource.com/MetaRepoForPharo14/ repo that I created today still has no configs. See world menu "Tools" -> "Configuration Browser" IMHO we should fill the repo once a Pharo version has a first release candidate or is released. So we should care for 1.3 and not yet for 1.4. since this is what people use. Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Dec. 29, 2011

Re: [Pharo-project] Help: #pointersTo broken (and fix, but I don't understand why it fixes)

by StÃ©phane Ducasse

On Dec 29, 2011, at 11:02 PM, Mariano Martinez Peck wrote: > Hi guys. #pointersTo is broken and that's why some tests of PointerFinderTest are yellow. Few weeks ago, I changed #pointsTo: so that it does not perform primitive 142 but it delegates to a new method #instVarsInclude: which has the primitive 132 now. > > Before this change, if I open a workspace and execute the following: > > | aDate | > aDate := Date new. > aDate pointersTo > > if you execute that several times, it is ALWAYS empty. After the change, in different executions answer not only empty but some MethodContext instances whose method is (ProtoObject>>#pointsTo: "a CompiledMethod(220463104)"). Most of the times, in these MethodContext instances, the receiver are the instance variables of aDate > So #pointersTo answer, for example, an Array(CompiledMethod(ProtoObject)>>pointsTo: Time(ProtoObject)>>pointsTo: Duration(ProtoObject)>>pointsTo:) I saw that too and I was confused. Thanks for taking the time to look at it. We often had a debugger open so I thought it was the reason. > > This causes #pointersToExcept: to have a different behavior. If in #pointersToExcept: I replace #pointsTo: with #instVarsInclude: it works perfect. The only difference is that one includes the class and the other one doesn't. BUT, in this example, the receiver is aDate, hence, there shouldn't be any object which class is #aDate. In fact, if I put a "(anObj class == self) ifTrue: [ self halt. ]" it NEVER HALT. That makes sense. But I don't understand then why with #pointsTo: it doesnt work and with #instVarsInclude: it works perfect. > > Any idea? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 29, 2011