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

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

[Pharo-project] User Interrupt Broken?!

by Sean P. DeNigris

Has anyone else noticed this? Open a fresh 2.0482 latest and hit Cmd-. a bunch of times. If the debugger opens on the first, close it and keep pressing the shortcut. Most presses seem to do nothing. -- View this message in context: http://forum.world.st/User-Interrupt-Broken-tp4664619.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 22, 2013

Re: [Pharo-project] Closing unresolved issues

by Sean P. DeNigris

StÃ©phane Ducasse wrote > The problem is what do we do if we have many bugs with nobody looking at > them. Maybe a good compromise would be a status like "Stale", where we can exclude them from searches if we want, but they are still being tracked? -- View this message in context: http://forum.world.st/Closing-unresolved-issues-tp4664420p4664618.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 22, 2013

Re: [Pharo-project] DocTest

by Sean P. DeNigris

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... -- View this message in context: http://forum.world.st/DocTest-tp4664547p4664617.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 22, 2013

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

by Gary Chambers

+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] Object>>#name

by StÃ©phane Ducasse

> 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â¦ + 1 Open a bug entry for 3.0 Stef > > > > -- > 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] What are the messages where we should always have a super send?

by StÃ©phane Ducasse

On Jan 22, 2013, at 7:19 AM, Jan Vrany wrote: > 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… Ok It is a good idea. What is the license of the changes you did? And sorry but we do not want to have author in comment for the moment :) > Could you please give me a pointer where newest Lint for Pharo > lives? For now it lives in Pharo20. Once we migrate for real to smalltalkHub I want to have subprojects for RB, SmallLint. We tried for while to have none disruptive changes by putting changes as extensions of code critics but it does not work for cleaning the rules. Stef > > > 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