May 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

by GermÃ¡n Arduino

2011/5/6 Sven Van Caekenberghe <sven(a)beta9.be>: > > On 06 May 2011, at 13:56, Johan Brichau wrote: > >> When I program in Smalltalk, I have a lot of open code browsers in my image >> When I program in Java/Javascript/..., I have a lot of open web pages on my desktop > > +1111 > > Browsing in a Smalltalk image should be self-documenting, not just because of comments, but because of beautiful, understandable code. > > A Dan Ingalls quote from "Design Principles Behind Smalltalk" ( http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html ) > > Just to get warmed up, I'll start with a principle that is more social than technical and that is largely responsible for the particular bias of the Smalltalk project: > > Â Â Â Â Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. > > An excellent read, this document, by the way! > > Sven > > > Full agree. I talked exactly about "Personal Mastery" on my talk in Smalltalks 2010 explaining my pov about why Smalltalk is good from a MicroISV (and not excluding other sort of companies). The talks are in Vimeo: http://www.vimeo.com/21859511 (Sorry with the self-promotion, but I think is worth to share my experience).

May 6, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 60 - DirectoryURI

by Guillermo Polito

I'd love to :). And OpaqueUri can be removed by just adding an attribute to URI for the boolean ;) On Fri, May 6, 2011 at 6:06 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > On Thu, May 5, 2011 at 8:21 PM, laurent laffont <laurent.laffont(a)gmail.com > > wrote: > >> Today: DirectoryURI >> > > This class is empty and only referenced in URI class, could be replaced by > HierarchicalURI.... Should we remove / deprecate it ? > > Laurent. > > > >> >> >> 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 >> >> Laurent >> > >

May 6, 2011

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

by Stefan Marr

On 06 May 2011, at 19:08, Igor Stasenko wrote: > I think the main reason why RoarVM does not exists for Pharo is > because there was no discussion and planning beforehead, how we could > cooperate. > Where the discussion, how we could introduce new execution models, and > gradually (means step by step) migrate to new VM? Igor, I remember some discussion from the Smalltalk school, two important points: 1. it is not a new execution model, but you do not have your old scheduling guarantees anymore. 2. "all it takes" is to make the important libraries thread-safe There is nothing fundamental in the RoarVM that is changing the language semantics of Smalltalk. It is just that for: `[do something] fork` you will have to assume that it is executed in parallel to other code. > Take into account there there is virtually no knowledge outside of > your team, what has to be changed in order to make Pharo run on > RoarVM. > So what did you expected? That people drop everything which already > works well for them and hastily migrate to new platform? No, of course not. I never expected anyone to jump onto a research platform, and it is also not really about adopting our C++ code, but about trying to integrate the ideas into the standard VM with Cog. Talking with Eliot basically resulted in the insight that there is no major problem that would prevent the adoption of parallel execution in the CogVM. They only thing we became aware of that might be interesting are the PICs. And there he had a nice paper reference with a perfectly good solution... > How about CogVM? Should we stop developing it? Or we should start > supporting both? And can we do that without too much pain? Give us the > idea. It is all about adopting the ideas, and I could collaboration on that, but I can't do that work. The only problem I see is that there does not seem to be a business case for a CogVM with parallel Smalltalk Process execution. > But then i wouldn't come > to pharo list to say > that i don't give a shit about pharo. Igor, the fact that the community did not show active interest in the RoarVM is much older than my bold statement. And, please understand my statement in the context of me not giving a damn about any particular language. Seriously, I can stand those 'ah but my language is so much nicer' discussions. And this here is just a variation of it. Languages are tools, and they are useful as long as they fit the problem. > I appreciate the engineering effort what you have did. But its a top > of the iceberg. Migrating existing system to another platform is very > complex task, Actually, for the RoarVM it is not. It is a lot of work, but it is not complex. It is tedious, but it can be done in small well defined steps. Perfect small projects for interested students. I already convinced two guys to apply for the Google Summer of Code. But well, that never happened... So, I do what I can, and actually more. But the community only responds to me when I say that I hate Smalltalk. Strange, isn't it? Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 6, 2011

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

