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

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

by Schwab,Wilhelm K

Dolphin's ability to wrap using COM type libraries is almost eerie, but you are correct that there is still more to know (very obvious with the Office Automation interfaces). The callout methods themselves are made possible by the work that went into creating the type library. For a bare dll/so, one would need to parse and "understand" header files to get as far as Dolphin's type library analyzer gets. Has someone familiar with VW's DLL & C-connect commented in this thread? Two questions: is it something worthy of our respect? If so, how far away are we? If we matched, how much more would there be to do? I ask the latter question relative to what is reasonable to expect, at least for foreseeable future. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of GermÃ¡n Arduino [garduino(a)gmail.com] Sent: Thursday, May 05, 2011 7:24 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Popularity of Smalltalk in Software Industry > > Haha.. i have strong suspicion that here you are talking about quite > specific set of libraries, > which using OLE/COM interfaces. Indeed, one could implement an > automatic "import/connect" tool > for it, because a library itself contain enough information reflecting > it interface(s). > You can check Dolphin smalltalk which works only on windows and has > integrated solution for that for years: > In same way like you described, you just pick the library, click "ok" > and its done & ready for use. > True, I was just ready to write the same thing about Dolphin and works very well, transforming OLE objects in Smalltalk objects with their respective methods. But allways you need to know what to do with such objects and methods. And is very dependent of the operating system and the underlying technology. I think that the cooperation with the outside world is needed, but I will not miss the advantages of work in Smalltalk, lot of times is more cheap to develop the needed stuff in Smalltalk than a complex artifact to interact with another technology. Cheers. GermÃ¡n.

May 6, 2011

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

by laurent laffont

On Fri, May 6, 2011 at 7:25 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 May 2011 18:45, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > On Fri, May 6, 2011 at 4:01 PM, Igor Stasenko <siguctua(a)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", 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] Send a notification

by Lukas Renggli

> Together with Ivan we have been looking for an easy way to send notifications. > We first thought about sending email directly from Pharo, but apparently it is not easy to send email. Anyone has experience with this? As long as your SMTP doesn't require encryption this is simple: Use MailSender that comes with every Pharo image. Seaside provides some objects on top of that, so that you don't have to assemble the message by hand. > We then thought about emitting twitts, but there is a need to authorize the client. Anyone has experience? Twitter requires OAuth, which requires an SSL capable HTTP client. > Maybe producing a RSS could do the thing? Again, simple with Seaside, but any XML library can do it. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 6, 2011

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

by Eliot Miranda

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

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

by Joseph T. Bore

On May 6, 2011, at 1:25 PM, Igor Stasenko wrote: > 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. call me crazy but: yes i would like that interface. ctypes works very well. i have used it plenty. it gives you the ability to get access to libraries trivially. you dont have to spend a week writing a wrapper for something you might only need for a short period of time. if you need to use that library extensively then you need to spend the time writing a proper library for it. you can call me crazy but i find functionality like this *extraordinarily* useful. both python and ruby have very nice implementations, its kind of a shame we dont yet. were all adults here, i understand that if i do something stupid i will get bad results, but i like having the ability to make that decision. jb -- A man can live and be healthy without killing animals for food; therefore, if he eats meat, he participates in taking animal life merely for the sake of his appetite. And to act so is immoral. -Leo Tolstoy

May 6, 2011

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

by Dave Mason

On May 6, 2011, at 13:25, Igor Stasenko wrote: > 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. Well, yes, actually. If it means they can access the big wide world beyond Smalltalk, lots of people *would* like that. Of course they'd like it better if there were the nice type-checking, etc. but presumably that would come incrementally. Seriously, this might be something I could contribute to Pharo. Especially if Igor can get a simple, but functional, start going easily. ../Dave

May 6, 2011

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

by Igor Stasenko

On 6 May 2011 18:45, laurent laffont <laurent.laffont(a)gmail.com> wrote: > On Fri, May 6, 2011 at 4:01 PM, Igor Stasenko <siguctua(a)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", 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. > Laurent -- Best regards, Igor Stasenko AKA sig.

