January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3528 in pharo: TestRunner button height not fixed

by pharo＠googlecode.com

Comment #1 on issue 3528 by bernhard.pieber: TestRunner button height not fixed http://code.google.com/p/pharo/issues/detail?id=3528 Fix in PharoInbox: SUnitGUI-BernhardPieber.68

Jan. 10, 2011

Re: [Pharo-project] Issue 3525 in pharo: Compiler>>parserClass is broken and does not querying the class for providing the parser class

by Igor Stasenko

On 10 January 2011 20:52, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Parser is not hardcoded (except in tests), but parserClass is > sometimes sent to the wrong class.. > Example is Text>>makeSelectorBold (sent from Debugger) > It should be replaced with makeSelectorBoldIn: > > Also notice that source code files cannot be analyzed if they contain > classes absent from current system that define their own parserClass. > That is a problem for change lists, and possibly for MC (it would be > interesting to try). > I think that there could be a solution to that. We could require that certain methods like #newParser, #newCompiler should be written in smalltalk. Then code import tools could rely on that and compile these methods first, and then could use them to compile the rest of class'es source code. > Nicolas > -- Best regards, Igor Stasenko AKA sig.

Jan. 10, 2011

[Pharo-project] Issue 3528 in pharo: TestRunner button height not fixed

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3528 by bernhard.pieber: TestRunner button height not fixed http://code.google.com/p/pharo/issues/detail?id=3528 Pharo image: <dev> Pharo core version: <Pharo1.2beta, Latest update: #12295> Virtual machine used: <Cog.r2345> Steps to reproduce: 1. Open TestRunner 2. Resize window so that it height increases 3. Note that button height increases also

Jan. 10, 2011

Re: [Pharo-project] Issue 3525 in pharo: Compiler>>parserClass is broken and does not querying the class for providing the parser class

by Igor Stasenko

On 10 January 2011 22:50, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mon, Jan 10, 2011 at 12:42 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> 2011/1/10 Eliot Miranda <eliot.miranda(a)gmail.com>: >> > >> > >> > On Mon, Jan 10, 2011 at 11:42 AM, Nicolas Cellier >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> >> Will it work ? >> >> >> >> because Compiler class>>new >> >> Â Â Â Â ^ super new parser: self parserClass new >> >> >> >> sets the parser ivar with Compiler parserClass new. >> >> Maybe you'll need to remove this definition of new too. >> > >> > I think it works. Â Behavior>>parser class gets compilerClass >> > parserClass: >> > Behavior>>parserClass >> > "Answer a parser class to use for parsing method headers." >> > ^self compilerClass parserClass >> > So one is supposed to implement a Compiler subclass that defines a >> > class-side parserClass method. Â e.g. >> > MySpecialClass>>compilerClass >> > Â Â Â ^MySpecialCompiler >> > MySpecialCompiler class>>parserClass >> > Â Â Â ^MySpecialParser >> > So then >> > Compiler>>parserClass >> > ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: >> > [parser >> > class] >> > will also find MySpecialParser. >> > Yes, its heavyweight because the Compiler subclass isn't providing >> > anything >> > other than the reference to the parser. But that's the way the system is >> > written so far. >> > what do you think? >> > best >> > Eliot >> >> I think you are right, the system is like that, and if I remember >> already was in st80 v2.3. >> I used this feature, but my CustomCompiler didn't have many methods, >> mostly #parserClass. >> So we have a right to question this implementation. > > I think the bug is that classes are expected to answer compiler and parser > classes, not compiler and parser instances. Â If things were organized like > this: > Behavior>parserClass > Â Â Â ^Parser > Behavior>compilerClass > Â Â Â ^Compiler > Behavior>newParser > Â Â Â ^self parserClass new > Behavior>newCompiler > Â Â Â ^self compilerClass new parser: self newParser > and the compilation utility methods used "self newCompiler" then one could > implement just parserClass to obtain the desired effect. > What do you think? +1000 i learned that requesting an initialized instance is much more convenient & flexible than requesting a class just for sending 'new' to it. Classes with complex API often don't giving the answer, how properly initialize its instances, which leads to confusion and inability to properly connect layers of framework and/or install proper hooks which in own turn leads to bad coding practices like attempts to control object initialization outside of its factory (a class, or object which is really should be responsible for providing it). In our concrete situation, a #newCompiler message is much more powerful expression, because it allows a responding object to answer partially of fully initialized object, and in this way shifting the responsibility of its initialization to right place. And in this way, an object which going to answer it, could take care and properly initialize it, like setting a custom parser. This is what you can't do by answering classes all the way, since the only guaranteed protocol of class is a #new message.. Limiting and not very helpful. I think that the rule of thumb in all such cases should be following: - if your code works with objects which implement a certain protocol, explicitly state that your code requires a preinitialized instance which comes from other objects, which you communicating with. Never require any intermediary object(s), because they are actually an information noise and really should not be a concern of your code. > best > Eliot >> >> Nicolas >> -- Best regards, Igor Stasenko AKA sig.

Jan. 10, 2011

Re: [Pharo-project] Origins [poll]

by Stephen Taylor

Jan. 10, 2011

Re: [Pharo-project] Origins [poll]

by Norbert Hartl

