headers
Matthew Gruenke | 3 Jan 1996 04:41
Picon

Re: TUNES object interactivity

>Dear Matt,
>   you description of your wished OS seems perfectly in phase with the TUNES
>project: fine-grained objects that users combine at will to obtain a custom
>system adapted to their needs and resources.

  Cool.  Resonance is being attained (I hope).

>   Actually, this is precisely what the Interfaces project is all about:
>the HLL project defines objects with clean, well-known semantics. But whenever
>there is no precise well-defined semantics for an object, it is defined with
>annotations describing what we know about the object, and external heuristics

  Why not require objects to be able to report information about themselves, 
upon request?

  Are all objects required to be written in either HLL (and/or) LLL?  Are these
then compiled when the code portion is to be run?

  Might objects be required to be able to create a copy of themselves, in their
packed up, distributable format, with their settings set to default?

  What did you think about my comment that all commands in an application, that
are available to a user via an interface, be available to another object?  This
seems to me like a requirement for the interface, alone, if flexibility is to be
maximized.  The added benifit of being able to write "super-apps" also seems
quite nice.

                                                :Matt Gruenke
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francois-Rene Rideau | 3 Jan 1996 16:02
Picon
Picon
Favicon

Re: TUNES documentation comments & misc questions

>    I am impressed at the amount of time and work that you've clearly
> put in on this project, so far.
   You shouldn't: I do like to think that I have put a fair amount of
original ideas in this project, but I have to bitterly admit that actual
work is what the project lacks most.

> For about how many years have you been involved with TUNES?
   Hum. Difficult to say. Somehow, I've been thinking about it this I began
