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

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

by Igor Stasenko

> > I don't know. But how do you know from his stackstrace that the problem is > that ? > > i dont. :) i replied after seeing an Esteban's message saying that your post is outdated and one should use 3.9 config version. and couple days before we had someone who asking why NB-enabled VM fails to build for him, when he still using this magic ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.5') load. while when i was released an CMakeVMMaker configs for NB , it was already far beyond that version, and of course won't work with 1.5. -- Best regards, Igor Stasenko.

Jan. 28, 2012

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

by Schwab,Wilhelm K

200 5+year smalltalkers - that's an army capable of almost anything... ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenrich(a)vmware.com] Sent: Saturday, January 28, 2012 1:07 PM To: The general-purpose Squeak developers list Cc: VWNC; Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Smalltalk for small projects only? Janko, I think the limitation for Smalltalk lies in source code management tools/styles ... With a file-based language 200 engineers can contribute to the project ... each engineer can checkout a version of the system work in isolation then commit his or her work to the shared repository resolve conflicts and move on .... other engineers can easily integrate the work and so on ... the source code management tools scale ... In the mid nineties at ParcPlace systems the image was passed around from engineer to engineer so that he or she could integrate their work into the production image... this doesn't scale... There have been proprietary source code management tools that have been created over the years. You can bet that the large companies that are invested in Smalltalk are using systems that are based on these proprietary systems, but you can also bet that they've had to customize those systems for their needs... The file-based SCM systems work out of the box and don't care what language or even development process that is being used ... they are managing files ... There is no standard SCM for Smalltalk and none of the file-based SCMs really fit Smalltalk. When we are arguing about whether git or mercurial is better on the Pharo list, I will retract that statement:). Without a standard SCM, the first thing that a 200 person engineering groups needs to do to start using Smalltalk is figure out (for themselves) how to share their work and keep 200 individual images in synch ... I'm not necessarily convinced that anyone has really solved this one. Personally I believe that the problem is surmountable, but for whatever reason the Smalltalk community hasn't focussed on seriously addressing the SCM issue .... in the last 30 years or so:) Being able to repeatably build images based on a minimal core image is certainly headed in the right direction, but we still have a ways to go on the tools front ... Dale ----- Original Message ----- | From: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> | To: Pharo-project(a)lists.gforge.inria.fr, "Squeak" <squeak-dev(a)lists.squeakfoundation.org>, "VWNC" <vwnc(a)cs.uiuc.edu> | Sent: Saturday, January 28, 2012 7:46:32 AM | Subject: [squeak-dev] 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. 28, 2012

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

by Dale Henrichs

