- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Adding a statement programmatically

by Norbert Hartl

Am 06.06.2013 um 22:18 schrieb "Sean P. DeNigris" <sean(a)clipperadams.com>: > Norbert Hartl wrote >> method := (AbstractSound>>#initialize) parseTree. >> method body addNode: (RBParser parseExpression: 'envelopes := nil'). >> method formattedCode >> ... >> Does not work? What do you mean by saying "same result"? > > It did work (one year later, lol)! My last statement was mistakenly "body > formattedCode" instead of "method formattedCode" :) Norbert > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Adding-a-statement-programmatically-tp4454447p4692030… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 7, 2013

Thanks

by Hilaire Fernandes

Hi, I just want to say thanks you for the tips you gave me to migrate both DrGeo repo and its build scripts to SmalltalkHub. Smooth and clean. Hilaire -- Dr. Geo - http://www.drgeo.eu

June 7, 2013

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

by Dennis Schetinin

I don't remember exactly where and when, but I think we've discussed the Laser Game tutorial already. I told this before, and I (after reviewing the tutorial again) should repeat it again: actually, this tutorial doesn't show TDD. I can explain my opinion in detail if someone's interested, but in general, that's simply an up-front design approach with some automatic testing. It's not even "Test-First" approach most of time. Disclaimer: I don't mean the tutorial and/or the design approach used there are bad. I like this tutorial. It's really very good: it shows many aspects for Smalltalk programing, it shows how to use debugger and inspectors properly. I borrowed many ideas from there for my Smalltalk programming courseâ¦ It's just not TDD, not "pure" TDD at least. -- Best regards, Dennis Schetinin 2013/6/7 <btc(a)openinworld.com> > Paul Davidowitz 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 >> >> >> >> > Actually some Smalltalk'ers consider the debugger a major facilitator of > TDD by mostly coding from within the debugger. > 1. Before writing any application code, write a test. > 2. Execute that test straight away. Of course it fails because you > haven't written any application code. > 3. Up comes the debugger - now "from within the debugger" add the > application code needed to satisfy the test. > 4. Repeat. > > A good demonstration of this is Stephan Wessels' Laser Game tutorial [1] > (but you'll temporarily need to revert to Squeak 3.9 to do it) > cheers -ben > > >

June 7, 2013

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

by btc＠openinworld.com

Paul Davidowitz 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 > > > Actually some Smalltalk'ers consider the debugger a major facilitator of TDD by mostly coding from within the debugger. 1. Before writing any application code, write a test. 2. Execute that test straight away. Of course it fails because you haven't written any application code. 3. Up comes the debugger - now "from within the debugger" add the application code needed to satisfy the test. 4. Repeat. A good demonstration of this is Stephan Wessels' Laser Game tutorial [1] (but you'll temporarily need to revert to Squeak 3.9 to do it) cheers -ben

June 7, 2013

Re: [Pharo-dev] 30181 Kernel package Dirty

by Marcus Denker

On Jun 6, 2013, at 7:22 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > 1. Download a fresh 30181 > 2. In MC Browser, view "Changes" on Kernel > > The package will show a handful of changes and be marked dirty > When I do it , it does not find any changes. Marcus

June 7, 2013

Re: [Pharo-dev] Problem with setting class comments

by Marcus Denker

On Jun 6, 2013, at 5:54 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > 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? > Yes! Marcus

June 7, 2013

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

by Paul Davidowitz

Thanks all for the feedback. TDD is for me! - Paul

June 6, 2013

Global initialization for new inst vars

by Sean P. DeNigris

From https://pharo.fogbugz.com/f/cases/10856/Global-initialization-for-new-inst-… : > When adding an instance variable which should be given a default value > e.g. in #initialize, you have a problem if there are existing instances of > the class. Instead of the proper default, they will have a nil value. Also > (although less importantly), you have to stop what you're doing to add the > statement to #initialize. In the mean time, I started implementing it in Pharo 2.0 and ran into a little issue... If you: 1. Load the changeset from the issue 2. Debug a method e.g. "RBAbstractCondition new doSomething" 3. Type the name of a non-existence inst var and accept 4. In the dialog, type 4, and accept the dialog The source will appear to have been accepted, but if you browse the method, the statement with the inst var name was not added. n.b. it works fine when editing in a browser instead of the debugger ----- Cheers, Sean -- View this message in context: http://forum.world.st/Global-initialization-for-new-inst-vars-tp4692042.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 6, 2013

taking a custom screenshot of a submorph

by Tudor Girba

Hi, Just in case you want to take a screenshot of a submorph, here is a description + video of how you can do it using the GTInspector: http://www.humane-assessment.com/blog/custom-morph-screenshot-with-gtinspec… Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

June 6, 2013

Re: [Pharo-dev] Sunbursts are coming in Roassal

by Tudor Girba

Very cool :) Doru On Thu, Jun 6, 2013 at 10:38 PM, Juraj Kubelka <juraj.kubelka(a)gmail.com>wrote: > Cool! :-) > > > 2013/6/6 Alexandre Bergel <alexandre.bergel(a)me.com> > >> Hi! >> >> Milton, an excellent engineer from Object Profile, just produced the >> following: >> >> >> Sunburst is a visualization particular efficient at visualizing >> hierarchical domain. >> It naturally uses Athens. >> >> We will show more at esug :-) >> >> Milton & Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

June 6, 2013