- Pharo-dev - lists.pharo.org

Re: [Pharo-project] mac-roman encoding borken?

by Nicolas Cellier

Fortunately, an analysis of code clearly shows that ByteTextConverter class>>#initializeTables is broken (stamped 2/5/2009) It maps characters with an offset of 128... Nicolas 2009/7/26 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > I don't know about the changes, but I know I cannot debug it in a core > image because debugger does not work at all... :( > > Nicolas > > 2009/7/26 Philippe Marschall <kustos(a)gmx.net>: >> Hi >> >> We have some failing tests in Seaside in the latest versions of Pharo >> that work in older versions. A short analysis seems to indicate that the >> there are some issues with mac-roman support in current versions Pharo. >> To be concrete the following code used to work in older versions but >> fails for newer ones. >> >> (('Ã¤Ã¶Ã¼' convertToEncoding: 'mac-roman') convertFromEncoding: >> 'mac-roman') = 'Ã¤Ã¶Ã¼' >> >> Is anybody aware of any changes? Should I open a bug? >> >> Cheers >> Philippe >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 26, 2009

Re: [Pharo-project] mac-roman encoding borken?

by Nicolas Cellier

I don't know about the changes, but I know I cannot debug it in a core image because debugger does not work at all... :( Nicolas 2009/7/26 Philippe Marschall <kustos(a)gmx.net>: > Hi > > We have some failing tests in Seaside in the latest versions of Pharo > that work in older versions. A short analysis seems to indicate that the > there are some issues with mac-roman support in current versions Pharo. > To be concrete the following code used to work in older versions but > fails for newer ones. > > (('Ã¤Ã¶Ã¼' convertToEncoding: 'mac-roman') convertFromEncoding: > 'mac-roman') = 'Ã¤Ã¶Ã¼' > > Is anybody aware of any changes? Should I open a bug? > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 26, 2009

Re: [Pharo-project] Smalltalk vs SmalltalkImage current woes

by Igor Stasenko

2009/7/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Smalltalk is a dictionary namespace > not a shit place full of crap. > Agree, this is why i proposing a consensus: Keep dictionary aside of shit, and at same time live with what we currently have :) > This is why we started to clean SystemDictionary > and people started to complain and we stop. >> >> But i understand the reasoning of dissection the Smalltalk dictionary >> of globals from the rest of service methods & additional state, >> which is needed and which were putted in SmalltalkImage class. >> >> But the more i thinking about it, the more i feel that this >> 'dissection' can be done in least intrusive way which is much >> friendlier to 'old ways' >> but also plays well with 'current ways'. >> >> So, what i'm proposing: >> >> - make a dictionary of globals a pure dictionary, without any extra >> unrelated methods. >> - completely move all fat stuff into SmalltalkImage from >> SystemDictionary class >> - add 'globals' ivar to SmalltalkImage class , and add proxy methods >> for accessing the dictionary, like #at: #at:put: etc. >> >> then simply: >> Smalltalk at: #Smalltalk put: (SmalltalkImage current). >> >> Now, Smalltalk == SmalltalkImage current and everyone is happy: >> - dictionary lives in separate ivar, >> - fat & boring housekeeping stuff lives in SmalltalkImage instance. >> >> What you think? > > Yes this was the solution we envision to keep people happy. > And one day cut the backlink. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 26, 2009

[Pharo-project] mac-roman encoding borken?

by Philippe Marschall

Hi We have some failing tests in Seaside in the latest versions of Pharo that work in older versions. A short analysis seems to indicate that the there are some issues with mac-roman support in current versions Pharo. To be concrete the following code used to work in older versions but fails for newer ones. (('Ã¤Ã¶Ã¼' convertToEncoding: 'mac-roman') convertFromEncoding: 'mac-roman') = 'Ã¤Ã¶Ã¼' Is anybody aware of any changes? Should I open a bug? Cheers Philippe

July 26, 2009

Re: [Pharo-project] Smalltalk vs SmalltalkImage current woes

by StÃ©phane Ducasse

On Jul 24, 2009, at 8:22 PM, Adrian Lienhard wrote: > I also like the idea since I always loose a few seconds to figure out > where some method, like vmStatisticsReportString, is located. There > are at least three different selectors used to access a singleton > instance: > > SmalltalkImage current > SystemNavigation default > SystemChangeNotifier uniqueInstance > > I just can't remember them. We could be consistent but havgin Smalltalk point to each of them is not a solution since the client code will still not distinguish between its really provider. Stef > > Adrian > > On Jul 24, 2009, at 12:27 , Igor Stasenko wrote: > >> I am currently using the Cuis, which doesn't having a 'SmalltalkImage >> current' refactoring.. >> And this difference is a bit frustrating to me, especially when code >> which have to be ported from Squeak, >> i need to visit all the places and fix the references. >> >> I was not here when this change was introduced, and you maybe know , >> that i'm a heated enemy of global state. >> But i understand the reasoning of dissection the Smalltalk dictionary >> of globals from the rest of service methods & additional state, >> which is needed and which were putted in SmalltalkImage class. >> >> But the more i thinking about it, the more i feel that this >> 'dissection' can be done in least intrusive way which is much >> friendlier to 'old ways' >> but also plays well with 'current ways'. >> >> So, what i'm proposing: >> >> - make a dictionary of globals a pure dictionary, without any extra >> unrelated methods. >> - completely move all fat stuff into SmalltalkImage from >> SystemDictionary class >> - add 'globals' ivar to SmalltalkImage class , and add proxy methods >> for accessing the dictionary, like #at: #at:put: etc. >> >> then simply: >> Smalltalk at: #Smalltalk put: (SmalltalkImage current). >> >> Now, Smalltalk == SmalltalkImage current and everyone is happy: >> - dictionary lives in separate ivar, >> - fat & boring housekeeping stuff lives in SmalltalkImage instance. >> >> What you think? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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

