May 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Explore Pointers ad startup errors

by Sven Van Caekenberghe

Davide, On 06 May 2012, at 12:02, Davide Varvello wrote: > Hi, > I'm working on a seaside image. I stopped the zinc server before saving and quitting but unfortunately, when I reopen my image, the server is on and listening. > > So I inspected ZnZincServerAdaptor and tried to kill references using "explore pointers". Unfortunately I killed too much; now, when I start the image I have a startup error, it seems SmalltalkImage try to startup WAServerManager but I can't figure out why. > > Hints? > > Thanks > Davide > > ---- > - Come avere 48 servizi a portata di mano senza alzare un dito (dalla tastiera :-) > Oltre il Passaparola > > - Blog: Cambia il Tempo Zn on its own has a mechanism to stop/start servers on images save/startup. Have a look at the class side of ZnServer. Servers can register themselves to become managedServers for the above behavior. Now, for Zn itself this only happens for the default server, the one you start with #startDefaultOn: or the one you create with #defaultOn: For all other servers, you will have to send #register yourself. Seaside does its own management, independent from Zn. The Zn server that is started by WAServerManager using ZnZincServerAdaptor is *not* managed by Zn, but it *is* by Seaside. It seems that you manually broke things. I would suggest to re-initialize WAServerManager. HTH, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 6, 2012

Re: [Pharo-project] Some Newbie problems

by Peredur

El 05/05/12 23:09, Sean P. DeNigris escribiÃ³: > This comes up every so often, so here's a one-click image adapted from the > Pharo 1.4 one click, but with the Jenkins Stack VMs, briefly tested on > Debian and OS X... > > I will host it temporarily at: > http://seandenigris.com/files/PBE-1.0-one-click.zip > > Maybe someone will test in on Windows... and maybe someone will add it to > the PBE site instead of the plain image so our new users will not suffer so > much :) > > HTH, > Sean > > -- > View this message in context: http://forum.world.st/Some-Newbie-problems-tp4611608p4611923.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > Tried it... Left-click (outside of a workspace) brings up the World menu - check. Right-click does nothing. But left-click in a workspace that contains a message (e.g. 3 - 4) brings up a context menu ('do it', 'print it' etc). Not sure if that's a check or not... So I guess that means that with this image, left-click is either a 'click' or an 'action-click' depending on context. Could not find any button combination to activate the "morphic halo". So I'm not sure if I'm better off with this image or not, TBH. Cheers Peter -- *Peter Bradley* peredur.net <http://www.peredur.net>

May 6, 2012

[Pharo-project] Explore Pointers ad startup errors

by Davide Varvello

Hi, Â I'm working on a seaside image. I stopped the zinc server before saving and quitting but unfortunately, when I reopen my image, the server is on and listening. So I inspected ZnZincServerAdaptor and tried to kill references using "explore pointers". Unfortunately I killed too much; now, when I start the image I have a startup error, it seems SmalltalkImage try to startup WAServerManager but I can't figure out why. Hints? Thanks Davide Â Â ---- - Come avere 48 servizi a portata di mano senza alzare un dito (dalla tastiera :-) Â Â Oltre il Passaparola - Blog: Cambia il Tempo

May 6, 2012

[Pharo-project] RPackage and Monticello are dependent on each other

by Pavel Krivanek

Hi, we have small dependency problem. The RPackage is currently dependent on Monticello and Monticello is dependent on RPackage. This makes them unable to load them to Pharo Kernel. I suppose this will fix the worst: MCPackage organization renameCategory: '*RPackage-Core' toBe: '*RPackage-SystemIntegration'. I will open an issue. Cheers, -- Pavel

May 6, 2012

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