June 2008 - Pharo-dev - lists.pharo.org

Re: Fwd: [Pharo-project] Pharo logos
by Bill Schwab June 14, 2008

June 14, 2008

The last one is pretty good. Someone noted (favorably) the lighthouse's being off-center. That is arguably _essential_ to having it look right. I suggest making the lettering a bit taller relative to the ring; you can probably kern to keep the horizontal dimension about the same as it is not w/o resorting to tall/skinny letters. It might be nice to have wiki page for this?? 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) 846-1285 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 06/14/08 6:29 AM >>> we were discussing with samuel about two logos one a bit clean and another one a bit more thrashy that could be used in different occasion. I like it Begin forwarded message: > From: Samuel MORELLO <samuel.morello(a)ouvanous.com> > Date: June 14, 2008 11:51:18 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] Pharo logos > > Comme ca ? > >

1 0

[Pharo-project] [updates] RootsOf is back + cleaning of norbert
by StÃ©phane Ducasse June 14, 2008

June 14, 2008

Next Damien on: Oscar tests cleaning Norbert nebraska cleaning Stef

1 1

[Pharo-project] DNU rootsOfTheWorld
by StÃ©phane Ducasse June 14, 2008

June 14, 2008

Once loaded the latest version and update When I open an environment to apply refactoring I get doesNotUnderstand: #rootsOfTheWorld Stef From: stephane.ducasse(a)inria.fr To: squeak-dev(a)lists.squeakfoundation.org Subject: [BUG]Class class(Object)>>doesNotUnderstand: #rootsOfTheWorld here insert explanation of what you were doing, suspect changes you've made and so forth. 13 June 2008 1:50:10 pm VM: Mac OS - a SmalltalkImage Image: Pharo0.1 [latest update: #10037] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /Users/ducasse/Desktop/Pharo/Pharo0.1-10036-2008-06-10 Trusted Dir /foobar/tooBar/forSqueak/bogus Untrusted Dir /Users/ducasse/Library/Preferences/Squeak/Internet/My Squeak Class class(Object)>>doesNotUnderstand: #rootsOfTheWorld Receiver: Class Arguments and temporary variables: aMessage: rootsOfTheWorld Receiver's instance variables: superclass: ClassDescription methodDict: a MethodDictionary(#addClassVarName:->a CompiledMethod (608) #addIn...etc... format: 156 instanceVariables: #('subclasses' 'name' 'classPool' 'sharedPools' 'environment...etc... organization: ('accessing' basicCategory basicCategory: basicLocalSelectors bas...etc... subclasses: an Array(ObjectTracer class PseudoContext class ProtoObject class) name: #Class classPool: a Dictionary() sharedPools: nil environment: a SystemDictionary(lots of globals) category: #'Kernel-Classes' traitComposition: TBehaviorCategorization localSelectors: an IdentitySet(#classPool: #sharing: #removeFromSystemUnlogged ...etc... BrowserEnvironment>>allClassesDo: Receiver: Smalltalk Arguments and temporary variables: aBlock: [] in BrowserEnvironment>>classesDo: {[:each | (self includesClass: eac...etc... each: nil Receiver's instance variables: label: nil searchStrings: nil BrowserEnvironment>>classesDo: Receiver: Smalltalk Arguments and temporary variables: aBlock: [] in BrowserEnvironment>>classesAndSelectorsDo: {[:class | self sele...etc... each: nil Receiver's instance variables: label: nil searchStrings: nil BrowserEnvironment>>classesAndSelectorsDo: Receiver: Smalltalk Arguments and temporary variables: aBlock: [] in OREnvironmentNode>>selectorEnvironment {[:class :selector | selec...etc... class: nil sel: nil Receiver's instance variables: label: nil searchStrings: nil --- The full stack --- Class class(Object)>>doesNotUnderstand: #rootsOfTheWorld BrowserEnvironment>>allClassesDo: BrowserEnvironment>>classesDo: BrowserEnvironment>>classesAndSelectorsDo: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - OREnvironmentNode>>selectorEnvironment ORSystemBrowser>>setMetaNode:node: ORSystemBrowser class(OBBrowser class)>>metaNode:root:selection:panels: ORSystemBrowser class(OBBrowser class)>>root:selection: ORSystemBrowser class(OBBrowser class)>>root: ORSystemBrowser class(OREnvironmentBrowser class)>>on: ORCmdSpawnEnvironment>>execute ORCmdSpawnEnvironment(OBCommand)>>perform:orSendTo: [] in MenuItemMorph>>invokeWithEvent: {[(selArgCount := selector numArgs) = 0 ifTrue: [target perform: selector] ...]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: MenuItemMorph>>invokeWithEvent: MenuItemMorph>>mouseUp: MenuItemMorph>>handleMouseUp: MouseButtonEvent>>sentTo: MenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuItemMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuMorph(Morph)>>processEvent:using: MenuMorph(Morph)>>processEvent: MenuMorph>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h processEvents. ActiveHand := nil]} Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor yield. false] whileFalse. nil]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]}

3 10

Fwd: [Pharo-project] Pharo logos
by StÃ©phane Ducasse June 14, 2008

June 14, 2008

we were discussing with samuel about two logos one a bit clean and another one a bit more thrashy that could be used in different occasion. I like it Begin forwarded message: > From: Samuel MORELLO <samuel.morello(a)ouvanous.com> > Date: June 14, 2008 11:51:18 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] Pharo logos > > Comme ca ? > > > > Le 14 juin 08 Ã 11:46, StÃ©phane Ducasse a Ã©crit : > >> je me demande si le pahre en noir ne ressortirait pas plus par >> rapport a la vague. >> >> Stef >> >> On Jun 14, 2008, at 10:32 AM, Samuel MORELLO wrote: >> >>> Voici une nouvelle planche >>> >>> On peu fonctionner avec un logo qui Ã deux versions en paralelle. >>> 1. Sans le rond : Net, reconnaissable et belle forme (pour moi en >>> tout cas) >>> 2. Avec le rond : CaractÃ¨re marquÃ©, pour les "brave programmers", >>> le rond est lÃ©gÃ©rement trash mais ca donne un bon caractÃ¨re (je me >>> repete ;-) >>> >>> >>> Apres je peux revenir sur une 3eme version type web 2 avec degradÃ© >>> et effets de lumiÃ¨re. >>> >>> Mais la base rÃ©elle du logo c'est le phare tout seul >>> >>> Qu'en pesnes tu ? >>> >>> Je pense que ca fonctionne pour ma part >>> >>> Je continue sur la version type web 2 comme la premiere version >>> bleue que j'ai fournie mais sur cette derniere base. >>> >>> Sam >>> >>> >>> >>> Le 14 juin 08 Ã 10:12, StÃ©phane Ducasse a Ã©crit : >>> >>>> moi j;aime bien le premier bleu >>>> si tu arrives a mettre un ou deux rayons cela serait interessant >>>> de voir. >>>> Mais c'est cool apres on va l'utiliser pour la vm et la distri + >>>> le site web youpi... >>>> Setf >>>> On Jun 14, 2008, at 9:58 AM, Samuel MORELLO wrote: >>>> >>>>> <pharo-0.6.1.pdf> >>>>> Bonjour, >>>>> >>>>> J'ai vu ce mail et je pense que les vagues donnent du caractÃ¨res >>>>> Qu'en pense tu ? >>>>> >>>>> Sam >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Pharo is not a paper lantern. >>>>>>> It is a lighthouse showing the way to brave programmers during >>>>>>> the tempest. >>>>>>> >>>> >>> >>> >> >

3 2

[Pharo-project] Messages sent but not implemented: how to
by Alain Plantec June 14, 2008