July 25, 2009

Re: [Pharo-project] Smalltalk vs SmalltalkImage current woes

by StÃ©phane Ducasse

Smalltalk is a dictionary namespace not a shit place full of crap. This is why we started to clean SystemDictionary and people started to complain and we stop. > > But i understand the reasoning of dissection the Smalltalk dictionary > of globals from the rest of service methods & additional state, > which is needed and which were putted in SmalltalkImage class. > > But the more i thinking about it, the more i feel that this > 'dissection' can be done in least intrusive way which is much > friendlier to 'old ways' > but also plays well with 'current ways'. > > So, what i'm proposing: > > - make a dictionary of globals a pure dictionary, without any extra > unrelated methods. > - completely move all fat stuff into SmalltalkImage from > SystemDictionary class > - add 'globals' ivar to SmalltalkImage class , and add proxy methods > for accessing the dictionary, like #at: #at:put: etc. > > then simply: > Smalltalk at: #Smalltalk put: (SmalltalkImage current). > > Now, Smalltalk == SmalltalkImage current and everyone is happy: > - dictionary lives in separate ivar, > - fat & boring housekeeping stuff lives in SmalltalkImage instance. > > What you think? Yes this was the solution we envision to keep people happy. And one day cut the backlink. Stef

July 25, 2009

[Pharo-project] Baseline test results on pharo core 10392

by Miguel Enrique CobÃ¡ Martinez

As I can't modify the wiki this is the output of the script of Mike Roberts for Baseline test results on pharo core 10392. Can someone with write permission update the wiki please, Thanks, Miguel CobÃ¡ = 10392 = 7123 run, 7037 passes, 4 expected failures, 17 failures, 65 errors, 0 unexpected passes == Failures == {{{ ClosureCompilerTest>>#testInjectIntoDecompiledDebugs ClosureCompilerTest>>#testSourceRangeAccessForBlueBookInjectInto ClosureCompilerTest>>#testSourceRangeAccessForBlueBookLongFormInjectInto ClosureCompilerTest>>#testSourceRangeAccessForClosureBytecodeInjectInto ClosureCompilerTest>>#testSourceRangeAccessForClosureLongFormBytecodeInjectInto ClosureCompilerTest>>#testSourceRangeAccessForInjectInto HostWindowTests>>#testOne IVsAndClassVarNamesConflictTest>>#testClassWithInvalidClassVariablesShouldNotBeReferencedByItsSuperclass MethodPragmaTest>>#testReformat MorphicToolBuilderTests>>#testGetButtonColor MorphicToolBuilderTests>>#testGetButtonSideEffectFree MorphicUIBugTest>>#testOpenWorkspaceAns PNGReadWriterTest>>#test16BitDisplay ProcessSpecificTest>>#testDynamicVariable ProcessSpecificTest>>#testLocalVariable ReleaseTest>>#testObsoleteClasses ReleaseTest>>#testUndeclared }}} == Errors == {{{ BlockContextTest>>#testTrace ClosureCompilerTest>>#testDebuggerTempAccess DebuggerUnwindBug>>#testUnwindDebugger HostSystemMenusTest>>#testAppendWindowMenuMacOnly HostSystemMenusTest>>#testCharacterChanging HostSystemMenusTest>>#testCommandIDMacOnly HostSystemMenusTest>>#testCountsMacOnly HostSystemMenusTest>>#testEditMenuEncodingMacOnly HostSystemMenusTest>>#testEditMenuIsMenuItemEnabledMacOnly HostSystemMenusTest>>#testEditMenuItemCmdMacOnly HostSystemMenusTest>>#testEditMenuItemIconMacOnly HostSystemMenusTest>>#testEditMenuItemMarkMacOnly HostSystemMenusTest>>#testEditMenuItemStyle HostSystemMenusTest>>#testEditMenuItemsTextMacOnly HostSystemMenusTest>>#testEditMenuKeyGlyphMacOnly HostSystemMenusTest>>#testEditMenuModifiersMacOnly HostSystemMenusTest>>#testEncodingMacOnly HostSystemMenusTest>>#testFileMenuCommandIDMacOnly HostSystemMenusTest>>#testFileMenuQuitEnabledMacOnly HostSystemMenusTest>>#testFileMenuQuitTextMacOnly HostSystemMenusTest>>#testFontIDMacOnly HostSystemMenusTest>>#testGetMenuTitleMacOnly HostSystemMenusTest>>#testKeyGlyphMacOnly HostSystemMenusTest>>#testMenuHandles HostSystemMenusTest>>#testMenuHandlesCount HostSystemMenusTest>>#testMenuHandlesGetMenu1CommandID HostSystemMenusTest>>#testMenuHandlesGetMenu1Encoding HostSystemMenusTest>>#testMenuHandlesGetMenu1FontID HostSystemMenusTest>>#testMenuHandlesGetMenu1KeyGlyph HostSystemMenusTest>>#testMenuHandlesGetMenu2CommandID HostSystemMenusTest>>#testMenuHandlesGetMenu2IsMenuItemEnabled HostSystemMenusTest>>#testMenuHandlesGetMenu2Items HostSystemMenusTest>>#testMenuHandlesGetMenu3Encoding HostSystemMenusTest>>#testMenuHandlesGetMenu3IsMenuItemEnabled HostSystemMenusTest>>#testMenuHandlesGetMenu3ItemCmd HostSystemMenusTest>>#testMenuHandlesGetMenu3ItemIcon HostSystemMenusTest>>#testMenuHandlesGetMenu3ItemMark HostSystemMenusTest>>#testMenuHandlesGetMenu3ItemStyle HostSystemMenusTest>>#testMenuHandlesGetMenu3Items HostSystemMenusTest>>#testMenuHandlesGetMenu3KeyGlyph HostSystemMenusTest>>#testMenuHandlesGetMenu3Modifiers HostSystemMenusTest>>#testMenuHandlesGetMenuTitle HostSystemMenusTest>>#testMenuHandlesNewMenu HostSystemMenusTest>>#testMenuHandlesNewMenuAppend HostSystemMenusTest>>#testMenuHandlesNewMenuAppend2 HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheck HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheckSetCmd HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheckSetCmd2 HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheckSetItemHierarchicalID HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheckSetItemModifiers HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheckSetItemText HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheckSetItemTextEncoding HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheckSetItemTextFondID HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheckSetMark HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheckSetMenuTitle HostSystemMenusTest>>#testMenuHandlesNewMenuAppendCheckSetStyle HostSystemMenusTest>>#testMenuHandlesNewMenuAppendDeleteItem HostSystemMenusTest>>#testMenuHandlesNewMenuAppendDeleteItem2 HostSystemMenusTest>>#testMenuHandlesNewMenuAppendInsertItem HostSystemMenusTest>>#testMenuHandlesNewMenuAppendText HostSystemMenusTest>>#testMenuHandlesNewMenuAppendWindowMenu HostSystemMenusTest>>#testMenuHideShowMenu LocaleTest>>#testIsFontAvailable MethodContextTest>>#testTempNamed MethodContextTest>>#testTempNamedPut }}}

