July 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo 1.1/1.2 and class names in Chinese

by StÃ©phane Ducasse

+ 20000 Stef On Jul 28, 2010, at 10:27 PM, Juan Vuletich wrote: > Hi Folks, > > I think that is a mistake. Having Spanish as my mother tongue, I used to code with Spanish names before knowing Smalltalk. So when started using Smalltalk I kept doing it. Later I realized it is a bad idea. In Smalltalk there is no clear distinction between the "vendor libraries" and our own code. Our application specific classes will many times implement methods akin to existing ones in the system. Writing their names in English makes the whole system more consistent. Following this a little bit, it is better if all the code we write is in English too. > > OTOH, I believe it is ok to write comments in languages other than English (if the code will not be open sourced). > > I'd even suggest the system to reject names and selectors not in ASCII. > > Cheers, > Juan Vuletich > > Alexandre Bergel wrote: >> I have no idea how to help you. But trying to have classes with chinese (or any other alphabet with accents) names is important. >> Even though I personally write all my code in English, many like to write code in their favorite natural language. This is what I see with students for example. >> >> Cheers, >> Alexandre >> >> >> On 28 Jul 2010, at 21:33, empty wrote: >> >> >>> In 1.1 and 1.2, without setting a language environment for Chinese, I am able >>> to use Chinese by setting fonts. It seems to work except for accepting a >>> class named in Chinese will end in a ClassBuilder error of 'Class names must >>> be capitalized'. Well is it a feature(requires language environment being >>> set correctly) or bug? >>> >>> The code located being: >>> >>> validateClassName: aString >>> "Validate the new class name" >>> >>> aString isSymbol >>> ifFalse: [ ^ false ]. >>> aString first canBeGlobalVarInitial ifFalse:[ >>> self error: 'Class names must be capitalized'. >>> ^false]. >>> environ at: aString ifPresent:[:old| >>> (old isKindOf: Behavior) ifFalse:[ >>> self notify: aString asText allBold, ' already exists!\Proceed will store over it.' withCRs]]. >>> ^ true >>> >>> and following the code the problemic method is #canBeGlobalVarInitial: which >>> is found in two classes: >>> in EncodedCharSet class side: >>> canBeGlobalVarInitial: char >>> >>> | leadingChar | >>> leadingChar := char leadingChar. >>> >>> leadingChar = 0 ifTrue: [^ self isUppercase: char]. >>> ^ self isLetter: char. >>> >>> and in LanguageEnvironment >>> >>> canBeGlobalVarInitial: char >>> >>> ^ Unicode canBeGlobalVarInitial: char. >>> >>> I didn't set a Chinese environment and the exception is occured in in >>> EncodedCharSet class since leadingChar is 0 and a Chinese char seems thought >>> to be lowercased. >>> >>> >>> >>> >>> ----- >>> åç¡ä½ åç¡æ³ åç¡å§ >>> -- >>> View this message in context: http://forum.world.st/Pharo-1-1-1-2-and-class-names-in-Chinese-tp2305496p23… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3030 - Release Date: 07/26/10 15:34:00 >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 31, 2010

Re: [Pharo-project] Limitation of number os literals in a method?

by StÃ©phane Ducasse

