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

[Pharo-project] loading Seaside 3.0.6.3 in Pharo 1.4

by Esteban Lorenzano

Hi, I loaded last version of seaside into a pharo 1.4 image. Everything looks working fine, but there a couple of fixes: 1) KomLogger>>#attachTranscript self detachTheTranscript. ^(self streams detect: [:ea | ea isTranscriptStream] ifNone: [nil]) ifNil: [self addStream: TranscriptStream new] "TranscriptStream" is not anymore on pharo and should be replaced with ThreadSafeTranscript 2) String>>#withBlanksTrimmed is deprecated, and now it should use #trimBoth how can I proceed to apply this fixes into seaside (without breaking other platforms)? cheers, Esteban

Jan. 29, 2012

Re: [Pharo-project] Smalltalk for small projects only?

by Guido Stepken

I often discuss with Frank Lesser about Smalltalk compiler internals. He has written a Smalltalk VM (GVM), that is written in Assembler and jits Smalltalk directly dynamically into Intel machine code, that is *faster* than C in normal cases, expecially when fine tuned, able to run VS, VA, Squeak, Dolphin, Lesser Smalltalk in their own namespace, and MP!!! Sounds strange, because of different implementations (bytecode, callbacks...). GC runs on a 2.nd processor, what means, no more interruptions, Real Time Availability!!! If you want, you can control all traffic signs of NY within one Intel machine. He proofes, that Smalltalk, expecially Pharo is far away from being at the end.... :-) (And yes, i try to convince him to take part in the "language shootout" and make his GVM MIT license) :-) regards, Guido Stepken Am 29.01.2012 20:51 schrieb "Philippe Marschall" <kustos(a)gmx.net>: > On 29.01.2012 19:39, StÃ©phane Ducasse wrote: > >> >> No, it does not. >>>>> >>>> >>>> Please elaborate: I really can't see the difference between doing a >>>> merge (either an easy one or a more diffucult one over multiple files, >>>> spread over a couple of days, with intervening changes by others) using >>>> either Monticello or Git. >>>> >>> >>> The scalability limits of Monticello are well understood. PackageInfo >>> doesn't scale, at all. You put too many classes in a package, and >>> snapshotting gets really slow. Don't believe me? Make a change in Morphic >>> which has only 200 classes and save it. >>> >> >> >> You confuse artifacts and models. >> > > No, because in the real world compared to the Smalltalk Theoretic Perfect > World it doesn't matter how things could scale, it matters how things do > scale. See [1] > > [1] http://c2.com/cgi/wiki?**SufficientlySmartCompiler<http://c2.com/cgi/wiki?SufficientlySmartCompiler> > > Cheers > Philippe > > >

Jan. 29, 2012

[Pharo-project] Command Line Interface using FFI

by Guillermo Polito

I've spent a few hours playing with Alien+FFI and I did want to have a Command line interface to play and use as a quick browser. Gofer it squeaksource: 'CLInterface'; package: 'ConfigurationOfCLInterface'; load. ConfigurationOfCLInterface load. To play with it write a script, for example startCLI.st, with the following: *CLInterface start* And then, from the command line CogVM -vm-display-null <image> startCLI.st What it does support? - executes smalltalk expressions - handles the errors and shows them into the stdout (so it does not explode :P) - stores variables as a workspace Since I used standard C functions (fgets and printf only) this should work on every platform from scratch (having a VM with FFI working, of course)... The problems I've ran so far: - blocking FFI blocks the vm. I've not tried yet to use threads through FFI (and I don't know if it works. Does it?). But It should be great to start a headless seaside server with a command line :/. Ok, it's a very simple thing, but it allows to execute a expression from a remote server via ssh without doing much :). Guille

Jan. 29, 2012

Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion

by Esteban Lorenzano

