- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo email list does not appear threaded

by Sean McGrath

I view this list with Thunderbird. It does not appear threaded, unlike other lists. A look at the headers compared to squeak-dev, for example, show no obvious difference, but I am far from an expert in email. Do others have the same experience? -- Sean McGrath sean(a)manybits.net

Feb. 15, 2009

Re: [Pharo-project] MimeType problems

by Michael Rueger

On Sun, Feb 15, 2009 at 6:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ok mike did you see the reset database DNU problem ? Yes, added a comment on the issue, but didn't have time to look at the code yet though. Michael > > Stef > > On Feb 15, 2009, at 6:04 PM, Michael Rueger wrote: > >> On Sun, Feb 15, 2009 at 4:56 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> Begin forwarded message: >>> >>>> From: Philippe Marschall <philippe.marschall(a)gmail.com> >>>> Date: February 15, 2009 4:02:05 PM CEST >>>> To: Seaside - general discussion >>>> <seaside(a)lists.squeakfoundation.org> >>>> Subject: Re: [Seaside] don't update to the latest Pharo >>>> Reply-To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org >>>>> >>>> >>>> 2009/2/15, Adrian Lienhard <adi(a)netstyle.ch>: >>>>> he filed an issue: http://code.google.com/p/pharo/issues/detail? >>>>> id=527 >> >> added as comment to issue >> >> If you add "asString" in the call in Kom it should work on both Squeak >> and Pharo. >> >> Making a fork most likely will be necessary at some point anyways, so >> changing Kom to work with proper MIME type objects would a step in the >> right direction IMHO. >> >> Decoupling would reduce reuse of existing classes. >> Reverting the change would break consistency of method naming. >> >> Michael >> >>>> >>>> Further analysis shows there are additional problems: >>>> MIMEDocument defaultContentType >>>> returns now an instance of MIMEType instead of a String which >>>> doesn't >>>> understand #indexOf: >>>> >>>> *must not add troll comment about static typing* >>>> >>>> I see three ways how "we" (= you & Giovanni) can proceed >>>> - make a fork of Kom for Pharo >>>> - decouple Kom from MIMEDocument >>>> - revert the changes done to MIMEDocument >>>> >>>> Additionally there is: >>>> http://bugs.squeak.org/view.php?id=7285 >>>> >>>> Cheers >>>> Philippe >>>> _______________________________________________ >>>> seaside mailing list >>>> seaside(a)lists.squeakfoundation.org >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>>> >>> >>> >>> _______________________________________________ >>> 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 >

Feb. 15, 2009

Re: [Pharo-project] Preferences refactoring

by StÃ©phane Ducasse

On Feb 15, 2009, at 6:05 PM, Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> Alain >> >> It would be nice to redesign completely preferences. > yes, it is the reason why I don't want to spend to much time on > the improvement of actual PreferenceBrowser. >> Did you read the thread >> Re: [Pharo-project] About Preference Flow >> of 4 of Feb ? > yes, I had it in mind. > Do someone know where I can find documentation on pragmas ? Pragma class je pense. Stef > > thanks > alain >> >> Summary here >> >> Instead of having the current situation ie >> >> MyTool>>doSomething >> >> .... >> Preferences useNewDiffTool >> ifTrue: [kjlhkjhjkh ] >> ifFalse: [nkjhkjkjhkj] >> >> >> and not been able to remove the preferences (or that the >> preference is >> just a configuration layer). >> >> I would like to have the preference made that way >> >> MyTool class>>useNewDiff >> >> MyTool class>> useOldDiff >> >> **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! >> >> >> Preferences useNewDiffTool >> MyTool useNewDiff >> >> I like the idea of lukas to use pragmas. >> >> Why not use pragmas on accessors of the class side that would be >> picked up by the preference browser? Then all state would be >> local to >> the affected code. >> >> Something along these lines: >> >> MCMonticelloBrowser>>showAdvanceDiffTool: aBoolean >> <preference: 'Show advanced diff tool' group: 'Monticello' >> type: #Boolean> >> >> advancedDiffTool := aBoolean >> >> >>>>> Hi all, >>> Here is a changeset with a new version of the PreferencesBrowser. >>> It is for testing. I can improve it a little bit >>> (by including display depth, desktop color, gradient color and >>> author >>> initials) >>> and provide a slice if it is ok. >>> >>> I've investigated how preferences are implemented and it seems to me >>> that >>> current situation is the result of succesives hacks. >>> I would like to clean out this part of the system. >>> I will provide a roadmap before any coding. >>> Can I start working on it ? >>> >>> Cheers >>> alain >>>>> >>>>>> On 11 Feb 2009, at 16:22, Alain Plantec wrote: >>>>>> >>>>>> >>>>>>> Hi all, >>>>>>> I would like to improve the PreferencesBrowser so that it >>>>>>> includes >>>>>>> standard Fonts preferences (see joined snapshot). >>>>>>> It's almost done except that, if a preference font is set to >>>>>>> Arial, >>>>>>> clicking on Save button leads to an infinite loop. >>>>>>> >>>>>>> To reproduce it, set button font to Arial-12 and >>>>>>> Preferences standardButtonFont deepCopy. >>>>>>> >>>>>>> Cheers >>>>>>> alain >>>>>>> < >>>>>>> FontsInPreferences >>>>>>> .png >>>>>>> >>>>>>>> < >>>>>>>> FTFdeepcopy.png>_______________________________________________ >>>>>>>> >>>>>>> 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 >>>>> >>>>> >>>> >>>> >>> >>> <PBFont.8.cs.gz>_______________________________________________ >>> 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 >