by Schwab,Wilhelm K

We might be able to introduce a way to look for a mangled match, proceeding if it it unique, or something like that?? I have just dealt with it by finding the exported name and putting in the call definition. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of laurent laffont [laurent.laffont(a)gmail.com] Sent: Friday, May 06, 2011 4:44 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Popularity of Smalltalk in Software Industry On Fri, May 6, 2011 at 9:16 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Laurent, I am starting to understand your pain, or at least how it manifests itself in my world. First, the search path for libraries (Unix VM) can be a problem, not because of how it works, but because it does not tell me what it is trying to do. IMHO, any time the vm translates something (library name to search path, COM port name to number or vice versa), it should describe what it did, perhaps only if the attempt to open/load/whatever fails (if a load works, I'm probably happy and not looking). I have been known to hack the vm to add such tracing - syslog, stdout - wherever, but somewhere. Yes. I remember some mails you sent on this subject some months ago. Mangled names are another topic, but I do NOT consider this to be a Squeak/Pharo/VM failing of any type. The author of the library failed to use extern "C" - simple as that. I wonder why Python / Ruby can manage mangled names and that FFI don't. Because it's a real pain. Laurent. The most recent encounter I had with this was on Windows, and I left behind the following comment: The conspicuous (in hindsight) absence of extern "C" from the header file comes at a price: the names are mangled. Enter pexports.exe and some copy/paste with periodic acerbic remarks. Translation: if you have not done this, consider using pexports.exe to obtain the true exported symbol names, and put them (with ?@, etc. intact) in your FFI definitions. HTH. 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 laurent laffont [laurent.laffont(a)gmail.com<mailto:laurent.laffont@gmail.com>] Sent: Friday, May 06, 2011 2:34 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] Popularity of Smalltalk in Software Industry On Fri, May 6, 2011 at 8:06 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu><mailto:bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>>> wrote: No real agenda either way here, except to say that we almost have that in FFI. If you know enough to make the call, do you not know enough to write the FFI wrapper? Just asking. Having stirred the broth, I'll shut up and learn :) My last attempts: http://forum.world.st/Re-Z3950-on-OSX-module-yaz3-not-found-tp3161332p31613… http://forum.world.st/Re-FFI-crashes-VM-on-Linux-was-Z3950-on-OSX-module-ya… Any help appreciated. Laurent. ________________________________________ 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>> [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 [laurent.laffont(a)gmail.com<mailto:laurent.laffont@gmail.com><mailto:laurent.laffont@gmail.com<mailto:laurent.laffont@gmail.com>>] Sent: Friday, May 06, 2011 1:47 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr><mailto:Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>> Subject: Re: [Pharo-project] Popularity of Smalltalk in Software Industry On Fri, May 6, 2011 at 7:25 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com><mailto:siguctua@gmail.com<mailto:siguctua@gmail.com>><mailto:siguctua@gmail.com<mailto:siguctua@gmail.com><mailto:siguctua@gmail.com<mailto:siguctua@gmail.com>>>> wrote: On 6 May 2011 18:45, laurent laffont <laurent.laffont(a)gmail.com<mailto:laurent.laffont@gmail.com><mailto:laurent.laffont@gmail.com<mailto:laurent.laffont@gmail.com>><mailto:laurent.laffont@gmail.com<mailto:laurent.laffont@gmail.com><mailto:laurent.laffont@gmail.com<mailto:laurent.laffont@gmail.com>>>> wrote: > On Fri, May 6, 2011 at 4:01 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com><mailto:siguctua@gmail.com<mailto:siguctua@gmail.com>><mailto:siguctua@gmail.com<mailto:siguctua@gmail.com><mailto:siguctua@gmail.com<mailto:siguctua@gmail.com>>>> wrote: >> >> Is it works because someone already provided a bindings for libraries >> you mention, >> or you did it by yourself? > > Have just used ctypes: >>>> import ctypes >>>> import ctypes.util >>>> ctypes.util.find_library("yaz") > '/usr/local/lib/libyaz.dylib' >>>> yaz = ctypes.cdll.LoadLibrary("libyaz.dylib") >>>> con = yaz.ZOOM_connection_new("z3950.loc.gov<http://z3950.loc.gov><http://z3950.loc.gov><http://z3950.loc.gov>", 7090); oh cool.. give me a 5 minutes to load external library, look up the random symbol exported by it and make a call to it with random number of arguments, and expect it won't crash. Works outta box! Cool. Now serious. How about spending time writing a bindings for that library? Where you have properly organized classes/interfaces, error handling and other stuff. No takers? Seriously, if you want such kind of shitty interface, which allows you to call arbitrary function with arbitrary arguments without any argument type checking, i can write it for you. Do it, please do it. Seriously. Thanks Laurent. > Laurent -- Best regards, Igor Stasenko AKA sig.

