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

[Pharo-project] small display in the image with condensed changes

by Pavel Krivanek

Hi, I tried the latest image with condensed changes from the CI server (https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4%20condense…) and when I open the image, it has very small display size, something like 12x12 pixels. The standard 1.4 image has normal display extent. Can you confirm that on other systems and VMs? Btw. Stef or Marcus, can you separe ThreadSafeTranscript to a standalone package. There was enough messages about Pharo-Kernel job failures :-) Cheers, -- Pavel

Jan. 30, 2012

Re: [Pharo-project] [update 1.4] #14298

by Camillo Bruni

I'll check again :) sorry I was unaware of the side-effects :D best cami On 2012-01-30, at 13:13, Sven Van Caekenberghe wrote: > > On 30 Jan 2012, at 12:36, Marcus Denker wrote: > >> This needs to be reverted: >> >> http://code.google.com/p/pharo/issues/detail?id=5222 >> >> So a .cs that either fixes it or reverts the change would help... I can look at reverting it the evening. > > If you revert MCCacheRepository>>#basicStoreVersion: and MCFileBasedRepository>>#notifyList to their previoius versions it works again. > To clean up, #includesFileNamed: should be removed as well. > > This is really a pity: it did make a noticeable difference. > > I looked a bit at the code and I can't figure out why this does not work as expected. > > Please, Camillo, please, it would be a shame to let improvements like this get lost. > > Sven

Jan. 30, 2012

Re: [Pharo-project] Enthousiasm is the main currency among developers

by Marcus Denker

On Jan 27, 2012, at 7:06 PM, Eliot Miranda wrote: > > > On Fri, Jan 27, 2012 at 1:53 PM, Guido Stepken <gstepken(a)googlemail.com> wrote: > I see quite a difference between "doing things right" and "doing the right things" ! :-) > > > Agreed. Don't let the perfect be the enemy of the good and all that. But we're talking at different levels here. I want to hear what Marcus thinks to my reply to his post. I think we need to look at the result. Does this kind of "piss on everything that moves" critique leads to a system that gets better? Or does it lead to complete standstill (because everyone fears to even suggest something). One can train a community to have a "no" reflex... this is what happend to Squeak over the years. Another aspect is: Is it *fun*? That is, does the community has positive energy? It can happen very quickly that this is lost. Marcus -- Marcus Denker -- http://marcusdenker.de

Jan. 30, 2012

Re: [Pharo-project] [update 1.4] #14298

by Sven Van Caekenberghe

On 30 Jan 2012, at 12:36, Marcus Denker wrote: > This needs to be reverted: > > http://code.google.com/p/pharo/issues/detail?id=5222 > > So a .cs that either fixes it or reverts the change would help... I can look at reverting it the evening. If you revert MCCacheRepository>>#basicStoreVersion: and MCFileBasedRepository>>#notifyList to their previoius versions it works again. To clean up, #includesFileNamed: should be removed as well. This is really a pity: it did make a noticeable difference. I looked a bit at the code and I can't figure out why this does not work as expected. Please, Camillo, please, it would be a shame to let improvements like this get lost. Sven

Jan. 30, 2012

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

by Otto Behrens

Hi, > how to you deal with conflict due to the for example move of methods due to file out? If someone edited a method that I moved to another class git picks it up and does not see a conflict, it includes the change on the new class. If both of us changed the method and I moved it, then git picks up a conflict and I have to edit the file. If the method was renamed by me and edited by someone else, it does not pick up a conflict, it sees it as a delete and modify conflict. I am sometimes quite amazed how it picks up what happened, but it does; we have not had problems that are in the way. I think it has to do with the nice object model git has, as well as the fact that it does not store deltas, but objects indexed by hashes. Cheers Otto

Jan. 30, 2012

Re: [Pharo-project] [update 1.4] #14298

by Marcus Denker

On Jan 29, 2012, at 10:01 PM, Benjamin wrote: > It seems there is a problem with Metacello which take down half of Jenkins projects ... > > > I got this error: "'retry with alternate repository failed: ''FileExistsException: ''''/Users/benjamin/Images/Pharo 1.4/Pharo-1.4 2/package-cache/Metacello-Base-DaleHenrichs.19.mcz'''''''" > This needs to be reverted: http://code.google.com/p/pharo/issues/detail?id=5222 So a .cs that either fixes it or reverts the change would help... I can look at reverting it the evening. Marcus -- Marcus Denker -- http://marcusdenker.de

Jan. 30, 2012

[Pharo-project] NonInteractiveUIManager

by Sven Van Caekenberghe

When making syntax errors in a startup script you get SubclassResponsibility: a NonInteractiveUIManager had the subclass responsibility to implement #syntaxErrorNotificationDefaultAction: Would it not be a better idea to just handle and print the syntax error ? Sven

Jan. 30, 2012

Re: [Pharo-project] pharo vision

by Edgar J. De Cleene

Excellent Too bad SOB of Squeak do not could bring us some similar. Edgar

Jan. 30, 2012

Re: [Pharo-project] pharo vision

by Milan Mimica

"Large applications" chapter on pages 6/7 is repeated twice. -- Milan Mimica http://sparklet.sf.net

Jan. 30, 2012

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

by StÃ©phane Ducasse

Hi otto how to you deal with conflict due to the for example move of methods due to file out? Stef > Hi, > > We've built a little package that allows us to save all our source in > git. We've been developing with this for 3 months now, and it's pretty > stable. I put a project on github, > https://github.com/finworks/smallsource that contains some more info > on it. Yes, there's more work to do, but there's hope. The repo > contains some examples that I just saved from the image. > > In short, we save and load all the monticello packages on our project > as smalltalk source files. We use git to merge and not monticello. We > use metacello, but watered down to essentially just dependencies. > > I just want to say thanks to all you people who put in such great > effort into Smalltalk. We are using Smalltalk to create a business and > are slowly getting somewhere. > > We've been using git for about 3 years now. This came from a need to > manage files, such as scripts, resources (images and stuff), documents > and recorded selenium (ide) tests with smalltalk code. So, we just > whacked all of this, including our monticello packages into the git > repo. > > As you can imagine, storing binary files in a git repo, especially > fairly large packages and lots of integrations / merges / versions, > grew the git repo quite a bit. We also needed to clone the git repo > all over. So we decided to give it a shot and write to files. > > It took about 2 weeks to get going and another to sort out some pain, > but the package in the smallsource repo have not changed for 3 months. > > We are 5-6 developers on the project, committing numerous times a day. > We currently have about 1100 classes (find repo -type d | wc -l gives > us 2200) and 23500 methods (find . -type f | grep -v "mcz$" | wc -l > gives us 23545) managed in this way. > > I'm keen to talk about how we can really "do the right thing" and > solve this source code management monster. I know this approach needs > work (I'll list some issues on the project, that I think needs > attention) and I also realise that there could be better approaches. > > Here's another idea: we can map class definitions and method > definitions directly to git objects. Git has a great object model > which will allow us to directly track the complete history of a method > or class definition, with commit details and what not. In a sense, I > feel that a tight integration between a smalltalk environment and git > will be a fantastic solution - something like envy, but on git, with > all the fanciness that comes with git! > > The only problem with this is a very tight coupling with git. Do we want that? > > Thanks again > Otto >

Jan. 30, 2012