Feb. 15, 2009

Re: [Pharo-project] MimeType problems

by StÃ©phane Ducasse

Ok mike did you see the reset database DNU problem ? Stef On Feb 15, 2009, at 6:04 PM, Michael Rueger wrote: > On Sun, Feb 15, 2009 at 4:56 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> >> Begin forwarded message: >> >>> From: Philippe Marschall <philippe.marschall(a)gmail.com> >>> Date: February 15, 2009 4:02:05 PM CEST >>> To: Seaside - general discussion >>> <seaside(a)lists.squeakfoundation.org> >>> Subject: Re: [Seaside] don't update to the latest Pharo >>> Reply-To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org >>>> >>> >>> 2009/2/15, Adrian Lienhard <adi(a)netstyle.ch>: >>>> he filed an issue: http://code.google.com/p/pharo/issues/detail? >>>> id=527 > > added as comment to issue > > If you add "asString" in the call in Kom it should work on both Squeak > and Pharo. > > Making a fork most likely will be necessary at some point anyways, so > changing Kom to work with proper MIME type objects would a step in the > right direction IMHO. > > Decoupling would reduce reuse of existing classes. > Reverting the change would break consistency of method naming. > > Michael > >>> >>> Further analysis shows there are additional problems: >>> MIMEDocument defaultContentType >>> returns now an instance of MIMEType instead of a String which >>> doesn't >>> understand #indexOf: >>> >>> *must not add troll comment about static typing* >>> >>> I see three ways how "we" (= you & Giovanni) can proceed >>> - make a fork of Kom for Pharo >>> - decouple Kom from MIMEDocument >>> - revert the changes done to MIMEDocument >>> >>> Additionally there is: >>> http://bugs.squeak.org/view.php?id=7285 >>> >>> Cheers >>> Philippe >>> _______________________________________________ >>> seaside mailing list >>> seaside(a)lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> >> _______________________________________________ >> 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 >

Feb. 15, 2009

