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

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

by Philippe Marschall

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? Cheers Philippe

Jan. 29, 2012

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

by Dale Henrichs

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

[Pharo-project] MCWorkingCopy>>#uniqueVersionName

by Sven Van Caekenberghe

Today I pressed Command-. while looking at a slow Monticello save, I was wondering what the system was doing before I even had written my commit message. Apparently, MCWorkingCopy>>#uniqueVersionName checks every repository linked to the package, (6 for Zn in my case), to see if the proposed version name is unique across all these repositories, not using the cache. I understand this, but this comes down to 6 times getting the list of all package names from remote servers. One way to speed this up would be to parallelize these. But fundamentally, I thought Monticello was supposed to be a distributed version control system ? Would it not be possible to assign the version name based on local, best effort knowledge alone and deal with possible conflicts afterwards (there is the ancestory) ? Just thinking out loud. Sven

Jan. 29, 2012

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

by Esteban Lorenzano

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] [squeak-dev] Smalltalk for small projects only?

by laurent laffont

Stef efforts are amazing. I started a course on Pharo this week. All students have their PBE. Very important. Laurent On Sun, Jan 29, 2012 at 7:09 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > +100 for your documentation efforts Stef! > > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: "The general-purpose Squeak developers list" < > squeak-dev(a)lists.squeakfoundation.org> > | Cc: "Pharo-project(a)lists.gforge.inria.fr Development" < > Pharo-project(a)lists.gforge.inria.fr> > | Sent: Sunday, January 29, 2012 12:25:56 AM > | Subject: Re: [squeak-dev] Smalltalk for small projects only? > | > | +1 > | Metacello is the way to go! > | Dale I will update the chapter as soon as you decide the new API :) > | I'm working on a nice process document for our little community. Stay > | tuned :) > | > | Stef > | > | > | > My opinion that being able to build images from scratch (easily and > | > reproducibly) is a "requirement" to get in the door for > | > mainstream projects... giving mainstream developers the > | > opportunity to work in a image-based environment will set them > | > free:) > | > | > | > >

Jan. 29, 2012

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

by StÃ©phane Ducasse

Yes took me 10 hours to install GTK and it crashed on meâ¦ So â¦ I do not see this discussion going anywhere. On Jan 29, 2012, at 7:16 PM, Sven Van Caekenberghe wrote: > > On 29 Jan 2012, at 18:48, Philippe Marschall wrote: > >> 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. >> >> And it's not like loading is any faster. Seaside takes 10 minutes to build from locally cached [1] packages, only 12 seconds go to running tests [2]. This makes C++ compilation times seem fast by comparison. >> >> [1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend >> [2] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testRe… > > I thought the thread and your remark were about the fact that it was functionally not possible to scale to larger teams. That is where is see no real difference. > > If you refer to scaleability purely on technical terms, speedwise, then yes we have room to improve ;-) > I worked with Pharo slices, I have built images containing Seaside. > Building bigger well known open source software from scratch usually takes quite some time too. > > We, as a community have to improve our tools, it will be a lot of work but work _is_ being done right now, think of the compiler, loader, networking, file access, package management. > > This very small hack already makes a difference: http://code.google.com/p/pharo/issues/detail?id=5222 and we need many more. > > Sven

Jan. 29, 2012

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

by dimitris chloupis

>> 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 StÃ©phane Ducasse

>>> 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. > And it's not like loading is any faster. Seaside takes 10 minutes to build from locally cached [1] packages, only 12 seconds go to running tests [2]. This makes C++ compilation times seem fast by comparison. > > [1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/buildTimeTrend > [2] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastCompletedBuild/testRe… > > Cheers > Philippe Stef

Jan. 29, 2012

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

by Guido Stepken