June 14, 2008

Hi, I've started to investigate on each SLint result (681 not implemented sent in my image). An obvious solution can be proposed for only few of them. Do I open an issue for each of them or ? thanks alain

2 1

[Pharo-project] Bug for harvesting
by Norbert Hartl June 14, 2008

June 14, 2008

Hi, I opened a bug a few minutes ago which you may find interesting for harvest. http://bugs.squeak.org/view.php?id=7090 Norbert

6 9

Fwd: [Pharo-project] Pharo logos
by StÃ©phane Ducasse June 14, 2008

June 14, 2008

Begin forwarded message: > From: Samuel MORELLO <samuel.morello(a)ouvanous.com> > Date: June 14, 2008 9:58:36 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] Pharo logos > > > Bonjour, > > J'ai vu ce mail et je pense que les vagues donnent du caractÃ¨res > Qu'en pense tu ? > > Sam > > >> >> >> >>> Pharo is not a paper lantern. >>> It is a lighthouse showing the way to brave programmers during the >>> tempest. >>>

1 0

[Pharo-project] Test message
by Pharo Smalltalk June 14, 2008

June 14, 2008

Sorry for the spam. I'm trying to set up automatic notification to the mailing list of wiki and issue comments, but it seems I can't get forwarding to work.. Saludos, Victor Rodriguez.

1 0

[Pharo-project] Pharo logos
by StÃ©phane Ducasse June 13, 2008

June 13, 2008

Hi guys here are some proposals I like the blue one. But there have something. Please comment Stef

9 12

Fwd: [Pharo-project] Pharo logos
by StÃ©phane Ducasse June 13, 2008

June 13, 2008

Begin forwarded message: > From: Samuel MORELLO <samuel.morello(a)ouvanous.com> > Date: June 13, 2008 1:27:25 PM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] Pharo logos > > > Le 13 juin 08 Ã 13:12, StÃ©phane Ducasse a Ã©crit : > >> >> >> Begin forwarded message: >> >>> From: Oscar Nierstrasz <oscar(a)iam.unibe.ch> >>> Date: June 13, 2008 12:29:32 PM CEDT >>> To: An open mailing list to discuss any topics related to an open- >>> source Smalltalk <pharo-project(a)lists.gforge.inria.fr> >>> Subject: Re: [Pharo-project] Pharo logos >>> Reply-To: An open mailing list to discuss any topics related to an >>> open-source Smalltalk <pharo-project(a)lists.gforge.inria.fr> >>> >>> >>> Cool graphics! >>> >>> But ... the first one looks too much like we are struggling in the >>> fog, and the last one looks like we are about to come under the >>> shadow of an eclipse (!). >>> >>> Is it possible to have the fog at the bottom, so the lighthouse is >>> emerging from the fog? >>> >>> - on >>> >>> On Jun 13, 2008, at 11:50, StÃ©phane Ducasse wrote: >>> >>>> Hi guys >>>> >>>> here are some proposals >>>> I like the blue one. But there have something. >>>> Please comment >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> <Picture 2.pdf><Picture 3.pdf><Picture >>>> 1.pdf>_______________________________________________ >>>> 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 3

[Pharo-project] ScriptLoader
by Norbert Hartl June 13, 2008

June 13, 2008

Can somebody explain me what benefit we gain by using ScriptLoader for updates? What can it do more/better than just plain changesets? Please have a look at http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129234.html How we like to deal with? Norbert

2 1

[Pharo-project] Broken tests
by Oscar Nierstrasz June 13, 2008

June 13, 2008

Just for phun, I ran all the tests in the Pharo image. There are only 13 failures, 2 expected failures, and no errors! I have started a page to give an overview: http://code.google.com/p/pharo/wiki/BrokenTests Please update this page with an appropriate comment if you are working on any of these (or if you fix them). - on

4 8

[Pharo-project] Improving the general quality of package
by StÃ©phane Ducasse June 12, 2008

June 12, 2008

Hi all I would really like to see if it make sense to run SmallLint on packages. Of course we should not naively apply the proposed refactoring (some blind applications of them in the past went against speed in Graphics), still identifying and building a process to produce a bit better code quality would be great. If any of you want to give a try it would be great. I'm also thinking about having a manifesto to each package or group of package so that we can attach information and metainformation to package such as documentation... So far I'm not happy with what I did (cf DrDoc but this is one step in that direction). Stef

1 0

[Pharo-project] Strange bug in TraitsTest
by Norbert Hartl June 12, 2008

June 12, 2008

If you open a test runner and select only KernelTests-ClassTest and TraitsTests-TraitsTestCase you may find a failure ClassTest>>testRootsOfTheWorld But I don't understand fully why it appears. I had once the chance to get a debugger on the failure (which does usually not work on this failure) and so I know that the rootsOfTheWorld (which is usually 3) is 6 in size containing additionally classes C3 C4 and C6. The ones which are created by TraitsTestCase (see my last mail "Bug for harvest"). They all have a superclass of nil but they aren't included in the SystemNavigation. (conditions for being included in the rootsOfTheWorld) If you press "Run selected" again the same error occurrs while pressing "Run failures" gives you all green (ok, it is this way in my case) And I can't reproduce the same in a 3.10 image. It seems that there is a timing problem involved. Selecting only the two test cases I get the failure every time (or nearly). Selecting all tests it appears only at random. Any hints? Norbert

4 8

[Pharo-project] Fwd: Comment on BrokenTests in pharo
by Pharo Smalltalk June 12, 2008

June 12, 2008

---------- Forwarded message ---------- From: <codesite-noreply(a)google.com> Date: Thu, Jun 12, 2008 at 3:16 AM Subject: Comment on BrokenTests in pharo To: pharo.smalltalk(a)gmail.com Comment by andreas.raab: 3.9 has a different manifest bit pattern for NaN than Pharo. Try this: Float nan hex "<print it>" 3.9: '7FF8000000000000' Pharo: 'FFF8000000000000' It looks like 3.9 was initialized on PPC, Pharo on Intel. Since there is an infinite number of NaN bit patterns the real solution is to use a manifest binary constant in Float initialization, i.e, Float class>>initialize "..." NaN := Float with: 16rFFF80000 with: 0. instead of the computation that is in there today. For more information: http://code.google.com/p/pharo/wiki/BrokenTests

1 0

[Pharo-project] Which tests broken in Phrao are also broken in 3.9 and 3.10
by Oscar Nierstrasz June 12, 2008

June 12, 2008

I checked all the broken tests. It seems that there are some fixes that we should be able to harvest from 3.10. http://code.google.com/p/pharo/wiki/BrokenTests - on

1 0

[Pharo-project] [ANN] New release
by StÃ©phane Ducasse June 12, 2008

June 12, 2008

We are happy to produce a new release. It includes: trait simplification, nebraska removal, MVC removal preparation, tests fixed (float array), semaphore fixes, ... Thanks alain, adrian, norbert, serge and other for their time. Stef Here is the log: update10028 Fixing MC ------------------------------------------------------ update10030 Fixing Delay 0006834: Delay class>>timeoutSemaphore:afterMSecs: doesn t. Description The implementation for Delay class>>timeoutSemaphore:afterMSecs: doesn t even use its first parameter, so it can t do what it says it does. This method should be deprecated or removed entirely. Additional Information + tests Fixing Obsolete references ------------------------------------------------------ withUdpateLog: 1.0 / (FloatArray with: 2.0) answer unexpected result. Bug is in FloatArray>>adaptToNumber:andSend: See : http://bugs.squeak.org/view.php?id=6782 fixing files left by tests ------------------------------------------------------ update10032 Fixing Number parsing Cleaning nebraska ------------------------------------------------------ update10033 Simplifying Traits usage in kernel Simplifying Traits usage in kernel ------------------------------------------------------ update10034 Fixing tests (serge stinckwich) http://bugs.squeak.org/view.php?id=6936 #asHTMLColor is inaccurate for certain values. Attached fix resolves that, also gives 10x speed-up. ------------------------------------------------------ update10035 Merging MVC removal step one of Alain Plantec ------------------------------------------------------ update10036 Merging MVC removal step one of Alain Plantec (missing part)