May 6, 2011

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

by Toon Verwaest

> I am interested in VMs, so why do I need to care about the language on top? Actually, I do research in how to support all kind of different languages on top of the same VM, because there is not a single language that is the ultimate answer to all problems. That is why I do not care about any particular language. > Just look at the JVM. How much of its technology was developed in the pure Java context? Not a lot. Most was actually conceived for Smalltalk. > As long as the languages have some commonalities and are not based on graph-reduction like Haskell, then they usually don't require a completely new designed VM, but a nice set of common abstractions. So why, as a researcher, should I care about Smalltalk? Smalltalk is not the final answer, and will never be. Neither is any other single language. +1 > Just answer the question! How often do your colleagues grab a book from the shelf? How often a day, how often a week? Some of my colleagues use books quite often. They like to put their monitors on them. :) > Still, there is already a good thing coming out of the whole flame war. Laurent took the time to look into how to make the books web-accessible. All it took was a small nudge in the right direction. Yay :) Lets stop this thread in peace and have a nice weekend :) Goodbye and thanks for all the fish!

May 6, 2011

Re: [Pharo-project] Popularity of Smalltalk in Software Industry

by Stefan Marr

(and here we go again...) On 06 May 2011, at 18:55, Miguel CobÃ¡ wrote: > El vie, 06-05-2011 a las 18:32 +0200, Stefan Marr escribiÃ³: >> Well, I think my work on the RoarVM is some contribution, no? Perhaps, I would be more interested in Pharo if it would actually run nicely on the RoarVM, but I am stuck with a Squeak 3.x MVC image for my day to day work. And without anyone from the community approaching the work to make Pharo thread-safe that won't change. It is nice to change the world with Pharo, but the future is multi/manycore and Pharo does not support it. Ah, and the day has just 24h so don't expect anything from me beside the VM work, thats already enough to keep a whole team busy. >> > > I found your post very contradicting and without internal consistency. > You don't care about smalltalk but are creating a vm should run > smalltalk (squeak or pharo) in multiple core. Don't get it. Or you care > that you dedicate time to it or you don't care and don't know why you > build a multicore vm for a system you don't care (maybe the money, the > papers, the citations, don't know) I am interested in VMs, so why do I need to care about the language on top? Actually, I do research in how to support all kind of different languages on top of the same VM, because there is not a single language that is the ultimate answer to all problems. That is why I do not care about any particular language. Just look at the JVM. How much of its technology was developed in the pure Java context? Not a lot. Most was actually conceived for Smalltalk. As long as the languages have some commonalities and are not based on graph-reduction like Haskell, then they usually don't require a completely new designed VM, but a nice set of common abstractions. So why, as a researcher, should I care about Smalltalk? Smalltalk is not the final answer, and will never be. Neither is any other single language. >>>> That's what I mean. From my perspective, books about programming languages are a wast of effort. >> That is BS. >> How often do you see your colleagues going to the library, or the > shelf next door to grab a book while they are programming? >> It has been 10 years ago that they stopped doing so. > > That is the reason that O'Reilly books is broken and stop printing books > 5 year ago right. Also this other publisher, I think they use to call > themselves the pragmatic progammer, what a bunch of loser, trying to > publish new books in this days that google has everything that is to > know. > > Wait, no, they exists and publish books, maybe is for having something > to do with their free time. Just answer the question! How often do your colleagues grab a book from the shelf? How often a day, how often a week? >> Today, they google. Well, at least if they use another language than Smalltalk. >> And I don't think there is something inherently wrong with that. >> > > Yes but isn't the only way to get knowledge. No, but to my experience books can only be a help to get an initial overview. How often do you come across a book that covers a topic in such a depth that you actually can use it when you have a specific question while working? Especially the Pragmatic Programmer books you refer to, most of them talk about the basic concepts. They are not full references. Nice introductions, but nothing to actually work with when you solve a deeper going problem. > Maybe assembler should be > lectured no more, because we have high level programing languages and > nobody needs that old tech anymore! What are you talking about? > You said: >>> That's what I mean. From my perspective, books about programming > languages are a wast of effort. > > and then: > >> I think, Stef's efforts of writing books should be supported, > > inconsistent! Right, it is indeed inconsistent, since that statement now also includes having books for introductory purposes. But again, that was not the initial point of the discussion. Still, there is already a good thing coming out of the whole flame war. Laurent took the time to look into how to make the books web-accessible. All it took was a small nudge in the right direction. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 6, 2011

