- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Instance variables references inside a method

by Carla F. Griggio

Yay! It works beautifully :D I added this method in CompiledMethod as an extension of my project: CompiledMethod>>referredInstVars |theClass idx| theClass := self methodClass. ^theClass instVarNames select: [ :varName | idx := theClass instVarIndexFor: varName. (self readsField: idx) or: [ self writesField: idx ] ] On Sun, May 6, 2012 at 6:04 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > Thanks Guille! That gives me more tools to play with :P > > > On Sun, May 6, 2012 at 5:49 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> LÃder, >> >> you can do something like: >> >> class := myCompiledMethod methodClass. >> class instVarNames select: [ :varName | >> idx := class instVarIndexFor: varName. >> myCompiledMethod readsField: idx or: [ myCompiledMethod writesField: >> idx ] >> ] >> >> because #readsField: and #writesField: are index based. >> >> You can also see as an example: Behavior>>#whichSelectorsAccess: that is >> var named based, but over all class selectors. >> >> Guille >> >> >> On Sun, May 6, 2012 at 10:38 AM, Carla F. Griggio < >> carla.griggio(a)gmail.com> wrote: >> >>> Hi! >>> I'm playing with some metaprogramming, and I'm stuck at trying to find >>> out *which* instance variables are referred inside a method. >>> I've found that a CompiledMethod understands hasInstVarRefs, but I don't >>> recognize a method that could tell just me what I'm looking for. >>> >>> Any leads? >>> >>> Thanks! >>> Carla. >>> >> >> >

May 6, 2012

Re: [Pharo-project] Instance variables references inside a method

by Carla F. Griggio

Thanks Guille! That gives me more tools to play with :P On Sun, May 6, 2012 at 5:49 AM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > LÃder, > > you can do something like: > > class := myCompiledMethod methodClass. > class instVarNames select: [ :varName | > idx := class instVarIndexFor: varName. > myCompiledMethod readsField: idx or: [ myCompiledMethod writesField: > idx ] > ] > > because #readsField: and #writesField: are index based. > > You can also see as an example: Behavior>>#whichSelectorsAccess: that is > var named based, but over all class selectors. > > Guille > > > On Sun, May 6, 2012 at 10:38 AM, Carla F. Griggio <carla.griggio(a)gmail.com > > wrote: > >> Hi! >> I'm playing with some metaprogramming, and I'm stuck at trying to find >> out *which* instance variables are referred inside a method. >> I've found that a CompiledMethod understands hasInstVarRefs, but I don't >> recognize a method that could tell just me what I'm looking for. >> >> Any leads? >> >> Thanks! >> Carla. >> > >

May 6, 2012

[Pharo-project] new generation of Unit tests â¦

by StÃ©phane Ducasse

