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

Re: [Pharo-project] DocTest

by Denis Kudriashov

2013/1/22 Sean P. DeNigris <sean(a)clipperadams.com> > Benjamin Van Ryseghem-2 wrote > > I am attending a python lecture and discovered DocTest[1], and I was > > wondering if such a tool exists for Pharo ? :) > > I've been dreaming about, and doing experiments around, this for quite a > while... could be so much better in st because we can create custom UI > tools > instead of text files... > I dream about it too :)). I remember we talk about this in Gent. But what experiments are you talk about? How I can try it? I think BDD programming can be much better and simpler with smalltalk because we are not limited with text files and code syntax. We can work with objects and present it with any way we want. With classic TDD we model system specs with test methods which are very restricted way for building readable and reusable specs of system. And I think we mix here few concepts: how to validate (run) specs, how to persist specs and what specs actualy is. And last item is what we should reimplement from scrach independently from others (we should forgot about others for the moment). BDD exactly about it. But nonsmalltalk world continue mix concepts because text files and code syntax is only way to persist and build system specs there. They was make just good refactoring of TDD approach which is very nice but I'm sure we can do better :)

Jan. 22, 2013

Re: [Pharo-project] Fonts in Pharo By Example

by Gary Chambers

No prob Regards, Gary ----- Original Message ----- From: "Sean P. DeNigris" <sean(a)clipperadams.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, January 22, 2013 7:54 PM Subject: Re: [Pharo-project] Fonts in Pharo By Example > Gary Chambers-4 wrote >> always look up fonts via LogicalFont class methods these days... > > Thanks, Gary! That actually solved an immediate problem I was dealing with > :) And I'm hoping a font guru will take a deeper cut for us ignorant > masses > ;) > > > > -- > View this message in context: > http://forum.world.st/Fonts-in-Pharo-By-Example-tp4664406p4664664.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 22, 2013

Re: [Pharo-project] SmallLint applied on Pharo: Continued

by Jan Vrany

Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like. For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source). However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever. I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-) Cheers On 22/01/13 19:32, StÃ©phane Ducasse wrote: > Jan > what is the license of your tags and other code? > > Stef > > On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote: > >> On 22/01/13 18:22, StÃ©phane Ducasse wrote: >>> Hi >>> >>> I'm running the rule RBSubclassResponsibilityNotDefinedRule that >>> >>> Checks that all subclassResponsibility methods are defined in all leaf classes. >>> >>> Now the results display the sender of ^ subclassResponsibility but I have to manually find the >>> problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method. >>> >>> But this would be much better. Jan did you do that in your version? >> >> Good point. Yes, since now we do that :-) >> >> Jan >> >>> >>> Stef >>> >> >> > > >

Jan. 22, 2013

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

by David T. Lewis

On Tue, Jan 22, 2013 at 09:15:32AM -0800, Sean P. DeNigris wrote: > David T. Lewis wrote > > I am trying to find a way to make OSProcess... work on Pharo 2.0, > > Pharo1.x, and the various versions of Squeak and Cuis > > I've been thinking a lot about keeping OSP working well on all our favorite > St platforms. Metacello was designed specifically to address this type of > problem, which I'm sure will multiply as squeak and pharo evolve. I wonder > if MetaC works with Cuis... If not, and for older versions of Squeak/Pharo, > there could be a Gofer/Installer script like the one for FFI, or - easier > for users but maybe a little more work - the multiple packages could be > loaded in each supported platform and re-commited as a single > platform-specific package e.g. OSProcessSqueak44, OSProcessPharo20; so > development would be done w. MetaC, and users can simply download one > package. This would also free us from the branching that currently exists to > figure out which system we're on. Are you open to committing to the > multiple-package path going forward and relying on MetaC to manage these > incompatibilities? Metacello will certainly handle this, and I certainly don't mind as long as I don't get stuck doing the maintenance chores for all the different images. I don't want to do Metacello configs for Squeak (because it is not necessary) or Cuis (I don't know if it is possible and I don't have the time), but it would be a good approach to support the more rapid rate of change in Pharo. My first preference would be to have the OSProcess package be clever enough to adapt to the various image variations, but that may not be feasible if the images get too different. Maybe we are at that point now, in which case maintaining Metacello configurations for Pharo 2.0, 1.4, etc would be the right thing to do. Dave

Jan. 22, 2013

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

by David T. Lewis

