[vwnc] [7.6] Collection>>removeAll inconsistency?

I find it strange that #removeAll: returns removed elements yet
#removeAll returns the receiver. Shouldn't it return removed elements
also?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.


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

Boris,

IME, whenever I've used removeAll it's because I wanted to recycle a
collection to avoid having to create a new one.  This is particularly so
with large dictionaries (growth pain due to rehashing) or ordered
collections (growth pain due to becomes).  In this context, I find that
I do not care much about what has been removed since none of it was
meant to be kept.  As such, I'd prefer removeAll to answer self.  This
also saves the time needed to prepare an answer were removeAll be
implemented like this:

removeAll

  | answer |
  answer := self copy. "or equivalent"
  self actuallyRemoveAll.
  ^answer


Andres.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Boris Popov
Sent: Wednesday, May 21, 2008 10:51 AM
To: VW NC
Subject: [vwnc] [7.6] Collection>>removeAll inconsistency?

I find it strange that #removeAll: returns removed elements yet
#removeAll returns the receiver. Shouldn't it return removed elements
also?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.


_______________________________________________
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

Andres,

Of course it all depends on the use cases, because I tend do something
along the lines of,
 
(outstanding removeAll: batch) do: [:ea | ea process]

So I'd assumed that the following would also work,

outstanding removeAll do: [:ea | ea process]

It seems that perhaps for the sake of consistency they should both
return the removed elements and your use case implement a different
name, #clear perhaps? Thoughts?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
Behalf
> Of Valloud, Andres
> Sent: Wednesday, May 21, 2008 12:37 PM
> To: VWNC
> Subject: Re: [vwnc] [7.6] Collection>>removeAll inconsistency?
>
> Boris,
>
> IME, whenever I've used removeAll it's because I wanted to recycle a
> collection to avoid having to create a new one.  This is particularly
so
> with large dictionaries (growth pain due to rehashing) or ordered
> collections (growth pain due to becomes).  In this context, I find
that header.
> Unless otherwise indicated, it contains information that is private
and
> confidential. If you have received it in error, please notify the
sender
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hmmm... I see what you mean.  However, and perhaps because of my own
subjective biases, it would be my opinion that removeAll is a special
case because the whole contents of the collection are being thrown away
(as opposed to a subset).

For a moment, and just for fun, I thought of implementing a variation of
removeAll along these lines...

removeAll

  | answer |
  answer := self class new. "or equivalent"
  self become: answer.
  ^answer


However, it has the defect that the capacity is not preserved, and if it
was preserved then it could cause a lot of memory usage in situations
where the current behavior is more appropriate.

Andres.

-----Original Message-----
From: Boris Popov [mailto:[hidden email]]
Sent: Wednesday, May 21, 2008 12:47 PM
To: Valloud, Andres; VWNC
Subject: RE: [vwnc] [7.6] Collection>>removeAll inconsistency?

Andres,

Of course it all depends on the use cases, because I tend do something
along the lines of,
 
(outstanding removeAll: batch) do: [:ea | ea process]

So I'd assumed that the following would also work,

outstanding removeAll do: [:ea | ea process]

It seems that perhaps for the sake of consistency they should both
return the removed elements and your use case implement a different
name, #clear perhaps? Thoughts?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
Behalf
> Of Valloud, Andres
> Sent: Wednesday, May 21, 2008 12:37 PM
> To: VWNC
> Subject: Re: [vwnc] [7.6] Collection>>removeAll inconsistency?
>
> Boris,
>
> IME, whenever I've used removeAll it's because I wanted to recycle a
> collection to avoid having to create a new one.  This is particularly
so
> with large dictionaries (growth pain due to rehashing) or ordered
> collections (growth pain due to becomes).  In this context, I find
that
> I do not care much about what has been removed since none of it was
> meant to be kept.  As such, I'd prefer removeAll to answer self.  This
header.
> Unless otherwise indicated, it contains information that is private
and
> confidential. If you have received it in error, please notify the
sender
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Andres,

What I am arguing however is that they are not *quite* being thrown
away, they are intended to be used for something good one last time when
the method returns. I am also arguing that removeAll is a simply a
shortcut for,

 collection removeAll: collection

