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

Re: [Pharo-project] additional font size?

by Mariano Martinez Peck

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>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] additional font size?

by Alain Plantec

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 3525 in pharo: Compiler>>parserClass is broken and does not querying the class for providing the parser class

by Nicolas Cellier

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. Nicolas

Jan. 10, 2011

[Pharo-project] Issue 3527 in pharo: Please add the following Generator code to Pharo. I need it to port a package I am writing from Squeak to Pharo

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3527 by rpboland: Please add the following Generator code to Pharo. I need it to port a package I am writing from Squeak to Pharo http://code.google.com/p/pharo/issues/detail?id=3527 Squeak 4.1 has a class Generator which I use for a package I am developing for Squeak and would also like to port to Pharo. But Pharo doesn't have this class. I propose that this class (and class GeneratorTest) be ported to Pharo. I have attached the two .st files that need to be filed in. I have loaded them into Pharo1.1 and it appears to work. Note that since the code is in Squeak 4.1 it is MIT. I have also signed the Pharo code release form though you would really need the release form signed by Andreas Rass if that is an issue. The generators code was added to Squeak by Andreas Raas. The class Generator can be found in Squeak as a subclass of Stream. It's about 140 lines of code and, as I said before, is really useful. Class Generator is tested in class GeneratorTest which also serves as examples of uses of Generators. The following text is from the Generator class comment: " A Generator transforms callback interfaces into stream interfaces. When a producer algorithm provide results as callbacks (blocks) and a consumer algorithm expects streamable input, a Generator transforms one into the other, for example: | generator | generator := Generator on: [:g| Integer primesUpTo: 100 do:[:prime| g yield: prime]]. [generator atEnd] whileFalse:[Transcript show: generator next]. " Try it. You'll like it. Regards, Ralph Boland Attachments: GeneratorTest.st 4.7 KB

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 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 > Nicolas > > 2011/1/10 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Mon, Jan 10, 2011 at 9:46 AM, <pharo(a)googlecode.com> wrote: > >> > >> Status: Accepted > >> Owner: siguctua > >> > >> New issue 3525 by siguctua: Compiler>>parserClass is broken and does not > >> querying the class for providing the parser class > >> http://code.google.com/p/pharo/issues/detail?id=3525 > >> > >> In the following: > >> > >> Compiler>>parserClass > >> > >> ^parser ifNil: [self class parserClass] ifNotNil: [parser class] > > > > Who writes this stuff ?? ;) > > <blush> > > I suggest the attached: > > parserClass > > ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: > [parser > > class] > > > >> > >> 'self class' should actually be 'class parserClass' > >> > >> So, any class could override the default parser by own. In that way a > >> default parser class is answered by Behavior, not by Compiler. > >> A Compiler class>>parserClass is useless. > >> > >> > >> But even more than that, due to initializing 'parser' ivar in > >> Compiler>>new, > >> it never gets to that code, and evaluating 'parser class' > >> So, a class can't specify a custom parser class to compiler. > >> > >> > >> > >> > > > > > >

Jan. 10, 2011

Re: [Pharo-project] additional font size?

by Tudor Girba

Indeed, this would probably go well with Mondrian. Is there a way to obtain DejaVu Sans lower than 7? Cheers, Doru On 10 Jan 2011, at 19:36, Alexandre Bergel wrote: > Ok, I will check. > > Cheers, > Alexandre > > > On 10 Jan 2011, at 13:57, Sven Van Caekenberghe wrote: > >> >> On 10 Jan 2011, at 11:26, Alexandre Bergel wrote: >> >>> Hi! >>> >>> Apparently, the 1.2 image contains only the size 7, 9 and 12 for Bitmap DejaVu Sans. Can we get additional font sizes? Are there a vectorial font police supported in Pharo? I would like to be able to give any arbitrary font size. >>> >>> Cheers, >>> Alexandre >> >> You could load 'DejaVuBitmapFonts' from SqueakSource 'DejaVu'. >> You then get size 8,9,10,11,12,14,17 and 22. >> These also work on Cog. >> >> Sven >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- www.tudorgirba.com "Reasonable is what we are accustomed with."

Jan. 10, 2011

Re: [Pharo-project] aligning morphs

by Tudor Girba

