- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec error

by Sean P. DeNigris

I manually fed in an instance of by changing the code to: actionToPerformWithSelector: selector arguments: args | instance | instance := spec instance. instance = #DialogWindowSpec ifTrue: [ instance := SpecDialogWindow new ]. ^ instance perform: selector withArguments: args But then I got: MessageNotUnderstood: ByteSymbol>>changeTableLayout (where the symbol was #Panel) It seems that #actionToPerformWithSelector:arguments: expects "spec instance" to return an actual instance, but is getting Symbols instead. It seems to be a bug in Spec because none of this has anything to do with my code, and if I change "self new openDialogWithSpec" to "self new openWithSpec" it opens correctly. On Oct 16, 2013, at 1:01 PM, "Benjamin Van Ryseghem-2 [via Smalltalk]" <ml-node+s1294792n4715064h72(a)n4.nabble.com> wrote: > Try replacing it with DlalogWindowModel > > Ben > > On Oct 16, 2013, at 5:27 PM, Sean P. DeNigris <[hidden email]> wrote: > >> Benjamin Van Ryseghem-2 wrote >>> Without further information, I can not do much more >> >> I sent #openDialogWithSpec, and the offending symbol is #DialogWindowSpec >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Spec-error-tp4714069p4715018.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/Spec-error-tp4714069p4715064.html > To unsubscribe from Spec error, click here. > NAML ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-error-tp4714069p4715081.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 16, 2013

Re: [Pharo-dev] default monospaced code font

by Nicolas Cellier

Very good comparison, thanks! Source code pro is so disgracious to my eyes, I can't stand it. Source code sans 10 not that bad. But my old eyes are much more comfortable with dejaVu, even if less code fits. 2013/10/16 <btc(a)openinworld.com> > Goubier Thierry wrote: > >> >> >> Le 16/10/2013 11:50, Sven Van Caekenberghe a Ã©crit : >> >>> >>> On 16 Oct 2013, at 10:20, Goubier Thierry <thierry.goubier(a)cea.fr> >>> wrote: >>> >>> Interesting display, Sven. >>>> >>>> My take on that: >>>> >>>> * Aesthetics: the system has two fonts, not one. -1 if I review a >>>> document with more than one font. >>>> >>> >>> In all documents, you have at least two fonts: body and headings, often >>> quotes, examples, listings, etc have an another font to make them stand >>> out. In the new approach, the idea is that monospaced fonts indicate code >>> (in browsers, debuggers, workspaces). It is a useful principle. >>> >> >> You're right. But nobody would dare write headings in a monospaced font >> :) unless for an art project. >> >> * Coherence / uniformity: A class name, a method selector has a >>>> different shape in the GUI (proportional) than in the code (monospaced). >>>> Are they different objects? Can I recognize my class name in the code >>>> without reading it? >>>> >>> >>> Syntax highlighting should take care of that I guess. >>> >> >> I don't think so. This is no by making the selector green that it will >> look more like the proportional version in the pane above. >> >> Kind of disrupting the uniformity of the underlying model, when I'm >> pushing for things like smart suggestions where the GUI understands the >> objects written in the code. >> >> I think that if the monospaced font is a point size smaller that the >>> main sans font (e.g. 12 and 11) the excessive width problem or visual shock >>> is much more manageable. In any case, I am giving it a try. >>> >> >> Probably. But then individual characters may become harder to read and >> distinguish... sort of compromising character readability to make space for >> the added whitespace inherent to the monospaced font. >> >> I'd be more impressed if the argument was helping me distinguish between >> | and l. >> > > Yes. It is designed to do that. Some common failings of monospaced fonts > are noted [1] and dealt with. There comment section is also interesting. > > The attached PDFs are the result of getting the urge to compare a broad > coverage of code examples (taken from "Terse Guide to Squeak") against > three fonts: > * DejaVu Sans 9 point > * Source Code Pro [1] [2] 9 point > * Source Sans Pro [3] [4] 9 point & 10 point, since the width of 10 was > the same as the others at 9. > Also attached is the source excel file. > > cheers -ben > > [1] http://blogs.adobe.com/**typblography/2012/09/source-**code-pro.html<http://blogs.adobe.com/typblography/2012/09/source-code-pro.html> > [2] http://sourceforge.net/**projects/sourcecodepro.adobe/**files/<http://sourceforge.net/projects/sourcecodepro.adobe/files/> > [3] http://blogs.adobe.com/**typblography/2012/08/source-**sans-pro.html<http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html> > [4] http://sourceforge.net/**projects/sourcesans.adobe/** > postdownload?source=dlp<http://sourceforge.net/projects/sourcesans.adobe/postdownload?source=dlp> > > >> I'l let you try, then :) >> >> Thierry >> > >

