working on a live multi-Smalltalk module system

Hi all--

     I'm developing a change management system (links below) that works
live across multiple Smalltalks, including VisualWorks. It's called
Naiad ("Name And Identity Are Distinct"), and is part of the Spoon
project, an exploration of minimalism. If you'd like to help implement
or test, please let me know.


     thanks!

-C

summary: http://netjam.org/spoon/naiad
news: http://thiscontext.wordpress.com
chat: irc://irc.freenode.net/#spoon
list: http://tinyurl.com/62nxn5l (lists.squeakfoundation.org)

--
Craig Latta
www.netjam.org/resume
+ 31 020 894 6247
+  1 415 287 3547

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

Craig,

I haven't looked at you links, but I have something that will give you a good start...

The kind of functionality you are talking about was encouraged many years ago and there is a good code base to start from. The basics are to parse Smalltalk to nodes that can then be used to generate dialect-specific and formatted source code (even basic Java syntax). The nodes would be serialized in a portable form. The nodes could even be evaluated like compiled code (for dialects that didn't include the compiler at runtime). 90% of that functionality already existed prior to Camp Smalltalk 1. I lead a CS1 project to port State Replication Protocol (the portable serialization framework) to more Smalltalk dialects. All dialect at that time were supported. The parsing and node work was already complete too but needed to be ported to more dialects too. It was (and still is) only ported to VisualAge and VisualWorks (a really old ENVY version). It was able to store the node tree more compactly than original source string. Aside from the SRP porting effort at CS1, I wrote all of!
  this code. It is open-source.

The code has waited for someone like you to continue the project. It wasn't something I wanted to do alone forever. I gave up when it became obvious that most people didn't about portability as much as I did. Store was in infancy at the time, and use of an RDB and XML is the limit of what people considered portable. My personal time is used on other projects now, and I don't care to get involved in this again. You are welcome to the code.

The parts that remain are: 1) use SRP to define the structure and protocol of a code repository; 2) create a portable communication layer for accessing code between dialects; 3) porting all the code to the latest versions of the dialects.

The last two is where it gets tricky depending on how ambitious you are. When I was doing it I was making the loaded code compatible with the native code repository (ENVY) so that either could be used. Now there are so many native forms that this is no longer a simple matter.

Regards,

Paul Baumann




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Craig Latta
Sent: Monday, January 31, 2011 06:40
To: vwnc
Subject: [vwnc] working on a live multi-Smalltalk module system
Importance: Low


Hi all--

     I'm developing a change management system (links below) that works
live across multiple Smalltalks, including VisualWorks. It's called
Naiad ("Name And Identity Are Distinct"), and is part of the Spoon
project, an exploration of minimalism. If you'd like to help implement
or test, please let me know.


     thanks!

-C

summary: http://netjam.org/spoon/naiad
news: http://thiscontext.wordpress.com
chat: irc://irc.freenode.net/#spoon
list: http://tinyurl.com/62nxn5l (lists.squeakfoundation.org)

--
Craig Latta
www.netjam.org/resume
+ 31 020 894 6247
+  1 415 287 3547

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


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


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

On 1/31/2011 12:40 PM, Craig Latta wrote:
>       I'm developing a change management system (links below) that works
> live across multiple Smalltalks, including VisualWorks. It's called
> Naiad ("Name And Identity Are Distinct"), and is part of the Spoon
> project, an exploration of minimalism. If you'd like to help implement
> or test, please let me know.
Hi Craig!
Good to see you working on this, I read the naiad document and have some
points of critique for you to use as you see fit:


First off the document mixes a load of implementation details with the
abstractions that are important, and seem to bemuddle some design
decisions I would consider important to keep clean.

Hence I suggest you create a mental model around abstractions first:
restrict yourself to think in terms of declarations, their references,
their 'current' name and how they tie to editions and perhaps shared
repositories.
Only when this model is complete and consistent progress towards
specializing this for various Smalltalk declarations (modules,
namespaces, classes, methods, selectors, named references etc) and then
again a specialization further towards Spoon and its innards.



Secondly I want to point out  that you (and many others in our métier  
;-) are using the word 'namespace' in a very flat-and-static way so we
can get away with hand waving when we say they are globally resolvable.
This system (which has strong tie-ins with the Squeak convention of
prefixing class names) is not a namespace but a naming authority system.
Other systems use DNS-like prefixes instead of the ad-hock ones used in
Squeak so that the system is more robust in the face of name clashes, in
particular the DNS adds the concept of delegation of authority (to
create names).
Namespaces (at least as I see them) are not about name creation
authority but about visibility management, so we can create and use
simple short names and have the context in which they are used determine
their interpretation (for example when I say 'class' you know what I
mean from context even though that word is a homonym for many other
things in the English language).
The word 'namespace' is an unfortunate historical choice since that
reflects the implementation. In discussions I often try to bend peoples
mind towards my interpretation by using the more abstract term
'vocabulary' (borrowed from the Forth language). So we then have the two
concepts 'naming authority' and 'vocabulary'.
There are many more things I can rant about concerning namespaces, but
I'll stop here - just make sure you know which you mean in the case of
naiad.