did you try to generate a string (I know this is not the same) container := CLPanel new. container name: 'container'. container text: ''. container usePolymorphStyleMechanism: true. container balloonText: nil. container enabled: true. container location: 8@10. container extent: 653@460. container anchors: {false .false .false .false .}. container imageResource: nil. container style: { (BorderStyle width: 0 color: Color transparent) .(Color r: 0.972 g: 0.972 b: 0.944) .(Color r: 0.972 g: 0.972 b: 0.944) .false .false .}. container minWidth: 2. container minHeight: 2. container layout: {ProportionalLayout .#rigid .#rigid .0 .#center .#none .0 .#topLeft .#topToBottom .#none .false .#topLeft .#none .0 .1073741823 .}. container visible = false. container openInWorld. => 'Panel name: ''container'' usePolymorphStyleMechanism: true. enabled: true. location: 8@10. extent: 653@460. anchors: {false .false .false .false .}. ... minWidth: 2. minHeight: 2. layout: #(ProportionalLayout .#rigid .#rigid .0 .#center .#none .0 .#topLeft .#topToBottom .#none .false .#topLeft .#none .0 .1073741823 ) . visible: false.' then you parse only subexpressions delimited by #( ) and do a big perform: loop what you could do is also to decouple the description from its interpretation using a Builder Design Pattern. This way you do not bind the spec to your specific widgets and you could customize your build with different widgets. PS: Apparently you have a problem also container visible = false. => container visible: false. Stef On Jul 31, 2010, at 10:57 AM, nullPointer wrote: > > I get that error when I try save a CLView builded with the UIBuilder > > More than 256 literals referenced. > You must split or otherwise simplify this method. > The 257th literal is: 128 > > Select Proceed to continue, or close this window to cancel the operation. > > > > How I can solve that problem? The method than I try save is generated > programmatically... > > Thanks > -- > View this message in context: http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp230874… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 31, 2010

Re: [Pharo-project] copying always the .sources ??? [WAS] Re: PharoCore 1.1 comments

by StÃ©phane Ducasse

A self contained version would be good. this way I download one file and I get everything. Stef > > > 2010/7/30 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com> > Hi all, > > some things I noticed in PharoCore 1.1 release: > > > - This PharoCore-1.1.zip doesn't include a sources file. It was good to > have it included in the zip as before. Can be included for every > PharoCore release? > > - The page says that PharoV10.sources is for use with 1.0, 1.1 and 1.2. > Shouldn't be better to have a different one for each release? (even if > 1.1 is a copy of 1.0, the different name avoids doubts about numbering > scheme): > > PharoCore-1.0.image > PharoCore-1.0.changes > PharoV10.sources > > PharoCore-1.1.image > PharoCore-1.1.changes > PharoV10.sources (???) > > > > I also thought about this and that could be confusing with newcomers. But if .sources didn't change in 1.1 and 1.2, is it necessary to have them? or the note saying that PharoV10.sources works for all is enought ? > > Cheers > > Mariano > > > > ... > > PharoCore-1.7.image > PharoCore-1.7.changes > PharoV10.sources (bigger ???) > > Just a suggestion. ;) > > - SystemVersion current majorMinorVersion prints: > > PharoCore 1.0: 'PharoCore1.0' > > PharoCore 1.1: 'Pharo1.1' > > Maybe this should be in the script preparing the image so that correctly > set the version string for PharoCore images and for Pharo images (or > maybe already is there but wasn't executed?) > > Other than that, the new image is *very* fast! > > Cheers > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > 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 31, 2010

Re: [Pharo-project] Conflic between Shout and PluggableTextMorph in Pharo 1.2

by StÃ©phane Ducasse

I see styler was only in the Plus variation.... Now styler is used in PluggableTextMorph so may be a default null Styler would be better than all these okToStyle check everywhere. So I would remove styler from shout and tag the version for 1.2. Stef > http://code.google.com/p/pharo/issues/detail?id=2734 > > It is easy to fix: > > a) use the same instVar and I just remove it from Shout > b) rename the instVar in Shout > > the problem is that I don't know the correct one > > cheers > > mariano > > > On Sat, Jul 31, 2010 at 5:47 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > open a ticket :) > > Stef > > On Jul 29, 2010, at 8:49 PM, Mariano Martinez Peck wrote: > > > Hi. If you try to load Shout, you will have the error: 'styler is already defined in PluggableTextMorph' > > > > The problem is that the Shut class PluggableShoutMorph subclass PluggableTextMorph. > > PluggableShoutMorph has its own instVar 'styler' which PluggableTextMorph doesn't have in Pharo 1.1 > > > > But in Pharo 1.2 (I don't know why) PluggableTextMorph has its own instVar 'styler'....thus, the problem. > > > > Of course, if I remove the instVar 'styler' from PluggableShoutMorph it shoud load...but I am not sure if this is the correct action. > > > > Thanks for the help in advance > > > > Mariano > > _______________________________________________ > > 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

July 31, 2010

Re: [Pharo-project] how do I turn off "smart" quotes in Pharo Seaside one-click image

by StÃ©phane Ducasse

>>> > > Well, I am sorry I said it is fairly easy to adapt. The implementation > was really bogus because it globally kept state. I rewrote the code > from scratch and committed it here: > > Name: ECompletion-lr.127 > Author: lr > Time: 31 July 2010, 7:21:25 pm > UUID: 42e3e807-2478-4dda-b207-acf162648cfe > Ancestors: ECompletion-lr.126 > > - rewrote the complete smart character logic (very ugly) > > Now this is really ugly and long code and there are literally dozens > of cases to handle. Let me know if it works better for you? I kind of > like it. The behavior for smart characters and the backspace is now > entirely different if there is a selection or if you are just typing sound exciting....

July 31, 2010

Re: [Pharo-project] Limitation of number os literals in a method?

by StÃ©phane Ducasse

