[vwnc] RBrowserHistory and RBTabbedToolsets

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Jul 18, 2008, at 9:13 PM, Randy Coulman wrote:

You don't HAVE to declare them. They're just warnings. The value  
derived from "informing" you that there is not a registered tag, is  
about the same as informing you that initalize is not an understood  
selector (look closely at the spelling).

If they *were* required up front, parcel/store loading would have to  
be more intelligent about how it loads stuff. You can tag your methods  
to your hearts content with non registered tags. You just got annoying  
warnings when you do it interactively. Perhaps we should tweak it so  
that it behaves similarily to how the unimplemented selector performs  
(i.e. once you've told it you know, it doesn't pester you any more).

You can see the side effects of this actually when you load something  
like Cairo. It uses an <original: > tag to track the orginal C  
definition, so that I can back link the names when/if necessary. When  
it's loading, you'll see a bunch of warnings go by in the transcript  
as these methods come in before the class side <pragmas: class> happens.

There, hopefully I've put enough sweet manure all over the subject to  
douse any afeared flames.

--
Travis Griggs
Objologist
My Other Machine runs OSX. But then... so does this one.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 19/07/2008, at 1:48 PM, Eliot Miranda wrote:

> ?? You just look for senders of pragmas: and you find all the  
> methods containing a pragmas: pragma.  The method can be called  
> whatever you like (which is the point).  It just has to live on the  
> class side.  The argument to pragmas: tells you which side the  
> pragma applies to, #instance or #class.  Go on, go to the Launcher's  
> Senders and type in pragmas:.  You find them all immediately.

OK, I don't know what I was doing that stopped that working :(

> Can you explain this?  There is no reason pragmas can;t be  
> refactored.  They're all there. But John Brant (defensibly) took the  
> position that the RB's refectoring facilities were going to ignore  
> pragmas because they were VisualWorks only.  ut since they're only  
> message sends they're easy to refactor.  But I think I'm missing  
> your point.


If I want to rename a pragma, code that enumerates pragmas won't be  
updated. They aren't accessed from the 'sender' side using message  
sends e.g. Pragma class>>allNamed: aSymbol from: subClass to:  
superClass is one way to enumerate them, but my code
won't be updated during refactoring. This is the same problem as using  
#perform: in the face of refactoring.

> Since you're so fired up, why not have a go at defining some tools?

Because I'm a paying customer, and I hope that Cincom won't ignore  
*everything* I say :) I fix a lot of stuff off my own bat - see e.g.  
ASBAqua, ASBLook, ASBRB. Is that going to be the response to every  
complaint/criticism? Do it you effing self?

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Lack of will power has caused more failure than lack of intelligence  
or ability.
  -- Flower A. Newhouse

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 19/07/2008, at 2:20 PM, Eliot Miranda wrote:

> This is a limitation of the RB's refactoring engine's implementation  
> which comes from a (defensible) desire not to support a non-standard  
> facility.  If the VW engineering team had the resource I'm surer  
> they'd fix this.  It is not a fundamental limitation.  I think I;ve  
> explained tat pragmas are conceptually easy to refactor because  
> they're messages.

Surely that's the halting problem? How would the system rename all  
uses of 'myPragma:' given this:

   p := OrderedCollection new.
   self computePragmas do: [ :x | p addAll: (Pragma allNamed: x from:  
MyClass to Object) ].

IMO a refactoring engine that works only on narrowly defined code  
templates isn't really reliable enough. Because pragmas MUST be  
accessed in my code using reflection, the refactoring engine is SOL.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

A reasonable man adapts himself to suit his environment. An  
unreasonable man persists in attempting to adapt his environment to  
suit himself. Therefore, all progress depends on the unreasonable man.
   -- George Bernard Shaw


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Jul 18, 2008, at 8:56 PM, Eliot Miranda wrote:

