[vw7.7] Deprecated Features -- GUI

_______________________________________________
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

At 11:57 AM 2010-07-27, Adams, Charles wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01CB2DA4.5F575D3D"

[Directed at VW developers] But questions remain…
 
Will SubCanvas, the class, eventually go away? What will the palette icon refer to? Will it still be called SubCanvas? Does the concept as expressed in the development guide change somehow?
 
But the thing that confounds me most is the idea that somehow the whole world is a SubCanvas. (The whole world being CompositePart.) In what sense is a BorderDecorator a SubCanvas?

Well, it's not that the intention is that you use any subclass of CompositePart where you would have used subclass previously. It's that the class CompositePart can directly serve as a Subcanvas, because Subcanvasses really didn't add much in terms of state or behaviour to what their superclass did. It had one variable which was unused, and a handful of methods.

ControlWORKS makes copious use of SubCanvas. It is a central theme to the GUI. I suspect there will be little or no impact on existing code, although I’ve not actually seen VW 7.7.
 
I’m still trying to get my customer onto VW 7.4 from VW 2.5 (without a great deal of success) so things like this make me nervous.
 
 
From: [hidden email] [[hidden email]] On Behalf Of Adams, Charles
Sent: Tuesday, July 27, 2010 10:23 AM
To: Mark Plas; [hidden email]
Subject: Re: [vwnc] [vw7.7] Deprecated Features -- GUI
 
I see. Well, that’s good I guess.
 
 
From: Mark Plas [[hidden email]]
Sent: Tuesday, July 27, 2010 9:48 AM
To: Adams, Charles; [hidden email]
Subject: RE: [vwnc] [vw7.7] Deprecated Features -- GUI
 
I think it's only the SubCanvas class itself that has been deprecated. The concept of a SubCanvas still remains.
 
From: [hidden email] [[hidden email]] On Behalf Of Adams, Charles
Sent: dinsdag 27 juli 2010 16:20
To: [hidden email]
Subject: [vwnc] [vw7.7] Deprecated Features -- GUI
 
Anyone know why Subcanvas has been deprecated? I’m told it is still on the GUI palette. Will that go away, too? And yet, there remain subcanvas references and examples in the GUI development guide for 7.7??
 
I’m confused…
 
 
Charles Adams
Developer, ECP
Rudolph Technologies, Inc.
1100 W Campbell Rd
Richardson, TX 75080
 
_______________________________________________
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

Question still remains:   We had some minor enhancements to SubCanvas and our customers have large numbers of windowSpecs that refer to "SubCanvasSpec". So where do we put our enhancements:

a. Override SubCanvas and carry along/maintain SubCanvas and SubCanvasSpec even though Cincom may remove it from the image.
b. Create a new class and require our customers to modify all their windowSpecs
c. Cincom leaves deprecated SubCanvas in place and we can subclass/modify and use as before.

We are just trying to figure out how to proceed and find that we are lacking the info to make an educated decision ...

On 7/27/2010 12:31 PM, Alan Knight wrote:

At 11:57 AM 2010-07-27, Adams, Charles wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01CB2DA4.5F575D3D"

[Directed at VW developers] But questions remain…
 
Will SubCanvas, the class, eventually go away? What will the palette icon refer to? Will it still be called SubCanvas? Does the concept as expressed in the development guide change somehow?
 
But the thing that confounds me most is the idea that somehow the whole world is a SubCanvas. (The whole world being CompositePart.) In what sense is a BorderDecorator a SubCanvas?

Well, it's not that the intention is that you use any subclass of CompositePart where you would have used subclass previously. It's that the class CompositePart can directly serve as a Subcanvas, because Subcanvasses really didn't add much in terms of state or behaviour to what their superclass did. It had one variable which was unused, and a handful of methods.

ControlWORKS makes copious use of SubCanvas. It is a central theme to the GUI. I suspect there will be little or no impact on existing code, although I’ve not actually seen VW 7.7.
 
I’m still trying to get my customer onto VW 7.4 from VW 2.5 (without a great deal of success) so things like this make me nervous.
 
 
From: [hidden email] [[hidden email]] On Behalf Of Adams, Charles
Sent: Tuesday, July 27, 2010 10:23 AM
To: Mark Plas; [hidden email]
Subject: Re: [vwnc] [vw7.7] Deprecated Features -- GUI
 
