- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

>> 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. Ok Igor will do it :) Igor you have too now :) Stef

May 7, 2011

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

by StÃ©phane Ducasse

> >> 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? +1 > > 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? +1 > 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. +1 > > 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 :)

May 7, 2011

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

by StÃ©phane Ducasse

Laurent igor is right if the bindings are done and package then of course this is different than just calling them. Stef > > > 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); > > Indeed, I think the great thing is that I could write this in 5 mn just looking at the doc, haven't used python for years. > > In Pharo, well, ......... > > > Laurent. > > > > Laurent > > > Here a first hit from google search: > > http://lists.indexdata.dk/pipermail/yazlist/2002-May/000269.html > > <quote> > I wrote these files for more than 2 years ago to play with SWIG and PERL, they > are far from being used, but I have just done a fast perl test and the results > were just fine. > > zclient.c > zclient.h > zclinet.i swig interface file > > The zclient_wrap.c will be created as > > > swig -python zclient.i > > which should be compiled and linked with the rest > </quote> > > So? Do you think it was easy in first place to a guy who did it from scratch? > Now you can easily use it (and its just works out of the box). But it > is because someone did it before you! > > And if you gonna repeat same from scratch, then you will have to learn: > - C > - SWIG > - Python > > so, do you still think that it easier to do that in Python than in Smalltalk? > > > But when I was working with Python and Ruby several years ago things was > > easy (for my needs), I think because of documentation. > > Laurent > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > >

May 7, 2011

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

by StÃ©phane Ducasse

>> >> 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. you can say that simply because I encouraged you to push some fixes to pharo and you told me that I have to do it myself more or less. So > 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. you see. This is always other job :) Stef

May 7, 2011

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

by Douglas Brebner

On 07/05/2011 01:06, Igor Stasenko wrote: > On 6 May 2011 23:45, Stefan Marr<pharo(a)stefan-marr.de> wrote: >> On 06 May 2011, at 19:08, Igor Stasenko wrote: >> >>> 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. >> > I can tell you more: there is no business cases for VM(s) which can do > manycore :) > At least, to my perception, there is not much pressure from people > (even on mainstream languages) to leverage this technology. > I thought it is very close to come into our houses, but no.. it stuck > somewhere on marketplace, buying a better clothes. > I have the bad feeling that there will continue to be no business case for manycore VMs (or serious concurrency in general) until we hit a wall at which point they'll suddenly go from uninteresting to desperately essential and any language not able to make the jump will be in big trouble. Besides, wasn't part of Smalltalk all about leading the way rather than following behind?

May 7, 2011

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

by Douglas Brebner

On 06/05/2011 22:23, Stefan Marr wrote: > (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. Smalltalk the language no. Smalltalk the infinitely malleable environment? That's another question :)

May 7, 2011

Re: [Pharo-project] Want ugly FFI interface [was: Popularity of Smalltalk in Software Industry]

by laurent laffont

> > > >> > 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. > > Oh. Okay. I will put that in my years-long todo list. Remind me time to > time :) > This is just a matter of priority. I vote for highest :) Laurent > > > > >> > >> > Laurent > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > >> > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

May 7, 2011

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

by Michael Haupt

Hi Igor, Am 07.05.2011 um 02:06 schrieb Igor Stasenko <siguctua(a)gmail.com>: > Heh.. then we're 99% done. Except that this last 1% is still could > take years to complete :) you serious? Making a Smalltalk image thread-safe is that hard? > I can tell you more: there is no business cases for VM(s) which can do > manycore :) > At least, to my perception, there is not much pressure from people > (even on mainstream languages) to leverage this technology. What market are you talking about? There are lots and lots of customers of certain big database/appliance vendors that would loudly protest had the stuff they bought no inherent support for parallel execution. > I thought it is very close to come into our houses, but no.. it stuck > somewhere on marketplace, buying a better clothes. And now it's arrived in tablets already. It's your problem if you leave your iPad lying around *outside* your house. ;-) > Implementing VM which enabling massive parallelism is just a > beginning. Then obviously you need do to a lot at language side > to leverage that, in order to really say "yes, our system(s) are aware > of multicore and can scale almost linearly in future". And do not forget the most important thing: people must be educated to program for parallelism. The computing power is there to be exploited, but programmers need to know how to exploit it. You can't rely on the compiler or VM alone. > Now, given that squeak's code a hugely non-thread-safe, imagine how > many iterations in redesign it would take to make it thread-safe > first, and then make it run in parallel with rest of the stuff. Is it really *that* hard or is this just FUD? > Best, Michael

May 7, 2011

Re: [Pharo-project] Instantiations forum moved to forum.world.st!

by Geert Claes

Big thanks to John O'Keefe from Instantiation! -- View this message in context: http://forum.world.st/Instantiations-forum-moved-to-forum-world-st-tp350290… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 7, 2011

Re: [Pharo-project] Tutorial on Announcements

by DougEdmunds

http://forum.world.st/file/n3504921/wiki_GUI.png Snapshot of the GUI created in the tutorial. -- View this message in context: http://forum.world.st/Tutorial-on-Announcements-tp3485040p3504921.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 7, 2011