- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] default monospaced code font

by Igor Stasenko

On 17 October 2013 10:47, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 17/10/2013 10:29, Igor Stasenko a Ã©crit : > >> hmm.. i have suspicion that it is actually adobe who can't handle the >> font properly.. >> because in some examples for source code pro font, the adjacent letters >> jump onto each other. >> i don't believe it is that bad (see attached)Inline images 1 >> > > Adobe or the viewer? I used evince to view it, not acrobat reader. It may > point to incorrect spacing information in Source Sans Pro (I have not the > errors you see in Source Code Pro). > > Who is in charge of the Source Pro font? Which typographer? Oh, Adobe > apparently. If they can't handle it properly... > > i am far from blaming adobe, just wanted to say that in my viewer it does not shows things properly, because when rendered in pharo it don't have such problems. so i cannot have decent comparison.. > Thierry > > > >> On 17 October 2013 09:28, Goubier Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr**>> wrote: >> >> Excellent, I like the comparison a lot! Thanks! >> >> My take is: >> - Unable to like Source Code Pro 9 (and it's so wide); >> - Source Sans Pro 9 has spacing issues (16r, the r is too close) and >> reading issues (it's the worse for the lL|i characters) >> - Source sans Pro 10 is better than 9 (but what with the 2x space?) >> >> Overall, I'd stay with DejaVu Sans 9 based on this sample. In my >> opinion, the best compromise density / readability. >> >> Thierry >> >> Le 16/10/2013 19:56, btc(a)openinworld.com >> <mailto:btc@openinworld.com> a Ã©crit : >> >> >> Goubier Thierry wrote: >> >> 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> >> <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/> >> <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> >> <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> >> >> <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 >> >> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- Best regards, Igor Stasenko.

Oct. 17, 2013

Re: [Pharo-dev] default monospaced code font

by Igor Stasenko

hmm.. i have suspicion that it is actually adobe who can't handle the font properly.. because in some examples for source code pro font, the adjacent letters jump onto each other. i don't believe it is that bad (see attached)[image: Inline images 1] On 17 October 2013 09:28, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Excellent, I like the comparison a lot! Thanks! > > My take is: > - Unable to like Source Code Pro 9 (and it's so wide); > - Source Sans Pro 9 has spacing issues (16r, the r is too close) and > reading issues (it's the worse for the lL|i characters) > - Source sans Pro 10 is better than 9 (but what with the 2x space?) > > Overall, I'd stay with DejaVu Sans 9 based on this sample. In my opinion, > the best compromise density / readability. > > Thierry > > Le 16/10/2013 19:56, btc(a)openinworld.com a Ã©crit : > > Goubier Thierry wrote: >> >>> 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 >>> >> >> > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- Best regards, Igor Stasenko.

Oct. 17, 2013

Re: [Pharo-dev] default monospaced code font

by Igor Stasenko

