Smalltalk - [VAS ] VA Smalltalk Survey Results

Author

[VAS ] VA Smalltalk Survey Results

solveig.instantiations@gmail.com

2006-07-27, 7:01 pm

Last month Instantiations sent out a survey to find out what is
important to you. Nearly 150 of you responded with praise and request.
We thank you for both.

1. We found out that most of you develop on a version of Windows.
About 60% intend to deploy on Vista; 80% are interested in automatic
themes and manifests available for Windows XP.

2. We asked about SUSE but got no responses to our questions about
the GUI standards or our level of support. We hope you have not given
up on us, but specific requests would help.

3. Most of you are interested in 64-bit support. Among those who
gave concrete numbers, one year was the most frequent response.

4. You found it equally important to maintain backward compatibility
and to keep abreast of new features.

5. Many of you are writing applications which rely on Smalltalk for
less than half the functionality. For about 1/3 of you Java is part of
the picture, though not necessarily Java RMI. Others rely on web
services. Users with 1-25 licenses mentioned .NET more frequently than
did users with more licenses. Users with more licenses mentioned the
importance of being able to run on the most current platform versions
and interoperate with the most current versions of middleware.

6. Customers mentioned a variety of databases with DB2, Oracle and
Gemstone the most frequent sources of data. Non-Gemstone users asked
for a persistence framework to make the database feature easier to use
and increase productivity.

7. Many of you are using web services. Many want to use Seaside on
VA Smalltalk. When asked how to make Web Services easier, you mentioned
automation of the process and the ability to translate between XML/WSDL
artifacts and Smalltalk objects.

8. When considering how to improve productivity, the most frequent
request was for integration of the refactoring browser, followed by
automatic code generation of some flavor. A few users wanted unit
testing well-integrated into the development environment.

9. When thinking in terms of debugging, users were generally pleased
with the ease of use of the debugger but wanted more control of the
debugger, more information from the debugger, more functions available
in other browsers to also be available in the debugger, more
full-featured remote debugging, and better access to and presentation
of error information from external interfaces.

10. One third of users with a 1-10 licenses and one half of users
with 11-100 licenses expressed garbage collection performance worries.
These prompted requests for improved memory profiling and leak
detection tools.

11. Respondents with 1-10 licenses expressed a desire for more
examples, tutorials and cookbooks in our documentation. Those with
50-100 were particularly interested in full web services documentation
and more information of memory management and garbage collection.

12. Respondents found the Goodies to be useful or vary useful. Small
shops were more likely to actually use Goodies. ENVY/QA, Eman, Mouse
Scroll Wheel, and Object Extender were the favorites.

Reinout Heeck

2006-07-28, 8:02 am

solveig.instantiations@gmail.com wrote:
> 8. When considering how to improve productivity, the most frequent
> request was for integration of the refactoring browser, followed by
> automatic code generation of some flavor. A few users wanted unit
> testing well-integrated into the development environment.
>

The refactoring browser is a great productivity tool but I want to warn
for the quality of the implementation.

VisualWorks switched to using the RB as the default browser and since we
have found that it is hard to extend the RB with our own customizations
without rewriting existing RB code. In VisualWorks the packaging system
allows for altering an existing definition living in another package
('package overrides') but on Envy based systems this will likely lead to
extra management overhead for the end users if they want to use
enhancements to the RB.

The RB also suffers from its cross-platform compatibility. This
expresses itself mostly as having 'unnatural' ways to extend the
available menus and that some of the helpful system facilities are
masked (e.g. accepting a class with a misspelled superclass name no
longer brings up the 'correct it' dialog that VW would show pre-RB).

The code is rife with case statements making extending it a pain, trying
to open a view in a way that is not the way the original authors
intended (like showing a package list alongside an 'implementers' view)
is hard to accomplish. For good measure the implementers threw their
hands in the air at one point and even implemented a #doesNotUnderstand:
handler to navigate the RB's data model...

I don't want to do without the RB, it *is* a great productivity tool but
be aware that a reimplementation might be more advantageous than
adopting it wholesale...

Reinout Heeck
-------------

John Brant

2006-07-29, 7:00 pm

Reinout Heeck wrote:

> The RB also suffers from its cross-platform compatibility. This
> expresses itself mostly as having 'unnatural' ways to extend the
> available menus

I'm not sure what you mean here. It has VW pramga menu support, and it
also has support to add and also remove menu items to the menu
prototypes. The menu prototypes allow users to remove items from the
standard menus or even rearrange items on the menu -- something not
possible with VW pragmas.

> and that some of the helpful system facilities are
> masked (e.g. accepting a class with a misspelled superclass name no
> longer brings up the 'correct it' dialog that VW would show pre-RB).

Your example doesn't work in 5i either. The compiler does not warn when
#{} expressions are misspelled since the #{} expressions allow for
unloaded code. If they would have used the superclass name directly in
the class definition instead of using #{}, then the correct it feature
would have worked.

As for misspelled selectors in class definitions, there are two problems
here. When you accept a definition, the RB parses the code to try to
figure out what you are doing. It needs to know so that it can undo the
operation. If it can't figure out what the code does, then it just
evaluates the code and you can't undo it.

