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

Re: [Pharo-dev] Debugger: why generated accessors #shouldBeImplemented?

by Sean P. DeNigris

btw https://pharo.fogbugz.com/f/cases/10220/Debugger-generated-accessors-send-s… ----- Cheers, Sean -- View this message in context: http://forum.world.st/Debugger-why-generated-accessors-shouldBeImplemented-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 6, 2013

Debugger: why generated accessors #shouldBeImplemented?

by Sean P. DeNigris

10220 Debugger-generated accessors send #shouldBeImplemented The debugger offered me the following implementation: description: aByteString self shouldBeImplemented. description := aByteString What's with line #2?! If it didn't exist, I could just accept the method and move on... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Debugger-why-generated-accessors-shouldBeImplemented-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 6, 2013

Please review Cases 10785 and 10314

by Sean P. DeNigris

10785 Auto-complete protocol renaming https://pharo.fogbugz.com/f/cases/10785/Auto-complete-protocol-renaming 10314 Debugger: create better argument names https://pharo.fogbugz.com/f/cases/10314/Debugger-create-better-argument-nam… ----- Cheers, Sean -- View this message in context: http://forum.world.st/Please-review-Cases-10785-and-10314-tp4691989.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 6, 2013

Problem with setting class comments

by Mariano Martinez Peck

Hi guys. I think I found a problem with class comments. The default method #classComment: in TClassAndTraitDescription does the following: classComment: aString "Store the comment, aString or Text or RemoteString, associated with the class we are orgainzing. Empty string gets stored only if had a non-empty one before." ^ self classComment: aString stamp: '<historical>' Why it puts a '<historical>' stamp instead of say "Author changeStamp" ? Nautilus uses this message. So as a consequence, when you edit and save a class comment with Nautilus, to get a <historical> stamp.... I am using Pharo 2.0. Bug? -- Mariano http://marianopeck.wordpress.com

June 6, 2013

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

by Sean P. DeNigris

Dennis Schetinin wrote > Regarding this, I think SUnit was just a very first approach to a good TDD > framework and should be rethought deeply (re-invented?)â¦ but I don't know > if someone ever tried to do that, everyone seems to be satisfied with test > as methods approach. +100. A TestCase class with test methods is an implementation detail. Writing them directly is like writing Smalltalk in bytecodes. This is exactly what I'm working on... would love some help ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-Necessity-of-TDD-with-Smalltalk-tp4691867p4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 6, 2013

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

by Dennis Schetinin

