- Pharo-dev - lists.pharo.org

[Pharo-project] Workspace API
by Keith Hodges Feb. 12, 2009

Feb. 12, 2009

http://bugs.squeak.org/view.php?id=5669 I requested then implemented a reasonable API for opening Workspaces on strings and files. I now find that pharo has implemented incompatible versions of the same. Workspace openContents: 'blah'. or Workspace new contents: 'blah'; label: 'Title'; open. Keith

6 23

[Pharo-project] I have a problem and I will redo the last update
by StÃ©phane Ducasse Feb. 12, 2009

Feb. 12, 2009

sorry. stef

1 0

[Pharo-project] [ANN][Dev-Images] February 2009 versions
by Damien Cassou Feb. 12, 2009

Feb. 12, 2009

Hi, I've just uploaded new dev and web images based on Squeak3.9.1-7075, Squeak3.10.2-7179 and Pharo0.1-10231. More information and download: http://damiencassou.seasidehosting.st/Smalltalk/squeak-dev Pharo-based images can be downloaded at: http://code.google.com/p/pharo/wiki/Downloads?tm=2 Download statistics at http://damiencassou.dabbledb.com/publish/dev-imagesdownloads Changes in this version: --------------------------- - Pharo images are based on version 10231 - Polymorph fixes (by Gary Chambers) - OmniBrowser changes (by David RÃ¶thlisberger) - Refactored auto-selection of list items to be easier extensible - Extended and improved traits integration (various new features) - Integrated OB patches done by various people - Improved compatibility to Polymorph (button colors, scrollbars) - Several defects corrected - Magritte and Pier have been updated to version 1.1 (by Lukas Renggli and Tudor Girba) Contained packages: ------------------------ This image contains the following packages (some packages are only in the squeak-web image or 3.10-based images): Aida version 5.6 Algernon version 1.2 AST version 160 AutomaticMethodCategorizer version 0.25 AutomaticMethodCategorizerOB version 0.2 DynamicBindings version 2.7 eCompletion version 0.102 eCompletion-Traits version 0.1 eCompletionOmniBrowser version 0.5 Installer version 4.3.284 KomHttpServer version 7.0.30 KomServices version 1.12 Magritte-Model version 1.1.331 Magritte-Seaside version 1.1.283 Magritte-Tests version 1.1.148 OB-Enhancements version 0.292 OmniBrowser version 0.436 OmniBrowser-Algernon version 0.5 OmniBrowser-Full version 0.27 OmniBrowser-Morphic version 0.74 OmniBrowser-Refactory version 117 OmniBrowser-Regex version 0.9.1 OmniBrowser-Standard version 0.389 Pier version current Pier-Blog version 1.1.103 Pier-Documents version 1.1.7 Pier-EditorEnh version 1.1.17 Pier-Model version 1.1.263 Pier-Seaside version 1.1.331 Pier-Security version 1.1.119 Pier-Tests version 1.1.116 Polymorph EventEnhancements version 1.1 Polymorph Geometry version 1.1 Polymorph TaskbarIcons version 1.0 Polymorph ToolBuilder version 1.2 Polymorph Tools Diff version 1.3 Polymorph Widgets version 1.3 Refactoring Core version 17 RoelTyper version 0.60 RSRSS2 version 2.8.3.11 Scriptaculous version 2.8.3.242 ScriptManager version 0.6 Seaside version 2.8.3.572 Seaside-Adapters-Core version pmm.2.mcz Seaside-Adapters-Swazoo version 9 Seaside-Squeak-Adapters version pmm.3.mcz SeasideAdaptersCompatibility version pmm.1.mcz Shout version 3.15-tween.72 ShoutWorkspace version 1-tween.4 SmaCC runtime version 13 Sport version 2.31 Squeak dev packages version 0.27 Squeak dev packages beta version 0.32 Squeak web packages version 0.2 SUnit-improved version 4.0.118 SUnitGUI-improved version 4.0.50 Swazoo version 2.1 Universes version 51 Universes OmniBrowser version 0.38 VBRegex version 1.9 YAXO version 14 -- Damien Cassou http://damiencassou.seasidehosting.st