> and Steve Dahl and Vassili Bykov deserve a lot of the credit.  Steve  
> cleaned up my initial implementation, did the menu builder and  
> invented class-side pragmas declaring which pragmas were legal (and  
> I think checking for legal pragmas in the first place).  Vassili did  
> all the pragma enumeration facilities.

I'd like to state my gratitude to you and Steve and Vassili for indeed  
doing such a nice job. I'm a big fan of these things. They make  
writing pluggable interfaces much easier. We use them in the browser.  
In the inspector now. The guys at Key use them to make APIs that can  
be plugged in. I've used them in SUnitToo(ls) to allow different rules  
for associating test code with it's "unit" to be more pluggable. I  
used them in SUnitToo as a way to tag test methods (rather than having  
to use testBlah, as an aside, this seemed corny at first, and I've  
come 180 on it, because I find a can write a selector that is more  
descriptive of the test, not being influenced by preambling it with  
the 'test' verb). They've been used to make UI composition more  
pluggable. 7.6 integrated the External-Interface-Pragmas add on, which  
uses them to make which libraries an ExternalInterface uses pluggable.  
I laugh at myself, because I frowned out these once upon a time, and  
was a while coming 'round to liking them. See, even an opinionated  
windbag has some hope of getting a clue.

Couple random thoughts in response to the thread, intermingled with  
some random trivia:

1) I like the minimalism involved in using an already established  
pattern. It allows a poor mans version of tools support to exist right  
out of the bag. It makes writing parsers nice, because you can reuse  
code. It looks similar to the other keyword patterns, so as a human  
reader of code, there's less patterns to interpret. It resonates with  
my "Less is More" passion.

2) The RBParser got proper <method tag> parsing abilities in 7.6 Which  
means that they're modeled as part of the RBParseNode tree. Which  
means they can be formatted properly, and are included in rewrite  
rules as well. And searching, etc. I think I saw hints that some of  
the posters wer under the misconception that this was not so.  
Inspection of the Release Notes and/or some simple tests could have  
revealed this to the misinformed. :)

3) Some know... I don't like the name Pragmas. Partly because of an  
odd irony with them. Pragma's traditional, and very computer-geek-
esque, interpretation is as compiler directives (see the wikipedia  
disambiguation page). The original method pragmas were indeed pragmas.  
Things like <unwind> and <primitive: 395>. Special bytecodes and  
method types were generated by the compiler as a result of these  
directives. But the wonderful generalization that was done, was done  
so that they could be used to express simple method annotations, which  
could be used by services other than the compiler. At this point, they  
just become method annotations, a way of "tagging" information on to  
methods, the same way you might hang tags on real world objects to  
help categorize them and attach simple information to them. So just  
about any of the new uses of them, are not as pragmas (compiler  
directives).  Because all o the uses I mentioned above, are not  
"pragmas". They're about tagging methods. So I usually use the term  
"method tags". I don't expect/need others to do the same.

4) One of the unfortunate ironies about the use of the <keyword:  
something> pattern, is that the all-to-common DLLCC method uses  
something that at first blush look like that to the parser, but indeed  
is not. So this has to be special cased. Oh well. (e.g. <C: > is NOT a  
method tag).

5) While I think you get a lot of mileage out of the "poor mans tools"  
that is there, I really would like to do something more.  It involves  
something inspired along the lines of Damien Cassou's  
RBDynamicProtocols (see previous posts about wishing I had time to  
work on the top half of the browser). Such work is a desire to  
generalize the way we categorize/search methods on a variety of  
attributes, amongst them, tags. I do not want to add yet another batch  
of menu options.

