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

Re: [Pharo-project] DocTest

by Camillo Bruni

for that we already have a fully working Phexample: http://www.squeaksource.com/phexample.html which I will push in 3.0, cause I never really liked #assert: and friends being sent to self. Furthermore we could finally build up decent messages! On 2013-01-22, at 18:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > it would be nice to introduce the same syntax than Sunit > > exp assert: exp2 > > [ exp ] shouldraise: > > 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. 23, 2013

[Pharo-project] Athens replacement for ImageReadWriter?

by Esteban Lorenzano

Hi, So, ImageReadWriter currently reads image files and retrieve Form objects, who can be displayed in world... anybody knows (cough, cough, Igor) what would be the Athens replacement for that? thanks, Esteban

Jan. 23, 2013

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

by StÃ©phane Ducasse

> 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. Else I will just go over them and it will help me to understand. I think that this is not difficult. > 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 :-) I imagine well. Let us keep it simple. Simple tags with a little class comments are good enough :) > > 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 01:51:56PM -0800, Chris Cunningham wrote: > On Tue, Jan 22, 2013 at 12:13 PM, David T. Lewis <lewis(a)mail.msen.com>wrote: > > > 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 > > > >> > > > 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. > > > > Could you capture for deprecation of OSPlatform osVersion, and resend the > other method (Smalltalk osVersion current osVersion)? Or, trap for > Deprecation and resume it (ignore deprecation - once it is removed, you'll > automatically fail-over to the new code). No, Pharo 2.0 is writing console output whenever an exception occurs, so catching the exception is not good. But not raising the exception in the first place works just fine ;) Dave

Jan. 22, 2013

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

by Chris Cunningham

On Tue, Jan 22, 2013 at 12:13 PM, David T. Lewis <lewis(a)mail.msen.com>wrote: > 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 > > >> > > 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. > Could you capture for deprecation of OSPlatform osVersion, and resend the other method (Smalltalk osVersion current osVersion)? Or, trap for Deprecation and resume it (ignore deprecation - once it is removed, you'll automatically fail-over to the new code).

Jan. 22, 2013

Re: [Pharo-project] Fwd: [squeak-dev] The Inbox: Monticello-nice.528.mcz

by Nicolas Cellier

Probably not, it was not the right interpretation... 2013/1/22 Sven Van Caekenberghe <sven(a)stfx.eu>: > Probably worth picking up: > > Begin forwarded message: > >> From: Bert Freudenberg <bert(a)freudenbergs.de> >> Subject: Re: [squeak-dev] The Inbox: Monticello-nice.528.mcz >> Date: 22 Jan 2013 20:12:14 GMT+01:00 >> To: squeak-dev(a)lists.squeakfoundation.org >> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> >> >> >> On 22.01.2013, at 14:42, commits(a)source.squeak.org wrote: >> >>> A new version of Monticello was added to project The Inbox: >>> http://source.squeak.org/inbox/Monticello-nice.528.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Monticello-nice.528 >>> Author: nice >>> Time: 22 January 2013, 3:42:35.787 pm >>> UUID: 3bc3c4a2-2ec6-e942-9517-5da75b32bac5 >>> Ancestors: Monticello-bf.527 >>> >>> Let MCTool inherit from Model. >>> This is to avoid nasty garbage to survive in DependentsFields with kilo bytes of un-released MCDefinition cache. >> >> Looks reasonable. Commit it and we'll find out soon if there are problems. >> >> - Bert - > >

Jan. 22, 2013

Re: [Pharo-project] DocTest

by Benjamin

You can have a look here Gofer it url: 'http://smalltalkhub.com/mc/BenjaminVanRyseghem/DocTest/main'; package: 'DocTest'; load. Then you can have a look at the test to see how it works :) Basically MockCommentWithValidTests is a class with a comment containing valid test then you can do (DocTest testClass: MockCommentWithValidTests) run It will run the test, and notify if something is wrong Ben On Jan 22, 2013, at 9:49 PM, Denis Kudriashov wrote: > 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] Object>>#name

by Sven Van Caekenberghe