2 1

[Pharo-project] [ANN] 10233 MVCMenuMorph removal + collectSelect...
by StÃ©phane Ducasse Feb. 12, 2009

Feb. 12, 2009

1 0

[Pharo-project] isActive and isEnable
by Alexandre Bergel Feb. 12, 2009

Feb. 12, 2009

Dear OBers, What is the difference between these two methods? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 3

[Pharo-project] Unwanted rude behaviour (was Re: Workspace API)
by Provoost, P (Paul) Feb. 12, 2009

Feb. 12, 2009

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

2 1

[Pharo-project] Fwd: [squeak-dev] ditching Monticello objects.
by StÃ©phane Ducasse Feb. 12, 2009

Feb. 12, 2009

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

1 0

[Pharo-project] Issue #505
by HernÃ¡n Morales Durand Feb. 12, 2009

Feb. 12, 2009

http://code.google.com/p/pharo/issues/detail?id=505

3 2

[Pharo-project] DNU error in OB
by Serge Stinckwich Feb. 12, 2009

Feb. 12, 2009

Hi all, i have a DNU error each time i didn't select any category when i open a new OB browser and i search a class with CTRL-F. Cheers, -- Serge Stinckwich IRD - UR 079 Geodes, MSI Team, Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

4 3

Re: [Pharo-project] Call for UI gripes
by Bill Schwab Feb. 11, 2009

Feb. 11, 2009

Gary, Space to sides of the buttons?? Perhaps unrelated, but I have been thinking of something similar while poking at Damien's recent dev image. Bottom line, I switched to Soft Squeak and was pleased to see that the OB buttons didn't look quite as (pardon me) UGLY<g> (sorry, but that needed to be said) as they did not long ago. It's getting quite nice. The problem was not the buttons so much as an awkward combination of shape, size and mismatching background color behind them. It would help even more to "do the same thing to the code buttons that has been done to the classes buttons." I hope that makes some sense. Take a look at the browser in soft squeak. Note two rows of buttons "in the middle." The upper row looks nicer than the lower row; a tweak of background color would help a lot, I think?? Soft squeak is a nice theme, and (I assume OB changes) have helped it a lot; it was hard on the eyes for a little while. In replying to something not long ago, you mentioned the range of themes and how they differ in color handling. In particular, Soft Squeak lets the tool colors show through. I have an idea for using that to advantage. The clay rose tint to the debugger is great - it does just the right psychological thing without being too strong. The browser color could be nicer; of course it can be set, but I think we should find another default. I recall playing with blues some time ago, but it can't be too strong due to the label text color. Anybody have any ideas? While I might be setting us up for even more drawing and a speed hit (ignore this if you fear that), it might be nice to render the tool-specific title bar icon in the task bar. That way, we could use the same color for browsers and workspaces, and still have them stand out by icon. The debugger would keep its color, as might the preference browser and other "special purpose" tools. Just some ideas. Thanks for the great work! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 02/10/09 8:25 AM >>> ----- Original Message ----- From: "Damien Pollet" <damien.pollet(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 08, 2009 1:52 PM Subject: Re: [Pharo-project] Call for UI gripes > On Sat, Feb 7, 2009 at 17:58, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: >> I suppose I could suggest replacing some of the button bars with more >> compact iconic toolbars. Things like debugging over, into, etc. lend >> themselves well to that. The world menu will not make much sense if we >> ever get one window per shell. > > it was probably already said, but could the other buttons in the > browser use the squarish buttons from the task bar rather than the > current rounded ones that waste a bit of space ? > At present the space to the sides must be reserved as the rounded state of the buttons is not known at the time of creation/initial-layout. I'll have a go at making it more adaptable. >> The biggest concern I have right now is speed. I'm not saying Pharo is >> too slow; I'm simply admitting that I do not know whether it is fast >> enough for some of the things I want to do. > > Agreed. Actually I'm wondering if a very sleek minimalistic theme > would be nice* flat colors, simple lines, very limited complicated > stuff like gradients or shaders* provided the typography, widget > spacing, and color choices are done with taste, I think it can look > quite nice, and would even be more usable than a more flashy theme. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 2