Sven, Keep in mind that I'm talking about making it possible for teams of 200 to use Smalltalk (or 20 teams of 10, or 20 teams of 4) ... How many Smalltalk developers rebuild their image from scratch multiple times per hour (day/month/year) during a development cycle ... If Smalltalk developers had to build their images over and over again on a daily basis, we would have had good tools for building images a long time ago:) Because Smalltalk is am image it isn't necessary to build from scratch very often, but because we as a group haven't focussed on making it easy it is unnecessarily hard ... and building from scratch is a prerequisite to being used in large projects ... As I said, I don't think the problem is insurmountable...and I do think we are getting better. It's just that if tomorrow a team of 200 walked up to my door and said they wanted my help in setting up their Smalltalk development environment, I'd gulp and say "give me a couple of months (at least)"... Dale ----- Original Message ----- | From: "Sven Van Caekenberghe" <sven(a)beta9.be> | To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org> | Cc: "VWNC" <vwnc(a)cs.uiuc.edu>, Pharo-project(a)lists.gforge.inria.fr | Sent: Saturday, January 28, 2012 11:08:08 AM | Subject: Re: [squeak-dev] Smalltalk for small projects only? | | Dale, | | On 28 Jan 2012, at 19:07, Dale Henrichs wrote: | | > Janko, | > | > I think the limitation for Smalltalk lies in source code management | > tools/styles ... | > | > With a file-based language 200 engineers can contribute to the | > project ... each engineer can checkout a version of the system | > work in isolation then commit his or her work to the shared | > repository resolve conflicts and move on .... other engineers can | > easily integrate the work and so on ... the source code management | > tools scale ... | > | > In the mid nineties at ParcPlace systems the image was passed | > around from engineer to engineer so that he or she could integrate | > their work into the production image... this doesn't scale... | > | > There have been proprietary source code management tools that have | > been created over the years. You can bet that the large companies | > that are invested in Smalltalk are using systems that are based on | > these proprietary systems, but you can also bet that they've had | > to customize those systems for their needs... | > | > The file-based SCM systems work out of the box and don't care what | > language or even development process that is being used ... they | > are managing files ... | > | > There is no standard SCM for Smalltalk and none of the file-based | > SCMs really fit Smalltalk. When we are arguing about whether git | > or mercurial is better on the Pharo list, I will retract that | > statement:). | > | > Without a standard SCM, the first thing that a 200 person | > engineering groups needs to do to start using Smalltalk is figure | > out (for themselves) how to share their work and keep 200 | > individual images in synch ... I'm not necessarily convinced that | > anyone has really solved this one. | > | > Personally I believe that the problem is surmountable, but for | > whatever reason the Smalltalk community hasn't focussed on | > seriously addressing the SCM issue .... in the last 30 years or | > so:) | > | > Being able to repeatably build images based on a minimal core image | > is certainly headed in the right direction, but we still have a | > ways to go on the tools front ... | > | > Dale | | I want to respectfully disagree (and I even don't understand some of | your remarks, or the underlying implications, given your excellent | work on Metacello and some much other contributions to Smalltalk). | | Yes, the very old way of passing images around was arcane and did not | scale (I did this too in the 80'ies early 90'ies). | | But today, with Monticello and Metacello things are quite different, | not perfect but totally acceptable. | | When building Smalltalk applications I am using code written by | hundreds of people during tens of years, this works out very well. | | In traditional file bases language like Java or C using a traditional | SCM, you will immediately hit problems when even a couple of people | work on parts of code that are closely related. Merging, branching, | solving conflicts there is no different than with Monticello, IMHO. | | Organizing big teams is plain hard, in any language. Clear | separations/responsabilities/interfaces are the only answer. | | Sven | | | |

Jan. 28, 2012

Re: [Pharo-project] browsers vs. guis

by Igor Stasenko

Nice post. Still, we want a data-flow browser + being able to control/customize UIs :) Sure, this is veeeery hard to achieve. But i understand that focusing at single problem and providing good solution for it is better than having no focus and trying to deal with everything at once and finally fail... On 28 January 2012 22:43, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Working with Glamour requires a slightly different mindset than when working with a generic user interface framework. Because this seems to generate confusion, I wrote down a small post that explains the differences. > > http://www.humane-assessment.com/blog/browsers-vs-guis > > Still issues? Just shoot, and I will try my best to answer them. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Live like you mean it." > > -- Best regards, Igor Stasenko.

Jan. 28, 2012

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

by Mariano Martinez Peck