On 16 October 2013 18:31, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Igor, > > > > On Wed, Oct 16, 2013 at 1:33 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 15 October 2013 18:36, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> >>> On 10/15/2013 11:06 AM, Esteban Lorenzano wrote: >>> >>> *From: *Eliot Miranda <eliot.miranda(a)gmail.com> >>> >>> >>> >>>> Progress is possible, >>> >>> >>> Indeed it is. And moving from proportional to mono-spaced fonts is >>> not progress, it is regress. >>> >>> >>>> perfection was not achieved in 81 or in 95. >>>> >>> >>> I didn't say it was. I said that systems designed with a coherent >>> aesthetics and philosophy are more coherent, powerful and comprehensible >>> than those which are not. >>> >>> >>> yes, they are, I agree with that, and that's what we are trying to >>> achieve... advancing one small step at a time, because we cannot doit all >>> together, sadly. >>> What I do not see is how proportional fonts fits more with a pharo >>> coherence (which in my pov does not exists today) than a monospaced one. >>> >>> >>> But the change is away from proportional to monospace. I think the sale >>> must be made as to what does that actually buy us. How does this improve >>> our experience, pharo coherence? >>> >>> It seems that many of us here don't believe that it provides that >>> coherence of UI/UX that your hoping to move us towards. >>> >>> So when changing from what we have, it seems that it needs to >>> demonstrated that the change is for the better and not neutral or worse. >>> >>> I personally don't buy the it is less foreign to non-Smalltalkers >>> argument. non-Smalltalkers would just move their distaste of Smalltalk >>> somewhere else. Why do we have to use the image? Why can't I use Emacs, >>> vim, Eclipse? Its all very personal and sometimes very visceral. >>> >>> I have seen some visceral comments from Igor regarding Python. I could >>> make some from the C++ I've been looking at. >>> >>> >> ah.. python. yes, i hate their choice of using white space as part of >> language syntax. >> That is really retarded choice. >> > > Slurring the off-side rule <http://en.wikipedia.org/wiki/Off-side_rule>with "retarded" is simply childish. I should declare that I knew and > admired the inventor of the off-side rule, Peter Landin, for quite a few > years at Queen Mary. And a more intelligent man you couldn't hope to meet. > The off-side rule is a considered design, it is used by lots of languages, > especially those in the functional tradition (e.g. Haskell and Curry), it > is simple and elegant, and for people brought up in that tradition I'm sure > it seems extremely natural. Like Smalltalk, these languages are concise, > having a minimal ammount of supporting syntax for declarations. The > off-side rule means no open and close braces, and what a field of > disagreement over code aesthetics that eliminates. > > "retarded"? Come on, how about some thought and criticism? > > I simply don't like it. Don't treat my criticism as a constructive one. It is emotional :) >From other side, imagine that i invent rule that you should terminate statements not with period, but with white space (lets say tab). I bet, i will find some followers in the world, who will praise my design choice as extremely natural :) > > >> And actually the roots of my disdain of it is same why i prefer >> proportional fonts: >> i like text, where white space is variable and not fixed, and used to >> make the text more readable, >> and ergonomically fit within its boundaries (like in newspaper column). >> > > But that doesn't militate against the off-side rule (which doesn't have to > be based on space count, or assuming tab with is 8, or..., simply needs to > be based on the clear appearance of indentation, and there are presumably > implementation choices there). > > the bad thing about it that without special support in editors/tools it is going to be broken. just for experiment try to copy and paste python code into html and see if you can read it (and don't tell me that i should put it into <pre> tag). It is again, because in writing, white space was invented to separate words, not letters or statements or something else. For other things there is punctuation. So, as long as we're talking about text (be it source code or not), i prefer that such rule is persisted, and if we're talking about diagrams or some other variants of visual programming (like in sketch), i don't care. > If for people it would be easier to read text printed with monospaced >> font, then it would be like that >> long before first computer display appear in the world. >> Therefore, the whole idea that monospaced font is more readable is moot. >> > > Agreed. > > >> I could justify such choice if we would have certain technical >> limitations (of the past), which forcing us to use >> less memory and text terminals.. but we're not.. >> > > Agreed. > > > And please forgive my outburst the other day. > >> >> We need to be the best open source Smalltalk-like experience. And not be >>> constrained to other languages/editors/environments constraints and views >>> on the world. >>> >>> So those who choose to advocate for a change. Advocate. Make the sale. >>> Or else lets not make the change. >>> >>> Jimmie >>> >> > -- > best, > Eliot > -- Best regards, Igor Stasenko.

Oct. 17, 2013

Fogbugz workflow

by Ben Coman

A further query on workflow with FogBugz. It seems the Galactic Monkey From Outer Space picks up Cases with status 'Resolved (Fix Review Needed)'. When that is succcessful, what is the next step? Should I being changing the status to 'Resolved (Fix To Include)' myself or is further human review required? Referring to https://pharo.fogbugz.com/default.asp?11835 this Case now doesn't appear in any of the Work Needed, Integration nor Review filters. Hence my query about the next step. cheers -ben

Oct. 17, 2013

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

by Camillo Bruni

On 2013-10-16, at 17:22, 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 one problem is that you still have to reset your password to be able to log in.

Oct. 17, 2013

Re: [Pharo-dev] default monospaced code font

by Goubier Thierry

Excellent, I like the comparison a lot! Thanks! My take is: - Unable to like Source Code Pro 9 (and it's so wide); - Source Sans Pro 9 has spacing issues (16r, the r is too close) and reading issues (it's the worse for the lL|i characters) - Source sans Pro 10 is better than 9 (but what with the 2x space?) Overall, I'd stay with DejaVu Sans 9 based on this sample. In my opinion, the best compromise density / readability. Thierry Le 16/10/2013 19:56, btc(a)openinworld.com a Ã©crit : > Goubier Thierry wrote: >> 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 > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 17, 2013

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