he... connection problems... yeah, I know a lot about them :) well... after a successful install, I *think* you should have gcc and gcc-4.2... last one is also a symlink who points to: /usr/bin/i686-apple-darwin11-gcc-4.2.1 who should be there... is that the case? El 29/01/2012, a las 4:51p.m., dimitris chloupis escribiÃ³: > there is no gcc in usr/bin at all. Afterall your first command removed the only one ;) > > I have reinstalled Xcode to be sure . My Xcode About box says its XCODE 4.2 build 4D199 > > no idea how to update cause I downloaded it via torrent, could not download from app store cause my connection is crapish and each time I disconnected it canceled my upload (no I could not resume, tried everything). So I had to install via torrent. > > > > From: Esteban Lorenzano <estebanlm(a)gmail.com> > To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> > Sent: Sunday, 29 January 2012, 20:49 > Subject: Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion > > There is a problem there... if you have XCode 4.2.1 (latest), you should have that one... xcode just changed the default, it did not remove the gcc, AFAIK. > > which versions of gcc do you have in /usr/bin? > > oh, btw... is ln -s, not just ln (my mistake, but both should work) > > (symlink macport gcc should work, but I'm fearing there is something wrong with xcode instalation, and that's probably the reason it didn't compiled the first time, so, let's be sure about that before try the port) > > El 29/01/2012, a las 3:40p.m., dimitris chloupis escribiÃ³: > >> >> >> sudo rm /usr/bin/gcc >> >> success ! >> >> >> sudo ln /usr/bin/gcc-4.2 gcc >> >> fail ! >> >> no such file >> >> there is a gcc symlink in developer/usr/bin that point to developer/usr/llvm-gcc-4.2/llvm-gcc-4.2 >> >> there is no gcc-4.2 in my Xcode folder or other folders except the gcc folder that I installed via macports following the previous tutorial that I have linked. Should I symlink macports gcc-4.2 ? >> >> Xcode is by default isntalled in the Developer folder >> >> I am open to suggestions and thanks for helping me. >> >> >> > > >

Jan. 29, 2012

Re: [Pharo-project] Smalltalk for small projects only?

by Philippe Marschall

On 29.01.2012 19:39, StÃ©phane Ducasse wrote: > >>>> No, it does not. >>> >>> Please elaborate: I really can't see the difference between doing a merge (either an easy one or a more diffucult one over multiple files, spread over a couple of days, with intervening changes by others) using either Monticello or Git. >> >> The scalability limits of Monticello are well understood. PackageInfo doesn't scale, at all. You put too many classes in a package, and snapshotting gets really slow. Don't believe me? Make a change in Morphic which has only 200 classes and save it. > > > You confuse artifacts and models. > Give me 1 engineer full time and we fix that. Linus wrote git in two weeks. We would stop all work on the kernel until we had an SCM that satisfied all this requirements including being fast and scalable. Isn't Smalltalk supposed to make you super productive? Cheers Philippe

Jan. 29, 2012

