September 2014 - Pharo-dev - lists.pharo.org

Undeclared dictionary

by Yuriy Tymchuk

Hi, can someone explain me how Undeclared dictionary works? Because as I look at it, all the values are nil. Is it possible for them to be not nil? Maybe we should have a âglobal variable commentsâ for this situations :) Uko

Sept. 3, 2014

Re: [Pharo-dev] [Off Topic] PHARO - Already Dead - YouTube

by Tudor Girba

Man, are you sure that you want to advertise publicly that you are listening to this music? :)) Doru On Wed, Sep 3, 2014 at 11:00 AM, stepharo <stepharo(a)free.fr> wrote: > Yes I saw it too :) > > > > On 3/9/14 09:40, Sven Van Caekenberghe wrote: > >> We should sue this guy ;-) >> >> https://www.youtube.com/watch?v=S3uktGJVebE >> >> >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 3, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 3, 2014

[pharo-project/pharo-core] f3cc5d: 40197

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: f3cc5d2f04f303f3132b6d095b7a656e1f7e9754 https://github.com/pharo-project/pharo-core/commit/f3cc5d2f04f303f3132b6d09… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-03 (Wed, 03 Sep 2014) Changed paths: M OpalCompiler-Core.package/extension/TClass/instance/classSideCompiler.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script197.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40197.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40197 13938 Opal, custom compilers and class side methods https://pharo.fogbugz.com/f/cases/13938 http://files.pharo.org/image/40/40197.zip

Sept. 3, 2014

Re: [Pharo-dev] Proportional Tab Stops

by stepharo

On 3/9/14 09:43, J.F. Rick wrote: > Hi everyone, > > I'm writing for two reasons. First, I wanted to let people know that I > haven't disappeared. I'm just having to take a break as I finish up > with my current academic post. As I am no longer going to be there, > Pharo contributions don't help the department. So, I can't justify > devoting any time to Pharo. But, I'm still interested in Athens, > multitouch support, and Pharo for beginners. In October, I move back > to Atlanta and will start a company. At that point, I aim to be back, > though I may concentrate a bit more on server technology (full version > of newest QRCode specifications half way done). Thanks for the update. > > Second, I wanted to mention a slight annoyance and suggest a solution. > Background: I taught a class on introduction / intermediate > programming in Pharo the last few years. One thing I try to teach my > students is to use proper indention for their code. Unlike Python > (great syntax for a first language), you do not need to indent in > Smalltalk for code to work properly so students don't have to properly > use indention to organize their code. For tiny bits of code (as is > required in introductory programming), indention is not that important > but it gets more important as they advance. Even my better students > often used bad indention practices, though I emphasized it in class > and all sample code I gave them was properly indented. In class, I > often solved problems and demonstrated code. So that students could > see what I typed, I increased the size of the font (24pt standard > font). Though the font increased, the tab spacing remained the same. > So, when I indented with one tab, it looked much smaller than a tab > would have looked on their 10pt code editor. I saw people using spaces > to indent code, which I never talked about. My guess is that they were > trying to replicate the amount of space that my code was indented. > They saw that a tab looked too big and used spaces. A simple solution > is for tab spacing in code panes to increase proportionally with the > font size. Yes it should. > I feel like suggesting that as an improvement for Pharo 4. Does that > seem reasonable? Are there arguments against it? No this should be like you mention. > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

Sept. 3, 2014

Re: [Pharo-dev] [Off Topic] PHARO - Already Dead - YouTube

by stepharo

Yes I saw it too :) On 3/9/14 09:40, Sven Van Caekenberghe wrote: > We should sue this guy ;-) > > https://www.youtube.com/watch?v=S3uktGJVebE > > > >

Sept. 3, 2014

Re: [Pharo-dev] Proportional Tab Stops

by Tudor Girba

