- Pharo-dev - lists.pharo.org

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

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