- Pharo-dev - lists.pharo.org

Re: [Pharo-project] XMLRPC Project - Progress Report
by StÃ©phane Ducasse Oct. 4, 2010

Oct. 4, 2010

:) >> Tell us when pharo core can be a user. >> Because we want to clean the mess. > > I know you are anxious to do so, and it will happen one day, for sure. Not anxious :) Happily eager :) > > There is still some technical work to do, but the most important thing is that we need as much users as possible to shake out the bugs. The code has to prove itself for others (with different encodings/languages/networks). > > Sven > > PS: As I said before, I am using it myself everyday, working in a Pharo 1.1 image were all HTTPSocket stuff is routed to Zn, so far so good. I also replaced all my other HTTP client uses by using Zn directly, and that works well too. We're getting closer. Excellent. I want to have nice code so that I can learn something.

1 0

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock
by StÃ©phane Ducasse Oct. 4, 2010

Oct. 4, 2010

please clean. Use version management to control impact on other clients. Else we cannot move and this is agony. slow and painful. Stef >> Ok, let's summarize: If an error occurs, the handler block is not >> evaluated, but attached to a new exception, that exception is raised. >> Then, the caller catches that exception, retrieves the handler block, >> does some more ballyhoo, and then runs the handler block. > > Yes, the block mostly contains some code to that allows the user to > fix the problem (like to show all references of a class to be removed, > etc.). > >> And you get invited to this construction by these methods in >> RBAbstractCondition: >> >> errorBlock >> ^self errorBlockFor: false >> >> errorBlockFor: aBoolean >> ^nil > > These methods (and subclass implementations) are used to retrieve the > right block that caused the composite condition to fail. > >> We can clean it up on the next sprint, if you want :) > > The implementation in RBCondition is fine, the problem is more the way > how exceptions are used to pass the values. This mainly stems from the > fact that exceptions evolved over the past 15 years and are no longer > the same as the signals that were used when the refactoring code was > originally written. > > Now of course it is difficult to change this code because there are > various users out there that depend on it, e.g. OB, > RefactoringBrowser, SmaCC, ... > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] CodeMorph >> text should return an instance of Text but return a String
by StÃ©phane Ducasse Oct. 4, 2010

Oct. 4, 2010

Excellent! On Oct 4, 2010, at 11:10 AM, Fernando olivero wrote: > ISSUE 2902: CodeMorph removal . > > Done, added the change set and set the issue to fixed. > > > Fernando > > On Oct 1, 2010, at 12:58 PM, Fernando olivero wrote: > >> Yes, i've been busy so i couldn't finish this issue. >> >> Because CodeMorph comes from Gaucho, and until now there was no need for it in the Pharo-Core. so i will remove it, and possibly when the need arises will propose its re-inclusion. >> >> Fernando >> pd: the idea behind CodeMorph is to have a specialized NewTextMorph for dealing with Methods sources, Class definitions. But now i have second thoughts, because i have the impression that having diferent Editors ( subclasses of TextEditor or SmalltalkEditor) should do the trick. >> >> On Oct 1, 2010, at 12:02 PM, Cyrille Delaunay wrote: >> >>> I just saw that there is propositions to remove CodeMorph: >>> >>> http://code.google.com/p/pharo/issues/detail?id=2902&q=CodeMorph&colspec=ID… >>> >>> So maybe the best fix will be to remove all the tests related ? :) >>> >>> 2010/10/1 Cyrille Delaunay <cy.delaunay(a)gmail.com> >>> In pharo 1.2, NewTextMorphTests>>#testFullMethodName raise an error. This error happen when calling: >>> >>> CodeMorph >> defaultStyledText >>> | text attribute | >>> text := self text. >>> text addAttribute: ( self newTextColorAttribute: Color black ). >>> ^ text. >>> >>> text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is: >>> >>> beFullMethodName >>> aspect := #selector. >>> adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ]. >>> >>> The block return a String and I guess the right code should be >>> >>> beFullMethodName >>> aspect := #selector. >>> adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ] >>> >>> ??. >>> >>> >>> I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031 >>> >>> <ATT00001..txt> >> >> <ATT00001..txt> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] Senders
by Benjamin Van Ryseghem Oct. 4, 2010

Oct. 4, 2010

Hi guys Am I the only one who can't browse senders anymore ? I'm working on 1.2-12168 Benjamin

2 1

[Pharo-project] [update 1.2] #12169
by StÃ©phane Ducasse Oct. 4, 2010

Oct. 4, 2010

12169 ----- - fixing showMenus. Thanks Gary Chambers

1 0

Re: [Pharo-project] Problem with popup lists (Senders of, implementors of etc.)
by StÃ©phane Ducasse Oct. 4, 2010

Oct. 4, 2010