My third and final remark is about UUIDs. In short: they are toy quality
- do not use them in any application that pushes real money or other
valuable assets.
UUIDs can be best thought of as being a hash of location+time and have
all the problems associated with hashes: you will need to both detect
and handle clashes.
Several years ago I did a revealing experiment: I searched the web for
UUIDs I had created several years before that (in the context of COM
interfaces); guess what: my 'Universally Unique' IDs where not unique at
all. Dereferencing a UUID thus needed context (my com server software
file that was installed/registered on my system) before they can be
disambiguated. This smells a lot like delegation of naming authority!
So I guess it is best to use UUIDs as a stop-gap measure (and they will
go a long way), but for real world applications you will need a
different system where naming authorities are established (particularly
in the context of shared repositories) and where naming authorities are
often unreachable (forcing one to create a lot of support structure, for
example to create temporary IDs that get replaced by 'more global' IDs
when a naming authority (like a shared repository or an intermediate
cache) becomes reachable again. I guess the fallout of this is that you
will need to prepare your implementation to handle different concrete
implementations of IDs.



Hope this helps,

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

Hi Reinout--

     Thanks for reading and commenting!

> First off the document mixes a load of implementation details with the
> abstractions that are important, and seem to bemuddle some design
> decisions I would consider important to keep clean.

     To what are you referring, specifically?

> Secondly I want to point out that you (and many others in our métier
> ;-) are using the word 'namespace' in a very flat-and-static way so we
> can get away with hand waving when we say they are globally
> resolvable.

     Actually, part of what I'm proposing is completely unconstrained
class names (by discontinuing the traditional equation of class identity
with class name), so I'm arguing that class namespaces by *any*
definition are unnecessary.

> The word 'namespace' is an unfortunate historical choice since that
> reflects the implementation. In discussions I often try to bend
> peoples mind towards my interpretation by using the more abstract term
> 'vocabulary' (borrowed from the Forth language).

     What exactly do you mean by "vocabulary"? (Telling me to just read
about Forth is a fine answer, but I'm interested in anything else you
might have to add.)

> So we then have the two concepts 'naming authority' and 'vocabulary'.

     Well, I aim to permit each developer to name each class anything at
all, and to provide tools for people to distinguish classes that happen
to have the same name, through other descriptive information.  (Sorry
for all the infinitives. :)

     For example, if you and I both create a class called "Socket", I
can still tell mine from yours because I can see that I defined it (and
probably redefined it :), at a certain time, etc. The compiler doesn't
care at all about the name, so, for example, changing the name of a
class requires no recompilation.

     Class names, in this system, are purely for the benefit of people.
In effect, every developer is an unconstrained naming authority.

     Of course you can't just leave it at that. ;) I'm curious about a
few things... with what frequency were you creating them? Were yours and
the ones you found on the web both created in a manner consistent with
the Leach/Salz algorithm? (Most recently documented in RFC 4122, as far
as I can tell.) If so, which version field value(s) were you using? (RFC
4122 section 4.1.3.) If they were version 4 (using randomness or
pseudo-randomness), what was your entropy source?

     Classes in Naiad are identified through a combination of a UUID for
the class itself, a UUID for the author, and 16 version bits. I argue
that the probability of a collision in even the author UUIDs, even using
time-based UUIDs, is sufficiently low.

     So...

> Dereferencing a UUID thus needed context...

     ...while the measures you went on to describe for collision
resolution in your case certainly sound unpleasant (especially the part
about dealing with unreachable naming authorities :), I'm not yet
willing to concede that the Naiad situation is similar.

> I guess the fallout of this is that you will need to prepare your
> implementation to handle different concrete implementations of IDs.

     As it happens, it can accommodate that, but I don't think it's
necessary.


     thanks again!

-C

--
Craig Latta
www.netjam.org/resume
+ 31 020 894 6247
+  1 415 287 3547


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

Craig,

I intended to answer in depth this week, but it seems that wont happen.
Please stand by.... I havent forgotton.

R
-






On 2/3/2011 4:28 PM, Craig Latta wrote:

--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************


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