I see. Well, that’s good I guess.
 
 
From: Mark Plas [[hidden email]]
Sent: Tuesday, July 27, 2010 9:48 AM
To: Adams, Charles; [hidden email]
Subject: RE: [vwnc] [vw7.7] Deprecated Features -- GUI
 
I think it's only the SubCanvas class itself that has been deprecated. The concept of a SubCanvas still remains.
 
From: [hidden email] [[hidden email]] On Behalf Of Adams, Charles
Sent: dinsdag 27 juli 2010 16:20
To: [hidden email]
Subject: [vwnc] [vw7.7] Deprecated Features -- GUI
 
Anyone know why Subcanvas has been deprecated? I’m told it is still on the GUI palette. Will that go away, too? And yet, there remain subcanvas references and examples in the GUI development guide for 7.7??
 
I’m confused…
 
 
Charles Adams
Developer, ECP
Rudolph Technologies, Inc.
1100 W Campbell Rd
Richardson, TX 75080
 
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

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

 

Thor Raabe
Master Developer / PCG
Rudolph Technologies, Inc.

1100 West Campbell Road
Richardson, TX 75080

Ph.  469.624.4669

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

I've worked on two VisualWorks upgrades lately and the Subcanvas issue has affected both upgrades.  Here are the problems we have seen:

    - Arbor Help still uses the "client" instance variable in SubCanvas. This variable isn't present in CompositePart
    - Customer added a "client" accessor method to SubCanvas and called it to access the variable (which is no longer present or set)
    - Various methods explicitly tested for SubCanvas - i.e.,  (component isMemberOf: SubCanvas) ifTrue: ...
    - Customer subclasses of SubCanvas end up creating instances of CompositePart instead because the new for SubCanvas creates a CompositePart

For both upgrades, I made the same choice - keep the SubCanvas class and delete the "new" method.

David Buck

Thor Raabe wrote:

Question still remains:   We had some minor enhancements to SubCanvas and our customers have large numbers of windowSpecs that refer to "SubCanvasSpec". So where do we put our enhancements:

a. Override SubCanvas and carry along/maintain SubCanvas and SubCanvasSpec even though Cincom may remove it from the image.
b. Create a new class and require our customers to modify all their windowSpecs
c. Cincom leaves deprecated SubCanvas in place and we can subclass/modify and use as before.

We are just trying to figure out how to proceed and find that we are lacking the info to make an educated decision ...

On 7/27/2010 12:31 PM, Alan Knight wrote:

At 11:57 AM 2010-07-27, Adams, Charles wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01CB2DA4.5F575D3D"

[Directed at VW developers] But questions remain…
 
Will SubCanvas, the class, eventually go away? What will the palette icon refer to? Will it still be called SubCanvas? Does the concept as expressed in the development guide change somehow?
 
But the thing that confounds me most is the idea that somehow the whole world is a SubCanvas. (The whole world being CompositePart.) In what sense is a BorderDecorator a SubCanvas?

Well, it's not that the intention is that you use any subclass of CompositePart where you would have used subclass previously. It's that the class CompositePart can directly serve as a Subcanvas, because Subcanvasses really didn't add much in terms of state or behaviour to what their superclass did. It had one variable which was unused, and a handful of methods.

ControlWORKS makes copious use of SubCanvas. It is a central theme to the GUI. I suspect there will be little or no impact on existing code, although I’ve not actually seen VW 7.7.
 
I’m still trying to get my customer onto VW 7.4 from VW 2.5 (without a great deal of success) so things like this make me nervous.
 
 
From: [hidden email] [[hidden email]] On Behalf Of Adams, Charles
Sent: Tuesday, July 27, 2010 10:23 AM
To: Mark Plas; [hidden email]
Subject: Re: [vwnc] [vw7.7] Deprecated Features -- GUI
 
I see. Well, that’s good I guess.
 
 
From: Mark Plas [[hidden email]]
Sent: Tuesday, July 27, 2010 9:48 AM
To: Adams, Charles; [hidden email]
Subject: RE: [vwnc] [vw7.7] Deprecated Features -- GUI
 
