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

Re: [Pharo-project] Some Newbie problems

by Ricardo Moran

On Sat, May 5, 2012 at 7:03 PM, Peredur <peredur(a)peredur.net> wrote: > I did try all the combinations I could think of, though (various > combinations of [Shift], [Ctrl], [Alt], [Meta] and left and right clicks). > Nothing seemed to work on Ubuntu 12, I'm afraid. > > Have you tried with middle click? At least in windows, you need "Shift + middle click" to get the halos. Cheers, Richo

May 6, 2012

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

by Frank Shearar

On 6 May 2012 16:01, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hmm, I don't know if it is worth to add a super meta meta framework when we > have only one test framework :).Â But evolving SUnit would be nice. > I'd like to add parameterized tests (for Glorp and OpenDBX should be > gorgeous) :P. SqueakCheck (http://www.squeaksource.com/SqueakCheck/) does just that: create a TheoryTestCase (subclassing TestCase), define a method with a single parameter, mark it with <theory> or <theoryTaking: #MySpecialClass>, and you're done. <theory> theories will attempt to find an appropriate object automatically (by considering all messages sent to the parameter (call it t1) and to t1 class. The TheoryTestCase uses a random data generator to throw at the theory. If something falsifies the theory, that counterexample is preserved as a standard test in the 'counterexamples' category. It still needs work: it needs to take a counterexample and "minimise" it, and the data generator is not at all sophisticated. I'd like a proper type inferencer in there too to inhabit the type expected by the test. But it does work, and I've used it in anger. frank > On Sun, May 6, 2012 at 10:52 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> 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] PBE1 update to Pharo 1.4 Re: Some Newbie problems

by Peredur

El 06/05/12 13:17, Mariano Martinez Peck escribiÃ³: > > > On Sun, May 6, 2012 at 12:51 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> 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? > > > > > > That would be AWESOME. Really. I would be the last person who could really help, directly with this, but I'd be happy (other pressures permitting) to do some proof-reading for you and to act as a guinea pig for you - along the lines of, "If it's clear to me it's probably going to be clear to other readers since my prior knowledge is nil". :-) Peter -- *Peter Bradley* peredur.net <http://www.peredur.net>

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 6 May 2012 17:08, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2012/5/6 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> >>> On Sun, May 6, 2012 at 2:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>>> >>>> <snip> >>>> I'm more worried about having all-platforms-specific-stuff inside image... >>>> but we can mitigate that with fuel, and making loadable packages when >>>> running the image... I don't know, I'm just thinking while writing, so, this >>>> is probably stupid :) >>>> >>> >>> Just think how many times you took a development image and used it in >>> several platforms.Â At least I don't.Â Same happened when I used Eclipse.Â I >>> didn't share my eclipses between systems.Â Even, I had several eclipse >>> installations with their own plugins (just like images, hehe). >>> >>> Probably with jenkins, metacello, and kernel/bootstrap we can generate >>> distributions per platform (With the possibility of an all-in-one >>> distribution for the ones who like that). >>> >>> Guille >> >> Yes, I understand that we can live without this feature... >> - If we can reconstruct images easily (one of the goal of Pharo) - I >> mean not only code, but any object (eventually with Fuel) >> - If we solve the bootstrap problem (or if we can still prepare an >> image for cross platform startup) >> - If we don't forget to always talk (send messages) thru an abstract >> layer, and never directly name the target library, >> >> Since I didn't have all these tools in the past, I were forced to use >> development images across different platform a lot, and yes, it was >> not following the mainstream rules (a la "we can reconstruct all from >> scratch") but damn powerful. >> For deploying applications, it also is very powerful and cheap. >> Personally, I would feel sore to lose it. >> > > But look at the root of what we are talking about: N bytes in VM > versus M bytes in image to support certain functionality. > I think if you need it, you will make sure that those bytes is there > and properly packaged with you application. > Unfortunately, it's more than moving code... What I mean is that when I need to pass an O_NONBLOCK flag to a FFI call, it's going to be a problem because I have to know how this information is encoded on each and every platform I want to support. At least, in C code, I just care about the symbolic information and have a relatively portable sentence. To me that's one of the highest hurdle with FFI, because this is the kind of complexity I wish I never cared of. That's just a flavour of #define/#ifdef hell. It can be worse if you want to interface with IPC (which has lot's of different flavours). Same for functions defined by macros that just use machine specific structure layout... We can no longer use these structures as opaque handles. > You can ship your product and use it on multiple platforms with ease, > granted that appropriate platform-specific code is loaded into your > image. > With distribution using VMs it's a bit different story: it is a > barrier with high entry cost. Especially if you think about all those > RPMs, which is controlled by third-party maintainers. It is not that > easy to directly control it, and much much slower in case if you need > to deal with some problems. > I agree on the principle, I always prefer to develop in FFI than hack the VM, I'm far far more efficient on the former. Nonetheless, I don't think FFI can magically solve all our problems. In certain ways it can make them worse. Nicolas >> Nicolas >> > > > > -- > Best regards, > Igor Stasenko. >

May 6, 2012

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

by Igor Stasenko

