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

[Pharo-project] Integrate changes from Cuis (was Fwd: [squeak-dev] Cuis update - Separate change sets for goodies available)
by Adrian Lienhard April 8, 2009

April 8, 2009

There probably are a couple of interesting improvements/fixes in the work of Juan. I created an issue: http://code.google.com/p/pharo/issues/detail?id=717 Adrian Begin forwarded message: > From: Juan Vuletich <juan(a)jvuletich.org> > Date: April 6, 2009 3:28:28 PM GMT+02:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: [squeak-dev] Cuis update - Separate change sets for goodies > available > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > Hi Folks, > > I've just uploaded http://www.jvuletich.org/Cuis/Cuis1.0-0169.zip . > I did some refactoring and cleanup in ScrollPane and ScrollBar. Now > Browser openBrowser takes almost half the time! I also added back > the preference for scrollbars on left. So, Klaus, you don't need to > do it. > > (These were already in previous release, 0166: I removed the Old > prefix from Morphic classes, to ease loading code from other Squeak > distributions. I also changed fonts to use just 16bpp and not 32. > The difference is invisible to my eyes, and they use half the space. > And I fixed the #isMorphic bug reported by Klaus. ) > > I also uploaded http://www.jvuletich.org/Cuis/ > CuisUpdatesUpTo0169.zip . This file includes the change sets of the > last year. I don't have older ones available in cs form, but most > goodies and tweaks that could be useful for other Squeak > distributions are here. This http://www.jvuletich.org/Cuis/CategoriesAndChangeSets.txt > is the detail of which changesets belong to which of the following > categories: > > - Rename class and update references goodie > - Process scheduling enh > - MessageTally enh > - Logging and ChangeSet enhancements > - Dan's == with SmallIntegers > - Affected class categories goodie > - Protocol Catcher goodie > - Nicer Cursors > - Chronology enh > - Parser enh > - ProgressBar enh > - Text cleanup and refactoring > - ScrollPane and ScrollBar cleanup & refacto > - NiceFonts > - Code authorship and relicensing > - Focus navigation and enh > - Pointer explorer goodie > - Code evaluation fixes > - Remote cursor sender goodie > - Semaphores, Delays and Processes > - Misc goodies and lesser tweaks > - Cleanup > - Morphic / LightWidgets > > Comments welcome. > > Cheers, > Juan Vuletich >

2 3

[Pharo-project] Schedule slippage
by stephan＠stack.nl April 8, 2009

April 8, 2009

Can we do something about the way schedule slippage is handled? There is a lot of feature creep, and we are taking too small slippages. Based on yesterdays weather, 1.0 is not going to be released in May 2009. Issues were closed after on average 30 days, 48% within a week, but 10% took 85 days or longer. Of the new,started,accepted, fixed issues for 1.0 40% is 280 days old. Stephan

5 5

Re: [Pharo-project] Schedule slippage
by stephan＠stack.nl April 8, 2009

April 8, 2009

Adrian wrote: > Thanks for the stats. How did you produce them? From the csv output of the issue tracker. I used an old Delphi hack and a calculator, but if you're interested in generating some kind of burn-down chart, I can do a Pharo version. (or a DabbleDB one, I guess) > One way to alleviate the problem is if more people help. There is > work for everybody. I know, but that's not likely to solve this problem. More people = more scope creep. The issue is that if Pharo is to be a professional development tool, the release schedule should be somewhat reliable. If we miss a milestone, just adding another month to the schedule isn't working very well. Stephan

2 1

[Pharo-project] [ANN][Dev-Images] April 2009 versions
by Damien Cassou April 8, 2009

April 8, 2009

