[vwnc] Developers from other languages trying Smalltalk

On 24/07/2008, at 12:11 PM, Peter Hatch wrote:

> I assume that in this statement "Cincom engineering" is a euphemism  
> for "Peter Hatch", and I'm not sure why you didn't just say that  
> because I'm the one that replied to your original suggestion about  
> providing a pragma VI interface for specifying ELF symbol versioning  
> identifiers on [at least] Solaris and Linux.

Actually, all communication went through James Robertson - I never  
knew who I was talking to, and James didn't tell me - it was always  
'From one of our engineers' or 'From Engineering'.

I presumed he didn't want to open a direct channel, and respected that.

> POSIX had nothing to do with my argument.  If I rejected DLLCC-
> related things due to lack of POSIX compliance, then there wouldn't  
> even be an external callout mechanism for HPUX, Mac OS X, or  
> Windows.  The argument pivoted on the "narrow edge case" issue and  
> my concerns about the general lack of acknowledgement in our current  
> DLLCC implementation of the distinction between the compilation  
> context and the execution context for C compilation units.

Here's the final email in that thread that I received on 20 Oct 2007,  
proxied via James:

> Here's what I got back from engineering:
>
> "we use dlsym() and do not support this particular feature -  
> dlvsym(), since it only exists on one platform and is not POSIX  
> standard."

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

In anything at all, perfection is finally attained not when there is  
no longer anything to add, but when there is no longer anything to  
take away.
   -- Antoine de Saint-Exupery


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

Peter,

I'm sorry if my original post caused offence. I hope you can see from  
my reply that I wasn't trying to misrepresent you, nor did I know who  
you were.

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

A Man may make a Remark –
In itself – a quiet thing
That may furnish the Fuse unto a Spark
In dormant nature – lain –

Let us divide – with skill –
Let us discourse – with care –
Powder exists in Charcoal –
Before it exists in Fire –

   -– Emily Dickinson 913 (1865)



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

David Buck wrote:

For non-Smalltalkers, there are many things about Smalltalk that make them nervous.  There's the image, the IDE, source code that's not in files, unfamiliar editors, the non C-style syntax and the dynamic typing.

I think it's a mistake to try to lure non-Smalltalk developers in using a bait and switch approach.  If you're going to make changes, make changes that even seasoned Smalltalk developers would use.

+2!

First, let's take the image.  It should be broken into two images - the development image and the system under development.  The system under development could be on the same computer or a different computer connected by a network.  This way, the development tools aren't embedded into the same system as the runtime. This will help alleviate concerns from non-Smalltalkers that the tools are in the same image as your code.

As for editors, the Smalltalk editor itself could be much improved. You should be able to bind keys to operations and have pre-built bindings for emacs-style or vi-style editors. Why can't we have an easy "move backward by one word" key? Would it be so hard to support keyboard macros? The argument is often made that Smalltalk code doesn't need it, but I don't but it.  There are many times when I could use a better editor.

There's lots of room for improvement right within the Smalltalk environment that would not only make non-Smalltalkers more comfortable but would also be beneficial to Smalltalkers as well.

David Buck
Simberon Inc.
www.simberon.com

Arden Thomas wrote:

Hi folks;

 

I posted a question to my blog;  Question for developers , about developers from other languages trying Smalltalk.

 

The quote from David Mertz is:

 

"I am very ambivalent about the imposed GUI/development environment/interpreter that Smalltalk (Squeak specifically in the tutorial) imposes on you. Smalltalk code focuses on ultra-short methods that really require the Smalltalk environment to browse and develop. I still feel a purity in separating my text editor from anything about the underlying language mechanisms. Smalltalk/Squeak is as far from that as it is possible to get: think Eclipse on steroids, and without any close button."

This, from my perspective, is one of those familiarity/comfort questions.

So, my question to the community but more so to any developer considering Smalltalk:

- If we made it so that you could write Smalltalk code in your favorite editor, would that be a bridge to help you become acquainted with Smalltalk?

- Second, would the comfort it brings overcome losing the power that the integration currently gives you? (hard question for non-Smalltalkers)

 

I appreciate any comments and perspective on this.  Thanks!

 

Arden Thomas

Cincom Smalltalk Product Manager

 

Cincom Smalltalk - It makes hard things easier, and the impossible, possible

 

_______________________________________________
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