and hence should preserve the behavior. If you really intend to just
throw them away in the most effective manner, the method should be
called something else, which is why I mentioned #clean or #clear etc.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
Behalf
> Of Valloud, Andres
> Sent: Wednesday, May 21, 2008 12:59 PM
> To: VWNC
> Subject: Re: [vwnc] [7.6] Collection>>removeAll inconsistency?
>
> Hmmm... I see what you mean.  However, and perhaps because of my own
> subjective biases, it would be my opinion that removeAll is a special
> case because the whole contents of the collection are being thrown
away
> (as opposed to a subset).
>
> For a moment, and just for fun, I thought of implementing a variation
of it header.
> Unless otherwise indicated, it contains information that is private
and
> confidential. If you have received it in error, please notify the
sender particularly
> so
> > with large dictionaries (growth pain due to rehashing) or ordered
> > collections (growth pain due to becomes).  In this context, I find
> that
> > I do not care much about what has been removed since none of it was
> > meant to be kept.  As such, I'd prefer removeAll to answer self.
This elements
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Now that the use cases are identified, I'd say that there is a need for
two methods instead of one, e.g. removeAll answering the removed
elements, as Boris suggested, and flushElements for just throwing them
away. Which would, of course, cause the usual backward compatibility
problems... :-)

Joachim

Valloud, Andres schrieb am 21.05.2008 21:58 Uhr: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Joachim,

There isn't much backwards compatibility to worry about given it was
added in 7.6, so I would urge the team to reconsider.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
Behalf
> Of Joachim Geidel
> Sent: Wednesday, May 21, 2008 10:43 PM
> To: VWNC
> Subject: Re: [vwnc] [7.6] Collection>>removeAll inconsistency?
>
> Now that the use cases are identified, I'd say that there is a need
for special
> > case because the whole contents of the collection are being thrown
away
> > (as opposed to a subset).
> >
> > For a moment, and just for fun, I thought of implementing a
variation of
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On May 22, 2008, at 9:05 AM, Boris Popov wrote:

> Joachim,
>
> There isn't much backwards compatibility to worry about given it was
> added in 7.6, so I would urge the team to reconsider.

I'd like to understand a bit better the motivation for consistency  
here. I'm all for consistency. I'm all for pragmatism too, there's  
always a tension there. I don't really have a position on this, other  
than I can see issues either way.

Is the desire for consistency here motivated by:
A) I was looking at the code, noticed it was different, thought that  
might not be a good thing, because it was inconsistent.
B) I was using the code, and expected a different result, so was a bit  
surprised, but I was not depending on the consistency.
C) I wrote code that depended on the consistency, and got burned by it  
not being so.

I'm just curious. No one needs to "defend" their position. :)

--
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



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

We should be trying to follow the Principle of Least Astonishment.  
Smalltalkers know that remove methods return the things removed.  This
should apply to all remove methods with no exceptions.  Exceptions will
cause bugs regardless how useful you think the exception may be.  All
removes should return the things removed.  All at:put:'s should return
the thing written.  It should be consistent everywhere.

David Buck
Simberon Inc.

Boris Popov wrote:
> Joachim,
>
> There isn't much backwards compatibility to worry about given it was
> added in 7.6, so I would urge the team to reconsider.
>
> -Boris
>
>  

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

Travis,

Mine was simply a case of B, where I needed to clear the collection then
do something with its previous contents (or vice versa) and knowing that
remove-type protocols always return element(s) that just got removed I
had wrongly assumed that removeAll would do the same. Hence the request
for consistency, because removeAll is nothing more than a special case
of removeAll: and should follow the same convention IMHO.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
Behalf
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The selector name removeAll brings to mind all the other remove
selectors and my expectation is that it would work the same way. I
believe most Smalltalkers would also expect it to work that way.
Creating a special case for us all to remember is a bad idea.

If there is a need for a method that behaves differently then it should
have a different name, ideally one evocative of its special behavior; in
this case perhaps clearAll or flushAll.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Travis Griggs
Sent: Thursday, May 22, 2008 9:29 AM
To: VWNC NC
Subject: Re: [vwnc] [7.6] Collection>>removeAll inconsistency?


On May 22, 2008, at 9:05 AM, Boris Popov wrote:

> Joachim,
>
> There isn't much backwards compatibility to worry about given it was
> added in 7.6, so I would urge the team to reconsider.

I'd like to understand a bit better the motivation for consistency  
here. I'm all for consistency. I'm all for pragmatism too, there's  
always a tension there. I don't really have a position on this, other  
than I can see issues either way.

Is the desire for consistency here motivated by:
A) I was looking at the code, noticed it was different, thought that  
might not be a good thing, because it was inconsistent.
B) I was using the code, and expected a different result, so was a bit  
surprised, but I was not depending on the consistency.
C) I wrote code that depended on the consistency, and got burned by it  
not being so.

I'm just curious. No one needs to "defend" their position. :)

