April 2010 - Pharo-dev - lists.pharo.org

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

by laurent laffont

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 >

April 8, 2010

[Pharo-project] Linux vm: assertions and strategy

by Schwab,Wilhelm K

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

April 8, 2010

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

by Torsten Bergmann

Michael Roberts wrote: > I think it should be possible for help to appear in the global help > browser without having to define a subclass of CustomHelp. This would > make the entry barrier really low for people to be able to document > parts of the system using this help system. 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. Providing CustomHelp subclasses is easy to understand for the "content writer" and system help is not spread around in the image. 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?). Stef wrote: >do you have a new version that we could integrate to 1.1? see http://www.squeaksource.com/HelpSystem The baseline works fine in 1.1.#11309, but I would remove a few methods after integration (for Squeak and Pharo 1.0 compatibility, see #initWindowInSqueak #isSqueak #isPharo11 and senders). That's easy. However, it is already working in 1.1. and integration would just mean to load it: - the minimum support is in the Core package HelpSystem-Core-tbn.35 - the according tests (HelpSystem-Tests-tbn.9) are green in 1.1 too. Thats anything you need to have help support, the browser ("Tools"->"Help Browser") and the full API help stuff (just run "HelpBrowser openOn: SystemReference" or any other sample I provided). One thing: if you just have the "HelpSystem-Core" loaded the standard help browser for the system would only display the help for the help system itself. If you want to additionally provide infos/content on the Pharo project you need other packages like "Pharo-Project-Help". We can enhance "Pharo-Project-Help" and use it either for the dev image or core image. We can also keep "Pharo-Project-Help" minimal for the pharo core image with basic infos on the project and create a "Pharo-Project-Dev-Help" or others for the pharo developer image. I see three options: (1) integrate it in 1.1. core as you wrote (2) no help in pharo core to keep it minimal and have the help system as one of the first packages loaded in the pharo dev image (3) wait until we can enhance it with Scamper code, markup, ... (which takes more time than I have now) Another option (4) which I dislike: If you find the help-core package (which currently includes the UI browser) to much for a pharo-core image we can also split the package so that: - the core model is in the image (only classes HelpTopic and CustomHelp are really necessary) so one can define and write help content - the help browser and builders are loadable/exchangable afterwards I would keep them together since you need minimal support to visually control what you wrote and why have help contents in the image when you cant browse it ;) If you would follow that path I can argue that we have to keep the settings framework but provide the settings browser only in the dev-image. Same issue. Thats why I would either follow (1) or (2), but that is just MHO. Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

April 8, 2010

Re: [Pharo-project] running tests using the method menu

by StÃ©phane Ducasse

On Apr 8, 2010, at 11:02 AM, Lukas Renggli wrote: >> Can we alter the placements of the items in the method menu? > > Yeah, this is an unfortunate placement, however it logically belongs > to the group of actions commands. > > Personally I didn't notice that problem, because I always use Ctrl+T > to run the test. > > In the latest OB with refactoring tools installed you can undo/redo > most actions (method definition, class definition, method removal, > method definition, method change, and of course all refactorings). > Just click on 'refactor --> undo' in case you accidentally > deleted/overwrite something. > >> The sad part of the story is that we changed all the menus in O2 but O2 will never make it. > > Shortening the menus is good, but not to the point where logical > groups are split into unrelated and messy submenus. don't be negative this is not because something does not suit you that it is bad or that others do not like it. stef > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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] running tests using the method menu

by Fernando olivero

great, much safer placements. But i think now i will force myself to start using cmd-T. Fernando On Apr 8, 2010, at 11:14 AM, Lukas Renggli wrote: > Name: OB-SUnitIntegration-lr.25 > Author: lr > Time: 8 April 2010, 11:12:28 am > UUID: 1cb48cf9-d265-4f04-8146-6a594a1b4ce0 > Ancestors: OB-SUnitIntegration-lr.24 > > - put menu item at the top > > On 8 April 2010 11:02, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Can we alter the placements of the items in the method menu? >> >> Yeah, this is an unfortunate placement, however it logically belongs >> to the group of actions commands. >> >> Personally I didn't notice that problem, because I always use Ctrl+T >> to run the test. >> >> In the latest OB with refactoring tools installed you can undo/redo >> most actions (method definition, class definition, method removal, >> method definition, method change, and of course all refactorings). >> Just click on 'refactor --> undo' in case you accidentally >> deleted/overwrite something. >> >>> The sad part of the story is that we changed all the menus in O2 but O2 will never make it. >> >> Shortening the menus is good, but not to the point where logical >> groups are split into unrelated and messy submenus. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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] running tests using the method menu