programming and was disappointed by the deeply rooted stubbornness of
available computer tools. The TUNES project itself began on late '94.
As you see, the yield has been poor :( :( :(.

>   About how many are on the mailing list?
   Again, the yield is poor. There are 46 people listening (or at least,
there were that much people subscribed last time I checked, one week ago),
but few are speaking (five at a time has been the max, I think),
and fewer even working (half a person, I'd say, including myself).

>   About how many hours per day do you put in on it?
   Greatly varies, and not enough, seemingly.
   I want all the code I produce to be perfect, so my code yield is poor,
plus I have great difficulties to begin when I write anything but e-mail or
draft notes.

>   Would you care to make even the vaguest estimate for a scheduel on the
> implementation of TUNES?
   Last time I cared, I was false. When the year is well begun, I'll try
give another, better one.

>   Has a specific course of action been mapped out in order to deal with some
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francois-Rene Rideau | 4 Jan 1996 03:33
Picon
Picon
Favicon

Re: About a new HLL

> Hi Fare',
>
>           I appreciate your attempt in order to make an ideal language.
   Thanks.

> To do this must be considered why the others languages have not meet
> the objective:
[I put your first suggestion last, because my reply to them is quite longer]

> were the people less intelligent than yours?
   Sure sure not !

> were the forces (# human hour) less than yours? ... sure not!
   Indeed.

   Those two points have long inspired me fear and doubt, which up to now
has prevented me from advancing more on my language design.

> were the ambitions fewer than yours?
   I dare affirm that in most cases, yes.
   Most languages (FORTRAN, BASIC, C, Pascal, Prolog, Smalltalk, C++, {,s}ed,
awk, {,ba,c,k,z}sh, Perl, etc) began as a quick and dirty hack to get things
running with some programming style in mind, with more hacks added as
intended programs needed some, sometimes ending in a huge kludgy bloat.
Though seemingly very efficient in the limited scope of programming they were
developped for, these languages are horrid monsters that are unable to do
anything with any efficiency outside of this limited scope, and tie
miserably the problems they process to the ad-hoc representation
that was used at the time they were designed.
   Some languages (Algol, Ada, Common LISP, *ML, etc) had the ambition
(Continue reading)

Permalink | Reply | 0 comments |
headers
Unknown | 4 Jan 1996 03:33

Re: About a new HLL

> Hi Fare',
>
>           I appreciate your attempt in order to make an ideal language.
   Thanks.

> To do this must be considered why the others languages have not meet
> the objective:
[I put your first suggestion last, because my reply to them is quite longer]

> were the people less intelligent than yours?
   Sure sure not !

> were the forces (# human hour) less than yours? ... sure not!
   Indeed.

   Those two points have long inspired me fear and doubt, which up to now
has prevented me from advancing more on my language design.

> were the ambitions fewer than yours?
   I dare affirm that in most cases, yes.
   Most languages (FORTRAN, BASIC, C, Pascal, Prolog, Smalltalk, C++, {,s}ed,
awk, {,ba,c,k,z}sh, Perl, etc) began as a quick and dirty hack to get things
running with some programming style in mind, with more hacks added as
intended programs needed some, sometimes ending in a huge kludgy bloat.
Though seemingly very efficient in the limited scope of programming they were
developped for, these languages are horrid monsters that are unable to do
anything with any efficiency outside of this limited scope, and tie
miserably the problems they process to the ad-hoc representation
that was used at the time they were designed.
   Some languages (Algol, Ada, Common LISP, *ML, etc) had the ambition
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jecel Mattos de Assumpcao Jr. | 5 Jan 1996 04:17
Picon
Picon

Re: About a new HLL


I hope this gets to the list - I haven't
had success posting here since June 1995!

I would be interested in Fare's comments on
Agora, since he wrote so much about reflection.
(http://progwww.vub.ac.be/prog/pools/agora/agora.html)

-- Jecel
Permalink | Reply | 0 comments |
headers
Harrison R. Ulrich | 5 Jan 1996 05:13

<none>

That Fare does know his stuff!

Dick
Permalink | Reply | 0 comments |
headers
Carlos Querol | 7 Jan 1996 06:14
Picon

Re: About a new HLL

Just tossing in some spare change.
(and testing that my reply/post is working :-)

I have (since before java came on the scene) believed that the future 
of program execution lies in "byte code" compiled programs executing 
on a portable interpreter.  It would be nice to be able to port an OS 
to a new platform and have the (compiled) programs from all the other 
existing platforms execute without modification.  The traditional 
arguments against this is that it adds overhead to the program (due 
to the byte code interpeter layer).  But today (and in the future) 
the rise of distributed systems would make this a requirement for 
successful application execution accross hetergeneous environments.
Along these lines, a question:  Does any one know how Plan 9 
distributes process execution to the compute servers?  I have read 
the FAQ (admitedly a while ago) and found no reference to this.  I am 
wondering if they set up a transparent execution layer, or if the 
process has to exist as a binary the compute server can execute.

Carlos Querol
quer0008 <at> tc.umn.edu
Permalink | Reply | 752 comments |
headers
Michael Hooker | 7 Jan 1996 15:11
Picon
Picon

Re: About a new HLL

Carlos Querol wrote:
> 
> Just tossing in some spare change.
> (and testing that my reply/post is working :-)
> 
> I have (since before java came on the scene) believed that the future
> of program execution lies in "byte code" compiled programs executing
> on a portable interpreter.  It would be nice to be able to port an OS
> to a new platform and have the (compiled) programs from all the other
> existing platforms execute without modification.  The traditional
> arguments against this is that it adds overhead to the program (due
> to the byte code interpeter layer).  But today (and in the future)
> the rise of distributed systems would make this a requirement for
> successful application execution accross hetergeneous environments.
> Along these lines, a question:  Does any one know how Plan 9
> distributes process execution to the compute servers?  I have read
> the FAQ (admitedly a while ago) and found no reference to this.  I am
> wondering if they set up a transparent execution layer, or if the
> process has to exist as a binary the compute server can execute.
> 

Plan 9 Keeps a bin directory for all the different processor types then
it binds that directory (the one for the local processor onto bin).

I can go into more depth if you like :)

Michael
Permalink | Reply | 0 comments |
headers
Francois-Rene Rideau | 10 Jan 1996 22:50
Picon
Picon
Favicon

Re: About a new HLL

> Just tossing in some spare change.
> (and testing that my reply/post is working :-)

   Ahem. fare <at> ens.fr is a buggy address (fare is my usual login at home,
but the login I receive e-mail to at school is rideau). But I got the
message by tunes <at> ens.fr which works.

> I have (since before java came on the scene) believed that the future
> of program execution lies in "byte code" compiled programs executing
> on a portable interpreter.
> It would be nice to be able to port an OS
> to a new platform and have the (compiled) programs from all the other
> existing platforms execute without modification.

   The P-Code based OS from UCSD in the late 70's already used portable
bytecodes. Today, lots of language systems like emacs lisp, caml,
clisp, etc, have portable bytecode systems.
   TAOS, a commercial OS, uses a RISCish "portable assembler" language
that each architecture assembles to its own code before it gets executed.
Mac/68K emulators that run on PCs or PowerPCs have no problem with
dynamically recompiling 68K assembly into native assembly with good
performance (roughly one 68K instruction to three native code instructions)
and response time.
   Even traditional unices manage to share a same environment by mounting
architecture-dependent partitions on similar trees and using architecture
dependent paths to find the right binaries.
   So techniques for cross-architecture computing have always existed,
and many other techniques haven't been explored yet. What prevented them
from being widespread is the strength of hardware-based industrial standard
rather than software-based ones.
(Continue reading)

Permalink | Reply | 751 comments |
headers
Harrison R. Ulrich | 11 Jan 1996 03:31

<none>

Hello list,

Does anyone on the list have any experience with the dynamic generation
of machine code? Or know of any tools which can give some element of
portability in this area?

Given a contiguous vector of elements such as ints, doubles, bits, etc.,
I need to set out on a sensible direction such that I can execute the
machine code generator on different architectures.

The extent of the generation is simply the machine code to 'access' the
'next' element of an array.

Thanks,
Dick
Permalink | Reply | 2 comments |

Gmane