by Goubier Thierry

Le 16/10/2013 14:00, StÃ©phane Ducasse a Ã©crit : > >>> thierry >>> >>> the one of alain is a simple do/undo now Epicea is a new changes model developed by martin and >>> you raised a good point, we should look if Epicea could be used for RB undo. >> >> My point is: undo/redo is one API (Alain's), EPICEA would specialize that for code changes, and RB is also for code changes (is EPICEA able to represent RB operations?). > > We should check that. > >> >> Also, would EPICEA come with a merge capability? It would beat any versionning system out there by providing better history understanding. > > This is exactly the goal of the phd of martin. > - better supporting merging Cool. > - I want a way to get the complete history of pharo and even do senders/implementors in the past :) This one is easy if you have a git repo below :) Partly implemented already, Stef... Just waiting for the rest of the system to catch up. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 17, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30494 Home: https://github.com/pharo-project/pharo-core

Oct. 17, 2013

[pharo-project/pharo-core] bd843d: 30494

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: bd843d375dd7c24ea5af9158193fd5e567e98413 https://github.com/pharo-project/pharo-core/commit/bd843d375dd7c24ea5af9158… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-17 (Thu, 17 Oct 2013) Changed paths: M CollectionsTests-Support.package/WideCharacterSetTest.class/instance/testing/testAddingToCharacterSet.st M NewList-Example.package/NewListExample.class/instance/initialize/buildMorphWithOld.st M NewList-Example.package/NewListExample.class/instance/initialize/openInWindow.st M NewList-Example.package/NewListExample.class/instance/initialize/openInWorld.st M NewList-Example.package/NewListExample.class/instance/morphic/setIndex_.st M NewList.package/NewList.class/instance/events - keyboard/basicKeyPressed_.st M NewList.package/NewList.class/instance/updating - private/updateHeaderHeight.st M NewList.package/NewListAdapter.class/instance/list protocol/getMenu_.st M SUnit-Core-Kernel.package/TAssertable.class/instance/asserting/shouldnt_raise_.st M SUnit-Core-Kernel.package/TAssertable.class/instance/asserting/shouldnt_raise_description_.st M SUnit-Core-Kernel.package/TAssertable.class/instance/asserting/shouldnt_raise_whoseDescriptionDoesNotInclude_description_.st M SUnit-Core-Kernel.package/TAssertable.class/instance/asserting/shouldnt_raise_whoseDescriptionIncludes_description_.st A SUnit-Core-Kernel.package/TAssertable.class/instance/asserting/validateShouldntException_.st M SUnit-Tests-Core.package/SUnitExtensionsTest.class/instance/tests/testExceptionWithoutMatchingString.st M SUnit-Tests-Core.package/SUnitExtensionsTest.class/instance/tests/testNoExceptionWithMatchingString.st M SUnit-Tests-Core.package/SUnitExtensionsTest.class/instance/tests/testNoExceptionWithNoMatchingString.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script149.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30494.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions-Menu.package/SugsAbstractContext.class/definition.st A SmartSuggestions-Menu.package/SugsAbstractContext.class/instance/accesing/isMethodSelected.st A SmartSuggestions-Menu.package/SugsAbstractContext.class/instance/private/selectedStatements.st A SmartSuggestions-Menu.package/SugsAbstractContext.class/instance/private/selectedTemporaryVariables.st M SmartSuggestions-Menu.package/SugsAbstractContext.class/instance/selection/selectTheTextForTheNode.st A SmartSuggestions-Menu.package/SugsAbstractContext.class/instance/selection/selectedStatementsAsSequence.st A SmartSuggestions-Menu.package/SugsAbstractContext.class/instance/selection/selectedStatementsAsText.st Log Message: ----------- 30494 11913 Trivial critic clean NewList https://pharo.fogbugz.com/f/cases/11913 11876 Do not allow shouldnt:raise: Error https://pharo.fogbugz.com/f/cases/11876 11879 Obtain selected statements for suggestions https://pharo.fogbugz.com/f/cases/11879 http://files.pharo.org/image/30/30494.zip

Oct. 17, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… 1 regressions found. Zinc.Tests.ZnServerTests.testEntityTooLarge

Oct. 17, 2013