6 14

[Pharo-project] Trait recent change
by Damien Cassou June 12, 2008

June 12, 2008

Hi, I'm building a new pharo dev and get a message about missing TCommentDescription. Is it normal? -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

2 2

[Pharo-project] Pharo, squeak and the tickets
by Norbert Hartl June 12, 2008

June 12, 2008

I had a look at the tickets in the google tracker. A lot of them appear to me that they belong to squeak as well. I'm quite unsure what would be the best way to deal with both sides (pharo and squeak) because there are bugs found through working on pharo that belong to squeak as well. On the other hand we harvest things from squeak. What would you prefer? 1. Opening issues where they belong first and let "the others" harvest what they think they need? 2. Playing back the issues to bugs.squeak.org if we find a bug that belongs also to squeak and bring them back by harvesting? How do we want to harvest fixes from other places? 1. Having a wiki page where issues found are written down? 2. Opening tickets on the google tracker for this? This would be "to harvest" tickets. Norbert

4 3

[Pharo-project] KernelTests green
by Oscar Nierstrasz June 12, 2008

June 12, 2008

I have posted some patches to the inbox to make the Kernel Number tests run, and in the Issues page I propose to delete a bunch of nonsensical testHash tests. With these changes the Kernel tests should all be green. - on

4 11

[Pharo-project] Fwd: Comment on BrokenTests in pharo
by Pharo Smalltalk June 12, 2008

June 12, 2008

My apologies if this message is forwarded to the list twice. Victor Rodriguez. ---------- Forwarded message ---------- From: <codesite-noreply(a)google.com> Date: Wed, Jun 11, 2008 at 12:05 PM Subject: Comment on BrokenTests in pharo To: pharo.smalltalk(a)gmail.com Comment by oscar.nierstrasz: FloatTests>>#testNaN5 currently reads as follows: {{{ testNaN5 "self assert: (Float nan asIEEE32BitWord printPaddedWith: $0 to: 32 base: 2) = '01111111110000000000000000000000'." ... }}} I believe this is over-specified. Instead it should just read as follows: {{{ testNaN5 self assert: ((Float nan asIEEE32BitWord printPaddedWith: $0 to: 32 base: 2) copyFrom: 2 to: 9) = '11111111'. ... }}} This would be consistent with the NaN spec (according to wikipedia). However it does not explain why these tests pass in 3.9 and 3.10. Have there been changes in the VM to the way that Floats are represented? For more information: http://code.google.com/p/pharo/wiki/BrokenTests

1 0

[Pharo-project] New pharo-dev based on latest release
by Damien Cassou June 11, 2008

June 11, 2008

I've just published a new pharo-dev based on 10036: https://gforge.inria.fr/frs/download.php/4978/pharo0.1-10036dev08.06.2.zip -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

3 6

[Pharo-project] HaveALookAt
by Norbert Hartl June 11, 2008

June 11, 2008

I think the link to the packages issue should point to http://www.squeaksource.com/PackagesForSqueak/ Norbert

4 3

[Pharo-project] MVC removal step2 investigations
by Alain Plantec June 11, 2008

June 11, 2008

Hi all, below is given a minute that briefly describes what I suggest for MVC removal. It's an aggressive update especially because a lot of classes are removed. (see all *ST80* system categories before and after having applied the patch and see Controller hierarchy also) I've attached the .cs. Maybe you can make a try and give your opinion. thanks alain MVC removal step2 proposition 1 : * Object>>couldOpenInMorphic : senders updated and method set as deprecated (as for Project>>isMorphic and SystemDictionary>>isMorphic) * Remove method openAsMVC and openInMVC * ST80-Editors system category seems removeable o BitEditor, FormEditor and al : are strongly related to MVC and seems not used * ScheduledControllers : o Remove all methods which are referencing it, this leads to remove class ControlManager; o Remove ControlManager refs in SystemDictionary>>initialize and o cleanup StartUpList and ShutDownList SystemDictionary class variables with a script. * ST80-Framework system category seems removeable o View class seems removable (see ST80-Views system category point) o Then, ModalController, NoController are not referenced anymore, they can be removed o WindowingTransformation is only used by GraphicSymbolInstance which is removable (see ST80-Symbols system category point) * ST80-Views system category can be removed: o StandardSystemView>>Comment: "I represent a view that has a label above its top left corner. The text in the label identifies the kind of view. In addition to a label, I add control over the maximum and minimum size of the display box of my instance. My default controller is StandardSystemController. The elements of ScheduledControllers, the sole instance of ControlManager, are usually controllers for instances of me". o StandardSystemView hierarchy seems removable, (subclasses are ColorSystemView, ModalSystemWindowView, PluggableFileListView and ProjectView ) o MorphWorldView class removed * ST80-Pluggable Views system category o PluggableListView removed * ST80-Symbols system category seems removable o GraphicSymbol and GraphicSymbolInstance are not refed and have no instance, seems removable * WorldViewModel, MVCWiWPasteUpMorph, MorphWorldController and CautiousModel: all these classes are not used, to be removed o MorphicExtras-ST80 system category is then removed * ST80-Support system category o StandardSystemController class>>initialize removed: it only initialize unused class variables HBorderCursor, ScheduledBlueButtonMenu ScheduledBlueButtonMessages and VBorderCursor (these class variables are removed) o StandardSystemController: remove all methods that are related to view (mvc view) o StandardSystemController: class seems to be unused, therefore removed o FillInTheBlankController: class removed o ColorSystemView: class removed * ST80-Kernel-Remnants o Controller and its subclasses: remove all methods that are related to view (mvc view) o Controler: MinActivityLapse class variable seems unused o ControlManager seems removeable o ScrollController seems removeable o MouseMenuController seems removeable * Remove all view classes refs: o SelectorBrowser>>classListIndex: depends on PluggableListView o Browser>>couldBrowseAnyClass depends on PluggableListView * Kernel-ST80 Remnants o ParagraphEditor and TextMorphEditor: kept but have to be cleaned up * ST80-Pluggable Views system category removed * Preferences o removed #mvcProjectsAllowed from flags dictionary * MorphicExtras-ST80 o MorphWorldController class removed * ParagraphEditor o made direct subclass of Controller (get rid of MouseMenuController) o renoved view instance variable o TextMorphEditor is the unique ParagraphEditor subclass, maybe we should only have one class now (ParagraphEditor was more for mvc ?)

1 0

[Pharo-project] Harvesting some fixes
by StÃ©phane Ducasse June 11, 2008

June 11, 2008

Hi all I will harvest the MVC cleaning step one. I harvested some changes. I suggest you to reload 10034. because of some manipulations I did with the scriptloader

2 2

[Pharo-project] self halt in RxParserTest>>testMatchesInwW
by Oscar Nierstrasz June 11, 2008

June 11, 2008

Stef, RxParserTest>>testMatchesInwW has a self halt in it dating from 2006, apparently added by you. I guess you should remove it ... The test runs fine otherwise. - on

3 5

Re: [Pharo-project] Who is working on which tests? Why are there new, broken tests?
by Bill Schwab June 10, 2008

June 10, 2008

