October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [OT] Free pie for Pharo?

by btc＠openinworld.com

Torsten Bergmann wrote: > https://raymii.org/s/static/Free_Raspberry_Pi.html > > > GPL

Oct. 17, 2013

Re: [Pharo-dev] https://pharo.fogbugz.com ??

by Alexandre Bergel

Thanks! I can log in now Cheers, Alexandre On Oct 16, 2013, at 12:22 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > abergel wrote >> How can I create a login on https://pharo.fogbugz.com ? >> I have created a login on bugs.pharo.org. I am not sure how does this >> differ from the fogbugz... > > The login you created should work for fogbugz. Now that we have a permalink > to the registration page, I've added it to the fogbugz welcome page. HTH > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/https-pharo-fogbugz-com-tp4714366p4715016.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 16, 2013

[OT] Free pie for Pharo?

by Torsten Bergmann

https://raymii.org/s/static/Free_Raspberry_Pi.html

Oct. 16, 2013

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

by Nicolas Cellier

And for the curious my favourite brainfuck was code:type: and its senders. Because the first time you read (code: index type: type), you wonder * why you pass a parameter index (that overrides inst var index, but most caller invoke with index inst. var.) * with the key code: * since there is also an inst var named code that's really troubling... Also because there is a cryptic use of negated type on return And once you start analyzing senders, and inst var refs, you're puzzled... To decipher, code:type: answers an encoded bytecode, made from an index (temp index, inst var index etc..) and a type (load inst var, load temp var, etc...) thus its name code... Now, I've contemplated this code too much, and it almost sounds familiar, I can hardly remember how impenetrable it was. But make you a pleasure, put a newbie in front of it. To me, this a a very clever factorisation of bytecode encoding - much too clever - much too obfuscated - and I bet we can do much much clearer with not much more code. But I don't have to prove anything, there is Opal already... 2013/10/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > 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] default monospaced code font

by Norbert Hartl

Am 16.10.2013 um 21:43 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 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. > +1 to every sentence Norbert > > 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 > [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] 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