January 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] An ideal to strive for

by Sean P. DeNigris

I love this Tony Hoare quote: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies." -- View this message in context: http://forum.world.st/An-ideal-to-strive-for-tp4274780p4274780.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 8, 2012

[Pharo-project] [COTDC] 101 - TarArchiveMember

by sean＠clipperadams.com

100 classes done 796 classes remaining Continuing in Compression... Today: TarArchiveMember Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Jan. 8, 2012

Re: [Pharo-project] Cog+linux: external module not found

by David T. Lewis

On Sun, Jan 08, 2012 at 12:37:59AM +0000, Schwab,Wilhelm K wrote: > Eliot, > > SOL?? Is that really the message we want to send to current and *prospective* users? Canonical does something that makes sense from a security perspective (one needs root privileges to alter the ldconfig mapping, not to to use it). All the vm needs to do is request the #moduleName as given, and users of Pharo "SOL" as a result? > > Please reconsider. > > Bill > I think you are taking the response out of context. The actual statement was "Then you're SOL :) You'd need to write new support for Ubuntu." You might take that as a gentle suggestion to expend a bit of effort on it yourself. After all, it is open source, and Eliot is only one person. He can't do everything for everybody without a little help from the rest of us. Dave > > > > ________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] > Sent: Saturday, January 07, 2012 6:38 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Cog+linux: external module not found > > > > On Sat, Jan 7, 2012 at 8:49 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: > Nick, > > Partial success. After a false start with getting output from strace (my fault), it showed me that the vm was looking a lot in the vm's directory. A symlink by the same name, allowed it to see the library. Clearly, this is not a fix, because one should not be forced to make links to any/every library on the system. However, it *was* nice to see the version string in an inspector :) > > Looking at the strace output (relevant parts below), it tries with prepending lib, appending .so, .so.dylib. It looks in the vm's directory, and in the root directory, not /usr/lib. > > It has been almost a year (based on a dated comment) since I last really strained my synapses on the workings of ldconfig. On my systems, it would tell one to look for the library as follows: > > ldconfig -p | grep Acces > libAccesIO-USB.so (libc6) => /usr/lib/libAccesIO-USB.so > > #moduleName answers 'libAccesIO-USB.so', and Ian's vm finds it. My (and I use the term LOOSELY) understanding is that Ubuntu no longer uses LD_LIBRARY_PATH. dlopen() seems to prefer that one use the names as reported by ldconfig. The best explanation I have found is that the change was a security measure. > > Then you're SOL :) You'd need to write new support for Ubuntu. > > > How does one get ldconfig to "know" where something lives? Putting a .so file in /usr/lib (and perhaps other places too) and then running ldconfig as sudo appears to build a cache. Then ldconfig -p (anyone can run this) will show the map, and one can grep the result to find something specifc, as above. > > Putting files in /usr/lib is a pain for things under active development. A file can live anywhere if one puts a .conf file in /etc/ld.so.confd; the .conf files should contain paths to directories to be searched for .so files - or at least that's how it *appears* to work. Run ldconfig as sudo to refresh the mapping, and verify with ldconfig - p. > > The fix might be as simply as having the cog vm try passing the #moduleName to dlopen(). > > Nick, thanks for the nudge in a working direction. I will probably symlink another file and see if a mix of hardware and software will get closer to cooperating with me. > > Bill >

Jan. 8, 2012

Re: [Pharo-project] Misc. newbie questions

by Gerry Weaver

