- Pharo-dev - lists.pharo.org

Re: [Pharo-project] potential bugfix for orphan OCompletion menus

by Romain Robbes

I also published, in Ocompletion-RomainRobbes.55, a potential fix for this issue: http://code.google.com/p/pharo/issues/detail?id=1678 Cheers, Romain On Apr 8, 2010, at 4:55 PM, StÃ©phane Ducasse wrote: > > On Apr 8, 2010, at 7:51 PM, Romain Robbes wrote: > >> Dear list, >> >> I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed. > > Excellent! > >> The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. >> To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically. >> >> You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better). > > I'm sure that people will give you feedback. > >> >> Cheers, >> Romain >> >> -- >> Romain Robbes >> http://romain.robb.es >> rrobbes(a)dcc.uchile.cl >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://romain.robb.es rrobbes(a)dcc.uchile.cl

April 8, 2010

Re: [Pharo-project] potential bugfix for orphan OCompletion menus

by StÃ©phane Ducasse

On Apr 8, 2010, at 7:51 PM, Romain Robbes wrote: > Dear list, > > I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed. Excellent! > The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. > To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically. > > You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better). I'm sure that people will give you feedback. > > Cheers, > Romain > > -- > Romain Robbes > http://romain.robb.es > rrobbes(a)dcc.uchile.cl > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 8, 2010

Re: [Pharo-project] Phari collaborActive book

by StÃ©phane Ducasse

Thanks doru. And let me restate it, everybody willing to participate is welcome. Stef On Apr 8, 2010, at 9:07 PM, Tudor Girba wrote: > Hi Geert, > > I created the user. Will send the password separately. > > Cheers, > Doru

April 8, 2010

Re: [Pharo-project] CollabActive book :)

by StÃ©phane Ducasse

Excellent! I will create an account for you. Stef On Apr 8, 2010, at 6:00 PM, Javier PimÃ¡s wrote: > I'd like to participate! > > Regards, > Javier. > > On Sat, Apr 3, 2010 at 8:35 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi Pharoers > > We put in place (big big thanks doru, anton, lukas and gemstone for that) a pier book > http://book.pharo-project.org/ > > The idea is that we can collect/edit.... information about pharo on this collaborative book. > Now we would like that **you**/**us** control the quality of the contents. The book will be open: > **you**= anybody from the pharo community can be editor (you should ask probably doru because I have to > really make sure that I do not mess it up) but not everybody can change text, everybody will be able to add notes > following the http://book.seaside.st principle. > As an editor you can register to the rss stream and includes the comments. > > Now the idea is that after a while the ready to get publish parts may be used for Pharo by example 2 since we > can generate automatically latex from the web. > > Now I would love to have chapter on > - how to compile my vm on Mac OSX > - how to compile my vm on linux > - how to compile my vm on Windows > - Understanding Announcement > - Settings > - Building UI with Polymorph.... > - Help > - ... > > So if you want to be an editor you are more than welcome! > Just ask > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 8, 2010

Re: [Pharo-project] [Preview] Help System with new model

by StÃ©phane Ducasse