Re: [Pharo-project] Relational Databases [WAS] Re: Nile tests red - Pharo 1.3

by Alain rastoul

Cool. Looks like really worth to have a look at dbxtalk -- Alain_rastoul

May 6, 2011

Re: [Pharo-project] [COTDC] 60 - DirectoryURI

by laurent laffont

On Thu, May 5, 2011 at 8:21 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: DirectoryURI > This class is empty and only referenced in URI class, could be replaced by HierarchicalURI.... Should we remove / deprecate it ? Laurent. > > > 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 > > Laurent >

May 6, 2011

Re: [Pharo-project] DBXTalk (SqueakDBX) goes to Pharo 1.3

by Alain rastoul

++ :) Will test mssql asap (next week) On Fri, 29 Apr 2011 22:39:43 +0200, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: > +1 -- Alain_rastoul

May 6, 2011

Re: [Pharo-project] doesNotUnderstand:/createActualMessageTo: for zero-argument sends appears to imply the need for an extra stack slot in methods

by Toon Verwaest

Seems to make sense. If they didn't allocate small/big frames but exactly just enough space for the arguments this will indeed fail. You could also change the DNU to reallocate the frame on demand; maybe even only if the argsize is 0? I don't know the implementation details obviously, but it seems like you would waste less space to do it that way; although you will get a slight performance hit for the DNU, but that seems less relevant. cheers, Toon On 05/06/2011 07:39 PM, Eliot Miranda wrote: > Hi All, > > could you check my reasoning here. I think I've found a serious > bug in the VM with doesNotUnderstand: processing for zero-argument > sends and the calculation of the necessary stack size in > MethodNode>>generate:* (senders of CompiledMethod>>needsFrameSize:). > The bug causes a push beyond the end of a context, overwriting the > header of the following object, when an MNU occurs for a zero-argument > send when the stack is full. If you look at > Interpreter>>createActualMessageTo: it does the following to push the > message created as the argument of the doesNotUnderstand: > > self pop: argumentCount thenPush: message > > If argumentCount is zero this pushes an item on the stack. If the > stack is full at this point (the receiver of the not-understood > message is the last item in the context) then the push will be out of > bound of the activeContext's stack and overwrite the first word of the > following object's header. > > We observe this with a Newspeak application at Cadence and see a > subsequent VM crash. > > 1. am I right? > > 2. is this an old bug? > > 3. did this, or did this not, affect Smalltalk-80 v2 and e.g. the > Dorado implementation, and if so why (e.g. was the message of an MNU > not pushed onto the stack, and instead MNUs activated by special > code?, or was the activeContext not on the heap? or...) > > 4. what's the right fix? It seems to me that the right fix is simply > to add one to the needed stack depth, with an explanatory comment, but > in senders of CompiledMethod>>needsFrameSize: or > in CompiledMethod>>needsFrameSize:? Trying to avoid pushing the > argument of an MNU is going to involve lots of changes to the VM and > will be tricky and likely have a bug tail. > > > best, > Eliot

May 6, 2011