Valloud, Andres schrieb: I think, that most Smalltalkers are thinking like this. Every
Smalltalker is programmig in terms of interfaces, we do it for years,
but the idea to document it within the source code seems to be strange
for Smalltalkers and I do not know why ? It may be ok, if the code
should be only used by one person, but if the code is for the general
public or a team - then such an annotation would be very nice.

Actually introducing features like this would not harm any old
Smalltalker, but will give all those C#, Java developers a well known
guidance within the language.

Marten


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

Colin,

this is an area where a lot could be copied from Eclipse. Its java text editor is great compared to the editing tools in Smalltalk browsers, except maybe Dolphin.

I like the occurence highlighting in Eclipse and I like the inidicators for breakpints, errors, warnings etc. on the left side of the editor. Heck, if someone wants line numbers in their class browser, why not?

And, of course, clean up the menus. This goes to VisualWorks as well as to VA Smalltalk...



>
>On 23-Jul-08, at 4:45 PM, Donald MacQueen wrote:
>
>> This is all so depressing. I think I'm gonna go launch some missiles.

I almost spit out my morning coffee when I read this ;-)
I am glad he's only playing with virtual missiles...

>
>Depressing? It's exciting! This is a great time to be a Smalltalker.  

Right. But it has been exciting all those years, even at the most depressing times...

>The mainstream is overrated.

agreed. But the people overrating it take it serious ;-)

Joachim


--
-------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

David,

>I think it's a mistake to try to lure non-Smalltalk developers in >usinga bait and switch approach.  If you're going to make changes, >makechanges that even seasoned Smalltalk developers would use.

+1

>First, let's take the image.  It should be broken into two images - >thedevelopment image and the system under development.  The system >underdevelopment could be on the same computer or a different >computerconnected by a network.  This way, the development tools >aren'tembedded into the same system as the runtime. This will help >alleviateconcerns from non-Smalltalkers that the tools are in the same >image asyour code.

I see no benefit in this. What advantage would you see in there? To me it looks like making the world a lot mor complex than it has to be. And what for?


>As for editors, the Smalltalk editor itself could be much improved.

Right. Look at the nice little tools that Eclipse offers.

I love the Diff viewer in Eclipse as well. Also its merging support.

>There are many times when I could use a bettereditor.

Especially in times when I have to work in Java and Smalltalk at the same time. I miss many little nice features of Eclipse's editor when working in VA or VW.


Joachim


--
Visit my blog (in German): http://www.joachim-tuchel.de
-------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

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

Am 24.07.08 07:20 schrieb "Marten Feldtmann":
Interfaces *can* be documented in Smalltalk, and the support for this has
been avaible for years. Load the package SmallInterfaces from the Public
Repository, and you have all you need. It has some nice features, like this
one:

"When a class chooses to implements an interface, the interface generates
stub methods for all messages for which there is no existing method
implementation via: createStubedMethodFor:from:. After which, the developer
fills in those stubs." (from the JOT article referenced below)

However, I have the impression that this package is almost forgotten. The
last version was from 2001 and was not loadable any more due to obsolete
class definition messages. I have republished it a few minutes ago with new
class definitions.

For more information about SmallInterfaces, see
Benny Sadeh, Stéphane Ducasse: "Adding Dynamic Interfaces to Smalltalk", in
Journal of Object Technology, vol. 1, no. 1, May-June 2002, pp. 63-79
http://www.jot.fm/issues/issue_2002_05/article1

Joachim Geidel



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

- after now working for 4 years with VS I still do not understand, how
the developers can be happy with their editor possibilities. Methods can
not be grouped into categories. Methods are sorted by names only.
Private/public methods, attributes - all are mixed together and offered.

How true! That's exactly what I think. After working for 4 years with
VS, I still prefer ObjectStudio Classic class browser over VS!

Madhu.

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

Am 24.07.2008 um 03:06 schrieb Colin Putney:

> The conventions around selection, cut and paste are near-universal,  
> and VW
> violates them for no reason that I can see. In fact, adhering to
> broader conventions would be generally good. Ctrl-F inserts
> 'ifFalse:'... WTF? There's no visual indicator when a method is dirty.
> Command keys are inconsistent between context menus and the text pane.
> Really important commands, like "senders" have obscure short-cuts,
> while really convenient short cuts, like Ctrl-F, are reserved for
> obscure functionality.