Re: [Pharo-project] Preferences refactoring

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > Alain > > It would be nice to redesign completely preferences. yes, it is the reason why I don't want to spend to much time on the improvement of actual PreferenceBrowser. > Did you read the thread > Re: [Pharo-project] About Preference Flow > of 4 of Feb ? yes, I had it in mind. Do someone know where I can find documentation on pragmas ? thanks alain > > Summary here > > Instead of having the current situation ie > > MyTool>>doSomething > > .... > Preferences useNewDiffTool > ifTrue: [kjlhkjhjkh ] > ifFalse: [nkjhkjkjhkj] > > > and not been able to remove the preferences (or that the > preference is > just a configuration layer). > > I would like to have the preference made that way > > MyTool class>>useNewDiff > > MyTool class>> useOldDiff > > **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! > > > Preferences useNewDiffTool > MyTool useNewDiff > > I like the idea of lukas to use pragmas. > > Why not use pragmas on accessors of the class side that would be > picked up by the preference browser? Then all state would be local to > the affected code. > > Something along these lines: > > MCMonticelloBrowser>>showAdvanceDiffTool: aBoolean > <preference: 'Show advanced diff tool' group: 'Monticello' > type: #Boolean> > > advancedDiffTool := aBoolean > > >>>> Hi all, >> Here is a changeset with a new version of the PreferencesBrowser. >> It is for testing. I can improve it a little bit >> (by including display depth, desktop color, gradient color and author >> initials) >> and provide a slice if it is ok. >> >> I've investigated how preferences are implemented and it seems to me >> that >> current situation is the result of succesives hacks. >> I would like to clean out this part of the system. >> I will provide a roadmap before any coding. >> Can I start working on it ? >> >> Cheers >> alain >>>> >>>>> On 11 Feb 2009, at 16:22, Alain Plantec wrote: >>>>> >>>>> >>>>>> Hi all, >>>>>> I would like to improve the PreferencesBrowser so that it includes >>>>>> standard Fonts preferences (see joined snapshot). >>>>>> It's almost done except that, if a preference font is set to Arial, >>>>>> clicking on Save button leads to an infinite loop. >>>>>> >>>>>> To reproduce it, set button font to Arial-12 and >>>>>> Preferences standardButtonFont deepCopy. >>>>>> >>>>>> Cheers >>>>>> alain >>>>>> < >>>>>> FontsInPreferences >>>>>> .png >>>>>> >>>>>>> <FTFdeepcopy.png>_______________________________________________ >>>>>>> >>>>>> 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 >>>> >>>> >>> >>> >> >> <PBFont.8.cs.gz>_______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Feb. 15, 2009

Re: [Pharo-project] MimeType problems

by Michael Rueger

On Sun, Feb 15, 2009 at 4:56 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > Begin forwarded message: > >> From: Philippe Marschall <philippe.marschall(a)gmail.com> >> Date: February 15, 2009 4:02:05 PM CEST >> To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> >> Subject: Re: [Seaside] don't update to the latest Pharo >> Reply-To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org >> > >> >> 2009/2/15, Adrian Lienhard <adi(a)netstyle.ch>: >>> he filed an issue: http://code.google.com/p/pharo/issues/detail? >>> id=527 added as comment to issue If you add "asString" in the call in Kom it should work on both Squeak and Pharo. Making a fork most likely will be necessary at some point anyways, so changing Kom to work with proper MIME type objects would a step in the right direction IMHO. Decoupling would reduce reuse of existing classes. Reverting the change would break consistency of method naming. Michael >> >> Further analysis shows there are additional problems: >> MIMEDocument defaultContentType >> returns now an instance of MIMEType instead of a String which doesn't >> understand #indexOf: >> >> *must not add troll comment about static typing* >> >> I see three ways how "we" (= you & Giovanni) can proceed >> - make a fork of Kom for Pharo >> - decouple Kom from MIMEDocument >> - revert the changes done to MIMEDocument >> >> Additionally there is: >> http://bugs.squeak.org/view.php?id=7285 >> >> Cheers >> Philippe >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 15, 2009

Re: [Pharo-project] Boring confirmation message...

by Keith Hodges

Why not combine your history idea with ScriptManager package, have workspaces broadcast their contents and have ScriptManager subscribe to the broadcast, recording the history, it then provides a browser for the history. The whole thing then becomes an optionally loadable package. regards Keith

Feb. 15, 2009

[Pharo-project] MimeType problems

by StÃ©phane Ducasse

Begin forwarded message: > From: Philippe Marschall <philippe.marschall(a)gmail.com> > Date: February 15, 2009 4:02:05 PM CEST > To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> > Subject: Re: [Seaside] don't update to the latest Pharo > Reply-To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org > > > > 2009/2/15, Adrian Lienhard <adi(a)netstyle.ch>: >> he filed an issue: http://code.google.com/p/pharo/issues/detail? >> id=527 > > Further analysis shows there are additional problems: > MIMEDocument defaultContentType > returns now an instance of MIMEType instead of a String which doesn't > understand #indexOf: > > *must not add troll comment about static typing* > > I see three ways how "we" (= you & Giovanni) can proceed > - make a fork of Kom for Pharo > - decouple Kom from MIMEDocument > - revert the changes done to MIMEDocument > > Additionally there is: > http://bugs.squeak.org/view.php?id=7285 > > Cheers > Philippe > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