On Sat, Jan 28, 2012 at 11:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 28 January 2012 23:22, Mariano Martinez Peck <marianopeck(a)gmail.com>wrote: > >> >> >> On Sat, Jan 28, 2012 at 10:37 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> On 28 January 2012 22:11, Mariano Martinez Peck <marianopeck(a)gmail.com> >>> wrote: >>> > >>> > >>> > On Sat, Jan 28, 2012 at 10:04 PM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> >> >>> >> On 28 January 2012 22:03, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >> > On 28 January 2012 19:00, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >> >> hi, >>> >> >> >>> >> >> you need to install xcode, not just gcc from macports (you'll need >>> the >>> >> >> libraries). Also, notice that Mariano's blog was outdated (I know >>> he >>> >> >> was >>> >> >> working to update it this days, but I don't know if it is ready >>> yet)... >>> >> >> you >>> >> >> better use ConfigurationOfCog version 3.9, not the one in the blog >>> :) >>> >> >> >>> >> > >>> >> > Again same thing. >>> >> > Mariano, can you please change that entry in your blog by mentioning >>> >> > that they should _not_ >>> >> > use a strange combinations of latest + updated stuff? >>> >> > >>> >> i meant latest + outdated :) >>> >> >>> > >>> > I think my blog is pretty clear regarding which version to use of each >>> part. >>> > In such a post I do not tell people to try latest of nothing. Each >>> part has >>> > fixed versions in order to be reproducible. If you want latest...then >>> fight >>> > again the world, but my post do not support that ;) >>> > >>> > >>> >> >>> >> > If you checking out from git, you should _always_ use the config >>> which >>> >> > is in LoadVMMaker.st >>> >> > because if you don't then you will have all those funny errors. >>> >> > >>> > >>> > >>> > Well, I document that in the second part of the post: >>> > >>> http://marianopeck.wordpress.com/2011/04/16/building-the-vm-second-part/ >>> > where in that case I explain how to do it without the specific >>> versions I >>> > say in the previous part. >>> > >>> > So it is simple... part 1 you use the exact versions I tell you and it >>> > should work. Part 2 is for trying to start the process from scracth if >>> I >>> > don't tell you which versions, that is, using all latest code. >>> > >>> >>> The problem is that people checking out latest sources from git, >>> and then trying to build VM with outdated VMMaker config: >>> >>> 1 Deprecation raiseWarning: false. >>> 2 Gofer new >>> 3 squeaksource:'MetacelloRepository'; >>> 4 package:'ConfigurationOfVMMaker'; >>> 5 load. >>> 6 ((Smalltalk at: #ConfigurationOfVMMaker) project version: >>> '1.5') load. >>> >>> you then should mention that if they want to build VM for that confing >>> they should do >>> >>> >> The post already includes that: >> >> " >> git clone git://gitorious.org/~marianopeck/cogvm/marianopecks-blessed.git >> >> For this post, I recommend to take the first option if you may be a >> beginner. I told you that I wanted my posts to be reproducible. With the >> previous commands, you will clone the latest version in the repository. >> Since I donât know when you are going to do it (if there is someone), I >> would like that you load the specific version I know it works. What I am >> suggesting is doing a kind of âsvn co http://xxxx -r 2202â³. I checked >> how to do this in git, and it seems not to provide a clone of a specific >> version. Instead, you just clone (from the latest one) and then you >> checkout or revert to a previous one. Execute: >> 1cd blessed >> 2git checkout f3fe94c828f66cd0e7c37cfa3434e384ff65915e >> " >> > I don't know. But how do you know from his stackstrace that the problem is that ? > > > so, why people keep doing it wrong? :) > > > -- > Best regards, > Igor Stasenko. > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Best regards, > Igor Stasenko. > -- Mariano http://marianopeck.wordpress.com

Jan. 28, 2012

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

by Igor Stasenko

On 28 January 2012 23:22, Mariano Martinez Peck <marianopeck(a)gmail.com>wrote: > > > On Sat, Jan 28, 2012 at 10:37 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: > >> On 28 January 2012 22:11, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > >> > >> > On Sat, Jan 28, 2012 at 10:04 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >> >> >> On 28 January 2012 22:03, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > On 28 January 2012 19:00, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> >> hi, >> >> >> >> >> >> you need to install xcode, not just gcc from macports (you'll need >> the >> >> >> libraries). Also, notice that Mariano's blog was outdated (I know he >> >> >> was >> >> >> working to update it this days, but I don't know if it is ready >> yet)... >> >> >> you >> >> >> better use ConfigurationOfCog version 3.9, not the one in the blog >> :) >> >> >> >> >> > >> >> > Again same thing. >> >> > Mariano, can you please change that entry in your blog by mentioning >> >> > that they should _not_ >> >> > use a strange combinations of latest + updated stuff? >> >> > >> >> i meant latest + outdated :) >> >> >> > >> > I think my blog is pretty clear regarding which version to use of each >> part. >> > In such a post I do not tell people to try latest of nothing. Each part >> has >> > fixed versions in order to be reproducible. If you want latest...then >> fight >> > again the world, but my post do not support that ;) >> > >> > >> >> >> >> > If you checking out from git, you should _always_ use the config >> which >> >> > is in LoadVMMaker.st >> >> > because if you don't then you will have all those funny errors. >> >> > >> > >> > >> > Well, I document that in the second part of the post: >> > >> http://marianopeck.wordpress.com/2011/04/16/building-the-vm-second-part/ >> > where in that case I explain how to do it without the specific versions >> I >> > say in the previous part. >> > >> > So it is simple... part 1 you use the exact versions I tell you and it >> > should work. Part 2 is for trying to start the process from scracth if I >> > don't tell you which versions, that is, using all latest code. >> > >> >> The problem is that people checking out latest sources from git, >> and then trying to build VM with outdated VMMaker config: >> >> 1 Deprecation raiseWarning: false. >> 2 Gofer new >> 3 squeaksource:'MetacelloRepository'; >> 4 package:'ConfigurationOfVMMaker'; >> 5 load. >> 6 ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.5') >> load. >> >> you then should mention that if they want to build VM for that confing >> they should do >> >> > The post already includes that: > > " > git clone git://gitorious.org/~marianopeck/cogvm/marianopecks-blessed.git > > For this post, I recommend to take the first option if you may be a > beginner. I told you that I wanted my posts to be reproducible. With the > previous commands, you will clone the latest version in the repository. > Since I donât know when you are going to do it (if there is someone), I > would like that you load the specific version I know it works. What I am > suggesting is doing a kind of âsvn co http://xxxx -r 2202â³. I checked how > to do this in git, and it seems not to provide a clone of a specific > version. Instead, you just clone (from the latest one) and then you > checkout or revert to a previous one. Execute: > 1cd blessed > 2git checkout f3fe94c828f66cd0e7c37cfa3434e384ff65915e > " > so, why people keep doing it wrong? :) -- Best regards, Igor Stasenko. -- Mariano http://marianopeck.wordpress.com -- Best regards, Igor Stasenko.

Jan. 28, 2012

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

by Janko MivÅ¡ek

Hi Michael, S, Michael Haupt 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 people 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? I think we need to ask Ralph to clarify that. But IMHO his main point is scaling from 50 to 200 ... >> 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? ;-) As I said in first post, there are few exceptions. But they all have their dev. process developed internally, while there are no common agreed and used development processes in Smalltalk as there are in enterprise Java development. Even more funny is that many (like Agile/Extreme programming) actually comes from that Smalltalk project "exceptions"... Best regards Janko

Jan. 28, 2012

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

by Dale Henrichs

Frank, No I meant what I said .... I'm not talking in a literal sense, but a functional sense .... With Metacello I can 'clone' version 3.0.6 of Seaside30, i.e., make a local copy of all of mcz files that make up version 3.0.6 in local directory. If I load the files into an image I can edit the files including add new files, etc. and then 'commit' version 3.0.7 to my local directory, which includes new versions of files and a new version of the configuration. I can 'push' my local files (mcz and config) to the common repository and even 'pull', but when it comes to 'merge' it all falls apart, because 'merge' is not supported at the Metacello level. Monticello does a great job with merging and Metacello needs to step up to the plate on merge:) Totally agree with you about builds...if customization is required, then each person around the world that does "a build" is not guaranteed to et exactly the same results... Dale ----- Original Message ----- | From: "Frank Shearar" <frank.shearar(a)gmail.com> | To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org> | Cc: "VWNC" <vwnc(a)cs.uiuc.edu>, "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si>, Pharo-project(a)lists.gforge.inria.fr | Sent: Saturday, January 28, 2012 1:45:04 PM | Subject: Re: [squeak-dev] Re: [Smalltalk for small projects only? | | 2012/1/28 Dale Henrichs <dhenrich(a)vmware.com>: | > Janko, | > | > Metacello itself needs work to make it usable by groups of | > developers ... the lack of merge capability is a real hindrance to | > being able to have multiple folks work on the same project and use | > Metacello ... | > | > I imagine that a Metacello configuration is the moral equivalent of | > a git repository. It should be possible to find "moral | > equivalents" of the various git operations: clone, push, pull, | > branch, checkout, merge, commit. It is something that I will be | > looking into in the not too distant future, since I want to | > improve the usability of Metacello for groups of developers. | | Um, do you mean Metacello or Monticello? Metacello seems like the | maven of Java world: "Here's what this artifact contains, its | dependencies, where you can find them, etc. etc." | | > I agree that integrated tools is another area that needs | > attention.... when it is time to commit your work there are just | > too many different windows and browsers that you have to monkey | > with to save your work ... | > | > Another area that shouldn't be neglected is the notion of basing | > things on a minimal core image and automated builds for | > individuals ... We've got folks doing good things with Jenkins but | > I sense that with each installation there are things that still | > need to be customized in the build process itself. It should be | > dead simple, like compiling a c file when you know the path to an | > image... | | A build should be a single command, with no customisation required at | all. This is especially important in large projects. Being able to | customise/parameterise a build means having an artifact but not | knowing what went into building it. | | Otherwise, I agree. Luckily, more and more folks are starting to use | Metacello, and building images up from some small base. | | frank | | > I think we may focus too much on the in-image tools and not enough | > on the external tools that are just as important. | > | > We need to make it easy for a developer (in a team of developers) | > to check out a version of a minimal1 image, do a reproducible | > build of the correct version of the project, then fire up the | > image and do his or her development thang, | > commit/push/pull/merge/bang and then the next developer does | > Â pull/merge/build/boom to pick up the changes for her image and so | > on ... This involves more than just in-image tooling. | > | > Dale | > | > ----- Original Message ----- | > | From: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Cc: "Dale Henrichs" <dhenrich(a)vmware.com>, "The general-purpose | > | Squeak developers list" | > | <squeak-dev(a)lists.squeakfoundation.org>, "VWNC" | > | <vwnc(a)cs.uiuc.edu> | > | Sent: Saturday, January 28, 2012 12:16:55 PM | > | Subject: Re: [Smalltalk for small projects only? | > | | > | Dale, | > | | > | I agree with you that source code management is where we are | > | weak. A | > | process therefore, as James already said. | > | | > | In SCM Â VisualWorks is ahead in my opinion, even that Store is | > | also | > | not | > | perfect yet. But it would be useful to reuse some of ideas in | > | Monticello | > | based SCM tools too. With Metacello we got a good packaging tool, | > | so, | > | where to go to be even better? I think SCM tool integration into | > | code | > | browser can be next and relatively easy step. As Store is | > | integrated | > | into VW code browser. | > | | > | Janko | > | | > | S, Dale Henrichs piÅ¡e: | > | > Janko, | > | > | > | > I think the limitation for Smalltalk lies in source code | > | > management | > | > tools/styles ... | > | > | > | > With a file-based language 200 engineers can contribute to the | > | > project ... Â each engineer can checkout a version of the system | > | > work in isolation then commit his or her work to the shared | > | > repository resolve conflicts and move on .... other engineers | > | > can | > | > easily integrate the work and so on ... the source code | > | > management | > | > tools scale ... | > | > | > | > In the mid nineties at ParcPlace systems the image was passed | > | > around from engineer to engineer so that he or she could | > | > integrate | > | > their work into the production image... this doesn't scale... | > | > | > | > There have been proprietary source code management tools that | > | > have | > | > been created over the years. You can bet that the large | > | > companies | > | > that are invested in Smalltalk are using systems that are based | > | > on | > | > these proprietary systems, but you can also bet that they've | > | > had | > | > to customize those systems for their needs... | > | > | > | > The file-based SCM systems work out of the box and don't care | > | > what | > | > language or even development process that is being used ... | > | > they | > | > are managing files ... | > | > | > | > There is no standard SCM for Smalltalk and none of the | > | > file-based | > | > SCMs really fit Smalltalk. When we are arguing about whether | > | > git | > | > or mercurial is better on the Pharo list, I will retract that | > | > statement:). | > | > | > | > Without a standard SCM, the first thing that a 200 person | > | > engineering groups needs to do to start using Smalltalk is | > | > figure | > | > out (for themselves) how to share their work and keep 200 | > | > individual images in synch ... I'm not necessarily convinced | > | > that | > | > anyone has really solved this one. | > | > | > | > Personally I believe that the problem is surmountable, but for | > | > whatever reason the Smalltalk community hasn't focussed on | > | > seriously addressing the SCM issue .... in the last 30 years or | > | > so:) | > | > | > | > Being able to repeatably build images based on a minimal core | > | > image | > | > is certainly headed in the right direction, but we still have a | > | > ways to go on the tools front ... | > | > | > | > Dale | > | > | > | > | > | > | > | > ----- Original Message ----- | > | > | From: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> | > | > | To: Pharo-project(a)lists.gforge.inria.fr, "Squeak" | > | > | <squeak-dev(a)lists.squeakfoundation.org>, "VWNC" | > | > | <vwnc(a)cs.uiuc.edu> | > | > | Sent: Saturday, January 28, 2012 7:46:32 AM | > | > | Subject: [squeak-dev] 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 | > | > | | > | > | | > | > | > | > | > | | > | -- | > | Janko MivÅ¡ek | > | Svetovalec za informatiko | > | Eranova d.o.o. | > | Ljubljana, Slovenija | > | www.eranova.si | > | tel: Â 01 514 22 55 | > | faks: 01 514 22 56 | > | gsm: 031 674 565 | > | | > | |

Jan. 28, 2012

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

by Mariano Martinez Peck

On Sat, Jan 28, 2012 at 10:37 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 28 January 2012 22:11, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > On Sat, Jan 28, 2012 at 10:04 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 28 January 2012 22:03, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > On 28 January 2012 19:00, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> hi, > >> >> > >> >> you need to install xcode, not just gcc from macports (you'll need > the > >> >> libraries). Also, notice that Mariano's blog was outdated (I know he > >> >> was > >> >> working to update it this days, but I don't know if it is ready > yet)... > >> >> you > >> >> better use ConfigurationOfCog version 3.9, not the one in the blog :) > >> >> > >> > > >> > Again same thing. > >> > Mariano, can you please change that entry in your blog by mentioning > >> > that they should _not_ > >> > use a strange combinations of latest + updated stuff? > >> > > >> i meant latest + outdated :) > >> > > > > I think my blog is pretty clear regarding which version to use of each > part. > > In such a post I do not tell people to try latest of nothing. Each part > has > > fixed versions in order to be reproducible. If you want latest...then > fight > > again the world, but my post do not support that ;) > > > > > >> > >> > If you checking out from git, you should _always_ use the config which > >> > is in LoadVMMaker.st > >> > because if you don't then you will have all those funny errors. > >> > > > > > > > Well, I document that in the second part of the post: > > http://marianopeck.wordpress.com/2011/04/16/building-the-vm-second-part/ > > where in that case I explain how to do it without the specific versions I > > say in the previous part. > > > > So it is simple... part 1 you use the exact versions I tell you and it > > should work. Part 2 is for trying to start the process from scracth if I > > don't tell you which versions, that is, using all latest code. > > > > The problem is that people checking out latest sources from git, > and then trying to build VM with outdated VMMaker config: > > 1 Deprecation raiseWarning: false. > 2 Gofer new > 3 squeaksource:'MetacelloRepository'; > 4 package:'ConfigurationOfVMMaker'; > 5 load. > 6 ((Smalltalk at: #ConfigurationOfVMMaker) project version: '1.5') > load. > > you then should mention that if they want to build VM for that confing > they should do > > The post already includes that: " git clone git://gitorious.org/~marianopeck/cogvm/marianopecks-blessed.git For this post, I recommend to take the first option if you may be a beginner. I told you that I wanted my posts to be reproducible. With the previous commands, you will clone the latest version in the repository. Since I donât know when you are going to do it (if there is someone), I would like that you load the specific version I know it works. What I am suggesting is doing a kind of âsvn co http://xxxx -r 2202â³. I checked how to do this in git, and it seems not to provide a clone of a specific version. Instead, you just clone (from the latest one) and then you checkout or revert to a previous one. Execute: 1cd blessed 2git checkout f3fe94c828f66cd0e7c37cfa3434e384ff65915e " > git checkout #the hash of commit for 1.5# > > i did not found 1.5.. in commit log but here is for 1.6: > > commit 688f6a0d35c479e845ab096fc3576483e6fee6c6 > Author: Igor Stasenko <siguctua(a)gmail.com> > Date: Mon Apr 11 14:36:39 2011 +0200 > > New configuration with ConfigurationOfCog 1.6 version > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Jan. 28, 2012

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

by Frank Shearar

2012/1/28 Dale Henrichs <dhenrich(a)vmware.com>: > Janko, > > Metacello itself needs work to make it usable by groups of developers ... the lack of merge capability is a real hindrance to being able to have multiple folks work on the same project and use Metacello ... > > I imagine that a Metacello configuration is the moral equivalent of a git repository. It should be possible to find "moral equivalents" of the various git operations: clone, push, pull, branch, checkout, merge, commit. It is something that I will be looking into in the not too distant future, since I want to improve the usability of Metacello for groups of developers. Um, do you mean Metacello or Monticello? Metacello seems like the maven of Java world: "Here's what this artifact contains, its dependencies, where you can find them, etc. etc." > I agree that integrated tools is another area that needs attention.... when it is time to commit your work there are just too many different windows and browsers that you have to monkey with to save your work ... > > Another area that shouldn't be neglected is the notion of basing things on a minimal core image and automated builds for individuals ... We've got folks doing good things with Jenkins but I sense that with each installation there are things that still need to be customized in the build process itself. It should be dead simple, like compiling a c file when you know the path to an image... A build should be a single command, with no customisation required at all. This is especially important in large projects. Being able to customise/parameterise a build means having an artifact but not knowing what went into building it. Otherwise, I agree. Luckily, more and more folks are starting to use Metacello, and building images up from some small base. frank > I think we may focus too much on the in-image tools and not enough on the external tools that are just as important. > > We need to make it easy for a developer (in a team of developers) to check out a version of a minimal1 image, do a reproducible build of the correct version of the project, then fire up the image and do his or her development thang, commit/push/pull/merge/bang and then the next developer does Â pull/merge/build/boom to pick up the changes for her image and so on ... This involves more than just in-image tooling. > > Dale > > ----- Original Message ----- > | From: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> > | To: Pharo-project(a)lists.gforge.inria.fr > | Cc: "Dale Henrichs" <dhenrich(a)vmware.com>, "The general-purpose Squeak developers list" > | <squeak-dev(a)lists.squeakfoundation.org>, "VWNC" <vwnc(a)cs.uiuc.edu> > | Sent: Saturday, January 28, 2012 12:16:55 PM > | Subject: Re: [Smalltalk for small projects only? > | > | Dale, > | > | I agree with you that source code management is where we are weak. A > | process therefore, as James already said. > | > | In SCM Â VisualWorks is ahead in my opinion, even that Store is also > | not > | perfect yet. But it would be useful to reuse some of ideas in > | Monticello > | based SCM tools too. With Metacello we got a good packaging tool, so, > | where to go to be even better? I think SCM tool integration into code > | browser can be next and relatively easy step. As Store is integrated > | into VW code browser. > | > | Janko > | > | S, Dale Henrichs piÅ¡e: > | > Janko, > | > > | > I think the limitation for Smalltalk lies in source code management > | > tools/styles ... > | > > | > With a file-based language 200 engineers can contribute to the > | > project ... Â each engineer can checkout a version of the system > | > work in isolation then commit his or her work to the shared > | > repository resolve conflicts and move on .... other engineers can > | > easily integrate the work and so on ... the source code management > | > tools scale ... > | > > | > In the mid nineties at ParcPlace systems the image was passed > | > around from engineer to engineer so that he or she could integrate > | > their work into the production image... this doesn't scale... > | > > | > There have been proprietary source code management tools that have > | > been created over the years. You can bet that the large companies > | > that are invested in Smalltalk are using systems that are based on > | > these proprietary systems, but you can also bet that they've had > | > to customize those systems for their needs... > | > > | > The file-based SCM systems work out of the box and don't care what > | > language or even development process that is being used ... they > | > are managing files ... > | > > | > There is no standard SCM for Smalltalk and none of the file-based > | > SCMs really fit Smalltalk. When we are arguing about whether git > | > or mercurial is better on the Pharo list, I will retract that > | > statement:). > | > > | > Without a standard SCM, the first thing that a 200 person > | > engineering groups needs to do to start using Smalltalk is figure > | > out (for themselves) how to share their work and keep 200 > | > individual images in synch ... I'm not necessarily convinced that > | > anyone has really solved this one. > | > > | > Personally I believe that the problem is surmountable, but for > | > whatever reason the Smalltalk community hasn't focussed on > | > seriously addressing the SCM issue .... in the last 30 years or > | > so:) > | > > | > Being able to repeatably build images based on a minimal core image > | > is certainly headed in the right direction, but we still have a > | > ways to go on the tools front ... > | > > | > Dale > | > > | > > | > > | > ----- Original Message ----- > | > | From: "Janko MivÅ¡ek" <janko.mivsek(a)eranova.si> > | > | To: Pharo-project(a)lists.gforge.inria.fr, "Squeak" > | > | <squeak-dev(a)lists.squeakfoundation.org>, "VWNC" > | > | <vwnc(a)cs.uiuc.edu> > | > | Sent: Saturday, January 28, 2012 7:46:32 AM > | > | Subject: [squeak-dev] 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 > | > | > | > | > | > > | > > | > | -- > | Janko MivÅ¡ek > | Svetovalec za informatiko > | Eranova d.o.o. > | Ljubljana, Slovenija > | www.eranova.si > | tel: Â 01 514 22 55 > | faks: 01 514 22 56 > | gsm: 031 674 565 > | >

Jan. 28, 2012