--
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



_______________________________________________
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

> Is the desire for consistency here motivated by:
> A) I was looking at the code, noticed it was different, thought that
> might not be a good thing, because it was inconsistent.
> B) I was using the code, and expected a different result, so was a bit
> surprised, but I was not depending on the consistency.
> C) I wrote code that depended on the consistency, and got burned by it
> not being so.

D) I saw Boris email, felt that he was right, and assume that if the method
stays the way it is, we'll see this discussion again next year. And the year
after that. And again when one of the other dialects adds the method, which
will of course have a different semantics. Oh, and I didn't even look at the
code. :-)

Joachim


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

Hear, hear! This must be the overarching rule.

----- Original Message -----
From: "David Buck" <[hidden email]>
To: "Boris Popov" <[hidden email]>
Cc: "VWNC" <[hidden email]>
Sent: Thursday, May 22, 2008 11:35 AM
Subject: Re: [vwnc] [7.6] Collection>>removeAll inconsistency?

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

I've been digging around in the documentation for information about  
deploying a universal OS X application using VW 7.6, but I can't seem  
to find any.  I have no trouble running my RTP'd application on my x86  
MacBook, but it terminates on startup with an error when trying to  
start it on my G4 iMac.  When I remove unnecessary VMs from the  
visual.app package, is there one in particular that I must leave in  
there to support G3/G4/G5?

-Carl Gundel
Easy Windows Programming - http://www.libertybasic.com
Easy Web Programming - http://www.runbasic.com

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

This is a preamble to a couple of replies. I want to say right up  
front, I don't honestly care how removeAll works. At least, not right  
now. I'd be fine changing it to return a different object. I've  
enjoyed the responses and taken some good thoughts from them. Thank  
you all.

If it seems like I'm defending the current position, I'm not really  
trying to defend it per se. It's instructive to me to challenge some  
of the things claimed and see what the results are. So if I challenge  
a response, I'm not really trying to advocate one approach or the  
other. Just exploring. In short... no need to flame me. :)

--
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

On May 21, 2008, at 10:43 PM, Joachim Geidel wrote:

> Now that the use cases are identified, I'd say that there is a need  
> for
> two methods instead of one, e.g. removeAll answering the removed
> elements, as Boris suggested, and flushElements for just throwing them
> away. Which would, of course, cause the usual backward compatibility
> problems... :-)


Is there really 2 *real* use cases defined? removeAll was added as a  
result of a variety of customers over the years requesting this  
utility be added, since they were adding it themselves. Of the 2 or 3  
submissions we looked at, none of them bothered to return something  
other than the receiver. So the apparent use case was a method called  
removeAll that did the "clean" behavior.

I'm not sure that there is a real request for a method that behaves as  
we've talked about here. I can imagine what I might do with such a  
thing. But I haven't ever really needed such a thing to date, so it's  
never been a common extension I've created.

--
Travis Griggs
Objologist
"Dying men never wish they'd spent more time at the office"


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

Travis,

I understand that you'd seen a few implementations that didn't care
about the return values and I can even see why most wouldn't, but that
fact alone doesn't make them objectively correct IMHO. I had in fact
come across a use case here where different behavior would have been
useful, a little too late it seems :)

I had just briefly looked at the ANSI only to find that it does not
specify return values for #removeAll: only that #remove: return the
removed element, but I still stand by my argument that convention up
until now has been to return added/remove element(s) when using
add:/remove:/addAll:/removeAll: so the newest addition of removeAll
should follow the same or be called something else. However, ultimately
Cincom is the authority as far as their codebase goes, we can only
provide feedback, so no hard feelings.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
Behalf them
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On May 22, 2008, at 9:35 AM, David Buck wrote:

> We should be trying to follow the Principle of Least Astonishment.
> Smalltalkers know that remove methods return the things removed.  This
> should apply to all remove methods with no exceptions.  Exceptions  
> will
> cause bugs regardless how useful you think the exception may be.  All
> removes should return the things removed.  All at:put:'s should return
> the thing written.  It should be consistent everywhere.


I certainly agree. I don't like being surprised.

But isn't this a dangerous rule Dave?

It basically gives every programmer the ability to proclaim something  
is bad because they got surprised when their expectations weren't met.  
It's a no win situation. I'm reminded of the scene on the deck of the  
Black Pearl (PoC-1) where Elizabeth is incensed about the fluidity of  
the "Pirates Code" and Barbosa condescendingly exclaims "it's more of  
a guideline."