Hello All, Thank you for all of your responses. They are really helping me get a better picture of Pharo, the environment, and the community. I really like the idea of a REPL type interface. If I understand correctly, all of the functionality that deals with class/method definition is already there. It seems like it would be a matter of writing a little server type application that would communicate via stdin/stdout. I assume one could then send messages to the code that evaluates methods/function definitions and provide result feedback via stdout. Maybe it could also understand some commands like doit and accept. It could be interesting to have a TCP based interface as well. How difficult would it be to do something like this? I may start looking into this. It seems like a good project to jump into the deep end, start paddling, and drinking a little water (hopefully not too much). Is the code that handles this kind of thing readily accessible? I've started looking around a bit. Thanks, Gerry -----Original Message----- > From: "Frank Shearar" <frank.shearar(a)gmail.com> > To: Pharo-project(a)lists.gforge.inria.fr > Date: 01/07/12 09:28 > Subject: Re: [Pharo-project] Misc. newbie questions > > On 7 January 2012 15:11, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2012/1/7 Frank Shearar <frank.shearar(a)gmail.com>: > >> On 7 January 2012 14:14, Nicolas Cellier > >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >>> 2012/1/6 Lukas Renggli <renggli(a)gmail.com>: > >>>> On 6 January 2012 11:20, Peter Hugosson-Miller <oldmanlink(a)gmail.com> wrote: > >>>>> On 6 jan 2012, at 06:41, "Gerry Weaver" <gerryw(a)compvia.com> wrote: > >>>>> > >>>>> 2. There appear to be some tool choices in the Pharo image. I would like to > >>>>> be able to create a class and it's methods in an editor in one go. I like > >>>>> being able to see all of the class code at once. Is there a way to do this? > >>>>> Â I just want to be able to type it all in and accept (evaluate?) all at > >>>>> once. > >>>>> > >>>>> This is an interesting question to me personally. After 15 years of working > >>>>> exclusively in Smalltalk I've recently been forced to start programming in > >>>>> Java, where the source code is always (as far as I know) arranged in the way > >>>>> you describe. > >>>>> > >>>>> This organization just emphasizes the dead and compiled nature of Java (and > >>>>> similar languages), compared to the living objects of Smalltalk, where even > >>>>> methods are objects, created by sending messages to other objects. Source > >>>>> code is relegated to being a mere artifact, which can be saved and organized > >>>>> in any way one wishes, and preferably never shows its ugly face to the coder > >>>>> :-p > >>>> > >>>> Which of course is no argument why Smalltalk code could not be > >>>> displayed in a more programmer friendly way as a continuous block of > >>>> text. There is no technical reason why source ranges in text box > >>>> couldn't correspond to life method objects. Compared to other > >>>> languages it is extremely tedious in Smalltalk to get an overview over > >>>> a project, a package, or even a single class or to navigate between > >>>> entities. > >>>> > >>>>> And yes, I really *really* miss a good, object oriented class browser! > >>>> > >>>> Eclipse is pretty good, especially with the Java Browsing Perspective. > >>>> > >>>> Lukas > >>>> > >>> > >>> As soon as you would display the code for many methods in a single text pane, > >>> you will find file-based-educated people making large refactorings in > >>> a single pass... > >>> Imagine this leads to many syntax errors, they will soon be willing to > >>> save their changes for a later rework... > >>> This would be a complete change in programming flow and if we really > >>> want to support this, we would have to: > >>> - add a way to save syntactically incorrect code > >>> - let IDE tools work on partially correct code (syntax highlighting, > >>> navigation, etc...) > >>> > >>> IMHO, these features add a lot of complexity... Is it really worth? > >>> I like the discipline of focusing on a single method until it is at > >>> least syntactically correct. > >> > >> The Pharo community has extremely limited resources so it seems quite > >> fair to me for Pharo to say "yes, but it's up to you because we have > >> no time". It _is_ very useful to be able to see and edit long reams of > >> text: my favourite text editor's been beaten on since the late 70s. It > >> is now very, very good at manipulating text, in multiple programming > >> languages, in multiple human languages, on many platforms. That I > >> can't use this text editor to manipulate a textual representation of > >> my favourite language is extremely annoying! > >> > >> frank > > > > Yeah, but my take was that re-inventing a very narrow subset of these > > 40 years old text editors in Smalltalk would likely be a failure... > > (or a big project) > > It would be a fairlly big piece of work although we do have lots of > pieces lying around: > * Coral's working on a scripting/REPL-like interface, > * the Common Lisp community has been using SLIME to provide a REPL to > a running image for years while also using files to store their code, > * we have Gitocello (which also translates Squeak/Pharo to gst), > * we have LanguageBoxes (*) allowing us to permit craziness like > storing code outside the image in one format without affecting the > entire language (letting us store Smalltalk code in something other > than chunk format) > > (*) watch this space: I'm making progress on breaking up the Helvetia > image into a bootstrappable bunch of packages > > > There is also this recent related post which touch this subject: > > > > http://railsrx.com/2011/12/29/getting-back-to-smalltalk/ > > Amusingly, I only just finished reading that in my newsreader. I think > _personally_ that I need to port TWM to Squeak because I'm tired of > being the window manager, and hopefully that would solve my other > pain, which Noel points out - the ability to see multiple methods at a > time is _really useful_. > > (Trivial example: think of how clear code in ML or Haskell looks when > pattern matching on type, versus having five browsers open on various > subclasses' implementations of #foo.) > > I guess I'm saying: the rest of the world isn't automatically wrong > because they're not using Smalltalk, and I want to bring the best > parts of the non-Smalltalk stuff to Smalltalk (like having the > _option_ of using my favourite version control system, text editor, > IDE, etc.) > > frank > > > Nicolas > > > >> > >>> On the other hand, in Smalltalk we have to transfer the complexity of > >>> multi-method changes in the refactoring engines/menus when some simple > >>> modify/replace in a file would work. > >>> > >>> Nicolas > >>> > >>>> -- > >>>> Lukas Renggli > >>>> www.lukas-renggli.ch > >>>> > >>> > >> > >