On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote: > > On Jan 22, 2013, at 5:27 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > > Dave > > > > I wonder why you can't check for > > > > Smalltalk at: #OSPlatform > > > > and if that exists go for > > OSPlatform osVersion > > > We deprecated that? but I can un-deprecate. > > > Neither Squeak nor Cuis do have an OSPlatform class. > > > > Then you go for > > Smalltalk os version > > > > This works in Pharo 2.0? Yes, "Smalltalk os version" is right for Pharo 2.0. I'm looking for a way to modify the following method so that it adds support for Pharo 2.0, so that it continues to work in the other images, and so that it does not raise deprecation warnings or DNUs in any of the images. OSProcess class>>osVersion "After Squeak version 3.6, #osVersion was moved to SmalltalkImage. Some versions of Pharo move this to OSPlatform and issue deprecation warnings about the other usages." ^ (((Smalltalk hasClassNamed: #OSPlatform) and: [(Smalltalk at: #OSPlatform) respondsTo: #osVersion]) ifTrue: [Smalltalk at: #OSPlatform] ifFalse: [((Smalltalk classNamed: 'SmalltalkImage') ifNil: [^ Smalltalk osVersion]) current]) osVersion Dave > > > Am I missing something here? > > > > --Hannes > > > > On 1/21/13, David T. Lewis <lewis(a)mail.msen.com> wrote: > >> Why is OSPlatform class>>osVersion deprecated but OSPlatform > >> class>>platformName > >> is not? > >> > >> My suggestion would be to comment #osVersion as being a synonym for > >> #version, > >> but do not deprecate it. That would enable use of "Smalltalk os version", > >> and > >> it would also support "OSPlatform osVersion", both of which make logical > >> sense. > >> It would also maintain support for external packages that rely on > >> #osVersion > >> to figure out platform differences. > >> > >> The reason that I am asking is that I am trying to find a way to make > >> OSProcess class>>osVersion work on Pharo 2.0, Pharo1.x, and the various > >> versions of Squeak and Cuis. I quite honestly cannot figure out any way to > >> add Pharo 2.0 without breaking one more more of the other supported images. > >> If OSPlatform class>>osVersion did not raise a deprecation warning, then > >> I could make it work. > >> > >> Thanks, > >> Dave > >> > >> > >> > > >

Jan. 22, 2013

Re: [Pharo-project] DocTest

by Denis Kudriashov

2013/1/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > it would be nice to introduce the same syntax than Sunit > > exp assert: exp2 > > [ exp ] shouldraise: > StateSpecs (package separated from Mocketry) implements it. And such "should" syntax extendable by pragmas. Your example looks like: [exp] should raise: Error It is implemented with main spec class RaisingExceptionSpec RaisingExceptionSpec >>basicMatches: aBlockContext [aBlockContext value. ^false] on: requiredException do: [:ex | ex class = SpecFailed ifTrue: [ex outer]. ^true] And single method in special DSL class: Raise>>exception: aClass <syntax: #(raise:)> ^RaisingExceptionSpec requiredException: aClass > Stef > > > On Jan 21, 2013, at 4:41 AM, Benjamin wrote: > > > Hi guys, > > > > I am attending a python lecture and discovered DocTest[1], and I was > wondering if such a tool exists for Pharo ? :) > > > > > > Ben > > > > [1]http://docs.python.org/2/library/doctest.html > > > > > > >

Jan. 22, 2013

Re: [Pharo-project] Fonts in Pharo By Example

by Sean P. DeNigris

Gary Chambers-4 wrote > always look up fonts via LogicalFont class methods these days... Thanks, Gary! That actually solved an immediate problem I was dealing with :) And I'm hoping a font guru will take a deeper cut for us ignorant masses ;) -- View this message in context: http://forum.world.st/Fonts-in-Pharo-By-Example-tp4664406p4664664.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 22, 2013

Re: [Pharo-project] DocTest

by Benjamin

With Nicolas Petton we implemented it yesterday afternoon :) It's missing Nautilus integration, but the code is pretty much there :) (I will provide the repo asap) Ben On Jan 22, 2013, at 6:46 PM, Sean P. DeNigris wrote: > Benjamin Van Ryseghem-2 wrote >> I am attending a python lecture and discovered DocTest[1], and I was >> wondering if such a tool exists for Pharo ? :) > > I've been dreaming about, and doing experiments around, this for quite a > while... could be so much better in st because we can create custom UI tools > instead of text files... > > > > -- > View this message in context: http://forum.world.st/DocTest-tp4664547p4664617.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 22, 2013

Re: [Pharo-project] [Ann] New version of Mocketry

by StÃ©phane Ducasse

On Jan 22, 2013, at 4:24 PM, Denis Kudriashov wrote: > 2013/1/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > ConfigurationOfMocketry > Tests > > This is already exists many years (thank's Laurent Laffont for configuration) > > SmallLint rules applied. > > Never use it. I will try. We are making the process smoother :) Wait a bit :) S.

Jan. 22, 2013

Re: [Pharo-project] SmallLint applied on Pharo: Continued

by StÃ©phane Ducasse

Jan what is the license of your tags and other code? Stef On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote: > On 22/01/13 18:22, StÃ©phane Ducasse wrote: >> Hi >> >> I'm running the rule RBSubclassResponsibilityNotDefinedRule that >> >> Checks that all subclassResponsibility methods are defined in all leaf classes. >> >> Now the results display the sender of ^ subclassResponsibility but I have to manually find the >> problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method. >> >> But this would be much better. Jan did you do that in your version? > > Good point. Yes, since now we do that :-) > > Jan > >> >> Stef >> > >

Jan. 22, 2013