+1, Yes, yes, please! Ctrl-Q for inspect is a joke. Use Ctrl-I  
instead. And Undo should work as expected too.

All these tiny things, probably kept for historical reasons,  
contribute to the historical appeal of Smalltalk. The impression is  
that noone cares about the details (longtime Smalltalkers quickly get  
used to it). The work required to fix them is minimal, so make a list  
of ARs and go for it.

Andre

_______________________________________________
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

Hi Arden,

> - If we made it so that you could write Smalltalk code in your favorite
> editor, would that be a bridge to help you become acquainted with Smalltalk?
> - Second, would the comfort it brings overcome losing the power that the
> integration currently gives you? (hard question for non-Smalltalkers)

I agree with those who wrote that the editors in VisualWorks have to be
enhanced (including AutoComplete, RBCodeHighlighting, using standard
keyboard shortcuts, adding keyboard macros for things like inserting
ifFalse:, etc. etc.).

Antony Blakey has done some very creative work with VW recently, some of
which would be nice to see in the base image, e.g. his Aqua LookPolicy for
MacOS-X and his layout enhancements. Andre Schnoor's Chimera LookPolicy
would also give VW a fresher look. IMHO, old-fashioned looks shape the
perception of a piece of software the first time you see it on the screen. A
split-second may be sufficient to decide if someone likes it or not. The
decision process may not be very rational, but that's how our stone-age
primate brains work (no offense intended to anybody in particular ;-) ).

And no, I don't think that using Emacs, VisualSomething or whatever would
help learning Smalltalk.

What would put me off if I were a newbie are things like these:
- Having to load tons of additional parcels manually until I have a decent
environment (AutoComplete, RBCodeHighlighting, GHStoreEnhance,
ExtraEmphases, GHTools, StoreGlorp, LessProgress, NewPrerequisiteEngine,
RBRegexExtensions, RBStoreExtensions, RBTabbedToolsets, SearchLight,
Tools-StartupOrderingTool, WindowsGoodies, just to name a few).
- Not even knowing that I have to do this, and feeling bad when I find out.
- No advice about which ones to load, except the categorization in the
parcel manager.
- Some of them may  not even be in the category view of the parcel manager.
- Sometimes I load an older parcel from the contributions, only to find out
that it breaks my image.

Without GHStoreEnhance, I wouldn't even see which version of which package I
have loaded! Without RBTabbedToolsets, I wouldn't see that a browser has
more than one view! The tab controls don't have a "close" button on the
tabs!

It's the little things which pile up to a non-usability mess here.

Another aspect implicit in your questions is whether a different kind of
view would make it easier to start with Smalltalk. I don't know, but the
file-like view which Antony Blakey has proposed sounds interesting.

Best regards,
Joachim Geidel


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

Am 24.07.2008 um 01:45 schrieb Donald MacQueen:

> Arden Thomas wrote:
>> Even if we were not able to become a truly mainstream language, I'd  
>> like to
>> be a bigger niche player.  Still plenty of room to grow!

Absolutely.

> These discussions (If only Smalltalk had X, then the world would come
> running) have a whiff of desperation about them. And they remind me of
> Kent Beck telling his audience at Smalltalk Solutions in 1997 or 1998,
> "Face it. You've lost. Java's won!".

The winner doesn't take it all in this situation. It's neither a  
browser war, nor the race for the next big thing. If VW could double  
or triple its commercial user base, it would be a great success and  
still be a niche.


> I think Steven is right that Smalltalk missed its first shot at the
> mainstream and won't be getting a second one

If it wants to gain recognition by the mainstream, it must be able to  
create mainstream applications. And in a straight forward fashion,  
like other IDEs do.

Apart from the "favorite editor" sensitivities, the most obvious  
question is: Will it be able to create the products we want to sell?  
The answer is currently not provided by the IDE itself.

Andre

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

+1 from a German perspective

Helge

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Valloud, Andres
Gesendet: Mittwoch, 23. Juli 2008 20:33
An: [hidden email]
Betreff: Re: [vwnc] Developers from other languages trying Smalltalk

I'd like to disagree regarding the translation of the development tools.
At least in my experience growing up in a Spanish speaking country, I have to say that I prefer computers and their software in English.  The reason is that sooner or later, you realize the English version just makes more sense because it is the original one.  There's no language problems (Spanish has gender, English does not), there are no artificially shoehorned terms where they don't belong because Spanish was not the language in which the thing was invented, and finally there are no translation problems where you find yourself reading really poor Spanish (or perhaps a variant of Spanish that sounds particularly odd in yours).

