- Pharo-dev - lists.pharo.org

[Pharo-project] Question regarding: #addYellowButtonMenuItemsTo:event:

by Martin Drautzburg

Hello all I am trying to build a nested menu and #addYellowButtonMenuItemsTo:event: seemed to be just the thing I need. But it gives me troubles: It builds the menu starting with the outermost morph an then adds submenus for the submorphs under the mouse. If I understand this correctly, then the menu- construction comes to halt when there is a submorph, which does not want to contribute to the menu, even when a sub-submorph wants to contribute something. I have this situation and the submorph in question is a plain Morph and I hesitate to create an extra class for it. Wouldn't it be better to let #addYellowButtonMenuItemsTo:event: find ALL Morphs which might want to contribute to the menu? Is there a better way of constructing menus with several contributors, or should I roll my own? -- Martin

May 6, 2012

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

by David T. Lewis

On Sat, May 05, 2012 at 03:23:15AM +0200, Igor Stasenko 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. Most, and probably all, of OSProcess could be implemented with FFI. It would take some work, and others have already pointed out the difficult parts, but with enough time an effort it could be done. > > 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. > I also prefer to do things in the image as much as possible. Aside from fork/exec and a few other things, almost everything in OSProcessPlugin is a thin layer over the corresponding C runtime call or system call. On the image side, a platform-specific OSProcessAccessor is responsible for the rest of the interface. If you want to experiment with this, I would suggest starting with a copy of UnixOSProcessAccessor (maybe call it UnixOSProcessFFIAccessor), and replacing calls to the primitives with the corresponding FFI calls. There is a fairly good set of unit tests, so as long as you can keep the tests green you will know you are making progress. Note that I am answering the question "could this be done", not "should this be done" ;) HTH, Dave

May 6, 2012

Re: [Pharo-project] [newbies] How can I diagnose kinetic scrolling screen flicker?

by Martin Drautzburg

On Wednesday, 2. May 2012 01:28:19 Chris Muller wrote: > Ensuring your drawOn: is fast is crucial for good frame-rate. > > Try profiling all processes, that should reveal something.. How exactly do I do this? I tried to get some profiles of my method, but I don't see the actual drawing. When I add a #displayWorldSafely I have the feeling that morphic redraws everything and I see redraws of the Browser etc. -- Martin

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>: > 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. > Well, like opendbx, maybe because opengl has quite standard interface... > Remember an endless issues "B3DAccelerator doesn't works, XYZPlugin > doesn't works", because of all this ldconfig/etc mess.. By the way, a wrong decision in the VM totally messed up the way FFI search and find libraries too. This decision was related to plugins, since the goal was to limit the possibility of loading a wrong plugin. So the looked up paths were restricted for plugins. Unfortunately, the same primitive is shared by FFI, and we also restricted the FFI search path... But it would be a mistake to try to mimic underlying platform rules with in-image code. That's a waste of time, energy and cannot fit settings that are customizable! What we need instead is to correct the VM and just use existing platform mechanism. We also need to add a possibility to bypass it and use our own specific library paths when we want to. > 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. > I agree. For our own use, it's not a problem because we can compile our own VM. But when it comes to distributing, yes, this is an heavy burden we drag... As for the user, yes, a DIY can make a workaround possible and that's better than nothing. See the library path example above... But imagine you want to distribute a software made with Pharo. What you gonna tell to your user if you don't have a generic solution that works and only workarounds? DIY ? Maybe I'm old, but I remember of Smalltalk distributions that just work... > 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. > As Eliot said, it's hard to solve it entirely with FFI, and it's better to have a single primitive that fork, close file descriptors except a list to keep opened (pipes) and exec... > 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. > I can only agree with that. Nonetheless, it's also Pharo's responsibility to provide the common denominator. Nicolas > -- > Best regards, > Igor Stasenko. >

May 6, 2012

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

by Davide Varvello

Sven Van Caekenberghe wrote > > Davide, > > 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 > One step at a time: I removed WAServerManager from the startup list calling: /WAServerManager unload/. That's preventing startup errors Davide -- View this message in context: http://forum.world.st/Explore-Pointers-ad-startup-errors-tp4612597p4613343.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 6, 2012

Re: [Pharo-project] Some Newbie problems

by Sean P. DeNigris

In Ubuntu 9.10 under Parallels... Peredur wrote > > But left-click in a workspace that contains a > message (e.g. 3 - 4) brings up a context menu ('do it', 'print it' > etc) > I get the expected behavior - click moves the cursor, right click brings up the menu Peredur wrote > > Could not find any button combination to activate the "morphic halo". > Alt-shift-click works for me. I should mention that the one-click worked if I executed the .sh from the Terminal, but couldn't seem to find the image if I clicked on it directly from gnome. IIRC both ways worked in Debian... HTH, Sean -- View this message in context: http://forum.world.st/Some-Newbie-problems-tp4611608p4613322.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 6, 2012

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