Hi guys here is a digest of a discussion in VW mailing-list. would be nice to have somebody looking and thinking about that. For example the work of Markus Gaelli for sorting falling tests was lost and this is a pity. Stef ------------------------------------------------------------ You might also want to look at Assessments (bundle of the same name in the public Store repository, MIT license). It offers a much more flexible implementation of a basic test framework, which is then used to execute tests from three different variants of SUnit (SUnit, SUnitToo, and SUnitVM) without needing to modify or override or reparent existing test classes. In addition, it implements test based validation, as well as test based benchmarks and performance measurements. For references, see Chapter 4 of "A Mentoring Course on Smalltalk" here: http://www.lulu.com/shop/search.ep?contributorId=441247 as well as several conference talk slides about these, for example: http://www.youtube.com/watch?v=jeLGRjQqRf0 and also see for example the paper Extreme Validation here: http://www.caesarsystems.com/resources/caesarsystems/files/Extreme_Validati… Assessments' flexible architecture also allows extending Assessments without having to override the framework itself. This is a problem with extending SUnit, and it will lead to various extensions being incompatible with each other. > The 'Unit Testing' Chapter of doc/ToolGuide.pdf has a section at the > end 'Extensions and Variants of SUnit in VisualWorks' which covers > the other tools. Briefly: > > - SUnit, with VW UI RBSUnitExtensions is the cross-dialect utility > we know and love > > - SUnitToo, with VW UI SUnitToo(ls), is a mature tool created by > Travis Griggs. It is VW-specific and permits exploration of > VW-specific ideas for SUnit that are not - or not yet - in the > cross-dialect framework. (Some ideas trialled in SUnitToo, and in > Andres' Assessments framework, have migrated to SUnit and are now > also in Pharo, VASmalltalk and Dolphin SUnit. Others may always be > too VW-specific, or may remain an area of debate.) > > - The SUnit2SU2-Bridge parcel reparents SUnit tests as SUnitToo > tests when the bridge is deployed (done automatically on loading the > parcel and can be done programmatically) and back again when the > bridge is retracted (done automatically on unloading and can be done > programmatically). This can be useful if for example you want to > keep your tests SUnit test, e.g. because the utility is > cross-dialect or for easier historic comparison, but want to use > SUnitToo(ls) UI or wish to run these tests in a single suite with > other SUnitToo tests. > > There is a very high degree of similarity between the frameworks: a > test case should run the same under either. Some minor differences are: > > - SUnitToo(ls) has an image memory of the last result of run > tests: open a fresh window on a test and you will see it with an > icon of the last-time-run result. RBSunitExtension remembers only > within each window: open another RB, or move off the test pane in > the same RB, and the knowledge of test outcomes is discarded. > > - SUnit has optimistic locking of TestResources by default, with > an optional pessimistic locking pattern. Thus, for example, if your > system can only be logged in to one database at a time and your > overall test suite includes two database login resources that login > to two databases, you must tag them as belonging to a > CompetingResource set. SUnitToo has pessimistic locking and (IIRC) > no pattern for escape from it at this time. Thus you need never tag > competing resources, but if you have a resource that takes 5 minutes > to setUp and tearDown (e.g. installing/uninstalling a complex > product), and use it in a suite of thousands of tests with tens of > other resources (e.g. your code integration suite), then SUnitToo > could turn that 5 minutes into an hour and 5 minutes as it was > repeatedly tornDown and setUp again in pessimistically-calculated > competing resource sets. > > - SUnit provides TestCase API on TestResources also, so e.g. if > code in a test case's setUp method starts being too slow as test > numbers grow, it can be refactored to a test resource's setUp > method, to be run once per suite instead of once per test, without > needing to be rewritten. > > - SUnitToo randomises each test run. On the plus side, this > means repeated runs may well find order-dependent errors that > Sunit's consistent run order does not expose. On the minus side, > the run order is not remembered or recreatable, so just such > order-dependent failures may haunt you as intermittent failures. > (FYI I wish to add a randomise-run-order feature to SUnit but with > memory of the order and only used when the user selects it.) > > Travis may be able to list other differences. Generally, the intent > is to keep behaviour the same except for areas where ideas for > developing the frameworks are being trialled. > > HTH > Niall Ross FYI, the mention in my earlier email of SUnit having taken some ideas from Assessments, as well as from SUnitToo, refers to some of these ways of extending. For example, the 'Extensions and Variants of SUnit in VisualWorks' subsection (in the test chapter of doc/ToolsGuide.pdf) mentions the pattern for skipping tests. This is an example of using ClassifiedTestResult, which owes its inspiration to Assessments. In 7.9, the RBSUnitExtensions tool allows plugin of TestSuite subclasses, by doing RBSUnitExtension suiteClass: MyTestSuite. During 7.10, we expect to publish some examples of TestSuite subclasses (and TestResult subclasses referenced by them) in the OR so people can use the above to experiment, and maybe some in the community will also do so: thus we can find out what subclassing patterns may be best, so make any (very minor, purely refactoring) changes in the top-level framework that would help support them. You are right that SUnitToo(ls) gives better visual feedback than RBSUnitExtensions (having the SUnit2SU2-Bridge, so we can always use SUnitToo UI for SUnit tests just by loading it, has made me careless about porting these UI features - I will try to do that for the next release). By contrast, RBSUnitExtensions is a bit ahead when it comes to handling tests that are extensions in other packages (maybe those features will also get ported).

May 6, 2012

Re: [Pharo-project] Instance variables references inside a method

by Guillermo Polito

LÃder, you can do something like: class := myCompiledMethod methodClass. class instVarNames select: [ :varName | idx := class instVarIndexFor: varName. myCompiledMethod readsField: idx or: [ myCompiledMethod writesField: idx ] ] because #readsField: and #writesField: are index based. You can also see as an example: Behavior>>#whichSelectorsAccess: that is var named based, but over all class selectors. Guille On Sun, May 6, 2012 at 10:38 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > Hi! > I'm playing with some metaprogramming, and I'm stuck at trying to find out > *which* instance variables are referred inside a method. > I've found that a CompiledMethod understands hasInstVarRefs, but I don't > recognize a method that could tell just me what I'm looking for. > > Any leads? > > Thanks! > Carla. >

May 6, 2012

[Pharo-project] Instance variables references inside a method

by Carla F. Griggio

Hi! I'm playing with some metaprogramming, and I'm stuck at trying to find out * which* instance variables are referred inside a method. I've found that a CompiledMethod understands hasInstVarRefs, but I don't recognize a method that could tell just me what I'm looking for. Any leads? Thanks! Carla.

