From rideau@clipper Tue May 18 00:46:06 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23327; Tue, 18 May 93 00:46:04 +0200
Return-Path: <rideau@clipper>
Received-Date: Tue, 18 May 93 00:46:04 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from nef.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17091; Mon, 17 May 93 15:39:19 -0700
Received: from dmi.ens.fr by nef.ens.fr (5.65c8/ULM-1.0)
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fregate.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23280; Tue, 18 May 93 00:38:38 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9305172238.AA23280@clipper.ens.fr>
Subject: Bases [far34]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Tue, 18 May 93 0:38:39 MET DST
X-Mailer: ELM [version 2.3 PL11]
Content-Length: 4936
X-Lines: 121
Status: OR

 Well, here is I think the main points we MUST agree before we can
begin coding what we call MOOSE (but we already can begin coding
IO drivers and suches).

SPECS
~~~~~

agreements
~~~~~~~~~~
a) MOOSE is "OO" (see Unknown, a))
b) we'll develop a generic UI (user interface), that will
specialize/extend into a TUI (Text UI) and a GUI (Graphical).
c)

Unknown
~~~~~~~

Questions:
@) What will we do that will be the same as or different from
other systems, currently existing or being developped ?
a) What does OO means for an OS ; i.e. what do we mean by "object" ?
b) How light will our basic objects/threads/tasks/processes be ?
c) What kind of typing/checking will the kernel/base system include,
if any ?
d) Must we include a standard LLL in the base system
e) Must we prepare for future distributedness (i.e. refuse solutions
that won't adapt to a distributed OS).

Answers:
Fare:
@) Object Orientedness will make us differ from everything else.
See a). Difference with NeXTStep ? I recommend using a tiny object
grain, whereas NeXTStep seems to use big objects and big messages.
a) it means objects are the generic basic system unit. Unix had files,
directories, devices, pipes, sockets, each completely different and
unextensible without kernel change. We'll have only one basic item,
which will be generic enough to contain code and data of any kind
wanted, and standard enough to be a media for code&data exchange
between programs (which is currently what @%^@%! computer users and
programmers most of the time).
b) Very light: objects are any kind, any size. A larger object is
a structure of smaller objects.
c) The whole thing. Typing some generalization of protection. At a
high level, typing IS protection. If you do not enforce typing
somehow, you won't have a secure OO system, so no one wishing
security will use system objects; you won't have an OO system, but
a common system like any other one; if so, let's just be happy with
unix.
Let us have a standard for describing objects. After that, we
can use this standard to describe other ways to describe objects, when
we want more extended classes. Let us have a HLL which will enable
direct access to this standard.
d) Yes, together with typing (will thus include code&data); see a);
at least, we need some way of exchanging code together with data.
Imagine a brand new format for this or that (example: the brand new
format YOU just designed); you'd like not to get/wait for/pay for
a brand huge (the hugest, the slowest/most difficult/most expensive
to get new version of each of your application to understand it; but
if you just get the proper small code for it, that's ok, and all your
apps will understand it). What I ask for is possible exchange of code,
in some compact and directly executable (or quickly compilable)
format.
e) Yes, because future machines WILL be distributed; the laws of
physics limit the power of a single processor. To break this barrier,
systems will HAVE to be distributed. So if we want not to write
Moose for nothing, we must prepare it for further extensions.


FIRST IMPLEMENTATION
~~~~~~~~~~~~~~~~~~~~
agreements
~~~~~~~~~
a) Moose will run on 386 PC compatible machines.

Unknown
~~~~~~~

Questions:


a) Kernel Requirements:
 - That's just a policy question, and there is a priori no rational
 arguments about it, but what machines we work on.
b) Object ID's.
c) Objects Classes.

Solutions proposed:
Fare:
a) a 386 with extended memory (even 384KB suffice for just booting
with a console ?).
b) use DT:Seg identifiers, or DT:Seg:Offset when needed. (when needed,
the offset may be considered as an argument to DT:Seg as a function
represented by the array of its values).
c) Disk representation will use integer codes (0,1,2,3,...) for
objects. When loaded to memory, these codes are eventually converted
to nearer or farer object IDs (and conversely), for fast
evaluation/access. (Note: this can be done at load time, or at use
time, or sometime in between, what is important is that disk
representation is portable, whereas memory representation is
efficient). 
To physically access an object, we need both its local data and its
more global class, and perhaps even more global meta-classes (a/o
classes you inherit from, etc). So what I propose is, at link time
(which can be just after loading, or during use), use two pointers
(or standard IDs of any kind), one to the class as a description of
data/methods, and to the effective data. If someone wants virtual
pointers, he'll have to use virtual memory traps so that a common
pointer using program can access it.


Please state your mind.
Please recall forgotten points.
Please add your comments.
Please correct mistype/broken english, or mistakes.
I'll maintain this bases list until we come to an agreement, or
someone is willing to replace me, so even a quick personal reply
in telegraphic style will be accepted, and I'll summarize it as soon
as received.

   ,
Fare

From rideau@clipper Tue May 18 04:44:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25664; Tue, 18 May 93 04:44:24 +0200
Return-Path: <rideau@clipper>
Received-Date: Tue, 18 May 93 04:44:24 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from nef.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28960; Mon, 17 May 93 19:27:56 -0700
Received: from dmi.ens.fr by nef.ens.fr (5.65c8/ULM-1.0)
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fregate.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25579; Tue, 18 May 93 04:26:46 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9305180226.AA25579@clipper.ens.fr>
Subject: Re: Beginning Work [djo9] [far35]
To: danodom@matt.ksu.ksu.edu (Dan Odom)
Date: Tue, 18 May 93 4:26:47 MET DST
Cc: mueller@sc.zib-berlin.de, moose-programmers@sfu.ca
In-Reply-To: <9305172217.AA29740@matt.ksu.ksu.edu>; from "Dan Odom" at May 17, 93 5:17 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

">" is Dan, quoting ">>" Peter

>> Therefore we have to create a module, which provides an interface with three
>> primitives, namely:
>> 
>> 	send(destination, message)
>> 	receive(from, message)
>> 	reply(to)
> 
> Agreed.
Well, this seems the basis of OOness. What isn't basic, is how we'll
implement it, and what part of it is in the specs/what part is
implementation dependent.

>> Where we still have to get to an agreement is:
>> 
>> o How looks a destination address? 
>>   Should it look like this: (machine address, object id, method id)
>>   or only like this: (object id, method id)
>>   or like this: (machine address, process id)
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That one.  Each process should have a 'message-handler' object that
> will receive messages and notify the rest of the process.

Well, an object's class is its message handler, isn't it ?
But what kind of message will the kernel transmit ?
Raw binary data ?
Ascii (burp) strings ?
Typed objects ?

> Kind of like:   if (MsgHandler.ismsg ());  // Check to see if msg. is waiting.
>                 switch (MsgHandler.message)
>                   // etc...
> 
uh ?

>> o How is address translation done?
>>   We have to specify the size of the address's parts.
>>   Here we have to say definitely where we expect Moose to run. Should it be
>>   able to run Moose on several machines or only on one? The latter will not
>>   require a machine address part, but that's clear.
> 
> Explain what you mean by 'more than one machine'.
Yes, do you mean have Moose portable (we agreed on that)(Oops ! I forgot it
in my bases posting; tomorrow's version will include it), or have it
distributed in a homogenous net, or even distributed in a heterogeneous net ?
Well, for the moment, we're not building a distributed version of Moose, but
perhaps we can build a driver to virtualize objects on a remote machine linked
by, say, a serial or parallel or ethernet port. However, this is not essential
to the original project (which does not mean we won't do it when we have time)
and this will be limited by our one machine based addressing (but we can build
gates -- no, not Bill Gates ;-( -- between different address types).


>> P.S: One for the compiler designer.
> 
> Woah!  SINGULAR??!!  Am I the only one interested in the compiler????
> Geez, I sure hope not.
>
> But if I must work alone, I must work alone.  Oh, well.
> 
Hey, he was talking about ME, not YOU ! :-)
More seriously, we're at least two about the compiler issue (I'm preparing
some post next)

>> I don't think, that the missing of a
>> compiler is a thing which disables us to start writing. If you provide the
>> possibility to use interfaces to other languages (preferably some which are
>> in common use, like C++), it's possible to start writing. (BTW: As some code
>> of the kernel must be done in Assembler, there must be at last an interface
>> to that sort of language ...)
> 
> Correct.  BUT, we haven't even decided what language we'll use (or if
> we have, no one told me).  Work on the C/C++ libraries can begin as
> soon as the kernel API is developed, and some work can be done before it is
> complete.  This assumes we're using C(++).

Well, I think Dennis should publish his pretty listing requirements; of course
we can begin coding; BUT let's not forget (1) not to use C/C++ unportable
hacks (i.e. pointer/integer typecasting, strange unions, etc); (2) let's be
ready to conform our programs to a new language and/or style to appear; (3)
let's include at lot of comments, so that anyone in the group can understand
one another's production;

> How's this:  Decide what language we'll use.  I'm in favor of C++, but
> if you all want something else we'll use something else.  Give me the
>  name of the language and I'll hammer out an initial spec for the RTL.
What about Objective C ?
What about some Objective ML ?
What about these languages Gary talked about ?
What about building our own HLL ?
What about having a language more intelligent than C++ (accepts larger
input to produce better code)

   ,
Fare

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Tue May 18 07:21:04 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04400; Tue, 18 May 93 07:21:03 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Tue, 18 May 93 07:21:03 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA04749; Mon, 17 May 93 22:09:09 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA03663; Tue, 18 May 93 01:09:05 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 010744.10133; Tue, 18 May 1993 01:07:44 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Tue, 18 May 1993 00:54:04 EDT
Date:      Tue, 18 May 1993 00:54:00 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bf86bed.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: ORG, IPC, pem 05/17/93  [djg22]
Status: OR


Gary D. Duzan wrote:

> Peter Mueller <mueller@sc.zib-berlin.de> wrote:
>
> =>Let me comment on this:
>
> => 1. A user should, of course, use blocking RPC (which meant
> =>    ROI).  This is the usual way to communicate in an
> =>    OO-environment.  (Ok, but to be honest: I suppose that their
> =>    will be some low-level user who uses low-lewel languages and
> =>    who will call IPC primitives directly ...  but that's for the
> =>    system people :-) Nonetheless their must be provided
> =>    mechanisms within the kernel with which ROI can be provided.
> =>    ROI is a more conceptual view of communication. As is RPC in
> =>    common procedure oriented environments. RPC also is only a
> =>    conceptual model, where the IPC stuff is hidden by stubs,
> =>    which are in turn automatically created.  We have also to
> =>    create such "stubs", though they will actually be some kind
> =>    of communication objects.  They should handle all necessary
> =>    stuff to invoke a remote method.
>
>    Fair enough.
>
> => 2. Now for the difficult part. I do not agree to include
> =>    asynchronous calls within the kernel.
>
> =>>    So I would advise making IPC asynchronous at the system level and
> =>> providing standard library (or langauge-imbedded) functions for
> =>> synchrounous IPC. When the secure function call technology appears, we
> =>> can simply change the library function (compiler) to use the new call.
> =>
> => And I say make it vice-versa: Provide synchronous IPC at system
> => level and mak e a standard lib. for asynchronous IPC. Yup, and:
> => BEWARE, I'm a tough guy to argue with in that subject ...
> => grrrrrr >:-|
>
>    Ok, ok, calm down. :-) I can live with synchronous IPC as long
> as we have good context switch time and kernel-level multiple
> thread support.

Well, the big problem with providing only synchronous IPC is that you
CANNOT make asynchronous I/O out of it without having a second thread.
The standard way in Unix to do I/O reading from two different sources
is to make one process reading each source.  Unix now has a kludge
called select() that allows a program to identify the descriptors with
available I/O, but this relies on the system and process being able to
keep up with the I/O.  On a VMS system (with asynchronous I/O), one
queues a number of asynchronous I/O calls on each channel, and
processes the data after it is transferred to your processes own space
and you are notified.  I feel this is a much more satisfactory
solution.

Until recently, I had felt that we should provide both synchronous and
asynchronous forms, but I now suspect that, by using only the
asynchronous form, we can have all method receptions having basically
the same starting environment.  With carefull design, starting a new
thread should be a very minor chore, probably less than the cost of
transferring data as part of the call.

> => Now I've got a question: An address of (Object id, method id
> => [,authorization] ).  Why is authorization necessary? Isn't it
> => enough that, IF an object have the address (object id, method
> => id), THEN it is automatically authorized to call the method?
> => Then authorization is separated from the objects. As the actual
> => address is grabbed from a (what's it name DIRECTORY? and:
> => where's the glossary?) Object, why not providing authorization
> => tasks within that object?
> => You are then again free to provide several security policies on
> => the fly by choosing the appropriate directory object. So you
> => can range from a system with no security at all to a full
> => secured system. Of course, the request for receiving an object's
> => address must hold a kind of ticket. This ticket should identify
> => the owner of the request and its permission rights.
>
>    The case you mention is using implicit rather than explicit
> authorization. Also, unless steps are taken to insure that it
> is very difficult (ideally impossible) to forge an address
> (capability, protected pointer, whatever), then it will not be
> secure. These steps I rolled up and called "authorization",
> since there is any number of ways to do it.
>
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts

The obvious way to avoid this is to not make the parameter be the
object ID.  If Unix had used their equivalent, you would pass inode
numbers to read() and write() calls.  The obvious solution is exactly
the same that Unix used, you open() the Object and get a process-
specific identifier.  There is then no possibility of forging
anything, and the authorizations are all checked only once.

On the subject of objects on remote machines, I believe that the
correct way to do this is to access an object of a "remote access
class", and tell it a remote machine and object identification to
connect to.  Once it is connected, all method calls get passed to the
remote machine.  [This might be a seperate meta-class, just so we can
grab all method calls at one point, while not increasing the overhead
for normal objects.]  Once you terminate access to the local object,
the network connection is dropped, and the remote machines object is
no longer used.

-- David

P.S. I should be available all the time except for a week in July and 
a week in December.
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From ANDREASA@dhhalden.no Tue May 18 16:31:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15436; Tue, 18 May 93 16:31:52 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Tue, 18 May 93 16:31:52 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15576; Tue, 18 May 93 07:25:20 -0700
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <07978-0@fenris.dhhalden.no>; Tue, 18 May 1993 12:01:39 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Tue, 18 May 93 12:01:33 GMT+1
To: moose-programmers@sfu.ca (Moose List)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 18 May 93 12:00:55 +0100
Subject: Re: Beginning Work [djo9][arf8]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <1781C826AF2@sofus.dhhalden.no>
Status: OR

Hello Moosers, hope I get the numbers right:-)

> is Dan Odom
> > Where we still have to get to an agreement is:
> >
> > o How looks a destination address?
> >   Should it look like this: (machine address, object id, method id)
> >   or only like this: (object id, method id)
> >   or like this: (machine address, process id)
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That one.  Each process should have a 'message-handler' object that
> will receive messages and notify the rest of the process.
>
> Kind of like:   if (MsgHandler.ismsg ());  // Check to see if msg. is waiting.
>                 switch (MsgHandler.message)
>                   // etc...

Ooooh, nooo!!! I'm in favour for another way of doing it.
 SupplyMessageSystemCrashFunction (MySystemCrashFunction);
When a system crash comes, the system crash "spy" calls the
"MySystemCrashFunction". Then the system would take care of all message
handling, and the programmer could program, and not think of eartly things
as messages.

Arff



sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From ANDREASA@dhhalden.no Tue May 18 16:29:28 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15372; Tue, 18 May 93 16:29:25 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Tue, 18 May 93 16:29:25 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15517; Tue, 18 May 93 07:24:03 -0700
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <09119-0@fenris.dhhalden.no>; Tue, 18 May 1993 13:04:47 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Tue, 18 May 93 13:04:40 GMT+1
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 18 May 93 13:04:15 +0100
Subject: MUSIC [arf9]
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <1792AA07694@sofus.dhhalden.no>
Status: OR

Hello Moosers

I'm writing a small draft for the GUI part of MUSIC. This contains
the minimum commandset we need, and some things to think about
when implementating it. I don't know if it is a good thing to publish it
for all of you, since only a few of you are interested in this part. But
on the other hand, you are entitled to know.

--------------------------------------------------------
The standard primitives for MUSIC

We must find some sort of greatest common divisor, and I think we'll find
it in the VGA/MCGA system. I have some overall goals that I'll present here,
which I think we all can agree on.
- Vga compability
- Exchangeable gadgets/widgets
- 24 or 8 bit colors
- 3 standard viewports - Pixelated, Vectorbased, PostScriptbased.

About the colors, this is only theoretical, it will work equally good on
4 or 15 or 16bpp. I think it is important to provide several types of
viewports, a wysiwyg program might want to use a PS window/viewport, while
some would rather prefer to use vectors. Any other suggestions?


Now over to the primitives.
---------------------------
Different HW forces us to build an exchangeable layer with code for different
cards. The VGA is only a small part here.

            +------------------+
            | VGA | SVga cards |  <--- HW
            +------------------+
            |  Primitives      |  <--- SW
            +------------------+
            | Gfx - interface  |  <--- SW
            +------------------+

What I'll deal with is the primitives, and of course there are some
minimum requirements.
During my "research", I have found out that we need the following
functions.
A. 1. Change Active/Current Bank
   2. Wait for electron beam vertical retrace
   3. Mode setting
   4. Palette Set

B. 1. Put a pixel
   2. Get a pixel
   3. Move a pixel
   4. Clear screen

In addition we need a function to determine the resolution for the screen.
For a fast GUI we need block functions. I think we should come to an
agreement on what we mean with the word block. It can mean a square, or a
polygon. Maybe we should implement to kind of block functions, square and
polygon. There is a speed advantage using squares, and speed loss making
polygons out of squares:-).
We also need iterative functions.
C. 1. Draw a line
   2. Draw an arc

D. 1. Put a block
   2. Get a block
   3. Move a block
   4. Fill a block

Many cards also have support for special features as short vectors and HW-
sprite(s). I think we should implement these too in the minimum code, and
if a card doesn't support it, it could be supported using other primitives.
I use the XGA specification here as the base for the extras I think should
be standard.
E. 1. HW-cursor/sprite
   2. Short vectors

Each implementation will probably have other functions, but these should
be mandatory. A1-3 are card dependant, while A4 could be the same for
(almost?) all cards, since all of them has a DAC that works the same way. B3
could be discussed, but I think it is a good choice. (Remember how to make
sprites with a ZX81 spectrum:-).

A fast UI should also beware certain commands, such as Jnn, any math-function,
and IN's and OUT's. The time consuming MUL operation could be reduced with
95%. Of course the GUI primitives should be written in assembler (mostly), and
this part could be ready made in a large extent befor the the kernel.
I'll have done some asm. code for some of these commands already, so
interested people can get it, and finish it for their SVGA card. I currently
have oak, ati and paradise here (writing this mail on a VBE compliant box,
but I don't know enough about VBE, so that'll have to wait).
In the figure there is a part called gfx-interface, this part is the
interface for the application writers.


Have a nice day.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From danodom@matt.ksu.ksu.edu Tue May 18 15:41:35 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14323; Tue, 18 May 93 15:41:34 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Tue, 18 May 93 15:41:34 +0200
Received: from matt.ksu.ksu.edu by dmi.ens.fr (5.65c8/ULM-1.0)
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA18802; Tue, 18 May 93 08:43:13 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9305181343.AA18802@matt.ksu.ksu.edu>
Subject: Re:  Beginning Work [djo11]
To: rideau@clipper (Francois-Rene Rideau)
Date: Tue, 18 May 93 8:43:12 CDT
In-Reply-To: <9305180226.AA25579@clipper.ens.fr>; from "Francois-Rene Rideau" at May 18, 93 4:26 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Francois-Rene Rideau Said:

> Well, an object's class is its message handler, isn't it ?

I don't understand what you mean by that.  If you mean that a message
handler will be built in to every class, yes, I think that's the way
to go.

> But what kind of message will the kernel transmit ?

There could be a finite number of messages, like in POSIX.  Have an
integer code for each message, and pass that code.

>> Kind of like:   if (MsgHandler.ismsg ());  // Check to see if msg. is waiting.
> >                 switch (MsgHandler.message)
> >                   // etc...
> uh ?

Know any C++?  MsgHandler.ismsg () calls a function that, presumably,
checks to see if a message is waiting.  MsgHandler.message is a
variable containing the integer code for the variable.

A switch is a bad way to do it, but hey, I was in a hurry :-).

> >> P.S: One for the compiler designer.
> > 
> > Woah!  SINGULAR??!!  Am I the only one interested in the compiler????
> > Geez, I sure hope not.
> >
> > But if I must work alone, I must work alone.  Oh, well.
> > 
> Hey, he was talking about ME, not YOU ! :-)
> More seriously, we're at least two about the compiler issue (I'm preparing
> some post next)

OK.  I assumed he was referring to my statement that it would be hard
to start writing device drivers without a compiler.

We should probably communicate in email and at least start on stuff
like printf ().  When we get the kernel API, the REAL work can begin
(including the writing of the compiler itself).

>Well, I think Dennis should publish his pretty listing requirements; of course
> we can begin coding; BUT let's not forget (1) not to use C/C++ unportable
> hacks (i.e. pointer/integer typecasting, strange unions, etc); (2) let's be
> ready to conform our programs to a new language and/or style to appear; (3)
> let's include at lot of comments, so that anyone in the group can understand
> one another's production;

Especially #3.  The others are minor; because we're writing our own
compiler, we choose what will work on this system and what won't.

> > How's this:  Decide what language we'll use.  I'm in favor of C++, but
> > if you all want something else we'll use something else.  Give me the
> >  name of the language and I'll hammer out an initial spec for the RTL.
> What about Objective C ?

Objective C is fine with me (<-- It Rhymes!).  Didn't Jobs do NExTStep
in OC?

> What about these languages Gary talked about ?

No offense intended to Gary, but I don't know ANYONE who uses any of
those languages.  We want people to be able to use the OS, right?

> What about building our own HLL ?

We could, but it would take forever.

I am still in favor of splitting off in to small subgroups to work on
this thing.  Let the kernel people get the kernel spec out, and then
the rest of us will begin to work on the rest of it (the DD people on
the DDK and DD API, the compiler people on the library API, etc.).

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From dobie.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Tue May 18 23:36:44 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22228; Tue, 18 May 93 23:36:43 +0200
Return-Path: <dobie.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Tue, 18 May 93 23:36:43 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17091; Tue, 18 May 93 14:31:09 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ac17885;
          18 May 93 17:29 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id ab25877;
          18 May 93 21:26 GMT
Received: from sol.cis.udel.edu by dobie.cis.udel.edu id aa01063;
          18 May 93 21:25 GMT
To: Dan Odom <danodom@matt.ksu.ksu.edu>
Cc: Moose List <moose-programmers@sfu.ca>
Subject: Re: Beginning Work [djo9] 
Date: Tue, 18 May 93 17:25:19 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305182125.aa01063@dobie.cis.udel.edu>
Status: OR

In Message <9305172217.AA29740@matt.ksu.ksu.edu> ,
   Dan Odom <danodom@matt.ksu.ksu.edu> wrote:

=>> P.S: One for the compiler designer.
=>
=>Woah!  SINGULAR??!!  Am I the only one interested in the compiler????
=>Geez, I sure hope not.
=>
=>But if I must work alone, I must work alone.  Oh, well.
=>
   I can certainly help out with a compiler, but we haven't yet
established the need for a new compiler (as opposed to adapting
and existing one) or a new langauge.

=>How's this:  Decide what language we'll use.  I'm in favor of C++, but
=>if you all want something else we'll use something else.  Give me the
=>name of the language and I'll hammer out an initial spec for the RTL.
=>
   There are other options, like Sather, and I may have a lead
toward an existing Ellie compiler, so we will have to wait and see.
I would leave C++ as a last option.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From danodom@matt.ksu.ksu.edu Tue May 18 23:41:45 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22324; Tue, 18 May 93 23:41:44 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Tue, 18 May 93 23:41:44 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17460; Tue, 18 May 93 14:37:03 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA15577; Tue, 18 May 93 16:37:31 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9305182137.AA15577@matt.ksu.ksu.edu>
Subject: Re: Beginning Work [dho12]
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Tue, 18 May 93 16:37:30 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <1781C826AF2@sofus.dhhalden.no>; from "Andreas Arff" at May 18, 93 12:00 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Andreas Arff Said:

> Ooooh, nooo!!! I'm in favour for another way of doing it.
>  SupplyMessageSystemCrashFunction (MySystemCrashFunction);
> When a system crash comes, the system crash "spy" calls the
> "MySystemCrashFunction". Then the system would take care of all message
> handling, and the programmer could program, and not think of eartly things
> as messages.

I thought about this, but we're screwed if the programmer isn't
careful about what he puts in the function.

As long as we think we can trust the programmer not to be too
dangerous, this would be OK.

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From dobie.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed May 19 00:24:09 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23021; Wed, 19 May 93 00:24:08 +0200
Return-Path: <dobie.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 19 May 93 00:24:08 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20708; Tue, 18 May 93 15:18:11 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa19700;
          18 May 93 18:10 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa26361;
          18 May 93 22:06 GMT
Received: from sol.cis.udel.edu by dobie.cis.udel.edu id aa01253;
          18 May 93 22:02 GMT
To: David Garfield <david@davgar.arlington.va.us>
Cc: moose-programmers@sfu.ca
Subject: Re: ORG, IPC, pem 05/17/93 [djg22] 
Date: Tue, 18 May 93 18:02:00 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305182202.aa01253@dobie.cis.udel.edu>
Status: OR

In Message <2bf86bed.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>>    Ok, ok, calm down. :-) I can live with synchronous IPC as long
=>> as we have good context switch time and kernel-level multiple
=>> thread support.
=>
=>Well, the big problem with providing only synchronous IPC is that you
=>CANNOT make asynchronous I/O out of it without having a second thread.
=>The standard way in Unix to do I/O reading from two different sources
=>is to make one process reading each source.  Unix now has a kludge
=>called select() that allows a program to identify the descriptors with
=>available I/O, but this relies on the system and process being able to
=>keep up with the I/O.  On a VMS system (with asynchronous I/O), one
=>queues a number of asynchronous I/O calls on each channel, and
=>processes the data after it is transferred to your processes own space
=>and you are notified.  I feel this is a much more satisfactory
=>solution.
=>
   Well, presumably you would want to different things with data
from different sources, so threads would make sense, and if they
are lightweight enough, performance should be ok. I think the main
argument is that object-invocation is basically synchronous, so an
object-oriented operating system should be synchronous.

=>The obvious way to avoid this is to not make the parameter be the
=>object ID.  If Unix had used their equivalent, you would pass inode
=>numbers to read() and write() calls.  The obvious solution is exactly
=>the same that Unix used, you open() the Object and get a process-
=>specific identifier.  There is then no possibility of forging
=>anything, and the authorizations are all checked only once.
=>
   This is certainly one way of doing it, but it adds a lot of
state and complexity to the kernel, which is exactly where not
to put complexity in a microkernel-based system.

=>On the subject of objects on remote machines, I believe that the
=>correct way to do this is to access an object of a "remote access
=>class", and tell it a remote machine and object identification to
=>connect to.  Once it is connected, all method calls get passed to the
=>remote machine.  [This might be a seperate meta-class, just so we can
=>grab all method calls at one point, while not increasing the overhead
=>for normal objects.]  Once you terminate access to the local object,
=>the network connection is dropped, and the remote machines object is
=>no longer used.
=>
   A remote access object is a good idea, but we shouldn't use a
connection-oriented protocol to do the job of an RPC. We can also
implement TCP/IP, SNA, and Vines objects if we want.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dmarer@td2cad.intel.com Wed May 19 01:38:29 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23965; Wed, 19 May 93 01:38:28 +0200
Return-Path: <dmarer@td2cad.intel.com>
Received-Date: Wed, 19 May 93 01:38:28 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from hermes.intel.com by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26335; Tue, 18 May 93 16:33:55 -0700
Received: from td2cad.intel.com by hermes.intel.com (5.65/10.0i); Tue, 18 May 93 16:33:53 -0700
Received: by td2cad (5.57/10.0i); Tue, 18 May 93 16:37:59 -0700
Received: by iws804.intel.com (4.1/SCDT-NCR)
	id AA08989; Tue, 18 May 93 16:33:30 PDT
Message-Id: <9305182333.AA08989@iws804.intel.com>
Subject: Re: ORG, IPC, pem 05/17/93 [djg22] [dpm11]
To: moose-programmers@sfu.ca (Moose Kernel Project)
Date: Tue, 18 May 93 16:33:28 PDT
From: Dennis Marer <dmarer@iws804.intel.com>
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Forwarded message:
> From: "Gary D. Duzan" <duzan@udel.edu>
> In Message <2bf86bed.davgar@davgar.arlington.va.us> ,
>    David Garfield <david@davgar.arlington.va.us> wrote:
> 
> =>Well, the big problem with providing only synchronous IPC is that you
> =>CANNOT make asynchronous I/O out of it without having a second thread.
> =>The standard way in Unix to do I/O reading from two different sources
> =>is to make one process reading each source.  Unix now has a kludge
> =>called select() that allows a program to identify the descriptors with
> =>available I/O, but this relies on the system and process being able to
> =>keep up with the I/O.  On a VMS system (with asynchronous I/O), one
> =>queues a number of asynchronous I/O calls on each channel, and
> =>processes the data after it is transferred to your processes own space
> =>and you are notified.  I feel this is a much more satisfactory
> =>solution.
> =>
>    Well, presumably you would want to different things with data
> from different sources, so threads would make sense, and if they
> are lightweight enough, performance should be ok. I think the main
> argument is that object-invocation is basically synchronous, so an
> object-oriented operating system should be synchronous.

I also think threads make sense.  As far as being lightweight, this too is
achievable.  Memory consumption (from a programmers perspective) is close
to nothing per thread, and task switching time could also be reduced by
having a more lightweight switch to go between threads in a process.


> =>The obvious way to avoid this is to not make the parameter be the
> =>object ID.  If Unix had used their equivalent, you would pass inode
> =>numbers to read() and write() calls.  The obvious solution is exactly
> =>the same that Unix used, you open() the Object and get a process-
> =>specific identifier.  There is then no possibility of forging
> =>anything, and the authorizations are all checked only once.
> =>
>    This is certainly one way of doing it, but it adds a lot of
> state and complexity to the kernel, which is exactly where not
> to put complexity in a microkernel-based system.

Ah, I still don't believe in the kernel is where IPC should go - support for
IPC, yes (shared memory, etc) but not the IPC itself.  Maybe.  I dunno.


> =>On the subject of objects on remote machines, I believe that the
> =>correct way to do this is to access an object of a "remote access
> =>class", and tell it a remote machine and object identification to
> =>connect to.  Once it is connected, all method calls get passed to the
> =>remote machine.  [This might be a seperate meta-class, just so we can
> =>grab all method calls at one point, while not increasing the overhead
> =>for normal objects.]  Once you terminate access to the local object,
> =>the network connection is dropped, and the remote machines object is
> =>no longer used.
> =>
>    A remote access object is a good idea, but we shouldn't use a
> connection-oriented protocol to do the job of an RPC. We can also
> implement TCP/IP, SNA, and Vines objects if we want.

In OOP terms, creating an instance of a "remote access class" establishes
the connection (by calling its constructor); when it is destroyed, it calls
its destructor to terminate the connection.

I use the term "connection" loosely - I don't mean to imply any protocol here.
Ideally, network connections should be possible independent of the protocol.
That's ideally...


Laterz.

	Dennis


From uunet.UU.NET!davgar!davgar.arlington.va.us!david Wed May 19 07:18:21 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04159; Wed, 19 May 93 07:18:20 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Wed, 19 May 93 07:18:20 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08318; Tue, 18 May 93 22:14:06 -0700
Received: from spool.uu.net (via localhost) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA27874; Wed, 19 May 93 01:14:04 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 011321.24482; Wed, 19 May 1993 01:13:21 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Wed, 19 May 1993 00:52:28 EDT
Date:      Wed, 19 May 1993 00:52:25 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bf9bd0e.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject:   Re: ORG, IPC, pem 05/17/93 [djg22] [dpm11] [djg23]
Status: OR

"> " is Dennis Marer
">> " is Gary D. Duzan
">>=>" is David Garfield (me)

>>=>Well, the big problem with providing only synchronous IPC is that you
>>=>CANNOT make asynchronous I/O out of it without having a second thread.
>>=>The standard way in Unix to do I/O reading from two different sources
>>=>is to make one process reading each source.  Unix now has a kludge
>>=>called select() that allows a program to identify the descriptors with
>>=>available I/O, but this relies on the system and process being able to
>>=>keep up with the I/O.  On a VMS system (with asynchronous I/O), one
>>=>queues a number of asynchronous I/O calls on each channel, and
>>=>processes the data after it is transferred to your processes own space
>>=>and you are notified.  I feel this is a much more satisfactory
>>=>solution.
>>=>
>>    Well, presumably you would want to different things with data
>> from different sources, so threads would make sense, and if they
>> are lightweight enough, performance should be ok. I think the main
>> argument is that object-invocation is basically synchronous, so an
>> object-oriented operating system should be synchronous.

"basically synchronous", but only when you do simple stuff.  More 
complicated stuff requires more advanced techniques.  

> I also think threads make sense.  As far as being lightweight, this too is
> achievable.  Memory consumption (from a programmers perspective) is close
> to nothing per thread, and task switching time could also be reduced by
> having a more lightweight switch to go between threads in a process.

Agreed.  These threads need only grab a copy of the loaded image's 
process space, add a stack, copy parameters, and run.  

>>=>The obvious way to avoid this is to not make the parameter be the
>>=>object ID.  If Unix had used their equivalent, you would pass inode
>>=>numbers to read() and write() calls.  The obvious solution is exactly
>>=>the same that Unix used, you open() the Object and get a process-
>>=>specific identifier.  There is then no possibility of forging
>>=>anything, and the authorizations are all checked only once.
>>=>
>>    This is certainly one way of doing it, but it adds a lot of
>> state and complexity to the kernel, which is exactly where not
>> to put complexity in a microkernel-based system.

Protection is REQUIRED in an operating system.  If we don't have it, 
we get a system known as DOS.  Protection includes a necessity for the 
OS to protect objects from unauthorized processes.  Any other 
suggestions on this that are proof against forgery?  

> Ah, I still don't believe in the kernel is where IPC should go - support for
> IPC, yes (shared memory, etc) but not the IPC itself.  Maybe.  I dunno.

If IPC is not in the kernel, how do you communicate with the IPC?

>>=>On the subject of objects on remote machines, I believe that the
>>=>correct way to do this is to access an object of a "remote access
>>=>class", and tell it a remote machine and object identification to
>>=>connect to.  Once it is connected, all method calls get passed to the
>>=>remote machine.  [This might be a seperate meta-class, just so we can
>>=>grab all method calls at one point, while not increasing the overhead
>>=>for normal objects.]  Once you terminate access to the local object,
>>=>the network connection is dropped, and the remote machines object is
>>=>no longer used.
>>=>
>>    A remote access object is a good idea, but we shouldn't use a
>> connection-oriented protocol to do the job of an RPC. We can also
>> implement TCP/IP, SNA, and Vines objects if we want.
>
> In OOP terms, creating an instance of a "remote access class" establishes
> the connection (by calling its constructor); when it is destroyed, it calls
> its destructor to terminate the connection.
>
> I use the term "connection" loosely - I don't mean to imply any protocol here.
> Ideally, network connections should be possible independent of the protocol.
> That's ideally...

Well, connection may be used loosely here, but in some ways, a 
connection-oriented protocol (like TCP) is a GOOD thing.  There are 
things that will work out much easier if it is not necessary to 
establish one or more objects, connect them appropriately, use them, 
and disconnect WITH EVERY CALL.  I admit that the RPC style makes 
sense for something as simple as a disk access (NFS), but not for 
everything.  Can you imagine trying to access a remote Vines 
connection-oriented connection over anything other than a connection-
oriented protocol?  

-- David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Wed May 19 07:18:15 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04154; Wed, 19 May 93 07:18:14 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Wed, 19 May 93 07:18:14 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08321; Tue, 18 May 93 22:14:09 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA11929; Wed, 19 May 93 01:14:07 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 011321.24487; Wed, 19 May 1993 01:13:21 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Wed, 19 May 1993 01:06:20 EDT
Date:      Wed, 19 May 1993 01:06:16 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bf9c04d.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject:   Re: Beginning Work [djo9][arf8] [djg24]
Status: OR

"> " is Andreas Arff
> > is Dan Odom
> > > Where we still have to get to an agreement is:
> > >
> > > o How looks a destination address?
> > >   Should it look like this: (machine address, object id, method id)
> > >   or only like this: (object id, method id)
> > >   or like this: (machine address, process id)
> >       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > That one.  Each process should have a 'message-handler' object that
> > will receive messages and notify the rest of the process.
> >
> > Kind of like:   if (MsgHandler.ismsg ());  // Check to see if msg. is waiting.
> >                 switch (MsgHandler.message)
> >                   // etc...
>
> Ooooh, nooo!!! I'm in favour for another way of doing it.
>  SupplyMessageSystemCrashFunction (MySystemCrashFunction);
> When a system crash comes, the system crash "spy" calls the
> "MySystemCrashFunction". Then the system would take care of all message
> handling, and the programmer could program, and not think of eartly things
> as messages.

Agreed.

Well, two problems with this.  The first is that you actually want a
function that you tell what function to call and when to call it.
That way there is one system function instead of one per message.  The
second problem is that this should for the most part be fed to the
IPC/ROI service provider (which I think is the kernel) all at once in
a table (thus a second function), and that image loading should
automatically feed any preconfigured entry points to the IPC service
provider.  This last technique should be used for 99+% of all
messages.

Well, third problem, but only with the example.  If the system is
crashing, you should not be able to notify anyone, because if you are
stable enough to notify people, you are stable enough not to crash.
Notify of System Shutdown maybe, power failure maybe (some machines
have hardware support for power failure), but not crash.

>
> Arff

-- David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From mueller@sc.ZIB-Berlin.DE Wed May 19 13:51:30 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA11521; Wed, 19 May 93 13:51:28 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Wed, 19 May 93 13:51:28 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17068; Wed, 19 May 93 04:46:35 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA11684; Wed, 19 May 93 13:46:26 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA10256; Wed, 19 May 93 13:46:26 +0200
Date: Wed, 19 May 93 13:46:26 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305191146.AA10256@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Word Chat
Status: OR

Hi,

Fare said the following to the terms 'kernel' and 'nucleus':

... kernel if you accept the "nucleus" terminology, but both words have 
exactly the same meaning ...

That's for the one with the glossary. In OS history there was a trend from
monolithical to mikro-kernel based OS. Then the microkernel grew and grew
and there were people, who thought the term 'micro' used for a kernel with more
then 100.000 lines of code (no comments) isn't ok. And they create a new
kernel with 10.000 lines of code and call it 'nano'-kernel, which should
express that this is a real small kernel. And then others came, saying, that
this is still to big. And then there was the NUCLEUS within the kernel and all-
together will fit within 1000 lines of code.
And though the semantic of 'kernel' and 'nucleus' seems to be the same, there's
still a syntactical difference ...

Is there anyone working on a glossary?

Peter

From mueller@sc.ZIB-Berlin.DE Wed May 19 14:18:25 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12538; Wed, 19 May 93 14:18:24 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Wed, 19 May 93 14:18:24 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17450; Wed, 19 May 93 05:13:19 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA11844; Wed, 19 May 93 14:13:15 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA10314; Wed, 19 May 93 14:13:14 +0200
Date: Wed, 19 May 93 14:13:14 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305191213.AA10314@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: ORG, IPC [pem01]
Status: OR

Hi,

I want to comment to the main design decision, whether to use synchronous or
asynchronous communication primitives. As Moose will be an oo-os it should be
possible, to provide a basic communication object (note: the object is
part of the kernel). Within an application one can create an instance of that
object, say, COMMUNICATION, something like this:

main() {
  COMMUNICATION comm;
  MESSAGE msg;
  ADDRESS addr1, addr2;

  addr1 = ...             // Initialize destination address
  comm.send(addr1, msg);  // Send the message

  // do something

  addr1 = ...            // Initialize source address  
  comm.receive(addr1, msg, addr2);
  comm.reply(addr2);

  // do something
} 

(Before you start to flame me for these implementation-details, please read on.
I used it, because it's very heavy to draw in ascii nice figures. And I think
with this flow of control I can illustrate what I mean ... and yes! I used 
C++ because I then know what I'm writing. :-)

The program above demonstrates the lowest level of IPC. A "normal" user will
not see this in this way, he will use ROI, where a method of a remote object
is directly invoked. Nonetheless, ROI must be mapped to such IPC primitives
(which we call "stubs" or communication objects, as above)

Now my idea: I'm definitely convinced that synchronous IPC is the right choice.
(But: there some of you who are not as much convinced as I am. Well, well. :-)
In my opinion, using very lightweight processes (threads) will give us the
possibility to provide *asynchronous* IPC outside the kernel.

I think, both IPC versions can be used with the following interface, namely

	send, receive, reply

If we can build the IPC primitives within an object, it should be possible,
to create two (2!) kernels: one synchronous and one asynchronous. As the 
interface should be the same, there should be no problem to the application
layer and to the lower layers as well. We can then compare these two or
even offer both.

But I still want to defense my position: Asynchronous IPC will lead to an
enormous communication overhead. There's buffer management, and still the
synchronization problem, when all buffers are in use. I don't want to see
this overhead within a new OS-kernel. Note, that this overhead leads to a
performance lost. If we really want to create a fast system, we should
provide synchronous IPC within the kernel and offer asynchronous IPC as
an add-on.

David wrote:

> Well, the big problem with providing only synchronous IPC is that you
> CANNOT make asynchronous I/O out of it without having a second thread.
> The standard way in Unix to do I/O reading from two different sources
> is to make one process reading each source.  Unix now has a kludge
> called select() that allows a program to identify the descriptors with
> available I/O, but this relies on the system and process being able to
> keep up with the I/O.  On a VMS system (with asynchronous I/O), one
> queues a number of asynchronous I/O calls on each channel, and
> processes the data after it is transferred to your processes own space
> and you are notified.  I feel this is a much more satisfactory
> solution.

Actually, I think the VMS IPC is a third form of I/O, though it's
asynchronous. If I understand it right, it is possible, to direct an I/O
to write into a pre-defined data space within my own process. I suppose,
there's a call like

	receive(chan, to_memory)

where 'to_memory' points to (big enough) data space. The OS waits for data
sent on 'chan' and relay the data to the indicated data space. After a 
sender says, "End Of Send" a notification signal is transferred.

In my opinion this differs from my use of the term 'asynchronous' IPC. Here
a sender is not blocked, because data is immediately transferred into a 
system internal buffer space. On the other hand, a receiver might be blocked,
if there's no data available. (In the above case a receiver is not blocked.)
(Or am I mixing things up?)

Nevertheless, if we do agree that we can provide each form of asynchronous
IPC by an additional buffer server this VMS asynchronous method can be simply
provided: Create a buffer server, who takes such an interface, and who 
will be able to write to a process' data space. Then notification is done by
invoking a method. The easiest way would be within this method, to set a 
flag that data is ready to be used. 

Dennis is '>', David is '>>':

> Ah, I still don't believe in the kernel is where IPC should go - support
> for IPC, yes (shared memory, etc) but not the IPC itself. Maybe. I dunno.
>
>> If IPC is not in the kernel, how do you communicate with the IPC?

Nice answer. (I still want to see the chance to distribute Moose over several
machines. Then their must be mechanisms within the kernel to communicate
to the outside of a machine ... BTW: then each machine should use its own
memory, leading to distributed memory. Virtual shared memory with several 
machines isn't useful ... (s. discussion in comp.os.research)).

I have to go now, stay tuned for more PEM News,

Peter
 

From bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed May 19 20:40:00 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20816; Wed, 19 May 93 20:39:59 +0200
Return-Path: <bofur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 19 May 93 20:39:59 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08156; Wed, 19 May 93 11:36:54 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa24733;
          19 May 93 14:34 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa13626;
          19 May 93 18:30 GMT
Received: from sol.cis.udel.edu by bofur.cis.udel.edu id aa06628;
          19 May 93 18:28 GMT
To: David Garfield <david@davgar.arlington.va.us>
Cc: Moose Project <moose-programmers@sfu.ca>
Subject: Re: ORG, IPC, pem 05/17/93 [djg22] [dpm11] [djg23] 
Date: Wed, 19 May 93 14:27:49 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305191828.aa06628@bofur.cis.udel.edu>
Status: OR

In Message <2bf9bd0e.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>"> " is Dennis Marer
=>">> " is Gary D. Duzan
=>">>=>" is David Garfield
=>
=>>>    Well, presumably you would want to different things with data
=>>> from different sources, so threads would make sense, and if they
=>>> are lightweight enough, performance should be ok. I think the main
=>>> argument is that object-invocation is basically synchronous, so an
=>>> object-oriented operating system should be synchronous.
=>
=>"basically synchronous", but only when you do simple stuff.  More 
=>complicated stuff requires more advanced techniques.  
=>
   Well, if we use Ellie, we can always use future return objects. :-)

=>> I also think threads make sense.  As far as being lightweight, this too is
=>> achievable.  Memory consumption (from a programmers perspective) is close
=>> to nothing per thread, and task switching time could also be reduced by
=>> having a more lightweight switch to go between threads in a process.
=>
=>Agreed.  These threads need only grab a copy of the loaded image's 
=>process space, add a stack, copy parameters, and run.  
=>
   Sounds like we are going to do threads. Now the trick is to do
it portably and efficiently. We may also want to consider what sort
of protection among threads is required/possible.

=>>>    This is certainly one way of doing it, but it adds a lot of
=>>> state and complexity to the kernel, which is exactly where not
=>>> to put complexity in a microkernel-based system.
=>
=>Protection is REQUIRED in an operating system.  If we don't have it, 
=>we get a system known as DOS.  Protection includes a necessity for the 
=>OS to protect objects from unauthorized processes.  Any other 
=>suggestions on this that are proof against forgery?  
=>
   Very sparse address spaces and encryption can be used, as in the
Amoeba system. Sparse addressing (i.e. say, a 128-bit number with
object numbers scattered around in it) may be sufficient for a local
system.

=>If IPC is not in the kernel, how do you communicate with the IPC?
=>
   Quite so. Unless the hardware has some IPC support, it has to
be in the kernel. The 386 seems to be one of the exceptions in that
the gates (if I remember correctly) can be used here. Other machines
aren't so fortunate. Regardless, it needs to be in the kernel API
whether it actually goes to the kernel or not.

=>Well, connection may be used loosely here, but in some ways, a 
=>connection-oriented protocol (like TCP) is a GOOD thing.  There are 
=>things that will work out much easier if it is not necessary to 
=>establish one or more objects, connect them appropriately, use them, 
=>and disconnect WITH EVERY CALL.  I admit that the RPC style makes 
=>sense for something as simple as a disk access (NFS), but not for 
=>everything.  Can you imagine trying to access a remote Vines 
=>connection-oriented connection over anything other than a connection-
=>oriented protocol?  
=>
   Quite so. So are we going to implement StreetTalk for Moose too? :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From uunet.UU.NET!davgar!davgar.arlington.va.us!david Thu May 20 06:55:20 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04472; Thu, 20 May 93 06:55:19 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Thu, 20 May 93 06:55:19 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA16761; Wed, 19 May 93 21:53:07 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA15635; Thu, 20 May 93 00:53:03 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 005133.20808; Thu, 20 May 1993 00:51:33 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Thu, 20 May 1993 00:44:37 EDT
Date:      Thu, 20 May 1993 00:44:32 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2bfb0cb6.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca (Moose Project)
Status: OR

Subject: IPC - synchronous/asynchronous etc... [djg25]

"> " is Peter Mueller
> I want to comment to the main design decision, whether to use synchronous or
> asynchronous communication primitives. As Moose will be an oo-os it should be
> possible, to provide a basic communication object (note: the object is
> part of the kernel). Within an application one can create an instance of that
> object, say, COMMUNICATION, something like this:
> 
> main() {
>   COMMUNICATION comm;
>   MESSAGE msg;
>   ADDRESS addr1, addr2;
> 
>   addr1 = ...             // Initialize destination address
>   comm.send(addr1, msg);  // Send the message
> 
>   // do something
> 
>   addr1 = ...            // Initialize source address  
>   comm.receive(addr1, msg, addr2);
>   comm.reply(addr2);
> 
>   // do something
> } 

Assuming you are talking about doing communications with a device 
object, like a serial port COMMUNICATIONS object, then it can look 
like this: 

MESSAGE msg_connect, msg_send, msg_receive; // constant values
main() {
  COMMUNICATION comm;
  ADDRESS addr;
  char output_data[1024];
  char input_data[1024];

  addr1 = ...                         // Initialize destination address
  comm.send(msg_connect, addr);       // establish the connection
  comm.send(msg_send, output_data);   // Send some data

  // do something

  comm.send(msg_receive, input_data); // Send some data

  // do something
}

> The program above demonstrates the lowest level of IPC. A "normal" user will
> not see this in this way, he will use ROI, where a method of a remote object
> is directly invoked. Nonetheless, ROI must be mapped to such IPC primitives
> (which we call "stubs" or communication objects, as above)
> 
> Now my idea: I'm definitely convinced that synchronous IPC is the right choice.
> (But: there some of you who are not as much convinced as I am. Well, well. :-)
> In my opinion, using very lightweight processes (threads) will give us the
> possibility to provide *asynchronous* IPC outside the kernel.
> 
> I think, both IPC versions can be used with the following interface, namely
> 
>         send, receive, reply

There are two basic models of communications.  

In one model one person sends and the other person receives.  In this 
model, communication is basically uni-directional.  You can do it bi-
directional, but the directions are totally independent.  This model 
is basically synchronous, and I am not sure how you make it 
asynchronous, other than having notification that you can receive 
something.  

In the other model, one person says do_X, and the other responds 
I_did_X.  In this model, communications is basically bi-directional, 
in a master-slave mode.  One person can say do_X or do_Y, and the 
other can only answer that it did it or not.  This model is easily 
either synchronous or asynchronous, from the senders point of view.  
In synchronous mode it is equivalent to a function call.  In 
asynchronous mode, the originator at some later time learns that the 
other guy is finished.  The thing that goes weird in this model, is 
that the receiver basically gets started out of the blue to do 
something, and can have multiple threads running all at once, but that 
is why we're building an OS.  

For use in Moose, the second makes more sense to me than the first, as 
it conforms nicely to a message-invokation model.  In the case of 
Moose, do_X could be "write this data out" or "read data and put it 
inn the buffer I gave you".  The send can then either tell how and 
where it is to be notified of completion, or receive back a tag that 
it can wait for the completion of.  

> If we can build the IPC primitives within an object, it should be possible,
> to create two (2!) kernels: one synchronous and one asynchronous. As the 
> interface should be the same, there should be no problem to the application
> layer and to the lower layers as well. We can then compare these two or
> even offer both.

Now you want two(!) kernels!?!?  Do you think we are masocists?  I 
mean, they can't be the same OS.  They would require two completely 
different sets of support software ...

[...]
> David wrote:
> 
[...]
> >                        On a VMS system (with asynchronous I/O), one
> > queues a number of asynchronous I/O calls on each channel, and
> > processes the data after it is transferred to your processes own space
> > and you are notified.  I feel this is a much more satisfactory
> > solution.
> 
> Actually, I think the VMS IPC is a third form of I/O, though it's
> asynchronous. If I understand it right, it is possible, to direct an I/O
> to write into a pre-defined data space within my own process. I suppose,
> there's a call like
> 
> 	receive(chan, to_memory)
> 
> where 'to_memory' points to (big enough) data space. The OS waits for data
> sent on 'chan' and relay the data to the indicated data space. After a 
> sender says, "End Of Send" a notification signal is transferred.

The VMS low level IPC is through an interface name SYS$QIO().  You 
give it an open channel (VMS's equivalent to a Unix file descriptor), 
a message number with modifiers, three different forms of return 
status values, and six arbitrary parameters.  The receiving program, 
known as a device driver, may process the message in any way it 
chooses.  It may use all six arbitrary parameters in any way it 
chooses, either as numbers, pointers to data to be read, or pointers 
to data to be written (though if it wishes to defer the activity 
pending a hardware device's activity, it can only have one pointer, 
and it must tell at compile time if the data is to be copied to/from a 
system buffer [Buffered I/O], or locked in memory for direct access by 
the device driver [Direct I/O]).  Within VMS, devices are categorized 
into classes that all respond to the same basic set of messages in the 
same way, so that you will know that if you have a class 1 (disk) 
device, you can (if you have the privilege to send the message in 
question) send messages to do physical read and physical write 
operations and expect them to work.

> In my opinion this differs from my use of the term 'asynchronous' IPC. Here
> a sender is not blocked, because data is immediately transferred into a 
> system internal buffer space. On the other hand, a receiver might be blocked,
> if there's no data available. (In the above case a receiver is not blocked.)
> (Or am I mixing things up?)
> 
> Nevertheless, if we do agree that we can provide each form of asynchronous
> IPC by an additional buffer server this VMS asynchronous method can be simply
> provided: Create a buffer server, who takes such an interface, and who 
> will be able to write to a process' data space. Then notification is done by
> invoking a method. The easiest way would be within this method, to set a 
> flag that data is ready to be used. 

Run that by me again....

=============================================================================

"> " is Gary D. Duzan
">=>" is David Garfield (me)
">=>> " is Dennis Marer
">=>>> " is Gary D. Duzan

>=>>>    Well, presumably you would want to different things with data
>=>>> from different sources, so threads would make sense, and if they
>=>>> are lightweight enough, performance should be ok. I think the main
>=>>> argument is that object-invocation is basically synchronous, so an
>=>>> object-oriented operating system should be synchronous.
>=>
>=>"basically synchronous", but only when you do simple stuff.  More 
>=>complicated stuff requires more advanced techniques.  
>=>
>   Well, if we use Ellie, we can always use future return objects. :-)

Sounds like its just a language construct for asynchrous messages. :-)

>=>> I also think threads make sense.  As far as being lightweight, this too is
>=>> achievable.  Memory consumption (from a programmers perspective) is close
>=>> to nothing per thread, and task switching time could also be reduced by
>=>> having a more lightweight switch to go between threads in a process.
>=>
>=>Agreed.  These threads need only grab a copy of the loaded image's 
>=>process space, add a stack, copy parameters, and run.  
>=>
>   Sounds like we are going to do threads. Now the trick is to do
>it portably and efficiently. We may also want to consider what sort
>of protection among threads is required/possible.

I think we won't have much choice, but it may be reasonable for a 
image to specify that only one thread may be active at any time, all 
others must wait to get in (subject to rule changes to prevent deadlock).

>=>>>    This is certainly one way of doing it, but it adds a lot of
>=>>> state and complexity to the kernel, which is exactly where not
>=>>> to put complexity in a microkernel-based system.
>=>
>=>Protection is REQUIRED in an operating system.  If we don't have it, 
>=>we get a system known as DOS.  Protection includes a necessity for the 
>=>OS to protect objects from unauthorized processes.  Any other 
>=>suggestions on this that are proof against forgery?  
>=>
>   Very sparse address spaces and encryption can be used, as in the
>Amoeba system. Sparse addressing (i.e. say, a 128-bit number with
>object numbers scattered around in it) may be sufficient for a local
>system.

Even if you do pick them at random in a sparse address, you are only 
getting good chances of preventing forgery, not proof.  Remember, if 
the OS is not protected (i.e. PROOF) against the applications, any 
application can trash the OS.  We call this an unprotected operating 
system.  DOS is unprotected.  

>=>If IPC is not in the kernel, how do you communicate with the IPC?
>=>
>   Quite so. Unless the hardware has some IPC support, it has to
>be in the kernel. The 386 seems to be one of the exceptions in that
>the gates (if I remember correctly) can be used here. Other machines
>aren't so fortunate. Regardless, it needs to be in the kernel API
>whether it actually goes to the kernel or not.

All CPUs with multiple protection levels will have a method for a user 
level program to invoke something at a higher protection level, and 
pass some sort of parameter.  The unusual part of the 386 is that the 
parameter is that any of several calls can be used.  Most hardwares 
just let you pass an n-bit constant.

>=>Well, connection may be used loosely here, but in some ways, a 
>=>connection-oriented protocol (like TCP) is a GOOD thing.  There are 
>=>things that will work out much easier if it is not necessary to 
>=>establish one or more objects, connect them appropriately, use them, 
>=>and disconnect WITH EVERY CALL.  I admit that the RPC style makes 
>=>sense for something as simple as a disk access (NFS), but not for 
>=>everything.  Can you imagine trying to access a remote Vines 
>=>connection-oriented connection over anything other than a connection-
>=>oriented protocol?  
>=>
>   Quite so. So are we going to implement StreetTalk for Moose too? :-)

If you can come up with a useful protocol and if failure to provide an 
implementation for the protocol will result in different people 
writing different implementation for it, then we need to provide an 
implementation as part of the original development.  At this time, 
TCP/IP fits the bill, as do SCSI hard disks, and MFM/ESDI/IDE hard 
disks, and VGA and SVGA displays.  Other protocols and interfaces may 
also qualify.  

=============================================================================

Sorry about the length, but it seemed to make sense to put the 
messages together since they where both based on variants off one 
original message, about the same basic topic, and I it didn't seem 
right to cut much.

David

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Thu May 20 17:01:12 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12018; Thu, 20 May 93 17:01:08 +0200
Return-Path: <nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Thu, 20 May 93 17:01:08 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28711; Thu, 20 May 93 07:56:43 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa08269;
          20 May 93 10:51 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa29460;
          20 May 93 14:47 GMT
Received: from sol.cis.udel.edu by nori.cis.udel.edu id aa17892;
          20 May 93 14:47 GMT
To: David Garfield <david@davgar.arlington.va.us>
Cc: Moose Project <moose-programmers@sfu.ca>
Subject: Re: 
Date: Thu, 20 May 93 10:46:56 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305201447.aa17892@nori.cis.udel.edu>
Status: OR

In Message <2bfb0cb6.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>> If we can build the IPC primitives within an object, it should be possible,
=>> to create two (2!) kernels: one synchronous and one asynchronous. As the 
=>> interface should be the same, there should be no problem to the application
=>> layer and to the lower layers as well. We can then compare these two or
=>> even offer both.
=>
=>Now you want two(!) kernels!?!?  Do you think we are masocists?  I 
=>mean, they can't be the same OS.  They would require two completely 
=>different sets of support software ...
=>
   Yes, this would be bad. IPC semantics need to be consistent.

=>"> " is Gary D. Duzan
=>">=>" is David Garfield (me)
=>">=>> " is Dennis Marer
=>">=>>> " is Gary D. Duzan

=>>   Well, if we use Ellie, we can always use future return objects. :-)
=>
=>Sounds like its just a language construct for asynchrous messages. :-)
=>
   The call is always synchronous, but in the future case, the return
is asynchronous. Accessing a future object state results in what
amounts to a synchronous call that returns the state.

=>I think we won't have much choice, but it may be reasonable for a 
=>image to specify that only one thread may be active at any time, all 
=>others must wait to get in (subject to rule changes to prevent deadlock).
=>
   The Ellie language has a neat idea called a dynamic interface.
An object itself may determine which methods may be accessed at a
given time, providing for mutual exclusion. We might adapt the idea
for Moose objects.
   If I seem to have a slightly odd view of objects lately, it is
probably because I have Ellie on the brain. It *is* a cool language,
though. Did anyone get around to reading the papers on it?

=>>   Very sparse address spaces and encryption can be used, as in the
=>>Amoeba system. Sparse addressing (i.e. say, a 128-bit number with
=>>object numbers scattered around in it) may be sufficient for a local
=>>system.
=>
=>Even if you do pick them at random in a sparse address, you are only 
=>getting good chances of preventing forgery, not proof.  Remember, if 
=>the OS is not protected (i.e. PROOF) against the applications, any 
=>application can trash the OS.  We call this an unprotected operating 
=>system.  DOS is unprotected.  
=>
   And I suppose you prove the correctness of all the programs you
write, too. :-) If it is going to take 2 years to try addresses at
random to get a hit, that may be good enough. There certainly needs
to be memory protection between objects, between objects and the OS,
and between objects and the hardware. I doubt we would ever get C-2
security certification, anyway, and most users don't need inordinate
levels of security.
   Also "DOS implies unprotected" is not equivalent to "all that is
unprotected is DOS". Protection is a relative thing. Is your machine
protected against my flipping the power switch? Openning the case and
installing a bus tap? Monitoring you serial port or network connection?
Sending you tons of annoying Email? :-)

=>>   Quite so. Unless the hardware has some IPC support, it has to
=>>be in the kernel. The 386 seems to be one of the exceptions in that
=>>the gates (if I remember correctly) can be used here. Other machines
=>>aren't so fortunate. Regardless, it needs to be in the kernel API
=>>whether it actually goes to the kernel or not.
=>
=>All CPUs with multiple protection levels will have a method for a user 
=>level program to invoke something at a higher protection level, and 
=>pass some sort of parameter.  The unusual part of the 386 is that the 
=>parameter is that any of several calls can be used.  Most hardwares 
=>just let you pass an n-bit constant.
=>
   Right, but I was looking at a feature of the 386 (I forget which)
that would allow direct, secure calls between segments using normal
function calls, not going through the kernel or anything else.

=>>   Quite so. So are we going to implement StreetTalk for Moose too? :-)
=>
=>If you can come up with a useful protocol and if failure to provide an 
=>implementation for the protocol will result in different people 
=>writing different implementation for it, then we need to provide an 
=>implementation as part of the original development.  At this time, 
=>TCP/IP fits the bill, as do SCSI hard disks, and MFM/ESDI/IDE hard 
=>disks, and VGA and SVGA displays.  Other protocols and interfaces may 
=>also qualify.  
=>
   I see no reason to provide TCP/IP before releasing a working
package. Certainly we must support standard hardware on supported
platforms. We would probably want to have some sort of
coordination effort among those who would build services and
applications on Moose.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri May 21 02:17:43 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA21376; Fri, 21 May 93 02:17:42 +0200
Return-Path: <ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 21 May 93 02:17:42 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from udel.edu (louie.udel.edu) by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sol.cis.udel.edu by louie.udel.edu id aa29248;
          20 May 93 20:16 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa06331; 21 May 93 0:11 GMT
Received: from sol.cis.udel.edu by ori.cis.udel.edu id aa19915;
          21 May 93 0:10 GMT
To: Francois-Rene Rideau <rideau@clipper>
Cc: All the happy Moosers ! <moose-programmers@sfu.ca>
Subject: Re: Bases [far34] 
Date: Thu, 20 May 93 20:09:55 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305210010.aa19915@ori.cis.udel.edu>
Status: OR

In Message <9305172238.AA23280@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=> Well, here is I think the main points we MUST agree before we can
=>begin coding what we call MOOSE (but we already can begin coding
=>IO drivers and suches).
=>
   Not necessarily, if drivers are implemented like normal objects.

=>SPECS
=>~~~~~
=>
=>agreements
=>~~~~~~~~~~
=>a) MOOSE is "OO" (see Unknown, a))

   Yeah, whatever that means.

=>b) we'll develop a generic UI (user interface), that will
=>specialize/extend into a TUI (Text UI) and a GUI (Graphical).

   Fair enough.

=>Unknown
=>~~~~~~~
=>
=>Questions:
=>@) What will we do that will be the same as or different from
=>other systems, currently existing or being developped ?

   I think it is fair to say that there will be no single feature
that won't have been implemented in some other system. The only
real innovation I think we can expect is in our particular
combination of features and overall system structure.

=>a) What does OO means for an OS ; i.e. what do we mean by "object" ?

   An object is a combination of state, code, and interface. Threads
execute the code, and there may be more that one thread executing on
one or more method. Objects are medium to large-sized from the system
level, though larger objects may manage smaller objects, which can
be addressed like the larger ones.

=>b) How light will our basic objects/threads/tasks/processes be ?

   As light as they can be without giving up inter-object
protection.

=>c) What kind of typing/checking will the kernel/base system include,
=>if any ?

   As I've said in the past, types are a mess. We might want to
attach type information with each call and have the called object
(or the kernel) check the information. We could limit passed
types to a set of standard types, building up more complex ones
from there, or maybe have a complex type server. This adds a lot
of additional overhead to building a message. Alternatively, we
could provide a system for callers to determine the type of
object method interfaces and rely on sanity checks in the
destination object. I would suggest the latter, since for the
most part data is data, and nonsense calls would generate
nonsense results, and sanity checks could handle most devistating
cases.

=>d) Must we include a standard LLL in the base system

   No. It might be a good idea on some systems, and there should
be nothing hindering its implementation, but high-level languages
should suffice for the most part. I don't believe the primary
target systems require LLL support.

=>e) Must we prepare for future distributedness (i.e. refuse solutions
=>that won't adapt to a distributed OS).

   Yes. The more flexibility the better.

=>FIRST IMPLEMENTATION
=>~~~~~~~~~~~~~~~~~~~~
=>agreements
=>~~~~~~~~~
=>a) Moose will run on 386 PC compatible machines.
=>
   The 386 version, yeah. :-) I'm thinking that I may get a
SPARC Classic or something and build my code there. The further
I can get from DOS machines, the better.

=>Unknown
=>~~~~~~~
=>
=>Questions:
=>
=>
=>a) Kernel Requirements:
=> - That's just a policy question, and there is a priori no rational
=> arguments about it, but what machines we work on.

   Whatever we can't implement in objects.

=>b) Object ID's.

   A large binary number, possibly arranged to allow addressing
smaller objects within system objects.

=>c) Objects Classes.

   I prefer the Ellie-object model of grouping objects by interface
rather than by inheritance classes. An object's class is its
interface.

=>Solutions proposed:
=>Fare:
=>a) a 386 with extended memory (even 384KB suffice for just booting
=>with a console ?).

   We should focus on making it small, but I don't think it
makes much sense trying to predict the size of the final product
before it is started.

=>b) use DT:Seg identifiers, or DT:Seg:Offset when needed. (when needed,
=>the offset may be considered as an argument to DT:Seg as a function
=>represented by the array of its values).

   Non-portable. The 386 implementation may map object ids to
segment, though.

=>c)  [ ... stuff about object disk images ... ]

   Object code is straightforward enough. I've not been completely
sold on the idea of persistant object state, but it is a good
possibility.  If inter-object references aren't tied to hardware
addresses, restoring them would be easier, assuming the kernel can
rebuild its list of objects.

=>Please state your mind.

   You really don't want to know what is in there. :-)

=>Please recall forgotten points.

   There are plenty of things I would rather forget. :-)

=>Please add your comments.

   _The Simpsons_ is a cool show. :-)

=>Please correct mistype/broken english, or mistakes.

   All English is broken. :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Mon May 24 11:56:29 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23828; Mon, 24 May 93 11:56:28 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Mon, 24 May 93 11:56:28 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA13195; Mon, 24 May 93 01:40:50 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA19964; Mon, 24 May 93 10:40:39 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA13661; Mon, 24 May 93 10:40:38 +0200
Date: Mon, 24 May 93 10:40:38 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305240840.AA13661@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Two Kernels: Sync/Async [pem00]
Status: OR

Dear moosers,

Wait! When I suggest to implement one communication object, providing 
synchronous and one asynchronous communication I only want to be able to 
make eg. a performance analysis. I don't think either, that we will implement
a whole OS for both. BUT: I think it is possible to provide both, without
much more effort. Of course we will restrict ourselves to one communication
scheme (and that should be synchronous ;-) (And there should be no mix of
synchronous and asynchronous applications in our development. Nonetheless,
as it was stated earlier both schemes can be simulated by the other. So it 
should be possible to run asynchronous apps with a sync.-kernel and vice-versa.)

What I want to express was, that in future versions it should be possible to
choose the appropriate kernel, either sync or async. And I still don't see
any reasons for not doing so. Providing 'two' kernels will maybe lead to a
more flexible and user-friendly kernel. 

Peter

From thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon May 24 13:16:13 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA24716; Mon, 24 May 93 13:16:12 +0200
Return-Path: <thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 24 May 93 13:16:12 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15030; Mon, 24 May 93 04:12:47 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa21645; 24 May 93 7:07 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa24817;
          24 May 93 11:07 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa17878;
          24 May 93 11:04 GMT
To: Peter Mueller <mueller@sc.zib-berlin.de>
Cc: moose-programmers@sfu.ca
Subject: Re: Two Kernels: Sync/Async [pem00] 
Date: Mon, 24 May 93 07:03:57 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305241104.aa17878@thorin.cis.udel.edu>
Status: OR

In Message <9305240840.AA13661@sc.zib-berlin.dbp.de> ,
   Peter Mueller <mueller@sc.zib-berlin.de> wrote:

=>What I want to express was, that in future versions it should be possible to
=>choose the appropriate kernel, either sync or async. And I still don't see
=>any reasons for not doing so. Providing 'two' kernels will maybe lead to a
=>more flexible and user-friendly kernel. 
=>
   Then you want to have both synchronous and asynchronous primitives
in the kernel API, implementing one over the other. Right?

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Mon May 24 13:42:23 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25188; Mon, 24 May 93 13:42:22 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Mon, 24 May 93 13:42:22 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15297; Mon, 24 May 93 04:39:39 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA21543; Mon, 24 May 93 13:39:33 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA14364; Mon, 24 May 93 13:39:32 +0200
Date: Mon, 24 May 93 13:39:32 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305241139.AA14364@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Two Kernels: Sync/Async [pem01]
Status: OR

Hi,

it seems, that I've a big communication problem :-)
Here I go again:

What I want is this:

	+-------+----+
	| BLACK |    |
	+-------|    |
	| KERNEL     |
	+------------+

The black box should be the communication stuff. It is
an object, providing an interface to IPC primitives 
such as
	send, receive, reply

I want to change this black box to be either sync or 
async. All other kernel stuff should remain the same.
Thus we actually have only ONE KERNEL box.

Then: We have to come to an agreement, which BLACK box
we choose in our first release. (You already know what
I want, do you :-) Then ALL apps are designed to use
this specific BLACK box, hence, using these IPC
primitives.

I only want to state the following: It should be possible
to make a design suggestion, where the IPC is a black box
which is exchangeable. (And if you all want async IPC
then I will follow you until I have my own system, where
I then will change to the sync. kernel.)

That's all. Please don't get confused for the term
'two kernels'. I still think we should implement a
'homogeneous' system.

I do agree that it is possible to simulate each IPC
form with the other, though I believe simulating sync
IPC out of async IPC is like using a steam hammer to 
crack a nut ... but that's IMHO ... ;-)

cheers,

Peter

From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Mon May 24 16:36:32 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA29422; Mon, 24 May 93 16:36:31 +0200
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Mon, 24 May 93 16:36:31 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17814; Mon, 24 May 93 07:33:37 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ab28002;
          24 May 93 10:24 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa26201;
          24 May 93 14:21 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa18534;
          24 May 93 14:21 GMT
To: Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au>
Cc: Moose Project <moose-programmers@sfu.ca>
Subject: Re: Two Kernels: Sync/Async [pem01] 
Date: Mon, 24 May 93 10:21:22 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305241421.aa18534@bifur.cis.udel.edu>
Status: OR

In Message <9305241325.17829@mulga.cs.mu.OZ.AU> ,
   Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:

=> Peter Wrote:
=>
=>> I do agree that it is possible to simulate each IPC
=>> form with the other, though I believe simulating sync
=>> IPC out of async IPC is like using a steam hammer to 
=>> crack a nut ... but that's IMHO ... ;-)
=>
=>Yes, however trying to simulate async using sync is much much worse
=>(you resort to having either 
=>	(a) ugly hacks in the kernel

   Nothing we do should be ugly. Convoluted, perhaps, but not ugly.
:-)

=>	(b) Extra processes floating around who's sole task is to merge 
=>		event streams

   I had foreseen the need for such a beast, and I think that a
system with a light enough thread can handle it without too much
pain. I could, of course, be wrong, but I think it would be worth
the attempt to gain a more object-oriented structure.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From winikoff@cs.mu.OZ.AU Mon May 24 15:28:33 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27633; Mon, 24 May 93 15:28:32 +0200
Return-Path: <winikoff@cs.mu.OZ.AU>
Received-Date: Mon, 24 May 93 15:28:32 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from mulga.cs.mu.OZ.AU by whistler.sfu.ca (5.65/SFU-2.0)
	id AA16630; Mon, 24 May 93 06:25:30 -0700
Received: by mulga.cs.mu.OZ.AU (5.83--+1.3.1+0.50); id AA17829
	Mon, 24 May 1993 23:25:24 +1000 (from winikoff)
Message-Id: <9305241325.17829@mulga.cs.mu.OZ.AU>
Subject: Re: Two Kernels: Sync/Async [pem01]
To: moose-programmers@sfu.ca (Moose Project)
Date: Mon, 24 May 93 23:25:23 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
In-Reply-To: <9305241139.AA14364@sc.zib-berlin.dbp.de>; from "Peter Mueller" at May 24, 93 1:39 pm
X-Mailer: ELM [version 2.3 PL0]
Status: OR

> I do agree that it is possible to simulate each IPC
> form with the other, though I believe simulating sync
> IPC out of async IPC is like using a steam hammer to 
> crack a nut ... but that's IMHO ... ;-)

Yes, however trying to simulate async using sync is much much worse
(you resort to having either 
	(a) ugly hacks in the kernel
	(b) Extra processes floating around who's sole task is to merge 
		event streams
)
Michael

> 
> cheers,
> 
> Peter
> 


From uunet.UU.NET!davgar!davgar.arlington.va.us!david Tue May 25 07:10:53 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17083; Tue, 25 May 93 07:10:52 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Tue, 25 May 93 07:10:52 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15566; Mon, 24 May 93 22:07:13 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA19964; Tue, 25 May 93 01:07:09 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 010543.25805; Tue, 25 May 1993 01:05:43 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Tue, 25 May 1993 00:58:09 EDT
Date:      Tue, 25 May 1993 00:58:04 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c01a762.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: Two Kernels: Sync/Async [pem01] [djg26]
Status: OR

Peter Mueller wrote:
> Hi,
>
> it seems, that I've a big communication problem :-)
> Here I go again:
>
> What I want is this:
>
>         +-------+----+
>         | BLACK |    |
>         +-------|    |
>         | KERNEL     |
>         +------------+

Actually, it is probably more like:

        +---------------+
        | BLACK BOX     |
        +--------+      |
        | KERNEL |      |
        +--------+------+

> The black box should be the communication stuff. It is
> an object, providing an interface to IPC primitives
> such as
>         send, receive, reply

Again, I think you have the wrong basic model.  There is (or should
be) no such call as "receive".  ("reply" is questionable, but that
discussion comes later.)

> I want to change this black box to be either sync or
> async. All other kernel stuff should remain the same.
> Thus we actually have only ONE KERNEL box.

One kernel box, but the basic devices (outside the kernel) are easily
10 times the size, probably more like 100 times.  And for them, THE
COMMUNICATIONS MODEL IS CRITICAL!

> Then: We have to come to an agreement, which BLACK box
> we choose in our first release. (You already know what
> I want, do you :-) Then ALL apps are designed to use
> this specific BLACK box, hence, using these IPC
> primitives.
>
> I only want to state the following: It should be possible
> to make a design suggestion, where the IPC is a black box
> which is exchangeable. (And if you all want async IPC
> then I will follow you until I have my own system, where
> I then will change to the sync. kernel.)
>
> That's all. Please don't get confused for the term
> 'two kernels'. I still think we should implement a
> 'homogeneous' system.

Synchronous can be done trivially on top of asynchronous.
Asynchronous on top of synchronous requires a helper thread and lots
of pain.

With a properly implemented system on top of an asynchronous setup,
you will NOT be able to replace it with a synchronous setup.  :-)
With a properly implemented system on top of a synchronous setup, you
WILL be able to replace it with an asynchronous setup.  :-)  Sorry.

> I do agree that it is possible to simulate each IPC
> form with the other, though I believe simulating sync
> IPC out of async IPC is like using a steam hammer to
> crack a nut ... but that's IMHO ... ;-)

Sync from async is using a steam hammer to crack a nut.
Async from sync is using a nutcracker to crack pavement.

The real problem is YOU NEED BOTH!

> cheers,
>
> Peter
>

All right, try this:  under Unix, write a program that reads data from
two data sources and does different things with the data, such that:
        1) only one process is used
        2) select() is not used
        3) either data source can produce data that will be processed
           imeadiately (sp?)
        4) the program does not eat CPU time

If you can do this in Unix, I want to see it.  I don't think Unix,
which only has synchronous IO, can do it.

With VMS and its asyncronous IO, this is trivial.


David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From mueller@sc.ZIB-Berlin.DE Tue May 25 11:50:54 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20312; Tue, 25 May 93 11:50:53 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Tue, 25 May 93 11:50:53 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21765; Tue, 25 May 93 02:47:04 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA24757; Tue, 25 May 93 11:46:55 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA15795; Tue, 25 May 93 11:33:06 +0200
Date: Tue, 25 May 93 11:33:05 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305250933.AA15795@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Two Kernels: Sync/Async [pem01] [djg26]
Status: OR


> From davgar!davgar.arlington.va.us!david@uunet.UU.NET Tue May 25 07:11:02 1993
> Date:      Tue, 25 May 1993 00:58:04 EDT
> From: "David Garfield" <david@davgar.arlington.va.us>
> Organization: Third Star on the Left
> To: moose-programmers@sfu.ca
> Subject:   Re: Two Kernels: Sync/Async [pem01] [djg26]
> Content-Length: 3159
> 
> Peter Mueller wrote:
> > Hi,
> >
> > it seems, that I've a big communication problem :-)
> > Here I go again:
> >
> > What I want is this:
> >
> >         +-------+----+
> >         | BLACK |    |
> >         +-------|    |
> >         | KERNEL     |
> >         +------------+
> 
> Actually, it is probably more like:
> 
>         +---------------+
>         | BLACK BOX     |
>         +--------+      |
>         | KERNEL |      |
>         +--------+------+
> 

Well, I don't want to start kind of hick-hack how it will look like. I think
that will bring us no step further. Let's do agree that there's a black box.


> > The black box should be the communication stuff. It is
> > an object, providing an interface to IPC primitives
> > such as
> >         send, receive, reply
> 
> Again, I think you have the wrong basic model.  There is (or should
> be) no such call as "receive".  ("reply" is questionable, but that
> discussion comes later.)
> 
> > I want to change this black box to be either sync or
> > async. All other kernel stuff should remain the same.
> > Thus we actually have only ONE KERNEL box.
> 
> One kernel box, but the basic devices (outside the kernel) are easily
> 10 times the size, probably more like 100 times.  And for them, THE
> COMMUNICATIONS MODEL IS CRITICAL!

Stop it! Didn't I have said that I don't want to implement the whole
os in two versions? I only want the possibility to make a sync. kernel. That
require the possibility to change the black box. Ok? AND IF YOU STILL THINK
THAT I WANT TWO WHOLE OS I CAN'T HELP YOU. BTW: Most modern OS uses sync.
IPC within their kernels. eg. PEACE, QNX, ... 

> 
> > Then: We have to come to an agreement, which BLACK box
> > we choose in our first release. (You already know what
> > I want, do you :-) Then ALL apps are designed to use
> > this specific BLACK box, hence, using these IPC
> > primitives.
> >
> > I only want to state the following: It should be possible
> > to make a design suggestion, where the IPC is a black box
> > which is exchangeable. (And if you all want async IPC
> > then I will follow you until I have my own system, where
> > I then will change to the sync. kernel.)
> >
> > That's all. Please don't get confused for the term
> > 'two kernels'. I still think we should implement a
> > 'homogeneous' system.
> 
> Synchronous can be done trivially on top of asynchronous.
> Asynchronous on top of synchronous requires a helper thread and lots
> of pain.

No. Sorry, I do not agree. Async. IPC will force a performance lost for 
some apps, which can be easily handled with sync. IPC. On the other hand
if async. is built with lightweight (AND THAT AREN'T PROCESSES, WHICH
ENABLING CAUSES PLENTY OF TIME) threads, there should be a minimal performance
lost for async apps. If you do it the other way round, the performance lost
for sync. apps. will be much much more greater.

> 
> With a properly implemented system on top of an asynchronous setup,
> you will NOT be able to replace it with a synchronous setup.  :-)
> With a properly implemented system on top of a synchronous setup, you
> WILL be able to replace it with an asynchronous setup.  :-)  Sorry.
> 
> > I do agree that it is possible to simulate each IPC
> > form with the other, though I believe simulating sync
> > IPC out of async IPC is like using a steam hammer to
> > crack a nut ... but that's IMHO ... ;-)
> 
> Sync from async is using a steam hammer to crack a nut.
> Async from sync is using a nutcracker to crack pavement.

Again: NO! Why are modern os using sync. IPC, then?

> 
> The real problem is YOU NEED BOTH!
> 
> > cheers,
> >
> > Peter
> >
> 

FIRST OF ALL: UNIX IS *NO* MODERN OS. IT IS HEAVY, UNFLEXIBLE, LIKE A
DINOSAUR, AND SHOULD BE REPLACED BY ANOTHER SYSTEM. UNIX is a monolithic
OS, where all things, which are to be said to be included in a 'modern'
os are fixed within the kernel. This leads to a tremendeous overhead in all
os related stuff. So, I do agree, that your example is a counterexample IF
YOU COMPARE UNIX AS A MODERN SYSTEM. Sorry, I don't think that this 
comparism is useful.

> All right, try this:  under Unix, write a program that reads data from
> two data sources and does different things with the data, such that:
>         1) only one process is used
>         2) select() is not used
>         3) either data source can produce data that will be processed
>            imeadiately (sp?)
>         4) the program does not eat CPU time
> 
> If you can do this in Unix, I want to see it.  I don't think Unix,
> which only has synchronous IO, can do it.
> 
> With VMS and its asyncronous IO, this is trivial.

VMS is ALSO NOT A MODERN SYSTEM. Stop talking about the old world, think over
the new one and look into future ... In current OS research there is the trend
to ask, what must not be in the kernel and not what do I want to have in it.
Eg. The QNX micro-kernel provides the following four (4!) functions:

	1) Synchronous IPC (send, receive, reply)
	2) Process scheduling (ie. context switch)
	3) Network connection
	4) Interrupt/Signal-handling (a signal is simply converted into
           a message which is then transferred to an appropriate server, which
           resides outside the kernel.)

The latter two points are placed within the smallest units. Sometimes if you
ask, what should the kernel of a modern OS provide, you will hear:

	1) Synchronous IPC (because it must be fast)
	2) Process execution (ie. scheduling)

 
> 
> David
> -- 
> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
> Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com
>

cheers, 

Peter 

From mueller@sc.ZIB-Berlin.DE Tue May 25 11:50:27 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20307; Tue, 25 May 93 11:50:26 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Tue, 25 May 93 11:50:26 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21764; Tue, 25 May 93 02:47:02 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA24754; Tue, 25 May 93 11:46:54 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA15811; Tue, 25 May 93 11:42:13 +0200
Date: Tue, 25 May 93 11:42:13 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9305250942.AA15811@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: paper recommendation
Status: OR

hi,

in my previous mail, I've mentioned a system named QNX, which provide a
micro-kernel with a size of at most 8K. If you want to read an 
architectural overview, here is a paper:

%A Dan Hildebrand
%T An Architectural Overview of QNX
%J Proceedings of the Usenix Workshop on Micro-Kernels & Other Kernel
   Architectures, Seattle
%M Apr.
%Y 1992

this paper is anon.-ftp-able as:

ftp.cse.ucsc.edu:/pub/qnx/qnx-paper.ps.Z

bye, (and: Always Look on the Bright Side of Life ...)

Peter

From rideau@clipper Thu May 27 03:23:38 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15458; Thu, 27 May 93 03:23:35 +0200
Return-Path: <rideau@clipper>
Received-Date: Thu, 27 May 93 03:23:35 +0200
Received: from nef.ens.fr by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from nef.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA27838; Wed, 26 May 93 18:20:39 -0700
Received: from dmi.ens.fr by nef.ens.fr (5.65c8/ULM-1.0)
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from fregate.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15430; Thu, 27 May 93 03:20:06 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9305270120.AA15430@clipper.ens.fr>
Subject: various subjects [far35]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Thu, 27 May 93 3:20:05 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR


- Blocking/Async IPC:
Why battle about it ? After all Intel x86 and most CPU instruction sets
provide sync IPC and nothing else (usually CALL, INT, TRAP, JSR or such
instruction). That's why the kernel's job usually is building async IPC
from sync instruction set. Sync communication can be done without the
kernel, using standard servers to connect (=process managin device,
memory managing device for sharing memory)
 Now, the system should porvide both synchronous an d asynchronous IPC
as standard, and building one from the other also should be included in
a standard system (meta-)library, so that synchronousness of IPC be
independent from the kernel.

- I've read the QNX papers: well, MicroKernel seems ok, but the question
is where to put object management in such a system. Moreover, we decided
to have dictionaries (name server) local to objects, etc.

Answer is not to put it in the innermost kernel (the "nucleus" as it was
called)
- MicroKernel: message passing between processes.
- Link: library to link any object with any other. Link understands
meta-typing through add-on libraries, and manages translation of
physical types inside indentical meta-types. This translation is done
according to relative trust between objects: an object can trust
another, thus doing less checking and allowing quicker transfer; it can
even allow direct addressing of its address space to another if it
really trust it, etc. Thus the Link module can handle functions as
parameters (what we want, don't we, Andreas ?), and when the function
is executed, it has more or less acess rights over the caller's address
space, according to the caller's confidence.
 The types of links are:
. existence link: forces the system to have the linked object handy
(the presence of a file in a directory is thus considered as an
existence link from the directory to the file).
. connection: the objects now send data each to the other through the
kernel.
For example, when you want to use some library, first build an existence
link to it, then connect to it each time you use it. This use can involve
a sub-connection, etc (but it is a finite process).
In our system, an existence link IS a connection to the object's class.
Or perhaps a connection is an existence link to an object's instance.

Link is an important part of the system, if not the most important part
of it. It is NOT in the nucleus, but it IS in the standard base system.
Link itself should be modular and include a Link kernel, etc.

- Gary, where can we find papers on Ellie ? on Sather ?

- Soon, my next posts about HLL, LLL and MOOSE Bases. Perhaps Dennis
should maintain a list of our naming conventions (=Kernel, Nucleus,
dictionaries, and so on).

- About HLL, my motto is genericity. The HLL we choose must include
maximal support of genericity. This includes grouping objects by
metaclasses i.e. interface, and not inheritance, and accepting types as
parameters and any other object. Types can also be understood as
restrictions upon objects. To illustrate that, I wrote some
generic module in Pascal (more readable than C, as powerful when you
don't use defines and type casting). Well, Pascal is truly horrible
for that, and well shows the limits of C-like languages.
Unfortunately, these modules were in french, so that I must translate
before I publish it (it was a Power 4 game, using a generic module for
games between two players, and another generic module for minimax
algorithm). The modules also showed that some optimizations that had
to be done manually would have to be included in the compiler (i.e.,
eliminating local variables in a recursive function by using global
ones and saving minor changes of the global variable in the stack), and
that memory management would be done if the language did accept multiple
memory zones (in that case, another stack for some kind of data), that
the optimizer could possibly join into the program's main stack (in a
mono-process version), etc.

- So what about that talk or irc around the net ? Mailing is too slow
for this project.

--
      ,						,           _      ~  ^
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
					'		    / .     

From thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri May 28 13:44:06 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00481; Fri, 28 May 93 13:44:05 +0200
Return-Path: <thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 28 May 93 13:44:05 +0200
Received: from nef (nef.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from whistler.sfu.ca by nef (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA26426; Fri, 28 May 93 04:40:18 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa08619; 28 May 93 7:33 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa06089;
          28 May 93 11:33 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa19349;
          28 May 93 11:31 GMT
To: Francois-Rene Rideau <rideau@clipper>
Cc: All the happy Moosers ! <moose-programmers@sfu.ca>
Subject: Re: various subjects [far35] 
Date: Fri, 28 May 93 07:31:15 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9305281131.aa19349@thorin.cis.udel.edu>
Status: OR

In Message <9305270120.AA15430@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=>
=>- Blocking/Async IPC:
=> Now, the system should porvide both synchronous an d asynchronous IPC
=>as standard, and building one from the other also should be included in
=>a standard system (meta-)library, so that synchronousness of IPC be
=>independent from the kernel.
=>
   Yes, I think this is a good idea, provided that we build it with
the idea that users will generally use synchronous with threads.

=> The types of links are:
=>. existence link: forces the system to have the linked object handy
=>(the presence of a file in a directory is thus considered as an
=>existence link from the directory to the file).

   This brings to mind the idea of garbage collection. I don't
know if we can can do it properly since we can't tell when an object
discards a reference. We could have a "Free Reference" call, but an
antisocial program could easily skip it. Ideas?

=>- Gary, where can we find papers on Ellie ? on Sather ?
=>
   You can FTP papers on Ellie from
ftp.diku.dk:pub/diku/dists/ellie/papers. I believe you can get Sather
papers from ftp.icsi.berkeley.edu. They may be part of the compiler
distribution.

=>- About HLL, my motto is genericity. The HLL we choose must include
=>maximal support of genericity. This includes grouping objects by
=>metaclasses i.e. interface, and not inheritance, and accepting types as
=>parameters and any other object. Types can also be understood as
=>restrictions upon objects. To illustrate that, I wrote some
=>generic module in Pascal (more readable than C, as powerful when you
=>don't use defines and type casting). Well, Pascal is truly horrible
=>for that, and well shows the limits of C-like languages.

   To be fair, that should be Algol-like langauges. In Ellie, any
object can be a metaclass. Extending such a thing to the system
level would be the real trick.

=>- So what about that talk or irc around the net ? Mailing is too slow
=>for this project.

   I rather like it slow, since it gives me time to think things
through a bit, but I would certainly join in an IRC session if we
were to put one together.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From mueller@sc.ZIB-Berlin.DE Thu Jun  3 13:20:04 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15909; Thu, 3 Jun 93 13:20:03 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Thu, 3 Jun 93 13:20:03 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20241; Thu, 3 Jun 93 04:13:43 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA24256; Thu, 3 Jun 93 13:13:33 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA26113; Thu, 3 Jun 93 13:13:33 +0200
Date: Thu, 3 Jun 93 13:13:33 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9306031113.AA26113@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Re: Pthhbbbt. [06/03, pem]
Status: OR

[Subject should be more like 'phew!']

I know, I know, I know. Actually I'm extremely too late. But I think I should
write something, too. Now.

I'm currently trying to get some order in my received Moose mails. A can't help
me, but I've read some of the 'Pthhbbbt' mails. I read some sort of:

... Moose should be useful ...
... Moose should be easy to program ...
... Moose should grab much acceptance ...

Well, well, well. Nice goals, though. But: How is it in reality? If you want 
Moose to be used in a wide spreaded user area you will have to consider the
following thing:

o  Users don't want to see changes. They don't want to learn a new system from
   scratch. They don't want to use, for example a different text processing
   system even if it is much better than their used old typewriter.
      If we want to make Moose attractive to the normal user, we have to offer
   well known interfaces. Sorry, I know the next sentence will make you flame
   me but it must be said: We have to provide a ms-dos-interface, we have to
   provide a unix-interface. The user must have the feel to work with ms-dos
   or unix, respectively. (OF COURSE: Moose can provide much better things.
   But these things must first establish themselves. And that will cost a 
   lot of time. BTW: There are many examples, where new technology was not
   accepted, although it provides fantastic advantages: It was not compatible
   to old, but used, systems.)

Ok. Now for the goodies. I think it is possible to provide Moose with such
attractiveness. And it is possible to make it available in such a way, that
new facilities can be used. The user will see those things, declares them as
useful, and will told them to his/her friends. And then distribution of Moose
will function automatically ... ;-) (That's the future view.)

Cheers,

Peter 

From mueller@sc.ZIB-Berlin.DE Thu Jun  3 14:08:01 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16475; Thu, 3 Jun 93 14:08:00 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Thu, 3 Jun 93 14:08:00 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20899; Thu, 3 Jun 93 05:02:16 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/04.05.93)
	id AA24424; Thu, 3 Jun 93 14:02:10 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA26232; Thu, 3 Jun 93 14:02:09 +0200
Date: Thu, 3 Jun 93 14:02:09 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9306031202.AA26232@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: PostScript available?
Status: OR

Hi,

I would like to know, whether all of you are able to print PostScript files.
I think, writing specifications, providing graphical pictures are much more
useful.

(I don't think it must be each specification release, or update. Only one in,
say 4 weeks (?). And I don't know either, how to contribute those files.
I just want to hear your comments on this.)

Cheers,

Peter

From mueller@sc.ZIB-Berlin.DE Thu Jun  3 14:51:48 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17021; Thu, 3 Jun 93 14:51:47 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Thu, 3 Jun 93 14:51:47 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21700; Thu, 3 Jun 93 05:41:41 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/03.06.93)
	id AA24611; Thu, 3 Jun 93 14:40:48 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA26347; Thu, 3 Jun 93 14:40:47 +0200
Date: Thu, 3 Jun 93 14:40:46 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9306031240.AA26347@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: ROI, ORG, [pem 06/03]
Status: OR

Hi,

I want to present two points.

1. Who is absolutely interested in designing ROI for Moose? (I mean, who is
   not able to live without it :-) This is the first attempt to create a smaller
   group. Maybe we can setup a smaller alias list. And others are not bombed
   with mails.

2. I've thinked about a problem, which - in my opinion - covers the area of
   the compiler designers (see below)

Ad 1.

I want to form a smaller group of interested people, to force a useful
specification on ROI (where a 1 is the major number ...). I plan to inform the
whole Moose community periodically each quarter a year. (If this is QUIRKS:
I mean after 3 weeks.) In my opinion we should create smaller groups, where
people talk especially and exactly about one (1) topic, and where mails
referencing to multiple sujects can be avoided. What do you think?

Ad 2.

Last night the following problem (and it's possible solution) came into my
mind. An object is, at least able to have two 'address spaces', namely private
and public. Variables, or 'objects' within the private space are only visible
to the object, whereas objects in the public space are also seen to the outer
world.

Now consider the following object:

class example {
   int i;               // i is private

public:
   int j;               // j is public

   void do_something() {
      i = 1;            // Change object's private state
      j = i + 1;        // Change object's public state
   }
};

Now consider, that 'do_something()' is a service, made available via the
DIRECTORY SERVICE. Then (I take the term now:) client objects can remotely
invoke do_something().

What happens?

For the client object, the example must change its private state! But this
must only be seen to the client object! Not to others. On the other hand,
the change to the public state must be seen to all other clients.

We can say, the change of the private state is a local change to the state
seen by a specific client object, whereas a change of the public state is
a global change seen to all possible client objects.

Where are the problems?

The global change leads to a synchronization problem. In each situation we
have to take care to establish a consistent state. (I think, that's where
the compilers must give as much as help as they can!)

The local change makes it necessary to provide a copy of at least the private
members of an object for each client object! (And therefore we need tools, 
which similiar to those nice stub-making tools for RPC.)

Solutions?

Well, to the local change there is an easy solution. Each client, wanting to 
use other objects' methods remotely, will create an appropriate instance of
a server class. This class will inform the remote object, that there is a new
client. This will lead at the remote object to 'fork' (if you will forgive my
UNIXness ;-) a private copy, especially for this new client. The private copy 
consists of 

   1) The private state as it was created on server startup time. (Each time
      a new client occurs, it will see the same private state.)
   2) The public state at this time. (A newly client can see different states
      than previous ones.)

At the client side, this will be done within the constructor of the server class
instance. The destructor call will inform the remote object to discard the
created client's private view.

I suggest the following terms for the - perhaps - following discussion:

connector - This is the object used by a client object to establish a new
            connection to a remote object. The constructor will inform the 
            remote object, that there is a new client, whereas the destructor
            will say, that the client is finished.

shadow    - This is the (remote) object which is actually seen by a client
            object after connection. Within this object only the private 
            (and/or protected (?)) members of the remote object are hold.
            Public members are still shared through the 'real' remote object.
            The shadow is created after a connection request by a connector.

(The connection between client and shadow must provide a merge between the
valid private and public state. Thus, the shadow 'merges' the local view and
the global view.)

Other Problems?

What's about availability and fault tolerance? Reliability? Garbage collection?

Hope, to hear some comments,

Peter

From danodom@matt.ksu.ksu.edu Thu Jun  3 22:39:46 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25109; Thu, 3 Jun 93 22:39:45 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Thu, 3 Jun 93 22:39:45 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA06241; Thu, 3 Jun 93 13:33:42 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA04511; Thu, 3 Jun 93 13:53:01 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306031853.AA04511@matt.ksu.ksu.edu>
Subject: Re: PostScript available?
To: mueller@sc.zib-berlin.de (Peter Mueller)
Date: Thu, 3 Jun 93 13:53:00 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <9306031202.AA26232@sc.zib-berlin.dbp.de>; from "Peter Mueller" at Jun 3, 93 2:02 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Peter Mueller Said:

> I would like to know, whether all of you are able to print PostScript files.
> I think, writing specifications, providing graphical pictures are much more
> useful.

Nope.  If you'll buy me the printer, I'll be happy to say yes... :-)
All I have is an HP Deskjet, but I can get access to a Laserjet.  If
you're using TeX, just send us the TeX source file.

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From danodom@matt.ksu.ksu.edu Thu Jun  3 22:52:27 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25271; Thu, 3 Jun 93 22:52:26 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Thu, 3 Jun 93 22:52:26 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07239; Thu, 3 Jun 93 13:45:39 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA10609; Thu, 3 Jun 93 15:48:05 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306032048.AA10609@matt.ksu.ksu.edu>
Subject: LARRIE
To: moose-programmers@sfu.ca (Moose List)
Date: Thu, 3 Jun 93 15:48:04 CDT
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Would somebody PLEASE get LARRIE off this list?  The 'unknown user'
bounces are annoying.

I'm also kinda curious about how a nonexistant name got added to the
list in the first place...

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Thu Jun  3 23:43:10 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25788; Thu, 3 Jun 93 23:43:08 +0200
Return-Path: <nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Thu, 3 Jun 93 23:43:08 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11260; Thu, 3 Jun 93 14:36:23 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa14730; 3 Jun 93 17:28 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa29831; 3 Jun 93 21:27 GMT
Received: from sol.cis.udel.edu by nori.cis.udel.edu id aa15193;
          3 Jun 93 21:25 GMT
To: Peter Mueller <mueller@sc.zib-berlin.de>
Cc: moose-programmers@sfu.ca
Subject: Re: Pthhbbbt. [06/03, pem] 
Date: Thu, 03 Jun 93 17:25:27 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306032125.aa15193@nori.cis.udel.edu>
Status: OR

In Message <9306031113.AA26113@sc.zib-berlin.dbp.de> ,
   Peter Mueller <mueller@sc.zib-berlin.de> wrote:

=>[Subject should be more like 'phew!']
=>
=>I know, I know, I know. Actually I'm extremely too late. But I think I should
=>write something, too. Now.
=>
=>I'm currently trying to get some order in my received Moose mails. A can't he
lp
=>me, but I've read some of the 'Pthhbbbt' mails. I read some sort of:
=>
=>... Moose should be useful ...
=>... Moose should be easy to program ...
=>... Moose should grab much acceptance ...
=>
=>Well, well, well. Nice goals, though. But: How is it in reality? If you want 
=>Moose to be used in a wide spreaded user area you will have to consider the
=>following thing:
=>
   [ ... Stuff about DOS and Unix interfaces ... ]

   Are you talking about shells, APIs, or binaries? None of these
should be in the base package, IMHO. Well, maybe a shell, but not
the others.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Thu Jun  3 23:44:03 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA25797; Thu, 3 Jun 93 23:44:02 +0200
Return-Path: <nori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Thu, 3 Jun 93 23:44:02 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA11334; Thu, 3 Jun 93 14:37:12 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa14933; 3 Jun 93 17:33 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa29839; 3 Jun 93 21:32 GMT
Received: from sol.cis.udel.edu by nori.cis.udel.edu id aa15218;
          3 Jun 93 21:28 GMT
To: moose-programmers@sfu.ca
Subject: Re: PostScript available? 
Date: Thu, 03 Jun 93 17:28:36 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306032128.aa15218@nori.cis.udel.edu>
Status: OR

In Message <9306031202.AA26232@sc.zib-berlin.dbp.de> ,
   Peter Mueller <mueller@sc.zib-berlin.de> wrote:

=>Hi,
=>
=>I would like to know, whether all of you are able to print PostScript files.
=>I think, writing specifications, providing graphical pictures are much more
=>useful.
=>
   I can print PostScript at work with a bit of hackery.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun  4 08:17:25 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07796; Fri, 4 Jun 93 08:17:24 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 4 Jun 93 08:17:24 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07543; Thu, 3 Jun 93 23:06:58 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA02017; Fri, 4 Jun 93 02:07:08 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020518.4592; Fri, 4 Jun 1993 02:05:18 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 04 Jun 1993 00:45:58 EDT
Date:      Fri, 04 Jun 1993 00:45:53 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c0ed387.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: PostScript available? [djg27]
Status: OR

On Thu, 3 Jun 93 14:02:09 +0200, Peter Mueller wrote:
> Hi,
>
> I would like to know, whether all of you are able to print PostScript files.
> I think, writing specifications, providing graphical pictures are much more
> useful.

I too can handle PostScript, if needed.

We may be able to handle some other formats.  If nothing else, we all
have PC class machines (I think).  Of course, such an other format
probably means on screen displays.

--David

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun  4 08:17:37 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07804; Fri, 4 Jun 93 08:17:36 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 4 Jun 93 08:17:36 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07574; Thu, 3 Jun 93 23:08:03 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA08273; Fri, 4 Jun 93 02:08:13 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020519.4597; Fri, 4 Jun 1993 02:05:19 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 04 Jun 1993 00:57:16 EDT
Date:      Fri, 04 Jun 1993 00:57:13 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c0ed62d.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   On Peters attempt to make a smaller group [djg28]
Status: OR

On Thu, 3 Jun 93 14:40:46 +0200, Peter Mueller wrote:
> Hi,
>
> I want to present two points.
>
> 1. Who is absolutely interested in designing ROI for Moose? (I mean, who is
>    not able to live without it :-) This is the first attempt to create a smaller
>    group. Maybe we can setup a smaller alias list. And others are not bombed
>    with mails.
...
> Ad 1.
>
> I want to form a smaller group of interested people, to force a useful
> specification on ROI (where a 1 is the major number ...). I plan to inform the
> whole Moose community periodically each quarter a year. (If this is QUIRKS:
> I mean after 3 weeks.) In my opinion we should create smaller groups, where
> people talk especially and exactly about one (1) topic, and where mails
> referencing to multiple sujects can be avoided. What do you think?
...
>
> Peter

There is a serious problem with trying to make a smaller group for
ROI.  ROI as you call it is the core of Moose.  It is the one of the
things that makes Moose Moose.  ROI is after all the messaging
facility of Moose, and so is crutial.  No one should even consider not
participating in, or at least paying attention to, this discussion.

David

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun  4 08:17:48 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07808; Fri, 4 Jun 93 08:17:47 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 4 Jun 93 08:17:47 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07542; Thu, 3 Jun 93 23:06:57 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA02003; Fri, 4 Jun 93 02:07:06 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020520.4602; Fri, 4 Jun 1993 02:05:20 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 04 Jun 1993 01:14:47 EDT
Date:      Fri, 04 Jun 1993 01:14:41 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c0eda49.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   On Peter's "address spaces" problem [djg29]
Status: OR

On Thu, 3 Jun 93 14:40:46 +0200, "Peter Mueller" <mueller@sc.ZIB-Berlin.DE> wrote:
> Hi,
> 
> I want to present two points.
...
> 2. I've thinked about a problem, which - in my opinion - covers the area of
>    the compiler designers (see below)
> 
> Ad 2.
> 
> Last night the following problem (and it's possible solution) came into my
> mind. An object is, at least able to have two 'address spaces', namely private
> and public. Variables, or 'objects' within the private space are only visible
> to the object, whereas objects in the public space are also seen to the outer
> world.
> 
> Now consider the following object:
> 
> class example {
>    int i;               // i is private
> 
> public:
>    int j;               // j is public
> 
>    void do_something() {
>       i = 1;            // Change object's private state
>       j = i + 1;        // Change object's public state
>    }
> };
> 

In C++ (the language of your example), these exist, but they are not 
called public and private.  They are called static member variables 
and member variables.  Please use the right notation.  

> Now consider, that 'do_something()' is a service, made available via the
> DIRECTORY SERVICE. Then (I take the term now:) client objects can remotely
> invoke do_something().
> 
> What happens?
> 
> For the client object, the example must change its private state! But this
> must only be seen to the client object! Not to others. On the other hand,
> the change to the public state must be seen to all other clients.
> 
> We can say, the change of the private state is a local change to the state
> seen by a specific client object, whereas a change of the public state is
> a global change seen to all possible client objects.
> 
> Where are the problems?
> 
> The global change leads to a synchronization problem. In each situation we
> have to take care to establish a consistent state. (I think, that's where
> the compilers must give as much as help as they can!)
> 
> The local change makes it necessary to provide a copy of at least the private
> members of an object for each client object! (And therefore we need tools, 
> which similiar to those nice stub-making tools for RPC.)
> 
> Solutions?
> 
> Well, to the local change there is an easy solution. Each client, wanting to 
> use other objects' methods remotely, will create an appropriate instance of
> a server class. This class will inform the remote object, that there is a new
> client. This will lead at the remote object to 'fork' (if you will forgive my
> UNIXness ;-) a private copy, especially for this new client. The private copy 
> consists of 
> 
>    1) The private state as it was created on server startup time. (Each time
>       a new client occurs, it will see the same private state.)
>    2) The public state at this time. (A newly client can see different states
>       than previous ones.)
> 
> At the client side, this will be done within the constructor of the server class
> instance. The destructor call will inform the remote object to discard the
> created client's private view.

I am confused.  It appears that you are trying to say that the client 
owns the data of the class.  This is, IMHO, why we have a kernel.  
When a client wishes to make a new object of a class, a request is 
made to the kernel.  The kernel allocates memory, and invokes the 
constructor, allowing the class driver code access to the object for 
the duration.  This allows the class to set up the clients specific 
data.  The 'shared' data is simply variables local to the classes 
application, that need not have any additional special processing.  

When the application invokes a method of (or "sends a message to" 
depending on your terminology) the object, the class is once again 
given access to the object to do whatever processing needs to be done.  

At no time, IMHO, should the client ever have access to any object 
specific or class specific variables.  If the client needs access to 
data, it should ask for it, not get it itself.

So, all the client ever does have is one number.  This may be an 
object ID or it may be a process specific results of having done an 
open()-like call to gain access to an object (as I suggested once 
before).

> 
> I suggest the following terms for the - perhaps - following discussion:
> 
> connector - This is the object used by a client object to establish a new
>             connection to a remote object. The constructor will inform the 
>             remote object, that there is a new client, whereas the destructor
>             will say, that the client is finished.
> 
> shadow    - This is the (remote) object which is actually seen by a client
>             object after connection. Within this object only the private 
>             (and/or protected (?)) members of the remote object are hold.
>             Public members are still shared through the 'real' remote object.
>             The shadow is created after a connection request by a connector.
> 
> (The connection between client and shadow must provide a merge between the
> valid private and public state. Thus, the shadow 'merges' the local view and
> the global view.)

These terms shoud not be needed.

> 
> Other Problems?
> 
> What's about availability and fault tolerance? Reliability? Garbage collection?

next message...

> 
> Hope, to hear some comments,
> 
> Peter

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun  4 08:17:24 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07795; Fri, 4 Jun 93 08:17:23 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 4 Jun 93 08:17:23 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07572; Thu, 3 Jun 93 23:08:01 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA08231; Fri, 4 Jun 93 02:08:08 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020521.4607; Fri, 4 Jun 1993 02:05:21 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 04 Jun 1993 01:26:17 EDT
Date:      Fri, 04 Jun 1993 01:26:13 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c0edcfa.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   On Garbage Collection [djg30]
Status: OR

The issue of garbage collection has now been brought up.

I hope to end it now.

Garbage Collection is an excuse to be sloppy.

In a kernel, or in anything important, you should be precise, not
sloppy.  If there is ever a time in which the we have lost all
pointers to a block, but not freed it, we have done something wrong.
To attempt to garbage collect it would just cover the problem up, and
it would come back and bite us, over, and over, and over again.

Lets not even consider garbage collection for the kernel or any core
classes.

Garbage collection for specific applications I have no objection to,
and this exists now, so it may continue.

The rule should be: any process (or kernel) that other processes
depend on must be precise and correct.

Comments?  Disagreements?

--David

-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun  4 10:19:17 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09597; Fri, 4 Jun 93 10:19:16 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 4 Jun 93 10:19:16 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA07537; Thu, 3 Jun 93 23:06:55 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA01957; Fri, 4 Jun 93 02:07:04 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 020521.4612; Fri, 4 Jun 1993 02:05:21 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 04 Jun 1993 01:56:12 EDT
Date:      Fri, 04 Jun 1993 01:56:08 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c0ee3fd.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Synchronous/Asynchronous, one more try. [djg31]
Status: OR

Well,

-------------------------

I have looked over the QNX paper.  I was very surprised to learn that
its send() call blocked until after the reply was done.  OK, so QNX is
synchronous.  That does not mean that all modern OSes are synchronous,
just that one 11 year old OS is.

-------------------------

I fully agree that either the standard library (or whatever we call
it) or the kernel should include a synchronous communication layer,
but still assert that the kernel must include an asynchronous
communication layer at at least as low a level.  I agree that
programmers should be encouraged to use the synchronous forms unless
the applications calls for something else.

-------------------------

Peter, my challenge stands.
}} All right, try this:  under Unix, write a program that reads data from
}} two data sources and does different things with the data, such that:
}}         1) only one process is used
}}         2) select() is not used
}}         3) either data source can produce data that will be processed
}}            imeadiately (sp?)
}}         4) the program does not eat CPU time
}}
}} If you can do this in Unix, I want to see it.  I don't think Unix,
}} which only has synchronous IO, can do it.
}}
}} With VMS and its asyncronous IO, this is trivial.

You dismissed this by saying that both Unix and VMS are old operating
systems.  Very well, you are welcome to replace either or both with
something that you consider a new/modern operating system.  I quoted
Unix and VMS because I know them and they are fairly well understood
and available.  If you do use another operating system in your
program, be prepared to explain it.

Good Luck...

-------------------------

The tendency of modern OSes to seperate things into lots of little
chunks outside the kernel is good.  But an OS can be just as modern
linked as one biiiiig image.  And an OS can be just as archaic in
little chunks.  The little chunks gives you modularity and isolation,
which make you programming job easier (usually).  :-)

-------------------------

--David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Jun  4 13:34:01 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13035; Fri, 4 Jun 93 13:33:59 +0200
Return-Path: <ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 4 Jun 93 13:33:59 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15188; Fri, 4 Jun 93 04:28:03 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa21807; 4 Jun 93 7:22 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa07537; 4 Jun 93 11:21 GMT
Received: from sol.cis.udel.edu by ori.cis.udel.edu id aa18201;
          4 Jun 93 11:16 GMT
To: moose-programmers@sfu.ca
Subject: Re: PostScript available? [djg27] 
Date: Fri, 04 Jun 93 07:16:34 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306041116.aa18201@ori.cis.udel.edu>
Status: OR

In Message <2c0ed387.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>We may be able to handle some other formats.  If nothing else, we all
=>have PC class machines (I think).  Of course, such an other format
=>probably means on screen displays.
=>
   Actually, all I have at home is an HP 2621P terminal. I use a
486DX/50 at work, though. I'm thinking of getting a low end Unix box,
like a SPARC Classic for hacking. The sooner I can get away from ISA,
BIOS, and 640K conventional memory, the better. I may end up with a
486 running 386BSD, but I'd rather not.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Jun  4 13:45:48 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13418; Fri, 4 Jun 93 13:45:46 +0200
Return-Path: <ori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 4 Jun 93 13:45:46 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15520; Fri, 4 Jun 93 04:38:58 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa22282; 4 Jun 93 7:37 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa07562; 4 Jun 93 11:36 GMT
Received: from sol.cis.udel.edu by ori.cis.udel.edu id aa18286;
          4 Jun 93 11:31 GMT
To: moose-programmers@sfu.ca
Subject: Re: Synchronous/Asynchronous, one more try. [djg31] 
Date: Fri, 04 Jun 93 07:31:23 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306041131.aa18286@ori.cis.udel.edu>
Status: OR

In Message <2c0ee3fd.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>Well,
=>
=>-------------------------
=>
=>I have looked over the QNX paper.  I was very surprised to learn that
=>its send() call blocked until after the reply was done.  OK, so QNX is
=>synchronous.  That does not mean that all modern OSes are synchronous,
=>just that one 11 year old OS is.
=>
   IPC in QNX was discussed on comp.os.research a few weeks back. It
seems that Dan Hildebrant (sp?) and the folks at QNX generally don't
have a need for the asynchronous primitives for the class of programs
that they deal with (real-time applications.)

=>I fully agree that either the standard library (or whatever we call
=>it) or the kernel should include a synchronous communication layer,
=>but still assert that the kernel must include an asynchronous
=>communication layer at at least as low a level.  I agree that
=>programmers should be encouraged to use the synchronous forms unless
=>the applications calls for something else.
=>
   Ok, so we do both, with synchronous being primary, with asynchronous
being equal or secondary, depending on architecture and implementation.
Good enough?

=>Peter, my challenge stands.
=>}} All right, try this:  under Unix, write a program that reads data from
=>}} two data sources and does different things with the data, such that:
=>}}         1) only one process is used
=>}}         2) select() is not used
=>}}         3) either data source can produce data that will be processed
=>}}            imeadiately (sp?)
=>}}         4) the program does not eat CPU time
=>}}

   I think my point would be that the question is flawed. :-)  You
assume that #1 is bad, while I would say that multiple processes
might be a reasonable way of dealing with multiple streams. If the
processes (threads) are light enough, this shouldn't be a problem.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Jun  4 17:53:57 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA17835; Fri, 4 Jun 93 17:53:56 +0200
Return-Path: <gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 4 Jun 93 17:53:56 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22823; Fri, 4 Jun 93 08:47:21 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ag00529; 4 Jun 93 11:40 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id ab09491; 4 Jun 93 15:29 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa21486;
          4 Jun 93 15:27 GMT
To: moose-programmers@sfu.ca
Subject: Re: On Peters attempt to make a smaller group [djg28] 
Date: Fri, 04 Jun 93 11:27:37 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306041527.aa21486@gloin.cis.udel.edu>
Status: OR

In Message <2c0ed62d.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>There is a serious problem with trying to make a smaller group for
=>ROI.  ROI as you call it is the core of Moose.  It is the one of the
=>things that makes Moose Moose.  ROI is after all the messaging
=>facility of Moose, and so is crutial.  No one should even consider not
=>participating in, or at least paying attention to, this discussion.
=>
   Agreed. If others want to split off to discuss the GUI, secondary
storage, etc., fine, but communication is at the heart of the
system.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Jun  4 18:23:13 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18414; Fri, 4 Jun 93 18:23:12 +0200
Return-Path: <gloin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 4 Jun 93 18:23:12 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA23640; Fri, 4 Jun 93 09:01:26 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id ae00988; 4 Jun 93 11:54 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa09491; 4 Jun 93 15:29 GMT
Received: from sol.cis.udel.edu by gloin.cis.udel.edu id aa21464;
          4 Jun 93 15:25 GMT
To: moose-programmers@sfu.ca
Subject: Re: On Garbage Collection [djg30] 
Date: Fri, 04 Jun 93 11:24:58 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306041525.aa21464@gloin.cis.udel.edu>
Status: OR

In Message <2c0edcfa.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>The issue of garbage collection has now been brought up.
=>
=>I hope to end it now.
=>
=>Garbage Collection is an excuse to be sloppy.
=>
=>Comments?  Disagreements?
=>
   I was commenting on garbage collecting system objects, and decided
it wasn't too practical. Garbage collection in general is a useful
tool. How often have you run across a program with a memory leak? If
it is part of your environment you might as well use it. You may be
right, though, that the kernel may not be a good place for it to be
used.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From danodom@matt.ksu.ksu.edu Fri Jun  4 23:45:08 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22149; Fri, 4 Jun 93 23:45:07 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Fri, 4 Jun 93 23:45:07 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20134; Fri, 4 Jun 93 14:37:08 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA07423; Fri, 4 Jun 93 16:39:31 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306042139.AA07423@matt.ksu.ksu.edu>
Subject: Re: PostScript available?
To: david@davgar.arlington.va.us (David Garfield)
Date: Fri, 4 Jun 93 16:39:30 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <2c0ed387.davgar@davgar.arlington.va.us>; from "David Garfield" at Jun 4, 93 12:45 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

David Garfield Said:

> We may be able to handle some other formats.  If nothing else, we all
> have PC class machines (I think).  Of course, such an other format
> probably means on screen displays.

Keep in mind that not all of us are running MS-DOS...

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From danodom@matt.ksu.ksu.edu Fri Jun  4 23:47:37 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22180; Fri, 4 Jun 93 23:47:36 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Fri, 4 Jun 93 23:47:36 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20518; Fri, 4 Jun 93 14:41:30 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA07747; Fri, 4 Jun 93 16:43:58 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306042143.AA07747@matt.ksu.ksu.edu>
Subject: Re: On Garbage Collection
To: david@davgar.arlington.va.us (David Garfield)
Date: Fri, 4 Jun 93 16:43:57 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <2c0edcfa.davgar@davgar.arlington.va.us>; from "David Garfield" at Jun 4, 93 1:26 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

David Garfield Said:

> Garbage Collection is an excuse to be sloppy.

Hear, Hear!  We should be careful enough not to need GC.

> Garbage collection for specific applications I have no objection to,
> and this exists now, so it may continue.

If we write a LISP, we'll definitely need it for THAT application... :-)

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From danodom@matt.ksu.ksu.edu Fri Jun  4 23:52:42 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22229; Fri, 4 Jun 93 23:52:41 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Fri, 4 Jun 93 23:52:41 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20858; Fri, 4 Jun 93 14:46:00 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA07974; Fri, 4 Jun 93 16:48:24 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306042148.AA07974@matt.ksu.ksu.edu>
Subject: Re: Home Boxes?
To: duzan@udel.edu (Gary D. Duzan)
Date: Fri, 4 Jun 93 16:48:23 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To:  <9306041116.aa18201@ori.cis.udel.edu>; from "Gary D. Duzan" at Jun 4, 93 7:16 am
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Gary D. Duzan Said:

>    Actually, all I have at home is an HP 2621P terminal. I use a
> 486DX/50 at work, though. I'm thinking of getting a low end Unix box,
> like a SPARC Classic for hacking. The sooner I can get away from ISA,
> BIOS, and 640K conventional memory, the better. I may end up with a
> 486 running 386BSD, but I'd rather not.

Hey, it's not THAT bad!  Especially if you use Linux rather than
386BSD.  You can get a low end ALPHA for $5,000 and a good one
for $10,000.  Why get stuck on a SPARC?

Seriously, though, we probably all need to decide on a
standard set of tools to write this thing with.  If Dennis uses TASM,
I use gas, and somebody else uses MASM, we'll be stuck.  I suggest
selecting GNU tools -- that way we won't have to pay for them if we
don't have them.

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From ANDREASA@dhhalden.no Sat Jun  5 12:17:54 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA04881; Sat, 5 Jun 93 12:17:53 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Sat, 5 Jun 93 12:17:53 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09078; Sat, 5 Jun 93 03:07:21 -0700
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <21283-0@fenris.dhhalden.no>; Sat, 5 Jun 1993 12:07:10 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Sat, 5 Jun 93 12:07:00 GMT+1
To: moose-programmers@sfu.ca (Moose List)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 5 Jun 93 12:06:41 +0100
Subject: Re: Home Boxes?
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <5ECCE958D0@sofus.dhhalden.no>
Status: OR

> Seriously, though, we probably all need to decide on a
> standard set of tools to write this thing with.  If Dennis uses TASM,
> I use gas, and somebody else uses MASM, we'll be stuck.  I suggest
> selecting GNU tools -- that way we won't have to pay for them if we
> don't have them.

Borland has got a very liberal copy policy. You can distribute x number of
copies, as long as only one is used at a time, and since we are spread
through out the world, that wouldn't be any crucial difficulties, if someone
has got a *legal* copy of it!

If we use GNU, mustn't we agree on some special policy things then. BTW, we'll
need an assembler for MOOSE anyway, so why don't we put our language group
to do it? It is very easy to make a simple assembler! Only to hardcode the
different op-codes to the different asm. commands.
MASS, Moose ASSembler.
> --
> Dan Odom
> danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS
>
> Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

Nough bullshit from me:-).

Arff

PS. Do you read alt.spam? No? Do! DS.
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From danodom@matt.ksu.ksu.edu Sat Jun  5 19:20:50 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09461; Sat, 5 Jun 93 19:20:49 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Sat, 5 Jun 93 19:20:49 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14651; Sat, 5 Jun 93 10:16:47 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA27244; Sat, 5 Jun 93 12:19:09 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306051719.AA27244@matt.ksu.ksu.edu>
Subject: Re: Home Boxes?
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Sat, 5 Jun 93 12:19:09 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <5ECCE958D0@sofus.dhhalden.no>; from "Andreas Arff" at Jun 5, 93 12:06 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Andreas Arff Said:

> Borland has got a very liberal copy policy. You can distribute x number of
> copies, as long as only one is used at a time, and since we are spread
> through out the world, that wouldn't be any crucial difficulties, if someone
> has got a *legal* copy of it!

I got a legal copy of BC++ 3.1.  If you think I'm going to upload it,
you're nuts.  It's like 16 HD floppies.

> If we use GNU, mustn't we agree on some special policy things then.

Not if Moose is going to be free software, which, as far as I know, it
will be.

> BTW, we'll
> need an assembler for MOOSE anyway, so why don't we put our language group
> to do it? It is very easy to make a simple assembler! Only to hardcode the
> different op-codes to the different asm. commands.
> MASS, Moose ASSembler.

OK, let's do it.  I'm posting another (short) mesage about this - read it.

> > Support the League for Programming Freedom.  Mail lpf@uunet.uu.net
> 
> Nough bullshit from me:-).

Hey, now, what's THAT supposed to mean? :-)

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From danodom@matt.ksu.ksu.edu Sat Jun  5 19:30:49 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09524; Sat, 5 Jun 93 19:30:49 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Sat, 5 Jun 93 19:30:49 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14926; Sat, 5 Jun 93 10:28:03 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA27676; Sat, 5 Jun 93 12:30:34 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306051730.AA27676@matt.ksu.ksu.edu>
Subject: Vacation and Groups
To: moose-programmers@sfu.ca (Moose List)
Date: Sat, 5 Jun 93 12:30:34 CDT
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Well, guys, the time has finially come - I'm going on vacation for a
few weeks.  Before I go, I've got a proposal or two...

We are not getting a lot done within our current 'corporate'
structure.  We are getting some things, like the kernel spec, started,
but we could be working on the compiler and UI specs as well.  I
propose that we split in to groups NOW, like we've been planning to do
all along.  Let's not discuss it - let's just get up off our asses and
do it.  I'll be here until about 5:00 Monday morning, CST (about 10:00
GMT, I think), and am 90% likely to be reachable by using ntalk
on the address below, by mailing me (I check mail every hour or so),
or on the #unix IRC channel (that's usually at night).  If you ntalk
and I don't respond, just wait - I'll get here eventually.  If anybody
has a copy of the old Group Structure message, pull it up and repost
it.  I would, but all my old Moose mail got nuked in a disk crash :-(.

Moose has been 'officially' in progress since before Christmas.  Let's
finially get around to starting.  I don't mean coding, I mean writing
some coherent specs.  Let's set a deadline (say, 1 October to have all
specs complete and to begin coding).  LET'S DO IT!!!

Oh, and put me in the language group. :-)

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From danodom@matt.ksu.ksu.edu Sat Jun  5 19:40:04 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09645; Sat, 5 Jun 93 19:40:04 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Sat, 5 Jun 93 19:40:04 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA15117; Sat, 5 Jun 93 10:36:59 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA28060; Sat, 5 Jun 93 12:39:25 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306051739.AA28060@matt.ksu.ksu.edu>
Subject: Re: Home Boxes?
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Sat, 5 Jun 93 12:39:25 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <6610150A50@sofus.dhhalden.no>; from "Andreas Arff" at Jun 5, 93 7:22 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Andreas Arff Said:

[ Stuff about copying BC++ deleted ]

> Well, we'd only need TASM:-)

I can upload it; it's not that long.  BUT, why not use A86?  It's
free, and a decent assembler, too.

[ Stuff about GNU policy deleted ]

> > Not if Moose is going to be free software, which, as far as I know, it
> > will be.
> 
> Yeap.

Then what's the problem?

[ LPF plug and comments deleted ]

> Can't we take that discussion on alt.flame, I'm in a bad mood today:-(.

Ah, Arrf supports software patents.  Maybe I'll post my League
position papers to the list... :-0

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From ANDREASA@dhhalden.no Sat Jun  5 19:25:36 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA09500; Sat, 5 Jun 93 19:25:36 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Sat, 5 Jun 93 19:25:36 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA14799; Sat, 5 Jun 93 10:22:53 -0700
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <26042-0@fenris.dhhalden.no>; Sat, 5 Jun 1993 19:22:47 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Sat, 5 Jun 93 19:22:36 GMT+1
To: moose-programmers@sfu.ca (Moose List)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 5 Jun 93 19:22:25 +0100
Subject: Re: Home Boxes?
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <6610150A50@sofus.dhhalden.no>
Status: OR

> Andreas Arff Said:
>
> > Borland has got a very liberal copy policy. You can distribute x number of
> > copies, as long as only one is used at a time, and since we are spread
> > through out the world, that wouldn't be any crucial difficulties, if someone
> > has got a *legal* copy of it!
>
> I got a legal copy of BC++ 3.1.  If you think I'm going to upload it,
> you're nuts.  It's like 16 HD floppies.

Well, we'd only need TASM:-)

> > If we use GNU, mustn't we agree on some special policy things then.
>
> Not if Moose is going to be free software, which, as far as I know, it
> will be.

Yeap.

> > BTW, we'll
> > need an assembler for MOOSE anyway, so why don't we put our language group
> > to do it? It is very easy to make a simple assembler! Only to hardcode the
> > different op-codes to the different asm. commands.
> > MASS, Moose ASSembler.
>
> OK, let's do it.  I'm posting another (short) mesage about this - read it.

I got to messages from you, right - but they both where the same:-)

> > Nough bullshit from me:-).
>
> Hey, now, what's THAT supposed to mean? :-)

Can't we take that discussion on alt.flame, I'm in a bad mood today:-(.

> Dan Odom
> Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From danodom@matt.ksu.ksu.edu Sat Jun  5 20:59:41 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10257; Sat, 5 Jun 93 20:59:40 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Sat, 5 Jun 93 20:59:40 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17035; Sat, 5 Jun 93 11:55:41 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA00277; Sat, 5 Jun 93 13:58:06 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306051858.AA00277@matt.ksu.ksu.edu>
Subject: Re: Home Boxes?
To: ANDREASA@dhhalden.no (Andreas Arff)
Date: Sat, 5 Jun 93 13:58:05 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <6729706595@sofus.dhhalden.no>; from "Andreas Arff" at Jun 5, 93 8:28 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Andreas Arff Said:

> Havn't read the GNU licens agreement so...

All it says is that, if you use any GNU code in your program, you must
distribute it under the terms of the GNU license, which says that if
anyone uses code from your program in their programs, they must
distribute it under the terms of the GNU license, which says that...

> > Ah, Arrf supports software patents.  Maybe I'll post my League
> > position papers to the list... :-0
> 
> Supports and supports, weeeeell I don't mind beeing the owner of licensed
> software. After, we are all programmer, and our work is our hobby, but
> when we work with our hobby, we need money for.

The league has nothing against copyrighted and licensed software; the
FSF and Project GNU do, but they are both independent of the LPF.  All
three were founded by the same guy (Richard Stallman, a.k.a. RMS), but
are different entities.  The League does _not_ oppose copyright on
individual programs.  We do oppose software patents, and also UI
copyright.  If anyone is interested, I can send you our paper `Against
Software Patents'.  I have it in TeX source form and in Postscript.

> I suggest you to send your papers to njale@dhhalden.no. You'd do the world
> a huge favour!

Uh oh.. Why?

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From ANDREASA@dhhalden.no Sat Jun  5 20:33:28 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10092; Sat, 5 Jun 93 20:33:27 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Sat, 5 Jun 93 20:33:27 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA16431; Sat, 5 Jun 93 11:29:14 -0700
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <26802-0@fenris.dhhalden.no>; Sat, 5 Jun 1993 20:28:58 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Sat, 5 Jun 93 20:28:48 GMT+1
To: moose-programmers@sfu.ca (Moose List)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 5 Jun 93 20:28:24 +0100
Subject: Re: Home Boxes?
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <6729706595@sofus.dhhalden.no>
Status: OR

> I can upload it; it's not that long.  BUT, why not use A86?  It's
> free, and a decent assembler, too.

Why not.

> Then what's the problem?

Havn't read the GNU licens agreement so...

> [ LPF plug and comments deleted ]
>
> > Can't we take that discussion on alt.flame, I'm in a bad mood today:-(.
>
> Ah, Arrf supports software patents.  Maybe I'll post my League
> position papers to the list... :-0

Supports and supports, weeeeell I don't mind beeing the owner of licensed
software. After, we are all programmer, and our work is our hobby, but
when we work with our hobby, we need money for.

I suggest you to send your papers to njale@dhhalden.no. You'd do the world
a huge favour!

Arff
Note: Dann, two ff's!

> Dan Odom
> danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From ANDREASA@dhhalden.no Sat Jun  5 21:17:44 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA10586; Sat, 5 Jun 93 21:17:42 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Sat, 5 Jun 93 21:17:42 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA17407; Sat, 5 Jun 93 12:12:37 -0700
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <27267-0@fenris.dhhalden.no>; Sat, 5 Jun 1993 21:12:32 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Sat, 5 Jun 93 21:12:21 GMT+1
To: moose-programmers@sfu.ca (Moose List)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 5 Jun 93 21:11:59 +0100
Subject: Re: Home Boxes?
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <67E3B03DE9@sofus.dhhalden.no>
Status: OR

> The league has nothing against copyrighted and licensed software; the
> FSF and Project GNU do, but they are both independent of the LPF.  All
> three were founded by the same guy (Richard Stallman, a.k.a. RMS), but
> are different entities.  The League does _not_ oppose copyright on
> individual programs.  We do oppose software patents, and also UI
> copyright.  If anyone is interested, I can send you our paper `Against
> Software Patents'.  I have it in TeX source form and in Postscript.

Could agree with that:-).

> > I suggest you to send your papers to njale@dhhalden.no. You'd do the world
> > a huge favour!
>
> Uh oh.. Why?

The most restrictive guy in this school:-).

> Dan Odom

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From uunet.UU.NET!davgar!davgar.arlington.va.us!david Sun Jun  6 05:06:27 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16028; Sun, 6 Jun 93 05:06:26 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Sun, 6 Jun 93 05:06:26 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA27894; Sat, 5 Jun 93 20:03:46 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA11635; Sat, 5 Jun 93 23:04:06 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 230206.25602; Sat, 5 Jun 1993 23:02:06 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Sat, 05 Jun 1993 21:07:44 EDT
Date:      Sat, 05 Jun 1993 21:07:41 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c114361.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose List" <moose-programmers@sfu.ca>
Subject:   Re: On Garbage Collection [djg32]
Status: OR

Dan Odom Said:
> David Garfield Said:
>
> > Garbage Collection is an excuse to be sloppy.
>
> Hear, Hear!  We should be careful enough not to need GC.

Actually, I've been thinking, and the lost memory check for garbage
collection is a good thing.  It is one of the sanity checks you can
run to make sure yoou haven't done anything wrong.  We shouldn't
actually free any lost memory found, just tell the user the system is
on the "fubar" and should be repaired, or at least restarted.

> > Garbage collection for specific applications I have no objection to,
> > and this exists now, so it may continue.
>
> If we write a LISP, we'll definitely need it for THAT application... :-)

Exactly.

--David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Sun Jun  6 05:05:35 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16019; Sun, 6 Jun 93 05:05:34 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Sun, 6 Jun 93 05:05:34 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay2.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA27867; Sat, 5 Jun 93 20:02:37 -0700
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA11449; Sat, 5 Jun 93 23:03:05 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 230207.25607; Sat, 5 Jun 1993 23:02:07 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Sat, 05 Jun 1993 22:25:10 EDT
Date:      Sat, 05 Jun 1993 22:25:01 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c115587.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Re: Synchronous/Asynchronous, one more try. [djg33]
Status: OR

"> " is Gary D. Duzan
"> =>" is David Garfield (me)

> =>I fully agree that either the standard library (or whatever we call
> =>it) or the kernel should include a synchronous communication layer,
> =>but still assert that the kernel must include an asynchronous
> =>communication layer at at least as low a level.  I agree that
> =>programmers should be encouraged to use the synchronous forms unless
> =>the applications calls for something else.
> =>
>    Ok, so we do both, with synchronous being primary, with asynchronous
> being equal or secondary, depending on architecture and implementation.
> Good enough?

Not Good enough.  If threads are light enough, sending a message to an
object can constitute starting a new thread.  Waiting for the message
to be finished constitutes waiting for the thread to end.

My argument is that asynchronous is the primary and synchronous is
equal or secondary, depending on architecture and implementation.

> =>Peter, my challenge stands.
> =>}} All right, try this:  under Unix, write a program that reads data from
> =>}} two data sources and does different things with the data, such that:
> =>}}         1) only one process is used
> =>}}         2) select() is not used
> =>}}         3) either data source can produce data that will be processed
> =>}}            imeadiately (sp?)
> =>}}         4) the program does not eat CPU time
> =>}}
>
>    I think my point would be that the question is flawed. :-)  You
> assume that #1 is bad, while I would say that multiple processes
> might be a reasonable way of dealing with multiple streams. If the
> processes (threads) are light enough, this shouldn't be a problem.

Multiple processes are the classical Unix way of solving this problem.
My point is that, with asynchronous I/O, it isn't needed.  And if you
needed to somehow interrelate the data from the multiple streams,
multiple processes isn't a good idea because you need to feed it all
to one process anyway.  As for the possibility of having the same
memory space for both processes, this is a possibility, but it means
you must right a fully multi-tasking application.  While many things
need to be capable of multi-tasking (like all our object management
code), we shouldn't make applications do it when it isn't needed.

Incidentally, #2 is because select() is a primative step towards
asynchronous I/O.  #4 is because the other way to solve this is to do
alternate non-blocking reads (reads that return immeadiately but
report that they did nothing), and this solutions is not compatible
with a multitasking environment.

--David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Sun Jun  6 05:06:41 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16041; Sun, 6 Jun 93 05:06:40 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Sun, 6 Jun 93 05:06:40 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA27892; Sat, 5 Jun 93 20:03:45 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA11576; Sat, 5 Jun 93 23:04:03 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 230208.25614; Sat, 5 Jun 1993 23:02:08 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Sat, 05 Jun 1993 22:53:55 EDT
Date:      Sat, 05 Jun 1993 22:53:51 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c115c44.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: moose-programmers@sfu.ca
Subject:   Software Licenses [djg34]
Status: OR

Before I begin, let me say it has been a while since I read either 
license agreement, but:

Andreas Arff wrote:
> Borland has got a very liberal copy policy. You can distribute x number of
> copies, as long as only one is used at a time, and since we are spread
> through out the world, that wouldn't be any crucial difficulties, if someone
> has got a *legal* copy of it!

I believe Borland's policy is that you may transfer you software from 
one machine to another, PROVIDED you remove all copies from the 
original machine.  Thus, you may use it like you would use a book.  
You may pass it around, but only one person can have it at any one 
time.  

Andreas Arff wrote:
> If we use GNU, mustn't we agree on some special policy things then.
Dan Odom wrote:
> Not if Moose is going to be free software, which, as far as I know, it
> will be.

The GNU policy is the so called "Copyleft", more formally the GNU 
General Public License.  I believe it policy is basically, "If it 
includes ANY GNU code, it is FREE SOFTWARE and you must give source 
when you give an executable.  The particularly NASTY part about this 
is that it applies to the C run time libraries.  I do not believe that 
it applies to the output of the compiler if it did not apply to the 
input.  This should make the GNU compilers/assemblers usable by us.  


On the subject of Moose being free, I can agree to it being free, but 
not to it being strictly under the GNU General Public License.  It is 
more reasonable to say "you may have this under the GNU General Public 
License, or you may have it under these other terms".  There is at 
least one other general license out there.


Andreas Arff wrote:
> MASS, Moose ASSembler.
Nice name.

--David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From danodom@matt.ksu.ksu.edu Sun Jun  6 07:52:34 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23647; Sun, 6 Jun 93 07:52:33 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Sun, 6 Jun 93 07:52:33 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA28955; Sat, 5 Jun 93 20:49:38 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA16432; Sat, 5 Jun 93 22:52:07 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9306060352.AA16432@matt.ksu.ksu.edu>
Subject: Re: Software Licenses [djg34]
To: david@davgar.arlington.va.us (David Garfield)
Date: Sat, 5 Jun 93 22:52:05 CDT
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To: <2c115c44.davgar@davgar.arlington.va.us>; from "David Garfield" at Jun 5, 93 10:53 pm
X-Mailer: ELM [version 2.3 PL11]
Status: OR

David Garfield Said:

> I believe Borland's policy is that you may transfer you software from 
> one machine to another, PROVIDED you remove all copies from the 
> original machine.  Thus, you may use it like you would use a book.  
> You may pass it around, but only one person can have it at any one 
> time.  

It may be installed on more than one machine at a time (e.g., your
home and your office), but it can only be in use on one machine at a
time.

> The GNU policy is the so called "Copyleft", more formally the GNU 
> General Public License.  I believe it policy is basically, "If it 
> includes ANY GNU code, it is FREE SOFTWARE and you must give source 
> when you give an executable.  The particularly NASTY part about this 
> is that it applies to the C run time libraries.  I do not believe that 
> it applies to the output of the compiler if it did not apply to the 
> input.  This should make the GNU compilers/assemblers usable by us.  

<sigh>  One of GNU's chief complaints is that people often
misinterpret the GPL this way.

>From Section 6, Paragraph 1 of the GNU Library General Public
License, Version 2 of June 1991:

``A program that contains no derivative of any portion of the Library,
but is designed to work with the Library by being compiled or liked
with it, is called a ``work that uses the Library''.  Such a work, in
isolation, is not a derivative work of the Library, and therefore
falls outside the scope of this license.''

>From Section 7, Paragraph 1:

``As an exception to the Sections above, you may also compile or link
a ``work that uses the Library'' with the Library to produce a work
containing portions of the Library, and distribute that work under
terms of your choice, provided that the terms permit modification and
reverse engineering for debugging and such modifications.''

So you see, Moose could be _commercial_ and legally make use of GNU
libraries.  All we have to do is allow the `customer' to modify it...

It's good that this license stuff is coming up now... I'd hate for
Moose to be completed before we discover that we all want distribution
on different terms.

I have two requirements for the Moose license:  Moose must be free,
and the source code to Moose must be freely available.  That's it.
When I joined the project I got the impression that both of the above
would apply, so I'm not too worried about it.

Before you jump down my throat about commercial software, let me say
that I am NOT opposed to copyright on individual programs, and neither
is the League for Programming Freedom.  Hell, I make my (meager)
living off of software.  The reason that I want Moose
to be free has to do with the kind of people who tend to use free
software...  Think of all the gurus you've known, and of how many used
SysV over the (free) Berkely UNIX.  On the PC, most (if not all) of
the Truly Great people I've known used Linux/Minix rather than SCO or
QNX.  I don't want some accountant running Lotus 1-2-3 on Moose; I'd
rather have some student running his cryptanalysis software on it.

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From ANDREASA@dhhalden.no Mon Jun  7 11:06:26 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA27200; Mon, 7 Jun 93 11:06:25 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Mon, 7 Jun 93 11:06:25 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA03133; Mon, 7 Jun 93 02:03:22 -0700
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <04944-31@fenris.dhhalden.no>; Mon, 7 Jun 1993 10:59:33 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Mon, 7 Jun 93 10:59:22 GMT+1
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 6 Jun 93 21:54:07 +0100
Subject: Doooomed
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <8097E8747A@sofus.dhhalden.no>
Status: OR

Anybody for a talk session?

Please mail me.

I'll be at andreasa@gyda.dhhalden.no.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From uunet.UU.NET!davgar!davgar.arlington.va.us!david Mon Jun  7 07:02:10 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA23986; Mon, 7 Jun 93 07:02:08 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Mon, 7 Jun 93 07:02:08 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA27546; Sun, 6 Jun 93 21:59:24 -0700
Received: from spool.uu.net (via localhost) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA29575; Mon, 7 Jun 93 00:59:11 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 005716.11078; Mon, 7 Jun 1993 00:57:16 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Mon, 07 Jun 1993 00:51:26 EDT
Date:      Mon, 07 Jun 1993 00:51:21 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c12c950.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Dan Odom" <danodom@matt.ksu.ksu.edu>
Cc: "Moose Project" <moose-programmers@sfu.ca>
Subject:   Re: Software Licenses [djg35]
Status: OR

Dan Odom Said:
> David Garfield Said:
>
> > I believe Borland's policy is that you may transfer you software from
> > one machine to another, PROVIDED you remove all copies from the
> > original machine.  Thus, you may use it like you would use a book.
> > You may pass it around, but only one person can have it at any one
> > time.
>
> It may be installed on more than one machine at a time (e.g., your
> home and your office), but it can only be in use on one machine at a
> time.

Borland Says: [Exact quote, first two paragraphs]

    This software is protected by both United States copyright law and
    international copyright treaty provisions.  Therefore, you must
    treat this software just like a book, except that you may copy it
    onto a computer to be used and you may make archival copies of the
    software for the sole purpose of backing up our software and
    protecting your investment from loss.

    By saying, "just like a book," Borland means, for example, that
    this software may be used by any number of people, and may be
    freely moved from one computer location to another, so long as
    there is no possibility of it being used at one location while it
    is being used at another or on a computer network by more than one
    user at one location.  Just as a book can't be read by two
    different people in two different places at the same time, neither
    can the software be used by two different in two different places
    at the same time (unless, of course, Borland's copyright has been
    violated).

[Note: "no possibility" on paragraph 2 line 4 is bold]

I don't know about you, but I am not willing to risk violating the
license on my copy.  My copy stays on my computer alone.


> > The GNU policy is the so called "Copyleft", more formally the GNU
> > General Public License.  I believe it policy is basically, "If it
> > includes ANY GNU code, it is FREE SOFTWARE and you must give source
> > when you give an executable.  The particularly NASTY part about this
> > is that it applies to the C run time libraries.  I do not believe that
> > it applies to the output of the compiler if it did not apply to the
> > input.  This should make the GNU compilers/assemblers usable by us.
>
> <sigh>  One of GNU's chief complaints is that people often
> misinterpret the GPL this way.
>
> From Section 6, Paragraph 1 of the GNU Library General Public
> License, Version 2 of June 1991:
>
> ``A program that contains no derivative of any portion of the Library,
> but is designed to work with the Library by being compiled or liked
> with it, is called a ``work that uses the Library''.  Such a work, in
> isolation, is not a derivative work of the Library, and therefore
> falls outside the scope of this license.''
>
> From Section 7, Paragraph 1:
>
> ``As an exception to the Sections above, you may also compile or link
> a ``work that uses the Library'' with the Library to produce a work
> containing portions of the Library, and distribute that work under
> terms of your choice, provided that the terms permit modification and
> reverse engineering for debugging and such modifications.''
>
> So you see, Moose could be _commercial_ and legally make use of GNU
> libraries.  All we have to do is allow the `customer' to modify it...

Well, the copy of GCC that I have on my 486 is DJGPP 2.1.  This is
under Version 1 of GPL.  Version 1 was before they figured out this
CORRECT INTERPRETATION that I described, that apparently lasted for
many years.

> It's good that this license stuff is coming up now... I'd hate for
> Moose to be completed before we discover that we all want distribution
> on different terms.
>
> I have two requirements for the Moose license:  Moose must be free,
> and the source code to Moose must be freely available.  That's it.
> When I joined the project I got the impression that both of the above
> would apply, so I'm not too worried about it.

The only additional requirement that I would make is to lose, at least
given the right conditions, GNUs restrictions on derived works (that
you must give source).

> Before you jump down my throat about commercial software, let me say
> that I am NOT opposed to copyright on individual programs, and neither
> is the League for Programming Freedom.  Hell, I make my (meager)
> living off of software.  The reason that I want Moose
> to be free has to do with the kind of people who tend to use free
> software...  Think of all the gurus you've known, and of how many used
> SysV over the (free) Berkely UNIX.  On the PC, most (if not all) of
> the Truly Great people I've known used Linux/Minix rather than SCO or
> QNX.  I don't want some accountant running Lotus 1-2-3 on Moose; I'd
> rather have some student running his cryptanalysis software on it.

I would rather have both.  Then we can try to kill MS-DOS, MS-Windows,
Windows-NT, and finally Microsoft.

--David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From mueller@sc.ZIB-Berlin.DE Mon Jun  7 10:41:29 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA26659; Mon, 7 Jun 93 10:41:27 +0200
Return-Path: <mueller@sc.ZIB-Berlin.DE>
Received-Date: Mon, 7 Jun 93 10:41:27 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from sc.ZIB-Berlin.DE by whistler.sfu.ca (5.65/SFU-2.0)
	id AA02771; Mon, 7 Jun 93 01:38:13 -0700
Received: from ave.ZIB-Berlin.DE by sc.ZIB-Berlin.DE (4.1/SMI-4.0-sc/03.06.93)
	id AA01996; Mon, 7 Jun 93 10:38:05 +0200
Received: from avex.ZIB-Berlin.DE 
        by ave.ZIB-Berlin.DE (4.1/SMI-4.0/1.9.92 )
	id AA01111; Mon, 7 Jun 93 10:38:04 +0200
Date: Mon, 7 Jun 93 10:38:04 +0200
From: mueller@sc.ZIB-Berlin.DE (Peter Mueller)
Message-Id: <9306070838.AA01111@sc.zib-berlin.dbp.de>
To: moose-programmers@sfu.ca
Subject: Pthhbbbt. [06/07, pem]
Status: OR


> =>[Subject should be more like 'phew!']
> =>
> =>I know, I know, I know. Actually I'm extremely too late. But I think I should
> =>write something, too. Now.
> =>
> =>I'm currently trying to get some order in my received Moose mails. A can't help
> =>me, but I've read some of the 'Pthhbbbt' mails. I read some sort of:
> =>
> =>... Moose should be useful ...
> =>... Moose should be easy to program ...
> =>... Moose should grab much acceptance ...
> =>
> =>Well, well, well. Nice goals, though. But: How is it in reality? If you want 
> =>Moose to be used in a wide spreaded user area you will have to consider the
> =>following thing:
> =>
>    [ ... Stuff about DOS and Unix interfaces ... ]
> 
>    Are you talking about shells, APIs, or binaries? None of these
> should be in the base package, IMHO. Well, maybe a shell, but not
> the others.

Yup. I think that's the first part. (I don't think, that it is too much work
to add, for example, a shell with ms-dos-like commands.) I still believe, 
offering the user a well-known interface will give us much more acceptance.
Especially when commands provide the same 'look-and-feel'.

In the second part (which must be NOT implemented now!!!) I wish to offer
an object, say MSDOS, where it should be possible to execute 'normal' msdos
programs. (Again: I don't want it NOW! It's just a future view.)

Sorry, if I've again had said something, which was misunderstood ...

Peter


PS: But that's for the GUI/TUI designer. As this is not my primer
part, I will go and concentrate on IPC and ROI ;-)

> 
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts
> 
> 
> 
> 


From danodom@matt.ksu.ksu.edu Wed May  5 22:36:00 1993
Received: from dmi.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA15285; Wed, 5 May 93 22:35:59 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Wed, 5 May 93 22:35:59 +0200
Received: from whistler.sfu.ca by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12555; Wed, 5 May 93 13:32:06 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA12024; Wed, 5 May 93 15:33:05 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9305052033.AA12024@matt.ksu.ksu.edu>
Subject: Moose Volume [djo8]
To: moose-programmers@sfu.ca (Moose List)
Date: Wed, 5 May 93 15:33:04 CDT
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Well guys, after tallying all of the messages in my mailbox for three days,
I must say that Moose has impressed me: it has a higher volume than the
Turbo C++ mailing list, even during a low period like this one.

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From rideau@clipper Thu Jun 24 22:59:00 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18811; Thu, 24 Jun 93 22:58:58 +0200
Return-Path: <rideau@clipper>
Received-Date: Thu, 24 Jun 93 22:58:58 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from nef.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA10730; Thu, 24 Jun 93 13:45:03 -0700
Received: from dmi.ens.fr by nef.ens.fr (5.65c8/ULM-1.0)
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from brick.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA18630; Thu, 24 Jun 93 22:44:04 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9306242044.AA18630@clipper.ens.fr>
Subject: Various subjects [far36]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Thu, 24 Jun 93 22:44:04 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

#--- begin manage/ideas/mailist.far ---
MOOSE messages
--------------
There haven't been many messages those times (or have I been missing it all).
I think the fact that we write messages in good english does slow the
discussion. Don't be reluctant to throw your ideas through the mail, even
if it's not finished.
#--- end manage/ideas/mailist.far ---


#--- begin manage/ideas/moose.far ---
(A-)Synchronousness
-------------------
let's have an occam-like SEQ/PAR construct in the system, and end
with the quarrel. When you want synchronous IO, you use SEQ mode;
when you want asynchronous IO, you use PAR mode. Both modes are
implemented. Really, I see no point in quarrel about synchronousness.
Please implement both sync&async and let the programmer choose. BOTH
are important (also remember you can hardly build PAR from SEQ, and
you can't feasably build SEQ from PAR).

Linking objects
---------------
 Info objects must contain:

Code:
- what are the implicit or explicit parameters; what is read,
and what is changed.
- How it changes data.
- What other code is called; what other code calls me.

Data:
- who can read and who can write.
- what it can read or write.
- What other data is pointed at; what other data points at me.

Note again that code and data are the dual representations of the
objective computer world.



Garbage Collecting
------------------
 Garbage collecting: a system global garbage collecting is good when and
only when every pointer use is trusted and/or checked. That shouldn't be
the general global case. Local GC is fine, and should be provided inside
a standard library for apps to use it. Global GC should be used only
through system descriptors, not with directly modifiable pointers.
 This already has been talked about before, and no one saw any objection
about the memory system be modularly layered for each object indepently
from the others, with standard modules provided, with raw (on a 386, already
three layers, physical, paged then segmented) memory as standard implemented
devices above the which you can use stack, double stack (up and
down, not very useful with paged memory, but to save segment registers),
malloc, malloc/realloc, and/or GC managers etc.
 From high level, better use name services, system descriptors and other
virtual stuff. The compiler is meant to simplify, find best implementation,
etc, whenever possible. Let's end with languages and compilers which can
only handle optimize code but not data. Let's have our data as virtual as
code, our code as handy as data.
  This means standard compiler output including info on how they implemented
HL constructs into LLL/asm.


Demand paging & scheduling
--------------------------

Demand paging seams is ok, but the MacIntosh shows that sometimes you'd like
pages to be loaded BEFORE they are demanded, while the system is just
waiting, 'cause ye know they're _very_ likely to be demanded: else you'll
have to wait when you demand the pages. Example: when you load Word 5 for
the Mac, it won't fetch every (any?) command (that's good: you don't need
them all); it loads a command the first time you use it, so at this time,
you have to wait for disk access. But as the system waits for your commands,
it would have been nice if it used this idle time to fetch commonly used
commands as cursor displacement or block commands.


MUSIC
-----

What's Good With

* MS-LoseDoze: scroll bars that appear when and only when necessary (but
that's only a detail, and it's not perfect).
* MacIntosh: extension is just easy BUT requires complete rebooting to
 take effect.

What's Wrong With

* MS-LoseDoze: everything that remains !
* MS-LoseDoze & MacIntosh
 - it's a user-unextensible interface; you CAN'T program it at user level.
 (ever tried a series of MANUAL search and replace ? I meant the same long
 series to call for 20 different files). When something lacks in a software,
 you just have to redo the software from scratch or wait hopefully for
 your problem to solve in the next version.
 - it's an screen only interface only software: you can easily share
 anything that displays on a screen, but you just can't really efficiently
 share generic objects. Actually, Apple & MicroShit think their product are
 OSes, they just are naughty interfaces.

* Everything but Borland products:
 - even a programmer can't program it without having read a (Mac: huge;
 MS-LoseDoze, worse: buggy) documentation !
 - even when the programmer manages anything, he can't append it to the app
 he uses, so he all the same have to wait for next version of the app, or be
 ready to rewrite and maintain his own app (true of all existing
 systems) !!!!

What should be good about MUSIC
- included should be copy/paste sub-windows (physical aspect a/o logic),
w/ or w/out mask. Thus, if a utility offers some interesting icon, you
can duplicate it and put it where you want (example: hour, etc). There's
NO need for special functions to do that, because iconized objects have been
interfaced, thus have a descriptor, thus can have this descriptor duplicated.
This means each opened library should remember new descriptors on temporary
objects that should not be released.
- copy/paste should only be a specialization of push/pop and even
read/write to any object IO device understanding the copied/pasted object's
class.
#--- begin manage/ideas/moose.far ---

Let's begin Coding
------------------

* There seems nobody has anything fundamental to add about specs.
So let's begin coding. When one needs some implementation convention,
just publish it, and continue until some decision has been taken, then
modify code accordingly.

* languages used. For device programming, let's use ANSI C and
Assembly (I vote for TASM, but perhaps you'll prefer GAS).
TASM has got good macros et al. and uses standard Intel pseudo-code.
GAS seems to have good macros, but uses non-standard pseudo-code for
intel instructions.
The language team (including myself) will build a C to HLL compiler, and
an assembler into HLL embedder.
C code will have to include HLL directives inside comments.

* C writing conventions. I propose something like the code I'm sending.
* ASM writing conventions. It will depend on the assembler used, but
that's what I propose. We'll add info about parameters inside macros like
DefParam (char near *) Dest in eax

* Object support in C and Assembly.
I'm sending an Object description library in C. Its purpose is only for
booting a HLL compiler in the language itself from only C and ASM. But
actual implemented public MOOSE object are very likely to look like that
(remember that only public objects need descriptors). So please look at
the logical part of it and state what these objects lack, or what they have
and shouldn't.
Please comment. Problem:
what kind of pointers to use in MOOSE implementation: near pointers, far
pointers or system only pointers ?

* Presentation: we should all use the same style in programming, naming,
etc. First, let's not use tab characters, but 8 char long (and even then,
let's restrict ourselves) (oops ! I hope this file doesn't contain tabs )-8
Then, I propose we use uppercase for beginning of words (i.e. WriteToDisk
and suches), without underscores, but to define types when C of ASM wanted
a name (i.e. const zap zap_1 = { &zap_2,1 }, when C required named zap
structure). Well, we'll see and we'll vote.

* For IO (Especially disk I/O and SuperVGA programming), we can get
docs from Linux and/or XFree drivers code, and other PD code.

* Regularly publish your code, even tiny. Proceed by month release, then
diffs relative to it.

#--- end manage/ideas/moose.far ---

#--- begin manage/ideas/manage.far ---
Project Management
------------------
* Let's define a common MOOSE tree.
Here is what I propose.
MOOSE (
  MANAGE (MAILLIST,    ; for project management: mailing list contents,
	  WHODOESWHAT, ; what's done, what's to do, who does/did/will do it
	  IDEAS,       ; lists of ideas, each subject managed by one person.
	  OLD),	       ; old stuff
  SPECS  (MOOSE,	; Generic MOOSE specifications
	  LANGUAGE,	; Low/High Level Language and compiler specs
	  386IMPL,      ; 386 implementation specs
	  PROGRAMG,	; programming conventions
	 )
  BIN    (386),
  386    (BOOT,					; how to boot from BIOS
	  NUCLEUS,				; nucleus
	  BASEOBJ (BASIC,CLASS,IO)		; management of basic objects
	  DRIVERS (MEM,TIME,DISK,SERIAL,GRX,FPU); hardware devices
	  ; perhaps a XMS/VCPI/DPMI compatible version someday ?
	 ),
  LIBSRC (
	  OBJECTS(GENERIC,BASIC,CONTAINERS,IO),	;
	  MEM(GENERIC,GRAIN,FLAT,ALLOCRE,GC),	;
	  FILING(FAT,OOFS,HPFS,LINUXFS),	; (sub) file systems
	  GRX(RAW,WINDOWS),			; HL code for graphix
	  SYSTEM(THREAD,SPOOL),			; HL code for multi*
	  DBASES(GENERIC,DBA),			; relational databases
	  MATH(SETS,NUMBERS,LINEAR,ANALYSIS),	; math libraries
	  EMU(DOS,UNIX,APPLE2)			; emulate DOS, Unix, etc.
	 ),
  COMPIL (BOOT(386,CUTILS),		;booting stuff, C utilities
	  OSL,				;stack language to bootstrap compiler
	  TREES,			;internal object representation def.
	  PARSING,			;parsing= treeing text
	  CASTING,			;manage implicit type cast
	  OPTIMIZG,			;optimizing trees
	  GENERATG(OSL,386),		;generating code from trees
	  ASSEMBLE,			;assembling, unassembling
	  CTRANSLAT,			;C to (from) HLL translation
	  INTERPRET			;tree interpreter/debugger
	 )
)

* 'bout IDEAS directory, here's how it's going to be. Each subject has
a file (name:8 chars :-( ), maintained by only one person. Those who
want to add things write FILENAME.PER files, where Filename refers to
the file's name and PER is a personal three letters identifier. The
file maintainer will include new ideas in his file and is meant to heed
.PER file ideas, but he each one is free to maintain his .PER file and
to remove an idea from it only when he thinks it was well taken into
account in the main file.
I propose a subject file for each second order subdirectory of the MOOSE
directory

* Files may be posted using the following syntax: #--- begin FILENAME ---
at the beginning of a line, #--- end FILENAME --- at the end.
I'm sure someone is able to produce an awk script to manage that, or
even .BTM 4dos script. The same person should then also be able to produce
automatic unzip-ing and/or diff-ing :-). (I think I'll do the .BTM stuff).

* Posted files should use LF only format, whereas zipped files may contain
CRLF. See your local DOS2UNIX/UNIX2DOS converter to translate. See another
utility to keep datestamp (if you have one, please send it to me, I'd like
not to have to do it myself).

* I'm willing to maintain any such file. Please state your mind via
the mail list.

#--- end manage/ideas/manage.far ---

#--- begin manage/ideas/LANGUAGE.far ---
MOOSE language issue
--------------------
Some ideas:
- Let's have a standard compiler, providing standard services and virtual
classes, from HLL to binary, through MLL,LLL,ASM, etc (when exists).
- Let's have a unified preprocessor for everything. The preprocessor will
manage compiler modules. I begun the preprocessor in HLL, and I'm translating
it to C: it uses a generic symbol table manager and a generic character input
manager, and just find a symbol in the input, execute a procedure associated
to the symbol if found, a global procedure if not found. Typical procedures
will add/remove symbols, accept new symbols, open/push/close/pop structures,
etc.
- First compiler modules are tokenizers and detokenizers (useful for
compressing source parts, but possibly expand it back to text). This is
done by putting the right symbols and procedures in the preprocessor.
- Then come token interpreters. Note that the use of exceptions as a
language feature comes handy for error processing, or even simpler code
structuring. A standard generic interpreter is provided. This also can be
done directly by using the preprocessor's symbol table. Macros can be
used by inserting text before the preprocessor. This is done by having
an input stack between the preprocessor and the raw input.
- Here, we come interpreters or list/tree builders, which manage identified
entities.
- Then will certainly come a global tree analyser, that will fill
unsynthetized fields and decide each parsed object's destiny: delete
unreferenced objects, then compile end objects, etc. Object are grouped
by mutual reference for optimization.
* Please note that a standard generic library for tree algorithms is
provided, as for any common class. Please also note that a tree is an
abstract concept independant from implementation. Implementation will
depend on particular expected shapes of implemented objects.
- Tree simplifiers and translators then come, successively called by the
global tree manager. Simplifiers "optimize" trees; translator express them
in another "language".
- Remains data packing modules to transform simplified trees into code.

All that I say to define the global shape of the compiler, but mostly
to show that we can and must provide some standard compiling features.
- someone in the group said that people don't want to learn new things.
That's inaccurate. People hate having to learn a new syntax everytime
they use a new tool, when they know this knowledge will have to be
forgotten when using then next tool. What I propose is providing a unique
syntax for all MOOSE tools. At least, if different contexts require
very different syntactic styles, provide a standard syntax for each style,
allowing easy differenciation of one from the other (example: structured
functional notation is opposite to raw listing, but it's easy to provide
both notations for the same objects with the same compiler, changing only
the list/tree building part.
- not only end-users will appreciate a standard syntax and preprocessor
(which will encompass shelling, making, compiling, interpreting, analysing,
etc), but also programmers: programmers (who, as end-users already like it)
like being able to be able to reuse code; they don't have to write it
themselves, and they are able to communicate one with the other without
having to study the other one's implementation. But for code reuse to
happen, the system must ensure that you can trust other one's code; and
it must also ensure that code interface is understandable by the human
reusers. That's why the system preprocessor must include as a standard
commenting, multiple editing, cross-referencing. This being seen as the
fact that an object has multiple aspects and can itself have influence on
several other objects, we can view that as the fact that the preprocessor
can dispatch multiple objects to multiple aspect managers.


BOOTSTRAPPING THE COMPILER
--------------------------
(default is SEQ)
PAR
  Define HLL
  Write HLL libraries /** also helps defining HLL **/
  SEQ
    PAR
      Design a format to describe objects
      in 386 ASM,
        Write a protected mode bootstrapper
        Write managers for basic OSL objects
        Write binary routines an OSL interpreter using these objects
      in C,
        Write an object manager
        Write simple IO
        Write symbol management
        Write the preprocessor
        Write an simple data compiler
        Write routines to write data in MOOSE binary format or assembly
        if using MOOSE binary, Write routines to get ASM routines' adresses
    Use the data compiler to produce assembly source or MOOSE binary
    Use the 386 booter + C object writer to write and debug binary code
    PAR
      SEQ
        optionnally build a C to OSL compiler using the  preprocessor.
        Rewrite the C preprocessor code in OSL
        Debug the OSL version of the preprocessor using
      Write in OSL a HLL parser
      Write in OSL a OSL code generator
    Finish rewriting the HLL compiler with itself
    Add features to the HLL compiler
  Write HLL compiler modules for optimization
  Write assembly code generator for the HLL, using HLL.
    /*****
    Has anyone got a complete C grammar to
  *****/
  /*****
    OSL: objective stack language; a very simple language that allows
    us using MOOSE objects, and that is very simply produced by our
    preprocessor
 *****/
  /*****
   the order in the PAR statements indicates the order to launch
   the processes, which are no independent, and tend to interact in
   that order
  *****/
END



HLL LANGUAGE DEFINITION
-----------------------
Here are the basic ideas I'd include in the HLL definition.
Please state your mind.
I wrote it similar to natural english, but if you stick to
 (*(int*)(++b->c))(&e)?x:d[++a] notations, I think it can
be included in the language too.
Basically, you define objects having subobjects and/or
operating on other objects. mutable objects can be modified,
the others can't and are constant (the default). You define
an object by constraining on it:
The compiler is meant to manage recursivity, so don't be reluctant
to ML-like functional notation.

- you define objects with some keywords like
Consider x
Define x
- you can define constraints on objects
x = 1
x : integer
- you can assume things about objects
assume that a is an integer
know that a>0
- You can define constraints while defining it.
Consider the integer x
let x be an integer
Define x: integer
Consider the integer x whose value is 1
let x be the integer 1
Define x :: integer = 1
Consider x = 1
let x = 1
Define x = 1
- You can access an object's export
a.b
a.c
- Objects have predefined exports
x.type
x.value
-
- you can define constraints on objects, which are boolean
x = 1
x+y = 0
IsEmpty(x)
x :: integer
x.type = integer
IsConstant(x)
x :: mutable integer
- you can give orders to the object
Check that a=1
a := 1
have a+b = 2 and a*b = 1
- You can define objects with a list syntax
LIST
 a ; b ; c
 LIST
   a
   b
   c
 LIST
   LIST
     a
     b
     c
   d
   e
- a list can be a list of orders
OBJECT
{
  type = Point
  x = 1
  y = OBJECT { value = OBJECT{ Consider a,b :: integer , a+b=5 , a-b=1}.a }
}
- you can have objects operate on others
a [ b ]
prefix [+] [ a , b ]
- you can define how objects operate on others
let a [ b ] = b + 1
let a = function b -> b+1
let a [{}] = {}
let a [b::l] = A [b]::a [l]
let a [x ; y] = ...
let a [x ;y ;z ] = ...
let a otherwise fail
end a's definition
a operates on integers and returns an integer
a is a function
a is an abelian group law on integers
a returns an integer and a
a operates
a does not have any static variable
a reads b
a writes b
a depends only upon c,d,e
a does not depend upon e
e does not affect a
a writes only its result,d and f
a is independent from e
let a [b] = { PAR { Write [b] }
- you can give implementation details on objects
implement a with a list
a is implemented as a raw list of short integers
a is implemented as register esi
on entry b is in register eax
input b from register eax
output b in esi
- you can give concurrent forms of an object
a is function a::longint -> a+1
   or inline i386 assembly  {input eax, inc eax, output eax}
let b = function x -> x+1
know that b restricted to longints can be implemented as a
- you can comment objects using hypertext
note that a's purpose is to make you laugh
note that these comments are boredom
about fopen, note that _mode_(view "mode description") contains
comment "mode description" is "ghheh"
- you can use the compiler's services with a standard library.
compile ["comment \""+x+"\" is \""+y+"\""]
a=compile[x]
- you can define exceptions to an object's behaviour
exception Out_of_paper | Connection_failure can occur in
  procedure print.

#--- end /manage/ideas/language.far ---


#--- begin /specs/language/cutils.doc ---
Here is the description of the C utility I'm programming to bootstrap
the MOOSE compiler.
It includes n parts: object management, symbol table management, IO
management, command line management, and a main (convert.c) program to mix
it all. All these libraries will be translated to OSL then HLL after the
first boot step is over.
- object management : it defines object, class and metaclass descriptors.
Roughly the same data format will be used for MOOSE objects. At least, the
same library will be used to process simple objects from C to MOOSE binary.
-
The uuencoded zipped C source (for BC 3.1) is given below in a zip.uu file.
#--- end /specs/language/cutils.doc ---

#--- begin /compil/boot/cutils/zip.uu ---
QUUNCD Ver. 1.2, by Theodore A. Kaldis.
BEGIN--cut here--CUT HERE--
begin 600 convert.zip
M4$L#!!0````(`+&^UQH?>H%>ZP4``%`1```)````0T].5D525"Y#G5=K;]NX
M$OT<`?X/4U\@L0TU20OLIHO<+)"Z<==`'!GUHUGD%@$M,38!B53Y<#<;Y$N`
M_;*_>H>DY,C/-:Z!(.+,F<.9,V/*/&EM^4!?BJDD&;0%GU.IF5+42#B'+?B3
M6E`++!L,9U114#.2IC"AH"7A*B6:)J`%1(-K(`J4$-S^SX52;))26&*(](Q*
MR$1B4JK`*`PM_?]A/$Y-0J'>>QP^YE0=S^I5ZV>JHUPO&_^K=,+$\>Q72[],
M,>Y&*P0=EM(U8S?*""=3NF+N"2X^FH?.BGD\>,PF(AVNF+]4S66UM:#0=TA0
MAA;$?G6O[1+.2Z#&4A/Z`)2;#)Z@,[P_FS!]?SEH=[NA75Y];'_JMMUCOQU=
M]=Q3=Q!]^/#3+^ZY1^*P%AR`_Z!AO(@=$#85W#W>C'J=Z&8X_+U_Y=8CSF*!
MR3]#1W!M!;<YU8+%:B",C*E[O%AL#N&!Z^,G^D!,J@%[K1Z5IEG1Q@/T*!\/
MU;#SW6$3(5)*.$!D=-_H]I?K#D8/I<&D#G:'UH(!U1\?->T3.]/JGEP\';[F
M'BX)^FQK7,'3-;Q7?!-6K&%=>9N@;`U:]&P3.%L#8U,W`>=KP/&VNM0:U$_#
M)JQ9PQ;CL0Y.G,!EE_]-WL3)6T5O$S=QXE:16Z1-G+15X%9A$R=L%;I1UL3)
M6H5M$35QHE:!VR1-G*15Y`Y!8WG_#M&OLQ_:R=^"/%U&=DBJ-D!;"<IW]_X;
M@E'8\-!OLA$W'I2X^4[<Y5F)(P7N="-N=%OBV$X<MJ($9CN!:EKBU";<-5,:
M4EOOQ=-["^@O35?I'@\*]WBPR7UY5K@OSS:Y1[>%>W2[R8VU%/Z5`2L!:EKX
MU?39G[.U(!8<G5&NF>!@@5$.=]_@`IYJ`<`3P&D(<#.ZO@Z+HQWZDG$]R$B:
M_D;3W)KK=7@./?R('(5PJ+`[);S(8;%&N')?<F`*SF#"M`+WO:V04$]"PX,]
M./QWN1(M?+38*[K?ANBJ5XEF/IKM%=T=1&_MM[X2G_GX[/_+?>ZCYWM%CU=D
M4SY8[17L#XU*M/'19J_H\L7=>/>S:V&S0G1IB=PTAPNFGDDURU-J&54(=7LH
M,4[<U&V?@RO+E.R<@Q6B-4&C(IE^>^]DUD:B6W",;O?FV#`8O8+%_E+:DP6A
M7:Z%FE5HQ@7->+!W,JMS,B@HU'1OBK5I&?G6[)J6%8IB9"H<L>6HO$8LB7N5
MA!42P8\TY$9#^XN""7T0DL)U1]47+.T-+/;5M92*V$;Q7)Z#,R*A!9=RJHKS
MK_ZV'N*?.RGMC[]:,.XJ+:E]'W2M<1R5R\B?IE%.N?U]KZ#1K`7N`.U>E$9H
M6.Z[TV]A74[J31L!$*VZWZ'[1^%^K@75:XO[U(*Y8`E\E4S3"!J+RP^TAF'W
MIC\:8FXW830:ND?\7R:"Y:L&KM_^^H"[A?A?E)L4G,5%X5YP3&8G5V57&/I"
MAJC8M>!3;'F/Z'@&C4.,C?T]XUX7Y39:#;MQWFPV;+J6>R6)3Z)(`QIV7>[X
M8^8D>M.AXL$RVQJ:S>64"W-XB*S._ZIA]0[)N(:,,`X-^T3D-`[!-[^%BWFY
MXU<A$YBP1'#?6VPE9_HSU>X70</%.;ROS+X*A_0/C3+4QP10F@?")`4L0L*;
M__&Z0[G8&Y--J$3@^Y)YP7KH7\"A8G_:0OVJ>;*TO#O]U@P/76:A'9FF9SEI
M.1YWS8-&.5Z5@?26BKY->]D^L49)M9$<3LM.^&E',+89#&J+`<I^BTVJ7R2C
M1M(02^186BRR'(M-*&I(,\9?K]RJ%N3"2"!IBM4F1X8C."%3"G\A)Q"C)3V&
M&PHY4?`22ZM63+5^W8WR6M`.;;,4/MNK?0C?#0-E\EQ(!&*EF3VV]$Q2DIP#
M2^$1B25Q27LK9H&]?=$D=UEJ21(3VR/I&-HS\MW0PJ>H"ZL(1.8TAI34`G]7
M)GDN12[9B^7)#>:4'OG07+[$+PGE1>H+NS)L3M"*LJ8$4:C/W[+<+V4:@1@D
M7U!,]"=4<N]'+30D5GLT*ZR4T>/R*/@'4$L#!!0````(`"AWV!H-3A$'A`,`
M`+X,```+````0T].5D525"Y$4TOM5EUOTU88?DX":4;I*`C6DHW5M(A!-J)Q
M6W;1U#G%K>HZM9U`4"3F)J?4*(D[^[BCT_8#=C=M%]LT3;O<[7[$M/\S"6D?
M-^/U1TJKIB0$KB;.T?%Q["?O\WX?VZ&_Y2FJHGH]*9Y(9<7M"*4`-G5AAA6`
M,VW\PB8!A&R-76%_X@_\!`\<LS3K5D-?-M;MDHHL3H&]8`)ZH[YJ$#*#BR=@
MWJ8U34AC>8VKMD58AE]I_7@,.8MO4:(%6+9I&_=CZ(LG<)?;1M4>":H:&W5N
M)MC,$*SYW`G#!:^LKO/8"Y&E#+D!H"E:YPE:X?44&?GEK0'(R1B=A\`/M!?P
MA/Z5PQGR;P'7R#^+6(:&%G8A42RIU6ITC99R1RF6-+JKEBV*B]VH<HM^:^6:
MK7.=,/V[LJ6#+Q9+>ED%*6,8J"PV&_S>`VXV5\HF;^HU:W6SQDOV?1L$JM@:
MWRQ5RC;)+B+BV,,ERHT<Z0_*D-.X)3AP*ZR3LM_C'-Y'0"].D\KO8A[7<1MW
M4(&%!WA(BN_`A2F<-E;;HB?=;;?E2!'Z"%H[HNO`=Q_MR``;XG.XO4#Z89=0
MZ#EN$#B]EH`E?;?WR/9@.7O"V>H(8^NQ:$D$\7/<%=+"#?<F6CN.#_`]IQ,Z
MTO.QCY]CU?9)M0F<)0L*N(*;Y$\--5)-H(,N?.QY;ELIXI[GMV,92K'X&!41
M2+0?QKO;<Z3K]6`)J8<=Z>YVQ/*^%`%:'2<(E$"VMZG:4GWH*IQNHDS?7N'#
M3(Q$U_-E:A&^P`(Y,T^*10&?HG1)PDMA2_Q>C"/])>5`!%,(-DDNO@3+"_V6
ML/=W1:Q??`,CE-50JN;Z"IZRKW,W@,MQKN*[ZY_.6Q-+N:6YI;E3^.VSB[FS
M]'2.I*[37HAPT;@<X?I[!K_?'OPF2T('O\D#,Y\@>XCU*5O*I0B*P,0)Y70A
MD4B)DDJE_^[./-_S4`^RM6H::]QN;AB-<JV9EG=S]!([B0*C46@CM(;VN!2'
M>DKV?\"A4>U-IR$9-*/>N#TNQTLUZ[&#GAQUHP0]H?@*W["Q*%1JE[/IF7'2
M:?KJ,<]0<V;4/8YSY..R.6I&4K6OW0PQ+D7_:^)EPS&6'<,_;EZ10L-5?$RB
M/AA`\2&MC_H1/^BEXU7YL*^3Q(Q_H62/<@SMN7TSWJ-CB>&=`13SM!9(T%^,
M;/B;Y=+8_,.F,G@SWHQD_$<#>`902P,$%`````@`*'?8&@4\P97:!P``)1T`
M``L```!#3TY615)4+E!22NV9:W`;5Q7'SZ[LV+'CV$GSLI*FUZFA>=1V[)+$
ML9LF\FKM*-6+E6S'B6A'EC;.!EMR5[)I@3I)7S#00J$#%!AF2H&65VE+H9^@
MS###!_I(2NG4;F#XR`R/87@6*)3E_'>ULF)B*\2FH3,]'OU\[KWGGG/WW'OW
M:E?Q"7,X*Q01-;,G]%1>]!JCNO"25+=ZO<3_JCI(J_XQR231LTRBYVS]>9LO
MV#5G;'ZO%OR^S6=L_J`6-B_9EC^U^3+30Z\P#]"T73-C\U5X\)RS_?R!R_1'
MX$_`GQG27X#7J(+H%-%?4?@;\'<8O(Y>XHD*IOQ[V\,KM5P]#<S8XW@5ZCE6
M&^AGS`KZ!_I]IY[Q3VAO,#S_@F;!*TE<E!@2DZ@"6B6P#*AB-%8STLL9H@8F
MM<`*H`Y8"=0##<`J='L(T;[(D!Z&]B5H7P:^`CP"/`I\%:U/`$^B^&W@*>!K
MJ/LZP_,-:-\$'@.^!3P.?!=X&EB-D%<@^!I@+8KK@/62D\,-*#1*R(X7%AN!
M3:B\$MIFI.`J:`+8PI"OAM8,O`-V[^3.ULEKN+C#=O->F2N/`N\!;@*&@120
M!G3@&#`"'&?0&)`!LJB[!5H.V@2T26CO@W8KM-N`]P,?`#Z(AH\!MZ,X!9P$
M3@&G@3N`.V%R%[2[@7M0_!#P810_`GP4N`^X'_@$\$G@`:"B`4L`6`94`=5`
MB^2GWBX:4@>/J%JB)Q"F2Y-6Z12I78F>B!;TA?U*(A!6@OU^E=Y,:9LSAF"@
MI]O?G5CTM?TWLI.7YW4=1.U2)77LXHH.5MIW[B2Z3CI)EUG>)6VF[0M:["IK
ML;NLQ9ZR%IUE+?:6M>@J:]%=UN+ZLA;[REK<4-9B?UF+`[QP6R8&Z'**[_(O
M3[]4S7MGS^X]K*NL=[;O[4!]+P_-W^7NXUZ?IB:4EJ@OUGU^)?T/1>%=W*I$
MH]1G'Q66Q?N9EO%)>_26&6\-;:BAJ3Y-C5Z$IQ%3'Z<EE);,#M$<4D-;VSLZ
MMXGF<"0VZ(N*YJ@6"47CHEGA0BC6MQ6CZV!EVV362(OMK2E!_U_RG"4YW^.F
MHLE<*CE*NCF?:3RJT%)*L^H/^T(J"5=YB\I/BBGTY7+ZV/#H`BGTQ4*TE$=O
MZ+!H.Q(0;1'1O-2^WTQYWJ)""OWZ\,3(R/P9I'R:EG@5'E;?RJO/E1?<%/+C
MV-0Q8X%%R!M9B_32VRF<*V<L29O2<]D),Z4+)3LV/G\6M:6]%5+S4CN\3/*2
M)4T%QL:S9EX$C6$S:1K)S#RF@5"4GQ1HZ5*XU`XOD[QHX6O.V[*X1R[ZK>03
MO4G#U+OJ:K:+D)$QQI*CK+<(M2TF<A.F.&:DCANZV8JZV&UCP]E1/=<E3#UU
M7#?Y<ZW0\RF[4<EF)G4S9V0S8M(P\Q/ZZ"B\PF\D%K1]:GHR'==OS8MQOGN(
M40XKTGI.I+.9C,[_%;%U?,+(P7P;_(J0+XIN@Z:1UWN,C---3YES.W*'NAIT
M=8,4C?\CAFU:XG(>CZ5#:75]&VE]3"0G]93(F\GT1"JO<^?T-<FTJ?-7FD)`
M7:2R:=WM$H_TQX6FJHH6T%2AAN%0-#4UN>U)/HM,(Y>$JVLQ@M(*UPA]TKH8
M3N:*?DL'X$042JFY/<I4-L-V1B:OYS`/=36[J)/?3VVA`7XN<-?`.CS;J`.!
M2*M"6H+/O$-J/!&.#/GZ$THD/*!J\83;?-'20/6TDFI8NYKNSLUX?87Z*_&\
M%`BJMK<+QRHV7ZRLIPW42,M9NXKNR<U>EX3S)S84ZHD$X[BT"\0J:;XX\=)&
MVD35K&VD0<XA'@`?YD>N>_$0YCAE7TIB5K]TP9O<"JIBK8D.<ZQVGKF57'J9
M/WUJ/!*%^X22*.J+D$I^6JSB#[*)6!^7G'H<2K&X%H\<=F(5]45(-<]5#4?$
M:ACB6/=Q_C2.]RC71'H.J4H\9N=P5K]TJ:455(?7VKQ&/LMK8Q]>>=GS2!0:
M<M>\DG#UQ<@J6DU7\)S!^Y&2_57+GX'9A98HT2]9UM!:WK<R7C4+0>+T[3_R
MMO%5^@.Q&^WK$%2H/>>Q-UQ<4]W:+WQZVGM3?<D2*MJ>DI$4IW_K0=2./##M
M?8H*J=I-KWN:N?!#>;-\5OZ-Y^>>,Y['//=Z3G@"GH?D;D^+I]9SO_R&O$.V
MK-_)>^4[Y;!TB'XA_Y*>EGIEF5\X3Y$NGY!^+7V.#MGK8"W]*C/C74-W,)=1
MX)%IKTS]/$NKZ7'.GX=V,BWK0..S_`(#Y-\*>%26*UM>.UOYX*?.5MJ[F'\?
MH,UTFGL[/DJ].OZJ;1_+:=9?K4W+FFN/.(WTXN>G"V6GS;+<.!64R<Z<U]9@
MCZJ^)(+C>T4APH7M$6<5=3[HQEE)1WER+`N;C.R5B\FJHJ;/G&\QWY74%Z+-
MM4>N*^G)9]Q:Q^/\^4!.T6<=Q8OSL*G$VK*<N;)GP3D;#MH%&!;+R'GA9NZT
M6NXNLZ?T`J_C$_Y(S+4MN35;F-7BL6#%BT$4Q[2XH0[.[YEO7(%P'RPPV<Y`
MN(!YF;W/6)CRDNUI8:K<9K;&3!7O@`N$\O/W:]@C]P5[+F$NBYMNWMXWA_N#
MP86NY.8P4K&@A5_MC2V<#+]S^5@&A2%Q"9,:&HH/156[-];+[#FVAP;MTWN`
M^BE.,=+HW12E"(4I1$&ZD7I((3_OZP`=I#[J)95\_!OD?KJ!]M'U_+>`8"/\
M&U!+`P04````"`"=EM<:B7%-D0\%``!>#P``"````$=%5$]05"Y#K5=M3]M(
M$/Y,)/[#M"<1VW$@_DKJ2&WOCD,*!0ETUQ-")Y,LR09G;7G7M!7-%S[?C[Z9
M?;$W(1RYETJH.^/=9V:>>=G-4?2__#O:[^QW?IBR.RX8G#!U7JH_3E##Q22O
MIPS>&MWA_*VOO%355?%Y7?E.JBDO#N>C#5W.;[5RO[/-9;BHBLG3M*Z8Q"6>
MXV66X_HUEQ\*/B5_+[(J6P;H(2\$1&,NE5G+^+>BFL+X?,S$3,UC+E0$[ZN9
MC"?SK$*[M)7D<+_SN-\!T-OY$`".(A#U\JDJ(*MF]9()!4Q`SF?($,8T*9;+
M3.""'`$@.(@6]F!92*Y=F69"0I[1YS_Q7%`6=06%<0V6=:YXB6&&%D0;%^O&
M"QM38R4".:30`2)R'%(8#$F27[B:S"'XF%53#/X#FW$1PJ/9.LDD@\$Q+0$X
MGDF&9KW`M28/<WG-;ZR6WT&@M1^+&N,>P2`T'X`V2V;)#7RB6Y+A@./?(K1@
M=T4%`4^3(1I^9ZT97-3T>@VR2\4U[R<W6]VZK5AV/_0BZB?'O@W-!5GQC!@;
M\.BL;`_XW\2U>N[4E-UEF-0=G3*[7O(,&M<H&W`J=4;1JR!:A-"PAL?W%KT>
M[=[;/08(&_256[!<,@0A:Z:R1M:?3_7REE5H<0^,XJ>JHM`0"MG0ENELFT!S
M/NSU*(T+1Q<<19'F)#+%C(971)OMXC7G7^]DDB+@KH\7KH'S0LQ`#-N>E(9(
MAT@+L.GZ,N<Y"]"?!;Q)!X;31R]W0C<*",R=LXO2\\P19`H'GK/78B-_9"--
M:6=_-%E+GE9)"/3_9<QC2RD9=U9["6SF:]5VJB!DMS4$WXW!S2%";VB,$0M(
MU=3K#?V$F'147*C+99;GO["\A$"S'SF^&[K+6LF`=ERQK\I@LJ]<!8D.8K5U
MWOO#_E+?*R!5)J8967AIUFNG</=55;-`"U%IBN"93U%P6Q0YRS#;88DLTI&A
M'QO"_)SE\I_BZ#/#]:JU'CV'<UR!!^A&=(2D]Y)P?3IW>]WC5DA\X=P72E_X
MW1>^=>W@>8&`-MWPTD#M]GW`@2]\\@7QDBG'T=_;6I^3[4P)>`Q-9;H#&X6)
MC)_9B_/#-\7D*TG4N3`P>)).4#=$<)&6;@SH7K\W<_J>YG1_)`"73:-'`:K.
MKN]O^J,RI"GMI(>FR*7*%)^`\]",S//J1Q-H0%,I@C(&-[;`S:UXO[.WMV=:
M&QR7I](>C/4XL\*6$6>>*XDW[E0,4=W*MS9&GJ#?$=<?:%A1`6I!#R=%$V1]
M`&H])WU[;?F/@&T9,S?(VFA$#*\&C.WFDHN:^W=ET^QCM)YUTRY\_PY6..Z&
MH!PF3<D3IDZ%8C.&:53Q01U"$YE*TSILX1I>0XBH6JT$GO_KL2TLEOYB@R)6
MB$][B`8[U/U6)F`!7N%N%L59LEZS6VZQ+254QE0VBUAW<PS]9!P.M\#_)VC=
MO3$,-J''A9CM`DS[-'\0V?Y"/B[ZHS*]:)O%@5ZHG9S%;3M#4GOO@DG[=@,]
M8>I257R'\.VP;_#LK9^F`Z\`33\DS=/*O(/#[47GRJYI(D`XOWE@N#*>IY%Y
M9>D'C3;[!LVN#6!:]_O07E_;?XCI^_G7+&=U)<DKF#[=9;5ZZ8=8^R/L5'#E
M?HA!P#&JK)I-W!5(PH-ER@L\U9NT@RXNHWNP+Q[ON9EN/DF:[Z:<<</9^\_C
MT\LK_<7_&43/.*UTBL,E%[5\KI9Y)N=T$5B>_@)02P,$%`````@`(9?7&E\&
MFHK)`P``70@```@```!'151/4%0N2)U5;6OC1A#^'(/_PY#"V585.^ZUUTM,
MH+F0MV*?T]BE+13"1AK;>R>MU-E=4W-W7PRE<+^ZL[M2(E]"H17!6<T\,_/,
MFW80/7W@9R4-7**9E@9V58-V:Q"U6^MA_[#=JM_F*ZF!_Y*BW)!<K@QTDQY<
MD%!_%U(?W*+:POZ%H.T^W,H4A84?K4(8'AV];+=^*RSD8@,+0LPVD$IM2-Y;
M@U`0Y$4J%QN0)@8609FAT`CO$<MV*]^`2%-"S;&59K\>)E0*&ODGQV`M,84U
MDI:%ZK=;DP<CU"`(C]NM`R!/ZH<DDV6)U$>E^PMRBE<QD$4XM4NKC53`B2+1
M!K[_[G!X!#>"..F+V].W9^>A&.W65W*A4EQ4Q;N[8@F_2L[V4>)1#=!ENP4U
M:HU_&B3%$,PT/E7`HUYQ<L&92C++Z>]/-O--B;J_VO?RRG)R^NOT9@[#5R]?
M?[LC'5_/YO!Z>/2-0QNV=)S6A4QA%EK?=2]1_$M!_)NL!$51;]0$<ZML8N`#
M\P2GAV2T-X@202(QGPE=2<![C*!TFI(U^6=#"$PW$U!2D6Q36R-#V`BTQ]8Z
M^(NA*D$*(!\G2ATD19V0+`VWUND^P=2?F2(K(15*@YLS(^XSCM@IO#8.@3&7
MS!!0&T@P8SUS@W2[$-9`:.6_I!F5,:Q'+B)3?K,Q>.,2&WUI\:%.'R)G$3V8
MW!CR%O#$)`3)"K7<#3)F21WD>1O7)7"YPPXI#CUI,AU+;;R/>J":/J0RD$ME
M]?$01K5`9T*O@N#3'E?X#2ZE@A'XA^O\T&ZWAZG\PPHVXM9`J+?VY:RC>99G
M@M+:D>NC<Y%*)3(_%AU4&G/7LI*VR39%%3JRQP]C#X]#]Y!`T-+FK#YI1JI@
M!\-C,`4WTW4XZ)\2\15Z:_-[I-%SJK/"*C/R_D[@CL,E.S["+$0>.C/4!*Z_
M'CX#O<*LG+.D$<R/1S?X."<JJ`==3R!L'(25"SG]9!$60KJQ98]"0]I!(K14
M36S3Y;62YA)-F(&NZZ.C7_MT#'NNHTV31_BTJI<;EG#6<2C+>#I&M32KV'$*
M(^"')#JE)6,J]\[."7I?1&#W&BN'_S5**(H,,:+HW1/?Q#QFN<@R5^6ZB/*!
MT[OPZ:I,JB\<_YN3Q=@=+D2FP\F)PAO'#]&K[?'JB<V,+#-T`AW7VQE7B[UC
M$V8K?CQ.:3)\1'#%9X9Y+\%S>^XN_A_/H/GUO]9^S3A9=R?_[I8:NM#M)B<G
MG8-.[\6+;KV)?;_YO1Y\_/B\WG\(6-_S_JV_YQKWE;N/8!!=GL^G-_.[*T?C
M'U!+`P04````"`!)IM<:JX5^LHT```#(````"0```$U95%E015,N2%/.3,M+
M24U3\*T,J2Q(+8[WX.52!O(S\U*1A7BY2H!,D+K2O.+,]+S4%(7P_*(4!6N$
M1&I>::Y"M8);8DYQJJV!3DA1::JMH4*M0E)^?DYJ8AZRTI3\TJ2<5(6@U,0<
M9.'DC,0B!;_$W%0%:P4%?2TP4TLALQ@LH:6@I0]RAW)J7DIF&D@:ZCR]#+`,
M`%!+`P04````"`#I;M@:2LF>J_P````@`@``!P```$U95DE/+D.=3T]+PS`4
MOP?R'1X;2%OJ]@%$+Y-*#[6'#7<<L7TS3Y*T-&EAB-]=TT1T\Z270'[_W[+%
M(QF$ZO14UH<'SI9D&C6V"(OZ^14;9U=R\1.=A1=800I_@?<X18RS=095UXXJ
M]JPVG`&0[A5J-,["1(,;A8*R!M>!/H%U`PIM.<O6WL_9U%$+=8]F)\EN9Q:2
M79@(6=3GT$@Q?'Z-T)@#&0<#O4AG4\[>?&62E8]%G611'G)*<^QR'YVFD$1F
M#HA>N/'60%S?>>;6/QY^/YNV[;$AH?ZY[B+KKR$Y?$OW$@>$KZ,+,FV@]N1D
MA4YLE+"V-.?77NE#*,UG>QK.^P!02P,$%`````@`"7?8&J;YY1'R`0``R`0`
M``<```!-659)3RY(C91=;YLP%(:O%RG_X:BY:5&4T#;3*O4J(6[#6@HB*.T=
M8G!H/!$G,B9J-NV_SQ]!L)!*`PG9?M[WG&-CG0'-688Y>(>5Z\>+?F\@9Y1A
ML]#OC2W+ZO<`-FIIM%;#%>6B2@IP?5A@DB$?]7M2-5;R`65I464(%_Z/GYB*
M<K2^,.MYD^E11:ES[?%#(&=2@D6)9P@T`I;17$43AQVJ<*7@52I@*3@F&Y?E
M6_BM`NRW-(-+R]\ANX++R%0"EI)+W1!>D@U:3'Z&0)D`3M_7HKR">^5-UPF7
MWE!NK.TUUJ/F&/^54X%=T=#$2/\5>U4AZ/FH0ZVQ9E6>(S<EE?07GO%_FO$_
M`CC%MCSCU:(_K2.\5P>LWOKXTRTK!40>BL0IDK*$36S4RGDB,H(T?J`%+NO3
MB.>X;R9R1-G[<=[O?0']I+'>H-D"9DV"YE*&ZC?%(9G.I<?^L&U[<@I?0S<B
M-;TYI>2-.#6\/H'EC(H`^2/?5CNX;:"Z0[$CDT;$%*KL-[9]HI@&`7DYUC7I
MT)"T"KMKX^BPP]B;+I\T>[`[;!D0QYT^:WS=Q1%YBS2[Z;(Y6;F.23KI4G_V
MG3C&>]>ESF(:2K_&W[IX]NP[3S7_VN6!&YC$MUWF$>^SW<S=4*.Y1OK?5[I!
MM7J$:@$PMDPG&:U!M9V_4$L#!!0````(`&YOV!I$1*!AU`0``#</```)````
M3T)*14-44RY#W5;-;^(X%#]OI?X/;QD)A=30V='>.G`89JF02EE-V?:P6E4A
M.,6KQ$&)TQ%3\;^OW[-CG)"VFNMR`//\/G[OVQ\V/!&2PW+]+X]5^7A]?O9!
MR#BM-AQZB_UJO^/E:-OSJ9:U1;V_VV?K/%TUR9]+M4G%>K2=-(F%D$]$/#^[
M#$\^<,TE+T0,LTK&2N2RA%Q"L.`J&DS3J"QY"6V92]2UF@F>;@`5*.1>\&S-
M"PA6^(<D(5Q,V6V4<0BE_AZ<G[V<GP$(J4#`%1Z=CAG^1TJ2:Q5B_/%*?%Y,
MAY-;H[6\$A<7`[PG#0"S,=Z:RPNK3&M.(`#M<)SM($"3;#:<D&D80,%554AC
M">"`7Y9T^]?-#5(/".$Y%QNXJ];.'9."D)"R^I_^Z?#,<V?<#HN6&$YB#,MP
MDFDZ,[@(#.*>_3I&'`/0D)^X"HP]M#.S7#PM.;P`70PGZWRS']LSJ1T;-P[D
M!WEA4]/TXQ7DYA86QI3S/^@O"(,'U@9M,4($-FQD;B;DQJAY$&KKJF`NG7&-
MZ!LOJU0QB+=1$2(.=G[VB_ZTJL8!"A^VO.!@<-:6KKG\*JA8HV+?=(WT4NIK
M:D$67?&=E$BOY&G2PPK)>!;O]H$1(+=+\8/G">9NX"6!ZM"O$4_""Y0Q9NYL
MODR.^GV@:JAV-N>&&VIJHTZ&$Y?$P-Z3$6;]<N5\J!L<YG)7J<MEI?0/F':E
ML'T1\AN/-NUJN"=^".>N&/Q<P!C:I6N+]K2-;6^YW"5$[NCLMQJ[OZ@;^V_Q
M3QU)VQ3)25-HO5X/U"%#-V=%GFF/K<R\%:@Z(`^%4"<!J4.W_/]$A/S4_J[R
M6J05D,[E0`NB5)'<1,7&CT)FL)YL!K<=J!"G!8]4;M@N7=11RRW_WHSY:#3"
M8(.6T_B+4D=2)CEDE3ZM.>0F?BF73VH+I,TU#,VA,611FN8Q!!`&.A'AH#%Q
M41FVN(V0AE]R98<RRK./K)W3X<18,]U/*3NVV%=>JJ**NYVCR[PYF.I*2@K.
M/;L6D>^'VT8_$0N'ZX_G**V:,:]!P'S#I1+*PP5UY'&>V;FN2;1$G,J[JGCF
M>U\CUCGZ>6,0--11$JVJUQ-Q!3_GW?NE:?KMW;*D'!T_<RE.%B3F-BZ8[Y3^
M9<9":-9OG4UBM;[IU/GKV"36,N#`AB,#_?7OJQVB&5M;S;?(\7/-U327I5HF
MY2N@S2YU\^85\&#1^]X;><MNV7R$MCB#@!8LY51SVB(>7`36LSQ)2FZ6TMM3
M!0LKUU&H2IY4*<3H5R15=^HP=\1!(W8IN4;R&]HX$E??<TW\U"3.\JK0U-_-
MP.U"`E^B4L3P-5(1U*_=/K@Y=_KVI2HR%E9F%,:/]YBF,;ST\-!C?13'(\-6
M/APA.8&ICB$)X,$*S*5BT->^=0G<;?-"D02=-&]#2CO?)763RR<2PD-;!F-S
M>#<P5&]FT+T5%7_J=^A"R:.X=^ID;PY38OPS*LKVE@;S;@F!WBV'$Y%"R)/-
M#G:UA["T0BYH]=,]>W0J'NU&1K]@;)KF!7KX:NTQ?3[@%Q+-#D7@5YY&;UL>
M=6(^H.?^DIYZ(S(WHIDW7YF_4XC=O>-8*T#,/6B\&Q,'$FR\FQE\8M#O<%=3
M34WC#CJMJM==\951[8,O;V>;E_VV/(JPOF^!Y/\#4$L#!!0````(`()NV!K.
M7`S.SP4``/\/```)````3T)*14-44RY(C5?=;]LX#'].@?X/1`=LCI&Z[RNP
MP]:D78"U*9J@O;N70+;E6#M;"F2Y77#H_WXB)3O*1[OS0R*)Y(\?(BGI@RAD
MS@N8I3]Y9IKE]].3#W8N)`^7[**06=7F',YN-XO-FC=)>>;6BU#\YO0$H`-X
MYK\,U](R\:KA1RBP99"Y*!#O(I[-?\!:\[56&6\:(5>G)RQ5K0%3B@8*4?'/
M"`7?.<NYAD)I.//JSZ!6>5N1*AB3JJ8S#7+>9%JLC=+-")C,X:IBS<YR@@8X
M7<(*B'I=\9I+PXQ0TBF=[JS!BZ@JX,]VWK*JVD#;<+AA.F4K#E>JJJQBZ\`(
M15.+*A4T;5:B)W(%0MH!A]+YP0S-C*@YI-S2$[CGNF3K!J5?^">K27*>0Z56
M5C,Z@*.BL,$2M3#BV?J*P5#D+ZR5D#:X#41_#,DQ:_U]*2K5J'6Y(4X*Z*Z7
MH`HR8S:#-=,LWZQJ<OP\B!,PS<D4:XQ14`GYCU?:@+*;^R),22#*_NC$B3>&
MI17O^1#"RJ8<,E6O[9[F-C@&E\A'W<ISBD3)JS4",+FIE>:)C2JQV^`5"JSY
M:ZV>!5I"6CT\^1O;[\*EU)M?GQR4TA"__Q&:L9R8\8W1K0WSPB'`OQ3@.U;S
MP0#PBT':"5S2^K,2.4!'2%6^@4L[O(A=G`CB4P,Y,PQ0C:5U^"Y+G6!&XTL2
MQ`QU\ST!;Q`)M&O2LZ<)?K:-`8PGK"J5LHH@7GO12_3ST%-GR?N.=KRWW##'
M'T-MQZ&[9/4GM[SC@8M2^,5NG[VP8Z85E[Y\'^2ULW+/A:QDVB$^3N6ZM=&)
M4-D0^3J>K?;'66N0*4*QH<,ZY+K2G&$UV"_J(A>/DB09=O:F'&Y43K8RV<4>
MS>S`A#0VAO-6/_,-(6V!+,B`?%:MQ+KJ4J3B<F7*'92M26/NXF^Q=I!\-"U<
M*[%<FV/&]`(P>695ZWQ[PS/N.'CSAF-HDO7LP;6VO1#Y+2##+!8R-5!H5=MX
M$.$0Z$D+<P3([U.'1%P--A'E"8=(8Y%AGV-Z$R#9_Q'N=8R9//++\0-OVLKL
M[7^7X->"5WE0#%3=1TO!%W!?O<=3/8I7W.KJ;(IQ+S/=V^(;U>CT9.#*;L>.
M&.B/3!U<],QN%<Z_.##7O.E<P./'A@DKJ"`>7X&6%!JEBJ+AU`]>.X^/!F-;
M[6%`@BH.PA*4C:/=\1=/"O+.D3#-/"TH$D?SA7#IS_H^\6D;:*XVGNK2D`@X
MO-:J_B;D*)@N^"_CF5VJ$3,-+>="C?HI<BY4I[9/)N*_X>:6URG7GMQ%DS;L
MSI&Z!/#AW(9A1S+H^HXZE87J.]MK&''?Z2[BV$I.?G$\SC]37W3YAMT';P(K
MU%VK'&0"_N*2\J"E)GABOG->^J2"DLF\POPI6DG>OWEL$ICWTP?',.]F%)X0
MMU<CRA@J/TIB*H]YF_;<O@P(K"\*+-MC@N%.1+]COA8R=RQ/PI2]55,9]`=P
MK6!$YTB,**X0!WM>;'OH4\DU!]\[WKZ`P+WF[DJ<]U>1^/W[A[\Y;VMEFG-I
MA*%D]\1ML5S9_3%,FA]]M717[PPI8:)ERT<;#^OC\LIZB?_S4FET>OE#T246
M6T^V[)I+MNR=)Z%NT/>)/4W;4-4]1AUBU,M^X/;9:40.9QF.IM*XP;V[W[K)
M5ZW9YHC.[5VHTQCH\W]C9EC0V][;L/Y-D23)[RZ+_89U;YZ[R5/$AH-!9'\3
MJKOS+UBFYU_N^$OTT:X.AUON\62^>)C]A1*'`KZ]'0A-'K_^&`QV6+&%;AGF
MT[\GL^OCH*ZA'F!^F]X]3+Z.(S::'I,*&BJ)CCY&TQWYQ>3/Q?\!P,9Z',%:
M\/0P74PLPNP8PK9-=_*S`PM^#^`:^W&$V\GMM\F#%4^S43T$B*(HS>(A(>%E
M?CBT4`'_].YZ9KE%-A*H+Q(=LU>+_19EQ#!X0B^7M_/Q;+Y<A@_E;#F5IBO%
M(P_ICHX5&CZC/[3TJ@]>X$B!_F[0).X.^1]02P,$%`````@`.)C7&LVC";>1
M`P``\`<```@```!35%)43U@N0Y556XO;.!1^WD#^PR'=QI=Q9I*6#G0S'FCG
M1J$MA>1A85D6698G2AS92/)<VIF70*&4_N@>79RXH5UV#7%T=&[?.=^1_(0+
M6C8Y@\&[^_E]S=3A8M#O]7M'\9.<%5PPF&DYK_[\YRH^ZO=VUF[7&RM--*=`
M%T0"5ZHFE$%H)1KU>Y_Z/0#)=",%[J;I\V?1PX-93)ZWB[%?O(Q@VN\]FI@W
M%<]AMN+US(13+EP<\S;@[8*7F,6G"XTF@A#?!P=M""XT7#%]QHN"R3T\ZI9K
MND`\$5B9$L4@>!7\L1->=X6SKG#>%2ZZPJ43MO52.(#)&$8F]'1G1KH^65>@
M72'O"JPK%+_,0TP>HT/Z2%-J;\<+"$-ZF@;C(!H.0WJ2!B\#[-C6'UW'QO4W
M<`\K,8_7CB86^Z/O:UF):]/8]\TZ:QL;J\3\(PU)(Q2_%BQW\Y"U'3^*S7L$
M;[F&1H"HUIEDP`1DIJ(,<B(4E,1X?1,,X6.IDE#]53(%*@&FH2!<VW+J"KEE
MF)6#:J3Q4@W7[-!EP-T;TFA`MX"7(()[(%`396*ZM`G:UQO)&3I_-NZFI,9(
M:++%X,,)%XV4E53P<2.K!-:$*UBC^YW3(5X37V&F@C/I'=^TN3^\FIG`FBD-
M[*XN.46P9B??9)7,V9H)C3692EJ$-H0Y<F"Q@9ANE]037%02.8UYE*I$I&.8
M0MBV/@IINIM\>S9.,F-@ST?D1@*PLA1_,3;_P$;=CI.8[E']!MM]W>$:'-G`
M]]FM)1-YAU_+:H/]^3FM_X/5MVUKH&;8\B_:K.2&;O(-Y`%FM*5[X[+L6+4S
M-AE#U<#D^!`^8!7YID#JL!(&BDF"6ML!@SVORA(M$"6_L?/@W(]]\%]/53MX
MWO`<2V3V?C(,*P/IQE)M8;,.W8E!IC8UD6[7UH+-L8A*#$,7R"6V;#L7]BZP
M;"P3B%=@P>\=O>G>^&1553(BX!T7C?)39$8"TB6DH*Q-Y\H=+B.[9>Z.&"U2
M"$:!OR_!!4&WN6R8ZQPL[=T+\&AOCQ_-+@EN_8<,O^\R9.@V.?Z7V-;`T69&
M>7<E84N&JP1"+G24[5)8+'[ZC<-(;%4K.(6E5\4<=:N?G@?S8?SA@?G%;`Y>
MZ'P@3Y3.>76X..WWUH0+"/U!<90!MWPY:NS2[JN_GKUX\3<X9A0E`H$-GJI!
M,E3VP]A6V9Y&E0RY4]022RW0.!\DPA;LD8\=\A;NT7=02P,$%`````@`6Y;7
M&FWX\LS*`0``50,```@```!35%)43U@N2&V23V_30!#%[Y;\'9[*A5IIT@@!
M2KE05:0$B8*2(L$);>RQL\39M69WH_K:2[\VLW;2I']LRY)G?C.>]W9&V<L+
MOXSV6'B^M;_Q-#5*DU&6)MOA>'B>)C.3UZ$@=Y$F9W!KW33:5'"-RLD-8RQ?
M*8:W6-$=<EV6Q,BMV1([;4U'.,^Q1AAM/%7/@9F!7Q'*X`/3Q=,")E4_;Q<<
MP9:8C7[`+O]1[J4M:DTA1OO2.-E>Q^U*.\B3VZ9E7:T\WN:GF+(R#U:[LSF9
M>YQ,%=^?8*X+4@'?@B&,)Y-W:?+'!FQ4BY*)ZA:%COV7P<L$C(TM=-E"^P$D
MA*8F):.MB9HTV;101<'DY-_&2=\.4Z:`(WEMJ*_65."@[?MC$3FHG1G<#?4Y
MK\5ZXB$9-RPY)CX,P(%P&:K@O%@@0HFYQ<?WY^,)?BH6T=/YY<W5E]Z,>+_1
MI2FHW!W\WZ\2D4\M>@^1CCJ"KM,$V&-;NO/$1ABJ';V2P0$P(C"VVUI=[,)8
MK'6SZ)9'CB%N3I;ITT]IHHW?(]?DK_H]ZHD\YFMKJB/@)FR6CT#F!MT62JL!
M@KA=&;&U2RU?J9WMEO!%<61E[M`Y="0TZL`HVSO4>_D?4$L#!!0````(`-";
MUQJB'JKZ70```&P````*````5E-934)/3%0N0U/.S$O.*4U)55#RK0RI+$@M
MULM0XN5"B/HG9:4FET!$>;GTM4!D<GY><8E"B&]J2:)S3F)QL4)8<&5N4GY.
M2&)23JJ"K4(U+Y="9DIJ7DEF2:4.+U<M2(^6/B\7`%!+`P0*``````#3E-<:
M````````````````"@```%9364U"3TQ4+DA02P,$"@``````D&C8&@``````
M``````````H```!24UE-0D],5"Y#4$L#!`H``````))HV!H`````````````
M```*````4E-934)/3%0N2%!+`P04````"`"1==@:*E_@OQ<!``#0`@``"```
M`$9)3$5)3RY#I9#!2\,P&,7O@?P/']NEEKI=!747L5*8%J9X$9$N^=)^TB62
M9,(4_W>;KF/3=@<QAQ1>7]][OXXE*M((*=68Y2\WG(U)BWHM$4:WF\<LGU2C
M0VWK^RE>."_)3*H99YQ-X]Z!?/F*PH-$41>V\&2T@WC@3$/`NR$)]]Z2+G.U
MH++R#B)1%19BEP!I#[853^"\,X=-S0=8K*YJXQ"BAZXP=JTZY,S?4/>,R5VQ
MPE@W5_*K9X`J@*5K+0(.+(TD'(;Z(Q5GGYP!D.+LZS^KNYRVHNM[.GL.+-#;
ML7TF![P`V^S364.VN52F*8[:BL7>U-]WY/]W6Y0(KZ/#Y%U.&+Z/F:,N?74T
MQZ)?6PV./M"H*,WFU[L8SKX!4$L#!!0````(`*]QV!J44CD,F@```.\````(
M````1DE,14E/+DC3U]+2XN524/#-3RG-255PRP02GOK^(*'2XM2TTAR%DGR%
MQ.3DU.)B!1?_8(6DG/SD;(64U+),H)""1DIF<7:QIHY":DFR'B\7T"Q]7BY>
M+N7,M+R4U#2P:9[^\1Y`$2`W,R\5202L"DF1.]!*F*JRU(J2U*(\H)+4G.)4
M3`D%A'Q>2F8:V+!2L(U(.D$R"OI:4//U,A1`;@,`4$L#!!0````(`%1QV!J,
M6$6FS@```/X````'````1$5624\N0]/7TM+BY5)0\,U/*<U)57!)+<M,3E7P
MU/<'"986IZ:5YBB4Y"LD)B>G%A<KN/@'*R3EY"=G*Z2`%18K:*1D%F<7:^HH
MI)8DZ_%R`4W3Y^7BY5).24W+S`.;Y^D?[PX4R,Q+SBE-2550`@OI92B!E66F
M`14JQ,?[!@.-CH\'6@I7:).27ZR780=4E)J3F:8`,3!%`ZC6WS_8-3Y>$R23
MEY*9!C)('^0)H',52C)2@:S$I.*BU,04"*N\*+,$))A6FI=<DIF?5PQT)MB1
MO%P`4$L#!!0````(`#!QV!H<:UO,FP```.T````'````1$5624\N2-/7TM+B
MY5)0\,U/*<U)57!)+<M,3E7PU/<'"986IZ:5YBB4Y"LD)B>G%A<KN/@'*R3E
MY"=G*Z2`%18K:*1D%F<7:^HHI)8DZ_%R`4W3Y^7BY5+.3,M+24T#F>?I'^\!
M%`#R,O-2$0)@-0@E[D#[8&K*4BM*4HOR@"I2<XI3,244$/)Y*9EI8+-*P=8A
MZ03)*.AK08S7RU``N0L`4$L!`A0`%`````@`L;[7&A]Z@5[K!0``4!$```D`
M`````````0`@`````````$-/3E9%4E0N0U!+`0(4`!0````(`"AWV!H-3A$'
MA`,``+X,```+````````````(````!(&``!#3TY615)4+D132U!+`0(4`!0`
M```(`"AWV!H%/,&5V@<``"4=```+````````````(````+\)``!#3TY615)4
M+E!22E!+`0(4`!0````(`)V6UQJ)<4V1#P4``%X/```(``````````$`(```
M`,(1``!'151/4%0N0U!+`0(4`!0````(`"&7UQI?!IJ*R0,``%T(```(````
M``````$`(````/<6``!'151/4%0N2%!+`0(4`!0````(`$FFUQJKA7ZRC0``
M`,@````)``````````$`(````.8:``!-65194$53+DA02P$"%``4````"`#I
M;M@:2LF>J_P````@`@``!P`````````!`"````":&P``35E624\N0U!+`0(4
M`!0````(``EWV!JF^>41\@$``,@$```'``````````$`(````+L<``!-659)
M3RY(4$L!`A0`%`````@`;F_8&D1$H&'4!```-P\```D``````````0`@````
MTAX``$]"2D5#5%,N0U!+`0(4`!0````(`()NV!K.7`S.SP4``/\/```)````
M``````$`(````,TC``!/0DI%0U13+DA02P$"%``4````"``XF-<:S:,)MY$#
M``#P!P``"``````````!`"````##*0``4U125$]8+D-02P$"%``4````"`!;
MEM<:;?CRS,H!``!5`P``"``````````!`"````!Z+0``4U125$]8+DA02P$"
M%``4````"`#0F]<:HAZJ^ET```!L````"@`````````!`"````!J+P``5E-9
M34)/3%0N0U!+`0(4``H``````-.4UQH````````````````*``````````$`
M(````.\O``!64UE-0D],5"Y(4$L!`A0`"@``````D&C8&@``````````````
M``H``````````0`@````%S```%)364U"3TQ4+D-02P$"%``*``````"2:-@:
M````````````````"@`````````!`"`````_,```4E-934)/3%0N2%!+`0(4
M`!0````(`)%UV!HJ7^"_%P$``-`"```(``````````$`(````&<P``!&24Q%
M24\N0U!+`0(4`!0````(`*]QV!J44CD,F@```.\````(``````````$`(```
M`*0Q``!&24Q%24\N2%!+`0(4`!0````(`%1QV!J,6$6FS@```/X````'````
M``````$`(````&0R``!$159)3RY#4$L!`A0`%`````@`,''8&AQK6\R;````
M[0````<``````````0`@````5S,``$1%5DE/+DA02P4&`````!0`%`!&!```
&%S0`````
`
end
END--cut here--CUT HERE--
#--- end /compil/boot/cutils/zip.uu ---

From uunet.UU.NET!davgar!davgar.arlington.va.us!david Fri Jun 25 06:56:01 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA00724; Fri, 25 Jun 93 06:56:00 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Fri, 25 Jun 93 06:56:00 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA20572; Thu, 24 Jun 93 21:53:17 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA13151; Fri, 25 Jun 93 00:53:15 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 005110.24930; Fri, 25 Jun 1993 00:51:10 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Fri, 25 Jun 1993 00:40:44 EDT
Date:      Fri, 25 Jun 1993 00:40:40 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c2a81cd.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject:   On "Various subjects [far36]" [djg36]
Status: OR

1) With two subjects, if the message is two screenfuls, make it two (or 
   more) messages.  (Please) 

2) I'm going to have to print your message to read it all, so a full 
   response will have to wait, but: 

3) What is this new scheme you've introduced for splitting up your message?  

4) Lack of activity does not mean it is time to begin coding.  We may be 
   ready to try an early attempt at a detailed design.  (See my old message 
   with big NO.) 

5) I still don't believe we should be developing a new language with an 
   Operating System, and the Low Level interpreter is only for generic 
   applications, and thus is one of the later steps.  

6) I looked at the .ZIP.UUE file, and after removing an orphan "if" it 
   compiled, but did nothing when run.  What it did call was commented in 
   French (but what I could follow made sense).  

--David
-- 
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com

From rideau@clipper Fri Jun 25 07:48:07 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01088; Fri, 25 Jun 93 07:48:06 +0200
Return-Path: <rideau@clipper>
Received-Date: Fri, 25 Jun 93 07:48:06 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from nef.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22095; Thu, 24 Jun 93 22:45:00 -0700
Received: from dmi.ens.fr by nef.ens.fr (5.65c8/ULM-1.0)
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from galion.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01062; Fri, 25 Jun 93 07:44:54 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9306250544.AA01062@clipper.ens.fr>
Subject: Ellie [far37]
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Fri, 25 Jun 93 7:44:53 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

  I've read the Ellie papers. The idea objects should group by interface
rather than by inheritance is good (that's what I did in my language,
even before I saw inheritance isn't needed at all; down with inheritance).
So the good idea is group objects by interface. The bad idea is that
interface contains only subnames exports. You can only say "there exist".
You can't say "there don't exist" or "that doesn't apply", etc. Only
strong programming conventions, and/or the use of the only negative keyword
"function" (i.e. does not depend on static values) can allow full negation
support in a clumsy Ellie sublanguage. I don't like the exports done only
by names either. When one can avoid names, better do so. What's important
is not the existence of objects (any object exists, or it's not an object :-),
but logical links between considered objects, that is how objects behave,
how the operate each on the other, etc.
  So, let's keep the interface aspect of the language. Let's keep the
grain-size adaptation aspect for a future release of MOOSE, and it's over.

Again, about C, let's use it only to boot the system. C is too low level.
C++ is either a dangerous low-level language or a clumsy high level language.
So I think we must build our language. After all, don't we have to build a
compiler ?

--
      ,						,           _ v    ~  ^
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
					'		    / .     

From rideau@clipper Fri Jun 25 08:21:51 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01290; Fri, 25 Jun 93 08:21:49 +0200
Return-Path: <rideau@clipper>
Received-Date: Fri, 25 Jun 93 08:21:49 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from nef.ens.fr by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22783; Thu, 24 Jun 93 23:15:10 -0700
Received: from dmi.ens.fr by nef.ens.fr (5.65c8/ULM-1.0)
Received: from clipper.ens.fr (clipper-gw.ens.fr) by dmi.ens.fr (5.65c8/ULM-1.0)
Received: from galion.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01254; Fri, 25 Jun 93 08:14:53 +0200
From: rideau@clipper (Francois-Rene Rideau)
Message-Id: <9306250614.AA01254@clipper.ens.fr>
Subject: Booting the compiler
To: moose-programmers@sfu.ca (All the happy Moosers !)
Date: Fri, 25 Jun 93 8:14:52 MET DST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

In a previous message, I posted the current state of the preprocessor
(that is, not much, but I'm working hard on it, and it's just the beginning).
What's done is
- MetaClass, Class, Object definition.
- Virtual IO definition beginning.
- Getting options from the command line in C.
The preprocessor was meant to translate any code to any other through a
symbol table.
What's being done:
- Virtual IO; IO through standard C files.
- Defining virtual symbol tables.
What's to be done:
- Defining implemented symbol tables

See my Bootstrapping Algorithm in [far36].

So I'll need 386 Protected Mode & Hardware support for next
bootstrapping step. I've written some stupid GetMem&Go_PM
code in assembly. Sorry comments are in french. I'll
translate in some future version. Can anyone send a more
complete routine ? Has anyone programmed hardware managing
stuff for the 386 (i.e. Descriptor tables initializers,
8259 and other chips initializers, interrupt drivers) ?

Here is my 386 implementation propositions:
- have only first 4K of GDT global. The rest of it will be
task dependent use of paging. LDT are object-local (?).
- use descriptors as objects system pointers. External
objects are used through descriptors.
- for OSL, use my SS:ESP trick, i.e. write interpreted code
to a stack user level write-protected. Use other stacks for interrupts
and/or when needed.

Even if the code does not interest you, mind looking at it
and tell me about coding style: how should I arrange text,
tabulations, comments, etc. (This is worth both for C and ASM).


#--- begin 386/BOOT/oslc.uue ---
begin 644 oslc.zip
M4$L#!!0    ( &1>&!F"6O*O8PP  -XC   )    ;6%C<F\N:6YCK1G;;MM&
M]GD,^ ?V:0*L76E+!Y:2[&YBV;4L40U36=+JDKC[$HRHD<R4(AE>'+>/ @HL
MBOWH/6?.#"^2Y3K;"H(X<^;<;S-#G9UQWG>NQFUG[-B\:_/K=F<\G!P>G/&:
M6^<]$6]XX_7KYN'!X8&WY*<,X&.Y%O'G3";UPX/S/1_>D6DJN>_-8^'%GN1N
M&*2>#%)^OO=S=GC0E0D7\WF\N?-$ZH5!PJ,PB_F'X;C+1].Q=?7CU%:#8:\W
ML:?6N]GUB$_>#L?3YZ@ADJ^%&X<)_Y5GB5A)OMH$FUCXAP<G_844C,DDY5G 
M?2EX+")O(;D,^#J$Y\*+I9L"8L>/ 6^Y%*Y$U%BNO"2-)0\SF((E(I%\O5F'
M@ _8$YDN&8O"Q$.%87W2L_[=LT8]GH#F)7J+:YZ='I<I'_: V$G&<L58+(,%
MJ,2#<#T'0>T@^2)CF 4\R'R>)!XN1B(6Z]]0$6V#80Q\KL4]8Y\SCXOE$HR0
M8/Y10Q'Y6<)7L0#^8.)1$R4?O4 *+WB$(I*IEVY1+%TTD(B\ *P5O@>>$/=<
MW$D72!/0=KU!YP/A,@P4/I ?'C"6A%ERDL.B>.-ZR49'%TP1421]+C+>!6KP
M,XRNO#!!J1G0&%57I-3Z/VN9D^;AT9$VS#EDJ ]9!P\T-P'.F@O* D/AB])J
M'B1ELW%;)S-R'<'IFI/<2JU(QFO(;A&D*A^B. 0'K]>"R-(X<],LWL@W()9(
M3B(/O/.&@1O2G_P[W[J,LN06?L,(<=Q;\=] *J^Y$&,W_2U&;#OPY9T<Q7+M
MR;BC%B1DT38 .4Q$EG+0QSL!@Q<Z$7W@<3GH=*S+=P-$,IJ!I#*6TNP2:OOY
M\^>\=@ED$H=U?@E)Z2VW*$''>9BYO@1K+F,929$JPLL,I/N/(7^Y!2<0[B*D
MYQ>0H$C"&'H#HN?$M:0.6LE[+S7.+ZOO"Z@)[$!(LT S).8*[T,FR,ZM\  P
MBD/W5H7.1CNV&Q=TN+/VU=78?N^TI\YP "WOZD<F/V=L_C-40Y3&AP<?A@KP
M)8P7!.AJR*( C30H*D##WD2!PN4RP>R?O%73Y!;,1,$HFMHL[W[3OK;[SG"L
M=.#=&7]GSP#J#";3\:RC%3L\N,8T8JJ#0;Y;_MQG[ Q[&/:8%SR$3$@3K!K?
MDQDZY244W3J\X_@Y1A)2A@,EK(!'K@U3['9A!.QV.Y[U<,MCU+4P>1DXEKH5
MC.]#Y&0I.*81J8"@4X10-E5DJ]ZIA)?ZIVJ>UH3Z)ZBR7^"NO!1:(\).&CL2
MP>O:Z:/A;,Q'$WO6'9X,1S;YWJB$G70!7*PP]E8-]=LDL0K 5RDW,$3C_)P6
M"AW*X.8#:F@YT'_WRVD:.8T_*H=<I_:.PP-NMI9S?HHS+XZ8O$]ED%BM"ZLE
M+Q"HP"Y;R0#SIB7F[D+#]4J2+9?>O=6Z]>\OE,K>(O TGV,B.]8X6BXK"2Y%
MAGC"9$WC8H2*><%"WBL5$@^46^#//(*?)"KTJ<C.*8S8LM!<F)%LI-&SZK6V
M[ZV"D7+;TC)U#!7L+>$ PVI_/3D])F@=SPYJ:UY2]!0.1F?.:@I\HB!UOLBB
MVNO3VSH[&PQ'WR0[ 3L;3=[4GM4Y]#QH8GRQ^?0K'DVNVY-K_NKY*:\E(EMR
M(Q7W4WUBX+6(MH0Z%GZ[[WP/R3S*8CC\D!F5CM/FLTG[>YM_;P\@\_NEA%0[
M)&ZW5I+-ERXHIG?\"@QV2P:[Y58AXV;]--K&Z3:MP<1]WDKF\$1RVO:%5057
MZ A%YZF:(1X>X2 0P9RUCA7PHIBKY0O=EW2FWA/IWQJGI[??&OI2^])H;PFM
M%#:-\PCK?JY/3K/=DLZZ=L\9.-3];=Z!?C]M#Z:V.H%SV*BARGE[TG&<PX-^
MCYVSTS;XKS/&41=&=N**2,*L<75;)H%,2&'KO<5AAAOFG8<M\X>/;\,UHK_\
MQRW.9A&._ZG&HQ7-7JM9?YGBY$I-QBLUZ:H)Z-[!64_-N@&,7YUJ#C1KJ)D3
M)(CWJDEXTL?)BUNS YH/YZ,]!RC^AH_PS+ 0@<IU.([!6<N522(SL$7MD'"@
M&J6ZG^6[2OI3_\YG[T5LP=""L2IXF+-.>PIDK 7P"^NH!DMU4_I$>SF:P7:-
M9.\%D?6'G78?(2#'(M8*3I JQQ9 J#<=F?5S/>#?ZB:DM=O2A)#J!2WBV/^:
MJ::E5*DVJ,O1<,2ZN'\ [CX]<QL>U]4>CYV>3?V1UX[+JOR^LB""H:*LA=H8
MXQ&*0&/*'I^<H$^*6GA22JQ%X$693RMX9%;'O:W3<^XH-._!<S19"U:=6EU[
M,BU<R*$(9P,"J)'9+#GB<8Q)B\QTQJ,.[UC(@^:]$JE")K^IL=7J:&\/NDZO
MX'[>,%!P OVB!R:2PR7X-\CZ-9@'NQO>-C9P?;D3/MZBX;9&(B:S*Q310BTN
MK&;9\*>8O&U#;F.'U+IQIM=_IH(-J_$5L0XVJR+.H?K1%Y=2)< 5A[FN%;@N
M*DHQ[(%KNU:GHXQ2$Q/%!YP"5R2->00QQ ,%^JD%,*@2<]8HEF !X6%^"#D&
M#2@O(ID#E5 =7""V^Q/;+.VP0BI6XH*L686!8I$G3GE2&D+^]<(,KU2\'+H2
MZHYU@=)W3X6 7T G+237/]<S.,X728(IY"(#X>:IE(?P].>^)1J6:%KBA25>
M6N*5)?X.9NJ:XWA1?:?$J8ARB@L!WAD E1-O?;K0*T?<K %_+AI<-+EXP<5+
M+EYQY$\)^^2$ Q>J:["REZ[!VCBG-YA=4Q)=HFLOG1[UYTMR#0%Q7 &7? &\
MR1=H=>@*'[6^ZN/U1O.FI]HH:".B<IUU)M,?+!7WFD*IFW5666V!",P<8,HZ
M(IU @Z6/6K#*Q#HNX.$)WDI)#^,K75=D *E**EI.#Q M7,#G!#TW$&NIU(']
M2&D3 , R>N%1!W<7<&%IU2BJB(ASB:"ZKY=GX!F&$81[/+Y1B>'X'V3K76>T
ME.X7RK.@:)$Y.X[0IA3KBK",<<0_K2.ZNW.-K:#$^8WQFO$9)4O%:4]WU</^
MV.<]O7%O+QK3=?A4CFU[0,E0BT=<F\%RU:OHY!!#D*-_95V-[9'=GJK:@CW/
M 1<29*NF"*@+2".6*HB6<_=2*!XHA*-:SGUOJ1#&GG+1B]86H\)9VIYS7IBA
MRG:KA)0)K*AXEJ-;?[" "O458<&W1*@,,W'<8Q)T MP\6SPQ?8!?;),J*_8[
MXRM3X<-;IZ]:*^\.U>,#,#@\4."M=% PG0V$1?#NL +,W:WPGY(>1MC>[% (
M>Y*#UJPJER(U2H;DPX=R XPH)89!_:-YD2NNZ'*NE293L?=19[1 RYUT0*=O
MFZ_3*-F[F5"D_F1C2;F]EE:U?CAJV-PI47[7QO\WX7O#L<KS@7TSY;7)U![5
M\3@!%W_^\2,L?OR(S&"PE?T T6E^ T,#[0_!VC(X=S'B.Y:]$K[EG%JS:!AW
MPR_!-+2<AI5XJT NK$$(A[PIW-/*16+=X(\^3N';"P?HZ:R'IJ5QF-W!7NN+
M\ND;4.G=&V\5DN! .54A@;6%7'*2JO89?6;T,<I<OSG)H7."ZG<C1_DZC.(8
M6(&D+3'=X8>!%K4KR[!=D9!<FH$+/2U,<(!EYX;8(4/F- !3G<.HZG>*AL)5
MWX?04G&ZR)?AH )*LK+_V2?W_A=V0\E'6,8#6^.CTJ3DI.)-)H:INUFJ/^7"
M(*FT+=;"Q+BHJ'Q36;[96=\RQFD\ -L%T=E]OZ-V7(1R"P.6PHNE^K>!_C/B
M](?1LV?/Z"7;MO_0+RY4KT/ZX;32A;1G"X>9!IU7FAX\U)RQ5O,:(3RK5"K4
MM%+L6EA=H$(S[U[%RO;)3O/9UZ'VA,DL[X1)^^W]!DH$[FW\<_:-Y_.?N>!S
M3P9E3ZH^H2H6? $W\5S%BSP*K*BU;80\D_MA:)HE./O&^)/;]UYZ7<Y),K?3
MV3W;[D(:99"N2-9R79#LJWOQ0KH,L\UIX@VIH?[9.2K509EB_M44*T7A!16*
M;Q^C$$^@ "=Z304I92AL-K^PT@Y92DWC2[I!ZY/XDS<8W!>*&PA,6&!MG3FG
M5F6[I?Q4;P>5=7-E&TQ<E\O/&5]'%7.H7$HW,8 !,;VM*"6+23)HQ[1%Q#)*
M6: "H-\D*A4T(\O<*0PO<[=Z+$])%_P]X2\>T))6FF9EO17)2DFAKX!UU8(2
M!BI[5"O."L>N6PY@\;[C[($/G_S.'];\[.$/,E2T[*&_L^F]GBL7,DC98L&^
MH_>T^-XM!X!BZE_CO_P/4$L#!!0    ( $8JT!JP=/2A3B    =3   *    
M;65M,S@V+F1O8]Q:6V_C1I9^I@']APH0K.6$[9%DQW'4<;+RI;N-V&FCY<DT
M$ 0&1=(6$XID>'&[\\A!8P:-?=L_O-]WJHH76>XL!O.RZR2(6'7JU*ES/Z=J
ML/7\W_DW:-&IRS2HXE %^#?UJU68E%X9I0D'8D^MZE4:Y:$*$[5*,93E:5G?
MU;OJ"73_'NJ(4)VKC;/JTI!4EV$25*$JJEQ=G:B]PX/-"X@PNE4C]5SEX<K+
M?Z_"@ELH=8'%814#0Y:E>:DR+U=@Q?'YZ[D:XO!O7E_NJ"P%_KLZ#_,N/^SF
M?IH445&&@ZV0+*L>U&V:^&1@H>[R\/:V#@NA,-Z.DC+,\RH3[HZ_6JJ@DJU<
M%251&7EQ2.8/MH#R'\#<W1<X?*\HPK+$+PIF^_SX$H>>XE>5A#A7<I]&(K#2
MBV(MSM@;;*V1ZP+>JTH,9&&^"DLU].Y#7RTB$)^%E0JV07'D>WY4UCOZ*_3+
M"B0$Y)F?9I$FP.+]0)Z54:Z&::7NP[S8V<"D7?+ZA6&+FKTZ.CQ\-55O#,V!
M!U;-WG9H!S$_I&KX:U7\7FU_4 ?[ERET,_%WGCR5OQT6)8@)>C0)H[P@#\$Y
ME2W?%Q%$K\8C_KW:52=D)Y&52VIVE.#4$.C2\ZN$2,!4K%5E6I7A)M&'#Q"\
M!Z$^5RLO*E2:#+8HM-Q32=@LYY:=Q4GM@QP//UV><PEIK%F:/10T"E,UML^3
M<)/^N%I%1/;OM78:!I9YFOQ>U:$2Z9)C5BG5X>%2#>V1 Q[X_,=K8-L1(5UL
MATE218K<).$_G9[/?^!I2F@([0-ZF*ZR4O0+!\'F^%YY22 ^H\"92E<5D.A@
MBTJ[2),$_TLS;1!!5&1I$BTX)6+G#VJ-S.9@#8X()!17[/FA@@I01%Z6?RQX
MOCA:D608SJJ^\X2#[U7MY]$]Y* *G._XZEA]]MEGHB\NI!@^^'&54P5_K+T$
M'":1D"_\V%WNK5;P &GE1S1<'@F'PTD640P#P, ]9 EQ0)>:8\,*J#>JO@>Q
ME4? Q_K]-?0[H\&N^TTMLM:L*DY7]V+Y@GP1IWYA=6%7G<VG\W,<)@+S4U$ 
M[4P\]?+TVN4I2P4K\B/ZK=LT7WGE=+ U&BW5L^_4,*A6J_<[H*',H0Q)!=W 
MY*%,8OU@:ZP!H<9Y.07;[X0.<"3W 3G6D##]SB2_HD3$/=B:Z/7B,$_F^#ZT
M^/S?R)19!0VA!KM@"WVEUJ.8G*;^;4.APTI[CY$J(C$V58@U!W6>5G%-KP,@
MOQ0>[4S56/.0;L^L)GN]G!(;EN\S&KFAM&-6" %)8[ [KIJT6%9>=0_[#35+
M]_0$S&V5I471Z$+K"Z':VVE6YSI,#@M!HR:'!Z[",:S [Z,<P+&VJWFDM-8T
M=BBTZ-B%Q;-KO3[4KIMJE]<F*H R1@#XECRE[^")C>'?BVK:'2'C&!J3:"8B
M7KB/-BW(>S! .Q=Z?./O:2 ,84%T:Z/OQO"K3B##_+]M@(%!WH&#L\GHJ=#[
MB>A[A6@KQO?8\K3?"M7AB%SY'1[)]V*_BCW800&?89PZ$%FWKH,LZ%A$I;@A
M(\80<[&(V08"KWH&'2XJB6,F& RVZI*X)9I#\6HQ7.U&/:VPP*LF8S$YGY/"
M?<YY")OU AP?9LLZ25<?$_%861C7ZEWN9<\\Z'$2<(V7W.$(A=$3JK?5U/9(
MT$UZQ=FU/C<<$RQ #J\MI\I;6+5V^GTBWIL8'M WU&!F#3Q9C>,B51AL%>^+
M\N,J%.1P-O3R'R"=1I9!$S$I569!DS'@74(@IJVBCQ*C/&8JLQ&HA5K>IYI-
M'KPK/-'V4V>3F.*'>4E 6(@<KO'$A:K*B.J>E+OJFCK<.NE[X.,.!F)C*D8O
M.=@"_8LT#W":A<W96B4=0E@P#.$_30V8*';A0QV:&"A)W6,E!T=N"6R21$D8
M@RXL4,<>#I6OVY(V&^UZ"JV7GN_7 :C[T*-OL/7#\8T)J#?<P#E"]K-TG.=#
M: _C7(E8MB-@0%=6Q6.HF$[* B$L>PW(:#G8.C^^N<W#T,'W! N$EL)#!,GI
M?>VQS#FTOX@6])X=PD HEH].QTN+P9X&W+5LZ1\+F2N7W;S^4:DC-1Z/QOQ;
M="9>O&@F1IPP?+OT_#PU/+.<SM>0"XP# O/0"]X[.BBXL$00?B/)%L6J+E*8
MD7H'$=Z<'V.$4A'WN.)ZA'GQQYN9T"8N:N@OTZ*;QVE4GF0@/#B-UF1DU'W#
M-1BV!GS61"T&]7\R%Z=WJDO:,<F!;@+_(O<2?QEJL9CC:@2)1$>F8BU5NQ9W
M]]2]>*LG&,8X16< H2&ILB*S]&M$Q39T@OD) F/B5P;]%U\P'\TKT#U[ZYZ\
M%;9&M\E"??L?W8V_DPF%J'2O_(?'D@CC(NR#P WK&6TTRHIIJK> YXS=WQ9=
MG9<)RHQ3T4*T6L;B-,W SU;.2OWJ/_QAN#[8.DN"2P>*^USV5U9MJ'%:D8Q*
M.L[K'ZF6[F9]XOJN^GB(L/<BO* NS$=73257]=Z3R:2ZUG6!5C6-;K.^-9+5
MU+0RA2EA,PX588S8+OBV\>,^K*0(T$3D/9)RC<T2MJL3$[HT;_61JB@,7= %
M2\8F.LHM)=$P%@R$QF1W_W^I-)7%J+/FME%D*JFW='EH,\'Q1E=;%3*@L=OW
MEIQ@.%MS[JX7=Y9XRT^!46M;%;T&NRQB[=;.'J#N0BT5\[KQ9=W@)[*E&M2Z
M]KRO\^@VDL(IPL;\#SQE!"DLIB9PVUA;V-C.:+^Y*GN6(E<O=RV*+YI"_T05
M79(ZY#2PZ])0654L55"TOPUM?JQ=25$ME/?@>@_R15:B?O0>8-_X<?0YDSN9
M"9!/=H ""Q0 Z,4++5 MB0<W**8_/YO\0A>A602E^?GS\>C%B[.S7XY^_ES_
MT&2L,JX(N6)\J,>*TM=>)_FC(Q;HG+*(_P2S82QR^HBYN:ZTGMA,'T;06B8T
M^W>W]V,9E(&I =,<S-+,,I4_R6NK;$S;\?40KC+F-]LZ^6JZ@ZS_Q?E)/G^%
MZD04,Q3OF82><396_/ZMR)^:J,5N++ 1N:&_J]RL'H6>*[.!E!]IO+X'6UD]
M7=<^$5L._=NCL3KZSNRYTQ7TV.8;(_VW<)Y[#TA#/@^"$5 L<]2:7ZK/#ZT2
M>8%//^#%C!_>4D,V</YM#VC9 _H2!=\S__:+B>9]N.&$O;.9XYXEWN+184UT
M*;:C6*I^MI >I\-:[%X<JT8H,O2?D&KBF_!K=<5 ^CT*"&R<G-#7$D-Y8^B\
MK17/GZK_I,=:LD&$G/SMY?P3=>)3M>+0=(C4WNY(Y/<*L2:L"JDOI)G3;* [
M!U*YUY]NW+I24NN.">EB.[#%<\<B!ZQ 5"G@@GL]3YC/,R)\=3ESU:OH;JDN
MPU6:OU<S1 '7QG4>5; $8581#3-_4SZU/2]XR;-8NB$H<A)?JLX1_=%R.AJQ
M.1.RWD7&D*^BI#<K_W-!'0PGA']XU.9LBMLEB@QQ,80?RO!D_X=41@\/\8,^
MG^5W'K'X+*2*DL;;4QY>'+S4V-J',Q.6W+C;B9">#NOWP99MA2A6B<'CH"2E
M6HULY%28U)2#>8UB'#(NN)6TK:$-=^P_I4G"U+L@1:>OYY#[>]TQ9.EX0F:B
M^E7O2=O'H-L1KFP?:[!E6=C1#>0(<9Q6H6U.6F Y:[]IJ#?\AV08PC';[P4Z
M$(8DIO":UI&D1/5#[5<E3>BY=*SBJNBS OIZ+V6U@)N:U%6P<C*)K8F0B1U.
M84^K*XP W*A#W54 8B13B=F,^5[0Y^GOU;:1*NMR*?S8P\VBNA#Q&4Y@-_8W
MR6@6RKNB\VSH2GOR[/)8#<,'6E(8P/F*^G/J-VI0YWK 7@# N,Q:E'RIZ0IH
M7/WF=X$*MVX4+^RJFS8Y2.(O.*?D*$@6I?=A]*O85><Q#9:Y">582R[X6Q2G
M4$8BV1%!PB5@QI3Q-/W!UH4VV"R$*[VE9B%+S"/IN[&\U;;EVI82V]YWR((R
M9NO8"]I_ET@S%^8,UN!(;2,^4V ]^(2CP=!VU:P"N"O)F<G6V6K?AG:1']2=
M,A2+%@F+^+6'#YDSI)+;Y[OJ=:*I;<=$HR+I#]W2<1F,NM5G/!*"S7KVW*+U
M8%K*7KI,OOH*M+*?X[:(!UN +".V]-G<_@-935!G$+'I;(05E:;3I($ _[D2
M7?;75.BO5*$J(PO[^J,=L=418X!=W90+LJYRZD:9O3.0:XK<MOCB;O<)8@_S
M^]KV8/0%WV!++F^B1%/-V;LZJ7-S'2?J? (W"B=R!H>QJZZDXZ$YWME(D+F\
M]A!.&QY(U\R[,PWSQD'2+UJU-7=P9Y>7>X<'.]([^L)LTK95@EQJ.6!N-<)Z
M'%Y[6/=_E_\=4>0#6]2]ZZ*A7/6LJKB,D,L]0)@[.'*I)B^6<+NZ9>:V2:GT
M^L MAJ2@&FSQ1$+E[.W1_AYBRB[CNB%*:C>!+DW-D=?T?SK%GUT<'1+^M#91
M##[)BU-H:7LW%S0';#<9<]'9?'K\UA9]0>YUU_#BLU%(<"2G"OA++[\+Q2M7
M:L%"A1T_"0AR3VJ@@QYW7 JR<T>F;R1?@>;>W@P ME 61Q(STA7@J8>H,WLK
MW42&53%?MADE%-+>R]"5+BOD+^/FWD.P'+_J;F)8HR](V,W4D-+7A[>.3<,0
M3J*]Y['Y$8[<C8Y,E;[[CH(R:4[0O6VC;$#.\<FI[KW[9>VJ9;0+9SG%!M"K
MT=YHK'D'3)T<;"R'[57BU0H^1'R)!G,5Q1:R%R8\N(\X2H8"%7=.JICA"LQR
MA6.F,A0'WZH3X\YH+&?4@3DG!,_U[;? ->U<&(M_+\R1.97>WA:\0.U'<I,_
M >U$T-HN<1]M=VVS8$_38;HJ#-AW<;IH;NU'^_JRK&FU; #YZA&*F-6[G3[8
MA*$'\;5 U% XW?HT=WG=._]-=8"PI(E):>G1:<Z:$=/B'7TCR&:&TXADCSD=
MA.Q+U.:.OL/N)89C9EJ2I^2D?KTU3 >/76:RRX5A?'\7C05 QP)T6ILT1T)C
MX_\U^'R*,^E+47LG6J"0E.XW!N1*.-2U+KSW\/1OK]^<[H"=R5W%H-[H#&@N
M$:&+6]*CP??54$/;8]D;44X>-+B,FG0G9^LK>]>EA#A97[X. 7LU:T=*KCZ9
M3 ;ZIN")]$Q[HVU+#TYG+H&,M6FGDK..]_Q:4A\#.SX0..&7V&IKRL9BZ.D+
M(R9DNA+@)4&U:0.S+-UIZSP7X<FU\,3J6 N D&>^?G!CU+D)PXWG';U8JN_U
M-8QZ8RK J0:3?)G.Q,LB!#,X*R_6:1=CO#Y.H3Z#[IR([OS4)D:;=4Q4]_@M
MM>AQ\:2U%:(2+?L>9>?HU*CD_9\A'IT9#<_YJ.0V%8%\BH974_.\H)(*97-F
MYII"_?ABVH'0B'HO*PQ<SVBA'$Q,C=&2RR#P!(OO< H#U:/0:.#P0S?!%#'O
M6#K>3A.^7!"7(ABTV.91]Q62X2.5,*^#2@)A')J6<J5]?9@';,>:MPC6_?RU
M(0<[M7Z>$1@)=;8,BU:$CY06V,8]-]/#M@%\L'622BUE7R0LZP<OB/QHY54/
MR)X8"1"HV;]Z>\0NQ.'(:;0V2G">A*[V<.R\F5W*HQEHO'X]8U.CS]10^BLA
M@PTQ3,Q5E7;EAV?VTZ:?&'MAQZ(\1T''1P<+3GPS<C*=7TC@^F;L,'*F/D$X
M/7&$[5)^9,CYS6VX!MX38%;]NDKB@GW'-&5Q%/W:KSF=I1H5>D)'*2FA$A]?
M24:ZPXM@Q]HG4\56&S$U=LH44U93.:\)A0!G$\=H&GDHSSPPN.?TW*Y]H(&9
M?:?G<SLS7SF/'6YG^L!Y[&T[TU\[35RPKT$P>N@4K/&R% F<EC-R1DFDS=L1
M-A()^(VS_A(%@S.')D<V-YX2H\>.-D1A<W?BQ EJ9N':83;^H.,"M(7.3C7>
M4-=_5(.^.QYL'8\<EE<B$2W]KD".QXVL"-6;FCC6%=I\B2"-;,+>Q?:<T=:!
M/&\NP8:;*^;&A32WFS2Y>.SB*7^$=Q/JDKMR>9URO1,$SO?:@XAL7XDXG>!=
M;_2U2+&%/84XUR$YUH,[2X+Y.IT\@.U>_M1O2JH+S^;1GWX$JS9W+YWGII]7
M2H^*N[R1]R#F(:CD]I0G'0Y?88&5-:_MY7Y2PO'XJV=[ZHCE=?B@TU#"\0F*
MFM#Y'JGK<Y=I<Z0N^&A)WDZ]-#!8_FQ$F#=7%WR>@<@>?[S359:D;Z*I[659
MQPF"=7X>99J2 Z46BX?8<>(I.W>Y)$M\Y;#T5IEI"0ZV]I7*LL7"<1:;H!8>
M+6E"3(1Y:&#42_?4';FSGRX0CY2*\><X63;529GN:^4I#V,H==65>XH#X;C7
M[S/1Q)=3]1(.J8K%Y P73*O2E#<ZQ3.LZD_M_X#S3A'064R;Q5;KAZR^_I)%
M<;AC4R2#8Q-$DVSA-%,UG,%_Q/33.S:SOIK:*&"PV)@PE*:0RU>*H2[481K2
MR&,60T!N #JO@-@*)\W5E0@UA% OPGNV$$:CJ1CU+2\,QV/SX=&LV=/EXR!#
MX^EU#Q-YJ89CQ'*4B#&VX@"RYEWN?GI]-&;>,3K[VZQM?IE^XW-U-I4>H.[]
MLO*3=U(>9OXVU;=7GKR8> ?Q"#^ :GSRID&E'P'RZD^=3(/4C^1Y1;IBN1HE
M=SLR\V:*:E>_O. MJ\6C9M.V\=R2.Q)R\>>89H^#OW'G6T^/G>OY')(5:VD]
MH(#JN;W)VIPL'(\<V)O&.>[C'/=PFE L<#V$38Q6O'9RKGB[0!6G?S"+L>CQ
ME%ZNEXWM'#*OO_O+T)$5XRXY^&X0]-\-ZRW&3P)T-AIW-\I)A]-2^'BR63K8
M>F$:#O(XG9?85"EVM<R":Y+-VBQXIUJJ\5%81]@8&GBGI[*;((MO1C<E%/2F
MMZCY:';8/N\>2??%KX5(LZG.!F[B]*EM=?M%!0NJB]W.[=+00[24RU0$#F@]
M"TFYRREL9U>+\(-JN-%AFGY(1+]T<G7Q[?GKJXON.69<^:_1;%.(/R'ZQ("U
M585^W,HG2R!97P[PID$:*9YX)%='0O@O.,?VR2&?<_':%5#(L*K<=B3DR#N]
M2T/]CN$TO&U=D0//X5Y$*_?FY<TIR(4S=6^N;N#Z;DZO;[3/I[, _6H(N!W%
MRR3;GM$SSA!(-DPLG*'24W);>Z :F!9BXUY8V)+#U;':5U^J(?\1&C0^BVZI
M=MJ%S7Z3_?4''#BX2-@!P]STME@[J&MEUSDQH#:>&!B:+=>6/7&F=P:9)GV=
MM'E8=F1R>C8_>7-^=6U>:/2?S+4/E)D+!VWN(&W<9LDS9;&8ND]>U'K,$/ZK
M\RY7TI-.^M&L#A</II=D(4.35[0@O@'IYR;-O!>WX4M "G%[NB\*%S%=3R[:
ME4N]DNF*)"MFIGVV$/)-Q@+_^>W[DI_MB7]QS2B9'?*EV\%CH"\GO[B+#MBB
M 4. ]NW3(/U6;NDNVJ_%TKPA6L.WW^#KCQ]H<OH"?_FTP.5MT4;1RTM84\CG
M<F%F3!UE:LT[6]-YVR!_W33^/RQ^\V;1'NKG@_8ISJ(SO-\.>_&:U/SVR\.7
MYC&-&WA'QKCI:SJJL(Y^\DL+U=>K#FVMK)__Z1\CK7K^O_EKBS\LX<:RO,AJ
MOWFP5"A&8..9YF%\<P&QW\QR7JJ&=$'?FZFK&X2]D11O2/98+:\BQIU?4^O&
MYO,N2'?9N#\VWS F<),-</VQ @[K_*HM(67@!8KN8FUL]G9MX&1]X'1]X'A]
M8+Z^T?'ZP/Q\'>GZP-E\G8[U@?GZP.GZ #/9)_B.&K_H27EO\J])V44U_#^U
M7%]OXS82?V:!?@=M7YH$2B+93ITZW0:V9*U]<"PA<O:"!L'"L9VM4&^4D^U@
M>X\&#KAOT*]ZCS>_&5*B[*37ET,>')&CX7 T' [G#P\N+R_UMM@OOS<=S-7_
M_MYXO?:FK]_<_^1[H(U70!L6J$(_R-/&W:'%7<C"O,9O+0SU1DA#O278:PGW
M6GI[+>G><+V]%LC$#N:]EK2<'JLZ#UXB#J7#2[3+9TMJ7&]/;NRF<+\IVF_Z
ML-]D)(PI>NU;PR;O96L O072(U4?P&6@9Z?>EM:_H..&X>2OZCC)?C2>&_N,
MM,)AYDADWSDZPG%PF%PJ>)#[1:&"Y$:-<VQ =(H+,XE]<M#%4RI2L1K39._\
M>\0V53)='?_KF+[/*=Q_GZ>?%VIR.G$C B*PTZ9B1>\UU/AJ2.-,I%W=-=':
MI"-8QI&7:5'\>ZW4R"T!L/UX+34<3V)5ZSA#QYGJQ3?C4/> I 8"D"I^GDDM
M[ O9=?.%H1>=;9J@58(F6>)6_[GS3H7YYD&G)-*[7>J+G8/WWB$#_$@ J:DB
M9%_GE@P"0DF H*VA>"OUN@2'O:A.1*R(%VWT]RP\F@H#@>@/]488GYVQV7)A
M=X;4F13T;<07:3SM*G*95B:S7T. #V(AB*CS6O0%B\12J6/Y0P"#.OOB")Y9
MK#(\4G=(VO5]@I)$"U&B.H[UQ7 S5G1<\!O'/L8J[+$D-23J"']=9]*1,Z0+
M9P@$P'5&G67^.9ME"R[U)!E-+CN<VXT >Y!V#OJ'PX3C*!D7'U314[*')'P*
MDC! ]L(8M%176%A M+];(^H@VX[3LP^LX*/Q7YGG0Y3.ZM=7G$]7'F%=)_\#
M[DIGRA5KM4@EO)Y>IW\[X2@GGOS.$*Y.0C]D#Q57G'&)*]=.\$'U>^JZ  7T
MHH#4O!SL _Q*#4\(6]$LDQLZ /\'OW:V(!</[K[*E9LNT235B5_I]RO2'(\<
MK'HH!UK<S%0 G)Z?NX[Y3EP\2)^!O@'Z;9:;B#6]W;@7H]-H!/K2.&7K2@^B
MEU:_0_J@BJ4RHY"%AFB5GA>I1%(">K3:EQ87:YEC]VSK$'KI[!XUX;'$%SBV
ML.!L0N(O*KOAT\B62*[$X0?%)5SIS&1PW*C@K,@X>N\3LA_N:P*SSC?0V2LD
M@%!O^]X1QZ.9A;C(F^!K30@0?45/"XRF=?3:M&QNDC@M32A/9(J.:R1K2*A\
M,BM_*U6OI,JY@/GHB!5C4H =Z:Q8T&S>O4-$^5SM2  S^%W'^34O:+UQ[L1;
M(+JL!WKK+9 @OO*AN?ZDO^$<>*7;]"'+5QR1?NN%P;28A]GJ-VBSMV"B9?[\
M_+N&BMZ"2JZS,:>1^IYB)GTDA9Q#B\GC7&=UB2;KH])4!_?]QFL0.I!;IG+X
M38$:GL:.3N>DQE;5&"!#SS^K&O"MS5T8U/.#[JGX[+>E*2;BQRAB5]?Q%<R(
M;$9//ZI>GJ]3+$AZZ@KHP'Q&OZ>"=;$\[A6+*?'%#U1@EW>:H%P%'ZH)^[@Y
MRQ:!I1/G)9MOP:%^V<67=' F,,]0"(^J;NU0YVM(EMLR<.0$'[K.P70URS+2
M),=1=(B"^^-FI,(X_?:;EJ=,1:1$'DOL3A*<WI*";/G[U D0S88XU6J9?DW 
MC&!F:\Y0WZ6E_Z%[^A'T:$(0,-=IUB]YMN:L1%()..$_+CDG'8H#5FC-<BJ5
M$W0Y]]#_M KCC5Q"8G(;B\4\*[+/.KOC=10<)ZF]91)/.0M3? &D_N73U:X;
MD$1T)AEE>8=&WYH41=*E>RF47%D@%'/]<+E[6"%1CB?"9TL-M-=U*UO3RG^T
M_:,;QS*IWC!"Z]40L(E#J.$9ZW SE&3-Y2A\6.A;#>"GF6\?LZ=LM>+::;Z5
M))]MY^*:!:[ZZJR3,R.>3)$ E,B%"(:[_*U7F\='!):A=4WB%"*E,NI.TMU<
MMOV.\Q/]^_@)8WQ"50IV6]2U.#^?P'=>$B>4@7+.R8<%3MCT&VP&5%YSJ7OD
M'>B!5X(NB>!(+1#19B*9*=J!5;& 4Z/FTV?L;#3U9?9"C=\E%0=H(-OF_8[I
M6CC7^<.B6#N##2T W+BP7$I& ->2\X8Y_;)=9CDLDEW! E?6BV=@@J\L6]69
M7MU<4 82X'QOG+=O1PXG#M._))VHR#JQ!$]<>7O,Q7)?(V7CVV_&8?(IG70G
M-RD.YL>^W">A#&0%R*ZO"R<IV83"$&3VZ6F/3O3,Y3,C^_@A)TLI>]+A[96C
M#2)'W"NT(@;R2^<=,HG.G;(RA!L;"K,R3TUZ:I9/+=6J8QKI#@\G)Q&LBGOV
M*.T:]G8->]O&'MZ"GM9Y.[VU!H(IUR$(SW-^>O\S[([T5LP?'O#$\.E"PQMO
M,.>ZZ!(!8FDAI4-R@8-K-3(64W;#2D1=Q1]5>.LB+CB@4ZY)HH;Y,^<@M8:Y
MJS[EO7OL:_?-/[=%+D09T_/\5 Q43KKGM( &<FW/M*N6#E=ZXV#?!MOO6^TO
MX-.UQN8S!<E-.H@N]$5+$-!_;/*,M?_40?VME+OS6(O'1R1MTJ04OX7?.%&H
MZ%1=.G-V!ZX7#?BZ H&L*)RS-3J7./:A1B!O$HKH3S%ZC))9+ZE2BP(8@JO$
M]-/3WW[!\7P8?L+M![KNU=5V.G',8N!2%AOQCS/(M9L;ND^7F##Q2&*B,W:@
MPL%KQ,77-FU?2/_H3?'_-=NWYF?6ES6WELA&*9-./QIU/^CD+9U@S\<M.AF4
M)U2G&YS8,PY&0RV5O<1-$QYTND'V;YIH<M/$'<<3ITE=)F.3^WANH9Y<GV<'
M//W>K0O'6H5)Z*+N6V(G=;F>AW4IJP0K2.P4Y$L'AHG]DHOAZT,)5*^$0K4F
M%]],-X7!!'*(^EY2[]-!4(L@N/08Y#,9WE+@W@WTN4,2(;8$G4Z&>U](UA,Q
MFE5>R5>M@Z^FF8Z7N7(_A<Z:J#0>'38U-OI/1>/A>,CI"1>[UP=QN';^/5+'
M&3"=I'^O:1*]5.YZOV./7!>.K64\=4%S@IIY@AI[ME0OIC0V<VIJW$$=-]&S
MEB]$%,R*C"\($(JJ"U2TN-2TF^\UHX&AS.Z0YMK FF=+?:<?7_/R1\DO.<W"
M N([S$Q:=5%>'B<FX>:I1"1;+=L(*$HA@O7&)(IZY(8#,'J'S0BR8U9$K*8[
M'+A- &)@W%%(NTG^VZO$4W?[E ;M !$A< Y*Y+B-#W9-=1]@]L26W0F$A(TM
M4*O3?X$+ACA-$*LU&H6^_/R"GW#X49Y((O%/,$CY)[Y*0'/TFFA@RB3H.ZUI
ME[63-1-,U%@N\P[OM"KLDU"/C* V.Q4ZE(.HZ_Z$#9EG8XOH.SIVC1GLD?\%
M4$L#!!0    ( +V*(QE$^F[:2B   /M2   *    ;65M,S@V+FEN8]Q:6V_C
M1I9^I@']APH0K.6$[9%DQW'4<7KE2W<;L=-&RY-I( @,BJ0M)A3)\.*X\\A!
M8P:-?=L_O-]WJHH76>XL!O.RZR2(6'7JU*ES/Z=JL/7\W_DW:-&IRS2HXE %
M^#?UJU68E%X9I0D'8D^MZE4:Y:$*$[5*,93E:5G?U;OJ"73_'NJ(4)VKC;/J
MTI!4EV$25*$JJEQ=G:B]PX/-"X@PNE4C]5SEX<K+?ZO"@ELH=8'%814#0Y:E
M>:DR+U=@Q?'YF[D:XO!OWUSNJ"P%_KLZ#_,N/^SF?IH445&&@ZV0+*L>U&V:
M^&1@H>[R\/:V#@NA,-Z.DC+,\RH3[HZ_6JJ@DJU<%251&7EQ2.8/MH#R'\#<
MW1<X?*\HPK+$+PIF^_SX$H>>XE>5A#A7<I]&(K#2BV(MSM@;;*V1ZP+>JTH,
M9&&^"DLU].Y#7RTB$)^%E0JV07'D>WY4UCOZ*_3+"B0$Y)F?9I$FP.+]0)Z5
M4:Z&::7NP[S8V<"D7?+ZI6&+FKT^.CQ\/55O#<V!!U;-WG5H!S'?IVKX2U7\
M5FU_4 ?[ERET,_%WGCR5OQT6)8@)>C0)H[P@#\$YE2W?%Q%$K\8C_KW>52=D
M)Y&52VIVE.#4$.C2\ZN$2,!4K%5E6I7A)M&'#Q"\!Z$^5RLO*E2:#+8HM-Q3
M2=@LYY:=Q4GM@QP//UV><PEIK%F:/10T"E,UML^3<)/^N%I%1/;OM78:!I9Y
MFOQ6U:$2Z9)C5BG5X>%2#>V1 Q[X_(=K8-L1(5ULATE218K<).$_GI[/O^=I
M2F@([0-ZF*ZR4O0+!\'F^%YY22 ^H\"92E<5D.A@BTJ[2),$_TLS;1!!5&1I
M$BTX)6+G#VJ-S.9@#8X()!17[/FA@@I01%Z6?RQXOCA:D608SJJ^\X2#[U7M
MY]$]Y* *G._XZEA]]MEGHB\NI!@^^'&54P5_J+T$'":1D"_\V%WNK5;P &GE
M1S1<'@F'PTD640P#P, ]9 EQ0)>:8\,*J#>JO@>QE4? Q_K]-?0[H\&N^TTM
MLM:L*DY7]V+Y@GP1IWYA=6%7G<VG\W,<)@+S4U$ [4P\]>KTVN4I2P4K\B/Z
MK=LT7WGE=+ U&BW5L^_4,*A6J_<[H*',H0Q)!=W Y*%,8OU@:ZP!H<9Y.07;
M[X0.<"3W 3G6D##]SB2_HD3$/=B:Z/7B,$_F^#ZT^/Q?R919!0VA!KM@"WVE
MUJ.8G*;^;4.APTI[CY$J(C$V58@U!W6>5G%-KP,@OQ0>[4S56/.0;L^L)GN]
MG!(;EN\S&KFAM&-6" %)8[ [KIJT6%9>=0_[#35+]_0$S&V5I471Z$+K"Z':
MVVE6YSI,#@M!HR:'!Z[",:S [Z,<P+&VJWFDM-8T=BBTZ-B%Q;-KO3[4KIMJ
ME]<F*H R1@#XECRE[^")C>'?BVK:'2'C&!J3:"8B7KB/-BW(>S! .Q=Z?./O
M:2 ,84%T:Z/OQO"K3B##_+]M@(%!WH&#L\GHJ=#[B>A[A6@KQO?8\K3?"M7A
MB%SY#1[)]V*_BCW800&?89PZ$%FWKH,LZ%A$I;@A(\80<[&(V08"KWH&'2XJ
MB6,F& RVZI*X)9I#\6HQ7.U&/:VPP*LF8S$YGY/"?<YY")OU AP?9LLZ25<?
M$_%861C7ZO?<RYYYT.,DX!HON<,1"J,G5&^KJ>V1H)OTBK-K?6XX)EB '%Y;
M3I6WL&KM]/M$O#<Q/*!OJ,',&GBR&L=%JC#8*MX7Y<=5*,CA;.CE/T ZC2R#
M)F)2JLR")F/ NX1 3%M%'R5&><Q49B-0"[6\3S6;/'A7>*+MI\XF,<4/\Y* 
ML! Y7..)"U65$=4]*7?5-76X==+WP,<=#,3&5(Q><K %^A=I'N T"YNSM4HZ
MA+!@&,)_FAHP4>S"ASHT,5"2NL=*#H[<$M@DB9(P!EU8H(X]'"I?MR5M-MKU
M%%HO/=^O U#WH4??8.O[XQL34&^X@7.$[&?I.,^'T![&N1*Q;$? @*ZLBL=0
M,9V4!4)8]AJ0T7*P=7Y\<YN'H8/O"18(+86'")+3^]ICF7-H?Q$MZ#T[A(%0
M+!^=CI<6@ST-N&O9TC\6,E<NNWGS@U)':CP>C?FWZ$R\?-E,C#AA^';I^7EJ
M>&8YG:\A%Q@'!.:A%[QW=%!P88D@_$:2+8I57:0P(_4[1'AS?HP12D7<XXKK
M$>;%'V]F0INXJ*&_3(MN'J=1>9*!\. T6I.14?<-UV#8&O!9$[48U/_)7)S>
MJ2YIQR0'N@G\B]Q+_&6HQ6*.JQ$D$AV9BK54[5K<W5/WXJV>8!CC%)T!A(:D
MRHK,TJ\1%=O0">8G"(R)7QGT7WS!?#2O0/?LG7OR3M@:W28+]>U_=#?^3B84
MHM*]\A\>2R*,B[ / C>L9[31*"NFJ=X"GC-V?UUT=5XF*#-.10O1:AF+TS0#
M/ULY*_6+__"'X?I@ZRP)+ATH[G/97UFUH<9I13(JZ3AO?J!:NIOUB>N[ZN,A
MPMZ+\(*Z,!]=-95<U7M/)I/J6M<%6M4TNLWZUDA64]/*%*:$S3A4A#%BN^#;
MQH_[L)(B0!.1]TC*-39+V*Y.3.C2O-5'JJ(P=$$7+!F;Z"BWE$3#6# 0&I/=
M_?^ETE06H\Z:VT:1J:3>TN6AS03'&UUM5<B QF[?6W*"X6S-N;M>W%GB+3\%
M1JUM5?0:[+*(M5L[>X"Z"[54S.O&EW6#G\B6:E#KVO.^SJ/;2 JG"!OS/_"4
M$:2PF)K ;6-M86,[H_WFJNQ9BER]W+4HOF@*_1-5=$GJD-/ KDM#956Q5$'1
M_C:T^;%V)46U4-Z#ZSW(%UF)^M%[@'WCQ]'G3.YD)D ^V0$*+%  H)<OM4"U
M)![<H)C^]&SR,UV$9A&4YJ?/QZ.7+\_.?C[ZZ7/]0Y.QRK@BY(KQH1XK2E][
MG>2/CEB@<\HB_A/,AK'(Z2/FYKK2>F(S?1A!:YG0[-_=WH]E4 :F!DQS,$LS
MRU3^)*^MLC%MQ]=#N,J8WVSKY*OI#K+^%^<G^?P5JA-1S%"\9Q)ZQME8\?NW
M(G]JHA:[L<!&Y(;^KG*S>A1ZKLP&4GZD\?H>;&7U=%W[1&PY]&^/QNKH.[/G
M3E?08YMOC/3?PGGN/2 -^3P(1D"QS%%K?JD^/[1*Y 4^_8 7,WYX2PW9P/FW
M/:!E#^A+%'S/_-LO)IKWX883]LYFCGN6>(M'AS71I=B.8JGZV4)ZG YKL7MQ
MK!JAR-!_0JJ);\*OU14#Z?<H(+!Q<D)?2PSEC:'SME8\?ZK^DQYKR081<O)W
ME_-/U(F?JA5?([R$52$EA?1O&IRZ62#%>OWI7JTK5;1NDI 4=@!;/'>L:W!Z
M!)("7K?7YH3%/"/"UY<S5[V.[I;J,ERE^7LU@^-W;2CGZ01+$&85T3#9-Q53
MV^:"8SR+I0&"NB;QI= <T04MIZ,1^S$A2UPD"?DJ2GJS\C\7U,%60KB$1YW-
MIIY=HJX0KT+XH0Q/]K]/9?3P$#_HYEEQYQ'KS4(*)^FU/>74Q:=+6:W=-I-?
M28>[S0=IX[!D'VS9[H=B81@\CD-2G=5(0$Z%24T%F->HOR'C@EM)IQH*<,>6
M4YHDS+8+4G3Z9@ZYO]=-0E:+)V0F"E[UGK1]#+I-X,JVK@9;EH4=W4!:$,=I
M%=I^I 66L_;[A'K#?TA2(1RS+5Z@ V'(6PJOZ19)%E0_U'Y5TFJ>2Y,JKHH^
M*Z"O]U))"[@I0UT%PR:3V(T(F<OA%/:TNJ@(P(TZU(T$($;^E)C-F.(%?9[^
M5FT;J;(4EUJ/;=LLJ@L1G^$$=F-+DXQF;;PK.L\>KG0DSRZ/U3!\H"6% ?RM
MJ#^G?J4&=6X$;,\?QF76HLI+32- X^KWNPL4M76C>&%7W;3)01)_P3DE+4%^
M*.T.HU_%KCJ/:;!,1RC'6M*_7Z,XA3(2R8X($BX!,Z9RI^D/MBZTP68AO.<M
M-0N)81Y)JXT5K;8MUW:1V.F^0^*3,4''7M#^NT3ZMS!GL 9':GOOF0+KP2<<
M#8:VJV85P%W)QTR"SN[Z-K2+_*#NE*%8M$A8Q*^=>L@T(95T/M]5;Q)-;3LF
M&A5)2^B6CLM@U-T]XY$07]83YA:M!]-2]IYE\M57H)4M'+=%/-@"9!FQB\]^
M]A](9((Z@XA-,R.LJ#2=O@P$^,^5Z+*_ID)_I0I5&5G8UQ_MB*V.& /LZJ;<
MB7654_?&[#6!W$SDMJL7=QM.$'N8W]>V[:+O] 9;<E\3)9IJSM[529V;&SA1
MYQ.X43B1,SB,774E30[-\<Y&@LSE38=PVO! &F7>G>F1-PZ2?M&JK;EV.[N\
MW#L\V)%VT1=FD[:3$N12O@%SJQ'6X_"FP[K_N_SOB"(?V)7NW1 -Y79G5<5E
MA/3M <+<P9%+-7FYA-O573*WS4.EO0=N,20%U6"+)Q(J9^^.]O<04W89R@U1
M4JX)=&G*C+RF_]-9_>SBZ)#PI[6)8O!)7IQ"2]OKN* Y8+O)F(O.YM/C=[;.
M"W*ONX9WG8U"@B,Y5<!?>OE=*%ZY4@O6)FSR24"0JU$#'?2XXU*0G6LQ?0GY
M&C3W]F8 L+6Q.)*8D:X 3SU$G=D[:2 RK(KYLK,HH9#V7H:N-%8A?QDW5QV"
MY?AU=Q/#&GTGP@:FAI16/KQU;'J$<!+MU8[))GCD;G1DJO3==Q2427."[@4;
M90-RCD].=;O=+VM7+:-=.,LI-H!>C?9&8\T[8+)[[.V.QG+87O%=K>!#Q)=H
M,%=1;"';7\*#^XBC9"A0<>>DBAFNP"Q7.&:*07'PK3HQ[HS&<D8=F'-"\%S?
M?@M<T\X=L?CWPAR94^GM;<$[TWXD-_D3T$X$K6T,]]%VUS8+]C0=II'"@'T7
MIXOFHGZTK^_'FN[*!I"O'J&(6;#;Z8--&'H07PM$#873W4YS?=>]YM^4^@M+
MFIB4EAZ=YJP9,5W=T3>";&8XC4CVF--!R%9$;:[E.^Q>8CAFIB5Y2D[JU[O!
M=/#892:[7!C&]W?16 !T+$"GM4ES)#0V_E^#SZ<XD[X'M=>@!6I':7AC0&Z!
M0UW>PGL/3__VYNWI#MB9W%4,ZHW.@.82$;JX)3T:?%\--;0]EKT$Y>1!@\NH
M27=RMKZR=T-*B)/UY>L0L%>S=J3DMI/)9* O!YY(S[0WVK;TX'3FWL=8FW8J
M.4MWSZ\E]3&PXP.!$WZ)K;:F;"R&GKXP8D*F*P%>$E2;-C#+TLVUS@L1GEP+
M3ZR.M0 (>>;K-S9&G9LPW'C>T<NE>J%O7M1;4_1--9CDRW0F7A8AF,%9>;%.
MNQCC]7$*]1ETYT1TY\<V,=JL8Z*ZQ^^H18^+)ZVM$)5HV8L=H#TU*GG_9XA'
M9T;#<[XCN4U%()^BX?74O"BHI$+9G)FYIC8_OIAV(#2BWF,* ]<S6B@'$U-C
MM.0R"#S!XCN<PD#U*#0:./S033!%S#N6CG?3A(\5Q*4(!BVV>=1]>&3X2"7,
MZZ"20!B'IHM<:5\?Y@$[L.;Y@74_?VW(P4ZMGV<$1D*=+<.B%>$CI06V<<_-
M]+!M !]LG:122]E'",OZP0LB/UIYU0.R)T8"!&JVK-X=C<"#PY'3:&V4X#P)
M7>WAV'D[NY1W,M!X_6#&ID:?J:&T5$(&&V*8F-LI[<H/S^RG33\Q]M*.17F.
M@H[O#!:<^&;D9#J_D,#US=AAY$Q]@G!ZX@C;I?S(D/.;"W -O"? K/IUE<0%
M^X[IP^(H^H%?<SI+-2KTA(Y24D(E/KZ2C'2'=[^.M4^FBJTV8FKLE"FFK*9R
M7A,* <XFCM$T\E!>=F!PS^FY7?LF S/[3L_G=F:^<AX[W,[T@?/8VW:FOW::
MN& ?@&#TT"E8XV4I$C@M9^2,DDB;YR+L'1+P&V?]\0D&9PY-CFQN/"5&CQUM
MB,+F[L2)$]3,PK7#;/Q!QP5H"YV=:KRAKO^H!GUW/-@Z'CDLKT0B6OI=@1R/
M&UD1JC<U<:PKM/D201K9A+V[[#FCK0-YWER"#3=7S(T+Z6<W:7+QV,53_@CO
M)M0E=^7R.N5Z)PB<%]J#B&Q?BSB=X/?>Z!N18@M["G&N0W*L!W>6!/-U.GD 
MV[#\L=^'5!>>S:,__>Y5;6Y8.L]-/Z^4'A5W>2M/0,S;3\GM*4\Z'#Z\ BMK
MWM3+E:2$X_%7S_;4$<OK\$&GH83CJQ,UH?,]4M?G+M/F2%WPG9(\EWIE8+#\
MV8@P;Z\N^"(#D3W^>*>K+$G?1%/;^[&.$P3K_#S*-"4'2BT6#['CQ%-V[G))
MEOBP8>FM,M,2'&SM*Y5EBX7C+#9!+3Q:TH28"//0P*A7[JD[<F<_7B >*17C
MSW&R;*J3,MW7RE,>QE#JJBOW% ?"<:_?9Z*)KZ;J%1Q2%8O)&2Z85J4I;W2*
M9UC5G]K_'N>=(J"SF#:+K=8/67W])8OB<,>F2 ;')H@FV<)IIFHX@_^(Z:=W
M;&9]-;51P&"Q,6$H32&7#Q-#7:C#-*21QRR&@-P =%X!L15.FJLK$6H(H5Z$
M]VPAC$93,>I;WA&.Q^;#HUFSI\OW0(;&T^L>)O)2#<>(Y2@18VS% 63-N]S]
M]/IHS+QC=/:W6=O\,OW&Y^IL*CU W?MEY2=/HSS,_&VJ+ZP\>23Q.\0C_ "J
M\<G;!I5^]\?;/G4R#5(_DA<5Z8KE:I3<[<C,VRFJ7?W8@A>K%H^:3=O&<TON
M2,C%GV.:/0[^QIUO/3UVKN=S2%:LI?6  JKG]B9K<[)P/')@;QKGN(]SW,-I
M0K' ]1 V,5KQILFYXNT"59S^P2S&HL=3>KE>-K9SR+S^[B]#1U:,N^3@NT'0
M?RJLMQ@_"=#9:-S=*"<=3DOAX\EFZ6#KI6DXR'MTWEM3I=C5,@NN239KL^!W
MU5*-C\(ZPL;0P#L]E=T$67PSNBFAH#>]1<U'L\/V>?=(NB]^+42:374V<!.G
M3VVKVR\J6%!=['9NEX8>HJ7<GR)P0.M92,I=3F$[NUJ$'U3#C0[3]-LA^J63
MJXMOS]]<773/,>/*?XUFFT+\"=$G!JRM*O1[5KY2 LGZ<H W#=)(\<0CN3H2
MPG_!.;:O#/F"BS>M@$*&5>6V(R%'WNG=$^JG"Z?A;>N*''@.]R):N3>O;DY!
M+IRI>W-U ]=W<WI]HWT^G07H5T/ [2A>)MGVC)YQAD"R86+A#)6>D@O: ]7 
MM! ;]\+"EARNCM6^^E(-^8_0H/%9=$NUTRYL]IOLK[_9P,%%P@X8YJ:WQ=I!
M72N[SHD!M?'$P-!LN;;LB3/];I!ITM=)FX=E1R:G9_.3M^=7U^911O^57/LF
MF;EPT.8.TL9MECQ3%HNI^^01K<<,X;\Z3W$E/>FD'\WJ</%@>DD6,C1Y10OB
M&Y!^;M+,>W$;O@2D$+>G^Z)P$=/UY*)=N=0KF:Y(LF)FVI<*(9]A+/"?WSXI
M^<F>^&?7C)+9(1^W'3P&^G+RL[OH@"T:, 1HW[X&TL_CENZB_5HLS;.A-7S[
M#;[^^($FIR_P5T\+7)X3;12]/'XUA7PN%V;&U%&FUKRS-9VW#?+73>/_P^(W
MSQ3MH7XZ:%_?+#K#^^VP%Z])S6^_/'QI'M.X@7=DC)N^IJ,*Z^@G/[=0?;WJ
MT-;*^OF?_C'2JN?_F[^V^,,2;BS+BZSVFS=*A6($-IYI'L8W%Q#[S2SGI6I(
M%_3"3%W=(.R-I'A#LL=J>14Q[OR26C<VGW=!NLO&_;'YAC&!FVR ZX\5<%CG
M5VT)*0,O4707:V.S=VL#)^L#I^L#Q^L#\_6-CM<'YN?K2-<'SN;K=*P/S-<'
M3M<'F,D^P7?4^$5/RGN3?TW*+JKAX8L7_U/+U>PV;B3A<P?("^R)DTML@[9)
M28X<.9.!1(HC+621,.59(X8QD"792T1C>BG)F.Q1P +[!GG5/6Y]5=UD4[*S
MN2Q\D-E=K*XN5E=7UT]_T-MBO_S>=#!7__M[X_7:F[Y^<_^3[X$V7@%M6* *
M_2!/&W>'%G<A"_,:O[4PU!LA#?668*\EW&OI[;6D>\/U]EH@$SN8]UK2<GJL
MZCQXB3B4#B_1+I\MJ7&]/;FQF\+]IFB_Z>-^DY$PINBU;PV;O)>M ?062(]4
M?0"7@9Z=>EM:_X2.&X:3/ZOC).'1>&[L,](*AYDCD7WGZ C'P6'R0<&#W"\*
M%237:IQC Z)37)A)[).#+IY2D8K5F"9[Z]\AMJF2Z>KX7\?T?4[A_GN</B[4
MY'3B1@1$8*=-Q8K>:ZCQY9#&F4B[NFVBM4E'L(PC+].B^/=:J9%; F#[\5IJ
M.)[$JM9QAHXSU8NOQZ'N 4D-!"!5_#R3\M<7LNOF"T,O.MLT0:OJ3!+#K?YS
MYYT*\\V]SD*D=[O4%SL'[[U#!OB1 %)3.,B^SBT9!(22 $%;0_%6ZG4)#GM1
MG8A8$2_:Z.]9>#05!@+1'^J-,#X[8[/EPNX,J3,IZ-N(+])XVE7D,JU,9K^&
M !_$0A!1YY7H"Q:)I5+'\H< !G7VQ1$\LUAE>*1ND:?K^P0EB1:B1'4<ZXOA
M9JSHN. WCGV,5=AC26I(U!'^NLZD(V=(%\X0"(#KC#K+_#&;90NN[B0933YT
M.)T; ?8@[1ST#X<)QU$RKC>HHJ=D#TGX%"1A@.R%,6BIKK"P@&A_MT;40;8=
M9V0?6,%'X[\RSX>HEM6OKSB?KCS"ND[^.]R5SI2+U&J12G@]O4[_9L)13CSY
MG2%<G81^R!XJ+C+CJE8NE^"#ZO?4=0$*Z$4!J7DYV ?XE1J>$+:B62;7= #^
M#W[M;$&N%]Q]E8LU7:))"A*_TN]7I#D>.5CU4 ZTN)FI #@]/W<=\YVX7I ^
M WT#]-LL-Q%K>KMQ)T:GT0CTI7'*UL4=1"^M?H?T015+948A"PW1*CTO4HFD
M!/1HM2\M+M8RQ^[9UB'TTMD=RL!CB2]P;&'!V83$7Q1SPZ>1+9%<B<,/ZDFX
MN)G)X+A1P5F1<?3>)V0_W-4$9IUOH+-72 "AWO:=(XY',PMQD3?!UYH0(/J*
MGA883>OHM6G9W"1Q6II0GL@4'==(UI!0^616_E8*74F5<\WRT1$KQJ0 .])9
ML:#9O'N'B/*YVI$ 9O"[CO/WO*#UQKD3;X'H2A[HK;= @OC2A^;Z@_Z&<^"5
M;M/[+%]Q1/JM%P;38AYFJU^AS=Z"B9;Y\_-O&BIZ"RJYRL:<1NI[BIGTB11R
M#BTFCW.=U26:K(_B4AW<]QNO0>A ;IG*X3<%:G@:.SJ=DQI;56. ##W_K&K 
MMS;77U#/#[JGXK/?EJ:8B!^C;EU=Q9<P([(9/?VH>GF^3K$@Z:DKH /S&?V>
M"M;%\KA7+*;$%S]0@5W1:8)R%7RH)NSCYBQ;!)9.G)=LO@6'^F47W\O!F< \
M0R$\JKJU0YUO'EENR\"1$WSL.@?3U2S+2),<1]$A:NR/FY$*X_3;;UJ>,D60
M$GDLL3M)<'I#"K+E[U,G0#0;XE2K9?HU 3."F:TY0WV7EO['[NDGT*,)0<!<
MIUF_Y-F:LQ)))>"$_[#DG'0H#EBA-<NI5$[0Y=Q#_],JC#=R[XC);2P6\ZS(
M'G5VQ^LH.$Y2>\LDGG(6IO@"2/W+IZO=,"")Z$PR*O$.C;XU*8JD2_=2*+FR
M0"CFDN%R][!"HAQ/A,^6&FBOZU:VII7_:/M'-XYE4KUAA-8+(& 3AU##,];A
M9BC)FLM1^+#0%QG 3S/?/F1/V6K%Y=)\$4D^V\[%-0M<]=59)V=&/)DB 2B1
M.Q ,=_E;KS8/#P@L0^N:Q"E$2F74G:2[N6S['><G^O?A,\;XC$(4[+8H97%^
M/H'OO"1.* /EG),/"YRPZ3?8#*B\YE+JR#O0/:\$71+!D5H@HLU$,E.T ZMB
M :=&S:?/V-EHZLOLA1J_2RH.T$"VS?L=T[5PKO+[1;%V!AM: +AD8;F4C  N
M'^<-<_IEN\QR6"2[@@6NK!?/P 1?6;:J,[VZK* ,),#YWCAOWXP<3ARF?TDZ
M481U8@F>N/+VF(OEOD;*QK??C,/D<SKI3JY3',R/?;E"0AG("I!=7Q=.4K()
MA2'([-/3'IWHF<MG1O;Q?4Z64O:DP]LK1QM$CKA7:$4,Y)?..V02G3ME90@W
M-A1F99Z:]-0LGUJJ5<<TTAT>3DXB6!7W[%':->SM&O:VC3V\ 3VM\W9Z8PT$
M4ZY#$)[G_/3^9]@=Z8V8/SS@B>'3A88WWF#.==$E L320DJ'Y,X&UVID+*;L
MAI6(NHP_J?#&15QP0*=<DT0-\V?.06H-<UM]RCOWV-?NFW]NBUR(,J;G^:D8
MJ)QTSVD!#>3:GFE7+1VN],;!O@VVW[?:7\"G:XW-9PJ2ZW007>B[E2"@_]CD
M&6O_J8.26ZEPY[$6#P](VJ1)*7X+OW&B4,2ING3F[ Y<+QKP#04"65$X9VMT
M+G'L0XU WB04T1]B]!@ELUY2I18%, 27B>FGI[_^@N/Y,/R,"P]TJ:NK[73B
MF,7 I2PVXA]GD&LW-W2?+C%AXI'$1&?L0(6#UXB+KVS:OI#^T9OB_VNV;\W/
MK"]K;BV1C5(FG7XTZG[4R5LZP9Z/6W0R*$^H3C<XL6<<C(9:*GN)FR8\Z'2#
M[-\TT>2FB3N.)TZ3NDS&)O?QW$(]N3[/#GCZO1L7CK4*D]!%W3?$3NIR/0_K
M4E8)5I#8*<B7#@P3^R47P]>'$JA>"84"32Z^F6X*@PGD$/6]I-ZG@Z 607#I
M,<@C&=Y2T]X-]+E#$B&V!)U.AGM?2-83,9I57LE7K8,OIYF.E[ER)87.FJ@T
M'ATV-3;Z3T7CX7C(Z0D7NS<&<;AV_CU2QQDPG:1_JVD2O51N>[]ACUP7CJUE
M/'5!<X*:>8(:>[94+Z8T-G-J:MQ!'3?1LY8O1!3,BHSO!!"*JCM3M+C4M)OO
M-:.!H<SND.;:P)IG2WV-']_L\GO)+SG-P@+B:\M,6G51WA<G)N'FJ40D6RW;
M""A*(8+UQB2*>N2& S!ZA\T(LF-61*RF.QRX30!B8%Q+2+M)_NNKQ%-W^Y0&
M[0 1(7 .2N2X@ ]V374%8/;$EMT)A(2-+5"KTW^!"X8X31"K-1J%OOS\@I]P
M^$F>2"+Q3S!(^2>^3$!S])IH8,HDZ#NM:9>UDS433-18+O,.[[0J[)-0CXR@
M-CL5.I2#J*O^A V99V.+Z&LY=HT9[)%_^2]02P,$%     @ ?)I[&"C8[B/Y
M!P  :!0   P   !O<VPP,# P,"YA<VWM6$MOVT@2/B= _D-%%]D [6R2Q6+&
MV0?T\D [?L%2)L%>!BVR)76FV62Z2<'.D0MC9G/=WY'_N%]U-RG)L7=FKX.E
M(.C!>M=7U55\]O0-C=;2TM#6IDB>X2?1IE"I(BU(*U=)RII***T;?)..2END
M359;?/U82_H@B4ED+DR&SWZ36F7EL1?T][Y0E!9Y+DW:D):T5.E:09EP3N8+
M+6OK901]TM MY;*JA*E [+R(P W]K&_5F,:*^@;2^<6FSFO"#;!65BC3Z6=E
MI94Y*RL6'V1%E[,S*DJP5ZHP1NJ$[L@):+8L2/<#5>\?A9%C>=[DN"&O&ZFU
MG-7V:O3ZFS_].),KMJ674%:PB8)2S9[  G"._/>>#R$D?:P5K1NK?'!V:/<U
M0!:K.,I_R26YHG8MF>=A47MLEVRD Y/8R)3* O%39EG8W'OE8PG'T[7(2^K-
M;TLH<N>(-(+78V'-2FCXO6/-6Z.JIC-G+(<"/K#Q"3E(OQHE9/KLGZ@KA#5H
M8%$5I%/O,JUDU0O9IK?(@M0QW@;^2"OH@\B%8JCT:X-_? 1]_M[@XC1_!2B 
M)@>G"C^KFI8AR*;+J./PY\)^K!L/$Y:$@)6Z=@J8@L@"X:@<X"!OX&D(SPGU
MGH>K1RV"P-<L%6+ X0MYRH'V&!V..61XAYX]/>MB.8/PL9QS4<@?A%4"4'[R
M%WIYGV8PR/#-[=*\ND\S*HRK;)U6"@0.%'_\6M,^P3?!]@?LYQ"'Z*-040=E
MQ166R3;N=,*).B(1S-H'9E;O<1VH8WF\O1TRW!MO*<:RK8?#AZ0"/4>?_FUD
MN*?[(+3H( V@M1$:OV3 +TC'<SKX6Q22-8NZXOI9JC8AI1:I)-L 3AM($'7K
MSJ]PU)5"_^*N)8SCNMACNZ.?5-I4MXQ,I4F4I;"5XB#%*MIB]0V)GZ03/]=+
MM0U]^V+T/AG66I_:8L6T'9Q]RTD+BZB4A8$1E3RA/]-@9=$JE3T3'EY_91XX
M5^M*5.ZDO>W;RR>//PE(^NKTTH45^6>4HCL)*9F,WJ,'9,I;+<AW:AA?EZ5N
MVLX9VW/3AGP+B*@$3D(4'>,*WT9HPY)"2'Q[NT,5LB2N,2BQ64*IL+YYQ4#[
MH,$NW_ <B_%0A$N<D2XH60'?$&VI4<BIYU^A*P=;5KI8"(V.Y$^::*1+6)BL
M4EA'QSBHY#+I[)&<<VO0%6"Y-%D9,L(^O%LCH&=R6?V6K%PQ9*YA/?_Q55*L
M-#@I=@.L%<K3N\NF/X"PQS*3*=;+M1RY8IH/MNR'O\=L# O]29CBG<1-]#/T
ME-^2EE&1EP)GS"/5X@-]Q$."IWJD9D#Q/R;POI1P'PG]/66&7^P#S=F8$. G
MN%Z\H/F_7+7FW[L4X4C:I3C'U#+$4=!)&J'%V[=FCQ+_B5U23SA(X::T=_=H
M!S<X_'&&S(OZ'L-H+<R*81!.W?$.(^M82]QM66;J4VOXN,'1"?_OZ?%':G%[
M3\<I1^H*'1+*4+1["C"&UD:YO!6,H7 CV9*OW.TH7]T7^]8,=9&.HV!WG_YU
M%\:I<8V5#]-/A^=T\/W:_A-A.NR,*4O+0].#'&- J.J",]2B_KBOY[+N!%RU
M(Q3+<5M!K-C@MWY03%X6MGI$^[5<B^PAKLG-?^$ZQXE[#OS=OE-;[$3N,/I_
M^4*CR_/SR<5H0E>#:QH-").=OT,C/['N3+EQ4N%YOIWF>_2\/;Z]#\/S'[^W
M[:3S:VWIX00]TIV4<9\AZ8(*'I8=S]_]."M%"L<3B&F[0BE<F&9YB/%M*F%?
MVA4+\\\*=+S%Q+.];0!Q>\OZ8E'8C#[4+$V4]C,6I.I%4>_^D_#$%/1B-"/!
M6O&?<P*-S&\C69SY'-NE"Q1?$I< ;G<)=Y38=[DI.46F23V_W?9AC"%8@9"Z
MN!#^OQ$_W(C5DOX0]IAX<;00)WT'C>T:!$-<%,+*K%QA.V?8>:!-!N^3R1#O
M$=YCO&=3?$[I).Q8HMXPJ0N+*WILPT"L!,\CJ6W\_G# FUI(>MCJE[R$I859
M*F'2.#PV^%WDB)Z?(Y$4 RC30O'.T=F4A+T]R-HA X;547J;:I_32N:EPQZ7
MKA62+'U 6TID,L0Z:X4'81$'?EL8S^!E<CI+OIO!3:^1X[21]4WP!0M^O9$^
M +QS\&:(O$5$.B]C-#N97H&;'>ZC:OC9 .N,X($U:%&1BA=BW5?MOH:( ?RU
MMS*VGE,M5LA'V"E<._UQR/O8*BO>L1A87/J0Y6MB,KR"%VS"%UQT=I?0SX*+
M#EW'><'/NVUY&J?)A6(4<26D_J0B6P#2QB-%[R+#ISON02COO,C44C7MR@R$
M)AQHPMHHS5'U2WA6T4'_F'[P$.3;-\@5_#R)MG"<N4U9+HX[CT>Q6-AFH_RJ
M#5T#M.>+\70^O;R@\83.)C-\G$XOIM=T=3T9G V&9Q-T[WD0U\FGBQ&:N?$/
M,7"DH^.D4-_A*E"/YF?7,P8FKX1('#\WT7LE@<0OR3<'IC^-B3EH";S!F16E
M%/7-87<.# OSH:CM_IX%FTITK8S1&5!$KT/P!^^9\CKV>] 1[VV+K1"<_3/?
MC&+@XW\\Z^^H]Q3*>(>;))BN ^K?8PTW,7^'_I$2:(,47'[O%WR/#P6F?_F2
M$SB:>63Q-F.5!VKL$<1M>CPC?IX',*J-<GX180R\_/;;5VCPNN#')YH/.O^,
M!+ZC!*@70T//>Q2O-W3@NR+W4^0+96P+'D@L/RO93ICXII;/GOX'4$L#!!0 
M   ( $ KT!IR0QX.QP8  (L.   ,    ;W-L8S P,# N87-MC5?);AM'$#U3
M /^A;,"@"-#48L1P1 0!31(R$2T,20GVL3G30[4SF[M[""O'"008^H!\:XYY
M53-<K,4)=9BMUE>OJDO4:ZQ_Q+]><X]ZU</@1MFE+BR%!:79K2KH<G:6/!3\
M7E=N>^2@-1F\>?>6LH*"+,F5-XM8-_>Z7V/C?'//1'38:/1HJA-EOQ3:46[+
MV"0F5<9JU]SCOV'Y^8XB9?P)7:4:$CHQ]U;32EMGLI24<SI9Q*6F_>/C@W<'
M/Q^WFWNCE+Q5)J43FAJ==IM[?;8!-3I!?*_I.C.6^@F\919A9:FCJ/"%>,7G
MN79>6XK97[:T*DFTI%.DA'Q$9!18MA<KRI7U1I,M=0R%#4[[)H6-2 6:AI>S
M*JA .0HU)5EH(A.(XRJ>F6%GP09LO4+8GOU![L8@EN[HXZA3)Z'BS'*@"PB1
M\AZB#,4=Q2V3&F\4\!7C,.3(Z64""==!8)Y328%](U3(>5-=[6EB8CW5G$.W
M#J=6I O.AS\18*$[5C8KXQ#4?MA2B\R&!#'$%62A[E"8I6FIX2Z'Q0[!98Y(
M=.H*XW6WVVUW8*%*Q-M[]R@!7UI3@? \NEVFQBPO@PV.#D#VV_2^\'Q'1_^T
MZ^RJ? DUA]T(IL TR>[6^7O4E7,2(.^XV($&G^"\IJTK\BJ:[F,3+<X*RCF*
M"G445=.[0^BMC/6%CA]HM$Q,MZ2$L'\*"\HD8Q!*I!_"8&@<@.(6Z7 ]D+LM
M 3*(7CFOTN'0-XU(4D5(/K E\F=F<5\Q=/TU"P+DHQE3F'$UMHY,6GC#+P#O
MFH,P<0P,MR3FOC\ D\7VF%^'QHL9D;%%+F7H,!Y.;Q !IKY<EIR1RG,IXCH#
M\(!!YR!0[5:!]IZ?#LEQ654LA:LA0,QW%,"$CB+M:S@RD(9%MB39]-Z7PNQZ
M0]3P?X!ZXN']&$];MP6,2:#,,([2:I\5%K' #BM&&$=5,/#[OBU^>;9X+41[
M38R==$/,G6U2:?$\9LSRS#DNJ*!1%R'(TE7%]U2:C9G\Y"2JK$\L*FIU-1XP
M^]#3+2X%FT0.*KE'YU626;'BL595T.X.CU#<1F995#Y(K73 %16FJ2#0.4H(
M*\C+H??- AF"]ZAF5I653)+')D '(ST3127"DGM8YC1D=J^')7<_C,$TAB;0
M]#S^$Y6&#*K/7I=?RZ#PBH$!R+%*@ZK8DEGWNV2<KO@D.4@WH#D_GL\X?7!=
MI6(;T=?C(BG]#5?SZ*>;.@0\7 _'L]]H'[ZD/AU2$2-3892@X]62B5I*72)Z
MT>[02FH%W>'D?'P 2]>#R;@*K;]6YJS3(BEM!AQ:: &.[4N!/$EZG8?S0Q5%
MSBS3S=22 5UI.GK!5$"U3<0WO6=^-!Q/1X/Y^'HTH^&(!I?GD_%9?SZ^O*#>
M\S^V.!Z.^F<X;S?%R$%TFO=GY[2?*)?\\L>-_0M8=T0"TYDKAYJ&&-R4F !Y
M9I%O2V@T!#Z!-RNN/)OA3L.I;M)E<^]5F@4^=G)CTB"NWF1IZ%B7[ZU&CNR3
MMP$50\*$6N'2>^5N$Q:#E+=%&D"7[2+L6/N6HV7&J4PPG_%*YK;[V](+9+ [
M;7)M$^/:DC4"*/#IY;E"!MWQQ> E-.7!80X44OQEF996Q=(.:Q97!7*((D _
MEGK7E$X0P-K6L(SDV.4V8<)E0;?&Y(G!_&QA:?YI@I*.YC2;3Z\&\ZLIGJ[F
MX[/Q##<_+"QK2[=<7'[J7W%DZ*,?<F@V.CT?7<S!H"L:?.A/3T=7TQ_1YSM7
M('>DBM""RWS\A*")M$]0AG57K%<.F>J\''S#R0_,C=M=<RIKC!2;:J&4Z]&U
M?U/>E&T9C:<V*_(&\ADTACPRM=NL(YWMW79YZ=12Z]6F,]AXZSM7@-:!.V%S
MG;"^ZOKJJBL[/0<S&X)3"\,'P]C66\-.:AA&. D(VP_O.ZX^BGD$X!6/Y.YL
M]#N,  ,<1<H*09#2N"(ZUI=ZO7J8EHQURHL%YBWHJ8_>4DL^MK W74Y/Z>CP
M\ -HM[_=3;N8 B![XW.24ZIQNH_!1XCT99R'&?K7M>1 ?+C5YA8-:G*.:-?V
M)0X7C>X/A=I6QE2]UQ%. 4J^)7QR$7.&SOCC3@]@T5LI.1UPBL(YCU79DLK 
M*A[E.!DYTGU>J=]@*_':<Z]6UOH%SLSUI@OV5%&]^=#A?>RI>.0LDX4N662X
MMGYM49?7[7#VB#);U+=P+VZ9OD_"+3:>4-[2[4?%$NVMZ*.*;[;O_[+Q0'YK
MZ'];V*IBGHYE)&^&&9/^\/#HL(N#@,?9Y,F-^Y'"\49A&X7-^/\S.<J-K_Y_
M@_M'53@!RVX:O<<$;N[]"U!+ P04    " "OH-<:25K@Y-T1  #K-P  #   
M &]S;&,P,#$P+F%S;>U;W6_;1K9_9H#\ _=I=E' ]H9Q)-NWFTCPS3K^R"W6
M28S(;1<W" R*'%GL4B3+(5TWCUP$*(I]WK_W_LZ9#PXEV7**+7 ?KHK&(F?F
MS)DY7[]S9O3XT?B^CS@I\EQ*)9)&O"U^CAHQOO_S^-%$7B]D7MN1/.J]E-GC
M1X\?T6AQE*77N3@(Z+OX3C9IELE*?!9QD2M9W>![MA51'TET1B+-55OA;4)L
M@&@KU>-' 0_//HNB$6DF9E%3AZ(LFDKHH=5N-U]22:4D+8'IH\_?WDS0F$53
MF07X?C71\R8_%56"!B'XY54Q4T'R4_#2>X75F5=,G=\.7EV5414M%--Z4]S(
MJPM^%B_%6$A5/XVE:.HTD^*EX^KRYQ(L2;%(XZIX6E9%3$PV%<]%C<<7W_),
MP9AVIDYI3T&A:E63U5%-8R]!&]W6K32G;6=:_QWE2299#$1O 'IS?D6\NZZA
M& B5"IF+1;LHTDK2%@=Z[AM,G9(T(2@F^6XV4[(V)!,F&9FILS1O(PSW".=-
M1J3S(H=LLJ)I+6EL;ZCD-34F4:[LS,M3=I*\C$A7B'0=+4K00R_TM^-.WDV$
MK-UC6\L\:22MJ8AK62N]M4SCDL?3?AP,7GP-7@[$7PL!*8JD-;K4I$I%><Q"
M2F1S*_[K4 S1B[A9WF^L.Q+_\^[2VW \V>U.$[G0NJE[B1_!E7Z6GJ#TKO(X
M[*FWZ"FZ76?%-,H,,RJNTK*&LBA'MOY'/,=.1/^LF268X=4I;8[\#K,'P6$P
M&,R#\?;D"KN[6$BAVDS&1&*'NK(HW\C%Z82[/I_32]^ ==MA,!QPTT5J-,J]
MUT,N(W!Q(H\Q10,=A031MF?&%%4MR=#26(\]'U+C\SL:]]"X?]?(?6K4(YU_
M(<X/:)']K178@RPD):@C6!!M?5PD<GF!3 $$GL^MP/P1SNU@B453!S37?_)<
M-1Y9^D;K=JD/R9"[,#6K&FZ#CN*Z(<76>ZW7>'YRN=1(;7J)Q^!WI>W%P!?2
M:O-S)ZA>V_F 6H\&=[0.N?6NL223P:N[QNYS*XV%YFHG/_P:7U^?7-+N@J_D
M1]@#=F1BE8]\PXBMN)7B)DW8O9S(V8E1\:(2@Q#_#0>#:8A_AO29@D*G?)M&
MT" :L:+-#QW8U_4[1H7@BX=,:7VK9K!NF&]V1 'CAS0[S;EJ*P^AP#S?16'O
M013NXV'_CL4/UDI'Q_S[!ZP3SEWCG@YY@?V!9(WK)UGMRT8('82O3YI2; ]V
M. HY3ZC(N7[U]0!0Y*L_G]TOZ*$G:&L =XZ@]6(,CUBQ\WO5T'R(^Q4GL&D@
M+UO0Q^WOP\</>(UN_!HW<O_PX8;AP_NYWS3[WL;%WSM\7^O!\_OTX)CUX(ST
MX#Q=I+5T;DP<BOV]/SU_.J11^WLCQ)G%E!#/EG9D2B.$QX\NFFF6QA;,A3[R
M"!TUU\W#::$'L$(')T('$(CX:9Y,@G48^_']B%YKTH/Q? ?H@]XL]\[P35[+
M:A8!.\E;?,OEAEFP!\"_P5E4719O950%LP@X&)+#VS9IL+?O)N<(VQ6P#38/
M8+&6([$=-7&3RQ$AZU2QFQ7IHL1>0EJ,.%O"U(1&=XC:>XN<1Z*];6.*VQ@N
M2C=)CJDA=*# .@40W&H 6,M24G9!Z<0X.+X\?\]\$;K_E9"6&-'[IQ3C2\+W
MDC"Z N:X3A6W)T5*6)8AO,S3BIO+;CQ#1Z*QP@9/+?7$3\5D,CI]=4'D:N";
ME#98(&51O 1,U4"W*\G<B%V'QK?W#/3=,:!HR[28?O$<V@C,3NJ[?7!'7^*Q
MD@ ZS(MXCZ2C2F/:;F56#\9R:7B+E/B%07F1I+.T94R-W:G@J%-TXE6U<KRT
M;:K&%(S6.1/(MEI.<?B[! ++?!J\06"/:&018'H+QH*R*(,/R."$4J-I^63O
M(][%2#B"#\*^I%<_+%:ZP90NR 6,B[]O5.U3;>+/%*)C"OEM-A]6[1,H*&#\
M49;!-E1 *R 7%F<I_<'NTI^QV-W=Y2]CTLIK*,E":HTY?3;14F'))Y3>O'WS
MC6%]B;A>!T][FJ^;5=5WS5K)N^9%3E14*?)G;]X^]8=L'Z9X0]X'S-7M=;MQ
M]^SV47\X9Z%7\#LZ!K.]VHKYH6I*5O605%MQ-KF@)91F"=&-C$DY+U^?D#XZ
MOQZ2+UCO9XA0RY2<(W#N!1EL=!O&:B33,KQ.ZBJ,J\%ZG_.ZL-O2\PI*)X3=
M=)_QB#RV6F9]K3$C#<U!HBP+Q6D-%U/$T=Y 1.AUT\I=,4E%+&D&V9!$.I.'
M(<>1(BK;V&22#&B4&<>!W&2HF'X&0>V$IFJ35!'M<WM-%9ZR:J.,=(KB#='I
M[QO&JJBYD==1E;"KQ6;445-I"2=]?CFE)OL7??/@]XOBYM,MO$X9JM*^X(V7
MWC/+@9&!J6CUX"E6&_&0#_CG3P=/G. _<FO9J#DU=P]+*((;SO$H/I14=A)E
M79%/ @<?>RRQ_/$,&,#/P]DLFN&#U%+.*,A6XN)U>'P2OOT^/'H3?G_!O8&(
M1)2%A%$6LB;I7)PZLB 96MZ2J1C(:*[K:7".@F-OIUQ7!9<Q>J^X*N:G#E2J
MV%XQ&:$0]"A#_J$@5)7F-U&6)O">.\:!&'J![[*^S>W;W]W8^P8-MYY!*_.T
M3L&FUGX*3LN&W _6=]FR$"O6#.%"X7Y'<]ZL-'(N.J4Y#=?HS;)Z&(T0W^:E
M$3Y>.QE=C5:L1>-MK>.C+HR)W>-W;UQGI4)#/TM@1MB6R84S+#;:7FSABH*G
MJD%/5;%S[V64:46%7D%+O+?*%E$_>[(E?.59,RMCIW@NE!F5G,B:$XVRTTE/
MB[[I-$;F?G%NO9@3:$%JI*N%VZOHA;J7G-YZ55\?B4TC6\J^MEX2W>/;7I'8
MXCKR.%YG0SSJ=58B@G](ITVMO*XF&$39X45X<G'^-#RY#"F1&8MH?O@Z/$&V
M=?3=.:?R.HX0/K1K)$<ZQ?_@BEU T@*@IL;WVMW4:1MO![]G.,*2\/9[,ZCP
MD@T(?O&,BL ;0<7C1R6CLG>3J_??!S;=L$(=8>=J.EAHP64-FQ?3K(B1$&A\
MK&$IWL[2>)Y"ET FU,B?EE]7:)[]"DME?-Z5!EU!>OMO;R8[?>TP&S>]13;9
M+-JJP&Q1'/_*(O'F,>).4O!8Y-<-U=#@$+A>SRT*+8C=*?O!R"2\%DA;2KIO
M# DE:R?DY9Z^>46+<JIG2-@VHA%TE?ADBS>K<<O&B%0!N1N-R$9BX(K5E&BC
M9RB&-M6P@SM=,CL"/^0M-6OD,^XJG9F0EM$Z$+I3_,7_BF!<TLY@[KK7\=GA
M$"XG%0A-QB[7)#'F% D:29[:\PY4SZJ=B&A;#4!JN39L#E+,Z564<L132VG@
M9]&HZ)JYOF[SMD)H-LB1EL49)WH9!<$"9&="_<5-2\(H;,BQ"L&K)';#F0JO
MU:[C,-^*&):![;JE(!C='@ZPC16+5R=S#)BV=(++&FPDS*0CDYFNZ*X^/=!"
MWS5^F=W_/(PR=LQPWW&3=;0Q(2LN1:,DH8[[9W,NG9S-1ZRZH3@8X"L)MI(>
M>IJ63) QWX@>:;TF;BA9SZ#!W 'N158+R@RQ4JQ>0X%U[//0OZ0S\4D?KHR9
M7R6&(_+!2"X9/QRN'D2Q%1GGP64EYC!1_I/AS*%+B-"\ZG9%J[]59U9^90X[
M*QL-XJQ1M:PZ8N3>PS_#T\[-.XKJ4(C!V1GO)%! DQ7B@,ZFN%TU4[)NXU@Y
MF\3RL2!KS-,&6* 2\^;:&#;<,+1,JZ1*#]W">';6O:7%H;=[I>85=^)J/WTJ
M.';J<6#Y39C?_@"T[SWWIB&[<PR36CS3"D%; OX7Y ')^9@A,0(<6T1LJ9)<
M\ZEY@$R*LA/)LH@$(56Q-YR[YQ^P\#F2>E+6]]]?)87J^A+_;'G>>)X_NO7F
M!XWI_32P9*\W0ZW;\+D3[,JZ%2\8.+I);R*;N_!2?YJG9*D!B[J_#6A-"A%Q
MJ]V#H%M^T*T\6+_HH+_>H+_48/TJ RODY[R:8$FDFFDHH945OJ:S.Z2=R"I?
MDK;9JR3U91W??OJ_*6UO=5W;R/H*GU.7=TY+K[GS*WCHFDS!IB/O>;"]]1[,
MNFWGNJP_U9Z&*\%=#.A\KY^X3LWWCA<0\;'TFI*FH4F!$>D^QUDQ>*7W/\XJ
MT*<(@#\C0KJ'M.>5V-:U<0Z].RZR3&T:OETQT1$4803OX48!C.C>:IXQ(C!^
MB%,+/'I4N]!A])+TJ)0<1<"YA[@+KK6;F&BJE(AD&ECK0KSO^WO^45!,+OUF
MIS4FL/4>S5[_169*;N[V11-VBH@%FK#(DK>H37918[S]62>:<+6$7F=%JD(O
M.GV&GC7FL@.==/Q22R<D$^X^^$<<:^H@4T4Q.XQTV%Y$A ^YM$CG[)3;($<P
MER, U^C:@ZX]WA1<.-?2JV,^KEG\ AS271.R4,PA$^HZG8HN")-V4)*JD\R\
MJ.V.<HY,,2[R%#WV#, ^L*^-&8Q94Z+0U$+W>1E"0W]9U5VB2WB4%NLG?'WE
MVF(PW0F]=$SXAL=$D+AI#$=)&]F"<E9+1H6Q[$T]M&SXW!1.EX-I+Y2:[!XL
ML-CZWL*86;)J9LM.%RZ7"_?:(]XNE-:"F[9*9\0,"9!N4X@;6"VLL(>T).E,
ML&9QAC_,KTI]C&>]FUJ!U;QO#I._M$""R@T?NEM@'[M52GM3S(8 JJ3XKIDT
M9BPZK1P+EV6$&G-3!L4RF\JL^(D>XZBJ?K9[DG_JQ1#:%0\S?5#IQU!:<]%E
M/ !P<_7GLZ"ZF@?Y6(*13Z ?QKP@QA21(7$]UJ27=D.6XIK'D['T>(VE/Q2[
M6.0B1,=2'\49\&(Z;%"^^]1O8]1G'7R("CY "7MJ^!NT<)T>KE7#%45<5L7?
MK(SWJN,7*^0ZE=R(K>Y3R_L4LX.67P8L^[!R"53^^_S>%RG=;W![_^_U?C^O
MYRD49SAE.-QSNN-#=Q^KQYG6+XW8.XJC+Z2##>[HZ+->7;*DNJC8IA*/^E<U
MPJ90I4>?"9156E1IW>YL/,N^Y*I)E"JNW]'ARD/.8K_-CS*J =K39#:S*2%&
M6RBUR8>^[4O "+"YNC:G>DYS2<[TR'A<PUDNS0A _3NN HN7&G):VP2))P<:
M:&HR.J]@+OAJH7_I6%@3=UFC@<Z=+S*5K(,7?&\SG?*]<R\-[9NVIQHV-^M>
M&5(#/EJSI.2"0=6*\='+3L9FAWO'8OI<PVUZ[WRR=RYI\FZ])GVZDH;>W2(W
MOYEEM9NYQ[S<R2SHA1L $1YA6@+G],[;&L/=P;&I;+@FVY^.<OXHQ*LB)V.&
M>LA/XH:JIG_X8SC<#X>#<.NK+7?+@%;^P.L9Y_!R4GL\?5E$;=+I-;>5",X(
M=QF)NMA;'Q-]ZX,[K!PKCY</K?J7';A'=[3!C^;$B;^[\Z<^3SK@C(4V?&KS
MS-;,:H^\X)2=P-R],F\AYDV?\W"):]/)Y]2\,OR%WMFP]UV%;@6A/9&S7SJR
M=AGFT?)N[K,M763K?DS2G2G26PT^Z=WA<+!W0#IA?QM@#F)-]5K'0F3XU2+*
M95[;'![.2)\P0 23BY$8LJ*./5,:B4GZ27;/3_3S\H6[4"!K1F@K8/:< M+D
M.YJP=PS:,6QX=9!AU/M! AS)]DU4I7SE_[.HHA_H>CD3U@5D<G]75Y=OWU]=
MB4.QO9XI\62)>?%D<#87.UQW/= 4+BR%CC4,ZW?335=OI3U QX#A8(Y^EH4G
MEI0QS !V[1'DZY4O=^A*?J3+*)*J],F67SV*$>&E/FG7--Z]?RT&G,O1;S!^
M;+;H0(.*#K:NKU]9,+<H=%QY_.B<?\]S(J=-S=/K7_.0^Q1G:7[LQR#R%1=\
M,\46=[CX8;"!5_#I?IZQYJ1ZO&U^(;#%IT)-OG3>'=ZW;D77()B1I.40Q1#5
MWC4Y-DKJ( (7LI;D$7BG+9&HM05T]QW<V/6E&1)S9(OTA$FFKE9BX^ 1'[9W
M);Q*1AS[J5HV\MF%%?% /SY2K+6!TP:,4T:)/5%X<??%6@"]'$V6I_&JH>)B
MW1TM:MONKE=$@,9M5\!L[;D+EVC<+5X:E+1Q%E6M+=3HHI?3"@U%Z!Z"<]P4
ML/JZYL*65AM84*_YB>\9/+> ?E;/NGO$KFOH=-QK]+(0XTW[3O,__A=02P,$
M%     @ ZZ#7&H!33=@<&P  F5$   P   !O<VQC,# R,"YA<VW$6UMOVTB6
M?E: _(<:8P%9$UHCV6FW8VTZX_8E22>.O7;ZLML3&"6R)+&'(MDL4I']R$4P
MC6#?!MC]%S-_<<\Y=6$5)3O.3O>L@>Y(8EW.]3N7*I[O[.V^Z71&(Y:E+.T*
M6;*<2R92-L\BP?(B*^MI'; YCR4KLZID\.O\E[E@OWOXX.&#2S&=B[1D1UF:
M"B$/9[R8BJK 1Z/;_]BID))/A611Q4(]A]TZ_.&#EVE99%$5EC%0&8W9<"<8
M#AX^Z$3CSL;7L4@7(JT$^\#.+E_/V6+0'PPW G<,8YMACYWPHF;#)WM[P?#)
MDVU_Q.:W99S$4MRPI)OEM,_6,Y9G0!=?9'&!;"=='D>BIR<&W7_I/GQPRJL%
MB.;P_%N@J^/M>9C-23:+K$K$S1;\(]G/5;=*4:K3@L-3%N(81?:&GC?)4N(S
M%4S"[A7\6XHD$3Z]XSKD\&2XR\9Q*=DS]F\@  F4;/TD L;#F2C-GK!AFE4+
MD=@MLB**4UZ"T .65?["0%M8%<U<P1:BD"B/<1%'M6!1%\AEOVL)^$W-TWD6
MIS( *F#W&V!5L)^(PYR78#QY(N)4D$0^@$S*0EAZYK'\6(B^+U@PO[W!WNYW
MC-8G$0$QN:B4A<)_4A2KADHJ2SB3\1QVM%N(DHU)I@7(")@!ZGP.%$6-9!BZ
MPM'Q-P?M+=@FDL46<5%6(NGMZQT4Z1N2IV#5X">"5=JBE"1#4<)O\WZ_3QY4
M@[!@OR@N&QK_)I8Y3*_%WU$MJ#>?1* Y";,4!8MV4Q&9L%CYGR#P *1*"B#!
MAP*%);.XM*M_'Z=1]EZRS3%,^W,/=SB[_,-VW]_CLALG3';Y-"9/QQ$!JI%X
MR'D1H1!'"@YP:^+4FB[_2Y8&#&0]Y\D4G(T>^QO,N5;$(DNRM*QI=?AZ?OSM
M#Z38>EF',*M0*H]0GF;]$! #! !" WN4+<I?)BS5=!:@.X&^]@&4EP@P8 :F
MD&33.(S!#8Q"-QJ35[8#(OF@.55>4/A;@%D99T#!P X\C1@Z)XBZ*.."LTU@
M7L;-;[V^9Q_*M!7Z'1T FBCK_BX#RH!&R13V  &9E/$8?R&#1EGL^\1LG2[A
MC]%?).9 ";#)*Q#],IY7<T9/7V6HI8N#4^L7_W'VUJ7(+#9O%D,O STH7$;X
M$R'A@+%9([:Z%&D$MA:GD[J(P:@0@7&9%IUOFZ5+'J-@0 %96(*D /Y+/L]!
MG@ +SM)1+-&*T9#TIGHSN_1(K7VX7/:OKZ]Q;>UNI.I)',YB0<X!]C*)IU7!
M"=,WS$P];Q,$E@#MRM9?]P]/GO=:Y)\OEW^ZOO[3S0UC,J_#>!*K/<#GYC%$
MHRX/PX]:3<[6AA74W-8K4?0AT+9"3DCAEH*JFMT%]RUY6OHAYIS+ \"ZFR-Q
M*C1JC!F$M%.>S%#JE52H2FN@]09L!<Q23[9@7$K'0#RN#-RWG%1+G9:<</P(
M9!:I\LH^.P<4WOH%][AF?*O< LR  )TSWZE4C)/^TD4MP>Q3B%FB_$-&@H=$
M@ (>[D,IP='999]=U N*Q];<(,@CXB:*6W0-+>O6#H=G;TY>/N]?_OLE&M#!
MMV_/CG\X/NQ_?? 6U+TP>)P+0%HP6"\<;U@BPR)>@";\E7E59G,P)+!-HB%T
M:,"]"I'P]"^<J&/R6I8?8<U-8'+#!IE*:F?%49A3M"1/PNY!/#\DXYCP,$[0
MKXJ:*^O6[N@0C9PAZ&YXD6P1HY_YB\-\'1C!BFO19\>I,K^02XP?8TBERK^6
M_7;R=-X'?>P[V15+:^!=8O "!P(Z  ;!&0AW]@8:=39:QK2(%\JB6AS;?*< 
M9RT* <B TO73@1%XP9'XX?12 28[PK@@&SSFH;*-0%&IP0 !KX4@#03 8GUV
MF5V#C<G_=HQ(/8W &<,$08U"D!*J<6['Q$ 5KOTVR[]X>7I\BD,"=GQZ"MY/
MGUN[@&W4/U=@:@G:T^8LCC+9!\N!V &6<G0!GL!V>Z0H7B(#8#84,>TV.ES%
MF)AQB+FB:.\!0%5H@>B<#YP29)=4)5?!!B"AC--I50OI2_V-0$\'T9]5BP*3
MX#%#Y/D&(G:7%P4I%&#D T1.>N[@GXM[30"'B"]2[2!I=LU;R2?EEO,^^PX"
M"N#LC<EES**@4< 9R&654A+78W-1E H=N]G_J"@.WAB*FU8,%V[Z;6H/V';K
ML \XL2ZY/U&[=S3WKQMZB 6G; (] KCY,CP&DZX*51D1:FCT%C+BH C2AL3P
M"1]!QRIY7F28,<8 > B) "T.@$..B AT@SN.,):JE+8E26)SG'Q$79<BG-$<
MV (3(9Y.(?_0.767JWRZ8K^X(9A$4_>=Q-[?8 JY(!&*DR#KG6Y-BBR. L 2
MRC.B&#T971.57OPU<1DH .9*C>.(2&5%EMA?)_US#KH2I0Y[SS-VC5$C UL0
M['U<SO![@:DIC@*=9!,F9Y!EMRJ432B7P$,H_U#Y89XEL1]I[RQ;&1'RL2SN
M6[9"W7J0Q-.4/=;KLA.3EE3:<E #X&79_ U^79,O['X9##HC2)2G%>Y59B4@
MQ5. 6,J?Y,,';XDC:Z%1YYDS/"( !-&4,<:0A+RC,M9K)NN]:6J3H&'(@7BQ
M4#66V>X6/E;R+,O8(?UL.,/\:B/X<AN8NI,KM<VI1FY%2"W<'/;A@ZNKTSB%
MC.CJBCV%.A@6U!6#RH4I986!"(N5KHR@6GZ5]1\^2/A8)!W%/0SI1.\A58+Y
M$/4Y!@W4L*B6#(N=&K&RHF1 2,S=B:93#'9 -(O>LX80^_A(T4"/MX:P,NB 
M1?4$$@BH4 O \<+43DZ$HLPLQ:S?FN(M,H"@H_-FC']KHEQ?R^<MC5(B&FP_
M!DJTAN>6@>X]%^-+9['!R<G)8.8LAT4'+5>I[I!:L7^71['O>!%SJG'NYT_H
M42] KHZ]OT>C3:MY760V$V\L7%DGTN [XNT^?IR6OY2B,>S1)_X>/GB)R2P$
MJY!B*QGZ&^O;.EM:UWP:&/>[@CT!N#I/.]M?[-H?#8?BYZJS"?;)E/!-@^W1
M%X-9KS-R/%//4\Y\ZZS'>M:K#.H*\(D2=R^$4#/8ZHQ=VH=MHEZ=)D@/6W_%
M(@[%Z^'5Z[/;I].&8/]0"@N$":EFN=-?O+Q]^B[M;M31S-J^<].]6<\=>M<&
M!^[0G3M7/?2'WK7J,0Z%T)]&EYTUK5'=->W<LUTZ8H<H^OLZ"9GEPP?8PN@<
M)$D60J+;206';:!,GF<+QF?!'N*E12+EQ#^<THB0)PG[$29=71+^OS/S;I9,
MA,N +W$NP 1 /CPN8R]"P% Y2V@@QEY<;Y[35Q$M.PQFRG@%-=(,"QJ .'"%
M + NJA!^Q#*>"LC@U*I_C"=L3)_TDAR6'"_5@E3,@G4F/*3H91!L!H@K CWK
MIS&0!H;(2"HPD7DQSLP98TW<UW-07$!X  PH*D!B\80^\BBB1P"L.R@13QQ0
M H&$-)\J)-5"38-:"6:E68F0O$._Y96<X5I:?(5>UU78$]P"-)-50.WQZ=<M
M54E'52@=$,[0BBV]T=PDD>"X>3LG-0*"B6@H["""A+3-+Q+RHXS?!1$9 #" 
M".MAKTOPX'"&PQ;PN$(I_/]2_6B;Z#9D<S![B4V0V;7$Q!B=:PQ&X4UY_"X8
M*Y7D&=E;IPEX[OA" "FP8]ZXVVB4_=EWPH[O@N00>G7Z/B8'@>_H[XTIJ>W(
MN,&D*$!CJ@OU2S[3CD%V"-,')[/&_>#[8_I68FVB'F/,AK^9YX/&-ME7;,A.
MLZ#I)4I1Z5X+/EA5"Y(-ZVX-USI&V"(H- 09;:ZTM1QRPUO)M7G+5VN=ZZ?T
MQK$%=$JJS:B9N-RZE>4L#9D@ZW(M^/&>HA_")-L>SAI/U7I#:80.(H'U JPB
MN2 Y[*DP< J1EYCC[%MX@42TFDR@%@>LNZ>!>TPY&X+TPR7M>(V8HSMQJJ7G
MG=4]:VVT7O:$D"L;M83AB^/3M(?W\$UP-*Y$&B:%<C3@J:C#*J\+4;A(ZK@=
M.B5?-A;&C86U_-%WQ@M!H&-:J=HI1P14V'/ 8P,0XC7CS/1&5UI(3:).AQU 
MGHDC?;66C%,\"+'1!:NP=F@B'T]5YPM84P&'G'\F"NK9K&E> ;8T3@1>0@PR
M" S8 LJ*.&"JLRM5\[LUO3%N$-6.<BW;P%7%(G;8GC56KSV8K#L)]@8S:_@W
MG1&.U5%;:UO%,>GF%DG78"WHCL2AG<RA9#CP;.MDY@Q0B<A5-I$6C;T'4DS?
M!1H)-5!+WW(I./.PC%$3TR0;<]-"AII L(/M@7&IM8E/2]B$[C804S?6T9/1
MCV/D-%O&@:I<WJ@\ULDL?G2J\'?-$QL/M%1U_D$TADU4TA_]3:@^9C9GPTU:
MA>F[QFV\3 .'CYOAILQUAH_M\'N017JR=3;H2?MKXZ&^._JNJL!$55,V>")"
M:(!([!'%T=GEU<7W=DODP"L4&[F&]I$2.*P38?LVI;[%ONU+-F@4.4$ZBHVZ
M5A86('V_H!MEDXG$0R[=JC1%Z>9;$X; .53!V7.R0-D(U&'+,6P*PB;ND"37
M&-QMB-Q.EJ!$.7<%;35PCAIXF<:EM5C$)MYC^%O,37?]^=%;ISQC&L)B9PSV
M3U2](YNZNJA%8KP.A3S&W(JG:85Y(GQCF[(J*(0U#2S*Y7M^\A%*L@205DA3
M8?28&ZR9.G$(;=?F1&XUH_6I*KAW[EJ2@X7-8QNE35IC*FV!1R#8\]<9$"/D
MUQ=BJ",6"8=:L \ ,138A:#CX4?L4I7K^-V'Q,'@R0EES[PLBWA<E7*?#7?Q
MID= RP;L\.(@8$?GKY\:\%+&8Q%2?0W-5S*G2U$>"1D6N85K-*IF2I8[,WQ>
M="?L4^SH6O=VKG;NYNK[%E-KR5XQ,$LH[0M0<GSI5F_A.HQM4/;',W+3E6>\
MA13&D$0Y,6F'CH3ZLZ[<$""WS>/&*S]E!&VR,3"B%?PVZKU=AJX*VS1]4N?K
MF=B9?6I3E7N8L+6B-XP=Z[76>M+HS'F0BBE3M5N>R5A?K0HG3$)5P9?_^M7 
MT65H=6EL]I!<<<2>/QWZ>L8&QW93$$)FAYDI56J/7V76 !(I5M9\;-<<>&N.
M]9(F8S)ME<^RID:*:ZP"51#U&BW8 T"L+#W__O%Y=B%X<@5I5RC-U+ -_]A@
M5^GBB/7[?1U/G+"A \GQ4H3J*$!'\A&[J&65E+S<IYM6(1W';^9))4&B!= H
MNUD(!0 FLMBBONU*!YURJF-#HE*1H0,C4F/3"3S#;&43.J2MGEZF7IH&.MLY
MVAX0=N'I8X''<JB=1(3TD4IE+_B:,YV5 M*U,CO8/V953R%\G^4B?;5O*JE/
MMSG\G$?75,CCN,=>QY2,"]W@%FS[BUVW::<#*F^R'4R=-?[HS,G+;SQV_0;H
M"M-WIR2AY=70JVNQPA*\DA]IM43--R$-\289CKW6O$-(O(Y>0Z-_Z.NRGXAT
M6L[8FF4+D=\P"16_:E!BP=YFR=9#0G5PS$DB)8<NE\0+M]AWM9)IMC)0FU2W
M)[8J"B\&>I-PCGL8X,QYGH'[EF#E5]F[H#7%/0!PIKS/&D!Z='EUCIU_/93V
M?CV\8Z47+S]KI4>[MZZU_9E4;=^QTN=1M7T'53N?2=7.'2M]'E4[#56$"-=T
M@YNYM9@#D,R4 =[!!#NGH_9;+)D"@JJI(W5#E<YA5PXF*""<XR)'(L3RLK,:
M$NBQNKD\'^/1:$TCZ5 WG/'_TGO [F'Y$7;OX_07<5WP KUBG^[/;"'LUQ'=
MX8$Z/^7)M11TBH^CF^/\?8PA6W1M$^]QF"2AIOO7=%]$S!&,8.7)!'ME.#I<
M L)%U#NFFE&1Z=*D?9L;@H6ZY5@+(O9"X(VZ9FN\++IF;[N<.81N=NO?FQ"\
M[T#WS7R">%Y@RW[4P7OCL3[U=%:&TI<N;\3"W18[3=+L/7DZI#Q*-4_99JJO
MM*>AT+>TZ;!:2ZYG%@9#IMXEMC@"&>\C!_4$LA*I1".A/J#+(T8W60K\YW1O
M,9H\';!->PV857F@&9)0(D(U0?? 9$]-5-=]L%)#^O N$NG8=*U&4#.4U@(<
M7<$@=66J%KK)DT5R'$3P*5SVW>X )@5-5ELX@OJ OJ6N3;HAUDQ1.L,DU-Q/
M0$E9?4_P6F@12QU,0]-U_BE<WK \&JI%D$CM;Z"HU/:D*C(XM#:VB*D.S:.!
M2B6($Z]%M\;,%(>J[==]TJ6N-EUQ1H+Q=KF]\]2H5Y$'];HYR*K&-'W054_&
M]@F*;NR*H=!O1NB5&&=U63?LZW(=S ;0 @^$EW2AX??1\A%7168"P9L:7?"_
M1_#?[Q^_:_W.U>_;ZG>E2&(+;[+]@H="$AN_J;T>E-!=3<>/;&P'45JMR)AD
MN]RWR^I?ANH7D]?C5MI+\+S20(I9O(%BRJ ]>%18K/)H61[+G(=B#6;"E$46
M-Z5-HJP84(=F?!HACVJZ?7::^=IGW4?#%GD-&0YM1\),7Y/C1VIM)&>>F8+/
MX)"^N_DK@7B.J8PP !K5X\K?K_\; 'C4WA:IGO%8<;N)H5)I 6]V IK6V%E*
M:X-2T3UHJ=12W 0!NX-:N+>6?X[^K/)]R\?_.6PX2^$:GC2UM1D<9YL@++SD
M1Q<.(U&DGK6SI-+T0I$!WC'.E5C H68\G=:_>ABP!HO^'>%K,?,L4B4&KT(P
MRD),8]A.!.;L!J  KVM!+<[S$@$<&*97>*P]]O^!\('#85?WIIZ>FE98R!O5
M./D.PGB?O6Z.4WP]T)X\R0I)2@"2T<",>O"(*@.*\#4.]"[1W)"F_FR%_^#;
M!X5ZR4XR>LE)E.J%*SQ$Q(7HAJAES+Q'L[.M7D(C,S>"I)<+-*D0%E&[1!TN
MXX]3AU.RI_-1C UT4M^<:>&Y+]@^<JB#F0Z#ZCK'T:GJ@A^=NA%.+88M$*O\
MU0(\RW*[B.G%8*'M+[Q2:4,%*>/."%G#?D!JWP]LCKHT[I#7VM 0Q39N((OK
M'=USU3:GV\3G\!Y\0EGM3C*[ZHD.WT-:<GN?_@&&]UM@W^ ZO29JX-Z%XC6 
MS]5C>E7!@#2]"V'>K^Q1>-\4/7TYDC;9HN  >$-FLJ:<N$>,H-A)9,G[A8B5
M8&S ]@,K"[RH7%C(7),.WP+3]LYI;UVVKPF@#'P]0M+.=?_^.^,=*C5)VB,G
MLCT?I.C%"76RHM^'"U@+V.A,K>#VQ5?9M/^A5BC5"S 2P7>>EWB1W!8.%J4-
MND1M6,$,?/,;A&VR&1/_>.J_:PK);X5@;!M!E!X*_7J<SCYYGHNDIDWU8P(R
M-LEB&2CL*N; FA+5%  PI_R\><L.Q%[$*.V*^HAT;T.2R9'R1OH"AYXUAD01
M;],70"T2RNWK><Z:6F.>=S18Z\&"OM>OU$JOW*% D5B"]4:UYM4G:0R&LPF^
M>N9>[]:% "VL:9#J(L-80(@#WO'%B/;;A8$O(PW,2E*X"% (["ZXNL!EWCVB
M&RV\HMN]/@SIE'&K:W-E:EF^.:.-,0>&Z71H0MD!?I,898&^ G(%>HF,/C?7
M(8"KOUD$^;O.:8TE6!PW%)C,OCEQT"83T<O;*S=AW'<Q3=M<,_&L:P+"+==O
M<-"+^PR:W3$(27S;OD3=.@XQZYR:=?QC)P)_MV*P3VP,<-^EL$_Q0!-$L-/I
MJ+N%:/@%@6)S@.'=5]SQ3C)6[A0$T=(.*-:>6KC,V@OHMS [_W69Q66!#?>R
MOIDW_B<(R=ZD^"PAV?=C6[)Y^]O)QESROZ=XFJG-^P'-5'[75*<IK4_?[R>;
MDUM/@CP9':Z7$653M[(2+H,OG]R3?G.68-]R<6C/D3L+29K7\37#Z[.#7X_'
M\W\BC\UQUC_((IU!VGQ'[@/NT<X.IKNT[.LIAW[3R1FMHXO.B?UC'/OVF I(
MZVZ_N*':O_[B9))W9+AK^N#MK'5M'AI)"F;.,?CYY3G;C.3^<'M//?*+/5T4
MT'W54M51-G=5[],W22*WM>5J_OGF\. "P^Z$B7&^4L0BU45NZI F*:2,BVY$
M3NL4\N\DL.4AE84@[/I_"[F6WK2!('SF+_3D6[!$46D>%5A56[GJ*:@]I+U&
MIC:*$0G(!B6](J'^[<Y[9UT'R 5OS'IW/#,[._M]PV=ZV0"THZDE-D+^%0DF
M,,+'\(+K-H1#C*&TD 9[",^EQ  Q[Q6W![/\NP^,>XUC=5M],O2D$(;2B2F-
MOZV8:_M6ML<4XQ9["(\DNJ%SCZ\XS)D[^VXZ;UW"E2'J)DH-2YT(%=*Q3%E_
MD95ZT(#68M6X/^Z.IEX>5L>08#Z \&Y1$S '<DR*U89J91C&#./FA'C>R,$\
M[)B#R=V5B+L*--F]Y^KFX_S[7,K1N)NPU(OGKDFYA+[^.(LW3DUH>9\:S>3?
M<<K<$B?EA22M96O65&O8;!2:P.LQ+'1JZ])VYFT] NL99)KVZSELK=#.7%H9
M<2;@M.*,+HT1$WXON*=JZ"5B0@;#=D[!E8Q@V>PE?#ZJ0^"$P?-#O;:(DL!\
M591=%221K'B?RTT UGM@I5SQF!([BK:%4N9<UOY1<9:4>\$-?^TNE,_R#"[.
M7MFW^FGF#M\+K=ZS )/:'4B<LH4P@1<]:-$DFW^$8'8X'SVF85_P&@K5$WM.
M>N\S& B<P!=0R0JWK9T<AO?DDL0X2?4-6^$&5*+>8J!ZAG%55LM[5//[.S#R
M_,=//F'1?J31EA;F)QBJE8 H2[1'TJI'WI6@.?"1 6DNK QE!,^8BLX&H 4*
M""8,9JN+&_,@/*P6O1CY-GCF)+53(,SF83HYE*[@6XJT<[SE<W>*[&3YVWD4
M](7^1%JI6%"$X0\,?$W'4M&Q%Q 6/.)ZRI$U_'1X U'V2%(I\-6<OC!6'2=.
M[YKH7;B:X@H% TIY*HM4A4RGDJO-NC91'V&U1?[OTS@*(WSEL1.BY_[?IUJY
MH"'*R?H">6U2L:JG6I5,$B2L"=O*#@_DQ-)S@M6\39<TZKK[LZV@(; HT-P>
M1I=] 9'^,)#AU)180($&(>/OEH3SU:^H)W102_; X%@&BBQ9[/#K:/)AD"&I
MAV>V@%?]:QZ/2PM]\;!^ZX!8I)<I;VC^PQL$<43Y/O[559KD4KXH!G3C_0'F
M$-IB&'IH=\CHT!BAHB7U:O@V=BS)=9K(&PT1  4OB!JK%Q _&>R1F"%FO>""
M/3Y*$6RONBK>.I'Z[EM)QN5G:*+*AYX0W]@CH6;R)*RU</5N>@.];9/AIS3)
MQ.#(LB@#MH2%OV5&6I>E$K >I\L WM;MC@,UC;[.$%LQ6&7WE27=/"]\_!)+
M#=WC0OK$&V1H-'N"[UXYX+*K%]RK\$#\)7V/M 6NG:+ E=<1N#0U)Y:PIP+C
MWYM_4$L! A,#%     @ 9%X8&8):\J]C#   WB,   D          0   *2!
M     &UA8W)O+FEN8U!+ 0(3 Q0    ( $8JT!JP=/2A3B    =3   *    
M      $   "D@8H,  !M96TS.#8N9&]C4$L! A,#%     @ O8HC&43Z;MI*
M(   ^U(   H          0   *2! "T  &UE;3,X-BYI;F-02P$"$P,4    
M" !\FGL8*-CN(_D'  !H%   #          !    I(%R30  ;W-L,# P,# N
M87-M4$L! A,#%     @ 0"O0&G)#'@['!@  BPX   P          0   *2!
ME54  &]S;&,P,# P+F%S;5!+ 0(3 Q0    ( *^@UQI)6N#DW1$  .LW   ,
M          $   "D@89<  !O<VQC,# Q,"YA<VU02P$"$P,4    " #KH-<:
M@%--V!P;  "940  #          !    I(&-;@  ;W-L8S P,C N87-M4$L%
3!@     '  < CP$  -.)       !
 
end

#--- end 386/BOOT/oslc.uue ---


From oin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Sun Jun 27 20:29:48 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA14306; Sun, 27 Jun 93 20:29:47 +0200
Return-Path: <oin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Sun, 27 Jun 93 20:29:47 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22376; Sun, 27 Jun 93 11:27:24 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa01908;
          27 Jun 93 14:24 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa27715;
          27 Jun 93 18:24 GMT
Received: from sol.cis.udel.edu by oin.cis.udel.edu id aa20474;
          27 Jun 93 18:24 GMT
To: All the happy Moosers ! <moose-programmers@sfu.ca>
Subject: Re: Various subjects [far36] 
Date: Sun, 27 Jun 93 14:23:52 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9306271824.aa20474@oin.cis.udel.edu>
Status: OR

In Message <9306242044.AA18630@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=>(A-)Synchronousness
=>-------------------

   I don't know anything about Occam, but I would go for including
both as well, though the interface should allow for the case where
one is emulated in terms of the other.

=>Linking objects
=>---------------
=> Info objects must contain:
=>
=>Code:
=>- what are the implicit or explicit parameters; what is read,
=>and what is changed.
=>- How it changes data.
=>- What other code is called; what other code calls me.
=>
   I'm not sure I take your meaning. Parameters can be expressed
explicitly enough, but not the semantics of the code. Are you wanting
to attach human-readable notes on the semantics to objects?

=>Data:
=>- who can read and who can write.

   So what is a "who"?

=>- What other data is pointed at; what other data points at me.
=>
   The former is no problem, but if I understand you correctly, the
latter is essentially the GC problem discussed later.

=>Garbage Collecting
=>------------------

   Right, no GC among system objects. GC within system objects
optional.

=>Demand paging & scheduling
=>--------------------------
=>
   Do you want automatic (profiled?) or programmer-defined preloading?

=>MUSIC
=>-----
=>
   No mention of X? As I'm not much of a UI person, I'l not comment
further.

=>Let's begin Coding
=>------------------
=>
=>* There seems nobody has anything fundamental to add about specs.

   What specs?

=>* languages used. For device programming, let's use ANSI C and
=>Assembly (I vote for TASM, but perhaps you'll prefer GAS).
=>TASM has got good macros et al. and uses standard Intel pseudo-code.
=>GAS seems to have good macros, but uses non-standard pseudo-code for
=>intel instructions.

   GAS is free and portable; I doubt that TASM is either.

=>The language team (including myself) will build a C to HLL compiler, and
=>an assembler into HLL embedder.
=>C code will have to include HLL directives inside comments.
=>
   Why comments? Why not pragmas or something?  Perhaps adopt the C++
'extern "C" {}' construct.  I'm reminded of C64 BASIC programs that had
assembly imbedded as a rem statement on the first line.

=>Please comment. Problem:
=>what kind of pointers to use in MOOSE implementation: near pointers, far
=>pointers or system only pointers ?
=>
   For portability reasons, inter-object pointers should be special
system pointers, interpreted by the destination objects themselves.

=>* For IO (Especially disk I/O and SuperVGA programming), we can get
=>docs from Linux and/or XFree drivers code, and other PD code.
=>
   They are at least a good source for example code. 386BSD too.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From ANDREASA@dhhalden.no Mon Jul  5 11:30:25 1993
Received: from nef by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA22985; Mon, 5 Jul 93 11:30:24 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Mon, 5 Jul 93 11:30:24 +0200
Received: from fenris.dhhalden.no by nef (5.65c8/ULM-1.0)
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <24336-0@fenris.dhhalden.no>; Mon, 5 Jul 1993 11:29:53 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Mon, 5 Jul 93 11:29:39 GMT+1
To: rideau@clipper (Francois-Rene Rideau)
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 5 Jul 93 11:29:19 +0100
Subject: Re: Booting the compiler
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <77818F252F@sofus.dhhalden.no>
Status: OR

> So I'll need 386 Protected Mode & Hardware support for next
> bootstrapping step. I've written some stupid GetMem&Go_PM
> code in assembly. Sorry comments are in french. I'll
> translate in some future version. Can anyone send a more
> complete routine ? Has anyone programmed hardware managing
> stuff for the 386 (i.e. Descriptor tables initializers,
> 8259 and other chips initializers, interrupt drivers) ?

Ask Dennis, he has got some code lying around for tasm 1.0. At least he has
tryed doing some GDT's and IDT's, and also (I think) some chip initialization.

I'm very happy to see that this group isn't dead, and that my supervisor
hasn't deleted my account yet. As I think I have mentioned before, you can
reach me at andreasa@fenris.dhhalden.no. You won't here much from me, but
I think I could threw in some comments.

I agree with Gary; we shouldn't start coding yet -  not final version anyway.
It is good making test-programs to try things out. I also agree that we
could start making the template of this thing. Going into a more specific
design part, but first of all, everybody should send mails to Dennis and
ask for the draft. He is said to be almost finished with it now; he only
lacks class definitions:-). As I have understood it, he has done *alot* on the
starting doc. already. There "only" remains ratification for it, which could
take a while:-).

You can also reach Dennis per phone; +1-408-356-7588, and don't forget there
might be a time difference:-)

Have a nice summer.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


From thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed Jul  7 13:28:14 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA16367; Wed, 7 Jul 93 13:28:12 +0200
Return-Path: <thorin.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 7 Jul 93 13:28:12 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA09379; Wed, 7 Jul 93 04:25:08 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa15593; 7 Jul 93 7:21 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa20126; 7 Jul 93 11:20 GMT
Received: from sol.cis.udel.edu by thorin.cis.udel.edu id aa07186;
          7 Jul 93 11:16 GMT
To: moose-programmers@sfu.ca
Subject: Dennis Gone?
Date: Wed, 07 Jul 93 07:16:35 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9307071116.aa07186@thorin.cis.udel.edu>
Status: OR


   I may be missing something, but it looks like Dennis' machine,
td2cad.intel.com, is gone. This might explain why we haven't heard
from him in a while. Anyone know better?

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Fri Jul 16 19:46:46 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA21083; Fri, 16 Jul 93 19:46:45 +0200
Return-Path: <dori.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Fri, 16 Jul 93 19:46:45 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA12421; Fri, 16 Jul 93 10:42:06 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa00994;
          16 Jul 93 13:33 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa15579;
          16 Jul 93 17:31 GMT
Received: from sol.cis.udel.edu by dori.cis.udel.edu id aa21046;
          16 Jul 93 17:27 GMT
To: moose-programmers@sfu.ca
Subject: Hardware Platforms
Date: Fri, 16 Jul 93 13:27:04 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9307161727.aa21046@dori.cis.udel.edu>
Status: OR


   Ok folks, I said at the beginning that the perfect operating system
should run on the perfect machine. Therefore, I say we make the DEC
Alpha one of the initial platforms. :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts


p.s. If this doesn't wake up our friend from Intel, nothing will. :-)

                                      GD,TL,TR,HPotCA




From bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed Jul 21 00:21:56 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA12931; Wed, 21 Jul 93 00:21:55 +0200
Return-Path: <bifur.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 21 Jul 93 00:21:55 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA22117; Tue, 20 Jul 93 15:14:42 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa13625;
          20 Jul 93 18:11 EDT
Received: from louie.udel.edu by sol.cis.udel.edu id aa02926;
          20 Jul 93 22:10 GMT
Received: from sol.cis.udel.edu by bifur.cis.udel.edu id aa10823;
          20 Jul 93 22:09 GMT
To: moose-programmers@sfu.ca
Subject: Dennis Lives
Date: Tue, 20 Jul 93 18:08:52 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9307202209.aa10823@bifur.cis.udel.edu>
Status: OR


   I had a chat with Dennis over the phone Sunday, and he is actually
alive. There have been some mail interruptions at Intel lately, but
mostly he has just been too busy to do much work on Moose. He has
part of the specs done, but they aren't quite ready to post.
   On another note, what is the group's opinion of Ada? Rumor has
it that GNU Ada is around the corner, so it might be another option
for implementation language. Also, I may end up getting an Alpha,
so that would be another initial Moose implementation platform. The
PALcode support in Alpha should give us a good bit of flexibility in
OS primitives.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From uunet.UU.NET!davgar!davgar.arlington.va.us!david Wed Jul 21 05:16:46 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA20432; Wed, 21 Jul 93 05:16:45 +0200
Return-Path: <uunet.UU.NET!davgar!davgar.arlington.va.us!david>
Received-Date: Wed, 21 Jul 93 05:16:45 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from relay1.UU.NET by whistler.sfu.ca (5.65/SFU-2.0)
	id AA08370; Tue, 20 Jul 93 20:07:16 -0700
Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA21969; Tue, 20 Jul 93 23:07:06 -0400
Received: from davgar.UUCP by spool.uu.net with UUCP/RMAIL
	(queueing-rmail) id 230505.2690; Tue, 20 Jul 1993 23:05:05 EDT
Received:  by davgar.arlington.va.us (UUPC/extended 1.11xDAVGAR7);
           Tue, 20 Jul 1993 22:53:09 EDT
Date:      Tue, 20 Jul 1993 22:53:05 EDT
From: "David Garfield" <david@davgar.arlington.va.us>
Message-Id: <2c4caf97.davgar@davgar.arlington.va.us>
Organization: Third Star on the Left
To: "Moose Project" <moose-programmers@sfu.ca>
Subject:   Re: Hardware Platforms
Status: OR

On Fri, 16 Jul 93, Gary D. Duzan wrote:

>    Ok folks, I said at the beginning that the perfect operating system
> should run on the perfect machine. Therefore, I say we make the DEC
> Alpha one of the initial platforms. :-)

Well, I don't think Moose will be "perfect", and from what I know of
the Alpha it isn't "perfect" either...

On Tue, 20 Jul 93 Gary D. Duzan wrote:

>    On another note, what is the group's opinion of Ada? Rumor has
> it that GNU Ada is around the corner, so it might be another option
> for implementation language.

Ada?!?  A language designed by government committee that couldn't even
fulfill it's design goal?  Lets not use it, even if GNU Ada does
exist.

>                              Also, I may end up getting an Alpha,
> so that would be another initial Moose implementation platform. The
> PALcode support in Alpha should give us a good bit of flexibility in
> OS primitives.

I too have been thinking of upgrading to an Alpha, and wouldn't mind
seeing it as an initial Moose platform.  Gary, do you have
information, likes, dislikes, or information sources (email addresses,
snail mail addresses, or phone numbers for inquiries) about the Alpha
(or other modern RISC architectures) you would like to share?

>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts

--David
--
David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com


From gumby.cis.udel.edu!cis.udel.edu,!udel.edu!duzan Wed Jul 21 13:47:38 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA07483; Wed, 21 Jul 93 13:47:37 +0200
Return-Path: <gumby.cis.udel.edu!cis.udel.edu,!udel.edu!duzan>
Received-Date: Wed, 21 Jul 93 13:47:37 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from louie.udel.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA21537; Wed, 21 Jul 93 04:41:53 -0700
Received: from sol.cis.udel.edu by louie.udel.edu id aa20588; 21 Jul 93 7:38 EDT
Received: from gumby.cis.udel.edu by sol.cis.udel.edu id aa10048;
          21 Jul 93 11:33 GMT
Received: from sol.cis.udel.edu by gumby.cis.udel.edu id aa19957;
          21 Jul 93 11:32 GMT
To: David Garfield <david@davgar.arlington.va.us>
Cc: Moose Project <moose-programmers@sfu.ca>
Subject: Re: Hardware Platforms 
Date: Wed, 21 Jul 93 07:32:12 -0400
From: "Gary D. Duzan" <duzan@udel.edu>
Message-Id:  <9307211132.aa19957@gumby.cis.udel.edu>
Status: OR

In Message <2c4caf97.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>On Fri, 16 Jul 93, Gary D. Duzan wrote:
=>
=>>    On another note, what is the group's opinion of Ada? Rumor has
=>> it that GNU Ada is around the corner, so it might be another option
=>> for implementation language.
=>
=>Ada?!?  A language designed by government committee that couldn't even
=>fulfill it's design goal?  Lets not use it, even if GNU Ada does
=>exist.
=>
   True, this is the natural reaction to anything handed down from the
government. However, though I haven't looked at it in a while, the
language has a number of nice features that make it a possibility.
Ever looked at military specs for electronic equipment? Ada is designed
to build software to similarly high standards of reliability.  Most of
the negative things I have heard about it are related to the complexity
of compiler construction, but if we get a compiler from GNU, then that
isn't an issue. I'd rather look at the language from its merits. I'll
be looking over my Ada programming manual again to formulate my own
opinion.

=>I too have been thinking of upgrading to an Alpha, and wouldn't mind
=>seeing it as an initial Moose platform.  Gary, do you have
=>information, likes, dislikes, or information sources (email addresses,
=>snail mail addresses, or phone numbers for inquiries) about the Alpha
=>(or other modern RISC architectures) you would like to share?
=>
   I have DEC Systems & Hardware catalogs, as well as the Alpha
Architecture Reference Manual. What do you want to know? A reasonably
configured low-end standalone Alpha 3000/300L (100Mhz (85.0 SPECmark),
32MB RAM, 425MB Hard Drive, 2.8MB Floppy, CD-ROM Drive, 17" Grey Scale
Monitor, 1024x768 8 plane graphics, OSF/1 Unix) is about $7716. A new,
low cost version of the Alpha is due out by the end of the year with an
EISA architecture and Windows NT. (And it might even have a little left
over RAM and disk, too.) OSF/1 is also in the works for the DECpc AXP.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts




From danodom@matt.ksu.ksu.edu Wed Jul 21 18:01:55 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA13777; Wed, 21 Jul 93 18:01:54 +0200
Return-Path: <danodom@matt.ksu.ksu.edu>
Received-Date: Wed, 21 Jul 93 18:01:54 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from matt.ksu.ksu.edu by whistler.sfu.ca (5.65/SFU-2.0)
	id AA00618; Wed, 21 Jul 93 08:56:42 -0700
Received: by matt.ksu.ksu.edu (4.1/1.34)
	id AA07509; Wed, 21 Jul 93 10:56:37 CDT
From: danodom@matt.ksu.ksu.edu (Dan Odom)
Message-Id: <9307211556.AA07509@matt.ksu.ksu.edu>
Subject: Re: Dennis Lives
To: duzan@udel.edu (Gary D. Duzan)
Date: Wed, 21 Jul 1993 10:56:37 -0500 (CDT)
Cc: moose-programmers@sfu.ca (Moose List)
In-Reply-To:  <9307202209.aa10823@bifur.cis.udel.edu> from "Gary D. Duzan" at Jul 20, 93 06:08:52 pm
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 608       
Status: OR

Gary D. Duzan Said:

>    On another note, what is the group's opinion of Ada? Rumor has
> it that GNU Ada is around the corner, so it might be another option
> for implementation language.

Ada?!?!?!?!?!?!?!?  ARRRRRRRRRRRRGH!  Remember that evil, vile Pascal
language that we all have/had to use in school?  Ada was based on it.

Ada was a language designed by a comittee, and it shows.  It is huge
and bloated.  I would most definitely prefer to avoid it.

-- 
Dan Odom
danodom@matt.ksu.ksu.edu -- Kansas State University, Manhattan, KS

Support the League for Programming Freedom.  Mail lpf@uunet.uu.net

From ANDREASA@dhhalden.no Sat Jun 19 15:47:06 1993
Received: from nef.ens.fr by clipper.ens.fr (4.1/88/01/19 3.0)
 	id AA01759; Sat, 19 Jun 93 15:47:05 +0200
Return-Path: <ANDREASA@dhhalden.no>
Received-Date: Sat, 19 Jun 93 15:47:05 +0200
Received: from whistler.sfu.ca by nef.ens.fr (5.65c8/ULM-1.0)
Received: from fenris.dhhalden.no by whistler.sfu.ca (5.65/SFU-2.0)
	id AA19730; Sat, 19 Jun 93 06:41:52 -0700
Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) 
          id <28554-0@fenris.dhhalden.no>; Sat, 19 Jun 1993 15:41:29 +0200
Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.0);
          Sat, 19 Jun 93 15:41:18 GMT+1
To: moose-programmers@sfu.ca
From: Andreas Arff <ANDREASA@dhhalden.no>
Organization: Ostfold College
Date: 19 Jun 93 15:40:50 +0100
Subject: Have a nice summer...
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Message-Id: <438C05670D@sofus.dhhalden.no>
Status: OR

Hello everybody, have a nice summer (except Michael). From now on you can all
reach me at andreasa@fenris.dhhalden.no.

You'll here from me now and then, but not so often as before.


Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--