I'd like to float a couple of "ideas" I've had on the subject. They're  
just brainfarts, not strong opinions, see the previous email. I'll  
make it a semi long email and use "headings."

_Anecdotal vs Theory
It's interesting that we're projecting what might happen because of  
the way the removeAll was implemented. But at least three sites with a  
decent amount of active programmers implemented it as such. So there  
was a quorum of people at one point whose "first cut" at this method  
(i.e. the one that was most natural and therefore least astonishing)  
was to not really care about the return value. And they were never  
astonished by the result in real world work. So we've got practice vs  
theory here.

_How Obvious is it for removeAnything to Return Anything in Particular?
This is another interesting aspect to look at. Only when taken in the  
context of just the VisualWorks class library does this make sense. A  
precedent was set there. While ObjectStudio does as VisualWorks does,  
prior to ObjectStudio 8, ObjectStudio did as Ruby does for adding.  
ObjectStudio already had a removeAll, it returns the receiver (not the  
removed objects). Squeak implements a removeAll, but only for limited  
Collection subclasses, not generally. In each case, it returns the  
receiver. Ruby does as VisualWorks does for removing (delete  
variants), but the various insert methods all return the reciever, not  
the additions. C++ returns the original collection. Objective-C  and  
Python return nothing useful (Python does have a pop() that behaves  
like removeLast). The point is, that the scope of one's POV  
establishes what is astonishing, and what is not. C++ people will be  
surprised. Objective C/Python people will never think to care. Ruby  
people will feel at home, until they start adding, at which point  
they'll be astonished, and have to learn about cascading. ObjectStudio  
people will be surprised by the removeAll implementation.

_What is the Convention Anyway?
The following humor vid is a good background to this line of thought:
http://youtube.com/watch?v=t439_zzEloY
We seem to be caught up on the fact that the method starts with the  
word 'remove'. But is that really the pattern? I might argue no. One  
thing all the other methods have that removeAll doesn't, is an  
argument. Not just the removeVariants:, but the various addVariants:  
too. What's being returned is the argument (or the implied one, e.g.  
removeAt:). Why is this? It's because in many cases the argument is  
the focus of an algorithm, and returning it turns out to be convenient  
to keep it on the top of the stack for continued use. But when using  
removeAll, you've moved to a point of indiscriminance regarding what  
to remove: "I don't care what's in there, I just want to dump it all".  
The point of interest is now the collection getting the enema, not  
what's coming out. So it might make sense to make that the return  
value. From this view point, it is the least astonishing (at least to  
me). If I did indeed want to snapshot an old collection of data and  
start afresh, I don't think I'd write it like this:

historicalSnapshot := gatheringSet removeAll.

I'd more likely write

historicalSnapshot  := gatheringSet.
puddleOfObjects := Set new.


The thoughtful reader might point out removeLast has no argument. This  
is just a macro basically for aSequence removeAt: aSequence size. And  
one could go farther than and fold the same argument on to the  
removeAll, which is a short cut for self removeAll: self. But even in  
this last case.. it's interesting, because if you implemented it like  
that, you'd get back an empty collection. Because the essential  
argument to the method is itself. So you're returning the thing  
removed. Perverse and twisted, probably? Just playing with ideas here.
(linguistic geekism aside here: isn't this so meta cool?, an argument  
revolving around whether there is an argument or not).

_Perverse Principle Allegiance Principle
Steve Dahl once challenged one of my proposals with the quote: ""Every  
institution finally perishes by an excess of its own first principle."  
by Lord Acton. I loved it so much I added it to my mail quotes list. I  
am NOT saying this is one of those cases. But I always think its  
valuable to back up in a case like this and ask if we are or not.

_Redux
Reminder, I was just having fun challenging some of the assertions put  
forward and thinking about them. I've put up  AR 54399 to consider  
changing it.

--
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



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

Hello all,
the only occasion that I have used removeAll
(my own implementation of it, that is, in another
smalltalk dialect), is to reuse OrderedCollections
and avoid creating garbage.
I only ever did this for optimization, after profiling.
Usually I just use
ivar := OrderedCollection new
instead.
So, IMHO, if somebody wants to iterate over the
collection before removing all elements, he might
as well do:
outstanding do: [ :ea | ea process ]; removeAll.

just my 2c
cheers,
Wolfgang



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

David Buck wrote:
> We should be trying to follow the Principle of Least Astonishment.  
>  
Absolutely. This is one of the things that distinguishes Smalltalk from
other languages. Like things work alike. And when you don't have to
think about language eccentricities, you can think about the domain
problem, which is, after all, what you are getting paid to solve.

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