> Yes, I had a pragma solution using <helpTopic: 'Title goes here'> > in one of the first versions - but it gets complicated if you > want to define structured help contents with nested books and > with pages in a specific order. The implementation is easy ... > I mean with pragmas it would be complicated for the "help writer" > to define these nested book structures and to remember the correct > pragmas. > And you have to solve the following scenario: you may have a class > A defining a help book using pragmas and a class B defining another > help book which should be displayed under the book defined by A. > Since you do not rely on a "help class hierarchy" and are decoupled > using pragmas both classes can live under Object. Good. Everything > works fine when A and B are in the image. But you can get a problem > when class A is not loaded - since the parent book of B is not there. > > > I would not see a problem in having the help hierarchy clearly > defined as a subclass hierarchy of a predefined "CustomHelp" class. The point is to avoid duplicating code between a class and its help or between a testcase and the help. > Providing CustomHelp subclasses is easy to understand for the > "content writer" and system help is not spread around in the image. Yes but it can also be out of sync. I like literate programming just because the comments are in the code. > You can see the structure in the class hierarchy browser and in the > help browser. Thats wonderfull. > For all these reasons I would prefer a CustomHelp for the standard > help. (Independent from that the help browser itself is still > capable to use anything with an #asHelpTopic interface). > > > Providing the CustomHelp class is the same as with TestCase - you know > that when you subclass you will later find it in the UI tool > (TestRunner/help browser) and you can peek in other TestCase subclasses > to see what is possible. > > And yes, that means that minimal help support (in minimum 2 classes > HelpTopic and CustomHelp) is already in the image similar to SUnit. > > Dont know if the name CustomHelp is good (maybe HelpBook/SystemHelpBook?). I'm not worried by having two classes extra in the system or core since help will not been referenced from everywhere. This kind of packages are easy to unload. I was more concerned about the idea that we can use the system to annotate what should be promoted as help. Writing separate and maintaining doc is costly and I was thinking that I wanted to reuse as much as possible as the existing information (class comments, unit tests...). Stef

April 8, 2010

Re: [Pharo-project] Linux vm: assertions and strategy

by laurent laffont

2010/4/8 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > Laurent, > > I was reading a little about Eliot's proposed FPU init changes to FFI and > then took another look at your evolving Pharo vm source and I was struck by > either: (1) a brilliant (well, fairly clever) workaround to my external > library hassles; (2) a completely and totally stupid idea. > > You have based the vm on the 3.11-3 sources, so it hopefully fixes the > double return defect that has been driving me nuts. My remaining problem is > to get the vm to load external libraries. Would a simple plugin to expose > dlopen() (and perhaps dlsym() while we're at it) solve the problem? I > should then be able to bypass the FFI code that calls dlopen() (I suspect > that it's pretty badly broken) by setting the handle of any ailing library > by using absolute paths if necessary. From there, I *think* everything will > just work. > > What do you think? > Well, I'm noob on VM stuff, I've just worked on how to generate VM source for Linux, that's all :) So I cannot tell anything...I have to learn before. > Somewhat related, have you looked at compiling the Alien plugin? The more > I look at posts on Alien, the more I wonder whether it will help, as there > are suggestions that it is weak on external calls. Still, it would be nice > to get it going and look over the tests the boldness that comes from > watching them pass having actually done something. > Yes I can compile it, but the VM crashes loudly when trying to use it. This thread has a lot of informations: http://n4.nabble.com/Trying-to-build-alien-plugin-in-linux-tc1562896.html Laurent Laffont > > Bill > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *laurent > laffont > *Sent:* Thursday, April 08, 2010 7:32 AM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Linux vm: assertions and strategy > > I'm totally noob on FFI. Maybe the vm-dev mailing list is more appropriate > ? It seems there's actually some problems with it > http://n4.nabble.com/forum/Search.jtp?tpl=search-page&node=104410&query=ffi > > On my machine, 20/21 FFI unit tests fails... > > I haven't been able to build last revision of squeak-vm trunk. > > Laurent Laffont > > > On Thu, Apr 8, 2010 at 1:53 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> Laurent, all, >> >> If I may jump to conclusions a little, the 3.11-3 vm's changes break the >> loading of libraries, certainly to the point of being arkane. Beyond that, >> LinuxODBC is transparent to it, so I am left wondering how it is suppose to >> work at all?? >> >> The RC3 one-click image and vm produce very nice fonts on my Ubuntu >> laptop, but it retains the FFI/double defect, and from the naming of the >> plugins, must be based on a pre 3.11-3 vm. >> >> Is the plan to use 3.11-3 for the one-click? If so, we need to do >> something about external libraries; at a minimum, LinuxODBC should work, >> whether by fully understanding how to use environment variables, or (as I >> suspect) getting the dlopen() call to work again. >> >> Another option is to identify the FPU related fixes and apply them to the >> current one-click vm. >> >> Any preferences? Any success with 3.11-3 and LinuxODBC? I'd be happy to >> be wrong about this. >> >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 8, 2010