6) The one area that I think our current implementation is still a  
little weak, is the extensibility of what the defining class does as  
these methods come and go. Currently you can use a <pragmas: > tag to  
indicate what other tags you'll be adding to either the instance or  
class behavior. But to respond to the changes, you implement an  
instanceMethodsChanged/classMethodsChanged which gets sent any time  
they're changed. You don't know whether you've got additions, or  
removals. Even more problematic, is that we've lost the "conflict free  
extensibility" (great phrase Eliot) of what to do in response. For  
example, many ApplicationModel subclasses implement the  
instanceMethodsChanged in such a way that they flush any menus and  
rebuild them, anticipating that I've added or removed methods with  
<menu:...> annotations. But what if I want to extend an existing app  
with a new type of service? What if, for example, I want to extend the  
FileBrowser so it can register new file type tools, based on file  
kind. I've got to override that instanceMethodsChanged method. And if  
someone wants to add their own services, we'll have override conflicts.

I don't know to what extent it should be made more pluggable. It might  
be enough to simply use a unary tag to tag methods that should fire  
when the annotated methods have changed:

myResponseToChanges
        <taggedMethodsChanged>
        ^so doMyThang

One could go farther and parameterize that with the tags it's  
interested in responding to:

updateTestCaches
        <taggedMethodsChanged: #(#test)>
        self flushTestResults

One could make it really rich, differentiating between add and remove.  
Or really go nuts and add points for aboutToRemove/removed/aboutToAdd/
added. One could pass the methods added/removed. I've not personally  
thought it all out enough to have strong opinions on how much to  
provide, I do find the Behavior>>instanceMethodsChanged method comment  
good advice on the subject.

7) If you want to hurt your brain, figure out where you put the  
<pragmas: > on ClassDescription (class or instance? and there, or in a  
Class or Metaclass) and where you put the instanceMethodsChange/
classMethodsChanged so that you can use method tags to add/remove  
instance variables as described here (http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Managing_Instance_Variables_Methodically&entry=3376826809 
). No, I'm not bragging that I did. I just threw darts until it worked.

8) My experience has led me to not go too nuts with these. Though I've  
employed them lots. Don't try to put too much info in the method tags  
themselves. You're not inventing a DSL inside the tags. You've still  
got your method to do the real work. (http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944 
) was such an experience, for me.

--
Travis Griggs
Objologist
"Every institution finally perishes by an excess of its own first  
principle." - Lord Acton



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 19/07/2008, at 1:48 PM, Eliot Miranda wrote:

> Can you explain this?  There is no reason pragmas can;t be  
> refactored.  They're all there. But John Brant (defensibly) took the  
> position that the RB's refectoring facilities were going to ignore  
> pragmas because they were VisualWorks only.  ut since they're only  
> message sends they're easy to refactor.  But I think I'm missing  
> your point.

I might be out to lunch on this.