Is your concern that the new tests are broken (which seems normal to me that they would start out that way), or are you objecting to their being included in the image? I can see arguments either way on the latter. If code in the image is wrong and a clearly correct but currently failing test highlights it, I'd rather be alerted to it. You are also correct that having them included draws attention that could easily encourage duplication of effort. Comments? 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) 846-1285 FAX: (352) 392-7029 >>> oscar(a)iam.unibe.ch 06/10/08 8:31 AM >>> I looked at the wiki page http://code.google.com/p/pharo/wiki/CurrentlyWorkingOn but it does not say much. I would like to work through some tests, but I cannot find an overview. The tests CharacterTest>>testHex and IntegerTest>>testHex are broken but seem to be very new. Stef, are you working on these? You seem to have written the tests ... - on _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 10

[Pharo-project] [ANN] test fixes + MVC cleaning step one
by StÃ©phane Ducasse June 10, 2008

June 10, 2008

Hi guys I harvested the MVC step one changes of Alain Plantec Next the on: of damien. PS: I'm checking the hex problem by rebuilding my image from the latest image available. Stef

1 1

Re: [Pharo-project] Who is working on which tests? Why are there new, broken tests?
by Bill Schwab June 10, 2008

June 10, 2008

But if the test is revealing a true flaw in the system, better to keep it than to remove it and pat ourselves on the back about "all tests passing." 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) 846-1285 FAX: (352) 392-7029 >>> oscar(a)iam.unibe.ch 06/10/08 10:00 AM >>> Well, I thought we would start to fix the existing broken tests before adding new broken tests. I would also be very happy to see some comments when someone adds a new broken test, so I know what the plan is. Now I added an implementation of Integer>>hex, for example, but I am not so sure why we need this. Ain't too many senders. An easier fix would have been to remove the broken test. Cheers, - on On Jun 10, 2008, at 15:53, Bill Schwab wrote: > Is your concern that the new tests are broken (which seems normal to > me > that they would start out that way), or are you objecting to their > being > included in the image? > > I can see arguments either way on the latter. If code in the image is > wrong and a clearly correct but currently failing test highlights it, > I'd rather be alerted to it. You are also correct that having them > included draws attention that could easily encourage duplication of > effort. > > Comments? > > 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) 846-1285 > FAX: (352) 392-7029 > >>>> oscar(a)iam.unibe.ch 06/10/08 8:31 AM >>> > > I looked at the wiki page > http://code.google.com/p/pharo/wiki/CurrentlyWorkingOn > but it does not say much. > > I would like to work through some tests, but I cannot find an > overview. > > The tests CharacterTest>>testHex and IntegerTest>>testHex are broken > but seem to be very new. Stef, are you working on these? You seem to > have written the tests ... > > - on > > > _______________________________________________ > 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] Why does Installer package stay dirty?
by Oscar Nierstrasz June 10, 2008

June 10, 2008

When I update a pharo-dev image, I see that Installer still has updates. However I cannot update this consistently. If I load Installer-sd.4.mcz then Installer-dc.4.mcz is highlighted. One of these two should be deleted, I think. Which one? - on

2 1

[Pharo-project] Who is working on which tests? Why are there new, broken tests?
by Oscar Nierstrasz June 10, 2008

June 10, 2008

I looked at the wiki page http://code.google.com/p/pharo/wiki/CurrentlyWorkingOn but it does not say much. I would like to work through some tests, but I cannot find an overview. The tests CharacterTest>>testHex and IntegerTest>>testHex are broken but seem to be very new. Stef, are you working on these? You seem to have written the tests ... - on

3 3

[Pharo-project] What is ScheduledControllers?
by Oscar Nierstrasz June 10, 2008

June 10, 2008

I was looking at http://code.google.com/p/pharo/issues/detail?id=6 and discovered this is broken because StandardSystemView sends to ScheduledControllers which does not exist. I googled for it and found it seems sometimes to be a class and sometimes a global. Anyway it does not exist. Anyone know where it came from? - on

3 3

[Pharo-project] fix Utilities offerCommonRequests -> UIEnvironment class
by Oscar Nierstrasz June 10, 2008

June 10, 2008

Stef, This is one of yours. UIEnvironment does not exist. Are you proposing to split up Utilities and move a lot of these utility-like this to a new utility class called UIEnvironment? What is the motivation/rationale? I do not see what problem is solved by introducing another utility class. Should the new class also stay in the System-Support category? - on

2 1

[Pharo-project] fix Utilities classFromPattern:withCaption: -> Browser
by Oscar Nierstrasz June 10, 2008

June 10, 2008

Damien, I do not understand this issue. http://code.google.com/p/pharo/issues/detail?id=2 Example doit: Utilities classFromPattern: 'orph' withCaption: 'Morphs' This generates a menu with the caption as heading. The name of the selected class is returned. I do not understand the issue here. The following code will fire up a browser. (Utilities classFromPattern: 'orph' withCaption: 'Morphs') browse WHat needs to be fixed? - on

2 2

[Pharo-project] Are wiki comments making it to the list?
by Victor Rodriguez June 10, 2008

June 10, 2008

Hello, I'm not sure comments added to wiki pages are making it to the site. Could it be that the list does not accept email from non-subscribers? If so, could someone please "subscribe" or otherwise "whitelist" codesite-noreply(a)google.com? Thanks, VÃctor RodrÃguez.

1 0

[Pharo-project] HaveALootAt -> HaveALookAt -- where are the open tasks?
by Oscar Nierstrasz June 9, 2008

June 9, 2008

I guess this page should be called "HaveALookAt" but I do not see how to rename a wiki page. Anybody know how to do this? http://code.google.com/p/pharo/wiki/HaveALootAt Where is the list of open tasks? I thought it might be here. - on

3 7

[Pharo-project] editing pharo home page?
by Oscar Nierstrasz June 9, 2008

June 9, 2008

How do I edit the Pharo home page? http://code.google.com/p/pharo/ I see no edit button. - on

2 1

June 9, 2008

- Adrian trait core cleaning. - Serge fixing tests I plan to harvest on: and MVC clean up. and some graphics test cleaning. stef

2 2

June 8, 2008

Hi all Beside cleaning the system I would like Pharo to be inventive and cooler. Here are a list of thoughts where I would like to see some efforts: Note that they are related to the milestone list http://code.google.com/p/pharo/wiki/Milestones Please have a look and see how you can contribute. - I plan to finish DrDoc. - I would like to have some mechanisms to deprecated classes. - first class packages. Then it would be good to have a look at the 3.10 fixes. Feedback is welcome. Stef

1 0

Re: [Pharo-project] About on:
by Bill Schwab June 8, 2008

June 8, 2008