I think Smalltalk just reinforces this preference because the syntax works in a language like English.  In a language with gender, you can't simply say Object new --- for example, is it Object nueva or Object nuevo?  There is no so-called 'number' in it either.  For instance, in English we get away with saying things like Things new, while in Spanish we would have to say Things nuevas (or nuevos).  The huge amount of code written in English and with English comments basically forces you to learn English as well.  At that point, I see little benefit in translating the IDE.

But... this is just an opinion.

Andres.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Mark Pirogovsky
Sent: Wednesday, July 23, 2008 10:19 AM
To: Ivan Tomek
Cc: VWNC List; [hidden email]
Subject: Re: [vwnc] Developers from other languages trying Smalltalk

We can all start programing in the Assembler using something like VI or ed line.  I do use VI on occasions to edit few *.st files - that is a great reminder how much nicer the Browser on any type of IDE is :-)


1. I think first thing you have to do is to translate all of the VW tools into the major native languages like German, French, Spanish,Italian or Russian -- I think there are as many smalltalk developers speaking those as English speaking folks.

BTW few days ago I asked that question - about language translations for the VW IDE and I did not get any straight answer.

2. Instead of trying to replace smalltalk browser, why not to make them to look more like other more familiar tools?

My 2c.


Ivan Tomek wrote:
>
> Hi Arden,
>  
> I think that the idea must sound horrible to every Smalltalk
programmer.
> Moreover, I don't think that the Browser as such can be a major
> obstacle for a programmer in another language. My opinion is that the
> resources that this would require could be spent in a far more
> beneficial way. For example, if you want to address development in
> particular, you could perhaps develope a substantially stripped down
> browser with only the essential options so as not to overwhelm the
beginner. <http://www.cincomsmalltalk.com/userblogs/arden/blogView?showComments=tr
ue&printTitle=Question_for_Developers&entry=3394260311> and
>     develop. I still feel a purity in separating my text editor from
>     anything about the underlying language mechanisms.
Smalltalk/Squeak that impossible, _______________________________________________
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

Marten,

Right... I certainly do not mean to impose my quite arbitrary POV on
these things on anybody.  They work for me, and that's about that :).

Andres.

-----Original Message-----
From: Marten Feldtmann [mailto:[hidden email]]
Sent: Wednesday, July 23, 2008 10:20 PM
To: Valloud, Andres
Cc: [hidden email]
Subject: Re: [vwnc] Developers from other languages trying Smalltalk

Valloud, Andres schrieb:
> Just from a personal point of view, and only thinking about my
> programming experience, I would not want to maintain the type
> annotations.  I try to write the least code possible, and in that case

> the number of choices is often reduced enough that I can remember all
> of them.  In that case, I can write less code and thus make progress
> faster because all the information I need is cached.
>
> However, your mileage may vary.
>
> Andres.
>  
I think, that most Smalltalkers are thinking like this. Every
Smalltalker is programmig in terms of interfaces, we do it for years,
but the idea to document it within the source code seems to be strange
for Smalltalkers and I do not know why ? It may be ok, if the code
should be only used by one person, but if the code is for the general
public or a team - then such an annotation would be very nice.

Actually introducing features like this would not harm any old
Smalltalker, but will give all those C#, Java developers a well known
guidance within the language.

Marten



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

My previous message concerning interface documentation was probably
off-topic.

Am 24.07.08 08:44 schrieb "Joachim Geidel" unter
<[hidden email]>:
> Am 24.07.08 07:20 schrieb "Marten Feldtmann":
>> I think, that most Smalltalkers are thinking like this. Every
>> Smalltalker is programmig in terms of interfaces, we do it for years,
>> but the idea to document it within the source code seems to be strange
>> for Smalltalkers and I do not know why ? It may be ok, if the code
>> should be only used by one person, but if the code is for the general
>> public or a team - then such an annotation would be very nice.
[snip]
> Interfaces *can* be documented in Smalltalk, and the support for this has
> been avaible for years. Load the package SmallInterfaces from the Public
> Repository, and you have all you need.

