- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by Antony Blakey

On 18/03/2009, at 10:46 PM, Igor Stasenko wrote: > I hear the magic word 'concurrency' .. :) > With green threading model we have a kind of concurrency on a > language level.. > except that its not scaling on to multiple native threads. The Erlang/Scala/Clojure concurrency models are applicable to a green threads model. Concurrency is difficult even with green threads. > There were a lot of discussion around native threading support and > everyone agrees that less sharing means less problems. Which is what such concurrency models provide. I suggest gaining some familiarity with Erlang/Scala/Clojure to protect against Smalltalk- insularity. > From this point, running separate object memory per native thread seem > most perspective way. That ties you to only doing large grained concurrency. What if I want thousands of threads, automatically distributed over the available hardware? Are you assuming that concurrency is limited to the number of running images, and each image is strictly single threaded? Concurrency is useful at many different levels of granularity. Using multiple images requires you to use one method for dealing with per- image concurrency (and currently those mechanisms aren't great) and another when considering multiple threads. And what about the tools to make debugging, profiling, deployment, management etc work over these multi-image systems? That might be more work than just biting the bullet and providing scalable concurrency within the image. > Running single object memory on multiple native threads opens a can of > worms. And the complexity of VM implementation will be overwhelming. Not neccessarily. There may well be legacy issues related to specific VMs and images, but the problem itself is not overwhelming. If it were you wouldn't have the JVM or CLR. This argument is exactly what I meant when I wrote: > If this were the "good old days"(TM) I'm sure someone would be > working on decent concurrency support for Smalltalk. Using multiple > images is one approach, but not one that I like - it seems (IMHO) to > be a reaction to the lack of resources to do something better. I would prefer to tackle this problem and do something worthy of Smalltalk's oft-proclaimed awesomeness. Instead we pretend that the multi-image model is actually a good and principled decision - but it's not, it's surrender. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. -- Antoine de Saint-Exupery

March 18, 2009

Re: [Pharo-project] Pharo Custom Menus

by Mariano Martinez Peck

Yes!!!! I find that very very useful. I put lots of doIts or snippets of code I usually use. Greetins, Mariano 2009/3/17 Rob Rothwell <r.j.rothwell(a)gmail.com> > One of the things I like about the standard Squeak World menu is the > "do..." menu--particularly when paired with "edit this list." > > What do you think about having some core functionality for creating your > own menu entries in Pharo? > > Unless, of course, it's already there and I just can't find it! > > Rob > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 18, 2009

Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by Igor Stasenko

2009/3/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi all > > I found this email really interesting. > Especially the concurrent aspects. > Clearly some nice research projects in perspective. > Also the immutability bit supports would be great. > I hear the magic word 'concurrency' .. :) With green threading model we have a kind of concurrency on a language level.. except that its not scaling on to multiple native threads. There were a lot of discussion around native threading support and everyone agrees that less sharing means less problems. >From this point, running separate object memory per native thread seem most perspective way. Running single object memory on multiple native threads opens a can of worms. And the complexity of VM implementation will be overwhelming. > Stef > > Begin forwarded message: > >> From: Antony Blakey <antony.blakey(a)internode.on.net> >> Date: March 18, 2009 2:50:47 AM CEST >> To: dfinlayson(a)usgs.gov, VWNC NC <vwnc(a)cs.uiuc.edu> >> Subject: Re: [vwnc] Would you start a new Smalltalk project today? >> >> I am a commercial user of VW. >> >> I've recently replaced my VW/GLORP/Postgresql app with one built in >> Ruby/CouchDB. I moved to Ruby because the documentation/learning >> material is superior to VW, because of the number of third party >> components, which is partly an issue of VW not being Open Source, >> because of tools such as Rails, Sinatra and Merb (which I still prefer >> over Seaside), and because I needed to focus on sustainable technology >> transfer into a market that won't accept VW. Tangentially I wanted to >> (subjectively) quantify the productivity improvement due to Smalltalk >> relative to another dynamic language (as opposed to Java in Eclipse). >> >> My experience with Ruby is that the language itself is just too much >> of a hack, and this was especially brought home to me when I started >> doing Scala and Clojure, and that emphasized for me the beauty of >> Smalltalk and Lisp/Scheme. >> >> I'm going back to Smalltak for new commercial development, partly >> because of this, but also because a) the Squeak community is getting a >> real injection of energy with Cog and Pharo (which itself pushes >> Squeak) and b) I'm getting a good feeling about the way the Cincom >> team is changing VW - not only what they're doing, but there seems to >> be a much clearer vision and approach that when I first encountered >> it. >> >> I'm also building a commercial application in Scala and Clojure. Both >> are great languages, especially for highly concurrent apps, and the >> library support is huge because they seamlessly use Java. If this were >> the "good old days"(TM) I'm sure someone would be working on decent >> concurrency support for Smalltalk. Using multiple images is one >> approach, but not one that I like - it seems (IMHO) to be a reaction >> to the lack of resources to do something better. Most of the Erlang/ >> Scala/Clojure goodness could be layered into Smalltalk if someone had >> the will to do so, but I think Cincom would have to do that for it to >> get the wide support it would need to have a dependable future. >> >> One benefit that a JVM language has, as opposed to Smalltalk, is that >> both the underlying performance improves, and the available libraries >> increase and improve independently of the language. Clojure and Scala >> don't need effort per se to improve. Oh for a Smalltalk running on the >> JVM in a high performance manner, with JVM object model integration. I >> think there is no other way to solve this problem for Smalltalk. >> >> I really miss programming in an image despite the pain of the Object/ >> Subject problem. I don't think it's *always* more productive than >> Scala or Clojure (esp for concurrency) but it's more *consistently* >> productive. >> >> Smalltalk's decline has not been terminal, implementations are >> improving albeit more slowly than one would like, and as long as it's >> the right tool for the job then you should use it. >> >> On 18/03/2009, at 8:03 AM, David Finlayson wrote: >> >>> Clojure has some great ideas but you need to know Lisp and Emacs. >> >> Both Scala and Clojure have good and improving support in (to varying >> degrees) IntelliJ, Eclipse, and NetBeans - no Emacs/Slime/VIM >> required. I use Clojure and Scala in IntelliJ, and I've done so in >> Eclipse as well. >> >>> 2. No Smalltalk I've used has a decent GUI. Squeak is an >>> abomination, down the road Pharo may be good, but not today and VW >>> looks like it hasn't been updated since the NT days. Although >>> everyone hates Java cross-platform desktop apps, it is interesting >>> to compare a VW app (say Bottom Feeder) to a Java app of similar >>> design (http://www.rssowl.org/overview) In my opinion the Java >>> version fits in a lot better than the VW version (particularly on >>> the Mac). >> >> For VW, my LinkuisticsUI bundle in the public Store improves the >> situation somewhat on OSX for VW 7.6. Cincom are also making >> improvements to the OSX UI for 7.7. >> >> Closure and Scala have Swing integration. Scala has very good SWT >> bindings. All three IDEs have GUI builders. >> >> Maybe you should consider a Web UI - checkout tools such as Capuccino >> and efforts like bespin. >> >> Antony Blakey >> ------------- >> CTO, Linkuistics Pty Ltd >> Ph: 0438 840 787 >> >> A reasonable man adapts himself to suit his environment. An >> unreasonable man persists in attempting to adapt his environment to >> suit himself. Therefore, all progress depends on the unreasonable man. >> Â -- George Bernard Shaw >> >> >> _______________________________________________ >> vwnc mailing list >> vwnc(a)cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 18, 2009

Re: [Pharo-project] Setting system categories ?

by Michael Rueger

Alain Plantec wrote: > Hi all, > I would like to know which system category/package to use for settings. > other solution ? > System-Setting-Core > System-Setting-Morphic > System-Setting-Browser this sounds good to me :-) Michael

