- Pharo-dev - lists.pharo.org

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

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

by StÃ©phane Ducasse

On May 6, 2012, at 2:17 PM, Mariano Martinez Peck wrote: > > > On Sun, May 6, 2012 at 12:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)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. > > > cheers -ben > > Thanks ben. > I think that the first volume of the book is on git hub so you can simply go ahead. > > https://github.com/SquareBracketAssociates/ > > May be you should register to the she mailing-list mailing-list and mention your effort. > > > Sbe-discussion(a)iam.unibe.ch, discussion for now. I do not know if the other is open > or > "sbe(a)iam.unibe.ch Example" <sbe(a)iam.unibe.ch>, > > ? > > > -- > Mariano > http://marianopeck.wordpress.com >

May 6, 2012

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

by Guillermo Polito

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

May 6, 2012

[Pharo-project] Command Line Handling

by Sean P. DeNigris

I've played a lot with the new command line argument handling. Here's a few thoughts: * I think we should not allow the use of raw handler names (e.g. 'eval') and restrict ourselves to flags. For example, disallow 'eval' and stick to '-e' or '--evaluate'. The raw name introduces ambiguity in parsing the command line, especially since custom commands can be added at will that may conflict and see next item... * The current implementation chooses the single matching handler with the highest priority, but usually command line tools may have multiple non-conflicting flags * The priority concept seems premature. It adds complexity and confusion (the handler for a specific flag is not obvious because it emerges from an interaction of all the handlers). Maybe a registry would be better? A dictionary could just map flags to handlers e.g. -e -> EvalHandler, --evaluate -> EvalHandler, etc. Sean -- View this message in context: http://forum.world.st/Command-Line-Handling-tp4612779.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 6, 2012

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

by Mariano Martinez Peck

On Sun, May 6, 2012 at 12:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)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. > > cheers -ben > > Thanks ben. > I think that the first volume of the book is on git hub so you can simply > go ahead. > https://github.com/SquareBracketAssociates/ > May be you should register to the she mailing-list mailing-list and > mention your effort. > > Sbe-discussion(a)iam.unibe.ch, or "sbe(a)iam.unibe.ch Example" <sbe(a)iam.unibe.ch>, ? -- Mariano http://marianopeck.wordpress.com

May 6, 2012