- Pharo-dev - lists.pharo.org

Need a decision on subString: vs substring:

by stepharo

*) It appears that Pharo is removing subString: in favor of substring:. The ANSI standard defines subString:. I was not aware of it. In fact ANSI is bad and totally incomplete (for example we studies strings and this is a mess and totally incomplete). Now we should probably add it. I will send the mail to the mailing-list and let people decide.

Sept. 3, 2015

Re: [Pharo-dev] Removing name from Object

by stepharo

yes but first name out :) Le 2/9/15 14:08, Peter UhnÃ¡k a Ã©crit : > > Off the top of my head, in the worst case implementing #name on the > class-side can be fatal. > > > TBH using generic names (for both variables and methods) on class side > is like running through a mine field. > I blew up my image more than once. > > From UX perspective the system should warn the user if he is trying to > override some system method or variable, but that is perhaps issue of > its own. > > Peter >

Sept. 3, 2015

Re: [Pharo-dev] Removing name from Object

by stepharo

Yes we know but first we should just make sure that the system is still working without this $#%^^&*^(&)*%^& method. Le 2/9/15 10:29, Esteban Lorenzano a Ã©crit : > but if we deprecate, that means we need to remove it from the system. > deprecated is for external users, not for Pharo it self. > > Esteban > > ps: We *can not* remove #name from the system just like that. It is > too widely use, we need to give users time to adapt. Doing otherwise > is not professional and expect a lot of people yelling (and with > reason, in this case). > >> On 02 Sep 2015, at 10:21, Guillermo Polito <guillermopolito(a)gmail.com >> <mailto:guillermopolito@gmail.com>> wrote: >> >> The problem is if (like in the past) name is extensively used by some >> library we depend upon (like... let's say morphic), a deprecation >> that raises an exception may turn the system unusable. It's not that >> it is not doable, but we should do it gently and with love. >> >> El miÃ©., 2 de sept. de 2015 a la(s) 9:30 a. m., Esteban Lorenzano >> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> escribiÃ³: >> >>> On 02 Sep 2015, at 09:25, Peter UhnÃ¡k <i.uhnak(a)gmail.com >>> <mailto:i.uhnak@gmail.com>> wrote: >>> >>> On Wed, Sep 2, 2015 at 8:40 AM, Nicolai Hess <nicolaihess(a)web.de >>> <mailto:nicolaihess@web.de>> wrote: >>> >>> How can we find out, which external projects depend on this? >>> >>> >>> Is #name in any way special? Why not just deprecate it like any >>> other method change or removal? (And then remove it in Pharo 6) >> >> +1 >> thatâs the way to do it :) >> >>> >>> Peter >> >

Sept. 3, 2015

Re: [Pharo-dev] Removing name from Object

by stepharo