Feb. 15, 2009

Re: [Pharo-project] unnecessary =, == :)

by Gary Chambers

Not yet... was unaware of that. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 15, 2009 2:36 PM Subject: Re: [Pharo-project] unnecessary =, == :) gary do you use <lint: 'Long methods' rationale: 'Rendering method' author: 'lr'> to tag the method you checked? http://code.google.com/p/pharo/wiki/SmallLintPharoFixing Stef On Feb 14, 2009, at 6:14 PM, Gary Chambers wrote: > SystemWindow>>#mouseDown: (actually needed, on first call that > property will > almost certainly be nil, set later in the method). > > Regards, Gary > > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 14, 2009 5:12 PM > Subject: Re: [Pharo-project] unnecessary =, == :) > > > PluggableTextMorph>>#accept (sadly required defence against text > setters > that don't return a boolean) > SystemWindow>>#mouseDown: (removed offending line, now obsolete, > apparently) > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 14, 2009 3:23 PM > Subject: [Pharo-project] unnecessary =, == :) > > >> Check for a =, ==, ~=, or ~~ message being sent to true/false or with >> true/false as the argument. Many times these can be eliminated since >> their receivers are already booleans. For example, "anObject isFoo == >> false" could be replaced with "anObject isFoo not" if isFoo always >> returns a boolean. Sometimes variables might refer to true, false, >> and >> something else, but this is considered bad style since the variable >> has multiple types. >> >> Project>>#setChangeSet: >> Project>>#isolationSet >> Project>>#compileAll:from: >> Project>>#writeFileNamed:fromDirectory:toServer: >> Project>>#isolationHead >> PNGReadWriter>>#debugging >> ClockMorph>>#addCustomMenuItems:hand: >> ClockMorph>>#step >> ClockMorph>>#toggleShowingSeconds >> ClockMorph>>#toggleShowing24hr >> WorldState>>#interCyclePause: >> Integer>>#quo: >> Integer>>#digitSubtract: >> SimpleServiceEntry>>#useLineAfter >> MorphicUIManager>>#interactiveParserFor: >> OBPluggableListMorph>>#mouseUp: >> PianoRollScoreMorph>>#addCustomMenuItems:hand: >> SystemDictionary>>#abandonSources >> SystemDictionary>>#internalizeSources >> SystemDictionary>>#internalizeChangeLog >> SetTest>>#testRemoveIfAbsent >> SimpleButtonDelayedMenuMorph>>#mouseUp: >> Installer>>#validate >> Installer>>#logErrorDuring: >> SketchEditorMorph>>#verifyState: >> SketchEditorMorph>>#deliverPainting:evt: >> SketchMorph>>#useInterpolation: >> Slider>>#descending >> JoystickMorph>>#autoCenterString >> JoystickMorph>>#button1 >> JoystickMorph>>#button2 >> SARInstaller>>#errorNoSuchMember: >> MessageSet>>#growable >> HandMorph>>#handleEvent: >> HandMorph>>#fullDrawOn: >> ImageSegment>>#declareAndPossiblyRename: >> PluggableListMorphPlus>>#wantsDroppedMorph:event: >> SUnitTest>>#testRanOnlyOnce >> BitmapFillStyle>>#isTiled >> InstallerMonticello>>#mcDetectFileBlock >> FTPClient>>#login >> Object>>#mustBeBooleanIn: >> Object>>#'~=' >> Decompiler>>#pushConstant: >> TextMorphForEditView>>#acceptOnCR >> HostSystemMenusMenuItem>>#shift >> FlapTab>>#inboard >> FlapTab>>#flapShowing >> FlapTab>>#tabSelected >> PluggableTreeMorph>>#wantsDroppedNode:on: >> DisplayScreen>>#deferUpdates: >> OBSystemBrowser>>#defaultBackgroundColor >> SmalltalkImage>>#setPlatformPreferences >> SmalltalkImage>>#snapshot:andQuit:embedded: >> URLMorph>>#mouseUp: >> MultiNewParagraph >> >>#multiComposeLinesFrom:to:delta:into:priorLines:atY: >> Collection>>#reject: >> TextDiffBuilder>>#hasMultipleMatches >> TrueTest>>#testNot >> TrueTest>>#testInMemory >> TrueTest>>#testAND >> MCFileBasedRepository>>#possiblyNewerVersionsOfAnyOf: >> Process>>#terminate >> ProtoObjectTest>>#testIsNil >> SqueakPage>>#write >> ColorPickerMorph>>#putUpFor:near: >> FalseTest>>#testAnd >> FalseTest>>#testOR >> FalseTest>>#testNot >> FalseTest>>#testAND >> UpdatingStringMorph>>#growable >> UpdatingStringMorph>>#autoAcceptOnFocusLoss >> LanguageEditor>>#selectedTranslationsAt:put: >> Socket>>#setOption:value: >> MultiCompositionScanner>>#setFont >> PositionableStream>>#unCommand >> HTTPSocket>>#logToTranscript >> Number>>#odd >> OBHierarchyBrowser>>#defaultBackgroundColor >> MorphExtension>>#isDefault >> MorphExtension>>#sortedPropertyNames >> MorphExtension>>#printOn: >> MorphExtension>>#hasProperty: >> ObjectOut>>#doesNotUnderstand: >> PluggableTextMorph>>#hasEditingConflicts >> PluggableTextMorph>>#accept >> SimpleSliderMorph>>#truncate >> OBProtocolBrowser>>#defaultBackgroundColor >> SystemWindow>>#mustNotClose >> SystemWindow>>#mouseDown: >> RBReadBeforeWrittenTester>>#read >> RBReadBeforeWrittenTester>>#processBlock: >> RBReadBeforeWrittenTester>>#processStatementNode: >> RBReadBeforeWrittenTester>>#processIfTrueIfFalse: >> GradientFillStyle>>#isRadialFill >> RefactoryTyper>>#typeFor: >> CompiledMethodTest>>#testValueWithReceiverArguments >> OBLazyListMorph>>#handleMouseMove: >> BlockContextTest>>#testSupplyAnswerThroughNestedBlocks >> BlockContextTest>>#testSupplyAnswerUsingTraditionalMatchOfQuestion >> BlockContextTest>>#testSupplySameAnswerToAllQuestions >> BlockContextTest>>#testSupplyAnswerUsingOnlySubstringOfQuestion >> BlockContextTest>>#testSupplySpecificAnswerToQuestion >> BlockContextTest>>#testSupplyAnswerUsingRegexMatchOfQuestion >> ImageMorph>>#isOpaque: >> ProjectSwikiServer>>#acceptsUploads >> PolygonMorph>>#rotateTestFlip: >> PolygonMorph>>#beStraightSegments >> PolygonMorph>>#beSmoothCurve >> BitBlt>>#drawFrom:to:withFirstPoint: >> FileList>>#getSelectedDirectory >> FileList>>#getSelectedFile >> RBParser>>#patchLiteralMessage >> OBMultipleSelectionColumn>>#listSelectionAt:put: >> ServerDirectory>>#upLoadProject:members:retry: >> MorphObjectOut>>#doesNotUnderstand: >> HaloMorph>>#addHandles >> ThumbnailImageMorph>>#togglePopupFeature >> ThumbnailImageMorph>>#handlesMouseDown: >> ThumbnailImageMorph>>#popupFeatureString >> ContextPart>>#jump:if: >> MCWorkingCopy>>#merge: >> FileDoesNotExistException>>#readOnly >> RBLiteralNodeTest>>#testValue >> Prefer... >> >> _______________________________________________ >> 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

Feb. 15, 2009

[Pharo-project] Mike we need some fixes for mime.... :)

by StÃ©phane Ducasse

> > > From: stephane ducasse <stephane.ducasse(a)free.fr> > Date: February 15, 2009 3:49:58 PM CEST > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Subject: Mike we need some fixes for mime.... > > > Issue 527: MIMEDocument changes break Kom > http://code.google.com/p/pharo/issues/detail?id=527 > > Issue 520: MIMEDocument class(Object)>>doesNotUnderstand: > #resetMIMEdatabase > http://code.google.com/p/pharo/issues/detail?id=520 > > Tx > Stef > > >

Feb. 15, 2009