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

[Pharo-project] browsers vs. guis

by Tudor Girba

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."

Jan. 28, 2012

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

by Igor Stasenko

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 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.

Jan. 28, 2012

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

by Michael Haupt

Karl, Am 28.01.2012 um 20:39 schrieb karl ramberg <karlramberg(a)gmail.com>: > Is there any work done on managing live images with several developers ? I'm not all sure I understand your question, but: http://www.hpi.uni-potsdam.de/hirschfeld/misc/etc/index.html Best, Michael

Jan. 28, 2012

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

by Dale Henrichs

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. 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... 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] Smalltalk for small projects only?

by Michael Haupt

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. 28, 2012

Re: [Pharo-project] addToStartUpList and World extent

by StÃ©phane Ducasse

This is strange. Did you look at the startup sequence? On Jan 28, 2012, at 10:01 PM, Hilaire Fernandes wrote: > Hello Pharoers, > > I am using "Smalltalk addToStartUpList: self" to register DrGeo in the > startup sequence, so a new drgeo window is instantiated fullscreen > automatically if none exist. However I have noted, at least on iPad and > Android, that the instantiated window is not set to the correct > fullscreen extent (it is smaller). DrGeo Window instantiated later from > user request are correctly set fullscreen. > > Could it be that World, at the startUp sequence time, does not know yet > the screen extent? > Should I use another kind of startup sequence > > Thanks > > Hilaire > > -- > Dr. Geo -- http://www.drgeo.eu > >

Jan. 28, 2012

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

by Igor Stasenko

On 28 January 2012 22:06, Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch> wrote: > May be it is time to forget about the image, I mean the name of the > image and change for something else, more in the proximal learning zone > of programmer. It is not an image we have, it is a data base of object, > and we are programming on this object data base. > Hmm.. when i started with smalltalk, it was pretty obvious to me from the very starting that an image is a bunch of dead bytes, and there's not much you can do with it at that level. Apparently people should not use "image" as as interchange product between project teams. As for scale.. monticello scales well. And if you scale to something huge (200 people) , your main problem will be to organize a process, and establish a rules. People were doing huge projects without SCMs in the past.. so it think organizing large projects is more depending on social organization rather than on technical limitations of tools they will use. > Hilaire > > > Le 28/01/2012 17:50, dimitris chloupis a Ã©crit : >> 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. > > > -- > Dr. Geo -- http://www.drgeo.eu > > -- Best regards, Igor Stasenko.

Jan. 28, 2012

Re: [Pharo-project] addToStartUpList and World extent

by Hilaire Fernandes

I am tempted to use #addDeferredStartupAction: instead, but it is not clear yet. If anyone has some experience to share about that I take it. Hilaire Le 28/01/2012 22:01, Hilaire Fernandes a Ã©crit : > Hello Pharoers, > > I am using "Smalltalk addToStartUpList: self" to register DrGeo in the > startup sequence, so a new drgeo window is instantiated fullscreen > automatically if none exist. However I have noted, at least on iPad and > Android, that the instantiated window is not set to the correct > fullscreen extent (it is smaller). DrGeo Window instantiated later from > user request are correctly set fullscreen. > > Could it be that World, at the startUp sequence time, does not know yet > the screen extent? > Should I use another kind of startup sequence > > Thanks > > Hilaire > -- Dr. Geo -- http://www.drgeo.eu

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: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. > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Jan. 28, 2012

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

by Hilaire Fernandes

May be it is time to forget about the image, I mean the name of the image and change for something else, more in the proximal learning zone of programmer. It is not an image we have, it is a data base of object, and we are programming on this object data base. Hilaire Le 28/01/2012 17:50, dimitris chloupis a Ã©crit : > 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. -- Dr. Geo -- http://www.drgeo.eu

Jan. 28, 2012