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

[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… 2 regressions found. Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits Zinc.Tests.ZnServerTests.testEntityTooLarge

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. Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits

Oct. 17, 2013

Re: [Pharo-dev] Smalltalkhub is exposing private information

by Nicolas Petton

Thanks, I'll fix the issue with the next release (It's overdue already). Cheers, Nico Norbert Hartl writes: > When you look at someones page you can read commit messages of packages that belong to a private project. You can't see the project nor the package but it is listed in recent activities. I filed a bug > > https://code.google.com/p/smalltalk-hub/issues/detail?id=32 > > Norbert -- Nicolas Petton http://nicolas-petton.fr

Oct. 17, 2013

Re: [Pharo-dev] IMPORTANT: RPackage behavior changed and Nautilus updated

by Goubier Thierry

AltBrowser is a tree based system browser for Pharo. It shows you the entire system as a tree, from groups of packages down to the methods, with a code pane on the left. It is refactoring aware and has RB-based filtering; it also replaces the finder and the message browser (i.e., as in old system browsers, you can specialize it to a subset: a package, a class, a list of methods). It's stable enough for development work, without all the features of Nautilus, but a nice subset of. There is a configuration available, with the version for Pharo2 stable, but the version for Pharo3 has just switched from stable to unstable :):) I join a screenshot, where you can see various stages of filtering with the finder. Thierry Le 17/10/2013 16:48, Alexandre Bergel a Ã©crit : > What is the AltBrowser? > Any screenshot? > > Alexandre > >> Le 17-10-2013 Ã 7:52, Goubier Thierry <thierry.goubier(a)cea.fr> a Ã©crit : >> >> Hi Esteban, >> >> thanks. This annoucement is very much appreciated, and will help me switch to the new RPackage. >> >> Have you changed things in the announcements as well (RPackage created / modified / unregistered?) >> >> Thierry >> >> Le 17/10/2013 12:20, Esteban Lorenzano a Ã©crit : >>> Hi, >>> >>> I just important an important change in Pharo. >>> I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. >>> Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) >>> I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. >>> >>> So, what's the change? >>> Now 1 RPackage 0 1 MCPackage. >>> As a result, package granularity is coarse, and then categories for class are stored as package tags. >>> Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) >>> This change opens the path to remove old PackageInfo, finally :) >>> >>> To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) >>> And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) >>> >>> THERE WILL BE BUGS! >>> This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! >>> Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) >>> >>> Please, report any issue around. >>> >>> Enjoy, >>> Esteban >> >> -- >> 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 >> > > > -- 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] IMPORTANT: RPackage behavior changed and Nautilus updated

by Alexandre Bergel

What is the AltBrowser? Any screenshot? Alexandre > Le 17-10-2013 Ã 7:52, Goubier Thierry <thierry.goubier(a)cea.fr> a Ã©crit : > > Hi Esteban, > > thanks. This annoucement is very much appreciated, and will help me switch to the new RPackage. > > Have you changed things in the announcements as well (RPackage created / modified / unregistered?) > > Thierry > > Le 17/10/2013 12:20, Esteban Lorenzano a Ã©crit : >> Hi, >> >> I just important an important change in Pharo. >> I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. >> Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) >> I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. >> >> So, what's the change? >> Now 1 RPackage 0 1 MCPackage. >> As a result, package granularity is coarse, and then categories for class are stored as package tags. >> Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) >> This change opens the path to remove old PackageInfo, finally :) >> >> To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) >> And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) >> >> THERE WILL BE BUGS! >> This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! >> Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) >> >> Please, report any issue around. >> >> Enjoy, >> Esteban > > -- > 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] Fogbugz workflow

by btc＠openinworld.com

Camillo Bruni wrote: > it is currently working fine, no? > the "status:review" also matches the "Fix Reviewed by the Monkey" status. > Whoops. Yes it works as expected - I must be going mad. > On 2013-10-17, at 14:39, btc(a)openinworld.com wrote: > >> Thanks Camillo. So if the Shared Filter > Review displays cases waiting for human review, should it be updated to... >> (status:review or status:reviewed) and area:"1. Pharo Image" >> >> cheers -ben >> >> Camillo Bruni wrote: >> >>> The idea would be that the monkey filters out most of the typical bugs and that then >>> a human (other than the submitter) reviews the code manually and puts it fix-to-include ;) >>> >>> On 2013-10-17, at 10:16, Ben Coman >>> <btc(a)openInWorld.com> >>> wrote: >>> >>> >>> >>> >>>> 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] default monospaced code font

by Goubier Thierry

Oh, ok, thanks for the explanation. I noticed effectively that switching to Source Sans 10 increased significantly the density (copying the Source Sans font files in /usr/local/share/fonts/ made them visible to Pharo), and that, it solved the MNU on unicode glyphs as well. So all is well with the Source Sans Pro and I'm happy. Thierry Le 17/10/2013 15:22, btc(a)openinworld.com a Ã©crit : > > what with the 2x space? > > Something I like about Source Code Pro is the greater spacing between > identifiers. In comparison, I found DejaVu Sans and Source Sans Pro to > be too dense, especially so with the latter. So I experimented with > doubling the size of that space with the proportional fonts. I just > Search-Replaced <space> with <space-space>, but in an IDE you could use > one of the wider space character like the EN-QUAD [5]. Except the > performance with Unicode versus ascii characters would need to be > checked. I've attached a some more comparisons of identifier spacing. > Sorry I mislead you with the Source Sans Pro 2X-spacing in previous > PDF. You wont get that exactly out of the box without some code changes > to use a wider space character. Check you opinion against the 1X-spacing. > cheers -ben > > [5] http://www.cs.tut.fi/~jkorpela/chars/spaces.html > > > > Goubier Thierry 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 >>> [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] IMPORTANT: RPackage behavior changed and Nautilus updated

