Beginning Work [djo9] [far35]

[Francois-Rene Rideau]

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