February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Unwanted rude behaviour (was Re: Workspace API)

by StÃ©phane Ducasse

Paul this is not a problem. I understand what keith is saying but we have a bootstrap problem: how can people help building better extensions. stef On Feb 12, 2009, at 12:21 PM, Provoost, P (Paul) wrote: > Keith, > > I think that you should not raise your voice the way you do in this > mailing list. > Please don't be rude in this list, it spoils the positive and > friendly atmosphere of it. > If you want to quarrel with Stef, then please do it in private mails. > > Thanks, > > Paul > > > Keith wrote: > >> You still dont get it do you. *** really look at it *** means pick >> over >> the carcass. Adopting it means JOINING IN AND MAKING EVERYTHING >> BETTER >> FOR EVERY ONE. > >> You guys have the expertise to fix things I dont, and test things >> that I >> dont. I dont have the skill to meet your high coding standards. I am >> working on comercial projects and I need something that WORKS not >> something that looks pretty. I used a code formatter for 6 years, so >> when I see code I dont see that it needs formatting. It looks ok to >> me. > >> If you adopt it, then your whole team of testers and experts get to >> contribute, and everyone benefits. > >> The reason I am causing trouble, and raising my voice is not that you >> wont use my stuff, its that you will not participate in any >> collaborative attitude AT ALL. Monticello IS NOT YOUR PROJECT, it is >> EVERYONES. It is the PEOPLES MONTICELLO. Your approach is killing >> that >> vision, and taking NEEDED (according to you private emailer) >> expertise >> away from that vision. > > >> Keith > > >> p.s. It doesnt matter if the code is crap, un-formatted crap. It cant >> possibly be worse than MC1.0 and the amount of cruft I refactored. > > > _____________________________________________________________ > > This email (including any attachments to it) is confidential, > legally privileged, subject to copyright and is sent for the > personal attention of the intended recipient only. If you have > received this email in error, please advise us immediately and > delete it. You are notified that disclosing, copying, distributing > or taking any action in reliance on the contents of this information > is strictly prohibited. Although we have taken reasonable > precautions to ensure no viruses are present in this email, we > cannot accept responsibility for any loss or damage arising from the > viruses in this email or attachments. We exclude any liability for > the content of this email, or for the consequences of any actions > taken on the basis of the information provided in this email or its > attachments, unless that information is subsequently confirmed in > writing. If this email contains an offer, that should be considered > as an invitation to treat. > _____________________________________________________________ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 12, 2009

Re: [Pharo-project] Workspace API

by StÃ©phane Ducasse

>> You still dont get it do you. *** really look at it *** means pick >> over > the carcass. Adopting it means JOINING IN AND MAKING EVERYTHING BETTER > FOR EVERY ONE. I know. > > > You guys have the expertise to fix things I dont, I'm not sure :) > and test things that I > dont. I dont have the skill to meet your high coding standards. I am > working on comercial projects and I need something that WORKS not > something that looks pretty. I used a code formatter for 6 years, so > when I see code I dont see that it needs formatting. It looks ok to > me. Ok > If you adopt it, then your whole team of testers and experts get to > contribute, and everyone benefits. > > > The reason I am causing trouble, and raising my voice is not that you > wont use my stuff, its that you will not participate in any > collaborative attitude AT ALL. Monticello IS NOT YOUR PROJECT, it is > EVERYONES. It is the PEOPLES MONTICELLO. Your approach is killing > that > vision, and taking NEEDED (according to you private emailer) expertise > away from that vision. I do not think so but I understand what you are saying. Now this is not that easy. > p.s. It doesnt matter if the code is crap, un-formatted crap. It cant > possibly be worse than MC1.0 and the amount of cruft I refactored. Probably. I'm not against, I just do not have enough cycles and I imagine that this is the same for other people. Looking/integrating part of Kernel extensions SUnit + MC1.5 is still on my stack but my stack is long. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 12, 2009

Re: [Pharo-project] Workspace API

by StÃ©phane Ducasse

