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

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

by Schwab,Wilhelm K

Laurent, A part-time boss/full-time friend once advised me to "get the machine to tell you what it's doing" (I was doing just that at the time, but I've never forgotten his advise<g>). I compiled your vm and then decided to stick some tracing code in strategic places to find what the vm thinks it is doing in trying to load unixODBC. Get ready: tryLoading(/sr/local/slib/squeak/3.11.13-/so.libodbc.so) = (nil) In short, it does not appear to recognize a difference between plugins (the names of which it twists around to avoid collisions with external libraries - that's fine) and external libraries that have been minding their own business for many clock cycles. The latter deserve special attention. So I had an absolutely nutty idea: give dlopen() the name of the library as written :) Clearly, that works only if one provides an absolute path in #moduleName, but (forgive/correct possible *nix-noob syndrome here) that is easy to test and even easier to do in the code. So, in sqUnixExternalPrims.c in the unix/vm directory, look near the end of tryLoadModule(). My proposed workaround is to add some code before the !handle test at the end. I will send a cut-down version of it in a separate email. Unless someone has a better idea, I suggest we make this change to you source to give people an opportunity to use external libraries: (1) I fear at all(!!); (2) by absolute path if desired. BTW, the 3.11-3 vm indeed appears to have fixed my problem w/ double return values, at least the boiled-down test works. 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 3:22 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Linux vm: assertions and strategy 2010/4/8 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@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@lists.gforge.inria.fr> [mailto:pharo-project-bounces@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<mailto:Pharo-project@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 _______________________________________________ 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] [Preview] Help System with new model

by Michael Roberts

Torsten, i appreciate the thought you are putting in. I just wonder if the definition of the help (the raw content) should also be bound up with the definition of the overall structure? I also wonder if I want to bend the help system in a way that it is not intended. For me i want something that is like python doc strings, and the great python package documentation available, ... but in a more smalltalk in-image manner. So that's why i think of it in terms of annotations. Having the help be in its own help class, on the class side, without any real behavior is a design smell to me. I don't really like heavy class-side programming; the class doesn't really offer any behaviour or scale across the image. I guess i want to see docs spread across the system. you want them central? to me the classes are really just annotations, apart from as you say needing to provide the role of structure for the nested content. my use case is that the documentation must be next to the code it is documenting. the network package is a good example. Since the API is in a state of flux, and no one knew how the 'new' api was supposed to work, it could really benefit detailed documentation for each version of pharo. it will change likely for each major version. the docs need to be in the package. fine, we can have the requisite 2 classes already in the image. that is ok. but it would be better to have the doc content on the actual system classes themselves. Like NetNameResolver. and Socket, etc. so i either have to have my custom class reference them, in some imperative manner, or i need to build a builder.. or something. I had imagined it would be possible to have standard places/hooks for packages and classes, where annotations would go. for example like stef says we could pull out the class comment. also, i imagine if documenting the system, in a system wide manner, was successful we would have lots of doit expressions. some mashup between workspaces, profstef, and hypertext. in that case it would be nice to somehow link doc expressions that are really little test assertions together, so we can actually test the docs to make sure that they validate against the system code. I think the SBE/PBE latex sources had this idea in them. And Adrian K has posted examples of these nice extensions to sunit that read very well. I would like that feeling somehow integrated, otherwise we won't be able to maintain the sanity of our docs either. so i guess i'm kinda with stef's comments later in this thread. but anyway, we start with zero in-image documentation. for me we must just have a doc system that scales. i really want to see the docs in the packages, not in a single central package. we'll just have to see how it plays out. i don't want to take away from building a 'help system' that would let you provide F1 style help for an actual application - we just desperately need system level documentation to take Pharo to the next level. I guess I see no need for defining inter-help structure because I think for system level docs it can be entirely derived. each package, class, method can all be annotated in a consistent manner. programming examples could be attached to classes in a standard manner. you could then provide a browser giving A-Z, hierarchy, package, classes, search, index, etc views on these annotations. This is not what you are trying to do with your help system, but i see this as a subset of the intent and a lot of the logic already there. i'm not sure if i'm making any sense... cheers, Mike

April 8, 2010

[Pharo-project] iPhone OS 4 SDK, section 3.3.1

by Sean Malloy

The old version: 3.3.1 â Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. The new version: 3.3.1 â Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited). Anyone have any thoughts on this change to the agreement?

April 8, 2010

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

by StÃ©phane Ducasse

great this one was annoying too :) On Apr 8, 2010, at 11:16 PM, Romain Robbes wrote: > 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 > > > _______________________________________________ > 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] 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