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

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

[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