I had read "interface" in the sense of interfaces in Java, i.e. a
declaration of which methods a class has to implement, which is what
SmallInterfaces offers. That's probably not what Marten meant. Documenting
the API of a class is something altogether different. And yes, we have a
strange reluctance to even write method comments at all, let alone writing
them in a way which lets readers understand which kind of objects may be
used as parameters, and what the method will return. Intention revealing
names are a good thing, but I don't think that self-documenting code is
really possible (maybe with the exception of some trivial cases).

Joachim Geidel


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

>

Not that this is a full answer, but I do cover those issues in  
"Smalltalk Daily".  And if you go to www.cincomsmalltalk.com, the  
prominent "Learn" icon takes you there


_______________________________________________
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

THX Jochen,

you are summing up my opinion very well. I fully agree with Eliot (and Andre, Antony, Arden, Colin, David, Donald, Steve, and all) who oppose to de-volution of the tool set. Enhancing and making it comply to widely used standards out of the box is key for lowering the entry barrier. And: documentation, tutorials, examples etc. pp.. Replacing good (maybe not perfect) tools by inadequate ones is not the way to go.

Substituting the RB by vi, EMACS or even Eclipse to get beginners hooked seems to me like requiring to mount steering wheels on motorcycles for beginners because they probably drove cars before. Once they get used to it we may mount handle bars :-)

Cheers
Helge

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Joachim Geidel
Gesendet: Donnerstag, 24. Juli 2008 09:46
An: Arden Thomas; 'VWNC List'
Betreff: Re: [vwnc] Developers from other languages trying Smalltalk

Hi Arden,

> - If we made it so that you could write Smalltalk code in your
> favorite editor, would that be a bridge to help you become acquainted with Smalltalk?
> - Second, would the comfort it brings overcome losing the power that
> the integration currently gives you? (hard question for
> non-Smalltalkers)

I agree with those who wrote that the editors in VisualWorks have to be enhanced (including AutoComplete, RBCodeHighlighting, using standard keyboard shortcuts, adding keyboard macros for things like inserting ifFalse:, etc. etc.).

Antony Blakey has done some very creative work with VW recently, some of which would be nice to see in the base image, e.g. his Aqua LookPolicy for MacOS-X and his layout enhancements. Andre Schnoor's Chimera LookPolicy would also give VW a fresher look. IMHO, old-fashioned looks shape the perception of a piece of software the first time you see it on the screen. A split-second may be sufficient to decide if someone likes it or not. The decision process may not be very rational, but that's how our stone-age primate brains work (no offense intended to anybody in particular ;-) ).

And no, I don't think that using Emacs, VisualSomething or whatever would help learning Smalltalk.

What would put me off if I were a newbie are things like these:
- Having to load tons of additional parcels manually until I have a decent environment (AutoComplete, RBCodeHighlighting, GHStoreEnhance, ExtraEmphases, GHTools, StoreGlorp, LessProgress, NewPrerequisiteEngine, RBRegexExtensions, RBStoreExtensions, RBTabbedToolsets, SearchLight, Tools-StartupOrderingTool, WindowsGoodies, just to name a few).
- Not even knowing that I have to do this, and feeling bad when I find out.
- No advice about which ones to load, except the categorization in the parcel manager.
- Some of them may  not even be in the category view of the parcel manager.
- Sometimes I load an older parcel from the contributions, only to find out that it breaks my image.

Without GHStoreEnhance, I wouldn't even see which version of which package I have loaded! Without RBTabbedToolsets, I wouldn't see that a browser has more than one view! The tab controls don't have a "close" button on the tabs!

It's the little things which pile up to a non-usability mess here.

Another aspect implicit in your questions is whether a different kind of view would make it easier to start with Smalltalk. I don't know, but the file-like view which Antony Blakey has proposed sounds interesting.

Best regards,
Joachim Geidel


_______________________________________________
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 VWNC image could be created with the environmental
enhancements already loaded. Although, I think it would
also be important for the VWNC CD to include a minimal image.

Another possibility would be to modify the settings pages so
they would auto load the approporiate enhancement parcel when
an enhancement is requested.

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 Thu, 24 Jul 2008 11:31:51 +0200
Joachim Geidel <[hidden email]> wrote:

> My previous message concerning interface documentation was probably
> off-topic.

Nonetheless, thanks a lot for bringing this back into light. I've been
looking for something like that.

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