March 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Unicode depending on Zinc

by StÃ©phane Ducasse

Add a bug entry :) Stef On Mar 15, 2012, at 4:22 PM, Guillermo Polito wrote: > What about changing the initialize via a request to a method with the data? I don't think Unicode case mappings will change too much in time :P... > > Something like the attach > > Guille > > On Wed, Mar 14, 2012 at 12:06 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi, > > Does this method make sense? (Do we want Unicode to update itself?) > > Unicode class>>initializeCaseMappings > "Unicode initializeCaseMappings" > ToCasefold := IdentityDictionary new. > ToUpper := IdentityDictionary new. > ToLower := IdentityDictionary new. > UIManager default informUserDuring: [ :bar| | result | > bar value: 'Downloading Unicode data'. > (result := ZnClient get: 'http://www.unicode.org/Public/UNIDATA/CaseFolding.txt') isSuccess > ifFalse: [ ^ self error: 'Download failed' ]. > bar value: 'Updating Case Mappings'. > self parseCaseMappingFrom: result contents readStream ]. > > Guille > > <Unicode class-initializeCaseMapping.st>

March 15, 2012

Re: [Pharo-project] MultiCompositionScanner depending on Morphic stuff

by StÃ©phane Ducasse

> > >> Good catch >> We should move them close to MultiCompositionScanner >> > > Yes, in general the structure of the system is ad-hoc. e.g. the whole Multi-* changes should be folded into > the classes that they extend (or at least be moved close). > > Other: Canvas is in Morphic, it should not :) > it's not clear where text support should be.. and lots more. yes but no stress one by one and we will get better.

March 15, 2012

Re: [Pharo-project] Unicode depending on Zinc

by Guillermo Polito

Of course with a nice comment saying something like: "Initialize the mappings from unicode lower to upper case and vice versa. sourceCodes and destinyCodes contains the unicode values for the mappings, and they match one by one. The source of this mapping can be found at: http://www.unicode.org/Public/UNIDATA/CaseFolding.txt' " On Thu, Mar 15, 2012 at 12:22 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > What about changing the initialize via a request to a method with the > data? I don't think Unicode case mappings will change too much in time > :P... > > Something like the attach > > Guille > > > On Wed, Mar 14, 2012 at 12:06 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi, >> >> Does this method make sense? (Do we want Unicode to update itself?) >> >> Unicode class>>initializeCaseMappings >> "Unicode initializeCaseMappings" >> ToCasefold := IdentityDictionary new. >> ToUpper := IdentityDictionary new. >> ToLower := IdentityDictionary new. >> UIManager default informUserDuring: [ :bar| | result | >> bar value: 'Downloading Unicode data'. >> (result := ZnClient get: ' >> http://www.unicode.org/Public/UNIDATA/CaseFolding.txt') isSuccess >> ifFalse: [ ^ self error: 'Download failed' ]. >> bar value: 'Updating Case Mappings'. >> self parseCaseMappingFrom: result contents readStream ]. >> >> Guille >> > >

March 15, 2012

Re: [Pharo-project] MultiCompositionScanner depending on Morphic stuff

by Marcus Denker

On Mar 15, 2012, at 4:18 PM, StÃ©phane Ducasse wrote: > Good catch > We should move them close to MultiCompositionScanner > Yes, in general the structure of the system is ad-hoc. e.g. the whole Multi-* changes should be folded into the classes that they extend (or at least be moved close). Other: Canvas is in Morphic, it's not clear where text support should be.. and lots more. > Stef > > On Mar 14, 2012, at 3:14 PM, Guillermo Polito wrote: > >> - MultiCompositionScanner>>composeFrom:inRectangle:firstLine:leftSide:rightSide: >> >> depends on TextLine which is packaged as Morphic-Text Support >> >> - MultiCompositionScanner>>setFont >> >> depends on TextComposer which is packaged as Morphic-Text Support also >> >> http://code.google.com/p/pharo/issues/detail?id=5478&thanks=5478&ts=1331734… >> >> Guille > > -- Marcus Denker -- http://marcusdenker.de

March 15, 2012

Re: [Pharo-project] CodeLoader>>startUp: installing World?

by StÃ©phane Ducasse

On Mar 14, 2012, at 3:08 PM, Guillermo Polito wrote: > CodeLoader class>>startUp: resuming > resuming ifTrue: [ > World ifNotNil: [ World install. ActiveHand position: 100@100]. > self processUpdates. > ]. > > > Is this method ok in this class? I'd expect for > > World ifNotNil: [ World install. ActiveHand position: 100@100]. > > to be on PasteUpMorph or soâ¦ Yes me too. To be fixed. > > Guille

