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

[update 3.0] #30182

by StÃ©phane Ducasse

30182 ----- 10115 MCClassTraitDefinition DNU printDefinitionOn: https://pharo.fogbugz.com/f/cases/10115 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Monticello-StephaneDucasse.80…

June 7, 2013

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

by Marcus Denker

On Jun 7, 2013, at 11:00 AM, phil(a)highoctane.be wrote: > Just got a bite from that bug. > > https://pharo.fogbugz.com/default.asp?10860 > > Now, how can get I my fileIns to work? > I do not think that these are related. The *only* thing the classComment: thing brings is that the meta-data for the class comment is not recorded. This has to be a completely unreleased error. > > On Fri, Jun 7, 2013 at 8:17 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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] Problem with setting class comments

by phil＠highoctane.be

Just got a bite from that bug. https://pharo.fogbugz.com/default.asp?10860 Now, how can get I my fileIns to work? On Fri, Jun 7, 2013 at 8:17 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > 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

Fwd: Release Artefact 1.0, the PDF framework

by Guillaume Larcheveque

Thanks a lot about your return!!! About format, we will add your format but can you please inform us about all commons US formats (please fileOut what you have implemented). In a short future, we will split the project in many packages and grant to everybody the right to contribute for format, composite elements, fonts... 2013/6/6 Chris Cunningham <cunningham.cb(a)gmail.com> > Hi. > > I'm using your Artefact project, and really enjoying it. But, of, course, > there is a little problem. > > I'm in the US, so naturally, I want to use US size paper. Looking at you > formats, your PDFLetterFormat is actually sized for Legal - if you could > change the class to be PDSLegalFormat, and add a new PDFLetterFormat where > the #defaultSize is "^612 point @ 792 point", that would make me super > happy. > > Or, of course, you could grant me access,and I could make the change (user > id cbc). I've already done this locally to move ahead. > > Thanks, > Chris > > > On Fri, May 31, 2013 at 6:30 AM, Guillaume Larcheveque < > guillaume.larcheveque(a)gmail.com> wrote: > >> We are proud to announce that Artefact is available in 1.0 version. >> >> You can download it from: http://smalltalkhub.com/#!/~RMoD/Artefact >> >> Artefact is a framework to generate PDF documents. It is fully written in >> Smalltalk and doesn't require any native library. Artefact is light, >> platform independant and offer to users a high level of abstraction in >> order to easily creating PDF documents. >> >> * completely written in Smalltalk (and only Smalltalk), >> * complete freedom about the order of creation for pages, elements... >> (no need to follow the document order) >> * multi format and orientation for pages >> * page composition based on reusables PDF elements, >> * extensibility by offering a composition standard to create your own >> high level elements >> * styleSheet that can be reused in many documents and avoid wasting time >> and place with duplication >> * image support with the JPEG format >> * pre-defined high level elements like datagrid >> * support PDF compression to produce compact files >> >> A basic documentation is available in the help browser. Many examples are >> implemented in the PDFDemos class. >> >> -- >> *Olivier Auverlot and Guillaume Larcheveque* >> >> > -- *Guillaume Larcheveque* -- *Guillaume Larcheveque*

June 7, 2013

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

by Rafael Luque

Hi Dennis, What do you think about the approach shown in this screencast: http://www.pharocasts.com/2011/02/stringcalculator-kata.html ? I'm far away from being an Smalltalk developer, but I tried to show a TDD process to solve this simple kata. Rafael Luque 2013/6/7 Dennis Schetinin <chaetal(a)gmail.com> > 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

Thanks for the participation to Pharo web days

by StÃ©phane Ducasse

Hi guys I wanted to thank you for the effort you did: coming to lille and presenting your great product. Thanks again. Stef

June 7, 2013

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