eliot in VW did windows spec faced such a limit and relied on such bytecodes? I imagine that this is the case but... Stef On Jul 31, 2010, at 6:10 PM, Eliot Miranda wrote: > > On Sat, Jul 31, 2010 at 1:57 AM, nullPointer <epicfan(a)gmail.com> wrote: > > I get that error when I try save a CLView builded with the UIBuilder > > More than 256 literals referenced. > You must split or otherwise simplify this method. > The 257th literal is: 128 > > Select Proceed to continue, or close this window to cancel the operation. > > > > How I can solve that problem? The method than I try save is generated > programmatically... > > A proper fix requires new bytecodes, but if your method contains lots of explicit literal references, not just lots of message selectors or global varaiables, then there is a workaround. The problem is due to encoding ranges in message send and literal reference bytecodes which are limited to a 0 to 255 single byte range. There is no way around this limitation for message selectors or global variables without defining as bytecode with an extended range, but for explicit references if you put your literals in multiple arrays and access them by index you can pool the indices. This can be done either at the compiler level or at the generation level, but you should start working at the generation level. e.g. > > myMethod > | litPool0 litPool1 litPool2 litPool3 | > litPool0 := #( a literal array with up to 128 elements). > litPool1 := #( a literal array with up to 128 elements). > litPool2 := #( a literal array with up to 128 elements). > litPool3 := #( a literal array with up to 128 elements). > .... > self doSomethingWith: (litPool2 at: 127) > ... > > Your method now uses 1 literal for each pool and 1 literal for each array index other than 1 & 2 (1 & 2 have special bytecodes for them, as does the selector #at:). So, assuming every index is used, the above method uses 4 + 126 = 130 literals, leaving 126 literals for selectors and globals, while providing access to 512 explicit literals in the pool literal arrays. If you were to make the literal pools 256 elements large you'd loose because you'd need as many literals for the indices 3 to 256 as you saved from making the literal pool indirect. So using more smaller pools increases the total number of literals, e.g. with 8 64-element pools the above example uses 8 + 62 = 70 literals. > > When we can get to it we need to redefine the bytecode set to extend these ranges. Take a look at the VisualWorks bytecodes for a better encoding scheme. > > HTH > Eliot > > > Thanks > -- > View this message in context: http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp230874… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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 31, 2010

[Pharo-project] [update 1.2] #12071

by StÃ©phane Ducasse

12071 ----- - Issue 2732: Paste Up Clean up post actions required - Issue 2731: SystemNavigation cleaning - Issue 2730: Dialog cleaning - Issue 2728: MCSubDirectoryRepository should not use / but - Issue 2709: printStringHex for Character Stef

July 31, 2010

Re: [Pharo-project] SqueakSSL fails...

by Mariano Martinez Peck

I am in mac...do you have binaries for mac of such plugin? On Sat, Jul 31, 2010 at 5:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Indeed, if somebody has time please help. > > Stef > > On Jul 31, 2010, at 1:52 PM, Levente Uzonyi wrote: > > > On Fri, 30 Jul 2010, Andrei Stebakov wrote: > > > >> It fails at the following statement: > >> (decoded readInto: buffer startingAt: index count: count) = count > >> ifFalse:[self error: 'Unexpected read failure']. > >> > >> In SecureSocketStream>>initialize it decoded defined as > >> decoded := ReadStream on: (ByteArray new: 20000) from: 1 to: 0. > >> > >> Maybe decoded is supposed to become a SocketStream later in the game, > >> but at this point it's still a ReadStream which doesn't understand > >> #readInto:startingAt:count: > > > > Hm no. It just wasn't integrated: > http://code.google.com/p/pharo/issues/detail?id=2177 . > > > > > > Levente > > > >> > >> Can anyone reproduce this in Pharo 1.1? Just evaluate "WebClient > >> httpGet: 'https://www.google.com/search?q=squeak'<https://www.google.com/search?q=squeak%27> > ." > >> > >> 2010/7/30 Levente Uzonyi <leves(a)elte.hu>: > >>> On Fri, 30 Jul 2010, Andrei Stebakov wrote: > >>> > >>>> Apparently #readInto:startingAt:count: is not supported by ReadStream > >>>> Pharo 1.1... > >>> > >>> SecureSocketStream is a subclass of SocketStream which has a method > named > >>> #readInto:startingAt:count:. > >>> > >>> > >>> Levente > >>> > >>>> > >>>> > >>>> On Fri, Jul 30, 2010 at 5:46 PM, Andrei Stebakov <lispercat(a)gmail.com > > > >>>> wrote: > >>>>> > >>>>> Well, I put it there when Pharo was running. Now that I restarted > >>>>> Pharo I got a different error: > >>>>> When I execute "WebClient httpGet: > >>>>> 'https://www.google.com/search?q=squeak'<https://www.google.com/search?q=squeak%27>." > I got: > >>>>> > >>>>> ReadStream(Object)>>doesNotUnderstand: #readInto:startingAt:count: > >>>>> SecureSocketStream>>receiveDataInto:startingAt: > >>>>> SecureSocketStream>>receiveAvailableData > >>>>> SecureSocketStream(SocketStream)>>upToAll: > >>>>> WebResponse>>readFrom: > >>>>> WebClient>>sendRequest:content:size: > >>>>> WebClient>>sendRequest: > >>>>> WebClient>>httpGet:do: > >>>>> WebClient>>httpGet: > >>>>> WebClient class>>httpGet: > >>>>> UndefinedObject>>DoIt > >>>>> Compiler>>evaluate:in:to:notifying:ifFail:logged: > >>>>> [] in TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection > >>>>> BlockClosure>>on:do: > >>>>> TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection > >>>>> TextMorphForShoutEditor(ParagraphEditor)>>doIt > >>>>> [] in TextMorphForShoutEditor(ParagraphEditor)>>doIt: > >>>>> > TextMorphForShoutEditor(ParagraphEditor)>>terminateAndInitializeAround: > >>>>> TextMorphForShoutEditor(ParagraphEditor)>>doIt: > >>>>> TextMorphForShoutEditor(ParagraphEditor)>>dispatchOnKeyEvent:with: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jul 30, 2010 at 4:47 PM, Andrei Stebakov < > lispercat(a)gmail.com> > >>>>> wrote: > >>>>>> > >>>>>> I've downloaded the SqueakSSL.dll plugin and put it in the root > folder. > >>>>>> Also I've downloaded > >>>>>> SqueakSSL-Core > >>>>>> SqueakSSL-Plugin > >>>>>> SqueakSSL-Tests > >>>>>> > >>>>>> All tests passed. > >>>>>> Now when I try to execute "SqueakSSL google: 'Squeak'." > >>>>>> It fails creating the module in > >>>>>> > >>>>>> primitiveSSLCreate > >>>>>> "Primitive. Creates and returns a new SSL handle" > >>>>>> > >>>>>> <primitive: 'primitiveCreate' module: 'SqueakSSL'> > >>>>>> ^self primitiveFailed > >>>>>> > >>>>>> How can I fix it? > >>>>>> > >>>>>> Thank you, > >>>>>> Andrei > >>>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> 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 >