I think it's only the SubCanvas class itself that has been deprecated. The concept of a SubCanvas still remains.
 
From: [hidden email] [[hidden email]] On Behalf Of Adams, Charles
Sent: dinsdag 27 juli 2010 16:20
To: [hidden email]
Subject: [vwnc] [vw7.7] Deprecated Features -- GUI
 
Anyone know why Subcanvas has been deprecated? I’m told it is still on the GUI palette. Will that go away, too? And yet, there remain subcanvas references and examples in the GUI development guide for 7.7??
 
I’m confused…
 
 
Charles Adams
Developer, ECP
Rudolph Technologies, Inc.
1100 W Campbell Rd
Richardson, TX 75080
 
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

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

 

Thor Raabe
Master Developer / PCG
Rudolph Technologies, Inc.

1100 West Campbell Road
Richardson, TX 75080

Ph.  469.624.4669

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

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.851 / Virus Database: 271.1.1/3030 - Release Date: 07/26/10 14:34:00

  

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

This is getting a bit beyond my ability to hand-wave as a manager, and Travis, who's probably best able to answer the technical questions, is out of commission with a failed hard drive right now. But he should be able to answer those once he's back on-line.

At 02:41 PM 2010-07-27, Thor Raabe wrote:

Question still remains:   We had some minor enhancements to SubCanvas and our customers have large numbers of windowSpecs that refer to "SubCanvasSpec". So where do we put our enhancements:

a. Override SubCanvas and carry along/maintain SubCanvas and SubCanvasSpec even though Cincom may remove it from the image.
b. Create a new class and require our customers to modify all their windowSpecs
c. Cincom leaves deprecated SubCanvas in place and we can subclass/modify and use as before.

We are just trying to figure out how to proceed and find that we are lacking the info to make an educated decision ...

On 7/27/2010 12:31 PM, Alan Knight wrote:

At 11:57 AM 2010-07-27, Adams, Charles wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
         boundary="----_=_NextPart_001_01CB2DA4.5F575D3D"

[Directed at VW developers] But questions remain…
 
Will SubCanvas, the class, eventually go away? What will the palette icon refer to? Will it still be called SubCanvas? Does the concept as expressed in the development guide change somehow?
 
But the thing that confounds me most is the idea that somehow the whole world is a SubCanvas. (The whole world being CompositePart.) In what sense is a BorderDecorator a SubCanvas?

Well, it's not that the intention is that you use any subclass of CompositePart where you would have used subclass previously. It's that the class CompositePart can directly serve as a Subcanvas, because Subcanvasses really didn't add much in terms of state or behaviour to what their superclass did. It had one variable which was unused, and a handful of methods.

ControlWORKS makes copious use of SubCanvas. It is a central theme to the GUI. I suspect there will be little or no impact on existing code, although I’ve not actually seen VW 7.7.
 
I’m still trying to get my customer onto VW 7.4 from VW 2.5 (without a great deal of success) so things like this make me nervous.
 
 
From: [hidden email] [ [hidden email]] On Behalf Of Adams, Charles
Sent: Tuesday, July 27, 2010 10:23 AM
To: Mark Plas; [hidden email]
Subject: Re: [vwnc] [vw7.7] Deprecated Features -- GUI
 
I see. Well, that’s good I guess.
 
 
From: Mark Plas [ [hidden email]]
Sent: Tuesday, July 27, 2010 9:48 AM
To: Adams, Charles; [hidden email]
Subject: RE: [vwnc] [vw7.7] Deprecated Features -- GUI
 
I think it's only the SubCanvas class itself that has been deprecated. The concept of a SubCanvas still remains.
 
From: [hidden email] [ [hidden email]] On Behalf Of Adams, Charles
Sent: dinsdag 27 juli 2010 16:20
To: [hidden email]
Subject: [vwnc] [vw7.7] Deprecated Features -- GUI
 
Anyone know why Subcanvas has been deprecated? I’m told it is still on the GUI palette. Will that go away, too? And yet, there remain subcanvas references and examples in the GUI development guide for 7.7??
 