Smalltalk rather has the structure of a human brain, neurons firing around, reacting to all sorts of events and data. Even for a psychologist it is impossible to say, what neuron did a wrong job, when the patient suffers from mental illness. That problem tries to address the Pharo team by giving the ball of ill neurons a clear hierarcy and new structure, so that responsbilities can be clearly addressed, parallel to the structure within the programmers and enterprise hierarchy. For too long time the crowd of "Alan Kay hackers" have been messing around in the code, fixing things here and there, destroying lots of things at the same time. Squeak is the perfect proof of Kay's incompetence as software project manager! (I think, he never intended to be one! :-) ) Thats, why Java was such successfull: Clear hierarchy in the code structure, clear assignable responsibilities, clear assignable costs. In Smalltalk - impossible. That's why it died out. Too many complications and administrative overhead besides the programming itself, not mentioned the costs for lawyers, expert witnesses and court, when trying to answer the question of guiltyness, case a customer had real damage by software bugs. Programmers reality is not the reality outside in the real world! I'm really very interested watching the great Squeak/Pharo "cleanup" and how these problems are addressed, if there is a solution existing!? And finally: LOC, effectiveness of a programming language, speed, has proofed to be a minor problem in reality! regards, Guido Stepken Am 29.01.2012 08:46 schrieb "dimitris chloupis" <thekilon(a)yahoo.co.uk>: > Very good point . The tools and the libraries sometimes can play more > important role than the language itself. However Java seems to constantly > loosing developers because if something is a mess for small project for big > projects becomes a big mess , just take a look how many gazillion scripting > languages Java has , way more than C/C++. > > I think Java is not that ideal for large project as people think. I will > go as far as saying that if it was not such a well marketed product would > be an abandoned product by now and not a dominating platform. Companies may > like , but coders certainly do not . Companies are attracted by good > marketing, but coders are not. > > Coders are attracted , pro coders that is, from what can bring food to > their table and pay their bills. And in that respect Java is phenomenal. If > I was a big company however Java would be the last thing I would use for > big project. As a matter of fact python has gained quite a momentum with > huge projects and it is afterall a smalltalk child. Why not smalltalk ? > > ------------------------------ > *From:* Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > *To:* Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis < > thekilon(a)yahoo.co.uk> > *Sent:* Saturday, 28 January 2012, 22:08 > *Subject:* Re: [Pharo-project] Smalltalk for small projects only? > > S, dimitris chloupis piÅ¡e: > > > 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 :) 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. > > > You know I dont find it mysterious at all that smalltalk is unpopular as > > it is. If I go to the python website I know in 4 second why I should use > > python, if I go to a Java site in 10 seconds I know what Java is good > > for, if I go to a C/c++ again in seconds it becomes clear what is the > > goal, even Assembly websites explain in a few lines what the language is > > all about. > > > With Squeak and Pharo on the other hand it took me literally hours to > > figure out what they are good for and by the time I did I was amazed how > > underhyped smalltalk is. For me at least is the most underhyped piece of > > software I have ever used. > > This is a valuable point to consider in the future. > > > > The issue with image here its easy to totally miss the whole point. An > > image is loading lighting fast , a java application is not, its also > > great way to organise object orientated code because it allows you to > > quickly navigate through it, loading files , is expensive and frankly > > quite archaic. The idea behind filesystem was created on the basic that > > computer could only load just a few kbs or even less because of limited > > memory. > > > > In the age we live , filesystems are unnecessary anyway. I am not saying > > that hardware storage is , just file systems, and I think smalltalk > > moves towards that direction. You dont really need files and extensions > > to separate data and code, OO can do the job just fine in that area. > > > > I cant comment on the specifics of the image I am new to smalltalk and > > still exploring the basics, but let me say that I would love to take the > > idea of image abit further maybe following the brilliant architecture of > > our brains which stores information not in packages but via association, > > I think this kind of workflow is alot closer to what OO tries to be. > > > > For me the image play a pivot role inside the OO of smalltalk, which > > unlike Java does not stop at class definition. Besides an oversize > > clumsy library , smalltalk has very little to be envious of Java. > > > > Regarding huge project I will boldly say that inside a system of > > gazillion files a single file can easily lost its identity, OO can plays > > a huge role here, it can create that association I was talking about > > earlier and it can make sure that the user and coder has immediate > > access to information that he want to focus on at that particular moment > > but also has a structure that is obvious and simple to navigate. > > > > About the limitation of an image , i think that is a matter of > > implementation , obviously smalltalk has not been used as extensively in > > large projects as Java. But then what stops us from implementing an > > image that can brake any barrier, even do direct streaming from disk > > when the memory is not enough or when we dont want to occupy its > entirety ? > > ------------------------------------------------------------------------ > > *From:* Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > > *To:* "Pharo-project(a)lists.gforge.inria.fr" > > <Pharo-project(a)lists.gforge.inria.fr>; Squeak > > <squeak-dev(a)lists.squeakfoundation.org>; 'VWNC' <vwnc(a)cs.uiuc.edu> > > *Sent:* Saturday, 28 January 2012, 17:46 > > *Subject:* [Pharo-project] Smalltalk for small projects only? > > > > Hi guys, > > > > Ralph Johnson in his InfoQ interview made an interesting observation: > > > > 2:55 minute: "Smalltalk made an fundamental error ... image ... you can > > build something with 4-5 people what 50 people can build in Java, but if > > you take 200 people in Java ... it is really designed for small systems > > ... " > > > > Are we because of the image really destined for relatively small > > projects and small systems (of Java 50 people project size)? > > > > Are we really not able to scale to bigger projects/systems because of > that? > > > > Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still... > > > > [1] http://www.infoq.com/interviews/johnson-armstrong-oop > > > > Best regards > > Janko > > > > > > -- > > Janko MivÅ¡ek > > Aida/Web > > Smalltalk Web Application Server > > http://www.aidaweb.si > > > > >

Jan. 29, 2012

[Pharo-project] [ANN] ConfigurationOfMongoTalk

by Esteban Lorenzano

Hi, I created a configuration of mongo talk who is able to load mongo in a Pharo 1. 3 or Pharo 1.4 image. Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMongoTalk'; load. (ConfigurationOfMongoTalk project version: #stable) load. this will install all you need (not much really), and if you have mongodb running in localhost you will be ready to execute tests. Cheers, Esteban

Jan. 29, 2012