Hi, I've just uploaded new dev and web images based on Squeak3.9.1-7075, Squeak3.10.2-7179 and Pharo0.1-10268. More information and download: http://damiencassou.seasidehosting.st/Smalltalk/squeak-dev Pharo-based images can be downloaded at: http://pharo-project.org/download Download statistics at http://damiencassou.dabbledb.com/publish/dev-imagesdownloads Changes in this version: --------------------------- - Pharo images are based on version 10268 - Pharo images are now closure-based - KomHttpServer has been updated with bug fixes, code cleaning and speed improvements (Giovanni Corriga, Michael Rueger, Julian Fitzell and GÃ¶ran Krampe) - Lukas Renggli updated Magritte and Pier - The code critic tool (lint) saw the addition of 4 new rules (by Lukas Renggli) - OmniBrowser changes (by David RÃ¶thlisberger) - Added package dependency command - Fixed move to package command - Improved performance of senders browser - Added support for tooltips to radio buttons (Dale Henrichs) - Added 'accept' button to menu appearing when a method contains unsaved changes (Simon) - Several minor improvings, corrections Contained packages: ------------------------ This image contains the following packages (some packages are only in the squeak-web image): Aida version 5.6 Algernon version 1.2 AST version 164 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 Installer-Core version 4.3.313 Installer-Formats version 4.3.3 Installer-Scripts version 4.3.8 KomHttpServer version 7.0.45 KomServices version 1.19 Magritte-Model version 1.1.1.340 Magritte-Seaside version 1.1.1.284 Magritte-Tests version 1.1.1.149 OB-Enhancements version 0.317 OmniBrowser version 0.444 OmniBrowser-Algernon version 0.5 OmniBrowser-Full version 0.27 OmniBrowser-Morphic version 0.86 OmniBrowser-Refactory version 145 OmniBrowser-Regex version 0.18 OmniBrowser-Standard version 0.402 Pier version current Pier-Blog version 1.1.1.108 Pier-Documents version 1.1.1.8 Pier-EditorEnh version 1.1.1.17 Pier-Model version 1.1.1.271 Pier-Seaside version 1.1.1.340 Pier-Security version 1.1.1.121 Pier-Tests version 1.1.1.117 Polymorph EventEnhancements version 1.1 Polymorph Geometry version 1.1 Polymorph TaskbarIcons version 1.0 Polymorph ToolBuilder version 1.3 Polymorph Tools Diff version 1.3 Polymorph Widgets version 1.4 Refactoring Core version 48 Refactoring Spelling version 5 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.28 Squeak web packages version 0.2 SUnit-improved version 4.0.118 SUnitGUI-improved version 4.0.50 Swazoo version 2.1 Universes version 52 Universes OmniBrowser version 0.38 VBRegex version 1.9 YAXO version 14 -- Damien Cassou http://damiencassou.seasidehosting.st

3 6

Re: [Pharo-project] Fwd: Re: FFI in closure image/modifying block arguments
by StÃ©phane Ducasse April 8, 2009

April 8, 2009

Yes this is why elliot added the preference so that you can load code doing assignment. On Apr 8, 2009, at 9:14 AM, Andreas Raab wrote: > StÃ©phane Ducasse wrote: >> block args in smalltalk are read-only > > For sure. But my point is that there is a lot more code out there > using block arg assignment than you might think. And it's one issue > to keep your own code clean, and a completely different one to force > other people to change theirs to your standards. Most of what you'll > get is complaints that "your system does't work, it doesn't even > load code that works fine in x, y, or z". Been there, done that > (underscore assignment in Croquet). It's a difficult road since you > loose potential users (people try, fail, and go away). But do > whatever you feel like. > > Cheers, > - Andreas > > >> On Apr 7, 2009, at 10:01 PM, Torsten Bergmann wrote: >>> I forwarded the mail from Andreas, since I think he is not >>> subscribed >>> to pharo list and his answer didnt appear on the the list archive. >>> >>> Many places - I agree. I had the problem while loading OB alpha >>> before >>> FFI since OB also had block arg assignment. But it was very easy to >>> fix. FFI could/should also be fixed. That's at least a start. >>> >>> However - the question left is if block arg assignment should be >>> allowed ... >>> >>> Bye >>> T. >>> >>> BTW: Andreas: would be good if you could subscribe to pharo list. If >>> you fear the traffic then just disable mail forwarding and use >>> the web archive to read. That's how I do it on all squeak related >>> lists and it works fine. >>> >>> >>> -------- Original-Nachricht -------- >>> Datum: Tue, 07 Apr 2009 07:06:41 -0700 >>> Von: Andreas Raab <XYZ(a)XYZ.de> >>> An: Torsten Bergmann <XYZ(a)XYZ.de> >>> CC: pharo-project(a)lists.gforge.inria.fr >>> Betreff: Re: FFI in closure image/modifying block arguments >>> >>> I think it is advisable to allow block arg assignment for the time >>> being. There is *lots* of code which uses it knowingly or >>> unknowingly >>> and unless you've fixed every single case you'll have these troubles >>> every step of the way. For laughs, just try to recompile all the >>> classes >>> in your image to see how far you get. >>> >>> Cheers, >>> - Andreas >>> >>> Torsten Bergmann wrote: >>>> FYI: with the new closure changes/image (Pharo0.1Core-10268cl.zip >>>> from [1]) >>>> it is not possible to store into block arguments: >>>> >>>> 1 to: 10 do: [:i | i := i + 1. Transcript show: i printString ] >>>> >>>> That makes the current version of FFI unloadable, due to >>>> the code in ExternalTypeClass>>initializeAtomicTypes >>>> >>>> Bye >>>> T. >>>> >>>> >>>> [1] https://gforge.inria.fr/frs/?group_id=1299 >>> >>> -- >>> Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit >>> allen: http://www.gmx.net/de/go/multimessenger01 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >

1 0

[Pharo-project] Fwd: Re: FFI in closure image/modifying block arguments
by Torsten Bergmann April 8, 2009

April 8, 2009

I forwarded the mail from Andreas, since I think he is not subscribed to pharo list and his answer didnt appear on the the list archive. Many places - I agree. I had the problem while loading OB alpha before FFI since OB also had block arg assignment. But it was very easy to fix. FFI could/should also be fixed. That's at least a start. However - the question left is if block arg assignment should be allowed ... Bye T. BTW: Andreas: would be good if you could subscribe to pharo list. If you fear the traffic then just disable mail forwarding and use the web archive to read. That's how I do it on all squeak related lists and it works fine. -------- Original-Nachricht -------- Datum: Tue, 07 Apr 2009 07:06:41 -0700 Von: Andreas Raab <XYZ(a)XYZ.de> An: Torsten Bergmann <XYZ(a)XYZ.de> CC: pharo-project(a)lists.gforge.inria.fr Betreff: Re: FFI in closure image/modifying block arguments I think it is advisable to allow block arg assignment for the time being. There is *lots* of code which uses it knowingly or unknowingly and unless you've fixed every single case you'll have these troubles every step of the way. For laughs, just try to recompile all the classes in your image to see how far you get. Cheers, - Andreas Torsten Bergmann wrote: > FYI: with the new closure changes/image (Pharo0.1Core-10268cl.zip from [1]) > it is not possible to store into block arguments: > > 1 to: 10 do: [:i | i := i + 1. Transcript show: i printString ] > > That makes the current version of FFI unloadable, due to > the code in ExternalTypeClass>>initializeAtomicTypes > > Bye > T. > > > [1] https://gforge.inria.fr/frs/?group_id=1299 -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

3 3

[Pharo-project] is the compiler threadsafe?
by StÃ©phane Ducasse April 7, 2009

April 7, 2009

Hi all I have a simple question. Is the compiler thread-safe? Stef

3 3

[Pharo-project] Pharo GemTools2.4 image and Seaside 2.8
by Dario Trussardi April 7, 2009

April 7, 2009

Hi All, i'm new to Pharo. I begin with GemtTolls 2.4 based on Pharo. I work to port some code development with Squeak2.3 ( Seaside Magritte ) to Gemstone. I load in the GemTools2.4 image DynamicBinding .47 KomServices .19 KomHttpServer .47 and Seaside2.8a1 .586. When from www i request the seaside page, it's answered ok by the system. After when open some other link seaside page, if it have submit button it not answer well. The scriptaculous page d'ont work fine. I can solve this problem? Any pointers would be greatly appreciated! Thanks! Dario

2 1

April 7, 2009

I checked Morph selectors size => 1000 in the image of juan => 600 then with ObjectsAsWrapper just opening some windows..... 320 so may be there is a hope. stef

1 0

April 7, 2009

Issue 719: Add setting test that are in the inbox SettingTest Takes into account Pragma setting and setting browser refactoring Support ProvideAnswerNotification for confirm and inform methods in PSUIManager. Issue 721: new tests for compiledMethod iv access Stef

1 0