Jan. 8, 2012

Re: [Pharo-project] Cog+linux: external module not found

by Schwab,Wilhelm K

Eliot, SOL?? Is that really the message we want to send to current and *prospective* users? Canonical does something that makes sense from a security perspective (one needs root privileges to alter the ldconfig mapping, not to to use it). All the vm needs to do is request the #moduleName as given, and users of Pharo "SOL" as a result? Please reconsider. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Saturday, January 07, 2012 6:38 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cog+linux: external module not found On Sat, Jan 7, 2012 at 8:49 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Nick, Partial success. After a false start with getting output from strace (my fault), it showed me that the vm was looking a lot in the vm's directory. A symlink by the same name, allowed it to see the library. Clearly, this is not a fix, because one should not be forced to make links to any/every library on the system. However, it *was* nice to see the version string in an inspector :) Looking at the strace output (relevant parts below), it tries with prepending lib, appending .so, .so.dylib. It looks in the vm's directory, and in the root directory, not /usr/lib. It has been almost a year (based on a dated comment) since I last really strained my synapses on the workings of ldconfig. On my systems, it would tell one to look for the library as follows: ldconfig -p | grep Acces libAccesIO-USB.so (libc6) => /usr/lib/libAccesIO-USB.so #moduleName answers 'libAccesIO-USB.so', and Ian's vm finds it. My (and I use the term LOOSELY) understanding is that Ubuntu no longer uses LD_LIBRARY_PATH. dlopen() seems to prefer that one use the names as reported by ldconfig. The best explanation I have found is that the change was a security measure. Then you're SOL :) You'd need to write new support for Ubuntu. How does one get ldconfig to "know" where something lives? Putting a .so file in /usr/lib (and perhaps other places too) and then running ldconfig as sudo appears to build a cache. Then ldconfig -p (anyone can run this) will show the map, and one can grep the result to find something specifc, as above. Putting files in /usr/lib is a pain for things under active development. A file can live anywhere if one puts a .conf file in /etc/ld.so.confd; the .conf files should contain paths to directories to be searched for .so files - or at least that's how it *appears* to work. Run ldconfig as sudo to refresh the mapping, and verify with ldconfig - p. The fix might be as simply as having the cog vm try passing the #moduleName to dlopen(). Nick, thanks for the nudge in a working direction. I will probably symlink another file and see if a mix of hardware and software will get closer to cooperating with me. Bill stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so.so<http://libAccesIO-USB.so.so>", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/liblibAccesIO-USB.so.so<http://liblibAccesIO-USB.so.so>", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("./libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("./libAccesIO-USB.so.so<http://libAccesIO-USB.so.so>", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("./libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("./liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("./liblibAccesIO-USB.so.so<http://liblibAccesIO-USB.so.so>", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("./liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("libAccesIO-USB.so.so<http://libAccesIO-USB.so.so>", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("liblibAccesIO-USB.so.so<http://liblibAccesIO-USB.so.so>", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/libAccesIO-USB.so.so<http://libAccesIO-USB.so.so>", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/liblibAccesIO-USB.so.so<http://liblibAccesIO-USB.so.so>", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/libAccesIO-USB.so.so<http://libAccesIO-USB.so.so>", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/liblibAccesIO-USB.so.so<http://liblibAccesIO-USB.so.so>", 0xbfd66c5c) = -1 ENOENT (No such file or directory) stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or directory) read(10, ">externalCallFailed\nAccesIOUSBLi"..., 3424) = 3424 read(10, ">externalCallFailed\nAccesIOUSBLi"..., 4096) = 3424 write(10, "FileAccess: ", 12) = 12 write(10, "SocketAccess: ", 14) = 14 write(10, "an AccesIOUSBLibrary", 20) = 20 write(10, "'libAccesIO-USB.so'", 19) = 19 write(10, "an AccesIOUSBLibrary", 20) = 20 write(10, "'libAccesIO-USB.so'", 19) = 19 write(10, "an AccesIOUSBLibrary", 20) = 20 write(10, "'libAccesIO-USB.so'", 19) = 19 write(10, "an AccesIOUSBLibrary", 20) = 20 write(10, "'libAccesIO-USB.so'", 19) = 19 write(10, "#'Hardware-AccesIO'", 19) = 19 write(10, "\t\ttextOrStream: \t'\t^AccesIOUSBLi"..., 65) = 65 write(10, "\t^ AccesIOUSBLibrary default AIO"..., 46) = 46 write(10, "a ReadStream '\t^AccesIOUSBLibrar"..., 61) = 61 write(10, "\t^AccesIOUSBLibrar...etc...", 27) = 27 write(10, "\t^AccesIOUSBLibrar...etc...", 27) = 27 write(10, "\t^AccesIOUSBLibrary defau...etc."..., 34) = 34 ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>] Sent: Saturday, January 07, 2012 8:55 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Cog+linux: external module not found It would also be nice to see (either via syslog()/OutputDebugString()) or (if possible) in the error itself, what library (full path) was being loaded. The output will generally be of interest only when something fails. Similar comments would apply to serial ports that won't open - what did the vm actually try to do when something failed? Most problems that I have had with getting Pharo to open something (library or port) have been relatively obvious to solve as soon as I saw how my intent was translated before it was passed on to the hardware (e.g. /usr/lib//this/that/something.so). Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Mariano Martinez Peck [marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>] Sent: Saturday, January 07, 2012 5:20 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Cog+linux: external module not found BTW, Eliot, is there a way so that FFI throws something different from "Module not found" when the module is there but not 32 bits? like "Module found but it is not 32 bits" ? cheers On Sat, Jan 7, 2012 at 10:04 AM, Nick Ager <nick.ager(a)gmail.com<mailto:nick.ager@gmail.com>> wrote: Hi Bill, Have you tried strace to determine what library it's failing to load? Nick On 7 January 2012 03:26, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Eliot, There is no /lib32 or /usr/lib32. As a double check, locate lib32 returns nothing. I put the library in /usr/lib, which is what I have done on two other Lucid systems. ldconfig shows it registered there. What's next? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>] Sent: Friday, January 06, 2012 7:29 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Cog+linux: external module not found On Fri, Jan 6, 2012 at 4:18 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Paul, The library is 32 bit - I build it from source because it ships with 64 bit binaries. Then try changing your LD_LIBRARY_PATH to /lib32:/usr/lib32:$LD_LIBRARY_PATH and see if that helps (if you have /lib32 & /usr/lib32 that is) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Paul DeBruicker [pdebruic(a)gmail.com<mailto:pdebruic@gmail.com>] Sent: Friday, January 06, 2012 6:59 PM To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Cog+linux: external module not found Schwab,Wilhelm K wrote > > Eliot, > > I'm getting the same error with your latest VM. Any ideas? > > Bill > > > When I had trouble with this it was a 64bit vs 32bit library mismatch on a 64bit OS. Is it a 32 bit or 64 bit OS? Is the library you're trying to reach 32bit? 64bit libs won't work with the 32bit CogVM, but are installed by default by the Ubuntu package manager on a 64bit Ubuntu. Ubuntu also moved some mandatory (from Cog's perspectvie) 32 bit libs from their ia32-libs package to the ia32-libs-multiarch recently but I don't know if that change affects Lucid. -- View this message in context: http://forum.world.st/Cog-linux-external-module-not-found-tp4271136p4271354… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- best, Eliot -- Mariano http://marianopeck.wordpress.com -- best, Eliot