Hello all, You will find a first draft of the proposal on the Wiki. It needs some more work, but should suffice as a start. 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) 846-1285 FAX: (352) 392-7029 >>> victorr(a)gmail.com 06/08/08 10:19 AM >>> On Sun, Jun 8, 2008 at 9:20 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Damien, > > I saw and replied to Victor's invitation first, so we should probably just wait for him to do it. I have added you as a member. Best Regards, VÃctor RodrÃguez. > Thanks! > > 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) 846-1285 > FAX: (352) 392-7029 > >>>> damien.cassou(a)gmail.com 06/07/08 2:18 PM >>> > Just send me your google email address and I will add you. > > On Fri, Jun 6, 2008 at 10:01 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: >> Stef, >> >> I appear to have a working google account, and it seems willing to let >> me add comments to wiki pages. Is there more to do to enable me to >> edit? >> >> 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) 846-1285 >> FAX: (352) 392-7029 >> >> >>>>> stephane.ducasse(a)inria.fr 6/6/2008 1:53:17 PM >>> >> Yes bill I think that this is important that we get one page with the >> >> proposal >> because we should find a way to make progress. >> May be with a stream factory or other method names as you suggest (if >> >> I understand correctly) >> This is important that we do not lose the ideas and proposal. >> >> Stef >> >> On Jun 6, 2008, at 6:49 PM, Victor Rodriguez wrote: >> >>> On Fri, Jun 6, 2008 at 9:46 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> >> >>> wrote: >>>> Lukas, >>>> >>>> Re "I hope that we do not have to implement our own stream >>>> hierarchy as >>>> well." >>>> >>>> I do not intend to be confrontational, but you are over-reacting. >>>> Nothing I am proposing would force you to create a stream >> hierarchy. >>>> Worry not, as I do not see my proposal being accepted anyway. I >> will >>>> simply add protocol that meets my needs, convert to it, and move >> on. >>> >>> Perhaps the Pharo project is not yet ready for your proposal, with >> so >>> many things yet to be done, but who knows what might happen in the >>> future? What about documenting your proposal in the wiki? >>> >>> Best Regards, >>> >>> Victor Rodriguez. >>> >>> >>>> If by your proposal, you mean relying on a default action to >> preserve >>>> behavior, that is not a solution. The whole point of exceptions is >> >>>> to >>>> fail loudly vs. (potentially) passing garbage into code that might >> or >>>> might not recognize what happened. The default action makes it too >> >>>> easy >>>> to miss. The very thing that keeps you happy subjects my customers >> >>>> to >>>> risk that I consider to be unacceptable, especially given that >>>> there are >>>> simple (if tedious) solutions that will avoid the problem. >>>> >>>> My particular RB limitations are based on what is built into >> Dolphin, >>>> and an old version at that. I need to see what Damien has on >>>> offer. My >>>> understanding is that the "comment abuse" is greatly reduced >>>> relative to >>>> what I have experienced. Failing that, there are other text- >>>> processing >>>> methods. >>>> >>>> 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) 846-1285 >>>> FAX: (352) 392-7029 >>>> >>>>>>> renggli(a)gmail.com 06/06/08 9:13 AM >>> >>>>> The changes I propose would be almost trivial for them to adopt, >> and >>>>> might actually make their lives easier in targeting Dolphin, >> should >>>> they >>>>> wish to do so. >>>> >>>> Yes, I agree. The rewrite engine can fix all these things. >>>> >>>>> All arguments in favor of preserving current behavior have been >>>>> based >>>> on >>>>> backward compatibility - nothing on merits. >>>> >>>> I am only saying that keeping things backward compatible in >> critical >>>> position makes everything easier. Frankly, I like the solution I >>>> proposed and that apparently other people have thought out as well. >>>> You can use both semantics, depending on what makes more sense in >>>> your >>>> context. And best of all, it does not break existing code. I am >>>> missing a reason why Alan Knight think this solution is not good. >>>> >>>>> or Seaside, I would certainly keep Seaside going, though I suspect >>>> the >>>>> Seaside developers would accomodate us in trying to align the >>>> dialects. >>>> >>>> We never forced anybody to align their dialect. If possible, we >>>> always >>>> changed our own code. We introduced compatibility layers that >> porters >>>> can fill or we simply built our own classes. I hope that we do not >>>> have to implement our own stream hierarchy as well. >>>> >>>>> [*] I assume that I will write Dolphin code to export something >> that >>>>> Pharo can load. If any of you know of a good solution to that >>>> problem, >>>>> please let me know. In case you are wondering why the renaming is >>>> all >>>>> done in Pharo, it is because it hopefully does a better job of >>>> leaving >>>>> formatting in tact - D5's version of the RB is fairly hostile in >>>>> that >>>>> regard. >>>> >>>> The rewrite engine in Squeak/Pharo reformats all code it touches. >>>> VisualWorks has some improvements in that area. I discussed with >> John >>>> Brant and he said that these improvements are part of the >> open-source >>>> refactoring browser, however the problem is that Cincom modified >> the >>>> code and that the original improvements are not part of the >> download >>>> on John's website. Therefor it is not clear, what code is clean and >>>> what code is commercial. >>>> >>>> Cheers, >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> http://www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> 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 >> >>>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > _______________________________________________ > 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 > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] About on:
by Bill Schwab June 8, 2008

June 8, 2008

Damien, I saw and replied to Victor's invitation first, so we should probably just wait for him to do it. Thanks! 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) 846-1285 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 06/07/08 2:18 PM >>> Just send me your google email address and I will add you. On Fri, Jun 6, 2008 at 10:01 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Stef, > > I appear to have a working google account, and it seems willing to let > me add comments to wiki pages. Is there more to do to enable me to > edit? > > 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) 846-1285 > FAX: (352) 392-7029 > > >>>> stephane.ducasse(a)inria.fr 6/6/2008 1:53:17 PM >>> > Yes bill I think that this is important that we get one page with the > > proposal > because we should find a way to make progress. > May be with a stream factory or other method names as you suggest (if > > I understand correctly) > This is important that we do not lose the ideas and proposal. > > Stef > > On Jun 6, 2008, at 6:49 PM, Victor Rodriguez wrote: > >> On Fri, Jun 6, 2008 at 9:46 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> > >> wrote: >>> Lukas, >>> >>> Re "I hope that we do not have to implement our own stream >>> hierarchy as >>> well." >>> >>> I do not intend to be confrontational, but you are over-reacting. >>> Nothing I am proposing would force you to create a stream > hierarchy. >>> Worry not, as I do not see my proposal being accepted anyway. I > will >>> simply add protocol that meets my needs, convert to it, and move > on. >> >> Perhaps the Pharo project is not yet ready for your proposal, with > so >> many things yet to be done, but who knows what might happen in the >> future? What about documenting your proposal in the wiki? >> >> Best Regards, >> >> Victor Rodriguez. >> >> >>> If by your proposal, you mean relying on a default action to > preserve >>> behavior, that is not a solution. The whole point of exceptions is > >>> to >>> fail loudly vs. (potentially) passing garbage into code that might > or >>> might not recognize what happened. The default action makes it too > >>> easy >>> to miss. The very thing that keeps you happy subjects my customers > >>> to >>> risk that I consider to be unacceptable, especially given that >>> there are >>> simple (if tedious) solutions that will avoid the problem. >>> >>> My particular RB limitations are based on what is built into > Dolphin, >>> and an old version at that. I need to see what Damien has on >>> offer. My >>> understanding is that the "comment abuse" is greatly reduced >>> relative to >>> what I have experienced. Failing that, there are other text- >>> processing >>> methods. >>> >>> 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) 846-1285 >>> FAX: (352) 392-7029 >>> >>>>>> renggli(a)gmail.com 06/06/08 9:13 AM >>> >>>> The changes I propose would be almost trivial for them to adopt, > and >>>> might actually make their lives easier in targeting Dolphin, > should >>> they >>>> wish to do so. >>> >>> Yes, I agree. The rewrite engine can fix all these things. >>> >>>> All arguments in favor of preserving current behavior have been >>>> based >>> on >>>> backward compatibility - nothing on merits. >>> >>> I am only saying that keeping things backward compatible in > critical >>> position makes everything easier. Frankly, I like the solution I >>> proposed and that apparently other people have thought out as well. >>> You can use both semantics, depending on what makes more sense in >>> your >>> context. And best of all, it does not break existing code. I am >>> missing a reason why Alan Knight think this solution is not good. >>> >>>> or Seaside, I would certainly keep Seaside going, though I suspect >>> the >>>> Seaside developers would accomodate us in trying to align the >>> dialects. >>> >>> We never forced anybody to align their dialect. If possible, we >>> always >>> changed our own code. We introduced compatibility layers that > porters >>> can fill or we simply built our own classes. I hope that we do not >>> have to implement our own stream hierarchy as well. >>> >>>> [*] I assume that I will write Dolphin code to export something > that >>>> Pharo can load. If any of you know of a good solution to that >>> problem, >>>> please let me know. In case you are wondering why the renaming is >>> all >>>> done in Pharo, it is because it hopefully does a better job of >>> leaving >>>> formatting in tact - D5's version of the RB is fairly hostile in >>>> that >>>> regard. >>> >>> The rewrite engine in Squeak/Pharo reformats all code it touches. >>> VisualWorks has some improvements in that area. I discussed with > John >>> Brant and he said that these improvements are part of the > open-source >>> refactoring browser, however the problem is that Cincom modified > the >>> code and that the original improvements are not part of the > download >>> on John's website. Therefor it is not clear, what code is clean and >>> what code is commercial. >>> >>> Cheers, >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> 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 > >>> >> >> _______________________________________________ >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Re: [Pharo-project] About on:
by Bill Schwab June 7, 2008