Re: [Pharo-project] Linux vm: assertions and strategy

by Schwab,Wilhelm K

Laurent, I was reading a little about Eliot's proposed FPU init changes to FFI and then took another look at your evolving Pharo vm source and I was struck by either: (1) a brilliant (well, fairly clever) workaround to my external library hassles; (2) a completely and totally stupid idea. You have based the vm on the 3.11-3 sources, so it hopefully fixes the double return defect that has been driving me nuts. My remaining problem is to get the vm to load external libraries. Would a simple plugin to expose dlopen() (and perhaps dlsym() while we're at it) solve the problem? I should then be able to bypass the FFI code that calls dlopen() (I suspect that it's pretty badly broken) by setting the handle of any ailing library by using absolute paths if necessary. From there, I *think* everything will just work. What do you think? Somewhat related, have you looked at compiling the Alien plugin? The more I look at posts on Alien, the more I wonder whether it will help, as there are suggestions that it is weak on external calls. Still, it would be nice to get it going and look over the tests the boldness that comes from watching them pass having actually done something. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of laurent laffont Sent: Thursday, April 08, 2010 7:32 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Linux vm: assertions and strategy I'm totally noob on FFI. Maybe the vm-dev mailing list is more appropriate ? It seems there's actually some problems with it http://n4.nabble.com/forum/Search.jtp?tpl=search-page&node=104410&query=ffi On my machine, 20/21 FFI unit tests fails... I haven't been able to build last revision of squeak-vm trunk. Laurent Laffont On Thu, Apr 8, 2010 at 1:53 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Laurent, all, If I may jump to conclusions a little, the 3.11-3 vm's changes break the loading of libraries, certainly to the point of being arkane. Beyond that, LinuxODBC is transparent to it, so I am left wondering how it is suppose to work at all?? The RC3 one-click image and vm produce very nice fonts on my Ubuntu laptop, but it retains the FFI/double defect, and from the naming of the plugins, must be based on a pre 3.11-3 vm. Is the plan to use 3.11-3 for the one-click? If so, we need to do something about external libraries; at a minimum, LinuxODBC should work, whether by fully understanding how to use environment variables, or (as I suspect) getting the dlopen() call to work again. Another option is to identify the FPU related fixes and apply them to the current one-click vm. Any preferences? Any success with 3.11-3 and LinuxODBC? I'd be happy to be wrong about this. Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 8, 2010

Re: [Pharo-project] Phari collaborActive book

by Tudor Girba

Hi Geert, I created the user. Will send the password separately. Cheers, Doru On 8 Apr 2010, at 09:33, Geert Claes wrote: > Hi Doru, > > I would like to put my hand up to help a bit with the collaborActive > book. Not sure yet how much I can contribute but I have good > intentions, do I ask you for login details? :) > > Cheers, > > Geert -- www.tudorgirba.com "Every thing has its own flow."

April 8, 2010

Re: [Pharo-project] How to manage todo?

by csrabak＠bol.com.br

Em 07/04/2010 17:48, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > tx I checked the inria task is too complex (the idea is to manage > dependency and produce gantt about tasks). Stef, If include in our process the concept of periodically perusing the [proposed] tasks and define the dependencies, it may worth the added complexity. My .019999.... -- Cesar Rabak

April 8, 2010

Re: [Pharo-project] Menu navigation

by Sean P. DeNigris

thanks, found it :) Sean DeNigris sean(a)clipperadams.com On Apr 7, 2010, at 11:55 AM, StÃ©phane Ducasse [via Smalltalk] wrote: > I know that people around me use Setup something.... > so probably somebody will mention it to you. > > > >> > >> What you can also do is to define a Script to do it for you and to setup > >> your image the exact way you want. > >> > > Cool, I'll try that. Is there a good place to look for info on how to do > > that? > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > View message @ http://n4.nabble.com/Menu-navigation-tp1754368p1754569.html > To unsubscribe from Re: Menu navigation, click here. > -- View this message in context: http://n4.nabble.com/Menu-navigation-tp1754368p1777023.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 8, 2010