Jan. 8, 2012

Re: [Pharo-project] [update 1.4] #14279

by Ben Coman

StÃ©phane Ducasse wrote: > 14279 > ----- > > - Issue 5157: Finder > Class > right-click > Hierarchy opens not on Class but on FinderClassNode. Tx Benjamin van Ryseghem. > http://code.google.com/p/pharo/issues/detail?id=5157 > > This was reported by me on Pharo-1.3-13315 yesterday and closed overnight, so I'm impressed with the response time. Now while this is hardly a critical issue I'm curious... now that it issue is marked closed, what is the plan to track these small fixes and roll them into a Pharo-1.3.1? Once you get the business support model up and running I would imagine this task falls to the paid engineers. (Release management is not exciting.) From a business perspective I would think that this is (almost) MORE important than the good refactoring work your doing to come out in a future version. There is a rule I've commonly seen in business to never use anything that is x.x.0. Wait for the "first service release" is the mantra. Seeing the versions go only from 1.3.0 to 1.4.0 to 1.5.0 does not instill business confidence in the stability of the platform. Maybe you are willing to sacrifice that image at this early stage to move faster with limited resources, but just something to consider. keep up the good work, cheers, Ben

Jan. 8, 2012

Re: [Pharo-project] Misc. newbie questions

by Eliot Miranda