I must admit that I didn't realize that literals would be renamed  
(doh!), although the testing that demonstrated this has uncovered a  
problem. Sorry for my time-wasting discussion on this point  :(

Regardless, I think it's important that pragmas are renamed by the RB.  
Consider this method that encapsulates both the 'sender' and  
'implementor' ends of a pragma, plus the possibility that a pragma  
matches an existing selector.

   somePragma: anArg
     <somePragma: #aaa>
     ^Pragma allNamed: #somePragma: in: self class

If you do a rename refactoring, you get this:

   someRenamedPragma: anArg
     <somePragma: #aaa>
     ^Pragma allNamed: #someRenamedPragma: in: self class

which is obviously broken. More use of pragmas, hence more chance of  
collision with 'real' method selectors, means this should be fixed for  
any refactoring that modifies any symbol literal. If the pragma was  
renamed, then my concerns about refactoring are largely moot. There is  
still an issue that a facility accessed purely through reflection is  
more likely to result in constructed symbols e.g.

   pragmaName := 'somePragma:'. "Imagine some reason for starting with  
a string".
   Pragma allNamed: pragmaName asSymbol in: self class

which isn't refactorable in the general case. Of course, this is a  
problem with refactoring with many reflective scenarios. One  
contribution to easing this could be

   String>>asPragmaSelector
     ^self asSymbol

resulting in

   sel := 'somePragma:' asPragmaSelector.

which at least is a way of revealing intention which could be  
leveraged by tools to find places that pragma selectors are  
constructed as opposed to being a literal. Somewhat more specific than  
#asSymbol. Maybe an #asSelector parallel would be useful in the same  
manner.

I still think better tools are needed - specifically, browser  
facilities that are designed for pragma use-cases. Sure, you can work  
it out using existing tools, but it's not obvious to a non-expert  
user, which I must admit automatically counts as 'failure' in my mind.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The truth does not change according to our ability to stomach it.
   -- Flannery O'Connor


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 19.07.2008 um 05:49 schrieb Eliot Miranda:

> This conflict-free extensibility is what I invented pragmas for.

I don't mean to be offensive and still think they're quite  
interesting, but I wish they weren't there. IMO pragmas are a step  
towards making Smalltalk more complicated.

Conflict-free extensibility should be the responsibilty of some higher-
level tool framework rather than a matter of language extensions. A  
package could contact the responsible instance at post-load time and  
have it add the menus and items where it deems appropriate. Something  
like

        ToolsManager augmentInterfaceFor: self interfaceExtensions

The manager could even decide to move all or some of the extensions  
elsewhere, if that is more appropriate in certain situations (e.g. for  
an updated version).

Just recently I needed to do an overhaul of a large application where  
a dozen or so tools needed to "add themselves" to a unified global  
menu structure (as required for the Mac menubar) in order to avoid a  
situation where one would need to maintain those "superset menus"  
manually. The only solution that seemed working to me was to have a  
global instance collect the desired items from all of the tools and  
assemble them in a controlled and well-informed fashion.

Just my 2 ct

Andre


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Andre Schnoor wrote:
I'd like to second this (except for the pragmas being interesting and
the not wanting to be offensive parts :)). Why is it that many
Smalltalkers like to make fun of languages like C# that add new features
by adding new syntax; however, when Smalltalk adds syntax (pragmas),
they think it is great?

If we needed to extend the browser's menus (circa 1995), we could have
directly modified the menus that were stored in the class variables of
the browsers. When a package was loaded or unloaded, we could have added
or removed our menu items directly from the cached menus.