The first problem is that if the code can't figure out what you are
doing, then it doesn't pass the controller along so the VW compiler
can't make any correction suggestions. This can be fixed by modifying
the ExecuteCodeChange class>>definition:for: method. At the end, it
defaults to "self new" -- this needs to be changed to pass the controller.

The second problem is that in the process of parsing the original code,
the RB creates selectors for the messages in the code. The correct it
suggestions work by looking at the symbol table and not by looking to
see what selectors are actually implemented. Since the symbol hasn't
been garbaged collected yet, the VW compiler thinks it is implemented.
To me, this is a bug in the correct it feature and not the RB.

> The code is rife with case statements making extending it a pain,

I assume you are talking about ifTrue:/ifFalse: and their variants since
there is no case statement in Smalltalk. I just ran a script that looks
at the density of ifTrue:/ifFalse: messages to the total number of parse
nodes:
'Tools-Refactoring Browser'->0.0220276
'Tools-Debugger'->0.0207559
'Base VisualWorks'->0.0231909
'StoreBase'->0.0222244
It appears that slightly over 2% of the nodes in the parse trees are
ifTrue:/ifFalse: messages. I don't see much difference between the RB
and any other packages. In fact, both Base VisualWorks and StoreBase
have a higher density of these messages. I'm not saying that you can't
find some stupid code in there, but I doubt that its density is that
much greater than most other code.

> trying
> to open a view in a way that is not the way the original authors
> intended (like showing a package list alongside an 'implementers' view)
> is hard to accomplish.

It took about 15 minutes for me to add a package list besides the method
list.

First, define the interface:
!Refactory.Browser.BrowserNavigator class methodsFor: 'interface specs'!

packageMethodWindowSpec
"Tools.UIPainter new openOnClass: self andSelector:
#packageMethodWindowSpec"

<resource: #canvas>
^#(#{UI.FullSpec}
#window:
#(#{UI.WindowSpec}
#label: 'Unlabeled Canvas'
#bounds: #(#{Graphics.Rectangle} 560 765 1241 1095 ) )
#component:
#(#{UI.SpecCollection}
#collection: #(
#(#{UI.SubCanvasSpec}
#layout: #(#{Graphics.LayoutFrame} 0 0 0 0 0 0.333333 0 1 )
#name: #packageList
#flags: 0
#majorKey: #{Refactory.Browser.HierarchyPundleNavigatorPart}
#minorKey: #windowSpec
#clientKey: #packageList )
#(#{UI.SubCanvasSpec}
#layout: #(#{Graphics.LayoutFrame} 0 0.333333 0 0 0 1 0 1 )
#name: #methodList
#flags: 0
#majorKey: #{Refactory.Browser.MethodNavigatorPart}
#minorKey: #windowSpec
#clientKey: #methodList ) ) ) )! !

Write a few methods for the new UI:
!Refactory.Browser.BrowserNavigator methodsFor: 'accessing'!

packageList
^partsDictionary at: #PackageNavigatorPart!

methodList
^partsDictionary at: #MethodNavigatorPart! !

!Refactory.Browser.BrowserNavigator methodsFor: 'initialize-release'!

initializePackageMethodBrowser
| methodNavigatorPart packageNavigatorPart |
packageNavigatorPart := HierarchyPundleNavigatorPart onNavigator: self.
partsDictionary at: #PackageNavigatorPart put: packageNavigatorPart.
parts add: packageNavigatorPart.
methodNavigatorPart := MethodNavigatorPart onNavigator: self.
partsDictionary at: #MethodNavigatorPart put: methodNavigatorPart.
parts add: methodNavigatorPart.
methodNavigatorPart listSelector: #listForPackages:! !

!Refactory.Browser.MethodNavigatorPart methodsFor: 'private'!

listForPackages: aNavigatorState
| selectedPackages |
selectedPackages := aNavigatorState packages.
selectedPackages isEmpty ifTrue: [^self fillInListFor: aNavigatorState].
^navigator environment methodDefinitions select:
[:each |
| selectorPackages |
selectorPackages := self storeRegistry
allContainingPackagesForSelector: each selector
class: each implementingClass.
selectorPackages anySatisfy: [:package | selectedPackages includes:
package]]! !

The last method adds behavior to the method list to filter the methods
by the package selected.

Now, we're ready to hookup the new view:

