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

[Pharo-project] OCompletion configuration for 1.4

by Guillermo Polito

I've written a new version of OCompletion for 1.4 with several fixes and compatibility additions for Pharo 1.4 Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOCompletion'; load. ConfigurationOfOCompletion loadStable If someone wants to try it :). Guille

Jan. 13, 2012

Re: [Pharo-project] Cmd-q autocompletion?

by Sven Van Caekenberghe

On 13 Jan 2012, at 14:59, Guillermo Polito wrote: > I've just realized that we have an autocompletion mechanism that is not OCompletion in the image, typing cmd-q. And also, it is just querying the Symbol table: Amazing, great ! It seems like a 'cheap' mechanism, let's keep it. Sven

Jan. 13, 2012

Re: [Pharo-project] Cmd-q autocompletion?

by Igor Stasenko

There's a lot of fuzzy stuff in OCompletion/ECompletion too. Would be nice to clean it up and make things more uniform. On 13 January 2012 15:21, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > How about (maybe for 1.5) think in making it pluggable? :P > > > On Fri, Jan 13, 2012 at 11:14 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 13 January 2012 14:59, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> > I've just realized that we have an autocompletion mechanism that is not >> > OCompletion in the image, typing cmd-q.Â And also, it is just querying >> > the >> > Symbol table: >> > >> > selectorsFromPrefix: aPrefix >> > Â Â Â "returns the value of labels from a selector prefix" >> > Â Â Â | key applicants | >> > Â Â Â aPrefix isEmptyOrNilÂ ifTrue: [^ #()]. >> > Â Â Â applicants := aPrefix first canBeGlobalVarInitial >> > Â Â Â Â Â Â ifTrue: [Array streamContents: [:strm | >> > Â Â Â Â Â Â Â Â Â Symbol allSymbolTablesDo: [:each | >> > Â Â Â Â Â Â Â Â Â Â Â Â (each notEmpty and: [each first canBeGlobalVarInitial]) >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [strm nextPut: each]]]] >> > Â Â Â Â Â Â ifFalse: [Array streamContents: [:strm | >> > Â Â Â Â Â Â Â Â Â Symbol allSymbolTablesDo: [:each | >> > Â Â Â Â Â Â Â Â Â Â Â Â (each notEmpty and: [each first canBeGlobalVarInitial >> > not]) >> > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [strm nextPut: each]]]]. >> > Â Â Â key := aPrefix asLowercase. >> > Â Â Â ^ (applicants select: [:each | (each asLowercase beginsWith: key) >> > and: >> > [each noneSatisfy: [:c | c tokenish not]]]) sort >> > >> > >> > Does anybody use it?Â Is it useful?Â Because I was loading OCompletion >> > into >> > 1.4 to see if it was working and I found that the 2 mechanisms live >> > together... >> > >> >> yes, i using it a lot. >> because often i'm not using the image with all tools loaded. and this >> simple completion is quite helpful >> >> > Guille >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Jan. 13, 2012

[Pharo-project] Styling in Inspector

by Guillermo Polito

I added the following method to inspector and styling turned on: shoutAboutToStyle: aPluggableShoutMorphOrView ^ true Should we add it? Also, I've tryed to remove the styling from the PreDebugger window on warning messages by setting it a NullTextStyler and it doesn't work :). I'll continue hacking.

Jan. 13, 2012

Re: [Pharo-project] Cmd-q autocompletion?

by Guillermo Polito

How about (maybe for 1.5) think in making it pluggable? :P On Fri, Jan 13, 2012 at 11:14 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 13 January 2012 14:59, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > I've just realized that we have an autocompletion mechanism that is not > > OCompletion in the image, typing cmd-q. And also, it is just querying > the > > Symbol table: > > > > selectorsFromPrefix: aPrefix > > "returns the value of labels from a selector prefix" > > | key applicants | > > aPrefix isEmptyOrNil ifTrue: [^ #()]. > > applicants := aPrefix first canBeGlobalVarInitial > > ifTrue: [Array streamContents: [:strm | > > Symbol allSymbolTablesDo: [:each | > > (each notEmpty and: [each first canBeGlobalVarInitial]) > > ifTrue: [strm nextPut: each]]]] > > ifFalse: [Array streamContents: [:strm | > > Symbol allSymbolTablesDo: [:each | > > (each notEmpty and: [each first canBeGlobalVarInitial > not]) > > ifTrue: [strm nextPut: each]]]]. > > key := aPrefix asLowercase. > > ^ (applicants select: [:each | (each asLowercase beginsWith: key) > and: > > [each noneSatisfy: [:c | c tokenish not]]]) sort > > > > > > Does anybody use it? Is it useful? Because I was loading OCompletion > into > > 1.4 to see if it was working and I found that the 2 mechanisms live > > together... > > > > yes, i using it a lot. > because often i'm not using the image with all tools loaded. and this > simple completion is quite helpful > > > Guille > > > > -- > Best regards, > Igor Stasenko. > >