March 15, 2012

Re: [Pharo-project] Methods depending on Ring

by StÃ©phane Ducasse

On Mar 14, 2012, at 3:59 PM, Guillermo Polito wrote: > Hi! > > All these methods use RGMethodDefinition or RGCommentDefinition: > > CompiledMethod>>methodReference > ClassDescription>>methodReferencesInCategory: > SystemNavigation>>allMethodsWithSourceString:matchCase: > SystemNavigation>>createMethodNamed:realParent: > SystemNavigation>>allCallsOn:localTo: > TTransformationCompatibility>>collectMethodsFor:into: > TraitDescription>>collectMethodsFor:into: > TraitDescription>>methodReferencesInCategory: > TClassAndTraitDescription>>methodReferencesInCategory: > TraitExclusion>>methodReferencesInCategory: > > Is this ok? Because of them Ring is not unloadable... > > Are really CompiledMethod polymorphic with RGMethodDefinitions? > > Because if true maybe we can have in kernel > > CompiledMethod>>methodReference > ^self > > And let Ring override it. or not? I would call it methodDefinition and yes it would be good to be able to unload Ring. Thanks for trying. The problem is that before a lot of these references were referencing MethodReference. Stef

March 15, 2012

Re: [Pharo-project] Unicode depending on Zinc

by Guillermo Polito

What about changing the initialize via a request to a method with the data? I don't think Unicode case mappings will change too much in time :P... Something like the attach Guille On Wed, Mar 14, 2012 at 12:06 PM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi, > > Does this method make sense? (Do we want Unicode to update itself?) > > Unicode class>>initializeCaseMappings > "Unicode initializeCaseMappings" > ToCasefold := IdentityDictionary new. > ToUpper := IdentityDictionary new. > ToLower := IdentityDictionary new. > UIManager default informUserDuring: [ :bar| | result | > bar value: 'Downloading Unicode data'. > (result := ZnClient get: ' > http://www.unicode.org/Public/UNIDATA/CaseFolding.txt') isSuccess > ifFalse: [ ^ self error: 'Download failed' ]. > bar value: 'Updating Case Mappings'. > self parseCaseMappingFrom: result contents readStream ]. > > Guille >

March 15, 2012

Re: [Pharo-project] LanguageEnvironment depending on Network stuff

by StÃ©phane Ducasse

I would also removed the thibetan environment. Stef > Do we want this dependency? > > LanguageEnvironment>>fontDownload > "(Locale isoLanguage: 'ja') languageEnvironment fontDownload" > > (FileDirectory default fileExists: self fontFullName) > ifTrue: [^ self]. > Cursor read > showWhile: [self fontDownloadUrls > do: [:each | [ | contents f |contents := (each , '/' , self fontFileName) asUrl retrieveContents contents. > (contents first: 2) > = 'PK' > ifTrue: [f := FileStream newFileNamed: self fontFullName. > f binary. > [f nextPutAll: contents] > ensure: [f close]. > ^ self]] > on: NameLookupFailure > do: [:e | e]]]. > self error: 'Fonts does not found (' , self fontFullName , ')' > > > > http://code.google.com/p/pharo/issues/detail?id=5479&thanks=5479&ts=1331734…

March 15, 2012

Re: [Pharo-project] MultiCompositionScanner depending on Morphic stuff

by StÃ©phane Ducasse

Good catch We should move them close to MultiCompositionScanner Stef On Mar 14, 2012, at 3:14 PM, Guillermo Polito wrote: > - MultiCompositionScanner>>composeFrom:inRectangle:firstLine:leftSide:rightSide: > > depends on TextLine which is packaged as Morphic-Text Support > > - MultiCompositionScanner>>setFont > > depends on TextComposer which is packaged as Morphic-Text Support also > > http://code.google.com/p/pharo/issues/detail?id=5478&thanks=5478&ts=1331734… > > Guille

March 15, 2012

Re: [Pharo-project] Gettext package, who?

by Hilaire Fernandes

Le 15/03/2012 15:12, Marcus Denker a Ã©crit : > Another question: There are the remnants of the system left (#translated) > that we used in Squeak 3.9... > > it might make sense to think about making gettext the default > tranlation infrastructure? > It is by the fact the case, no. So I guess this remnants can be removed. In parallel, the gettext lookup at runtime of the message catalog could be optimized. It was done for Etoys. May be not top priority has the impact is light anyway. As for now, I publish my changes to the gettext package in PharoNonCorePackages Hilaire -- Dr. Geo -- http://www.drgeo.eu

March 15, 2012