I know. I just want to tell you that nothing is easy. Now saying that we do not pay attention is not exact. But really beside integrating fixes and cleaning etoy I have no time. Stef On Feb 12, 2009, at 11:22 AM, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> About MC1.5 here is what I received as a private email. >> So I imagine that the person is a bit too negative too but you can >> understand that we pay attention and need time >> to ***really*** look at it. >> >> I hope you don't include Monticello 1.5 in Pharo. All code that we >> have seen so far from Keith cases trouble. I have nothing to support >> this except the people reporting problems with Monticello 1.5. >> >> Stef >> >> > Well thats incredibly stupid. > > I have NO KNOWLEDGE of these so called problems. What are they were > are > they? > > If the anonymous detracter will tell me what those problems are we can > fix them. We aim to be very responsive. > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 12, 2009

[Pharo-project] Unwanted rude behaviour (was Re: Workspace API)

by Provoost, P (Paul)

Keith, I think that you should not raise your voice the way you do in this mailing list. Please don't be rude in this list, it spoils the positive and friendly atmosphere of it. If you want to quarrel with Stef, then please do it in private mails. Thanks, Paul Keith wrote: >You still dont get it do you. *** really look at it *** means pick over >the carcass. Adopting it means JOINING IN AND MAKING EVERYTHING BETTER >FOR EVERY ONE. >You guys have the expertise to fix things I dont, and test things that I >dont. I dont have the skill to meet your high coding standards. I am >working on comercial projects and I need something that WORKS not >something that looks pretty. I used a code formatter for 6 years, so >when I see code I dont see that it needs formatting. It looks ok to me. >If you adopt it, then your whole team of testers and experts get to >contribute, and everyone benefits. >The reason I am causing trouble, and raising my voice is not that you >wont use my stuff, its that you will not participate in any >collaborative attitude AT ALL. Monticello IS NOT YOUR PROJECT, it is >EVERYONES. It is the PEOPLES MONTICELLO. Your approach is killing that >vision, and taking NEEDED (according to you private emailer) expertise >away from that vision. >Keith >p.s. It doesnt matter if the code is crap, un-formatted crap. It cant >possibly be worse than MC1.0 and the amount of cruft I refactored. _____________________________________________________________ This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat. _____________________________________________________________

Feb. 12, 2009

Re: [Pharo-project] Workspace API

by Keith Hodges

StÃ©phane Ducasse wrote: > About MC1.5 here is what I received as a private email. > So I imagine that the person is a bit too negative too but you can > understand that we pay attention and need time > to ***really*** look at it. > > I hope you don't include Monticello 1.5 in Pharo. All code that we > have seen so far from Keith cases trouble. I have nothing to support > this except the people reporting problems with Monticello 1.5. > > Stef > You still dont get it do you. *** really look at it *** means pick over the carcass. Adopting it means JOINING IN AND MAKING EVERYTHING BETTER FOR EVERY ONE. You guys have the expertise to fix things I dont, and test things that I dont. I dont have the skill to meet your high coding standards. I am working on comercial projects and I need something that WORKS not something that looks pretty. I used a code formatter for 6 years, so when I see code I dont see that it needs formatting. It looks ok to me. If you adopt it, then your whole team of testers and experts get to contribute, and everyone benefits. The reason I am causing trouble, and raising my voice is not that you wont use my stuff, its that you will not participate in any collaborative attitude AT ALL. Monticello IS NOT YOUR PROJECT, it is EVERYONES. It is the PEOPLES MONTICELLO. Your approach is killing that vision, and taking NEEDED (according to you private emailer) expertise away from that vision. Keith p.s. It doesnt matter if the code is crap, un-formatted crap. It cant possibly be worse than MC1.0 and the amount of cruft I refactored.

Feb. 12, 2009

Re: [Pharo-project] Workspace API

by Keith Hodges