Jan. 13, 2012

Re: [Pharo-project] Cmd-q autocompletion?

by Igor Stasenko

On 13 January 2012 14:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I've just realized that we have an autocompletion mechanism that is not > OCompletion in the image, typing cmd-q.Â And also, it is just querying the > Symbol table: > > selectorsFromPrefix: aPrefix > Â Â Â "returns the value of labels from a selector prefix" > Â Â Â | key applicants | > Â Â Â aPrefix isEmptyOrNilÂ ifTrue: [^ #()]. > Â Â Â applicants := aPrefix first canBeGlobalVarInitial > Â Â Â Â Â Â ifTrue: [Array streamContents: [:strm | > Â Â Â Â Â Â Â Â Â Symbol allSymbolTablesDo: [:each | > Â Â Â Â Â Â Â Â Â Â Â Â (each notEmpty and: [each first canBeGlobalVarInitial]) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [strm nextPut: each]]]] > Â Â Â Â Â Â ifFalse: [Array streamContents: [:strm | > Â Â Â Â Â Â Â Â Â Symbol allSymbolTablesDo: [:each | > Â Â Â Â Â Â Â Â Â Â Â Â (each notEmpty and: [each first canBeGlobalVarInitial not]) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [strm nextPut: each]]]]. > Â Â Â key := aPrefix asLowercase. > Â Â Â ^ (applicants select: [:each | (each asLowercase beginsWith: key) and: > [each noneSatisfy: [:c | c tokenish not]]]) sort > > > Does anybody use it?Â Is it useful?Â Because I was loading OCompletion into > 1.4 to see if it was working and I found that the 2 mechanisms live > together... > yes, i using it a lot. because often i'm not using the image with all tools loaded. and this simple completion is quite helpful > Guille -- Best regards, Igor Stasenko.

Jan. 13, 2012

[Pharo-project] Cmd-q autocompletion?

by Guillermo Polito

I've just realized that we have an autocompletion mechanism that is not OCompletion in the image, typing cmd-q. And also, it is just querying the Symbol table: selectorsFromPrefix: aPrefix "returns the value of labels from a selector prefix" | key applicants | aPrefix isEmptyOrNil ifTrue: [^ #()]. applicants := aPrefix first canBeGlobalVarInitial ifTrue: [Array streamContents: [:strm | Symbol allSymbolTablesDo: [:each | (each notEmpty and: [each first canBeGlobalVarInitial]) ifTrue: [strm nextPut: each]]]] ifFalse: [Array streamContents: [:strm | Symbol allSymbolTablesDo: [:each | (each notEmpty and: [each first canBeGlobalVarInitial not]) ifTrue: [strm nextPut: each]]]]. key := aPrefix asLowercase. ^ (applicants select: [:each | (each asLowercase beginsWith: key) and: [each noneSatisfy: [:c | c tokenish not]]]) sort Does anybody use it? Is it useful? Because I was loading OCompletion into 1.4 to see if it was working and I found that the 2 mechanisms live together... Guille

Jan. 13, 2012

Re: [Pharo-project] Preparing 1.4 beta

by Luc Fabresse

2012/1/13 Norbert Hartl <norbert(a)hartl.name> > Very good idea to release what we have and continue with open stuff in > 1.5. Feels just right! > yes! Luc > > Norbert > > > > Am 12.01.2012 um 21:54 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > >: > > > Hi > > > > since we will not have OPAL as preview in 1.4 and we do not need to > change the refactoring engine > > code, we will unload AST and RBEngine package from the system and start > to pass in 1.4 beta probably at the end of the month. One idea was that we > could have decent tools to work on the core but this is not the case. > > > > We will encourage people to try their packages to 1.4 beta and rc so > that we can produce 1.4. > > > > Stef > > > > > > > > > >

Jan. 13, 2012

Re: [Pharo-project] Preparing 1.4 beta

by StÃ©phane Ducasse