> The problem is if (like in the past) name is extensively used by some > library we depend upon (like... let's say morphic), a deprecation that > raises an exception may turn the system unusable. It's not that it is > not doable, but we should do it gently and with love. The devil is in the details... they say.

Sept. 3, 2015

Re: [Pharo-dev] size of MCbrowser should be proportional

by stepharo

ok I understand. I think that we should rebuild these tools but time time time Le 3/9/15 16:19, Peter UhnÃ¡k a Ã©crit : > On Thu, Sep 3, 2015 at 4:14 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > I'm sorry but you have to think modularly. > I do not see why having multiple repositories is a problem. > > > This is not what I meant, having system modular is a good thing. > > What I was getting at is that the need to have the MCBrowser larger is > primarily (in my eyes at least) because now they are suddenly more > packages. > That's why I proposed to have them hidden from the view by default. > > That way > 1. the system can be separated into as many repos as we want > 2. the MC Browser wouldn't need to be so large > 3. it will be easier for end users to see their repos > 4. if you need to see them, you just click on a button/checkbox > > Peter >

Sept. 3, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 3, 2015

[pharo-project/pharo-core] be04d6: 50302

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: be04d6787cc11acb9510da2fb55a0b762aae7886 https://github.com/pharo-project/pharo-core/commit/be04d6787cc11acb9510da2f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-03 (Thu, 03 Sep 2015) Changed paths: M Morphic-Core.package/Morph.class/instance/layout/layoutProportionallyIn_.st A Morphic-Widgets-Pluggable.package/PluggableTextMorph.class/instance/testing/isAutoFit.st A Morphic-Widgets-Scrolling.package/ScrollPane.class/instance/layout/layoutProportionallyIn_.st A Morphic-Widgets-Scrolling.package/ScrollPane.class/instance/testing/isAutoFit.st M OpalCompiler-Core.package/IRBuilder.class/instance/instructions/pushClosureCopyCopiedValues_args_jumpTo_.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterAssignment.st M Reflectivity.package/RFASTTranslator.class/definition.st A Reflectivity.package/RFASTTranslator.class/instance/reflectivity/emitMetaLinkAfterNoEnsure_.st M Reflectivity.package/RFASTTranslator.class/instance/reflectivity/emitMetaLinkAfter_.st A Reflectivity.package/RFASTTranslator.class/instance/reflectivity/emitPrepareLinkAfter_.st R Reflectivity.package/RFASTTranslator.class/instance/reflectivity/hasSeen_.st R Reflectivity.package/RFASTTranslator.class/instance/reflectivity/recordSeen_.st R Reflectivity.package/RFASTTranslator.class/instance/reflectivity/removeSeen_.st M Reflectivity.package/RFASTTranslator.class/instance/reflectivity/visitVariableValue_.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/emitMessageNode_.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitArrayNode_.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitAssignmentNode_.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitLiteralArrayNode_.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitLiteralNode_.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitMethodNode_.st R Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitNode_.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitVariableNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50301.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50302.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50301.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50302.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50302 16452 Improve Morph>>layoutProportionallyIn: https://pharo.fogbugz.com/f/cases/16452 16471 Pass over #after: make after work for assignment https://pharo.fogbugz.com/f/cases/16471 http://files.pharo.org/image/50/50302.zip

Sept. 3, 2015

Re: [Pharo-dev] size of MCbrowser should be proportional

by Peter UhnÃ¡k

On Thu, Sep 3, 2015 at 4:14 PM, stepharo <stepharo(a)free.fr> wrote: > I'm sorry but you have to think modularly. > I do not see why having multiple repositories is a problem. > > This is not what I meant, having system modular is a good thing. What I was getting at is that the need to have the MCBrowser larger is primarily (in my eyes at least) because now they are suddenly more packages. That's why I proposed to have them hidden from the view by default. That way 1. the system can be separated into as many repos as we want 2. the MC Browser wouldn't need to be so large 3. it will be easier for end users to see their repos 4. if you need to see them, you just click on a button/checkbox Peter

Sept. 3, 2015

Re: [Pharo-dev] size of MCbrowser should be proportional

by stepharo

I'm sorry but you have to think modularly. I do not see why having multiple repositories is a problem. Stef Le 3/9/15 11:22, Peter UhnÃ¡k a Ã©crit : > > The new, large size, makes it a very scary tool. That many > packages? That many repositories? > > > Pharo 4 image has just 2 external repos (Pharo + PharoInbox), > Pharo 5 has 19 fucking repositories. > > I don't want to generalize, but how often does an end user care about > any of them? > For example the only time I interact with Pharo or PharoInbox is when > I am fixing issues and I do that from clean image. > > So my proposal: > Why not hide them? There could be a checkbox "[ ] Show system > repositories" (default unchecked). > That way the window can be much much smaller and users will see what > is important for them. > > Peter

Sept. 3, 2015

Re: [Pharo-dev] size of MCbrowser should be proportional

by stepharo

> >> >> >> and for "size of MCbrowser should be proportional": >> >> We don't have any other windows with a size proportional to the >> display size. >> Why should only MCBrowser behave like that? (Nautilus uses the same >> size). >> >> And what would be a good size, max. half the screen? >> >> And if we want a display screen dependent window size, this should be >> done by >> RealEstateAgent, and not for every single tool. > > I really donât know if it should be proportional. I has never been > like that. What I do know is that now is too big (while before was to > small) :) > So maybe best is to play a bit with the sizesâ¦ it was small, now is > big, lets find something in the middle :) > + 1

Sept. 3, 2015