On Sat, Jan 7, 2012 at 6:32 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 06.01.2012 06:41, Gerry Weaver wrote: > >> Hello All, >> >> Firstly, let me say that I am enjoying Pharo very much at this point. I >> wish I would have found the time to look at this a long time ago. >> >> I have a few misc. newbie questions. >> >> 1. VisualWorks - I am doing a lot of thinking about projects that I >> could use Smalltalk on. I have a consulting project coming up that might >> be a good candidate, but I'm sure I would be required to use a >> commercial Smalltalk version for it. I guess it may be odd to ask about >> VisualWorks on this list, but I'm not really looking for a comparison to >> Pharo. What I'm interested in is your opinion of the product. I would >> like to know if any of you would consider using it on a project. I would >> appreciate anything y'all could share in the form of experiences good or >> bad. I am trying to get my hands on it, but Cincom's mail server >> (windoze) is having issues. I am also having some trouble getting >> pricing out of them. Anyway, I would like to get your take on the Cincom >> products. >> >> >> 2. There appear to be some tool choices in the Pharo image. I would like >> to be able to create a class and it's methods in an editor in one go. I >> like being able to see all of the class code at once. Is there a way to >> do this? I just want to be able to type it all in and accept (evaluate?) >> all at once. >> >> 3. I've seen some discussion about images and image sizes. What is the >> current state of this. Is it possible to strip an image down to just the >> required components for an application (ie; no world menu, etc.). I >> would like to be able to run an image that would bring my gui >> application up filling the image window such that it looks a close as >> possible to a conventional gui application. >> >> 4. I have been reading about something called "Opentalk". It is a way >> for images to be able to comminucate with each other over the network. >> I've also seen something callesd "rST" that appears to do a similar >> thing. In addition, I notice that someone has done some FFI bindings for >> zeromq. What would y'all recommend as the best option to achieve >> something like this in Pharo? >> >> 5. I'm trying to figure out exactly what the Pharo gui toolkit provides >> in the way of widgets. Is there a widget gallery type thing somewhere >> that shows all of them? I know I can play with them in the image, but it >> would be nice to see a list of what is there with a brief description. >> >> 6. I know Pharo doesn't currently support OS threads in an image, but >> I'm wondering about the FFI. Is it possible to call a foreign function >> in a separate OS thread or asynchronously in Pharo? >> > > My understanding is with the very latest mt Cog VMs that FFI call-outs > happen in a native OS thread. I'm not sure whether the required > infrastructure is already in Pharo. > That's the idea in the MT (multi-threaded) VMs. But its not the case in the standard VM. This makes all FFI calls from the VM thread, blocking the VM until the call returns or calls-back. N.B. the MT VMs are not yet production ready. > Cheers > Philippe > > > > -- best, Eliot