June 7, 2008

Stef, I appear to have a working google account, and it seems willing to let me add comments to wiki pages. Is there more to do to enable me to edit? 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) 846-1285 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 6/6/2008 1:53:17 PM >>> Yes bill I think that this is important that we get one page with the proposal because we should find a way to make progress. May be with a stream factory or other method names as you suggest (if I understand correctly) This is important that we do not lose the ideas and proposal. Stef On Jun 6, 2008, at 6:49 PM, Victor Rodriguez wrote: > On Fri, Jun 6, 2008 at 9:46 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> > wrote: >> Lukas, >> >> Re "I hope that we do not have to implement our own stream >> hierarchy as >> well." >> >> I do not intend to be confrontational, but you are over-reacting. >> Nothing I am proposing would force you to create a stream hierarchy. >> Worry not, as I do not see my proposal being accepted anyway. I will >> simply add protocol that meets my needs, convert to it, and move on. > > Perhaps the Pharo project is not yet ready for your proposal, with so > many things yet to be done, but who knows what might happen in the > future? What about documenting your proposal in the wiki? > > Best Regards, > > Victor Rodriguez. > > >> If by your proposal, you mean relying on a default action to preserve >> behavior, that is not a solution. The whole point of exceptions is >> to >> fail loudly vs. (potentially) passing garbage into code that might or >> might not recognize what happened. The default action makes it too >> easy >> to miss. The very thing that keeps you happy subjects my customers >> to >> risk that I consider to be unacceptable, especially given that >> there are >> simple (if tedious) solutions that will avoid the problem. >> >> My particular RB limitations are based on what is built into Dolphin, >> and an old version at that. I need to see what Damien has on >> offer. My >> understanding is that the "comment abuse" is greatly reduced >> relative to >> what I have experienced. Failing that, there are other text- >> processing >> methods. >> >> 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) 846-1285 >> FAX: (352) 392-7029 >> >>>>> renggli(a)gmail.com 06/06/08 9:13 AM >>> >>> The changes I propose would be almost trivial for them to adopt, and >>> might actually make their lives easier in targeting Dolphin, should >> they >>> wish to do so. >> >> Yes, I agree. The rewrite engine can fix all these things. >> >>> All arguments in favor of preserving current behavior have been >>> based >> on >>> backward compatibility - nothing on merits. >> >> I am only saying that keeping things backward compatible in critical >> position makes everything easier. Frankly, I like the solution I >> proposed and that apparently other people have thought out as well. >> You can use both semantics, depending on what makes more sense in >> your >> context. And best of all, it does not break existing code. I am >> missing a reason why Alan Knight think this solution is not good. >> >>> or Seaside, I would certainly keep Seaside going, though I suspect >> the >>> Seaside developers would accomodate us in trying to align the >> dialects. >> >> We never forced anybody to align their dialect. If possible, we >> always >> changed our own code. We introduced compatibility layers that porters >> can fill or we simply built our own classes. I hope that we do not >> have to implement our own stream hierarchy as well. >> >>> [*] I assume that I will write Dolphin code to export something that >>> Pharo can load. If any of you know of a good solution to that >> problem, >>> please let me know. In case you are wondering why the renaming is >> all >>> done in Pharo, it is because it hopefully does a better job of >> leaving >>> formatting in tact - D5's version of the RB is fairly hostile in >>> that >>> regard. >> >> The rewrite engine in Squeak/Pharo reformats all code it touches. >> VisualWorks has some improvements in that area. I discussed with John >> Brant and he said that these improvements are part of the open-source >> refactoring browser, however the problem is that Cincom modified the >> code and that the original improvements are not part of the download >> on John's website. Therefor it is not clear, what code is clean and >> what code is commercial. >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 1

[Pharo-project] Wiki pages moved to http://code.google.com/p/pharo/
by Victor Rodriguez June 7, 2008

June 7, 2008

Hello all, I have "moved" all the wiki pages from the INRIA gforge wiki to the google code one. I believe I got all the pages, but it won't hurt if someone can double check, which will be very easy, because I left a "wiki has moved" message in all moved pages. I did some very minor cleanup, mostly making sure lists and links appear correctly, but most pages still need to be fixed. Please help cleaning up the new wiki! I suggest for us to be very aggressive on keeping the wiki in a good shape. On second thought, make that *very very* aggresive :-). I know it is a lot of work, but there is nothing worse than a messy wiki. Conversely, nothing speaks better of an open source project than a clean and useful wiki. Ã votre service, VÃctor RodrÃguez.

4 7

Re: [Pharo-project] About on:
by Bill Schwab June 6, 2008

June 6, 2008

Lukas, Re "I hope that we do not have to implement our own stream hierarchy as well." I do not intend to be confrontational, but you are over-reacting. Nothing I am proposing would force you to create a stream hierarchy. Worry not, as I do not see my proposal being accepted anyway. I will simply add protocol that meets my needs, convert to it, and move on. If by your proposal, you mean relying on a default action to preserve behavior, that is not a solution. The whole point of exceptions is to fail loudly vs. (potentially) passing garbage into code that might or might not recognize what happened. The default action makes it too easy to miss. The very thing that keeps you happy subjects my customers to risk that I consider to be unacceptable, especially given that there are simple (if tedious) solutions that will avoid the problem. My particular RB limitations are based on what is built into Dolphin, and an old version at that. I need to see what Damien has on offer. My understanding is that the "comment abuse" is greatly reduced relative to what I have experienced. Failing that, there are other text-processing methods. 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) 846-1285 FAX: (352) 392-7029 >>> renggli(a)gmail.com 06/06/08 9:13 AM >>> > The changes I propose would be almost trivial for them to adopt, and > might actually make their lives easier in targeting Dolphin, should they > wish to do so. Yes, I agree. The rewrite engine can fix all these things. > All arguments in favor of preserving current behavior have been based on > backward compatibility - nothing on merits. I am only saying that keeping things backward compatible in critical position makes everything easier. Frankly, I like the solution I proposed and that apparently other people have thought out as well. You can use both semantics, depending on what makes more sense in your context. And best of all, it does not break existing code. I am missing a reason why Alan Knight think this solution is not good. > or Seaside, I would certainly keep Seaside going, though I suspect the > Seaside developers would accomodate us in trying to align the dialects. We never forced anybody to align their dialect. If possible, we always changed our own code. We introduced compatibility layers that porters can fill or we simply built our own classes. I hope that we do not have to implement our own stream hierarchy as well. > [*] I assume that I will write Dolphin code to export something that > Pharo can load. If any of you know of a good solution to that problem, > please let me know. In case you are wondering why the renaming is all > done in Pharo, it is because it hopefully does a better job of leaving > formatting in tact - D5's version of the RB is fairly hostile in that > regard. The rewrite engine in Squeak/Pharo reformats all code it touches. VisualWorks has some improvements in that area. I discussed with John Brant and he said that these improvements are part of the open-source refactoring browser, however the problem is that Cincom modified the code and that the original improvements are not part of the download on John's website. Therefor it is not clear, what code is clean and what code is commercial. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2