On 22 Jan 2013, at 20:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi gary > > we will address it. :) > > Stef http://code.google.com/p/pharo/issues/detail?id=7304 > On Jan 22, 2013, at 3:31 PM, Gary Chambers wrote: > >> Indeed, is a common accessor for domain/business objects. >> Have got use to having to re-implement each time myself but quicker to not have to. >> >> Regards, Gary >> >> ----- Original Message ----- From: "Sven Van Caekenberghe" <sven(a)stfx.eu> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, January 21, 2013 6:43 PM >> Subject: [Pharo-project] Object>>#name >> >> >> Hi, >> >> Many people have hit the fact that Object implements #name, which then seems to conflict with some other class where one would really like to use name as an instance variable and thus accessor. >> >> Turns out that it seems that Object>>#name is actually not used (anymore). >> >> I just put a halt in it and tried a couple of tools and everything seems to work just fine. >> >> The comment talks about Inspector use, but there is #defaultLabelForInspector for that. >> >> It is a small thing, but it confuses everybody for no good reason, >> >> Any comments ? >> >> Sven >> >> PS: it was also in the testing procotol ;-) >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> > >

Jan. 22, 2013

[Pharo-project] Fwd: [squeak-dev] The Inbox: Monticello-nice.528.mcz

by Sven Van Caekenberghe

Probably worth picking up: Begin forwarded message: > From: Bert Freudenberg <bert(a)freudenbergs.de> > Subject: Re: [squeak-dev] The Inbox: Monticello-nice.528.mcz > Date: 22 Jan 2013 20:12:14 GMT+01:00 > To: squeak-dev(a)lists.squeakfoundation.org > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > > On 22.01.2013, at 14:42, commits(a)source.squeak.org wrote: > >> A new version of Monticello was added to project The Inbox: >> http://source.squeak.org/inbox/Monticello-nice.528.mcz >> >> ==================== Summary ==================== >> >> Name: Monticello-nice.528 >> Author: nice >> Time: 22 January 2013, 3:42:35.787 pm >> UUID: 3bc3c4a2-2ec6-e942-9517-5da75b32bac5 >> Ancestors: Monticello-bf.527 >> >> Let MCTool inherit from Model. >> This is to avoid nasty garbage to survive in DependentsFields with kilo bytes of un-released MCDefinition cache. > > Looks reasonable. Commit it and we'll find out soon if there are problems. > > - Bert -

Jan. 22, 2013

Re: [Pharo-project] SmallLint journey: another rule :)

by Sven Van Caekenberghe

On 22 Jan 2013, at 20:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I'm trying the Temporaries read before written and I have the impression that I found a bug in the > RBReadBeforeWrittenTester class > because it flags connections (but connections is not a temp but an instance variable). > > Did anybody experience the same? Yes, I have seen it and I didn't understandâ¦ > Stef > > listenLoop > "Private! This loop is run in a separate process. It will establish up to maxQueueLength connections on the given port." > "Details: When out of sockets or queue is full, retry more frequently, since a socket may become available, space may open in the queue, or a previously queued connection may be aborted by the client, making it available for a fresh connection." > "Note: If the machine is disconnected from the network while the server is running, the currently waiting socket will go from 'isWaitingForConnection' to 'unconnected', and attempts to create new sockets will fail. When this happens, delete the broken socket and keep trying to create a socket in case the network connection is re-established. Connecting and disconnecting was tested under PPP on Mac system 8.1. It is not if this will work on other platforms. > > Fixed to not accept the connection if the queue is full (gvc)." > > > | newConnection | > > socket := Socket newTCP. > "We'll accept four simultanous connections at the same time" > socket listenOn: portNumber backlogSize: 4. > "If the listener is not valid then the we cannot use the > BSD style accept() mechanism." > socket isValid ifFalse: [^self oldStyleListenLoop]. > [true] whileTrue: [ > socket isValid ifFalse: [ > "socket has stopped listening for some reason" > socket destroy. > (Delay forMilliseconds: 10) wait. > ^self listenLoop ]. > [newConnection := socket waitForAcceptFor: 10] > on: ConnectionTimedOut > do: [:ex | newConnection := nil]. > (newConnection notNil and: [newConnection isConnected]) > ifTrue: [(accessSema critical: [connections size < maxQueueLength]) > ^^^^^^^^^^ > > > > ifFalse: [newConnection close. newConnection := nil]] > ifFalse: [newConnection := nil]. > (newConnection notNil and: [newConnection isConnected]) ifTrue: [ > accessSema critical: [connections addLast: newConnection]. > newConnection := nil. > self changed]. > self pruneStaleConnections].

Jan. 22, 2013