by Lukas Renggli

Name: OB-SUnitIntegration-lr.25 Author: lr Time: 8 April 2010, 11:12:28 am UUID: 1cb48cf9-d265-4f04-8146-6a594a1b4ce0 Ancestors: OB-SUnitIntegration-lr.24 - put menu item at the top On 8 April 2010 11:02, Lukas Renggli <renggli(a)gmail.com> wrote: >> Can we alter the placements of the items in the method menu? > > Yeah, this is an unfortunate placement, however it logically belongs > to the group of actions commands. > > Personally I didn't notice that problem, because I always use Ctrl+T > to run the test. > > In the latest OB with refactoring tools installed you can undo/redo > most actions (method definition, class definition, method removal, > method definition, method change, and of course all refactorings). > Just click on 'refactor --> undo' in case you accidentally > deleted/overwrite something. > >> The sad part of the story is that we changed all the menus in O2 but O2 will never make it. > > Shortening the menus is good, but not to the point where logical > groups are split into unrelated and messy submenus. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

April 8, 2010

Re: [Pharo-project] running tests using the method menu

by Lukas Renggli

> Can we alter the placements of the items in the method menu? Yeah, this is an unfortunate placement, however it logically belongs to the group of actions commands. Personally I didn't notice that problem, because I always use Ctrl+T to run the test. In the latest OB with refactoring tools installed you can undo/redo most actions (method definition, class definition, method removal, method definition, method change, and of course all refactorings). Just click on 'refactor --> undo' in case you accidentally deleted/overwrite something. > The sad part of the story is that we changed all the menus in O2 but O2 will never make it. Shortening the menus is good, but not to the point where logical groups are split into unrelated and messy submenus. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 8, 2010

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

by StÃ©phane Ducasse

Torsten do you have a new version that we could integrate to 1.1? Stef On Mar 29, 2010, at 9:21 PM, Michael Roberts wrote: > Hi Torsten, i like a lot of the new features. > > regarding defining help in classes without the help system loaded - i > think it could be simpler. I am not sure how this would work as you > describe in my example where I want to shove some simple help in the > monticello package. I don't understand the asHelpTopic conversion and > which builder to use etc. > > I think it should be possible for help to appear in the global help > browser without having to define a subclass of CustomHelp. This would > make the entry barrier really low for people to be able to document > parts of the system using this help system. For example I have spent > too long on this already ;-) > > > Can you consider the idea of a PragmaHelpBuilder as an extension to > your system? > > I can define a method like this on some class: > > helpForThisPartOfTheSystem > <helpTopic: 'Title goes here'> > > ^'Contents goes here. > foo > bar > wibble' > > And then I can find all of these pragmas: > > | pragmas topics | > pragmas := ((SystemNavigation default allMethodsSelect: [:each | each > pragmas notEmpty]) > select: [:each | each compiledMethod pragmas allSatisfy: [:eachPragma | > eachPragma keyword = #helpTopic:]]) > collect: [:each | each compiledMethod pragmaAt: #helpTopic:]. > topics := pragmas collect: [:each | > HelpTopic > title: (each argumentAt: 1) > contents: (each method valueWithReceiver: nil arguments: #())] > > With a bit more annotation we could build classes just like the simple > subclass case of CustomHelp where you only have a few methods on the > class side. i.e just like your metacello example. Then there is no > dependency on CustomHelp, and help comments can go anywhere in our > various package structures for e.g pharo core, dev image. We would > just need to decide on a set of annotations. > > thanks, > Mike > > _______________________________________________ > 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] running tests using the method menu

by StÃ©phane Ducasse

Yes! The sad part of the story is that we changed all the menus in O2 but O2 will never make it. stef On Apr 8, 2010, at 10:05 AM, Fernando olivero wrote: > Can we alter the placements of the items in the method menu? > > Sometimes i click just to pixels above and erase a method instead of running the test! > > <methodmenus.png>_______________________________________________ > 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

[Pharo-project] running tests using the method menu

by Fernando olivero

Can we alter the placements of the items in the method menu? Sometimes i click just to pixels above and erase a method instead of running the test!

April 8, 2010