StÃ©phane Ducasse wrote: > About MC1.5 here is what I received as a private email. > So I imagine that the person is a bit too negative too but you can > understand that we pay attention and need time > to ***really*** look at it. > > I hope you don't include Monticello 1.5 in Pharo. All code that we > have seen so far from Keith cases trouble. I have nothing to support > this except the people reporting problems with Monticello 1.5. > > Stef > > Well thats incredibly stupid. I have NO KNOWLEDGE of these so called problems. What are they were are they? If the anonymous detracter will tell me what those problems are we can fix them. We aim to be very responsive. Keith

Feb. 12, 2009

[Pharo-project] Fwd: [squeak-dev] ditching Monticello objects.

by StÃ©phane Ducasse

Begin forwarded message: > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Date: February 12, 2009 6:13:50 AM CEST > To: Keith Hodges <keith_hodges(a)yahoo.co.uk> > Cc: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: Re: [squeak-dev] ditching Monticello objects. > Reply-To: johnmci(a)smalltalkconsulting.com, The general-purpose > Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Ok, well I did > > I've been collecting lists of pruning methods so.. > > ScrollBar initializeImagesCache. > GradientFillStyle initPixelRampCache. > NaturalLanguageFormTranslator classPool at: #CachedTranslations > put: nil. > NaturalLanguageTranslator resetCaches. > PartsBin clearThumbnailCache. > PaintBoxMorph classPool at: #ColorChart put: nil. > PaintBoxMorph classPool at: #Prototype put: nil. > ImageMorph classPool at: #DefaultForm put: (Form extent: 1@1 depth: > 1). > Utilities classPool at: #ScrapsBook put: nil. > Project allInstancesDo: [ :each | each setThumbnail: nil ]. > ScriptingSystem stripGraphicsForExternalRelease. > ProjectHistory currentHistory initialize. > Utilities zapUpdateDownloader. > Smalltalk forgetDoIts. > Behavior flushObsoleteSubclasses. > CommandHistory allInstancesDo: #initialize. > ChangeSorter removeChangeSetsNamedSuchThat: [ :each | true ]. > ChangeSet resetCurrentToNewUnnamedChangeSet. > MethodChangeRecord allInstancesDo: [ :x | x noteNewMethod: nil ]. > RequiredSelectors initialize. > ProvidedSelectors initialize. > LocalSends initialize. > SendCaches initializeAllInstances. > Utilities cleanseOtherworldlySteppers. > Smalltalk organization removeEmptyCategories. > Browser initialize. > SMSqueakMap default purge. > SystemBrowser removeObsolete. > TheWorldMenu removeObsolete. > AppRegistry removeObsolete. > FileServices removeObsolete. > MCFileBasedRepository flushAllCaches. > MCDefinition clearInstances. > Undeclared removeUnreferencedKeys. > Smalltalk flushClassNameCache. > 3 timesRepeat: [ Smalltalk garbageCollect. Symbol > compactSymbolTable ]. > Set rehashAllSets. > Smalltalk garbageCollect. > > > > I added these ones. > > ChangeSorter initializeChangeSetCategories. > MCWorkingCopy inspect. > MCRepositoryGroup inspect. > MCCacheRepository inspect. > > and cleaned up the class instance variables & any class vars via the > inspect. > > That removed all the MC packages and MC http repositories from the > MC Browser > > gave me back 4 megabytes of image space. > > Well brute force, still 4 mb wonderful to get back this late in the > project. > > > On 11-Feb-09, at 6:18 PM, Keith Hodges wrote: > >> John M McIntosh wrote: >>> I'm building an image for a limited memory hardware platform. >>> >>> At the point here where I want to *deploy* things and I can see that >>> various parts of Monticello >>> are consuming well over a megabyte of memory to retain MCVersionInfo >>> instances, MCMethodDefinition(s), time stamps, uuids, etc etc >>> >>> I'm wondering if anyone has some code to strip all that out thus >>> returning I suspect a couple of MB back for more constructive usage? >> You may want to look into the cleanUp/freeSomeSpace conventions. >> MC1.5 >> has a few implemented. There are many more available from >> http://bugs.squeak.org/view.php?id=7244 >> >> Keith > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > >

Feb. 12, 2009

Re: [Pharo-project] Workspace API

by StÃ©phane Ducasse

On Feb 11, 2009, at 7:34 PM, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> Where? When? >> Keith >> in the long run it would be nice that yu do not bash us >> systematically. >> Yes we have a different way of working but normally this is often by >> pure lack of time or information >> that we do not check what exist. >> >> Stef >> > I was concerned to find code in Pier that did not seem to be > compatible > with squeak, while I thought that the Workspace issue had come up > before. no idea. > Your different way of working..... as I see it: > > You want more tests, you develop more tests, you add more tests to the > image. Are those tests useful to the rest of the squeak community? No. > Should they be? YES. > > If there was a way of marking those tests that are pharo only tests, > as > such, and also marking those tests that should work in squeak. Then > the > squeak/pharo communities could use one testing package for all squeak > images, and pharo. may be > So to enable this to happen you need to think about testing in a > broader > sense and you need improved tools to handle it, and you need to > develop > or assess those tools FIRST. Yes. > hmm, so August 2006, I thought this through, that to support diversity > in the squeak community we needed something like that, and > SUnit-improved was the result. That was its purpose, to support > forks of > squeak, I believe in forking squeak.... I know I should have a look at SUnit-Improved but my time is limited > All the tools I have worked on for 2 years are to enable working with > diverse images, and to facilitate packages to work in different > images. > Thus reducing the dependency upon a specific kernel-image and thus > releasing the kernel-image to be improved. > > What I don't believe in was the pharo approach of going your own way > WITHOUT considering anyone else, to the extent that you ignore all of > the extensive work that has been carried out to provide tools that > would > enable you to participate. The main goal of the 3.11 effort hasn't > been > a particular image, but a tool set, and a process, that would enable > folks to work on diverse projects, while considering each other. Our goal is to make progress. Squeak is dying don't see it? > And you are ignoring those tools, because you dont see them as > important. No. The problem is the noise ratio with them (nul pattern, bad formatting, extensive extensions....) > I cant work out why you dont see them as important is because > you have sucessfully harnessed a lot of enthusiasm for improving > squeak. > YET you dont have a process for using that enthusiam effectively. You > still have the same old bottlenecked controlled process where there is > no actual plan (you do what you feel like when you get up in the > morning), and two people get to hack at the image day and night and > everyone else is contributing to a moving target. I would love to have a buildServer and also run automatically SmallLint rules on the code now either pharo does not exist because we build those tools or pharo exist. So we are going slowly on both side. I was hoping to get such buildserver and this is why we started to write on Installer (and you know that this is not only for pharo so you should be happy). Now you should ask yourself the question why people are not all using your tool extensions. Conservatism? stupidity? lack of time? lack of trust? Dont'care? Stef

Feb. 12, 2009

Re: [Pharo-project] Workspace API

by StÃ©phane Ducasse

About MC1.5 here is what I received as a private email. So I imagine that the person is a bit too negative too but you can understand that we pay attention and need time to ***really*** look at it. I hope you don't include Monticello 1.5 in Pharo. All code that we have seen so far from Keith cases trouble. I have nothing to support this except the people reporting problems with Monticello 1.5. Stef On Feb 11, 2009, at 6:55 PM, Keith Hodges wrote: > Alexandre Bergel wrote: >> I was wondering, how many people saved their workspace content in a >> file? >> >> Cheers, >> Alexandre >> > MC1.5 supports files so if you want to manage scripts and readmes > having > a workspace that knows its file, is a good idea. > > Also Bob wants a way to (optionally) show you the script that it > used to > build the image. > > http://bugs.squeak.org/view.php?id=5669 > > Keith > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 12, 2009

Re: [Pharo-project] Issue #505

by StÃ©phane Ducasse

thanks a lot! Stef On Feb 11, 2009, at 5:28 PM, HernÃ¡n Morales Durand wrote: > http://code.google.com/p/pharo/issues/detail?id=505 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 12, 2009