Wow, that would be great! I cannot wait to test it. Cheers, Doru On 10 Jan 2011, at 16:50, Gary Chambers wrote: > I may get time later in the week to have a go with GeneralScrollPane to support the feature you desire... ;-) > > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Cc: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, January 10, 2011 2:23 PM > Subject: Re: [Pharo-project] aligning morphs > > > Hi Gary, > > Thanks for the reply. > > So, what would be required for scrollbars to work with spaceFill? I would really need this feature, but I do not know how to go about it. > > Could you or anyone else provide some hints? Of course code would be even better. But at this moment hi ts would be helpful, too :) > > Cheers, > Doru > > > > On Jan 10, 2011, at 13:04, "Gary Chambers" <gazzaguru2(a)btinternet.com> wrote: > >> Hi Doru, >> >> #spaceFill constraints are typically only used by table layouts. >> ScrollPane is designed for fixed size contents, at present. >> Might be nice to extend it to honour any #spaceFill of its single target morph. >> This would simplify usage of scrollers quite a bit! >> >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >> To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, January 08, 2011 1:22 AM >> Subject: [Pharo-project] aligning morphs >> >> >> >> Hi, >> >> I would need help with understanding the magic behind alignment in Morphic. >> >> Take the example from below. Could anyone help me with what I should do to have the morph stretch all the way horizontally? >> >> | scroll window morph | >> scroll := ScrollPane new. >> scroll >> fillStyle: (SolidFillStyle color: Color blue); >> vResizing: #spaceFill; >> hResizing: #spaceFill. >> morph := PanelMorph new. >> morph >> fillStyle: (SolidFillStyle color: Color yellow); >> changeTableLayout; >> listDirection: #topToBottom; >> vResizing: #shrinkWrap; >> hResizing: #spaceFill; >> layoutInset: 10. >> morph addMorphBack: (SimpleButtonMorph new width: 200; height: 200). >> scroll scroller addMorph: morph. >> window := SystemWindow new. >> window addMorph: scroll fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)). >> window openInWorld >> >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Every thing should have the right to be different." >> >> >> >> >> > > -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

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 Nicolas Cellier

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). Nicolas 2011/1/10 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 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. > > Nicolas > > 2011/1/10 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Mon, Jan 10, 2011 at 9:46 AM, <pharo(a)googlecode.com> wrote: >>> >>> Status: Accepted >>> Owner: siguctua >>> >>> New issue 3525 by siguctua: Compiler>>parserClass is broken and does not >>> querying the class for providing the parser class >>> http://code.google.com/p/pharo/issues/detail?id=3525 >>> >>> In the following: >>> >>> Compiler>>parserClass >>> >>> Â Â Â Â ^parser ifNil: [self class parserClass] ifNotNil: [parser class] >> >> Who writes this stuff ?? ;) >> <blush> >> I suggest the attached: >> parserClass >> ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: [parser >> class] >> >>> >>> 'self class' should actually be 'class parserClass' >>> >>> So, any class could override the default parser by own. In that way a >>> default parser class is answered by Behavior, not by Compiler. >>> A Compiler class>>parserClass is useless. >>> >>> >>> But even more than that, due to initializing 'parser' ivar in >>> Compiler>>new, >>> it never gets to that code, and evaluating 'parser class' >>> So, a class can't specify a custom parser class to compiler. >>> >>> >>> >>> >> >> >

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 Nicolas Cellier

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. Nicolas 2011/1/10 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Mon, Jan 10, 2011 at 9:46 AM, <pharo(a)googlecode.com> wrote: >> >> Status: Accepted >> Owner: siguctua >> >> New issue 3525 by siguctua: Compiler>>parserClass is broken and does not >> querying the class for providing the parser class >> http://code.google.com/p/pharo/issues/detail?id=3525 >> >> In the following: >> >> Compiler>>parserClass >> >> Â Â Â Â ^parser ifNil: [self class parserClass] ifNotNil: [parser class] > > Who writes this stuff ?? ;) > <blush> > I suggest the attached: > parserClass > ^parser ifNil: [(class ifNil: [self class]) parserClass] ifNotNil: [parser > class] > >> >> 'self class' should actually be 'class parserClass' >> >> So, any class could override the default parser by own. In that way a >> default parser class is answered by Behavior, not by Compiler. >> A Compiler class>>parserClass is useless. >> >> >> But even more than that, due to initializing 'parser' ivar in >> Compiler>>new, >> it never gets to that code, and evaluating 'parser class' >> So, a class can't specify a custom parser class to compiler. >> >> >> >> > >

Jan. 10, 2011

[Pharo-project] Font bug in 1.1.1

by Sean P. DeNigris

When I set the list font to Bitmap DejaVu Sans bold 12 and try to open an inspector, I get an error. I can't reproduce it in 1.2, but didn't find an issue for it. Partial stack trace: UndefinedObject(Object)>>doesNotUnderstand: #fontIndexOf: Receiver: nil Arguments and temporary variables: aMessage: fontIndexOf: a StrikeFont(Bitmap DejaVu Sans 12B 19) exception: MessageNotUnderstood: receiver of "fontIndexOf:" is nil resumeValue: nil Receiver's instance variables: nil StringMorphAttributeScanner>>initializeFromStringMorph: Receiver: a StringMorphAttributeScanner Arguments and temporary variables: aStringMorph: an IndentingListItemMorph(308543488)nil style: nil Receiver's instance variables: fontNumber: 1 textColor: nil emphasis: 1 alignment: nil actualFont: a StrikeFont(Bitmap DejaVu Sans 12B 19) indent: 0 kern: 0 -- View this message in context: http://forum.world.st/Font-bug-in-1-1-1-tp3207795p3207795.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 10, 2011