by Esteban Lorenzano

yes, because package names changed (no more 1 rpackage = 1 system category), then the export of sources changed too (not the contents). For example, what was AST-Core-*, now is just AST-Core. Esteban On Oct 17, 2013, at 2:51 PM, Marcus Denker <marcus.denker(a)gmail.com> wrote: > > >> On 17.10.2013, at 13:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> Strange... the commit is already there :) >> > > > too large for the list (7mb) >> https://github.com/pharo-project/pharo-core/commit/39e14deac5f2ad03e2d1b539… >> >>> On 2013-10-17, at 13:08, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> he... the update is already there, github failed to send the diff info (yet) >>> >>>> On Oct 17, 2013, at 1:09 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>> >>>> >>>> >>>> Le 17/10/2013 12:51, Esteban Lorenzano a Ã©crit : >>>>> >>>>> On Oct 17, 2013, at 12:57 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>>>> >>>>>> Are you using MorphTreeMorph? >>>>> yep :) >>>> >>>> I haven't tried to use multi-selection in the tree; the code to handle multi-selection looks fairly complex. >>>> >>>> I remember having difficulties to understand how to pass and receive objects through drag and drop. >>>> >>>> I'll have a look as soon as I see the update coming. Unless loading the last Nautilus packages in Pharo3Inbox works :) >>>> >>>> Thierry >>>> >>>>>> >>>>>> Thierry >>>>>> >>>>>> Le 17/10/2013 12:46, Esteban Lorenzano a Ã©crit : >>>>>>> btw, a couple things that I know still doesn't work in Nautilus with trees: >>>>>>> >>>>>>> - drag and drop (I failed miserably when trying to implement it, any help here would be welcome :) >>>>>>> - multiselection in packages >>>>>>> >>>>>>> Esteban >>>>>>> >>>>>>> >>>>>>>> On Oct 17, 2013, at 12:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I just important an important change in Pharo. >>>>>>>> I made a new step over the integration of RPackage into the system, and as a result there is a different behavior. >>>>>>>> Although 99% of users shouldn't notice it, that can drive to headaches to tool developers, like Thierry and his AltBrowser (but I'm not sure about that) :) >>>>>>>> I'm sorry, but this is inevitable... and part of a long path discussed and adopted since almost 1 1/2 years. >>>>>>>> >>>>>>>> So, what's the change? >>>>>>>> Now 1 RPackage 0 1 MCPackage. >>>>>>>> As a result, package granularity is coarse, and then categories for class are stored as package tags. >>>>>>>> Other consequence is that RPackageSet is now more or less useless, but I'm keeping it because it provides caching services for monticello, and the speed up resulting is good :) >>>>>>>> This change opens the path to remove old PackageInfo, finally :) >>>>>>>> >>>>>>>> To take the new structure into account (and to add a long time awaited feature), I modified nautilus to use a tree instead a simple list (finally!) >>>>>>>> And since I was in the mood, I moved groups to same list, taking the idea of the screenshot Stef sent the other day (lots of good ideas that we should adopt there), and then I removed the "groups" button... in functionality is good, but visually not so much... I accept ideas about :) >>>>>>>> >>>>>>>> THERE WILL BE BUGS! >>>>>>>> This is a really deep and important change, I'm pushing it because we need to test and fix. So, do not hesitate to send your reports! >>>>>>>> Also, there are features in modified-nautilus that are missing. It would be good to have a list of them so I can implement it :) >>>>>>>> >>>>>>>> Please, report any issue around. >>>>>>>> >>>>>>>> Enjoy, >>>>>>>> Esteban >>>>>> >>>>>> -- >>>>>> 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 >>>> >>>> -- >>>> 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] default monospaced code font

by btc＠openinworld.com

> what with the 2x space? Something I like about Source Code Pro is the greater spacing between identifiers. In comparison, I found DejaVu Sans and Source Sans Pro to be too dense, especially so with the latter. So I experimented with doubling the size of that space with the proportional fonts. I just Search-Replaced <space> with <space-space>, but in an IDE you could use one of the wider space character like the EN-QUAD [5]. Except the performance with Unicode versus ascii characters would need to be checked. I've attached a some more comparisons of identifier spacing. Sorry I mislead you with the Source Sans Pro 2X-spacing in previous PDF. You wont get that exactly out of the box without some code changes to use a wider space character. Check you opinion against the 1X-spacing. cheers -ben [5] http://www.cs.tut.fi/~jkorpela/chars/spaces.html Goubier Thierry 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 >> [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. 17, 2013

Re: [Pharo-dev] Fogbugz workflow

by Camillo Bruni

it is currently working fine, no? the "status:review" also matches the "Fix Reviewed by the Monkey" status. On 2013-10-17, at 14:39, btc(a)openinworld.com wrote: > Thanks Camillo. So if the Shared Filter > Review displays cases waiting for human review, should it be updated to... > (status:review or status:reviewed) and area:"1. Pharo Image" > > cheers -ben > > Camillo Bruni wrote: >> The idea would be that the monkey filters out most of the typical bugs and that then >> a human (other than the submitter) reviews the code manually and puts it fix-to-include ;) >> >> On 2013-10-17, at 10:16, Ben Coman >> <btc(a)openInWorld.com> >> wrote: >> >> >> >>> 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