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

Re: [Pharo-project] Command Line Handling

by Sean P. DeNigris

Thanks for helping me think this through, Camillo... Camillo Bruni-3 wrote > > you > conceptionally execute subcommands > Okay, I think I understand your intention better now. I was thinking of options, like "-la" for "ls", but you're talking about different modes, like you would never pass both a script and string, mixing basic code loader and eval... Camillo Bruni-3 wrote > >> * 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). > ... > and I disagree with you that it adds complexity. Just look at how much > simpler... > I didn't mean that it increased complexity from the mess that you cleaned up :) Just that it may add unnecessary complexity to your simple system. I guess some real world use will reveal whether that's true... Re registry vs. select... if I'm adding a handler that will mask another handler, it seems like that'd be important to know, not to have it happen silently. I'm wondering whether the criteria-based approach adds unneeded flexibility at the cost of making the system less understandable. With a registry, you can have ifPresent: etc... Sean -- View this message in context: http://forum.world.st/Command-Line-Handling-tp4612779p4613781.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 7, 2012

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

by Peredur

El 06/05/12 23:27, Ben Coman escribiÃ³: > That would be welcome. I'll move further discussion to > sbe-discussion(a)iam.unibe.ch list. Announce yourself there also. > > cheers -ben > I tried, but the list rejected me: You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at sbe-discussion-owner(a)iam.unibe.ch. Cheers Peter -- *Peter Bradley* peredur.net <http://www.peredur.net>

May 6, 2012

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

by Ben Coman

Peredur wrote: > 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 That would be welcome. I'll move further discussion to sbe-discussion(a)iam.unibe.ch list. Announce yourself there also. cheers -ben

May 6, 2012

Re: [Pharo-project] Command Line Handling

by Camillo Bruni

Hi sean, thanks for the response... though I'll be mostly standing against your observations here :). On 2012-05-06, at 14:41, Sean P. DeNigris wrote: > 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... there is no ambiguity, since you can always push a command further up by changing it's priority. besides adding switching is not that nice since you conceptionally execute subcommands > * The current implementation chooses the single matching handler with the > highest priority, but usually command line tools may have multiple > non-conflicting flags I disagree with that. AFAIK there is no unix tool that does that. The only way that this happens is for subcommands that may inherit from their parents some options (see all git sub commands that still allow for --repository from the main command). If you want to support multiple ones you can still add a specific handler that will merge your N other handlers. > * 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). 1. the input is given to all handlers which decide whether they can do something with it or not. 2. the handler with the highest priority is chosen > Maybe a registry would be better? A > dictionary could just map flags to handlers e.g. -e -> EvalHandler, > --evaluate -> EvalHandler, etc. again, I want to have subcommands, and not some smalltalk specific handling... (like for instance the super weird -LONGOPTIONNAME from the vm...) and I disagree with you that it adds complexity. Just look at how much simpler the tests are now, the system doesn't work globally any more. or for instance for coral... I didn't have to manually unregister the default option anymore. In my optinion the system got much easier to use. Of course the goal would be to use some option parsing mechanisms from coral. but I think the base system should be rather flexible and very small and simple.

May 6, 2012

[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