- Pharo-dev - lists.pharo.org

[Pharo-project] a test :) yet another one.

by StÃ©phane Ducasse

Jan. 22, 2013

[Pharo-project] Fwd: [Moose-dev] ZnUrl, Encoding

by H. Hirzel

I assume this question is better placed here .... I am interested in the answer as well. --Hannes ---------- Forwarded message ---------- From: Dennis Schenk <d.schenk(a)students.unibe.ch> Date: Tue, 22 Jan 2013 14:00:06 +0100 Subject: [Moose-dev] ZnUrl, Encoding To: Moose-related development <moose-dev(a)iam.unibe.ch> Hi all, I stumpled upon a problem with encoding of URLs in Pharo. I am using the Google Geocoding API. For example I want to get the result of: http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+CuraÃ§… When one enters this in a Browser a correct JSON response is returned. If I do the following: *(Url absoluteFromText: ' http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+CuraÃ§…<http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Cura%C…>') retrieveContents contents.* I get an error back grom Google. When digging through the code I found that in ZnHTTPSocketFacade the following happens: *' http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+CuraÃ§…<http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Cura%C…>' asZnUrl * And the result of this is: http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Cura%C… * * Which Google does not know how to handle and then returns an error. Does anyone have an idea how I could get contents from a URL which has special chars like '*Ã§'?* Or is there a way to convert all special chars to to their 'normal' counterparts, like *Ã§ -> c?* * * Cheers, Dennis

Jan. 22, 2013

[Pharo-project] ping

by Camillo Bruni

Jan. 22, 2013

Re: [Pharo-project] What are the messages where we should always have a super send?

by StÃ©phane Ducasse

> Yes, #setUp and #tearDown Really. Ok I was not aware of it. Good idea. Stef > For #initialize, having a super may not be that necessary if you working on the class side. > > Alexandre > > > On Jan 18, 2013, at 12:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi >> >> While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a >> super send. >> >> Here is the current list: >> >> ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) >> >> >> and I'm cleaning the list because there are VW elements such as postBuildWith: >> but do we have some other to add? >> >> Stef >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Jan. 22, 2013

Re: [Pharo-project] What are the messages where we should always have a super send?

by Jan Vrany

Hi, On 19/01/13 10:16, StÃ©phane Ducasse wrote: > Hi jan > > do you have an example of such tagging? Look at RBTranslateLiteralsInMenusRule class>>tagsBasic, RBNilOrEmptyCollectionReplaceRule, RBMethodSourceContainsLinefeedRule, RBTempsReadBeforeWrittenRile RBLawOfDemeterRule RBContainsNamespaceIdentifiersRule at http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ Some comment on tagging http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/RB… Could you please give me a pointer where newest Lint for Pharo lives? Cheers, Jan > Right now we are also thinking that we want three kinds of rules > - 1 whose result is either zero because there is no problem or zero because we flag the false positives > - 2 more fuzzy one where we should have flase positive defined per package > - 3 more statistical rules (long methods, large number of instance variables) > > We are checking how we can find decent threshold values not generating thousands of warnings and > also if we want to embed false positives for them too. May be they are just good for trend analysis and > when you want to spot ugly code but you do not care to have them under your nose systematically. > > For the rules I'm also changing the implementation to make sure that we can customized the list of selectors, thresholds â¦. > without having to recompile a method. This way people will be able to use their own conventions. > > Stef > > On Jan 18, 2013, at 6:24 PM, Jan Vrany wrote: > >> Hi Stef, >> >> while massaging SmallLint rules, you should also have look at >> Smalltalk/X version of SmallLint [1] as we have ported >> Pharo version and improved some rules. I have also added >> a tagging system. That's useful for some rules are only >> good if you want to ensure portable code, some are simply >> broken and some stupid, etc. Having them properly classified >> would help us all. >> >> Tell me once you finish your ride, I'll merge changes back :-) >> >> Jan >> >> [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ >> >> to checkout issue: >> >> cvs -d :pserver:cvs@cvs.smalltalk-x.de:/cvs/stx co stx/goodies/refactoryBrowser/lint/ >> >> >> On 18/01/13 17:06, StÃ©phane Ducasse wrote: >>> Hi >>> >>> While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a >>> super send. >>> >>> Here is the current list: >>> >>> ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) >>> >>> >>> and I'm cleaning the list because there are VW elements such as postBuildWith: >>> but do we have some other to add? >>> >>> Stef >>> >>> >>> >> >> > > >

Jan. 22, 2013

[Pharo-project] [update 2.0] #20482

by Marcus Denker

20482 ----- Issue 7261: Improve PharoUser>>#retrieveGravatarFromMail:size: ZnClient usage http://code.google.com/p/pharo/issues/detail?id=7261 Issue 7267: Update Pharo License String to 2013 http://code.google.com/p/pharo/issues/detail?id=7267 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.761.diff http://ss3.gemstone.com/ss/Pharo20/KeyChain-MarcusDenker.27.diff

Jan. 22, 2013

[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