Re: [Pharo-project] [Smalltalk for small projects only?

by Steve Wart

On Sun, Jan 29, 2012 at 11:39 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 29.01.2012 17:29, Steve Wart wrote: > >> Big legacy projects are still using Envy for VisualWorks less for the >> reasons listed below, but mostly because it's extremely difficult to >> migrate to Store without doing a "big bang" and most of these projects >> don't have 200+ developers anymore anyhow (disclaimer: I'm only familiar >> with 2 or 3 of these "success stories"). Many of the big Smalltalk >> projects were mostly done using Envy, and it's a powerful tool, in spite >> of its limitations. If there was a reliable way to move the latest >> changes from a set of Envy configuration maps into Store, it would make >> it much easier to get away from ancient, buggy and unsupported SCMs >> (like Envy/GemKit). >> > > So in something like ten (10) years they haven't managed to migrate await > form said SCMs OOCL and JP Morgan are still using Envy (although I've heard that JPM has purchased a license from IBM and maintains an in-house fork with the latest version of VW). I believe UBS has migrated to Store, but their team is very small and tight-knit. It's been very hard for big distributed shops to migrate SCM from Envy to Store. I think that Cincom has provided consulting support for that but I don't think they've provided any stats on the cost or effort to migrate a typical project. VA shops continue to use Envy as a supported and effective SCM but I haven't used VA commercially, but I'm assuming it works for them. It's not surprising that this old stuff doesn't get migrated given how IT projects are funded in general. When you've got hundreds of Java servers spewing errors all day, it's hard to get excited about some old Smalltalk stuff that just keeps the business chugging along. Cheers, Steve

Jan. 29, 2012

Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion

by dimitris chloupis

there is no gcc in usr/bin at all. Afterall your first command removed the only one ;) I have reinstalled Xcode Â to be sure . My Xcode About box says its XCODE 4.2 build 4D199 no idea how to update cause I downloaded it via torrent, could not download from app store cause my connection is crapish and each time IÂ disconnectedÂ it canceled my upload (no I could not resume, tried everything). So I had to install via torrent.Â ________________________________ From: Esteban Lorenzano <estebanlm(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> Sent: Sunday, 29 January 2012, 20:49 Subject: Re: [Pharo-project] Trying to build CogVM in MacOSX 10.7 Lion There is a problem there... if you have XCode 4.2.1 (latest), you should have that one... xcode just changed the default, it did not remove the gcc, AFAIK. which versions of gcc do you have in /usr/bin? oh, btw... is ln -s, not just ln (my mistake, but both should work) (symlink macport gcc should work, but I'm fearing there is something wrong with xcode instalation, and that's probably the reason it didn't compiled the first time, so, let's be sure about that before try the port) El 29/01/2012, a las 3:40p.m., dimitris chloupis escribiÃ³: > >>> sudo rm /usr/bin/gcc > > >success ! > > >>> sudo ln /usr/bin/gcc-4.2 gcc > >fail ! > > >no such file > > >there is a gcc symlink in developer/usr/bin that point to developer/usr/llvm-gcc-4.2/llvm-gcc-4.2 > > >there is no gcc-4.2 in my Xcode folder or other folders except the gcc folder that I installed via macports following the previous tutorial that I have linked. Should I symlink macports gcc-4.2 ? > > >Xcode is by default isntalled in the Developer folder > > >I am open to suggestions and thanks for helping me. Â > > >Â Â > > >

Jan. 29, 2012

Re: [Pharo-project] Smalltalk for small projects only?

by Philippe Marschall

On 29.01.2012 19:39, StÃ©phane Ducasse wrote: > >>>> No, it does not. >>> >>> Please elaborate: I really can't see the difference between doing a merge (either an easy one or a more diffucult one over multiple files, spread over a couple of days, with intervening changes by others) using either Monticello or Git. >> >> The scalability limits of Monticello are well understood. PackageInfo doesn't scale, at all. You put too many classes in a package, and snapshotting gets really slow. Don't believe me? Make a change in Morphic which has only 200 classes and save it. > > > You confuse artifacts and models. No, because in the real world compared to the Smalltalk Theoretic Perfect World it doesn't matter how things could scale, it matters how things do scale. See [1] [1] http://c2.com/cgi/wiki?SufficientlySmartCompiler Cheers Philippe

Jan. 29, 2012

Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?

by Steve Wart

Hi Dale First let me apologize for using such a horrible IT euphemism. I have been hanging around software politicians for far too long. I think you deserve all the credit for coming up with an elegant and effective configuration management system that has brought many parts of the Smalltalk community together to build common, useful and practical tools. Regarding your race suggestion, I think you are right that having more choices will be good for the community. I can't claim that I don't have resources available - I can come up with a few hours a week to work on this. I'll start with the links Frank posted, but I think the two approaches in the end may share some common features. I've been thinking about this idea for a long time but without feedback I haven't had the courage to start. Maybe I can finally help. Cheers, Steve On Sun, Jan 29, 2012 at 11:13 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Steve, > > I have two comments: > > 1. "inventing the future" doesn't happen by considering > how "ambitious" it may seem. In the end it is probably > easier than you think and harder than I think. If it was > real easy, I'd have been done by now:) > > 2. I propose a race: > > You start working on your git backend for Smalltalk and > I'll continue working on Metacello, first one to "git work > flow" wins ... But then the real winners will be the Smalltalk > Community... > > I have said this before: "I can hardly wait until someone > invents the replacement for Metacello---it will give me > more time for other projects:)" > > Dale > > ----- Original Message ----- > | From: "Steve Wart" <steve(a)wart.ca> > | > | The idea of building the git workflow on top of metacello strikes me > | as being somewhat ambitious. > >

Jan. 29, 2012

Re: [Pharo-project] Smalltalk for small projects only?

by Michael Haupt

Hi Dimitris, the Greek Google link does not work for me for some reason; maybe the shootout server is down ... in any case I strongly doubt that the shootout benchmarks (if that's where the link was supposed to point to) say anything about productivity. The other link is not what I was expecting, sorry. For one, the blog entry does not really say anything about productivity. It is all about LOC, which is a poor metric for productivity. The blog post certainly does not "prove that by replacing java with python you can scale down developing time by 2-3x times", to quote you. Having to write, say, 50 % of the LOC in no way means you need half the time. Staying tuned for more, Michael Am 29.01.2012 um 18:06 schrieb dimitris chloupis <thekilon(a)yahoo.co.uk>: > ok I think I found something you may like > > this > > http://codemonkeyism.com/comparing-java-and-python-is-java-10x-more-verbose… > > From: dimitris chloupis <thekilon(a)yahoo.co.uk> > To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, 29 January 2012, 18:58 > Subject: Re: [Pharo-project] Smalltalk for small projects only? > > sorry could not find it , nor I remember the name, I have seen one or two . But in any case I think the comparison is obvious. If you visit the language game , the code required by python is usually 2x 3x times less for the same thing. > > http://www.google.gr/url?sa=t&rct=j&q=language%20game&source=web&cd=1&ved=0… > > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, 29 January 2012, 16:12 > Subject: Re: [Pharo-project] Smalltalk for small projects only? > > Reference, please :) I fully believe it. > > Bill > > > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Michael Haupt [mhaupt(a)gmail.com] > Sent: Sunday, January 29, 2012 7:44 AM > To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis > Subject: Re: [Pharo-project] Smalltalk for small projects only? > > Dimitris, > > this is very interesting; I've always wanted to read that kind of study. Do you have a pointer? > > Thanks, > > Michael > > Am 29.01.2012 um 08:51 schrieb dimitris chloupis <thekilon(a)yahoo.co.uk>: > >> Maybe not for smalltalk but for python there is a number of surveys that prove that by replacing java with python you can scale down developing time by 2-3x times. By "prove" I mean projects that have actually done that. Not quite a 10x but I think its impressive non the less and I think the numbers wont be very dissimilar for smalltalk >> >> From: Michael Haupt <mhaupt(a)gmail.com> >> To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, 28 January 2012, 23:29 >> Subject: Re: [Pharo-project] Smalltalk for small projects only? >> >> Janko, >> >> Am 28.01.2012 um 21:08 schrieb Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: >> >> I think this is a post that clearly illustrates the big problem with >> >> smalltalk. The very fact that is compared with Java and Java survives. >> > >> > Yes, that 4-5 peole can do what 50 Java people are needed is both a >> > blessing and a curse :) >> >> I wanted to ask this earlier: is there actual evidence for this, or is it just boasting? >> >> > Blessing because of productivity, curse because >> > we are not able to scale beyond one highly connected development group. >> > We don't have project management practices and tools, while Java guys >> > have because they need them from the start. >> >> I'm not so sure the people at those Smalltalk firms building software for banks et al. have no project management. Boasting? ;-) >> >> Best, >> >> Michael >> >> > > > >

Jan. 29, 2012