I’m confused…
 
 
Charles Adams
Developer, ECP
Rudolph Technologies, Inc.
1100 W Campbell Rd
Richardson, TX 75080
 
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

_______________________________________________
vwnc mailing list
[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
 

  Thor Raabe
Master Developer / PCG
Rudolph Technologies, Inc.
1100 West Campbell Road
Richardson, TX 75080
Ph.  469.624.4669

_______________________________________________
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

Travis,

Welcome back among the storage enabled. We were trying to figure out the status/future plans for SubCanvas and I understand you may be able to answer the following, previously posed question:

Question still remains:   We had some minor enhancements to SubCanvas and our customers have large numbers of windowSpecs that refer to "SubCanvasSpec". So where do we put our enhancements:

a. Override SubCanvas and carry along/maintain SubCanvas and SubCanvasSpec even though Cincom may remove it from the image.
b. Create a new class and require our customers to modify all their windowSpecs
c. Cincom leaves deprecated SubCanvas in place and we can subclass/modify and use as before.

We are just trying to figure out how to proceed and find that we are lacking the info to make an educated decision ...

It would also be interesting to understand what your plans are w.r.t. the UIBuilder for instance. Will there still be a SubCanvas button there, or will it be called CompositePart in the widget palette?

-Thor

On 7/28/2010 11:30 PM, Travis Griggs wrote:

On Jul 28, 2010, at 8:19 AM, Steven Kelly wrote:

Alan Knight wrote:

Travis, who's probably best able to answer the technical questions, is out of commission with a failed hard drive right now.

 

Hah! I always knew Travis was too good to be human. I suggest you reward him for all his good work by fitting him with a top of the range SSD drive :-)

 

Have no fear! He's back! With 4x the disk he used to have (now I can go nuts making vmware images). That said... did I miss a thread here somewhere?

--

Travis Griggs

Objologist

"No other topic generates more heat and less light than code formatting" --Kent Beck

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

Thor Raabe
Master Developer / PCG
Rudolph Technologies, Inc.
1100 West Campbell Road
Richardson, TX 75080
Ph.  469.624.4669

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

> a. Override SubCanvas and carry along/maintain SubCanvas and
> SubCanvasSpec even though Cincom may remove it from the image.
> b. Create a new class and require our customers to modify all their
> windowSpecs
> c. Cincom leaves deprecated SubCanvas in place and we can
> subclass/modify and use as before.

we have chosen option (a), because we added some extensions to SubCanvas
that utilize the client instVar for traversing subapplications.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Jul 29, 2010, at 12:31 AM, Holger Kleinsorgen wrote:

Did you make some overrides so that the client was actually being set/
retained by the Builder?

--
Travis Griggs
Objologist
Light travels faster than sound. This is why some people appear bright  
until you hear them speak...




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

Am 29.07.2010 18:43, schrieb Travis Griggs:
requires three changes:

Subcanvas class>>new
   ^  super new

UILookPolic>>subCanvasClass
   ^SubCanvas

SubCanvas>>aisClient: anAppModel
   client := anAppModel.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Jul 29, 2010, at 10:28 AM, Holger Kleinsorgen wrote:

So you've added a setter for client (#aisClient:) and are taking care  
somewhere else to get that sent. Could you do the same thing as you  
have done by simply adding the one following method:

CompositePart>>aisClient: anAppModel
        self propertyAt: #aisClient put: anAppModel

I assume you actually access it as well, so you'd probably add a second

CompositePart>>aisClient
        ^self propertyAt: #aisClient

(note you could actually place this on VisualPart just as well, just  
for generalizations sake)

--
Travis Griggs
Objologist
10 2 letter words: "If it is to be, it is up to me"


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

I have a better idea: why don't y'all just leave SubCanvas alone?

I have yet to hear a cogent argument for mucking with this class.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Travis Griggs
Sent: Thursday, July 29, 2010 2:29 PM
To: Holger Kleinsorgen
Cc: [hidden email]
Subject: Re: [vwnc] [vw7.7] Deprecated Features -- GUI


On Jul 29, 2010, at 10:28 AM, Holger Kleinsorgen wrote:

