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

[Pharo Consortium] New Sponsor: CaesarSystems

by Marcus Denker

The Pharo Consortium is very happy to announce that CaesarSystem is supporting the Pharo Consortium as a Sponsor. More about - CaesarSystems: http://www.caesarsystems.com - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

June 6, 2013

Re: [Pharo-dev] Lowecase class names

by Marcus Denker

On Jun 6, 2013, at 9:29 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 03/06/13 12:18, Marcus Denker wrote: >> >> On Jun 3, 2013, at 1:13 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >>> I thought so. Attached hack removes it. >>> >> >> Of course a complete rewrite of the class builder is ready for integrationâ¦ >> >> https://ci.inria.fr/pharo-contribution/job/Slot/ >> >> So the question is if it makes sense to add this one? > > Hm...I'm not sure what you mean. I mean that we should not change ClassBuilder now if it is replaced next week. (man power is limited). > Let put it this way? Any chance > 2.0 will allow lowercase class names? The problem with changing 2.0 is that all change always has side-effect impacting othersâ¦ often in very non-expected ways. So I am a bit skeptical to change 2.0, especially anything in the dark places like the class builder. If it is a change that is for the good of all users, is makes sense to invest time and effort. But changing the class builder in 2.0 just for an experiment of one person? I would tend to argue to not do it. The current development version is another story. There we can break things, have time to stabilize. Marcus

June 6, 2013

Re: [Pharo-dev] Lowecase class names

by Jan Vrany

On 03/06/13 12:18, Marcus Denker wrote: > > On Jun 3, 2013, at 1:13 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> I thought so. Attached hack removes it. >> > > Of course a complete rewrite of the class builder is ready for integrationâ¦ > > https://ci.inria.fr/pharo-contribution/job/Slot/ > > So the question is if it makes sense to add this one? Hm...I'm not sure what you mean. Let put it this way? Any chance 2.0 will allow lowercase class names? If not, fine with me, I'll patch ClassBuilder before loading my packages. Jan

June 6, 2013

Re: [Pharo-dev] [Screencast]: Pharo Smalltalk's New TxText: The Power of Clean Code

by StÃ©phane Ducasse

On Jun 5, 2013, at 10:52 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > https://vimeo.com/67752734 > > Very short and simple video describing my experience while implementing > replacing a text morph's cursor with a block cursor to signify vim normal > mode. Shows how I was able to accomplish something in a few minutes which > seemed impossible with TextEditor and friends. thanks for the videos. > > Things are getting really exciting around here :) ohhhhh yes. We are getting there and even more :) Stef

June 6, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Marcus Denker

On Jun 5, 2013, at 4:10 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 05/06/2013 16:04, Marcus Denker a Ã©crit : >> >> On Jun 5, 2013, at 4:03 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> Le 05/06/2013 15:56, Marcus Denker a Ã©crit : >>>> >>>> On Jun 5, 2013, at 2:39 PM, no-reply(a)ci.inria.fr wrote: >>>> >>>>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=lin… >>>>> >>>>> 3 regressions found. >>>>> FileSystem.Tests.Disk.FileHandleTest.testTruncate >>>>> Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment >>>>> Tests.Monticello.MCClassDefinitionTest.testLoadAndUnload >>>>> Ok, so we have 2 independent issues; 1) testTruncate failing on recent Ubuntu in both 2.0 and 3.0 https://pharo.fogbugz.com/f/cases/10852 2) The slice I integrated was wrong / not complete: FileSystem.Tests.Disk.FileHandleTest.testTruncate Refactoring.Tests.Changes.RBRefactoringChangeTests.testPerformChangeComment https://pharo.fogbugz.com/f/cases/10415 For this, I think the best would be to submit the missing code in some machine readable form as I right now am a bit confused about what exactly "adding the right flush methods" means. Marcus

June 6, 2013

halos are disappearing much slowler than before, isn't

by StÃ©phane Ducasse