Jan. 7, 2012

Re: [Pharo-project] Cog+linux: external module not found

by Eliot Miranda

On Sat, Jan 7, 2012 at 8:49 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Nick, > > Partial success. After a false start with getting output from strace (my > fault), it showed me that the vm was looking a lot in the vm's directory. > A symlink by the same name, allowed it to see the library. Clearly, this > is not a fix, because one should not be forced to make links to any/every > library on the system. However, it *was* nice to see the version string in > an inspector :) > > Looking at the strace output (relevant parts below), it tries with > prepending lib, appending .so, .so.dylib. It looks in the vm's directory, > and in the root directory, not /usr/lib. > > It has been almost a year (based on a dated comment) since I last really > strained my synapses on the workings of ldconfig. On my systems, it would > tell one to look for the library as follows: > > ldconfig -p | grep Acces > libAccesIO-USB.so (libc6) => /usr/lib/libAccesIO-USB.so > > #moduleName answers 'libAccesIO-USB.so', and Ian's vm finds it. My (and I > use the term LOOSELY) understanding is that Ubuntu no longer uses > LD_LIBRARY_PATH. dlopen() seems to prefer that one use the names as > reported by ldconfig. The best explanation I have found is that the change > was a security measure. > Then you're SOL :) You'd need to write new support for Ubuntu. > > How does one get ldconfig to "know" where something lives? Putting a .so > file in /usr/lib (and perhaps other places too) and then running ldconfig > as sudo appears to build a cache. Then ldconfig -p (anyone can run this) > will show the map, and one can grep the result to find something specifc, > as above. > > Putting files in /usr/lib is a pain for things under active development. > A file can live anywhere if one puts a .conf file in /etc/ld.so.confd; the > .conf files should contain paths to directories to be searched for .so > files - or at least that's how it *appears* to work. Run ldconfig as sudo > to refresh the mapping, and verify with ldconfig - p. > > The fix might be as simply as having the cog vm try passing the > #moduleName to dlopen(). > > Nick, thanks for the nudge in a working direction. I will probably > symlink another file and see if a mix of hardware and software will get > closer to cooperating with me. > > Bill > > > > stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so", 0xbfd66c5c) = > -1 ENOENT (No such file or directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so.so", > 0xbfd66c5c) = -1 ENOENT (No such file or directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so.dylib", > 0xbfd66c5c) = -1 ENOENT (No such file or directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/liblibAccesIO-USB.so", > 0xbfd66c5c) = -1 ENOENT (No such file or directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/liblibAccesIO-USB.so.so", > 0xbfd66c5c) = -1 ENOENT (No such file or directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/liblibAccesIO-USB.so.dylib", > 0xbfd66c5c) = -1 ENOENT (No such file or directory) > stat64("./libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("./libAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("./libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file > or directory) > stat64("./liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("./liblibAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file > or directory) > stat64("./liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such > file or directory) > stat64("libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("libAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("liblibAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file > or directory) > stat64("liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file > or directory) > stat64("/libAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("/libAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("/libAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such file > or directory) > stat64("/liblibAccesIO-USB.so", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("/liblibAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file > or directory) > stat64("/liblibAccesIO-USB.so.dylib", 0xbfd66c5c) = -1 ENOENT (No such > file or directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/libAccesIO-USB.so", > 0xbfd66c5c) = -1 ENOENT (No such file or directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/ > libAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/libAccesIO-USB.so.dylib", > 0xbfd66c5c) = -1 ENOENT (No such file or directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/liblibAccesIO-USB.so", > 0xbfd66c5c) = -1 ENOENT (No such file or directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/ > liblibAccesIO-USB.so.so", 0xbfd66c5c) = -1 ENOENT (No such file or > directory) > stat64("/home/bills/Work2010/Pharo-1.1.1/libAccesIO-USB.so/.libs/liblibAccesIO-USB.so.dylib", > 0xbfd66c5c) = -1 ENOENT (No such file or directory) > read(10, ">externalCallFailed\nAccesIOUSBLi"..., 3424) = 3424 > read(10, ">externalCallFailed\nAccesIOUSBLi"..., 4096) = 3424 > write(10, "FileAccess: ", 12) = 12 > write(10, "SocketAccess: ", 14) = 14 > write(10, "an AccesIOUSBLibrary", 20) = 20 > write(10, "'libAccesIO-USB.so'", 19) = 19 > write(10, "an AccesIOUSBLibrary", 20) = 20 > write(10, "'libAccesIO-USB.so'", 19) = 19 > write(10, "an AccesIOUSBLibrary", 20) = 20 > write(10, "'libAccesIO-USB.so'", 19) = 19 > write(10, "an AccesIOUSBLibrary", 20) = 20 > write(10, "'libAccesIO-USB.so'", 19) = 19 > write(10, "#'Hardware-AccesIO'", 19) = 19 > write(10, "\t\ttextOrStream: \t'\t^AccesIOUSBLi"..., 65) = 65 > write(10, "\t^ AccesIOUSBLibrary default AIO"..., 46) = 46 > write(10, "a ReadStream '\t^AccesIOUSBLibrar"..., 61) = 61 > write(10, "\t^AccesIOUSBLibrar...etc...", 27) = 27 > write(10, "\t^AccesIOUSBLibrar...etc...", 27) = 27 > write(10, "\t^AccesIOUSBLibrary defau...etc."..., 34) = 34 > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm > K [bschwab(a)anest.ufl.edu] > *Sent:* Saturday, January 07, 2012 8:55 AM > > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Cog+linux: external module not found > > It would also be nice to see (either via syslog()/OutputDebugString()) > or (if possible) in the error itself, what library (full path) was being > loaded. The output will generally be of interest only when something fails. > > Similar comments would apply to serial ports that won't open - what did > the vm actually try to do when something failed? Most problems that I have > had with getting Pharo to open something (library or port) have been > relatively obvious to solve as soon as I saw how my intent was translated > before it was passed on to the hardware (e.g. > /usr/lib//this/that/something.so). > > Bill > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano > Martinez Peck [marianopeck(a)gmail.com] > *Sent:* Saturday, January 07, 2012 5:20 AM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Cog+linux: external module not found > > BTW, Eliot, is there a way so that FFI throws something different from > "Module not found" when the module is there but not 32 bits? like "Module > found but it is not 32 bits" ? > cheers > > On Sat, Jan 7, 2012 at 10:04 AM, Nick Ager <nick.ager(a)gmail.com> wrote: > >> Hi Bill, >> >> Have you tried strace to determine what library it's failing to load? >> >> Nick >> >> >> On 7 January 2012 03:26, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> >>> Eliot, >>> >>> There is no /lib32 or /usr/lib32. As a double check, >>> >>> locate lib32 >>> >>> returns nothing. I put the library in /usr/lib, which is what I have >>> done on two other Lucid systems. ldconfig shows it registered there. >>> >>> What's next? >>> >>> Bill >>> >>> >>> >>> >>> ------------------------------ >>> *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ >>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda >>> [eliot.miranda(a)gmail.com] >>> *Sent:* Friday, January 06, 2012 7:29 PM >>> >>> *To:* Pharo-project(a)lists.gforge.inria.fr >>> *Subject:* Re: [Pharo-project] Cog+linux: external module not found >>> >>> >>> >>> On Fri, Jan 6, 2012 at 4:18 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: >>> >>>> Paul, >>>> >>>> The library is 32 bit - I build it from source because it ships with 64 >>>> bit binaries. >>>> >>> >>> Then try changing your LD_LIBRARY_PATH to >>> /lib32:/usr/lib32:$LD_LIBRARY_PATH and see if that helps (if you have >>> /lib32 & /usr/lib32 that is) >>> >>> >>>> >>>> Bill >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >>>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Paul >>>> DeBruicker [pdebruic(a)gmail.com] >>>> Sent: Friday, January 06, 2012 6:59 PM >>>> To: pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] Cog+linux: external module not found >>>> >>>> Schwab,Wilhelm K wrote >>>> > >>>> > Eliot, >>>> > >>>> > I'm getting the same error with your latest VM. Any ideas? >>>> > >>>> > Bill >>>> > >>>> > >>>> > >>>> >>>> When I had trouble with this it was a 64bit vs 32bit library mismatch >>>> on a >>>> 64bit OS. >>>> >>>> Is it a 32 bit or 64 bit OS? Is the library you're trying to reach >>>> 32bit? >>>> 64bit libs won't work with the 32bit CogVM, but are installed by >>>> default by >>>> the Ubuntu package manager on a 64bit Ubuntu. >>>> >>>> Ubuntu also moved some mandatory (from Cog's perspectvie) 32 bit libs >>>> from >>>> their ia32-libs package to the ia32-libs-multiarch recently but I don't >>>> know >>>> if that change affects Lucid. >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/Cog-linux-external-module-not-found-tp4271136p4271354… >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Jan. 7, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Levente Uzonyi