May 6, 2012

Re: [Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?

by Esteban Lorenzano

Hi, On May 6, 2012, at 9:45 AM, Nicolas Cellier wrote: > 2012/5/6 Igor Stasenko <siguctua(a)gmail.com>: >> On 5 May 2012 18:00, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> >>> On Fri, May 4, 2012 at 6:23 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>> Hi, David, all >>>> >>>> i just want to know, if we can use FFI calls, for implementing an >>>> OSProcessPlugin functionality (or at least most of it). >>>> and if there parts which is hard to implement, i would like to know >>>> what and why. >>> >>> >>> Once we have the threaded FFI and the threaded VM then yes, because one can >>> block one thread in a read without blocking the entire VM. But without the >>> threaded VM one needs asynchronous i/o. >>> >> yes, but nobody said, that i can't use non-blocking i/o. >> >> the main advantage which i see for using FFI is being able to deal >> with everything at language level. >> so, bugs can be fixed quickly, things can be improved more easily etc etc.. >> and the main disadvantage is, of course, speed. >> > > No. > The main disadvantage is to expose the complexity of outside world at > user face, when it was once hidden under the VM carpet. And why is that a disadvantage? This is smalltalk. "Users" are developers, not ben laden... is not like we are going to do terrible things with that power. Even if we are newbies, worst thing that can happen is to make mistakes while learning... same as today :) > In the VM, complexity is handled with the "right tools" (cough...) your "cough" is right :). Right tools is what does our life easier, not what is closer to the hardware. > #include machine_specific_stuff.h driven by #ifdef > why_the_hell_is_it_so_complex ;) and include paths library paths > ldconfig etc... > It's of course cough-able because this complexity then spread into m4 > macros for configure scripts and other such niceties. > > Sure, > - when the VM is not able to handle outside world zoo because a lack > of manpower, and because the outside world changed too fast while we > were sleeping happy in our mickey world, > - or if we want more than least common denominator between several > underlying platforms, > then yes, it might be better to adopt your strategy, because we can > get more manpower at image level than at VM level... this is an important issue: is easier to maintain at smalltalk level than c level. And there are more willing hands to code :) > However, it's a kind of pact with the devil: we get the power at the > price of introducing the #ifdef hell in the image. That's simply not true... look at dbxtalk code, if you want. We could do a plugin to deal with that, but we did it with FFI. Plain smalltalk and straightforward (real problem is to compile opendbx libraries, in fact... and I would love to replace them with smalltalk code, but those are just dreams) > Sure, with a good object model, we might think that it will be easier > to handle such complexity. +1 > But then we're just ignoring the efforts of hordes of programmers > maintaining this shit, and redo all in image. horde of programmers (me, for instance) will be most than pleased to be ignored in this case :) > I'm not sure that it will be sustainable... > Unless of course we focus on a single platform. right now OSProcess is also a hell... if Dave chooses to do something else, we are in problems. I prefer a hell in smalltalk than a paradise in C (and of course, vm is not a paradise :) > Your work is very important, because at least, it will enable powerful > single platform extensions. > But as you see, I just wonder how it would help us to continue > providing ubiquity... Same as today, but in a better way :) Lot of plugins don't need to be in VM side if we have a powerful FFI, with callbacks and threads. I think (as a smalltalk programmer and as a vm programmer) that if we can move to image side those plugins, we can focus in the real complexity of the vm, and after all do better things. > > Nicolas > >>>> >>>> If you want to ask, why one would want to do this.. the answer is simple: >>>> we stated previously, that we want to reduce the VM complexity by >>>> implementing things at language side, when it possible, >>>> leaving only key parts to VM. >>>> This is the main reason why i consider implementing OSProcess using >>>> purely FFI, not because of quality of OSProcessPlugin >>>> implementation etc. >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

May 6, 2012

Re: [Pharo-project] PBE1 update to Pharo 1.4 Re: Some Newbie problems

by Sven Van Caekenberghe

On 06 May 2012, at 09:06, Ben Coman wrote: > The new book focuses on different issues than the old book. It would be sad to let the old book languish entirely and end up with a poor first impression for newcomers, so I am willing to participate in updating it to Pharo 1.4. I am getting a lot from Pharo and this is something I can contribute. I think it fair the main developers continue with implementing and documenting the advanced features, while the community maintains the more established things. A quick scan pegs this effort at updating about 170 images, plus hopefully a minimal amount of text. How would I proceed with this? This would be a **really** good idea/initiative ! Sven

May 6, 2012