Jan. 10, 2011

Re: [Pharo-project] XML packages, CDATA and encoding

by Norbert Hartl

Torsten, On 10.01.2011, at 13:38, Torsten Bergmann wrote: > Create a file "test.xml" with the following > contents (german umlaut): > > > <?xml version="1.0" encoding="iso-8859-1"?> > <test><![CDATA[ZaunkÃ¶nig]]></test> > > After loading ConfigurationOfXML try to parse it: > > |fs| > fs := FileStream fileNamed: 'test.xml'. > XMLDOMParser parseDocumentFrom: fs. > > > => gives an error: 'Invalid utf8 input detected' > => it works if you remove the CDATA section > > Looks like UTF8TextConverter is used independent > from the encoding of the XML... > the problem seems not to be the xml parser. If you use FileStream>>fileNamed: the fileNamed: is delegated to FileStream class>>concreteStream which is MultiByteStream. This stream initializes itself with the utf8 converter if it isn't set intentionally. Besides that I'm not sure if the parsing of the xml parser works correctly if the setup is properly done for latin1 encoding. Norbert

Jan. 10, 2011

Re: [Pharo-project] Issue 3525 in pharo: Compiler>>parserClass is broken and does not querying the class for providing the parser class

by Eliot Miranda

On Mon, Jan 10, 2011 at 12:42 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/1/10 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Mon, Jan 10, 2011 at 11:42 AM, Nicolas Cellier > > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> > >> Will it work ? > >> > >> because Compiler class>>new > >> ^ super new parser: self parserClass new > >> > >> sets the parser ivar with Compiler parserClass new. > >> Maybe you'll need to remove this definition of new too. > > > > I think it works. Behavior>>parser class gets compilerClass parserClass: > > Behavior>>parserClass > > "Answer a parser class to use for parsing method headers." > > ^self compilerClass parserClass > > So one is supposed to implement a Compiler subclass that defines a > > class-side parserClass method. e.g. > > MySpecialClass>>compilerClass > > ^MySpecialCompiler > > MySpecialCompiler class>>parserClass > > ^MySpecialParser > > So then > > Compiler>>parserClass > > ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: > [parser > > class] > > will also find MySpecialParser. > > Yes, its heavyweight because the Compiler subclass isn't providing > anything > > other than the reference to the parser. But that's the way the system is > > written so far. > > what do you think? > > best > > Eliot > > I think you are right, the system is like that, and if I remember > already was in st80 v2.3. > I used this feature, but my CustomCompiler didn't have many methods, > mostly #parserClass. > So we have a right to question this implementation. > I think the bug is that classes are expected to answer compiler and parser classes, not compiler and parser instances. If things were organized like this: Behavior>parserClass ^Parser Behavior>compilerClass ^Compiler Behavior>newParser ^self parserClass new Behavior>newCompiler ^self compilerClass new parser: self newParser and the compilation utility methods used "self newCompiler" then one could implement just parserClass to obtain the desired effect. What do you think? best Eliot > > Nicolas > >

Jan. 10, 2011

Re: [Pharo-project] additional font size?

by Alain Plantec

Hi Mariano, see http://code.google.com/p/pharo/issues/detail?id=2986 My position is that we should remove acuny and load some of the DejaVu fonts in the core in order to make the demo mode working for every one. Now, yes, a loader can be added in the setting browser. I can't do it now. If someone wants to make it, it's pretty simple, just look at GraphicFontSettings class>>standardFontsSettingsOn: standardFontsSettingsOn: aBuilder <systemsettings> (aBuilder group: #standardFonts) label: 'Standard fonts' translated; target: StandardFonts; parent: #appearance; order: 4; with: [ (aBuilder launcher: #updateFromSystem) order: 1; target: FreeTypeFontProvider; targetSelector: #current; description: 'Update available fonts by scanning the current system'; script: #updateFromSystem; label: 'Update fonts from system' translated. .... Cheers Alain Le 10/01/2011 22:24, Mariano Martinez Peck a Ã©crit : > Alain, maybe we can add a buttton or something like that in the > settings, that just runs the gofer script to load those fonts? > > Suppose you can see "To download DejaVU Sans between 5 and 24 click > here" or something like that in the fonts configuration. > > Once again, I suggest to include such package in the dev image. It is > also useful for Demos. > > cheeers > > mariano > > On Mon, Jan 10, 2011 at 9:43 PM, Alain Plantec <alain.plantec(a)free.fr > <mailto:alain.plantec@free.fr>> wrote: > > yes, all sizes from 5 to 24 are available. > > Le 10/01/2011 21:28, Tudor Girba a Ã©crit : > > Indeed, this would probably go well with Mondrian. > > Is there a way to obtain DejaVu Sans lower than 7? > > Cheers, > Doru > > > >

Jan. 10, 2011

Re: [Pharo-project] Issue 3526 in pharo: Update bug reporting instructions now that new issues are automatically posted to mailing list

by pharo＠googlecode.com

Updates: Cc: adrian.lienhard Comment #1 on issue 3526 by marianopeck: Update bug reporting instructions now that new issues are automatically posted to mailing list http://code.google.com/p/pharo/issues/detail?id=3526 thanks sean. Adrian can you update?

Jan. 10, 2011