On Sat, 7 Jan 2012, Mariano Martinez Peck wrote: > On Sat, Jan 7, 2012 at 4:04 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Fri, 6 Jan 2012, Mariano Martinez Peck wrote: >> >> >>>> Thanks Levente. However, #pointersToExcept: does a GC at the >>>>>> >>>>> beginning... >>>>> so.. am I missing something? >>>>> >>>>> >>>> Yes, at the beginning The MethodContexts are created after that GC. >>>> >>>> >>>> But those MC shouldn't be excluded by the instVar >>> objectsToAlwaysExclude ? >>> >>> objectsToAlwaysExclude := { >>> results collector. >>> thisContext. >>> thisContext sender. >>> thisContext sender sender. >>> objectsToExclude. >>> }. >>> >> >> Since #pointsTo: is not a primitive anymore, > > > That's an interesting point. Now I understand this better. Even if I didn't > know the reasons (now I do), I even tried adding some more senders but > still they appear :( > I tried (for example) > > objectsToAlwaysExclude := { > results collector. > thisContext. > thisContext sender. > thisContext sender sender. > thisContext sender sender sender. > thisContext sender sender sender sender. > thisContext sender sender sender sender sender. > objectsToExclude. > }. > > What I don't understand is why in Squeak it does work. Because #pointsTo: is not used in Squeak (yet). As usual I dug deeper than I should have, so I'll publish a few changes soon. Levente > > Thanks in advance Levente! > > > > > >> it will create at least one new MethodContext which is not included in >> that list. >> >> >> Levente >> >> >>> >>> >>> >>> >>> >>>> Levente >>>> >>>> >>>> Thanks again. >>>>> >>>>> >>>>> >>>>> Levente >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Do you mean what I understand :)? that some tools compiled methods? :) >>>>>>> >>>>>>> >>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> Mariano >>>>>>> http://marianopeck.wordpress.******com <http://marianopeck.wordpress. >>>>>>> **** >>>>>>> com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.****com <http://marianopeck.wordpress.** >>>>> com <http://marianopeck.wordpress.com>> >>>>> >>>>> >>>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 7, 2012

[Pharo-project] Now you can use Fuel with FileSystem

by Mariano Martinez Peck

Hi guys. Now you can use FileSystem streams for Fuel. Fuel only needs one small package 'FuelFileSystem' which has just 3 extension methods, and that's all ;) There is also 'FuelFileSystemTests' which let's you run all fuel tests using FS. If you want to do that, change FLSerializationTest >> setUp to send #useFileSystemFileStream rather than #useStandardFileStream and that's all. To install: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFuel'; load. (ConfigurationOfFuel project version: #bleedingEdge) load: 'withFS'. An example: | sourceArray loadedArray serializer stream materializer | sourceArray := Array with: 'a string' with: Transcript with: [ Transcript show: 'a string' ]. "Create a file and serialize on it" stream := (FSLocator imageDirectory / 'example.fuel') writeStream. serializer := FLSerializer newDefault. serializer serialize: sourceArray on: stream. stream close. "Load from the file" stream := (FSLocator imageDirectory / 'example.fuel') readStream. materializer := FLMaterializer newDefault. loadedArray := (materializer materializeFrom: stream) root. Cheers -- Mariano http://marianopeck.wordpress.com

Jan. 7, 2012