thanks. May be I will add SystemAnnouncement and RPackage since this is stable. We will check if we can push or not in 1.4 the clean of the eventBuff. Stef > Very good idea to release what we have and continue with open stuff in 1.5. Feels just right! > > Norbert > > > > Am 12.01.2012 um 21:54 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Hi >> >> since we will not have OPAL as preview in 1.4 and we do not need to change the refactoring engine >> code, we will unload AST and RBEngine package from the system and start to pass in 1.4 beta probably at the end of the month. One idea was that we could have decent tools to work on the core but this is not the case. >> >> We will encourage people to try their packages to 1.4 beta and rc so that we can produce 1.4. >> >> Stef >> >> >> >> >

Jan. 13, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by GastÃ³n Dall' Oglio

Hello. Let me say first that several year ago I understand that any ambient of Smalltalk is more powerfull that any IDE Delphi for work with object, but this depend of your skills in one enviroment obviously. For that, I'm a more powerful programer in Delphi that in Smalltalk, for misfortune for me. Second, let me say something about Delphi, just for information, anyway, correct me if I'm wrong: 2012/1/13 blake <dsblakewatson(a)gmail.com> > > On Thu, Jan 12, 2012 at 3:07 AM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> On Thu, Jan 12, 2012 at 11:07 AM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: >> >>> 2012/1/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> >>>> >>>> but UI building is just one part of the story. If after you just get a >>>> long initialize methods then nothing gets really reused. >>>> >>>> >>> Yes, >>> It is reason why I hate VisualStudio and Delphi approaches. It is >>> imposible to create reusable components of user interface applications. >>> >> >> ??? Haven't use Delphi for +4 years but from Delphi 3 -> 7 it was not >> really hard to create reusable components, extend them and the IDE >> itself...... >> >> Laurent >> > > Perhaps I can interject usefully here. > > It isn't =hard= to create reusable components in Delphi. What it is is > =different=. Delphi adopted Visual Basic's "two classes of developers" > approach through delegation that hides all the actual object-oriented > programming from those who aren't comfortable with it. When you create an > event routine for a component on a form, the method is part of the form > class. > This method is for manage the event, not for do something that is really part of the model. A Form, no is part of the model. This is similar in VW: you coded your event handler method in the AplicationModel, that is like a Form in Delphi. > Rather horrifyingly, Delphi auto-creates forms by default and assigns them > to global variables, thus encouraging the practice of referencing a > =specific instance= of the class. Re-usable? It sets novices up to create > interfaces that don't even work properly with multiple instances of the > =same= form. > > No. The IDE automaticaly define a global variable and create code for create and assign a instance, but if you want more instances of same Form you can easy declare local variables and create new instance (on initialize of other instance or on the fly in accesor methods) and asign to. Same in Smalltalk.... And you can delete this automaticaly created code. Now, creating a component requires creating an actual object, then > compiling and installing it into the environment. It's not hard, but it's > easy to screw up, and fixing it requires going back into this other mode. > (It's not quite frozen once installed but it's not completely flexible, > either.) > I agree. I spend very much dead time in code-compile-debug cycle, but this is not mainly for use component, is for lack of a truth ambient of programing with object, Delphi is just an IDE. I screw up very often in Smalltalk, but I fix this directly in the debugger and go on :) > Components are supposed to be contract-less, meaning user type #1 can't > break them (at least from inside the object inspector). > > The upshot is that, yes, it is actually more difficult to create a > reusable UI. The delegation model encourages the mashing of the V and C > into the M, as it were. > mmm no. Again, a Form is not part of model, idealy this is for write event methods handlers. > You can easily make all the buttons on a form call the same code, but > buttons on a different form? Well, now you're looking at that compiled > component model. > In the Buttons you can use Actions for delegate the handler method of the click event. In general, you can assign method of a Form to events of controls in another Form, but I do not do often that becouse I only write a small code in the event handler in the Form for delegate to some model the work (DataModules). > > JBuilder (the Java equivalent of Delphi) sub-classed everything, which > seemed less than ideal, too. > > A Smalltalk-style equivalent could out-do this easily, since component > design wouldn't be any different from any other sort of programming. You > could use delegates OR subclass, and any subclass could instantly appear as > a component. > > I started using Smalltalk with VisualAge. While there were a lot of > limitations with the connector approach, I always thought it was kind of > cool: Being able to visually connect two objects so that a message from one > was matched up to a method the other was superior than "Intellisense" in a > lot of ways. > Finally, I like work with component in Delphi when I begin a proyect, but I guess that when I comming to make something more complex the IDE no aid much, you have to go at code editor and sometimes the utilization of components even hinder... In Smalltalk (Pharo) I have the problem at begining becouse I have to write all code by hand, but at end all work (coded, debug) is very simple all the time. GastÃ³n

Jan. 13, 2012