So you've added a setter for client (#aisClient:) and are taking care  
somewhere else to get that sent. Could you do the same thing as you  
have done by simply adding the one following method:

CompositePart>>aisClient: anAppModel
        self propertyAt: #aisClient put: anAppModel

I assume you actually access it as well, so you'd probably add a second

CompositePart>>aisClient
        ^self propertyAt: #aisClient

(note you could actually place this on VisualPart just as well, just  
for generalizations sake)

--
Travis Griggs
Objologist
10 2 letter words: "If it is to be, it is up to me"


_______________________________________________
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

The aisClient: call comes from Arbor Help. It's still called within a #respondsTo: test in ApplicationModel>>buildInSubcanvas:withBuilder:.

David Buck

Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message-----
From: Travis Griggs <[hidden email]>
Sender: [hidden email]
Date: Thu, 29 Jul 2010 12:29:16
To: Holger Kleinsorgen<[hidden email]>
Cc: <[hidden email]>
Subject: Re: [vwnc] [vw7.7] Deprecated Features -- GUI


On Jul 29, 2010, at 10:28 AM, Holger Kleinsorgen wrote:

So you've added a setter for client (#aisClient:) and are taking care  
somewhere else to get that sent. Could you do the same thing as you  
have done by simply adding the one following method:

CompositePart>>aisClient: anAppModel
        self propertyAt: #aisClient put: anAppModel

I assume you actually access it as well, so you'd probably add a second

CompositePart>>aisClient
        ^self propertyAt: #aisClient

(note you could actually place this on VisualPart just as well, just  
for generalizations sake)

--
Travis Griggs
Objologist
10 2 letter words: "If it is to be, it is up to me"


_______________________________________________
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

#aisClient: is still being sent in the base image code.

Our extensions to SubCanvas rely on the client instVar being set, so
these would have to be pushed up, too. Adding the three methods was
easier. Actually, it took less time than writing this mail ;) And if at
some point SubCanvas is removed from the base image, it will be probably
easier to add the class definition to the package containting the three
methods. After all, SubCanvas isn't a terribly evil guy, didn't cause
any troubles in the past.

CompositePart is also the superclass of a rather extensive class
hierarchy, so adding a #client accessor to CompositePart doesn't sound
very desriable.

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

On Jul 29, 2010, at 12:41 PM, Adams, Charles wrote:

> I have a better idea: why don't y'all just leave SubCanvas alone?
>
> I have yet to hear a cogent argument for mucking with this class.

Let me wax wide and philosophical, we'll leave the specific  
application of SubCanvas alone, until farther down.

<Big Long Analogy I worked up about old cities being built strata upon  
strata deleted>

Short of it, it behooves us, in general to simplify and reduce the  
Smalltalk class library. It's been a case of just add more and more  
and more and more and more for 30 years now. At some point, we have to  
sit back and reduce and simplify, if we're to be able to move forward.  
Moving forward is a good thing for all parties involved.

In specific, we reduced SubCanvas, because there was no real apparent  
reason for it, from a state/implementation Point of View. The arbor  
help system is EOL at best, the only reason it still exists, with all  
of its egregious hacks and overrides is because we've not allocated  
the resources to do a new help system. The current aisClient: method  
would only be invoked from the base image, if you had added said  
method yourself, or always shipped with the help system loaded.

It could be we reduced it the wrong way. Throwing stuff out isn't  
something we've had a lot of experience with over the years. In this  
same period, we've removed a bunch of WinXXSupport classes and  
ApplicationWindow. In both of those cases, we did so by simply  
removing the sublayer, pulling existing behavior up, and then aliasing  
the subname to the original name. Aliasing has the advantage that all  
extensions to and subclasses of, continue to load and work fine.

And it could be that the benefit of reducing in this particular spot  
outweighs the cost of "fixing it." That happens sometimes. :)

--
Travis Griggs
[hidden email]
"The dissenter is every human being at those moments of his life when  
he resigns momentarily from the herd and thinks for himself." -
Archibald MacLeish, poet and librarian



--
Travis Griggs
Objologist
For every adage, there is an equal and contrary un-adage

_______________________________________________
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