Re: [Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?

by Nicolas Cellier

2012/5/6 Igor Stasenko <siguctua(a)gmail.com>: > On 5 May 2012 18:00, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> On Fri, May 4, 2012 at 6:23 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> Hi, David, all >>> >>> i just want to know, if we can use FFI calls, for implementing an >>> OSProcessPlugin functionality (or at least most of it). >>> and if there parts which is hard to implement, i would like to know >>> what and why. >> >> >> Once we have the threaded FFI and the threaded VM then yes, because one can >> block one thread in a read without blocking the entire VM. Â But without the >> threaded VM one needs asynchronous i/o. >> > yes, but nobody said, that i can't use non-blocking i/o. > > the main advantage which i see for using FFI is being able to deal > with everything at language level. > so, bugs can be fixed quickly, things can be improved more easily etc etc.. > and the main disadvantage is, of course, speed. > No. The main disadvantage is to expose the complexity of outside world at user face, when it was once hidden under the VM carpet. In the VM, complexity is handled with the "right tools" (cough...) #include machine_specific_stuff.h driven by #ifdef why_the_hell_is_it_so_complex ;) and include paths library paths ldconfig etc... It's of course cough-able because this complexity then spread into m4 macros for configure scripts and other such niceties. Sure, - when the VM is not able to handle outside world zoo because a lack of manpower, and because the outside world changed too fast while we were sleeping happy in our mickey world, - or if we want more than least common denominator between several underlying platforms, then yes, it might be better to adopt your strategy, because we can get more manpower at image level than at VM level... However, it's a kind of pact with the devil: we get the power at the price of introducing the #ifdef hell in the image. Sure, with a good object model, we might think that it will be easier to handle such complexity. But then we're just ignoring the efforts of hordes of programmers maintaining this shit, and redo all in image. I'm not sure that it will be sustainable... Unless of course we focus on a single platform. Your work is very important, because at least, it will enable powerful single platform extensions. But as you see, I just wonder how it would help us to continue providing ubiquity... Nicolas >>> >>> If you want to ask, why one would want to do this.. the answer is simple: >>> we stated previously, that we want to reduce the VM complexity by >>> implementing things at language side, when it possible, >>> leaving only key parts to VM. >>> This is the main reason why i consider implementing OSProcess using >>> purely FFI, not because of quality of OSProcessPlugin >>> implementation etc. >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> best, >> Eliot >> > > > > -- > Best regards, > Igor Stasenko. >

May 6, 2012

[Pharo-project] PBE1 update to Pharo 1.4 Re: Some Newbie problems

by Ben Coman

StÃ©phane Ducasse wrote: > welcome peter > > >> I'm trying to work my way through the Pharo by example book on my Ubuntu 12.04 LTS box. Unfortunately, things in the book don't look like they do on my setup. For example, I can't work out what the key combination is to get the 'Morphic Halo'. I can get it from a menu, but not from a key press combination. >> > > on mac it is > option + cmd + shift > and you click on the morph > > > >> Also, calling: >> >> BouncingAtomsMorph new openInWorld >> >> doesn't work. I just get an error message saying that there is no such object. >> > > The BouncingAtomsMorph is not loaded in the new images. > > >> I thought these problems might be due to me having the standard image instead of the Pharo by Example image. So I downloaded that image but when I call Pharo on that image: >> >> $ ./pharo ../Resources/PBE.image >> >> I just get a segmentation fault. >> > > The image of the book is an old one and you should get (may be I'm wrong) an old vm for example it should work on a Squeak3.9 VM. > > >> I'm a complete newbie (but an experienced programmer in a variety of OO and other languages), so if anyone could shed any light on this, I'd be very grateful. >> > > Let us know if you have any other problems. This is try true that such problems are annoying but we do not have the resources to > write a new book, develop pharo and maintain the old book. > The new book focuses on different issues than the old book. It would be sad to let the old book languish entirely and end up with a poor first impression for newcomers, so I am willing to participate in updating it to Pharo 1.4. I am getting a lot from Pharo and this is something I can contribute. I think it fair the main developers continue with implementing and documenting the advanced features, while the community maintains the more established things. A quick scan pegs this effort at updating about 170 images, plus hopefully a minimal amount of text. How would I proceed with this? cheers -ben > Did you have a look at the pharocast because this is also a good way to learn. > > Stef > >> Thanks >> >> Peter >> -- >> Peter Bradley >> peredur.net >> > > > >

May 6, 2012

Re: [Pharo-project] Artefact - a PDF framework

by Ben Coman

Stephan Eggermont wrote: > Hi Olivier, > > I've taken a look at the state of Artefact. Don't you think it would be much less work > to port Christian Haider's work to Pharo? The namespace extensions to ring should > be helpful to make two-way changes from both the VW and Pharo side. > > Stephan Eggermont > > Are there any examples on using the Ring namespace extensions ?

May 6, 2012