Oct. 16, 2013

Re: [Pharo-dev] [Moose-dev] [ann] system attraction view

by Chris Cunningham

That does sound interesting. So the new (student-based) force algorithm would allow for a 'everything is equal' default, or set a certain class of things as more important than others. Or maybe a hierarchy of things a more important (so, classes most important, then packages, then whatever is left over). I haven't yet personally figured out how I would apply this yet (even the original use), but I am definitely thinking on it. And, yes, if I do find a use, it will probably be outside of software as well. I am really enjoying this toolset known as Moose - both for software analysis, and other business-related analysis. -Chris On Wed, Oct 16, 2013 at 10:12 AM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > >> For example, if you want to connect methods with their defining > classes, and have many classes on screen. It is more important to have a > strong repulsion between the classes, than having the methods of a class > repulsing from methods from another class. > > > > I like the idea, but what do you mean by domain-specific ? > > Do you want to visualize something else than software ? > > The force base layout gives to all the edges and nodes the same value. But > maybe, if you can tell that some nodes are more important than other, then > the complexity can be significantly reduced. > > The algo can be used for anything that is represented as a graph. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Oct. 16, 2013

Re: [Pharo-dev] TxText status (was Re: bug: [4993] Typing cmd+L cancel all typing and we can't undo it [Terminated] )

by btc＠openinworld.com

StÃ©phane Ducasse wrote: > - I want a way to get the complete history of pharo and even do senders/implementors in the past :) > > That would be very cool. cheers -ben

Oct. 16, 2013

Re: [Pharo-dev] default monospaced code font

by btc＠openinworld.com

Goubier Thierry wrote: > > > Le 16/10/2013 11:50, Sven Van Caekenberghe a Ã©crit : >> >> On 16 Oct 2013, at 10:20, Goubier Thierry <thierry.goubier(a)cea.fr> >> wrote: >> >>> Interesting display, Sven. >>> >>> My take on that: >>> >>> * Aesthetics: the system has two fonts, not one. -1 if I review a >>> document with more than one font. >> >> In all documents, you have at least two fonts: body and headings, >> often quotes, examples, listings, etc have an another font to make >> them stand out. In the new approach, the idea is that monospaced >> fonts indicate code (in browsers, debuggers, workspaces). It is a >> useful principle. > > You're right. But nobody would dare write headings in a monospaced > font :) unless for an art project. > >>> * Coherence / uniformity: A class name, a method selector has a >>> different shape in the GUI (proportional) than in the code >>> (monospaced). Are they different objects? Can I recognize my class >>> name in the code without reading it? >> >> Syntax highlighting should take care of that I guess. > > I don't think so. This is no by making the selector green that it will > look more like the proportional version in the pane above. > > Kind of disrupting the uniformity of the underlying model, when I'm > pushing for things like smart suggestions where the GUI understands > the objects written in the code. > >> I think that if the monospaced font is a point size smaller that the >> main sans font (e.g. 12 and 11) the excessive width problem or visual >> shock is much more manageable. In any case, I am giving it a try. > > Probably. But then individual characters may become harder to read and > distinguish... sort of compromising character readability to make > space for the added whitespace inherent to the monospaced font. > > I'd be more impressed if the argument was helping me distinguish > between | and l. Yes. It is designed to do that. Some common failings of monospaced fonts are noted [1] and dealt with. There comment section is also interesting. The attached PDFs are the result of getting the urge to compare a broad coverage of code examples (taken from "Terse Guide to Squeak") against three fonts: * DejaVu Sans 9 point * Source Code Pro [1] [2] 9 point * Source Sans Pro [3] [4] 9 point & 10 point, since the width of 10 was the same as the others at 9. Also attached is the source excel file. cheers -ben [1] http://blogs.adobe.com/typblography/2012/09/source-code-pro.html [2] http://sourceforge.net/projects/sourcecodepro.adobe/files/ [3] http://blogs.adobe.com/typblography/2012/08/source-sans-pro.html [4] http://sourceforge.net/projects/sourcesans.adobe/postdownload?source=dlp > > I'l let you try, then :) > > Thierry