July 25, 2009

[Pharo-project] Access to pharo wiki

by Miguel Enrique CobÃ¡ Martinez

Hi all, Who can give me permission to modify the pharo wiki? How can I change the status of a issue in the issue tracker? Cheers, Miguel CobÃ¡

July 25, 2009

[Pharo-project] Polymorph depends on Sound

by Adrian Lienhard

Hi Gary, I'm working on removing the Sound package. Polymorph's SoundTheme class has some methods that reference RestSound. For instance: windowRestoreDownSound ^self sounds at: #windowRestoreDown ifAbsent: [RestSound dur: 0] Could we change these methods, for example like this: windowRestoreDownSound ^self sounds at: #windowRestoreDown ifAbsent: [self defaultDefaultSound] and then defaultDefaultSound ^ Beeper default Projects that use sound can then load the Sound package and define their own SoundTheme. If this is OK with you I'll do these changes in Pharo and you can pick them up and merge them later. Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

July 25, 2009

[Pharo-project] Fix for issue 981 Author class in pharo

by Miguel Enrique CobÃ¡ Martinez

http://code.google.com/p/pharo/issues/detail?id=981 Name: SLICE-ChangeAuthorInitialsAndNameToFullName-MiguelCoba.3 Author: MiguelCoba Time: 25 July 2009, 3:53:41 am UUID: 27a1accc-4f41-4d11-94f5-9bdbb4166bd7 Ancestors: SLICE-ChangeAuthorInitialsAndNameToFullName-MiguelCoba.2 Dependencies: Monticello-MiguelCoba.372, Morphic-MiguelCoba.347, ScriptLoader-MiguelCoba.972, System-Changes-MiguelCoba.11, System-Support-MiguelCoba.62, Tools-MiguelCoba.179 Removes all the code from initials and name on Author class. It is replaced by a new fullName inst var and corresponding methods. The old code it is deprecated and the image contains no more calls to the old code. All the new code should call only the fullName methods in Author This is my first intent to rewrite the Author class to unify the instance variables. Please, check it on a 10392 core image and post your comments/critics. Also, I didn't modify the following methods of Utilities. Tell me what would you like to do with them, please: Utilities fixStamp: Utilities methodsWithInitials: Utilities doesMethod:forClass:bearInitials Cheers, Miguel CobÃ¡

July 25, 2009