On 6 May 2012 17:08, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2012/5/6 Guillermo Polito <guillermopolito(a)gmail.com>: >> >> >> On Sun, May 6, 2012 at 2:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >>> >>> <snip> >>> I'm more worried about having all-platforms-specific-stuff inside image... >>> but we can mitigate that with fuel, and making loadable packages when >>> running the image... I don't know, I'm just thinking while writing, so, this >>> is probably stupid :) >>> >> >> Just think how many times you took a development image and used it in >> several platforms.Â At least I don't.Â Same happened when I used Eclipse.Â I >> didn't share my eclipses between systems.Â Even, I had several eclipse >> installations with their own plugins (just like images, hehe). >> >> Probably with jenkins, metacello, and kernel/bootstrap we can generate >> distributions per platform (With the possibility of an all-in-one >> distribution for the ones who like that). >> >> Guille > > Yes, I understand that we can live without this feature... > - If we can reconstruct images easily (one of the goal of Pharo) - I > mean not only code, but any object (eventually with Fuel) > - If we solve the bootstrap problem (or if we can still prepare an > image for cross platform startup) > - If we don't forget to always talk (send messages) thru an abstract > layer, and never directly name the target library, > > Since I didn't have all these tools in the past, I were forced to use > development images across different platform a lot, and yes, it was > not following the mainstream rules (a la "we can reconstruct all from > scratch") but damn powerful. > For deploying applications, it also is very powerful and cheap. > Personally, I would feel sore to lose it. > But look at the root of what we are talking about: N bytes in VM versus M bytes in image to support certain functionality. I think if you need it, you will make sure that those bytes is there and properly packaged with you application. You can ship your product and use it on multiple platforms with ease, granted that appropriate platform-specific code is loaded into your image. With distribution using VMs it's a bit different story: it is a barrier with high entry cost. Especially if you think about all those RPMs, which is controlled by third-party maintainers. It is not that easy to directly control it, and much much slower in case if you need to deal with some problems. > Nicolas > -- Best regards, Igor Stasenko.

May 6, 2012

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

by Nicolas Cellier

2012/5/6 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Sun, May 6, 2012 at 2:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> >> <snip> >> I'm more worried about having all-platforms-specific-stuff inside image... >> but we can mitigate that with fuel, and making loadable packages when >> running the image... I don't know, I'm just thinking while writing, so, this >> is probably stupid :) >> > > Just think how many times you took a development image and used it in > several platforms.Â At least I don't.Â Same happened when I used Eclipse.Â I > didn't share my eclipses between systems.Â Even, I had several eclipse > installations with their own plugins (just like images, hehe). > > Probably with jenkins, metacello, and kernel/bootstrap we can generate > distributions per platform (With the possibility of an all-in-one > distribution for the ones who like that). > > Guille Yes, I understand that we can live without this feature... - If we can reconstruct images easily (one of the goal of Pharo) - I mean not only code, but any object (eventually with Fuel) - If we solve the bootstrap problem (or if we can still prepare an image for cross platform startup) - If we don't forget to always talk (send messages) thru an abstract layer, and never directly name the target library, Since I didn't have all these tools in the past, I were forced to use development images across different platform a lot, and yes, it was not following the mainstream rules (a la "we can reconstruct all from scratch") but damn powerful. For deploying applications, it also is very powerful and cheap. Personally, I would feel sore to lose it. Nicolas

May 6, 2012

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

by Igor Stasenko

since most of Nicolas concerns were answered by others, there's only one thing i'd like to say about: platform-specifc zoo. At first look it can be scary, but look at opengl binding using nativeboost: we were able to deal with it at image side. And in our case a platform-specific code is maybe less than 1% of total codebase of all NBOpenGL code. Remember an endless issues "B3DAccelerator doesn't works, XYZPlugin doesn't works", because of all this ldconfig/etc mess.. Every time we have such issue, we need to look at VM code, patch it, and rebuilt it again. That means more time and more people involved every time there are issue in VM side. In contrary, if problems like this arising in FFI world, users can easily patch the code by they own, and have stuff working in minuted instead of days (or even months) waiting till new VM build will be released. Especially for OSProcess: why i targeting it? Because it exposing most basic kernel functionality, which can be found on all systems. That means there much less likely will be the problems with linkage with right libs etc. Since OS kernel is there and cannot disappear. And last but not least, of course, avoiding problem of minimal common denominator. For any software experts, i guess , it is important to be able to access the full potential of a system, not a small portion of it. It might be not that important for people with "living in sandbox" mindset, but if you really approach with goals like "i want to implement a modern application on this system using this language" then you probably will start worrying about limitations sooner or later, as well as, how easy you can change it to adopt to your needs. -- Best regards, Igor Stasenko.

May 6, 2012

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

by Guillermo Polito

Hmm, I don't know if it is worth to add a super meta meta framework when we have only one test framework :). But evolving SUnit would be nice. I'd like to add parameterized tests (for Glorp and OpenDBX should be gorgeous) :P. On Sun, May 6, 2012 at 10:52 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 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] Explore Pointers ad startup errors

by Davide Varvello

Thanks Sven, I'm gonna try to reinitialize Davide Sven Van Caekenberghe wrote > > > > 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 > -- View this message in context: http://forum.world.st/Explore-Pointers-ad-startup-errors-tp4612597p4612964.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 6, 2012

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

by Pavel Krivanek

On Sun, May 6, 2012 at 12:57 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > > > 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 think that this is just a problem that we should fix once we get rid of > packageInfo and friends. > > > I suppose this will fix the worst: > > MCPackage organization renameCategory: '*RPackage-Core' toBe: > '*RPackage-SystemIntegration'. > > I do not get that one. > Can you explain the root of the cycle? > RPackage-Core contains extension of MCPackage class and Monticello initialization is dependent on Ring. This way we can load packages in order RPackage-Core, Monticello, RPackage-SystemIntegration. -- Pavel > > > I will open an issue. > > > > Cheers, > > -- Pavel > > >

May 6, 2012