- Pharo-dev - lists.pharo.org

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

by Marcus Denker

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â¦ > 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] Closing unresolved issues

by Marcus Denker

On Jan 22, 2013, at 5:17 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > 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). > Yes, I was too fast closing this reportâ¦ I will open it again. Marcus

Jan. 22, 2013

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

by Jan Vrany

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] Fonts in Pharo By Example

by Gary Chambers

Have got used to using FreeType so always look up fonts via LogicalFont class methods these days... headingFont "Answer the font for headings." ^LogicalFont familyName: 'Arial' pointSize: 20 Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, January 22, 2013 5:26 PM Subject: Re: [Pharo-project] Fonts in Pharo By Example On Jan 21, 2013, at 11:57 AM, Sean P. DeNigris wrote: > It would be great to have a section in PBE2 about fonts. I find them very > confusing - TrueType, FreeType, Logical, etc. Understanding how they're > handled in Pharo requires background knowledge, and an overview and a few > specific examples could really do some good. If somebody explain it It would be great. I always wanted to read something on fonts but unfortunately I feel a bit alone on the writing side This is why I love the attitude of sven to produce doc. Stef > > Cheers, > Sean > > > > -- > View this message in context: > http://forum.world.st/Fonts-in-Pharo-By-Example-tp4664406.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 22, 2013

Re: [Pharo-project] Object>>#name

by Gary Chambers

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] SmallLint applied on Pharo: Continued

by StÃ©phane Ducasse

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? Stef

Jan. 22, 2013

Re: [Pharo-project] Object>>#name

by Esteban Lorenzano

+1 On Jan 22, 2013, at 6:45 PM, "Gary Chambers" <gazzaguru2(a)btinternet.com> wrote: > +1 to removal... > > 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 5:02 PM > Subject: Re: [Pharo-project] Object>>#name > > >> Sven Van Caekenberghe-2 wrote >>> 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. >> >> Yes, I've been bitten by this a few times. When developing through the >> debugger, it's confusing when the thing fails silently instead of prompting >> to create the method. >> >> >> Sven Van Caekenberghe-2 wrote >>> Turns out that it seems that Object>>#name is actually not used (anymore). >> >> There are lots of senders... I guess they're sending Class>>#name or another >> message. I say ditch it, but wait until 3.0... >> >> >> >> -- >> View this message in context: http://forum.world.st/Object-name-tp4664573p4664583.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 22, 2013

Re: [Pharo-project] NativeBoost and unions

by Esteban Lorenzano

as all the core packages for pharo (and NB is one of them), it should be in smalltalkhub :) On Jan 22, 2013, at 5:29 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jan 22, 2013, at 5:26 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > >> Hi Igor, >> >> as usual after squeaksource restart, i lost my commit rights on the NativeBoost repository... >> > > Could NativeBoost move away from SqueakSource? SqueakSource is not stable. > >> 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. 22, 2013

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

by Sven Van Caekenberghe

Hi Dennis, I don't know where you were trying this, it does not change the explanation, but in Pharo 2.0 with the latest Zinc HTTP Components code, your example gives an error: 'http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+CuraÃ§…' asZnUrl retrieveContents. ZnCharacterEncodingError: ASCII character expected. and rightfully so: an encoded URL cannot contain these characters. There is a difference between internal and external encoding of URLs and of ZnUrl. One way to do it correctly is: 'http://maps.googleapis.com/maps/api/geocode/json' asZnUrl queryAt: #address put: 'Willemstad, CuraÃ§ao'; queryAt: #sensor put: 'false'; queryAt: #language put: #en; retrieveContents. Please check the extensive class comment of ZnUrl. Leave the problem of encoding to ZnUrl, supply the internal values directly ;-) So why does it work in your browser ? Because your browser's URL entry field has very permissive parsing, doing this conversion as an extra service, above what is required. ZnUrl is stricter. HTH, Sven On 22 Jan 2013, at 15:13, "H. Hirzel" <hannes.hirzel(a)gmail.com> wrote: > 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 -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 22, 2013

Re: [Pharo-project] [Issue Tracker] Status

by Sean P. DeNigris

HumanReviewNeeded: http://code.google.com/p/pharo/issues/detail?id=7108 -- View this message in context: http://forum.world.st/Issue-Tracker-Status-tp4664590p4664623.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 22, 2013