Thanks this is my mistake.... I will integrate it now. On Oct 4, 2010, at 12:57 PM, Gary Chambers wrote: > Hi. > > Since the update to 12168 I am getting an MNU... > Tracked down to > > showMenuOf: selectorCollection withFirstItem: firstItem ifChosenDo: choiceBlock withCaption: aCaption > "Show a sorted menu of the given selectors, preceded by firstItem, and all abbreviated to 40 characters. Use aCaption as the menu title, if it is not nil. Evaluate choiceBlock if a message is chosen." > > | index menuLabels sortedList | > sortedList := selectorCollection asSortedCollection. > menuLabels := Array streamContents: > [:strm | strm nextPutAll: (firstItem contractTo: 40). > sortedList do: [:sel | strm nextPutAll: (sel contractTo: 40)]]. > index := UIManager default chooseFrom: (menuLabels substrings) lines: #(1). > index = 1 ifTrue: [choiceBlock value: firstItem]. > index > 1 ifTrue: [choiceBlock value: (sortedList at: index - 1)] > > The following revision seems to work ok... > > > showMenuOf: selectorCollection withFirstItem: firstItem ifChosenDo: choiceBlock withCaption: aCaption > "Show a sorted menu of the given selectors, preceded by firstItem, and all abbreviated to 40 characters. Use aCaption as the menu title, if it is not nil. Evaluate choiceBlock if a message is chosen." > > | index menuLabels sortedList | > sortedList := selectorCollection asSortedCollection. > menuLabels := Array streamContents: > [:strm | strm nextPut: (firstItem contractTo: 40). > sortedList do: [:sel | strm nextPut: (sel contractTo: 40)]]. > index := UIManager default chooseFrom: menuLabels lines: #(1). > index = 1 ifTrue: [choiceBlock value: firstItem]. > index > 1 ifTrue: [choiceBlock value: (sortedList at: index - 1)] > > Regards, Gary > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] Wrong fix: Issue 2947: SmalltalkEditor doesn't handle ESC key.
by Fernando olivero Oct. 4, 2010

Oct. 4, 2010

I argue that this fix is wrong, giving the morph logic to the Editor instead of the View ( the morph). this conceptual problem, leads to having to ask for the Global ActiveEvent in the Editor>>offerMenuFromEsc:. If you take a look at the already present method, which should be the one to be used. Editor>>escapePressed "The message is sent when the user hits esc" self announceEscape Which allows the Morph to take care of the view related behavior. So i propose reverting to this behavior: Editor>>escapePressed self morph escapePressed . ^ false Then adding TextMorph>>escapePressed self yellowButtonActivity: false. TextMorphForEditView>>escapePressed self editView yellowButtonActivity: false . Given that TextMorphForEditView is the only implementor of #editView, and following the logic in TextEditor>>raiseContextMenu: TextEditor>>offerMenuFromEsc: aKeyboardEvent The attached change set implements the fixes.

1 0

[Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock
by Niko Schwarz Oct. 4, 2010

Oct. 4, 2010

Hi, The RB refactorings do some obscure dance around an errorBlock, which is always nil, as far as I can see. As I was trying to supply a non-nil error block, I was astonished to find out that even if it isn't nil, it won't be executed. Here's the relevant snippets: checkPreconditions | conditions block | conditions := self preconditions. conditions check ifFalse: [block := conditions errorBlock. block notNil ifTrue: [self refactoringError: conditions errorString with: block] ifFalse: [self refactoringError: conditions errorString]] refactoringError: aString with: aBlock ^ RefactoringError signal: aString with: aBlock I can't imagine how that could help anyone. I suggest either removing the errorBlock, or turning it into a good old instance variable, and running it in case of an error. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

2 6

Oct. 4, 2010

hi gary do we need handleDisabledKey: because this is not defined on the new editorHierarchy? http://code.google.com/p/pharo/issues/detail?id=3003 Stef

3 5

[Pharo-project] [OT] NO-SLQ vs RDBMS Re: FluidDB API for Pharo
by Mariano Martinez Peck Oct. 4, 2010

Oct. 4, 2010

Hi. Can someone with experience in "No-SQL" databases explain me the differences/advantages over a RDBMS and doing something like: create table database (key varchar() , value varchar() ) thanks mariano On Sat, Sep 25, 2010 at 10:30 AM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 25 Sep 2010, at 10:22, Jordi Delgado wrote: > > > Hi > > > > I write just to let you know that we (the smalltalk.cat group) did an > > API to interact with a nice no-SQL database called FluidDB. It has been > > mainly the work of Sergio Garcia, but there is a little of some of us in > the > > tests and the code: > > http://www.squeaksource.com/FluidDB.html > > To see what this FluidDB is: > > http://fluidinfo.com/ > > > > Bests, > > > > Jordi > > Sounds interesting, however the SqueakSource project has a 'Global: no > access', so we can't see anything. > > Sven > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

6 6