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

[Pharo-project] [Issue Tracker] Status

by Marcus Denker

Overall open issues: http://code.google.com/p/pharo/issues/list?can=2 Issues tagged 2.0: http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D2.0 It would be nice if everyone would check the issues that she/he is involved with and answer the question: "What needs to be done as the next step to move this issue forward to a state where we can close the entry?" If there are issues where *You* where supposed to do something for the last 6 Month but it turned out to be so non-important that you never did, please consider that maybe the report itself is not important enough to stay open. Marcus

Jan. 22, 2013

Re: [Pharo-project] where can I find the latest athens?

by StÃ©phane Ducasse

yes but I could not find it and I looked around. On Jan 20, 2013, at 7:30 PM, Camillo Bruni wrote: > You should not even have to ask for it ;) > > https://ci.inria.fr/rmod/job/Athens/ > > > On 2013-01-20, at 16:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Because I want to try boids. >> >> Stef >> > >

Jan. 21, 2013

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

by StÃ©phane Ducasse

On Jan 20, 2013, at 3:08 PM, Denis Kudriashov wrote: > Hello. > > I upload new version of Mocketry 2.1 to smalltalkhub http://www.smalltalkhub.com/#!/~dionisiy/Mocketry . > > Changes: > > 1) All code now migrated to smalltalkhub repository. New configuration with version 2.1 implemented accordingly. > 2) State specs extracted to separate project "StateSpecs" with separate configuration. This project contains all object state specifications and validation stuff. Mocketry depends on it and only implements behaviour specs and mock objects. StateSpecs can be used in different projects. I use it in Presenty to describe data fields validness. > 3) Main new feature is stub behaviour. You can teach mock for stubs with: > mock stub someMessage willReturn: 'result' > And then mock can receive #someMessage everywhere anytimes. So you don't need scenario block if you only need stubs behaviour. > 4) Few state specs like > dictionary should include: item at: #key > > It will be cool if Mocketry become part of Pharo tools. What I can do for this? ConfigurationOfMocketry Tests SmallLint rules applied. Ideally we want to manage pharo as a list of configuration + a main one. Then people should be able to load in one click "certified" package via their configuration. Then if people write a lof of mockertry based tests for the central part of the system it can sit side by side to SUnit. But in general the idea is to have a modular system so first steps are above. > Mock objects to me is main tool to design and implement flexible object systems. And Mocketry simplifies mock objects technique very much. > > Best regards, > Denis > >

Jan. 21, 2013

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

by H. Hirzel

Dave I wonder why you can't check for Smalltalk at: #OSPlatform and if that exists go for OSPlatform osVersion Neither Squeak nor Cuis do have an OSPlatform class. Then you go for Smalltalk os version 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. 21, 2013

[Pharo-project] NativeBoost and unions

by Ciprian Teodorov

Hi Igor, as usual after squeaksource restart, i lost my commit rights on the NativeBoost repository... This time I have a small refactoring in the NBExternalStruct/NBExternalStructFields to enable union support. Besides that, c unions, I have implemented a first prototype, and now my question for you is: Should I add it in nativeboost (its rightful place in my opinion), or should I keep it only as support code for my TalkFFI project(in TalkFFI-runtime)? What do you think? Cheers, Ciprian -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Jan. 21, 2013

[Pharo-project] Object>>#name

by Sven Van Caekenberghe

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. 21, 2013

[Pharo-project] [update 2.0] #20481

by Marcus Denker

Jan. 21, 2013

[Pharo-project] Closing unresolved issues

by Sean P. DeNigris

For example... Issue 5656: Large fonts make tools slow http://code.google.com/p/pharo/issues/detail?id=5656 This issue has not been resolved, but the issue was closed, leading to this experience... - I just upgraded a project to 2.0 - I notice that the UI is very slow - a simple Spec dialog window with a few text fields and buttons takes ~4 seconds to open - I check the issue tracker because I remember I reported the bug already, but I don't find it in the open issues - I waste time because I think it must be something else - I finally expand my search through the issues and find my report was closed as invalid I'm not saying that this is wrong, just that I don't understand and want to share another perspective and come to the best solution... What benefit are we getting from closing these that is significant enough to justify this kind of experience (I'm sure I'm not the only one). Cheers, Sean -- View this message in context: http://forum.world.st/Closing-unresolved-issues-tp4664420.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 21, 2013

Re: [Pharo-project] is the list working?

by Marcus Denker

I think not. I will write a mail to support... On Mon, Jan 21, 2013 at 5:17 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I did not receive any mails today from the pharo-project mailing list > (21.01.2013). Is it still working? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Jan. 21, 2013

[Pharo-project] is the list working?

by Tudor Girba

Hi, I did not receive any mails today from the pharo-project mailing list (21.01.2013). Is it still working? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Jan. 21, 2013