We probably change somethingâ¦ Stef

June 6, 2013

Re: [Pharo-dev] Necessity of TDD with Smalltalk

by Stephan Eggermont

Paul wrote: >It seems to me that a big reason for developing via writing tests first >(Test Driven Development) is that the tests serve as a debugging tool -- >if a test breaks, then the last piece of (non-test) code that change is >likely the culprit. But with the powerful debugging environment that >comes with Smalltalk, I am wondering of the utility of TDD (TDD is big >in the Ruby camp perhaps for a reason). After all, writing and >re-writing the tests becomes quite a non-trivial chore (not to mention >that the tests themselves could be buggy). So my question: Is it ok in >Smalltalk to write tests afterwards? Is it even perhaps recommended? Test-driven development works well when you have some idea of where you want to go. If you don't know yet what your first test could look like, the powerful debugging environment of Smalltalk allows you to do some fast experiments. Then you might want to switch to TDD, as there are two ideas in TDD that are not covered by having a good debugging environment: - don't write more code than you have tests for, so the design is really driven by the tests - the tests provide insurance that you'll notice when something breaks. Writing and re-writing tests is what helps you get to a simple design. Tests need refactoring and DRY just as much as other code. Stephan

June 5, 2013

Re: [Pharo-dev] [Screencast]: Pharo Smalltalk's New TxText: The Power of Clean Code

by Mariano Martinez Peck

Thanks Sean. This is exactly the type of thing that normal users don't see when they use Pharo. Of course, most people notice the UI refactors, the new tools etc. But only a few notice the work underneath :) On Wed, Jun 5, 2013 at 6:29 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 05 Jun 2013, at 22:52, "Sean P. DeNigris" <sean(a)clipperadams.com> > wrote: > > > https://vimeo.com/67752734 > > > > Very short and simple video describing my experience while implementing > > replacing a text morph's cursor with a block cursor to signify vim normal > > mode. Shows how I was able to accomplish something in a few minutes which > > seemed impossible with TextEditor and friends. > > Cool. > > > Things are getting really exciting around here :) > > Yes ! > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Screencast-Pharo-Smalltalk-s-New-TxText-The-Power-of-… > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > -- Mariano http://marianopeck.wordpress.com

June 5, 2013

Re: [Pharo-dev] Necessity of TDD with Smalltalk

by phil＠highoctane.be

Well, at one point, I realized that tests were saving my butt more often than not. Especially with Smalltalk. They also do form basic documentation for the lack of anything better. At least, you can debug them to see what happens. Phil On Thu, Jun 6, 2013 at 12:11 AM, Paul Davidowitz <pdavidow(a)fastmail.fm>wrote: > It seems to me that a big reason for developing via writing tests first > (Test Driven Development) is that the tests serve as a debugging tool -- > if a test breaks, then the last piece of (non-test) code that change is > likely the culprit. But with the powerful debugging environment that > comes with Smalltalk, I am wondering of the utility of TDD (TDD is big > in the Ruby camp perhaps for a reason). After all, writing and > re-writing the tests becomes quite a non-trivial chore (not to mention > that the tests themselves could be buggy). So my question: Is it ok in > Smalltalk to write tests afterwards? Is it even perhaps recommended? > > - Paul > >

June 5, 2013

Necessity of TDD with Smalltalk

by Paul Davidowitz

It seems to me that a big reason for developing via writing tests first (Test Driven Development) is that the tests serve as a debugging tool -- if a test breaks, then the last piece of (non-test) code that change is likely the culprit. But with the powerful debugging environment that comes with Smalltalk, I am wondering of the utility of TDD (TDD is big in the Ruby camp perhaps for a reason). After all, writing and re-writing the tests becomes quite a non-trivial chore (not to mention that the tests themselves could be buggy). So my question: Is it ok in Smalltalk to write tests afterwards? Is it even perhaps recommended? - Paul

June 5, 2013