March 18, 2009

Re: [Pharo-project] pharo channel?

by Adrian Lienhard

Hi Sebastian, Thanks for the suggestions. I updated the page http://www.pharo-project.org/community Cheers, Adrian On Mar 18, 2009, at 12:01 , Sebastian Sastre wrote: > Hi Adrian, > for a quick read is almost invisible and the eyes goes to the > sponsor block > instead of the channel text. > I've only saw the IRC reference the second time I've visited the > page searching > explicitely for it and when slowly read all. > Maybe if the IRC paragraph is moved to be before the Mailing List it > gets > balanced? > besides.. what you think about a warm title i.e: "come over and say > hi" or "come > say hi" instead of a cold "IRC" ? > cheers > sebastian > > >> -----Mensaje original----- >> De: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] En >> nombre de Adrian Lienhard >> Enviado el: Friday, March 13, 2009 12:37 >> Para: Pharo-project(a)lists.gforge.inria.fr >> Asunto: Re: [Pharo-project] pharo channel? >> >> I added it to http://www.pharo-project.org/community >> >> Adrian >> >> On Mar 13, 2009, at 16:27 , StÃ©phane Ducasse wrote: >> >>> indeed we do not chat a lot on channels >>> but may be we should add that to the web site. >>> I would encourage other to participate. >>> >>> Stef >>> >>> On Mar 13, 2009, at 2:16 PM, Damien Cassou wrote: >>> >>>> On Fri, Mar 13, 2009 at 2:08 PM, Sebastian Sastre >> <ssastre(a)seaswork.com >>>>> wrote: >>>>> I see a lot of activity in the list and I found it cool. >>>>> List aside, I'm the only one to feel that an IRC channel about >>>>> pharo will make >>>>> us feel closer one each other? >>>> >>>> #pharo-project exists but is too often calm. >>>> >>>> -- >>>> Damien Cassou >>>> http://damiencassou.seasidehosting.st >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 18, 2009