Hi, Glad to hear from you. Thanks for spotting the issue with tabbing. I think your suggestion of having tabs spacing being proportional with the font size makes sense. Could we interest you in submitting a slice for this? :) Cheers, Doru On Wed, Sep 3, 2014 at 9:43 AM, J.F. Rick <self(a)je77.com> wrote: > Hi everyone, > > I'm writing for two reasons. First, I wanted to let people know that I > haven't disappeared. I'm just having to take a break as I finish up with my > current academic post. As I am no longer going to be there, Pharo > contributions don't help the department. So, I can't justify devoting any > time to Pharo. But, I'm still interested in Athens, multitouch support, and > Pharo for beginners. In October, I move back to Atlanta and will start a > company. At that point, I aim to be back, though I may concentrate a bit > more on server technology (full version of newest QRCode specifications > half way done). > > Second, I wanted to mention a slight annoyance and suggest a solution. > Background: I taught a class on introduction / intermediate programming in > Pharo the last few years. One thing I try to teach my students is to use > proper indention for their code. Unlike Python (great syntax for a first > language), you do not need to indent in Smalltalk for code to work properly > so students don't have to properly use indention to organize their code. > For tiny bits of code (as is required in introductory programming), > indention is not that important but it gets more important as they advance. > Even my better students often used bad indention practices, though I > emphasized it in class and all sample code I gave them was properly > indented. In class, I often solved problems and demonstrated code. So that > students could see what I typed, I increased the size of the font (24pt > standard font). Though the font increased, the tab spacing remained the > same. So, when I indented with one tab, it looked much smaller than a tab > would have looked on their 10pt code editor. I saw people using spaces to > indent code, which I never talked about. My guess is that they were trying > to replicate the amount of space that my code was indented. They saw that a > tab looked too big and used spaces. A simple solution is for tab spacing in > code panes to increase proportionally with the font size. I feel like > suggesting that as an improvement for Pharo 4. Does that seem reasonable? > Are there arguments against it? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 3, 2014

Re: [Pharo-dev] Spec license

by Sven Van Caekenberghe

http://forum.world.st/Board-clarification-around-Spec-td4775346.html On 03 Sep 2014, at 10:24, Torsten Bergmann <astares(a)gmx.de> wrote: > The Spec news page [1] explains the license change and anyone can easily guess that it is caused > by Benjamins personal disagreements with Stef. No judgement on that from my side as this > is a personal issue between the two and as I like most of us have only a few infos on that from > the outside. > > It is interesting that there is also a new Spec release [2] announced this week although in his > last post [3] Benjamin stated "I am quiting the Pharo community, as well as the Smalltalk community". > > To me it looks like Benjamin want's to punish Stef - but it will affect the community and the idea > WE ALL hardly work on ... > Sorry but this is a more childish like reaction from his side and not a good way to solve disagreements. > > I can only talk about this from an outside point of view but I think nobody in our community > will profit from Benjamin reaction - it makes it harder for the whole Pharo community to work > with Spec and in my opinion it will be not good for Spec framework or Benjamin either. > > From what I see now my personal recommendation would be decide within the community if Spec > could be a base for the future of our UI and tool building and if so rename and continue in a > forked way with the MIT licensed code within the Pharo image so it will not be confused > with Benjamins version, license and page. > > Looks like currently that this is the only way to continue with it and ensure contributions > will stay single licensed/MIT licensed. > > We can only change the future - not the past... > > Thx > T. > > [1] http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html > [2] http://spec.st/news/#Spec%202.0.0%20release > [3] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-August/0993… >

Sept. 3, 2014

Re: [Pharo-dev] Spec license

by Torsten Bergmann

The Spec news page [1] explains the license change and anyone can easily guess that it is caused by Benjamins personal disagreements with Stef. No judgement on that from my side as this is a personal issue between the two and as I like most of us have only a few infos on that from the outside. It is interesting that there is also a new Spec release [2] announced this week although in his last post [3] Benjamin stated "I am quiting the Pharo community, as well as the Smalltalk community". To me it looks like Benjamin want's to punish Stef - but it will affect the community and the idea WE ALL hardly work on ... Sorry but this is a more childish like reaction from his side and not a good way to solve disagreements. I can only talk about this from an outside point of view but I think nobody in our community will profit from Benjamin reaction - it makes it harder for the whole Pharo community to work with Spec and in my opinion it will be not good for Spec framework or Benjamin either. >From what I see now my personal recommendation would be decide within the community if Spec could be a base for the future of our UI and tool building and if so rename and continue in a forked way with the MIT licensed code within the Pharo image so it will not be confused with Benjamins version, license and page. Looks like currently that this is the only way to continue with it and ensure contributions will stay single licensed/MIT licensed. We can only change the future - not the past... Thx T. [1] http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html [2] http://spec.st/news/#Spec%202.0.0%20release [3] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-August/0993…

Sept. 3, 2014

Re: [Pharo-dev] nil pointersTo size

by Guillermo Polito

Arrays with empty slots, all collections whose size is smaller than their capacity... :) On Wed, Sep 3, 2014 at 7:52 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > All âuninitialisedâ variables are pointing to nil. I think this is the case > > Uko > > On 03 Sep 2014, at 06:10, Ben Coman <btc(a)openinworld.com> wrote: > > > > > I am curious... what does it mean that > > nil PointersTo size is a large number? Intuitively I'd have thought > the answer would be zero. > > > > Pharo build 40196 --> ~101,000 > > Pharo build 30856 --> ~103,000 > > Pharo build 20628 --> ~80,000 > > Squeak 4.5 --> ~40,000 > > > > cheers -ben > > > > >

Sept. 3, 2014