â¦ :) One more thing on the topic I've just remembered: a test shouldn't be just a method in a "test-case" class; test should be a separate alive object with its own state and probably extendable behaviorâ¦ preferably a visible object that can be manipulated directlyâ¦ Regarding this, I think SUnit was just a very first approach to a good TDD framework and should be rethought deeply (re-invented?)â¦ but I don't know if someone ever tried to do that, everyone seems to be satisfied with test as methods approach. -- Best regards, Dennis Schetinin 2013/6/6 Dennis Schetinin <chaetal(a)gmail.com> > â¦ I've forgot to explicitly mention that TDD-ing in Pharo I spent most of > time in debugger and inspectors: I see live objects there, I can > investigate and find roots of troubles, I code thereâ¦ That's why TDD is > most productive in Smalltalk environment for me, and another reason why I > think a good debugger (in an alive environment) doesn't make TDD > unnecessary (or inversely) but rather complement and empower each other. > > > -- > > Best regards, > > > Dennis Schetinin > > > 2013/6/6 Dennis Schetinin <chaetal(a)gmail.com> > >> I didn't mean to start a big discussion so I'm not ready to state or >> develop my vision right now fully and logicallyâ¦ But let's try to start >> little-by-little. >> >> Considering Pharo as an exampleâ¦ there are few minor issues like lack of >> some code-producing features in debuggerâ¦ the one I can remember right now >> is lack of code formatting there, but there are few more. Fixing such >> issues would be a first step towards TDD-oriented environment. >> >> Next steps would be about some more serious improvements: Test Runner >> improvements, auto-test running (it's already is implemented I think?), >> test annotations (expressing ideas behind every tests, relations between >> them, etc.), better test navigation and, perhaps, a "TDD-oriented" browser. >> Then, there should be introspection tools that for example silently save >> all the history and allow to review, analyze the development process >> regarding the idea-test-implementation tripletsâ¦ >> >> â¦Sure, I rather have a "feeling" of the TDD-oriented environment then a >> good proposal right now. The feeling grows to something almost reasonable >> when I code, but I didn't have such chance for few months already, so I'm >> kinda caught off base :) >> >> -- >> >> Best regards, >> >> >> Dennis Schetinin >> >> >> 2013/6/6 Frank Shearar <frank.shearar(a)gmail.com> >> >>> On 6 June 2013 14:44, Dennis Schetinin <chaetal(a)gmail.com> wrote: >>> > TDD is not about tests (as a bug-finding/debugger tool) at all. And the >>> > anti-regression feature of TDD is just the secondary one. >>> > >>> > First of all, TDD is about structuring thinking/creation process. And >>> "test" >>> > here is a tool that allows and makes developer to formalize >>> requirements and >>> > to translate them to the language they will be implemented in. This >>> starts >>> > and really drives coding. Thus, a programmer that really masters TDD >>> (really >>> > means an ability to apply "pure" TDD for all programming activities: >>> both >>> > top-down and bottom-up design activities) is expected to produce much >>> better >>> > architecture/design/code. >>> > >>> > â¦ So, I don't think TDD is somehow obsolete by Smalltalk. Vice versa, >>> TDD >>> > should be really efficient here. And it's a great pity TDD is not >>> actually >>> > popular in Smalltalk society. One of the dire consequences is that >>> modern >>> > Smalltalk environments are not "TDD-oriented" and don't advantage from >>> good >>> > TDD methodology. >>> >>> Why do you think Smalltalk environments aren't "TDD oriented"? What >>> would an IDE need to be TDD oriented? (I can think of something like >>> Ruby's guard, which runs tests every time you save a file.) >>> >>> frank >>> >>> >> >

June 6, 2013

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

by Dennis Schetinin

â¦ I've forgot to explicitly mention that TDD-ing in Pharo I spent most of time in debugger and inspectors: I see live objects there, I can investigate and find roots of troubles, I code thereâ¦ That's why TDD is most productive in Smalltalk environment for me, and another reason why I think a good debugger (in an alive environment) doesn't make TDD unnecessary (or inversely) but rather complement and empower each other. -- Best regards, Dennis Schetinin 2013/6/6 Dennis Schetinin <chaetal(a)gmail.com> > I didn't mean to start a big discussion so I'm not ready to state or > develop my vision right now fully and logicallyâ¦ But let's try to start > little-by-little. > > Considering Pharo as an exampleâ¦ there are few minor issues like lack of > some code-producing features in debuggerâ¦ the one I can remember right now > is lack of code formatting there, but there are few more. Fixing such > issues would be a first step towards TDD-oriented environment. > > Next steps would be about some more serious improvements: Test Runner > improvements, auto-test running (it's already is implemented I think?), > test annotations (expressing ideas behind every tests, relations between > them, etc.), better test navigation and, perhaps, a "TDD-oriented" browser. > Then, there should be introspection tools that for example silently save > all the history and allow to review, analyze the development process > regarding the idea-test-implementation tripletsâ¦ > > â¦Sure, I rather have a "feeling" of the TDD-oriented environment then a > good proposal right now. The feeling grows to something almost reasonable > when I code, but I didn't have such chance for few months already, so I'm > kinda caught off base :) > > -- > > Best regards, > > > Dennis Schetinin > > > 2013/6/6 Frank Shearar <frank.shearar(a)gmail.com> > >> On 6 June 2013 14:44, Dennis Schetinin <chaetal(a)gmail.com> wrote: >> > TDD is not about tests (as a bug-finding/debugger tool) at all. And the >> > anti-regression feature of TDD is just the secondary one. >> > >> > First of all, TDD is about structuring thinking/creation process. And >> "test" >> > here is a tool that allows and makes developer to formalize >> requirements and >> > to translate them to the language they will be implemented in. This >> starts >> > and really drives coding. Thus, a programmer that really masters TDD >> (really >> > means an ability to apply "pure" TDD for all programming activities: >> both >> > top-down and bottom-up design activities) is expected to produce much >> better >> > architecture/design/code. >> > >> > â¦ So, I don't think TDD is somehow obsolete by Smalltalk. Vice versa, >> TDD >> > should be really efficient here. And it's a great pity TDD is not >> actually >> > popular in Smalltalk society. One of the dire consequences is that >> modern >> > Smalltalk environments are not "TDD-oriented" and don't advantage from >> good >> > TDD methodology. >> >> Why do you think Smalltalk environments aren't "TDD oriented"? What >> would an IDE need to be TDD oriented? (I can think of something like >> Ruby's guard, which runs tests every time you save a file.) >> >> frank >> >> >

June 6, 2013

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

by Dennis Schetinin

I didn't mean to start a big discussion so I'm not ready to state or develop my vision right now fully and logicallyâ¦ But let's try to start little-by-little. Considering Pharo as an exampleâ¦ there are few minor issues like lack of some code-producing features in debuggerâ¦ the one I can remember right now is lack of code formatting there, but there are few more. Fixing such issues would be a first step towards TDD-oriented environment. Next steps would be about some more serious improvements: Test Runner improvements, auto-test running (it's already is implemented I think?), test annotations (expressing ideas behind every tests, relations between them, etc.), better test navigation and, perhaps, a "TDD-oriented" browser. Then, there should be introspection tools that for example silently save all the history and allow to review, analyze the development process regarding the idea-test-implementation tripletsâ¦ â¦Sure, I rather have a "feeling" of the TDD-oriented environment then a good proposal right now. The feeling grows to something almost reasonable when I code, but I didn't have such chance for few months already, so I'm kinda caught off base :) -- Best regards, Dennis Schetinin 2013/6/6 Frank Shearar <frank.shearar(a)gmail.com> > On 6 June 2013 14:44, Dennis Schetinin <chaetal(a)gmail.com> wrote: > > TDD is not about tests (as a bug-finding/debugger tool) at all. And the > > anti-regression feature of TDD is just the secondary one. > > > > First of all, TDD is about structuring thinking/creation process. And > "test" > > here is a tool that allows and makes developer to formalize requirements > and > > to translate them to the language they will be implemented in. This > starts > > and really drives coding. Thus, a programmer that really masters TDD > (really > > means an ability to apply "pure" TDD for all programming activities: both > > top-down and bottom-up design activities) is expected to produce much > better > > architecture/design/code. > > > > â¦ So, I don't think TDD is somehow obsolete by Smalltalk. Vice versa, TDD > > should be really efficient here. And it's a great pity TDD is not > actually > > popular in Smalltalk society. One of the dire consequences is that modern > > Smalltalk environments are not "TDD-oriented" and don't advantage from > good > > TDD methodology. > > Why do you think Smalltalk environments aren't "TDD oriented"? What > would an IDE need to be TDD oriented? (I can think of something like > Ruby's guard, which runs tests every time you save a file.) > > frank > >

June 6, 2013

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

by Sean P. DeNigris

Mariano Martinez Peck wrote > only a few notice the work underneath :) I've been so grateful for and empowered by the new infrastructure I was moved to share a bit, even if it only interests a few of us :) ----- 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.

June 6, 2013

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

by Sean P. DeNigris

Henrik Sperre Johansen wrote > Even Smalltalkers are impressed once in a while that the distance from > idea to implementation can be less than an hour :) Yes, when it takes longer for someone to write a feature request than it does for you to implement it, I notice :) ----- 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.

June 6, 2013