Re: [Pharo-project] pharo channel?

by Sebastian Sastre

Hi Adrian, for a quick read is almost invisible and the eyes goes to the sponsor block instead of the channel text. I've only saw the IRC reference the second time I've visited the page searching explicitely for it and when slowly read all. Maybe if the IRC paragraph is moved to be before the Mailing List it gets balanced? besides.. what you think about a warm title i.e: "come over and say hi" or "come say hi" instead of a cold "IRC" ? cheers sebastian > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > nombre de Adrian Lienhard > Enviado el: Friday, March 13, 2009 12:37 > Para: Pharo-project(a)lists.gforge.inria.fr > Asunto: Re: [Pharo-project] pharo channel? > > I added it to http://www.pharo-project.org/community > > Adrian > > On Mar 13, 2009, at 16:27 , StÃ©phane Ducasse wrote: > > > indeed we do not chat a lot on channels > > but may be we should add that to the web site. > > I would encourage other to participate. > > > > Stef > > > > On Mar 13, 2009, at 2:16 PM, Damien Cassou wrote: > > > >> On Fri, Mar 13, 2009 at 2:08 PM, Sebastian Sastre > <ssastre(a)seaswork.com > >>> wrote: > >>> I see a lot of activity in the list and I found it cool. > >>> List aside, I'm the only one to feel that an IRC channel about > >>> pharo will make > >>> us feel closer one each other? > >> > >> #pharo-project exists but is too often calm. > >> > >> -- > >> Damien Cassou > >> http://damiencassou.seasidehosting.st > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 18, 2009

[Pharo-project] Setting system categories ?

by Alain Plantec

Hi all, I would like to know which system category/package to use for settings. Currently, I've : Setting-Core SettingSupport-Morphic SettingSupport-Browser other solution ? System-Setting-Core System-Setting-Morphic System-Setting-Browser or something else ? thanks alain

March 18, 2009

[Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?

by StÃ©phane Ducasse

Hi all I found this email really interesting. Especially the concurrent aspects. Clearly some nice research projects in perspective. Also the immutability bit supports would be great. Stef Begin forwarded message: > From: Antony Blakey <antony.blakey(a)internode.on.net> > Date: March 18, 2009 2:50:47 AM CEST > To: dfinlayson(a)usgs.gov, VWNC NC <vwnc(a)cs.uiuc.edu> > Subject: Re: [vwnc] Would you start a new Smalltalk project today? > > I am a commercial user of VW. > > I've recently replaced my VW/GLORP/Postgresql app with one built in > Ruby/CouchDB. I moved to Ruby because the documentation/learning > material is superior to VW, because of the number of third party > components, which is partly an issue of VW not being Open Source, > because of tools such as Rails, Sinatra and Merb (which I still prefer > over Seaside), and because I needed to focus on sustainable technology > transfer into a market that won't accept VW. Tangentially I wanted to > (subjectively) quantify the productivity improvement due to Smalltalk > relative to another dynamic language (as opposed to Java in Eclipse). > > My experience with Ruby is that the language itself is just too much > of a hack, and this was especially brought home to me when I started > doing Scala and Clojure, and that emphasized for me the beauty of > Smalltalk and Lisp/Scheme. > > I'm going back to Smalltak for new commercial development, partly > because of this, but also because a) the Squeak community is getting a > real injection of energy with Cog and Pharo (which itself pushes > Squeak) and b) I'm getting a good feeling about the way the Cincom > team is changing VW - not only what they're doing, but there seems to > be a much clearer vision and approach that when I first encountered > it. > > I'm also building a commercial application in Scala and Clojure. Both > are great languages, especially for highly concurrent apps, and the > library support is huge because they seamlessly use Java. If this were > the "good old days"(TM) I'm sure someone would be working on decent > concurrency support for Smalltalk. Using multiple images is one > approach, but not one that I like - it seems (IMHO) to be a reaction > to the lack of resources to do something better. Most of the Erlang/ > Scala/Clojure goodness could be layered into Smalltalk if someone had > the will to do so, but I think Cincom would have to do that for it to > get the wide support it would need to have a dependable future. > > One benefit that a JVM language has, as opposed to Smalltalk, is that > both the underlying performance improves, and the available libraries > increase and improve independently of the language. Clojure and Scala > don't need effort per se to improve. Oh for a Smalltalk running on the > JVM in a high performance manner, with JVM object model integration. I > think there is no other way to solve this problem for Smalltalk. > > I really miss programming in an image despite the pain of the Object/ > Subject problem. I don't think it's *always* more productive than > Scala or Clojure (esp for concurrency) but it's more *consistently* > productive. > > Smalltalk's decline has not been terminal, implementations are > improving albeit more slowly than one would like, and as long as it's > the right tool for the job then you should use it. > > On 18/03/2009, at 8:03 AM, David Finlayson wrote: > >> Clojure has some great ideas but you need to know Lisp and Emacs. > > Both Scala and Clojure have good and improving support in (to varying > degrees) IntelliJ, Eclipse, and NetBeans - no Emacs/Slime/VIM > required. I use Clojure and Scala in IntelliJ, and I've done so in > Eclipse as well. > >> 2. No Smalltalk I've used has a decent GUI. Squeak is an >> abomination, down the road Pharo may be good, but not today and VW >> looks like it hasn't been updated since the NT days. Although >> everyone hates Java cross-platform desktop apps, it is interesting >> to compare a VW app (say Bottom Feeder) to a Java app of similar >> design (http://www.rssowl.org/overview) In my opinion the Java >> version fits in a lot better than the VW version (particularly on >> the Mac). > > For VW, my LinkuisticsUI bundle in the public Store improves the > situation somewhat on OSX for VW 7.6. Cincom are also making > improvements to the OSX UI for 7.7. > > Closure and Scala have Swing integration. Scala has very good SWT > bindings. All three IDEs have GUI builders. > > Maybe you should consider a Web UI - checkout tools such as Capuccino > and efforts like bespin. > > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > A reasonable man adapts himself to suit his environment. An > unreasonable man persists in attempting to adapt his environment to > suit himself. Therefore, all progress depends on the unreasonable man. > -- George Bernard Shaw > > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >

March 18, 2009

Re: [Pharo-project] Condense Changes error

by StÃ©phane Ducasse

can you try with the latest image since the condenseChanges got fixed. Stef On Mar 17, 2009, at 10:00 PM, John Toohey wrote: > The name of my image file is Pharo0.1Core-10225.image. Smalltalk > version gives me 'Pharo0.1' > > > > On Tue, Mar 17, 2009 at 16:47, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi john >> >> can you tell us your image update exactly since the latest I'm aware >> of is 10252. >> >> Thanks >> >> On Mar 17, 2009, at 9:07 PM, John Toohey wrote: >> >>> When I run condenseChange on my Phao image (10255), it stops after >>> about 95% with a 'syntax error' message. Closing the message does >>> nothing and the process seems stopped. If I delete the changes file, >>> the image is okay, but the parameter names of all my methods has >>> been >>> changes to t1, eg, renderContentOn: html becomes renderContentOn: t1 >>> etc. >>> >>> I can't make any more changes, and need to know how to repair the >>> changes file, or just get rid of it without it changes my source >>> code. >>> -- >>> -JT >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > -JT > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 18, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by John M McIntosh

If you are using the core audio unix drivers on os-x powerpc. Then you should look at the mac os carbon sqUnixSoundMacOSX.c there are a number of fixes, at least four come to mind, one being getting the endien correct for powerpc. On 17-Mar-09, at 2:35 PM, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > Bruce O'Neel writes: >> Hi, >> >> Thanks, I've finally gotten back to this and tested it. >> >> It works fine except for sound, which is broken in the same way >> that the 3-10.4 ones are broken (on at least ppc). They sound >> very bad. >> >> Does sound work on x86? If true, then it's probably a byte >> swapping problem and I can track that down. If no, then >> I have no idea. >> >> I did spend some time on it and wasn't successful. The >> 3.7-7 vm worked fine for sound. > > I haven't tested sound in a few years, it's not something I > use. Last time I did test it, I needed to make sure my kernel > had the right sound interface installed. > > Bryce > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 17, 2009