July 31, 2010

Re: [Pharo-project] PharoCore 1.1 comments

by Mariano Martinez Peck

2010/7/30 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com> > Hi all, > > some things I noticed in PharoCore 1.1 release: > > > - This PharoCore-1.1.zip doesn't include a sources file. It was good to > have it included in the zip as before. Can be included for every > PharoCore release? > > I agree. The release SHOULD include the .sources. Not every pharo core release because it is too much...but official releases may have also the .sources. Maybe we can repackage and upload a newone? marcus? > - The page says that PharoV10.sources is for use with 1.0, 1.1 and 1.2. > Shouldn't be better to have a different one for each release? (even if > 1.1 is a copy of 1.0, the different name avoids doubts about numbering > scheme): > > PharoCore-1.0.image > PharoCore-1.0.changes > PharoV10.sources > > PharoCore-1.1.image > PharoCore-1.1.changes > PharoV10.sources (???) > > ... > > PharoCore-1.7.image > PharoCore-1.7.changes > PharoV10.sources (bigger ???) > > Just a suggestion. ;) > > - SystemVersion current majorMinorVersion prints: > > PharoCore 1.0: 'PharoCore1.0' > > PharoCore 1.1: 'Pharo1.1' > > Maybe this should be in the script preparing the image so that correctly > set the version string for PharoCore images and for Pharo images (or > maybe already is there but wasn't executed?) > > Other than that, the new image is *very* fast! > > Cheers > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 31, 2010

[Pharo-project] copying always the .sources ??? [WAS] Re: PharoCore 1.1 comments

by Mariano Martinez Peck

2010/7/30 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com> > Hi all, > > some things I noticed in PharoCore 1.1 release: > > > - This PharoCore-1.1.zip doesn't include a sources file. It was good to > have it included in the zip as before. Can be included for every > PharoCore release? > > - The page says that PharoV10.sources is for use with 1.0, 1.1 and 1.2. > Shouldn't be better to have a different one for each release? (even if > 1.1 is a copy of 1.0, the different name avoids doubts about numbering > scheme): > > PharoCore-1.0.image > PharoCore-1.0.changes > PharoV10.sources > > PharoCore-1.1.image > PharoCore-1.1.changes > PharoV10.sources (???) > > I also thought about this and that could be confusing with newcomers. But if .sources didn't change in 1.1 and 1.2, is it necessary to have them? or the note saying that PharoV10.sources works for all is enought ? Cheers Mariano > ... > > PharoCore-1.7.image > PharoCore-1.7.changes > PharoV10.sources (bigger ???) > > Just a suggestion. ;) > > - SystemVersion current majorMinorVersion prints: > > PharoCore 1.0: 'PharoCore1.0' > > PharoCore 1.1: 'Pharo1.1' > > Maybe this should be in the script preparing the image so that correctly > set the version string for PharoCore images and for Pharo images (or > maybe already is there but wasn't executed?) > > Other than that, the new image is *very* fast! > > Cheers > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 31, 2010