Oct. 16, 2013

Re: [Pharo-dev] Old Compiler is now unload able!

by StÃ©phane Ducasse

> Too bad :( > One of the most brilliant anti-pattern onto which I burnt so many brain cells is gone, > how are we going to teach good coding practices by counter examples. > ;) :) We should continue to build the new generation it is more exciting and now I can start to invest in reading the compiler code. Stef

Oct. 16, 2013

Re: [Pharo-dev] [Moose-dev] [ann] system attraction view

by Alexandre Bergel

>> For example, if you want to connect methods with their defining classes, and have many classes on screen. It is more important to have a strong repulsion between the classes, than having the methods of a class repulsing from methods from another class. > > I like the idea, but what do you mean by domain-specific ? > Do you want to visualize something else than software ? The force base layout gives to all the edges and nodes the same value. But maybe, if you can tell that some nodes are more important than other, then the complexity can be significantly reduced. The algo can be used for anything that is represented as a graph. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 16, 2013

Re: [Pharo-dev] MorpgTreeMorph enable/disable?

by StÃ©phane Ducasse

Thanks Alain!!!! Esteban is enhancing Nautilus with some nice features and KILLING PackageInfo Stef On Oct 16, 2013, at 5:41 PM, Alain Plantec <alain.plantec(a)yahoo.com> wrote: > done. > a slice is in inbox > Cheers > Alain > > On 15 oct. 2013, at 20:14, plantec <alain.plantec(a)yahoo.com> wrote: > >> Hi Esteban, >> >> Le 15 oct. 2013 Ã 18:30, Esteban Lorenzano <estebanlm(a)gmail.com> a Ã©crit : >> >>> Hi, >>> >>> I'm working with MorphTreeMorph and I need to toggle enable/disable... and as far as I see is not implemented. >>> Any idea how can I do it? >> >> I will have a look >> cheers >> Alain >> >> >> >>> >>> Thanks, >>> Esteban >> >> > >

Oct. 16, 2013

Re: [Pharo-dev] Color is strange

by StÃ©phane Ducasse

I did it but my image went slugggggish. On Oct 16, 2013, at 4:55 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > haltOnce :) > > On 2013-10-16, at 16:53, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> put a halt >> >> XD >> >> Ben >> >> On Oct 16, 2013, at 4:49 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Hi guys >>> >>> I wonder if this is me that miss something importantâ¦ but here is what I did: >>> >>> Color>>printOn: aStream >>> | name | >>> Transcript show:'x'. >>> (name := self name) ifNotNil: >>> [ ^ aStream >>> nextPutAll: 'Color '; >>> nextPutAll: name ]. >>> self storeOn: aStream >>> >>> >>> then I type >>> >>> 1 makeAnError and execute it. >>> >>> and in the transcript I get >>> xxxxxxxxxxxxxxxxxxxxxSmallInteger >>> >>> I'm totally puzzled why would we printOn: color ? before even opening a browser. >>> >>> stef >> >

Oct. 16, 2013

Re: [Pharo-dev] Old Compiler is now unload able!

by Nicolas Cellier

Too bad :( One of the most brilliant anti-pattern onto which I burnt so many brain cells is gone, how are we going to teach good coding practices by counter examples. ;) 2013/10/16 Sean P. DeNigris <sean(a)clipperadams.com> > StÃ©phane Ducasse wrote > > Well said! > > Indeed :) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Old-Compiler-is-now-unload-able-tp4714845p4715017.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 16, 2013