May 6, 2011

Re: [Pharo-project] PetitParser puzzle

by Norbert Hartl

Ok, next try. Am 06.05.2011 um 13:59 schrieb Damien Pollet: > I have a unit test for a parser of mine: > > testLine > self fail: 'Just a line.' rule: #lineBlank. "passes" > self parse: 'Just a line.' rule: #lineNonBlank. "passes" > self parse: 'Just a line.' rule: #line. "end of input > expected at 0" > Here you test if the parser can consume all of the string. But it different to the situation if the parser succeeds. A star parser always succeeds. And the operator / only matches of the parser on the left side couldn't succeed. In the "line" case the lineBlank succeeds thus the right one is not tried. So no characters are consumed and the test fails because it does not parse. That was what first came to my mind but then I thought this might be just a hack to reverse the order of ther parser. But my initial mail was right. The more specific parser should go before to all matching parser. hope this helps, Norbert > Now the fun part: > > line > ^ lineBlank / lineNonBlank > > For reference, here are the rest of the involved rules: > > blank > ^ #blank asParser > > lineBlank > ^ blank star > > lineNonBlank > ^ blank star , blank not , lineEnd negate plus > > lineEnd > ^ (Character lf asParser) > / (Character cr asParser , Character lf asParser optional) > > Insights ? > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

May 6, 2011

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

by Igor Stasenko

On 6 May 2011 18:32, Stefan Marr <pharo(a)stefan-marr.de> wrote: > (And some more flame war here) > > > On 06 May 2011, at 17:11, Miguel CobÃ¡ wrote: > >>>>> No need to get into a cat-fight here :) >>>> >>>> No this is not my point. But what do people really do to help? >>> Stef, if you haven't noticed: I don't care about Smalltalk, and I don't care about Pharo, or any other language out there in particular. I don't share your vision, I have other goals in life. >> >> So what are you doing here, the less the noise the best for everyone >> else. You don't contribute, you only criticize, and then you said you >> don't care, the we don't care about your "opinion". You can keep it for >> yourself. > > 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. This statement is true for most of us, just replace "VM" with something else. About RoarVM. 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? 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? 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. I, personally all for having VM which knows how to exploit multicore/manycore systems. But at what costs? At cost of throwing away everything and implementing new VM and new smalltalk from scratch? I can do that myself. But then i wouldn't come to pharo list to say that i don't give a shit about pharo. Because if i would like Pharo to use my stuff, i will stay with people and help, and try to figure out how we can manage to leverage new technology without jumping too high with the risk to break the legs. It makes no point saying here that you don't give a shit about Pharo. If you don't, why pharoers should? 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, and given that day has 24 hours in it.. figure the answer :) > >>> That's what I mean. From my perspective, books about programming languages are a wast of effort. >>> You need a good entry level book, that is all it takes. >>> The rest is great online documentation. >> >> Umm, or you are very young or completely lost your mind. Internet as we >> know today has a decade at most. The documentation you as happy use now >> didn't existe 20 years ago. But, doesn't a lot of code was written more >> than Â 20 years ago. How is that possible just with fucking books and >> without google. >> -- Best regards, Igor Stasenko AKA sig.

May 6, 2011

Re: [Pharo-project] PetitParser puzzle

by Norbert Hartl

Oops, sorry, I was too quick the last reply. Norbert Am 06.05.2011 um 13:59 schrieb Damien Pollet: > I have a unit test for a parser of mine: > > testLine > self fail: 'Just a line.' rule: #lineBlank. "passes" > self parse: 'Just a line.' rule: #lineNonBlank. "passes" > self parse: 'Just a line.' rule: #line. "end of input > expected at 0" > > Now the fun part: > > line > ^ lineBlank / lineNonBlank > > For reference, here are the rest of the involved rules: > > blank > ^ #blank asParser > > lineBlank > ^ blank star > > lineNonBlank > ^ blank star , blank not , lineEnd negate plus > > lineEnd > ^ (Character lf asParser) > / (Character cr asParser , Character lf asParser optional) > > Insights ? > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

May 6, 2011