BrowserNavigator navigatorSpecBlocks addFirst:
[:navigator |
navigator environment isSelector
ifTrue:
[navigator initializePackageMethodBrowser.
#packageMethodWindowSpec]]!

When you open the senders you should see a package view besides the
methods. However, the current package view lists all packages for all
classes in the methods list instead of just the packages for the methods
listed. To fix this, we need to create a new class and change the
reference to HierarchyPundleNavigatorPart in
BrowserNavigator>>initializePackageMethodBrowser that we created above:

Refactory.Browser defineClass: #PackageListForMethodsNavigatorPart
superclass: #{Refactory.Browser.HierarchyPundleNavigatorPart}
indexedType: #none
private: false
instanceVariableNames: ''
classInstanceVariableNames: ''
imports: ''
category: 'Browser-Navigator Parts'!

!Refactory.Browser.PackageListForMethodsNavigatorPart methodsFor: 'private'!

fillInListFor: aNavigatorState needsRefresh: aBoolean
| packages |
packages := Set new.
navigator environment methodDefinitions do:
[:each |
packages
addAll: (self storeRegistry allContainingPackagesForSelector: each
selector
class: each implementingClass)].
self updateListWith: packages! !

!Refactory.Browser.BrowserNavigator methodsFor: 'initialize-release'!

initializePackageMethodBrowser
| methodNavigatorPart packageNavigatorPart |
packageNavigatorPart := PackageListForMethodsNavigatorPart onNavigator:
self.
partsDictionary at: #PackageNavigatorPart put: packageNavigatorPart.
parts add: packageNavigatorPart.
methodNavigatorPart := MethodNavigatorPart onNavigator: self.
partsDictionary at: #MethodNavigatorPart put: methodNavigatorPart.
parts add: methodNavigatorPart.
methodNavigatorPart listSelector: #listForPackages:! !

Given your limited description, this should be a close to what you want.
However, it doesn't work for everything. There is a bug when the senders
list includes an initializer -- the packages calculations in the
#fillInListFor:needsRefresh: and listForPackages: methods don't work for
initializers. I suggest moving the calculation to the MethodDefinition
and writing one for the InitializerDefinition class.

Anyway, I wrote all of this in about 15 minutes, and I didn't use any
overrides. The fileout is less than 4KB.

> For good measure the implementers threw their
> hands in the air at one point and even implemented a #doesNotUnderstand:
> handler to navigate the RB's data model...

This fixes some problems we had with menu dispatching. We asked Sames
about it, and we got the standard response that we've all heard for the
past several years. We might have been able to come up with another
solution, but since the previous browsers had several DNU handlers and
it was relatively easy to fix the problem with a single DNU handler,
that's what we did.

John Brant

Niall Ross

2006-08-17, 7:02 pm

Dear Solveig, Reinout, John et al,
I dissent, but cautiously, with Reinout and agree, again cautiously,
with John, re the RB discussion in this thread.

I assume Reinout is talking solely about the UI part; obviously you should
reuse the model layer, extending and improving it by all means but not
reimplementing, as is done in the current Envy-browser integration. So the
issue is reimplementing the RB UI layer for VASmalltalk and/or using
menupick integration of RB features into the existing browsers as at present
with the RB UI as an extra for use by who wants it, rather than making it
the RB the UI of choice as was done in VW7.

After, I concede, quite some effort to get my head round how the framework
wanted to work, I have found it possible to extend the RB with fairly
minimal code for what I have wanted to do, both in the VW7 version and in
the cross-platform Envy version. I think the UI layer basic structure of
navigators, code models / tools, states, etc., which is common to both
versions, works fairly well. The VW7 version has some refactoring of
responsibilities between e.g. states and navigators, that would emerge
naturally in any reimplementation of the older Envy version. (I've
backported some as part of enhancing the non-VW7 StoreGlorp RB browser.)

VW7 also has some new ideas, e.g. the RBCommand system. After reading
Reinout's email, before reading John's, I found myuself thinking that John
and Don would defend the DNUs in the VW7 version RBCommand dispatch system
(if Reinout and I are thinking of the same method - I suspect we are :-)) as
not 'throwing their hands in the air' but a design decision for maximum
flexibility. (As my long comment in the one-line BrowserCodeTool>>action:
method in the custom refactoring project's download suggests, I did not
grasp how to customise this system in an instant. :-) However these new
ideas are VW7-specific. They will not appear in VA unless someone sees
value in backporting them to the Envy version.

These new ideas replace code, e.g. MenuHolders, that provided a common
VW3/Envy-VA facade to version-specific functions, so VA integration of the
RB UI can dump them too for no loss. (That said, the MenuHolder protocol
had its advantages, though also its di

vantages, as fanatical XPers found
when they tried to drive coding from menu items and instead of giving them a
DNU to code in the debugger, the MenuHolder removed their
not-yet-implemented menu item during its 'intelligent' self-configuration.
:-)

That said, it is tricky to keep enhancements from having _no_ impact on the
using framework. In Envy this means custom configuration maps and apps
instead of the base RB ones, which cause us few problems today because the
base Envy code does not change. In VW7, each release needs a compare of the
custom refactoring RB to the new base and there is usually something to
merge (trying to add UI customisations in ways that minimise this has
broadened my understanding of the framework). Making the RB UI the default
in VASmalltalk would create this situation there too.

In VW, the old coding UI had been ignored for years and was tired; I saw
the decision to make the RB the default as clear overall gain. The VA
browsers did more and the Envy RB UI, ported from VW, did not duplicate them
in all their functions. It might be worth asking users what kind of RB UI
integration they want beyond the menupick integration that Joseph Pelrine et
al originally supported. Is it pluggable code tools they want, for example?

Yours faithfully
Niall Ross

Sponsored Links