[Pharo-project] 40 kb limt on Mails
by Norbert Hartl June 6, 2008

June 6, 2008

Hi, I sent a mail yesterday evening that was about 43 kb in size (I've attached a changeset). The list sent me a notice that the maximum limit on this list is 40kb and it waits for approval of the list admin. Is that a feasible size if you take into account that there can be changeset that some sends to the list? Who is this list admin? Stephane? Norbert

2 1

Re: [Pharo-project] About on:
by Bill Schwab June 6, 2008

June 6, 2008

Victor, I will be happy to do that, as soon as I figure out how to get access to it :) Marginal attempts at humor not withstanding, I need to update my web page links to make things easier on me - hopefully that will happen today. 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) 846-1285 FAX: (352) 392-7029 >>> victorr(a)gmail.com 6/6/2008 11:49 AM >>> On Fri, Jun 6, 2008 at 9:46 AM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Lukas, > > Re "I hope that we do not have to implement our own stream hierarchy as > well." > > I do not intend to be confrontational, but you are over-reacting. > Nothing I am proposing would force you to create a stream hierarchy. > Worry not, as I do not see my proposal being accepted anyway. I will > simply add protocol that meets my needs, convert to it, and move on. Perhaps the Pharo project is not yet ready for your proposal, with so many things yet to be done, but who knows what might happen in the future? What about documenting your proposal in the wiki? Best Regards, Victor Rodriguez. > If by your proposal, you mean relying on a default action to preserve > behavior, that is not a solution. The whole point of exceptions is to > fail loudly vs. (potentially) passing garbage into code that might or > might not recognize what happened. The default action makes it too easy > to miss. The very thing that keeps you happy subjects my customers to > risk that I consider to be unacceptable, especially given that there are > simple (if tedious) solutions that will avoid the problem. > > My particular RB limitations are based on what is built into Dolphin, > and an old version at that. I need to see what Damien has on offer. My > understanding is that the "comment abuse" is greatly reduced relative to > what I have experienced. Failing that, there are other text-processing > methods. > > 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) 846-1285 > FAX: (352) 392-7029 > >>>> renggli(a)gmail.com 06/06/08 9:13 AM >>> >> The changes I propose would be almost trivial for them to adopt, and >> might actually make their lives easier in targeting Dolphin, should > they >> wish to do so. > > Yes, I agree. The rewrite engine can fix all these things. > >> All arguments in favor of preserving current behavior have been based > on >> backward compatibility - nothing on merits. > > I am only saying that keeping things backward compatible in critical > position makes everything easier. Frankly, I like the solution I > proposed and that apparently other people have thought out as well. > You can use both semantics, depending on what makes more sense in your > context. And best of all, it does not break existing code. I am > missing a reason why Alan Knight think this solution is not good. > >> or Seaside, I would certainly keep Seaside going, though I suspect > the >> Seaside developers would accomodate us in trying to align the > dialects. > > We never forced anybody to align their dialect. If possible, we always > changed our own code. We introduced compatibility layers that porters > can fill or we simply built our own classes. I hope that we do not > have to implement our own stream hierarchy as well. > >> [*] I assume that I will write Dolphin code to export something that >> Pharo can load. If any of you know of a good solution to that > problem, >> please let me know. In case you are wondering why the renaming is > all >> done in Pharo, it is because it hopefully does a better job of > leaving >> formatting in tact - D5's version of the RB is fairly hostile in that >> regard. > > The rewrite engine in Squeak/Pharo reformats all code it touches. > VisualWorks has some improvements in that area. I discussed with John > Brant and he said that these improvements are part of the open-source > refactoring browser, however the problem is that Cincom modified the > code and that the original improvements are not part of the download > on John's website. Therefor it is not clear, what code is clean and > what code is commercial. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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 > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] About on:
by Bill Schwab June 6, 2008

June 6, 2008

Lukas, The changes I propose would be almost trivial for them to adopt, and might actually make their lives easier in targeting Dolphin, should they wish to do so. The current semantics are <candidMode>watered-down to the point of being pointless, all in the name of being backwardly compatible with something that was questionable even before the existence of tools for exceptions and handling of same</candidMode>. All arguments in favor of preserving current behavior have been based on backward compatibility - nothing on merits. It will be interesting to see what happens when it comes time to de-cruft morphic - *that* will break external code. I will grant you one thing though: if I were to choose between breaking old morphic code or Seaside, I would certainly keep Seaside going, though I suspect the Seaside developers would accomodate us in trying to align the dialects. All they would need to do is use a selector to match the semantics they have learned to accept. It is the first disk pack I would burn - well, maybe just after underscore assignment has been scorched down to the sub-atomic level :) I will probably end up taking some of my own advice. Once my code can move to Pharo[*], I will probably load it into a throw-away image, using the RB therein to rename selectors. The first step would be to get #next and #next: "out of the way," by naming them #nextOrNil and #nextAvailable: - that's what they do. Load my code, and then rename #next to #nextOne and #next: to #nextMany:. These methods would signal EndOfStreamError (new name) to steer clear of default actions. Filing out and loading the resulting code should allow me to safely avoid the (to me deprecated) #next and #next:. It is a shame though, as they are the natural selectors one would want to use. Some slips detection based on packages and/or developer name would help me catch myself should I revert. It is precisely the risk of using the simpler/misleading selectors that has me convinced the breaking change is needed. Failing that, I need to at least solve it for my own code, and I will of course make that available to all. [*] I assume that I will write Dolphin code to export something that Pharo can load. If any of you know of a good solution to that problem, please let me know. In case you are wondering why the renaming is all done in Pharo, it is because it hopefully does a better job of leaving formatting in tact - D5's version of the RB is fairly hostile in that regard. 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) 846-1285 FAX: (352) 392-7029 >>> renggli(a)gmail.com 6/5/2008 11:10:07 AM >>> > ANSI is a standard and there are cases where it is wrong (commitee decisions > = compromise) I agree, however changing the behavior of #next means that we will not be able to develop Seaside on Pharo. Seaside takes great advantage that Squeak is ANSI compatible. Lukas > > On Jun 5, 2008, at 3:27 PM, Bill Schwab wrote: > > > > Lukas, > > > > I have blind copied someone who can comment, or not at his discretion, > > on Cincom's view on this; he never said he was commenting off the > > record, but I try to err toward assuming that. I got the distinct sense > > that they are contemplating a change of some type and are also > > struggling with backward compatibility. > > > > You are correct about ANSI; I was shocked to see what they did. > > Without reservation, I assert the standard is wrong. Exception handling > > was created to allow the widespread elimination of precisely the > > condition that arises when #next reads off the end of a stream. I can > > always (and probably will if we do not fix this) deprecate #next and > > #next: in my own work, but that still leaves inconsistencies between and > > within dialects. > > > > 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) 846-1285 > > FAX: (352) 392-7029 > > > > > > > > > > > > > > > > > > renggli(a)gmail.com 6/5/2008 7:18 AM >>> > > > > > > > > > Yes, but it is not consistent, and they are apparently not happy > > > > > > > > > with it. > > > > Why? Can you give any pointers? > > > > > > > Object Arts' solution is consistent both with itself and with yoga of > > > > > structured exception handling. However, at this point, it appears that > > you do not want to make the change, so I will stop pressing. > > > > As far as I see this is inconsistent with the ANSI standard. > > > > Cheers, > > Lukas > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > 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 > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Re: [Pharo-project] About on:
by Bill Schwab June 6, 2008

