- Pharo-dev - lists.pharo.org

[Pharo-project] potential bugfix for orphan OCompletion menus

by Romain Robbes

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. 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). Cheers, Romain -- Romain Robbes http://romain.robb.es rrobbes(a)dcc.uchile.cl

April 8, 2010

Re: [Pharo-project] Expacted Resource (RAM) requirements to run Pharo

by Mariano Martinez Peck

On Tue, Apr 6, 2010 at 5:34 PM, Rudi Ludwig <rudihl(a)gmx.de> wrote: > Hello, > > so I got interested in Smalltalk (again) installed Pharo and > ran the ProfStef tutorial. I'm not a programmer, just interested :-) > > To be more precise, I followed the link on the Pharo homepage > Download directory and installed from > > squeakvm.org/unix : Squeak-3.11.3.2135-solaris2.10_i386.tar.gz in > - /usr/local/Squeak-3.11.3.2135-solaris2.10_i386 > > and from Pharo: Pharo-1.0-10515-rc3dev10.03.1 in my home directory. > > OS: OpenSolaris b127. > > Now while that worked --I can start Squeak (/usr/local/../bin/squeak.sh) > chose the Pharo Image form the file browser that opens and go. > Just following the integrated tutorial (ProfStef) and having maybe one > more ClassBrowser open, at some point consumed 780 MB RAM (RSS). > > Hi, of course that's not common. You should be using 50MB or similar....you have a problem there. Can you try another VM, for example this one: http://gforge.inria.fr/frs/download.php/24736/pharo-vm-0.15.2f-linux.zip Or....the one click image: https://gforge.inria.fr/frs/download.php/26774/Pharo-1.0-10515-rc3dev.zip where you have just un unzip and ./Pharo.sh Cheers Mariano > Question: > Is that the expacted behavior (resource requirement) > or is there something wrong with the steps I choose to run Pharo, > although apparently they worked? > > There is a "PharoDebug.log" 180+kB large from that session, I can > provide on request. (Didn't want to send it to whole list directly). > > > Rudi > > _______________________________________________ > 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] A small idea how to get closer to hardware with small efforts :)

by Igor Stasenko

Okay, here the small snippet of code, which does the trick! :) Compile it with: gcc calltest.c callgate.s -o calltest Here, a fn1() and fn2() is equal functions (almost), which imitating the native code, which moved during the VM call. And fnCallGate() is a special function, which needs to be called instead of actual function, which potentially could move our code. extern void fnCallGate(void* fn, ...); it take a first argument - a function which needs to be called, and then rest of arguments (if any), which belong to that function. This gate function using another function, which returns a current value of a method oop. In terms of Squeak VM, this is a method oop, which it retrieving before calling a VM function and after calling it (interpreterProxy->primitiveMethod). So, in case if method oop is moved during GC, it will change the return address by the same offset as a difference between old method oop value and new one. And so, with this trick, a native code could safely call any VM function (through a gate function) without the risk that if native code is moved during GC, it will return to wrong address and cause a system crash. On 6 April 2010 23:49, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 April 2010 14:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> I always liked how Smalltalk X did it... they have >> >> Â Â Â Â -> an ivar in CompiledMethod that is the "native code pointer". >> Â Â Â Â -> Primitive methods are just methods that have this pointer set >> Â Â Â Â Â Â to the primitive in the vm. >> Â Â Â Â -> Methods with embedded C-code are compiled and linked with >> Â Â Â Â Â Â the Smtk->C cross-compiler, the pointer than points to that function >> Â Â Â Â -> the JIT just put a pointer to the code it generates. >> >> So they merge primitives / static compiling(+embedded c-code) *and* the JIT >> into one not that ugly mechanism. In STX, the memory is managed by the VM, though (the >> code is not allocated in the GCed object memory by the JIT). >> >> So: Yes, I like this :-) and your mechanism is a nice way to get it easily integrated into the current >> system. >> >> Q: what happens when code is moved by the GC? >> > Yeah, it will break the whole thing :) > To avoid that, a native code should not issue any memory allocation, > which may cause GC. > > Perhaps, there is a way to counter this , while still being able to > move the code. > A primitive could set a flag that its going to call a native code, > embedded into compiled method, > so, then, after GC, if this flag is set, VM knows, that memory > allocation is issued from native code, > and should fix the return address (1) on stack, before returning to > native code, which moved to the new code location: > > primitive -> native code --(1)-> VM allocation procedure -> GC > > (1) - a return address , which should be fixed. > >> -- >> Marcus Denker Â -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

April 8, 2010

Re: [Pharo-project] CollabActive book :)

by Javier PimÃ¡s

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

April 8, 2010

Re: [Pharo-project] Show Actions of a SystemWindow: bug?

by Mariano Martinez Peck

Remember to put the state to fixed at the end...thus, it can be integrated. 2010/4/7 Carla F. Griggio <carla.griggio(a)gmail.com> > Whoops! It is Morph>> showActions :P > > I'll submit the bug and the fix :) > > I don't usually use that menu either, but I was playing with Morphs and I > recalled that I had seen that menu before and it could be usefull. Actually, > I didn't remember how to open it, I tried several key combinations until I > got it, hehehe. > > > > On Wed, Apr 7, 2010 at 10:45 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> add a bug entry :) >> >> On Apr 7, 2010, at 3:11 PM, Mariano Martinez Peck wrote: >> >> > >> > >> > 2010/4/6 Carla F. Griggio <carla.griggio(a)gmail.com> >> > Hello! >> > >> > I was fooling around with the latest rc3 image and I tried to use the >> "show actions" option in the menu of a SystemWindow and got this: >> > >> > MessageNotUnderstood: ToolSet class>>openMessageList:name:autoSelect: >> > ToolSet class(Object)>>doesNotUnderstand: >> #openMessageList:name:autoSelect: >> > SystemWindow(Morph)>>showActions >> > [] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >> > BlockClosure>>ensure: >> > CursorWithMask(Cursor)>>showWhile: >> > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >> > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: >> > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: >> > MouseButtonEvent>>sentTo: >> > ... >> > >> > This is the code in SystemWindow>>showActions: >> > >> > >> > Actually, it is Morph >> showActions ;) >> > >> > >> > >> > >> > ToolSet openMessageList: list name: 'Actions of ' , self >> printString autoSelect: false >> > >> > Shouldn't the last line be MessageSet openMessageList: list name: >> 'Actions of ' , self printString autoSelect: nil ? I tried it and it seemed >> to work OK, although I never tried that option before so I don't know what >> was it's original behaviour. >> > >> > >> > >> > I think your change is correct and it works. >> > It is funny it is almost the first time in my life I do a ctrl + click >> hahaha I saw that menu one or two times in my life :) >> > >> > Even more, I checked and it is broken since, at least, Squeak 3.9 haha >> > >> > So..Carla, can you open a bug ticket and submit the fix ? >> > >> > http://www.pharo-project.org/community/issue-tracking >> > >> > Thanks and good catch! >> > >> > Mariano >> > >> > >> > Cheers! >> > Carla. >> > >> > _______________________________________________ >> > 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 >> >> >> _______________________________________________ >> 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, The tests fail loudly, but that appears to be a known problem, and they can fail with FFI working (save doubles). Maybe the problem John mentions is behind the library loading troubles?? 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] 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