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

Re: [Pharo-project] NativeBoost and unions

by Marcus Denker

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] [ANN] Headless support for Cog Cocoa VM

by Esteban Lorenzano

yeah, I declare my self guilty for having that incredibly ugly idea... :) On Jan 21, 2013, at 3:35 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sat, Jan 19, 2013 at 1:08 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Mariano Martinez Peck wrote > > thanks Square [i] International <http://www.square-i.net/> > > ... headless support will be included in the official Pharo > > VM and will be, therefore, accessible to everybody. > > Yes, thank you, thank you!! I've been using Pharo for Jenkins build scripts, > and it was really disruptive to see the image pop up every time a job > started. > > As to the flag limitation, I think for now I'll have two copies of the VM - > a headful one, which will be the default on my Mac, and one with the > headless flag set, that gets explicitly launched by Jenkins... not perfect, > but a HUGE step!! > > Yes, that's the easiest way. > I spent *a lot* of time trying to find another way, but they all failed. There is one possibility that should work but it is too hacky for me: > very at the beginning of the VM (before starting Cocoa) read the arguments. If "-headless" is present, then programmatically set/write the flag in the Info.plist. If it it not, do nothing (or set it to false). But modifying the file on startup looks hacky to me. I prefer the user to manually set it. > > > Cheers, > Sean > > > > -- > View this message in context: http://forum.world.st/ANN-Headless-support-for-Cog-Cocoa-VM-tp4664137p46642… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 22, 2013

Re: [Pharo-project] Closing unresolved issues

by Sven Van Caekenberghe

+1 On 21 Jan 2013, at 17:35, "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). > > Cheers, > Sean

Jan. 22, 2013

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

by Benjamin

I received your mail so I guess :) Ben On Jan 21, 2013, at 5:17 PM, Tudor Girba 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"

Jan. 22, 2013

[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