June 6, 2008

Alan, I appreciate your time and respect your opinion. However, I do indeed consider ANSI's handling of #next to be wrong. Since I appear to be the outlier here, I will proceed with my backup plan unless I hear otherwise. You are of course correct that I *can* test for the end of stream every time I use #next, but I argue that the entire point of exceptions is to enable things like #next to be used safely, meaning without trusting the programmer to do such things. Note that the exceptions have to have teeth (no default action) in order to provide protection. If you have not read it, I highly recommend Maguier's Writing Solid Code. Be warned about the sub-title: "Microsoft's Techniques for Writing Bug-free C Programs." I know -- too bad they haven't read it! The publisher's hypocrisy aside, it is an excellent book. The chapter "Candy Machine Interfaces" is particularly relevant. Also, do not miss the disassembler example - great stuff! Then think back to your childhood. I just barely remember matchbooks that had the strike strip on the front; the books were of course REALLY old at the time :) Match books still say "close cover before striking," but some clever person decided to put the strip on the back, forcing the user to put some type of barrier between the strip and the remaining match heads. Another Microsoft document offers insight. At least the original MFC tutorials made a point of using new objects w/o testing for error conditions or null pointers, all thanks to exceptions. When I last looked, they pitched "smooth scrolling" (ways to make the computer draw even more than necessary) instead of tackling the finer points of redraw optimization as they once did. Who knows what else was cut. Kinda pathetic, but I digress. Absent robust and consistent use of exceptions, #next is an accident waiting to happen. The simplest course of action for me is to design something that is safe and consistent, and ensure that I use it over inconsistent alternatives. BTW, I do a LOT of stream I/O, so I do not trust myself any more than I do some idiot striking a match :) Happy Smalltalking! 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) 846-1285 FAX: (352) 392-7029 >>> Alan Knight <knight(a)acm.org> 06/05/08 9:12 PM >>> Um, I guess that'd be me, but I'm missing a bit of context here. I guess you're probably not talking about #on:, but about #next, which I had discussed earlier with Bill. I had glanced at the ANSI standard and it appeared to me that it left the behaviour undefined. I don't know if you could characterize that as "wrong". A bad idea, perhaps, but it can't be wrong because it doesn't say anything. With respect to next, what VisualWorks does is raise an EndOfStream exception which is a notification. If not caught, it proceeds with nil. I don't think this is a good idea, and would like to at least make it not common behaviour. But I can't see changing the behaviour that a read past end of stream results in a nil. That assumption is pretty deep in a lot of Smalltalk code, and I think (without checking) that it is what all the dialects except Dolphin do. I note that it's not necessary to avoid the use of next in your own code if you don't like the behaviour. Just use it in conjunction with an atEnd test. At 09:27 AM 6/5/2008, Bill Schwab wrote: >Lukas, > >I have blind copied someone who can comment, or not at his discretion, >on Cincom's view on this; he never said he was commenting off the >record, but I try to err toward assuming that. I got the distinct sense >that they are contemplating a change of some type and are also >struggling with backward compatibility. > >You are correct about ANSI; I was shocked to see what they did. >Without reservation, I assert the standard is wrong. Exception handling >was created to allow the widespread elimination of precisely the >condition that arises when #next reads off the end of a stream. I can >always (and probably will if we do not fix this) deprecate #next and >#next: in my own work, but that still leaves inconsistencies between and >within dialects. > >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) 846-1285 >FAX: (352) 392-7029 > > >>>> renggli(a)gmail.com 6/5/2008 7:18 AM >>> >> > Yes, but it is not consistent, and they are apparently not happy >with it. > >Why? Can you give any pointers? > >> Object Arts' solution is consistent both with itself and with yoga of >structured exception handling. However, at this point, it appears that >you do not want to make the change, so I will stop pressing. > >As far as I see this is inconsistent with the ANSI standard. > >Cheers, >Lukas > >-- >Lukas Renggli >http://www.lukas-renggli.ch > >_______________________________________________ >Pharo-project mailing list >Pharo-project(a)lists.gforge.inria.fr >http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Alan Knight [|], Engineering Manager, Cincom Smalltalk knight(a)acm.org aknight(a)cincom.com http://www.cincom.com/smalltalk

1 0

June 6, 2008

Begin forwarded message: > From: Alan Knight <knight(a)acm.org> > Date: June 6, 2008 2:05:34 PM CEDT > To: pharo-project-owner(a)lists.gforge.inria.fr > Cc: "Bill Schwab" <BSchwab(a)anest.ufl.edu> > Subject: Re: [Pharo-project] About on: > > I guess I'm a non-member and not allowed to post, but it'd probably > be good if you could forward this. > >> Um, I guess that'd be me, but I'm missing a bit of context here. I >> guess you're probably not talking about #on:, but about #next, >> which I had discussed earlier with Bill. >> >> I had glanced at the ANSI standard and it appeared to me that it >> left the behaviour undefined. I don't know if you could >> characterize that as "wrong". A bad idea, perhaps, but it can't be >> wrong because it doesn't say anything. >> >> With respect to next, what VisualWorks does is raise an EndOfStream >> exception which is a notification. If not caught, it proceeds with >> nil. I don't think this is a good idea, and would like to at least >> make it not common behaviour. But I can't see changing the >> behaviour that a read past end of stream results in a nil. That >> assumption is pretty deep in a lot of Smalltalk code, and I think >> (without checking) that it is what all the dialects except Dolphin >> do. >> >> I note that it's not necessary to avoid the use of next in your own >> code if you don't like the behaviour. Just use it in conjunction >> with an atEnd test. >> >> At 09:27 AM 6/5/2008, Bill Schwab wrote: >>> Lukas, >>> >>> I have blind copied someone who can comment, or not at his >>> discretion, >>> on Cincom's view on this; he never said he was commenting off the >>> record, but I try to err toward assuming that. I got the distinct >>> sense >>> that they are contemplating a change of some type and are also >>> struggling with backward compatibility. >>> >>> You are correct about ANSI; I was shocked to see what they did. >>> Without reservation, I assert the standard is wrong. Exception >>> handling >>> was created to allow the widespread elimination of precisely the >>> condition that arises when #next reads off the end of a stream. I >>> can >>> always (and probably will if we do not fix this) deprecate #next and >>> #next: in my own work, but that still leaves inconsistencies >>> between and >>> within dialects. >>> >>> 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) 846-1285 >>> FAX: (352) 392-7029 >>> >>> >>> >>> renggli(a)gmail.com 6/5/2008 7:18 AM >>> >>> > > Yes, but it is not consistent, and they are apparently not >>> happy >>> with it. >>> >>> Why? Can you give any pointers? >>> >>> > Object Arts' solution is consistent both with itself and with >>> yoga of >>> structured exception handling. However, at this point, it appears >>> that >>> you do not want to make the change, so I will stop pressing. >>> >>> As far as I see this is inconsistent with the ANSI standard. >>> >>> Cheers, >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Alan Knight [|], Engineering Manager, Cincom Smalltalk >> knight(a)acm.org >> aknight(a)cincom.com >> http://www.cincom.com/smalltalk > > -- > Alan Knight [|], Engineering Manager, Cincom Smalltalk > knight(a)acm.org > aknight(a)cincom.com > http://www.cincom.com/smalltalk

1 0

[Pharo-project] Most active
by Damien Cassou June 5, 2008

June 5, 2008

Pharo is the 4th most active project in gforge and it appears in the front page. Pharo is also the most active SqueakSource project. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

4 4