Alternatively, if we wanted something like pragmas, but without new
syntax, we could have extended the browsers to add annotation objects to
methods. The ANSI standard defines that we can add annotations to
methods, but they are external to the method's source. The browser
already supports one such annotation (the method's category). Why
couldn't other annotations be added?

Hey Travis: you need to stop drinking the Kool-Aid, and Eliot: I still
can't add an imaginary number menu item :)...


John Brant
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Jul 19, 2008, at 8:31 AM, John Brant wrote:

I think that's not entirely fair. Because no new syntax was added.  
Rather, a special case syntax, that had been around for a long time,  
was generalized. Reduction to a more general form is IMO a good thing.

As for the "high level tool", I've seen it done that way. I don't want  
to go back there. When I switched over the RB's management of toolsets  
in the bottom half, life just got easier. It was all to easy to screw  
up the collection before hand. And it took more code. Same thing with  
the ExternalInterface stuff. I guess, I've tasted the water with and  
without the koolaid, and the water without it doesn't taste good. :)

> If we needed to extend the browser's menus (circa 1995), we could have
> directly modified the menus that were stored in the class variables of
> the browsers. When a package was loaded or unloaded, we could have  
> added
> or removed our menu items directly from the cached menus.

But this is not a high level tool. This is a high level data (read,  
"global") with the responsibility to muck with it spread over clients.  
Using meta data on the methods, means that the behavior of what to do  
with it is encapsulated to the tool.

> Alternatively, if we wanted something like pragmas, but without new
> syntax, we could have extended the browsers to add annotation  
> objects to
> methods. The ANSI standard defines that we can add annotations to
> methods, but they are external to the method's source. The browser
> already supports one such annotation (the method's category). Why
> couldn't other annotations be added?

OK, this is the part I semi agree with. Or at least semi-ambivalent  
about. We've had this discussion before, and I was going to put it in  
the 8 point rambling, but betwixt the other points, it got forgotten.  
There are two separable discussions here. One is whether you should  
annotate methods or not and what to do with the annotation. The other  
is *how* the annotations get on the methods. When you say "the  
method's source", I guess I would clarify it as the method body's  
source. Method source is already two pieces of source slapped  
together. It is it's body, the same type of stuff you might put in a  
workspace, and then there's a separable piece of source for the method  
signature. Each parser already has two sets of entry points because  
you've got to tell it whether you're just parsing a body, or a body  
with a method signature header. Putting the <tags> in there means we  
have to now slap three sequential pieces of source together. From an  
ideological pov, this bothers me a little. While everone wants to put  
multiple methods in one text pane, and figure out what additional  
syntax you add to put the boundaries around the methods, my back  
burner dream project, is to go the other way, and actually use  
multiple text editing widgets to edit one method. One for the method  
signature, one for the body, and some kind of widgetry to manage tags.  
That's from an ideological pov. From a pragmatic pov, I guess I've  
just lived with the generalized form, and not found the time to get  
that excited about it.

Maybe I recognize with a sullied sense "yes we evolved the syntax",  
but there are a number of other things that were changed in the last  
10 years that annoy me far more than this ever did, and I've been able  
to put it to good use. It's made my life easier, not harder. That  
cannot be said for some of the other changes that were made.

I also note that Squeak has tagged method support now as well.

--
Travis Griggs
Objologist
"HTTP. It's like a bike pretending to be a bus, a bulldozer, and a cup  
of coffee at the same time." - Martin Kobetic


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

While pragmas are implemented using messages, I view them
as method properties and as such, how they are used, and
ultimately how they can be explored, depends on the code
system using them. Many of the menu pragmas use symbols,
such as a method selector for enablement, but they could
have just a well used a string that compiles to a block.
So, I would have to say that it is up to the individual
that defines the pragmas as to how easy it is to use
senders/implementors to analyze the code. Additionally,
I don't see how a generalized tool can be created to
analyze all the possible flavors pragmas can take on.

I think part of your dilema is that when the system or an
application uses reflection to determine its configuration
it becomes difficult to analyze.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 21/07/2008, at 3:35 AM, Terry Raymond wrote:

> =I think part of your dilema is that when the system or an
> application uses reflection to determine its configuration
> it becomes difficult to analyze.

Yes, hence my repeated comments about the 'sender' side of pragmas not  
being reified into the language syntax, unlike the implementers side.

And pragmas ARE part of the language not least because the implementor  
side of the pragma is syntax.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

You can't just ask customers what they want and then try to give that  
to them. By the time you get it built, they'll want something new.
   -- Steve Jobs



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 20-Jul-08, at 10:59 PM, Eliot Miranda wrote:

> Basically program change needs to be better formalised.  There was  
> an attempt to generalise the ChangeSet notification framework, but  
> that isn't adequate.  People need to [put their heads together,  
> collect some use cases and design something, eradicating the  
> existing hacked mess.  But its effectively a rewrite of the  
> compilatin and class building kernel.

Squeak has something called the SystemChangeNotifier. It works  
remarkably like Announcements, though unfortunately it was written a  
little bit too early to benefit from Vassili's insight there. One can  
subscribe to change notifications at various granularities and receive  
objects describing the changes in detail. It's used for things like  
writing to the changes file, updating the current change set, updating  
browsers, etc. Now that Squeak has pragmas as well, it's good  
mechanism for monitoring metadata changes, although the *use* of  
pragmas isn't yet widespread in Squeak.

This solves the problem that Travis mentioned - lack of conflict-free  
extensibility in reacting to metadata changes. But it is also  
generalization of ChangeSet notification, so you clearly have some  
something more in mind... would you care to elaborate?

Colin


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc