---------- Forwarded message ----------
Date: Thu, 12 Nov 1998 20:29:46 -0800
From: David Ungar <David.Ungar@...>
To: Randy Smith <Randall.Smith@...>, randall.smith@...,
     mario.wolczko@..., david.ungar@..., lourenci@...
Subject: Re: Kansas (fwd)

Albertina,

Hi! Well, Randy said it far better than I ever could.
To paraphrase a joke from an American TV show:
"It's a dessert topping! No, it's a floor wax! Hey.....it's both!!!"

- Dave


At 11:09 AM -0800 11/12/98, Randy Smith wrote:
>Albertina --
>
>Well the question seems to be if Kansas is a multi-user programmable
>virtual reality or a graphical interface.
>
>I would say it is both, and here's why:
>
>It is a graphical interface in that every object in the system can be
>viewed as an object for direct manipulation.
>
>It is also a multi-user programmable virtual reality: As you know, Self
>is a fully general first class programming language in which everything
>is an object, including, for example, collections and numbers.  (In this
>regard, it is more object-oriented than Java, say, which has non-object
>data such as Java integers and classes.) Kansas is the environment for
>working with Self, and it is written in Self. Since even the rules of
>arithmetic can be changed as it runs, Kansas is a fully programmable
>world, supporting multiple simultaneous users.
>
>The only argument might come from someone who defines Virtual Reality as
>necessarily 3D. Kansas is a 2D space, although much larger than a single
>screen's worth of space. For some it would *not* qualify as VR without
>being a large *3D* space. For a few, a system must be 3D AND have a
>head-mounted display to be VR.
>
>Hope that helps.
>
> --Randy
>
>
>
>
>
>> From lourenci@... Thu Nov 12 10:50 PST 1998
>> Date: Thu, 12 Nov 1998 16:54:09 -0200 (EDT)
>> From: Albertina Lourenci <lourenci@...>
>> To: randall.smith@..., mario.wolczko@..., david.ungar@...
>> Subject: Kansas (fwd)
>> MIME-Version: 1.0
>>
>> Dear RAndy, Mario and Dave:
>>
>>                   First of all I want to congratulate you for having
>> created such a beautiful language as Self. I am  developing a knowledge
>> based systems in Self with the Jecel's help.
>>                    I would be very happy if you make your best to answer
>> this question because people from Third World countries can feel how
>> serious researchers from First World countries are. I mean I need this
>> answer to give continuity to my studies. It will help the outdated people
>> from the financing agency FAPESP in Brazil to understand that I am not
>> that kind of person who hears of a language in unspecialized magazines
>> and create my own usage of the words.
>>
>>
>>                  Thank you very much for your kind attention.
>>
>> Best wishes
>>
>> Albertina Lourenci
>>
>> PhD in Architecture and Urbanism USP
>>
>> post-doctorate student Laboratory for Integrated Systems USP
>>
>> ---------- Forwarded message ----------
>> Date: Thu, 12 Nov 1998 16:46:28 -0200 (EDT)
>> From: Albertina Lourenci <lourenci@...>
>> To: self-interest@egroups.com
>> Subject: Kansas
>>
>>
>> During the oral presentation of my PHD thesis on 10 November  I was
>> questioned by a young researcher in computer graphics if Kansas was
>> indeed a multi-user programmable virtual reality. He suggested it
>> was rather a graphical interface. I would be extremely happy if the
>> authors of the paper RAndall Smith, Mario Wolczko and David Ungar
>> answer this question. This was stated in the paper Thrown from Kansas
>> to OZ Collaborative debugging when a shared world breaks in CACM April
>> 1997. Of course anyone else can join the dialogue.
>>
>> Albertina lourenci
>>
>> PhD in Architecture and Urbanism
>>
>> post-doctorate student at Laboratory for Integrated Systems USP
>>
>>
>>
>>

     - Dave

     David Ungar
     Sun Microsystems Laboratories
     (650) 336-2618

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

During the oral presentation of my PHD thesis on 10 November  I was
questioned by a young researcher in computer graphics if Kansas was
indeed a multi-user programmable virtual reality. He suggested it
was rather a graphical interface. I would be extremely happy if the
authors of the paper RAndall Smith, Mario Wolczko and David Ungar
answer this question. This was stated in the paper Thrown from Kansas
to OZ Collaborative debugging when a shared world breaks in CACM April
1997. Of course anyone else can join the dialogue.

Albertina lourenci

PhD in Architecture and Urbanism

post-doctorate student at Laboratory for Integrated Systems USP


------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Jecel,
Thanks for the explanation. I have been trying to do what you told for some
time, but I didn`t link the code to the articles` contents so as to get this
pretty view you gave me.
I am doing a bookkeeping job on the classes and inheritance, but it seems not to
be a small job. Also, it is easy to get tired of looking at so much code if you
don`t understand how all that matches the beautiful theory we read in the
articles. Anyway, if someone wants to help, it is interesting that we start
reading specific subsystems of the VM, like asm, fast_compiler, lookup, prims,
parser, runtime, etc. I guess they are more or less independent of each other.
Douglas

-----
See the original message at http://www.egroups.com/list/self-interest/?start=25
--
Free e-mail group hosting at http://www.eGroups.com/
------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Steve Dekorte wrote:
> Jecel Assumpcao Jr <jecel@...> wrote:
> > There are easy (but slow) ways and there are hard (but a little
> > less slow) ways to do it. Many people have asked me to do this
> > over the years, so I looked into it.
>
> I'm interested in the details of the hard way. I see a problem with
> the slow way - If Java is 10x slower than C, and a JSelf within Java
> is 10x slower than Java, then it's use will be limited to simple
> scripting which isn't very interesting.

Even a simple Self interpreter written in C would be to slow for
pratical use. On page 31 of Urs' thesis there is a discussion of
the peformance of a Self interpreter and mentions one written in
Oberon-2 that was about 500 times slower than Oberon-2 itself.

Does anyone here have any experience with the Self 1.0 interepreter
written in Smalltalk? It was called Ultimardrev. Now that a free
version of the ParcPlace Smalltalk is available for Linux, I might
try it out.

About the hard way, it is the one Diego Deck listed as step "c" of
the JSelf project. It is essentially doing a full Self 4-like
virtual machine but using Java bytecodes instead of Sparc machine
language as a target.

> > Why not a plug-in?
>
> A plug-in is fine, as long as it's just as easy to install.
> With a COM object, installation = 1 or 2 button clicks.
> The last plug-in I tried to install was Cocoa and it wasn't easy.

My experience with Netscape 3 is that if a page includes an object
that needs a plug-in you don't have, you can be redirected to a page
at Netscape that lists all plug-ins available for your platform. You
just click on the right one and it is downloaded and installed. The
original page now works. The last time I did this was a long time ago,
so my memory is not to be trusted on this.

I have no idea how things are on the Internet Explorer side of things.

> > One problem with a Self or Smalltalk VM plug-in is that it needs
> > a rather complete image to work with (see Dolphin Smalltalk for
> > an example). What we need is a way to split up the image into
> > tiny pieces that can be loaded on demand.
>
> NewtonScript soups did this. I didn't like some of the details
> of their implementation but it's worth taking a look at.

I never saw any technical details on Newton soups, so I can't comment
on them. On the Merlin pages, I describe two different designs for
persistent objects store, but the one I intend to implement in tinySelf
is a little different in that there is no garbage collection at all for
old objects. I have this silly idea that disk space is growing at such
a rate that the horrible distributed GC problem is no longer worth
solving!

-- Jecel

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com

Jecel Assumpcao Jr <jecel@...> wrote:
> There are easy (but slow) ways and there are hard (but a little
> less slow) ways to do it. Many people have asked me to do this
> over the years, so I looked into it.

I'm interested in the details of the hard way. I see a problem with
the slow way - If Java is 10x slower than C, and a JSelf within Java
is 10x slower than Java, then it's use will be limited to simple
scripting which isn't very interesting.

> Why not a plug-in?

A plug-in is fine, as long as it's just as easy to install.
With a COM object, installation = 1 or 2 button clicks.
The last plug-in I tried to install was Cocoa and it wasn't easy.

> One problem with a Self or Smalltalk VM plug-in is that it needs
> a rather complete image to work with (see Dolphin Smalltalk for
> an example). What we need is a way to split up the image into
> tiny pieces that can be loaded on demand.

NewtonScript soups did this. I didn't like some of the details
of their implementation but it's worth taking a look at.

Steve
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

This is a general discussion list about Self, so not everyone will be
interested in hearing about the virtual machine's internals. I promised
I would say a little about it, however, so here it is:

When looking at any large C++ program, the first thing to do is to
list all the classes and make an inheritance tree showing what the
various subclasses are. Fortunately, this has already been done for
the 4.0 VM - take a look at the vm/memory/types.h file.

We can see:
   - the oop hierarchy (20 types) which represent the various "object
     oriented pointers" used in the system
   - the map hierarchy (27 types) which are the invisible meta-objects
     used in Self. They are the link to the C++ world and also serve
     as the system's notion of "type".
   - the memory hierarchy (20 types) which together organize space
     allocation
   - slots (2 types) this is what objects are made of
   - frames (4 types) allow access to the execution stack
   - misc (6 types) processes and stuff
   - lookups (12 types) the compilers need this for message sends
   - dependency (2 types) allows selective recompilation when the
     programmer changes something
   - code (9 types) the output of the compilers
   - various helper (16 types)
   - scanner (5 types) to convert Self source to bytecodes
   - statistics (4 types)
   - function types (10 types)
   - compiler classes (7 types) the compilers themselves
   - SIC classes (54 types) all of the temporary structures that the
     Simple Inlining Compiler builds up as it looks through the code
   - globals (3 types)

The next step is to look through the code and see what groups of
classes are used together (what "frameworks" are part of the system).
I haven't done this and it would be pretty long anyway. Understanding
the Self VM is far from trivial, and porting to another machine is
even harder. But it is certainly worth the effort.

-- Jecel

______________________________________________________________________
NextCard Internet VISA -- 2.9% intro APR
Earn free airline tickets WITH DOUBLE Rew@rds points.
http://ads.egroups.com/click/61/0/nextcard

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Steve Dekorte wrote:
>
> Doesn't Java count as Java a "huge plug-in"? :-)

Very true, technically. But it feels very different since it comes
in the same download or CD-ROM as the browser itself. Another
difference is that it is included in all ports of the browser, while
a lot of plug-ins are Win32 or Mac only.

> I know Netscape is moving it to the plug-in side, at least.
> And Java is certainly huge in size and complexity.

A great opportunity for Self or Squeak!

> I don't see how mapping Self like language to Java byte codes
> is possible,

There are easy (but slow) ways and there are hard (but a little
less slow) ways to do it. Many people have asked me to do this
over the years, so I looked into it.

> but even if it where, wouldn't it be better to
> write a small, fast VM and stick it inside an Active-X control
> for Netscape and a COM object for IE?

Why not a plug-in? Aren't the solutions you propose Win32-only? At
least Netscape has made loading plug-ins a lot more automatic than
it used to be.

One problem with a Self or Smalltalk VM plug-in is that it needs
a rather complete image to work with (see Dolphin Smalltalk for
an example). What we need is a way to split up the image into
tiny pieces that can be loaded on demand.

-- Jecel


------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

I'd like to make the JSelf project GNU, but I'm not sure about the licenses
implication of use the sunlabs sources as base of the developing.

Any of you know about this????

(|diego. gomez. deck|)


-----
Free e-mail group hosting at http://www.eGroups.com/
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

The principal idea to make the Java classes available to the JSelf environment
is to show the Java classes as a set of Self Objects:

one trait that represent the class and,
one prototype per constructor.

For the constructor with parameters we will use a copy message with parameters.

This is the very preliminar idea,

All your comments help to the project....


(|diego. gomez. deck|)

PS: I like that many people is interesed in the project


-----
See the original message at http://www.egroups.com/list/self-interest/?start=19
--
Free e-mail group hosting at http://www.eGroups.com/
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

The principal idea behind the JSelf porting is not to execute in a browser....
(This is a secondary efect)

The ideas will be writed soon in a document called "Why JSelf?".

Before this document becomes available I'll tell you why we believe in a Java
Port.

1) Run Everywhere.  All of us thinks that one pendient thing of Self is the
posibility of run in too many machines.
2) Garbage Collector.  The actual implementation of Java GC not are to good, but
they are working... (And many people is working in do them better!)
3) And.... HotSpot... We beleive that some of the work to make the JSelf
performance aceptable is current in process in JavaSoft....  Another chance is
the GNU-Spot project....

The project are in the initial stage, too many definition are pending, but we
have in mind 3 stages in the project
a) Interpreter (No care of performance)
b) Runtime Bytecode generation (A la JPython)
c) Dinamic Runtime Bytecode generation, type inference and.... all the necesary
to make the JSelf usable.

TIA,

(|diego. gomez. deck|)

PS: If i spend the time writing mails, I can't work in the project.

-----
See the original message at http://www.egroups.com/list/self-interest/?start=20
--
Free e-mail group hosting at http://www.eGroups.com/
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

>Once again, I'd like to say that this is a very worthwhile effort
>and it will be very important to be able to run Self code inside
>a web browser without having to load a huge plug-in.

Doesn't Java count as Java a "huge plug-in"? :-)

I know Netscape is moving it to the plug-in side, at least.
And Java is certainly huge in size and complexity.

I don't see how mapping Self like language to Java byte codes
is possible, but even if it where, wouldn't it be better to
write a small, fast VM and stick it inside an Active-X control
for Netscape and a COM object for IE?

Steve
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Diego Gomez Deck wrote:
>
> One very simple Home Page for the JSelf project has borned in
http://www.ConsultAr.com/JSelf
>
> All of you are invited...

Once again, I'd like to say that this is a very worthwhile effort
and it will be very important to be able to run Self code inside
a web browser without having to load a huge plug-in.

While Java and Python have a lot of things in common, Self is not
class based which might complicate things a little for you. JPython
allows you do subclass a Java class (Applet, for example) with Python
code. When you make an object inherit from another in Self, however,
it does not get a copy of the state of that object (instance variables
in class based languages) but shares that state instead. The Self 4.0
programming environment simulates this class-like behavior with what
are called "copy down slots", but this isn't part of the language
itself.

The only other problem I see is that if you translate Self self-send
bytecodes to Java send bytecodes, the performance will be horrible.
If, on the other hand, you translate these bytecodes to more specific
Java bytecodes (instance variable and constant bytecodes, for example)
then you will have to have a complex dependency mechanism to undo this
if the user changes the Self sources.

-- Jecel
P.S.: if everybody working with Self is in South America, maybe my
future Self book should be in Spanish/Portuguese instead of English? ;-)


______________________________________________________________________
NextCard Internet VISA - 2.9% intro APR
Earn free airline tickets WITH DOUBLE Rew@rds points.
http://ads.egroups.com/click/63/0/nextcard



Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello, all.  I'm Doug Auclair; I'd like to help the porting effort of SELF.  It
seems the source is not at self.sunlabs.com (the just have a binary in the tar
... and I don't have a Sparc).  Would someone give me the source/point me to the
URL where it is?  Is it, like, GPLed?  Question for Jecel:  you said you're
running SELF on an Ultra5.  I'm not sure, but I think they are expensive?  What
version of Solaris is it running on?  Is it too slow to run in on a Sparc2 or 5?
When I read the whitepapers on SELF, I thought, <em>WOW!</em>, inheritance
without classes.  And I thought Smalltalk was responsive. (well, it is!  I
program in C++ on the job :-)  Here I am, what do you need me to do?  thx, Doug

-----
Free e-mail group hosting at http://www.eGroups.com/
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Diego Gomez Deck wrote:

	 The thing is getting better...

> One very simple Home Page for the JSelf project has borned in
http://www.ConsultAr.com/JSelf
> All of you are invited...

--
-----BEGIN PGP SIGNED MESSAGE-----

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Luis Campos de Carvalho - Undergraduate Student at University of São
Paulo
http://www.lsi.usp.br/~campos
mailto:campos@...

            Train Station is the place where the train stops.
              Bus Station is the place where the bus stops.
               On my desktop, I have a WORKstation... :-)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>

iQEVAwUBNg59Nlg/n1QImiClAQHTZAf9HYEzgLwQlBwTSzMWIQ2woTZf7p7OJdOP
ZiQrNYF2ZdcJFMZPdmeIzde98Eh4FV58iZTkatQbjbaiKL6eIwDFzSNMRDECLHY/
LE9G1CuUMn69PxotE74CqFtSjAR4QbCJbk5P5MKcojSEStbeqBWb8L1vVYTWhsW+
xRtrs/OktJNv7+FPaXwK/ieYYXPCFIjjui3FWWolofuMW/ewImYaQ0cquxD/1YJ7
TQTN/1EdXQh3AopRQd9hX0ZRBPy+nZlN48vlT4/PY5Oy6DjGvNX7N47eZOJskUlU
zoLA4eWKZvYB2EzFUT6NkvOh+v8xJqcEk0UOKHMpNNg9ATe9b4+CtQ==
=7RWr
-----END PGP SIGNATURE-----
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

One very simple Home Page for the JSelf project has borned in
http://www.ConsultAr.com/JSelf

All of you are invited...

(|diego. gomez. deck|)

-----
Free e-mail group hosting at http://www.eGroups.com/
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

> If you mean a version of Self that run on a normal Java VM, that is
> a very good idea any many people have written to me in the past
> suggesting that I do something like this. While I have gone in another
> direction, there certainly seems to be some demand for this. I don't
> know if you saw what the Python people did (called JPython - see
> http://www.python.org), but it will probably help spread that
> language a bit more.

The inspiration comes from JPython.  The JPython integration with Java classes
is very interesting.

(|diego. gomez. deck|)

-----
See the original message at http://www.egroups.com/list/self-interest/?start=14
--
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________
NextCard Internet VISA -- 2.9% intro APR
Earn free airline tickets WITH DOUBLE Rew@rds points.
http://ads.egroups.com/click/61/0/nextcard

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Diego Gomez Deck wrote:
> I started a Self implementation dependent of the Java VM.

If you mean a version of Self that run on a normal Java VM, that is
a very good idea any many people have written to me in the past
suggesting that I do something like this. While I have gone in another
direction, there certainly seems to be some demand for this. I don't
know if you saw what the Python people did (called JPython - see
http://www.python.org), but it will probably help spread that
language a bit more.

Another interesting thing to do is to allow Java programs to run
on top of Self 4.0. This would let the web browser run applets,
for example. One trivial way to do this would be to translate
Java bytecodes more or less directly into Self bytecodes with
most of the more complex ones being converted into normal message
sends (plus an adequate library, of course). If I remember correctly,
some student has already done something like this at Sun, right?

-- Jecel
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello,

I started a Self implementation dependent of the Java VM.

In a few days, will be a web site to visit.

I'd like to known your opinion.

TIA

(|diego. gomez. deck|)

-----
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________
Setup your own FREE forum. You control access to your message board
and chat room. Great for families, workgroups, special interests,
businesses, alumni groups ...
http://www.delphi.com/eg

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

I'll make some comments on the Self implementation tomorrow, but I
would like to reproduce here a message I sent to the "chipcon" list
at the old Byte site and also to the Squeak mailing list. It is a bit
dry and technical - I was trying to clearly define what I meant by
terms like "virtual machine" and "adaptive compilation":
-------------------------------------------------------------------
I will define what I mean by various terms to make the
following discussion clearer:

  - native compilation: the developer invokes some program
    on his/her machine to produce a machine language version
    of the application, which is then distributed to users.
    Examples include VC++, Cobol and many others.

  - virtual machines: code is compiled into the machine language
    of a CPU that is different from the one on which it will
    actually run. Examples include UCSD Pascal P-Code, the
    AS/400, Smalltalk and Java bytecodes, 68K Mac code on
    PowerMacs, X86 code on Alpha NT machines, etc. Note that
    most people would not agree with this definition, saying
    that a virtual machine is a definition of a CPU that
    doesn't actually exist. But this would exclude Java from
    this list once Sun gets its Java chips out the door.

  - interpreted virtual machines: a program on the user's
    computer simulates the CPU the code was compiled for.
    This is a few orders of magnitude slower than native
    compiled code. Examples include most Smalltalks, the
    first Java implementations, the 68K emulator on PowerMacs,
    UCSD Pascal, and others. Since this is much simpler than
    the following technologies, it is usually used to quickly
    get the system "out there".

  - install time compilation: instead of simply copying the
    virtual machine code to disk, the installation software
    compiles it to the user's native CPU code. The only example
    of this that I am aware of is the proposed Architecture
    Neutral Distribution Format (ANDF) for GNU software. This
    kind of system doesn't usually have a virtual machine
    definition that is easily interpreted, but is more like
    the intermediate code between compiler passes.

  - load time compilation: the virtual machine code is stored
    on the user's disk, but when it comes time to load it into
    memory for execution it is translated into native code
    (possibly also stored in a disk cache). Examples include
    the TAO OS and Java Just In Time compilers.

  - dynamic run time compilation: the virtual machine code is
    actually loaded from disk into memory, but the first time
    that some piece of code would be executed it is translated
    into native code and stored in the memory based code cache.
    Examples include some Smalltalks and ARDIs Executor Mac
    emulator.

  - adaptive run time compilation: like the previous one but
    normally uses more than one compiler. When a piece of
    code is first called, it is translated by a simple and
    fast compiler and "instrumented" to generate information
    about its execution characteristics. If this code proves
    to be a bottleneck for system performance, it is compiled
    again with a much better compiler which will use the
    collected execution statistics to adapt the code as much
    as possible to the current runtime environment. Examples
    include Self (from Sun) and Hot Spot (now at Sun - there
    seems to be a pattern here, doesn't it? ;-)

  - hardware: a hardware implementation of a virtual machine
    will get all the benefits of native compilation yet still
    be compatible with the other alternatives. Examples include
    Western Digital's P-Code engine, several Smalltalk chips
    (not SOAR, Smalltalk On A RISC, though) and PicoJava.

One interesting example missing from my list is DEC's FX!32
technology. I don't know enough about it to classify it,
though it seems to combine elements of adaptive compilation
(or at least dynamic compilation) and load time hints.

The first thing we should note is that native code for most
popular CPUs (specially RISC ones) tends to be sufficiently
larger than bytecoded virtual machine code that a low end
Pentium can probably compile bytcodes to native code much
faster than the disk could load the extra sectors needed
to hold the larger native code. So it might have made sense
to save native code on disk in the past (install time and
load time compilation) but this is no longer true (even
dynamic and adaptive compilation schemes have to be very
carefull not to do this indirectly through the virtual
memory system).

Memory size and compilation overhead can be greatly reduced
in adaptive systems by not compiling "uncommon branches".
If is piece of code is not likely to be used, don't waste
time on it until it actually is. Of course, having the
compiler(s) sharing memory with the application at run time
might offset some of these gains. It is important to note
that the quality of native code generated adaptively often
exceeds that of even very good native compilers for they
can do agressive inlining and other things that are not
practical until run time information is available. The
key here is that the adpative compiler can "guess" that
some things will be constant even though the source code
doesn't say it is. The native compiler must be conservative
and always treat this case as variable. If the adaptive
compiler guessd wrong and the value does change, then there
is no harm done - just compile it again fixing this!

-----------------------------------------------------------
I hope this helps at least place the Self VM solution in context.

Cheers,
-- Jecel

------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Where can I download the Linux version of TinySelf???

(|diego. gomez. deck|)


-----
Free e-mail group hosting at http://www.eGroups.com/
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello, Jecel, everyone.

Well, I would like both theoretical and practical explanations. I have read
papers but it is not necessarily true that I understood it all. If you are
pleased with the idea of a generic explanation about adaptive compilation, I
would be glad to "listen to" it. But yes, I am reading Self 4.0 VM source code
and would also like some explanation on how to start reading that bunch of C++.
I have tried to systematically read each class but it is not very productive, at
least for my knowledge level. It is too bigger and more complicated than every
code I have already seen.
I also have doubts on the development environment. This document (vmUseDoc), for
instance, tells a lot about how to setup a personal copy of the Self code and VM
sources to make enhancements to the project.
There are lots of shell scripts that make lots of small tasks, and also some
programs in C++.
One of these programs, for example, makeDepsAndIncs, creates include files for
every source file to automate the task of making class declarations available to
other classes that depend on them. It is incredibly ingenious. The includeDB is
a file that lists all the dependencies of one file on every other, which is very
easy to maintain. Then one only runs a script that invokes this makeDepsAndIncs
and you have the includes ready. All this is ready for Solaris on SPARC. When I
tried to compile it, first on Linux, then on Win32 with GCC (Cygwin32) then with
Borland C++Builder, it didn`t work. It behaves strangely and sometimes running
it causes an error. I think there is a memory leak somewhere, as when I run it
on Linux it says there is not enough memory, and Windows (compiled with
GCC-CygWin32) exits with a GPF. Windows compiled with Borland C++ doesn`t crash,
but exits with a error. Debugging the program, I found out that sometimes a
character '\x0E' is inserted in the middle of the filename strings that the
program inserts in the include files. I stopped here and that's where I am now.
Is someone there acquainted with the Self development environment that could
understand what I said?
Another strange thing is that the source directories explanation lists
directories (like the new_compiler) which don`t appear in the Self 4.0 VM
sources, and some directories that appear in the sources are not listed there.
In fact, the directories explained in vmUseDoc seem to be the ones in the Self
3.0 VM sources (the ones you arranged for me, thanks).

As you see, I have looked at many aspects of the VM, so I have doubts of the
most eclectic kinds. Let me organize it. I would like to start from the
beginning, so that other people that like Self can understand all this.
Could we start by explaining what Self is and what adaptive compilation is? I
think this will help me refresh my memory, correct eventual misunderstandings I
may have and help newcomers to this list find out what they are getting into.
:-)

Regards,
Douglas

-----
See the original message at http://www.egroups.com/list/self-interest/?start=6
--
Free e-mail group hosting at http://www.eGroups.com/
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Gregory Burd wrote:
>         I have toyed with tinySelf (nice work)

Thanks, but I wonder if you are talking about the C parser thing
(which I renamed tinySelf 0) or the one in Self (tinySelf 1). The
former doesn't do anything while the latter is still very much
broken (but at least it is broken in parallel ;-).

> and I have started an
> implementation of the train GC algorithm to place under GNU GPL
> someday with all of the extra stuff that Java 1.2 has added to the
> complex world of GC.

I liked the train algorithm as was presented for Beta at ECOOP'95,
but don't know if any idea with backpointers will ever be scalable.

I haven't kept up with what has been happening on the Java front
and frankly don't care - I can never use anything that wasn't already
in Java 1.0 or it won't work with a lot of browsers out there (including
the ones I use).

> I have also toyed with various adaptive
> compilation ideas, no code there yet...

Too bad the Self 4.0 virtual machine isn't exactly an ideal place
on which you could try out your ideas - it is hardly "open ended"
enough for that.

Cheers,
-- Jecel


------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Greetings all,

	 My name is Greg Burd, I work for Sun.  I used to work in the
JavaSoft division, now I write software to generate excitement in
emerging markets.  I have followed Self for years, I have videos on
it, I have talked to the people who wrote it, I love it.  I hated the
day that Steve Jobs killed the Newton not only because it was a great
technology, but also because it was inspired by Self to some degree.
I have other reasons to dislike Steve, I used to work at NeXT Computer
(note the "Computer" part, :)

	 I have toyed with tinySelf (nice work) and I have started an
implementation of the train GC algorithm to place under GNU GPL
someday with all of the extra stuff that Java 1.2 has added to the
complex world of GC.  I have also toyed with various adaptive
compilation ideas, no code there yet...

just thought I would drop everyone a line,

-greg
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Douglas ,

Since you have already read a lot of the Self papers as well as at least one of
the thesis about the Self compilers, I am assuming you want a more detailed
explanation of the C++ code and not a generic explanation about adaptive
compilation, right?

At least some of the people who actually wrote this code are on this list, as
they can certainly give a much better answer than I can as I have only looked
briefly at the VM sources (I mostly use the Unix commands grep and find to
search for what I need and just look at that).

In the virtual machine directory, there is a "doc" subdirectory. The file
vmUseDoc (in various formats) mostly explains how to invoke make to generate a
new VM, but it also has a one line comment about each of the source
subdirectories. The file stackFormat is very short but really helps to
understand what is going on. And the file vm-debugging.doc (how did a Word file
get here!?!) has tips on tracking down bugs in the VM, but it also clears up a
few points about how it works.

If you could be more specific about what you would like to know, I'll be glad to
look up the answer (that's what grep is for :-)

-- Jecel
P.S.: this list is currently set up so that the Reply-To: field is set to the
author, not to the list. It is easy for me to change this, but I don't know what
people prefer. The way it is now, you can "reply" to send a private comment or
"reply to all" to send to the list (and an extra copy to the author). If I
change it then "reply" will send to the list (what you want most of the time)
but there is no way to send a private reply to the author without manually
editing the To: field in the composition window.



------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello all:

               I have just read Douglas's message. I do think it would be
better if
everybody introduces oneself. We would know about each one's interest in

Self and have an idea about the possibility of the prototype to take
off  and
prevail over the class world.

Best wishes
`
Albertina Lourenci
I will defend my PhD thesis  in architecture and urbanism on 10 November

candidate to post-doctorate student af Laboratory for Integrated Systems
USP

------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello, everyone. Let me introduce myself. I consider myself new to Self though I
first heard about it in 1996. I got interested in its philosophy of simplicity
and power, together with the prototypes which were a new concept to me. In fact,
I have downloaded and printed most of the articles available on
http://self.sunlabs.com/ but have not been able to grasp all the concepts and
ideas present in these articles. Perhaps the problem was that I didn't have a
SPARCstation on which to run Self. I thought it would be interesting to try to
port the Self Virtual Machine to a more popular architecture, like PCs, but it
is proving itself not very easy. As I am so stubborn, I have not given it all up
yet, but set a new aim for myself: I intend to study the Self Virtual Machine
and model it with the Booch'93 notation. If anyone wants to join this
"expedition" into the Self source code, please do. You are supposed to be able
to read C++ source code. Then you are supposed to download the sources and look
at them!
Note: I intend not to do it in a hurry, as I am rather busy with other subjects
by now, and I intend to be looking at this list once a week (on Tuesdays). I
appreciate comments on the structure of the Self VM (I know of at least Jecel
who knows Self well enough to do that) and suggestions of recommended readings
about it.
I hope this makes everybody start talking. This list is so quiet...
Regards to all,
Douglas

-----
Free e-mail group hosting at http://www.eGroups.com/
------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

One of the main complaints I hear about Self is that it takes up
too much memory (the other is that it only runs on Sparcs). Since
I see people buying entry level machines with 64MB of RAM or more
perhaps this isn't as much of an issue as it used to be. What
follows is a comment on the implemenation details of Self and
probably won't make any sense to someone who is unfamiliar with
that.

I was looking at a paper to be presented at Micro'98 by Karel
Driesen and Urs Hoelzle (called "The Cascaded Predictor:
Economical and Adaptive Branch Target Prediction") and found it
interesting to note the parallels between their problems and
the implementation of Self.

One source of code bloat is excessive customization. When you
generate dozens of copies of native code, all alike, you are
wasting time as well as memory. In the same way, the UCSB guys
noted that when you use two level branch prediction hardware
(the moral equivalent of customization) you end up with many
entries that are really all alike. They added a filter that tries
to discriminate between branches that can be handled in one
level (not customized) and those that get better results in
two levels (customized). This allowed them to get by with two
small memories (one for each case. Not really, but read their
paper if you really need to know ;-) instead of one huge one.

This reminded me of an idea I worked on last year. The idea is
that compiled native code would be shared between different
objects (not a problem with PICs as they do their type checks
on the caller side, it but does require multiple headers for ICs).
This would happen as long as all lookups for messages to self
gave the same results (for the different objects). This would
have to be tested recursively (any self messages must invoke
native methods that are also shared). If this test fails, then
a new (customized) native code must be generated for the current
object, otherwise just a new header will be enough.

I don't have any data on how much memory this would save, but
hope to work on this soon. Anyway, avoiding another customized
version of a method not only saves some space but replaces the
compilation with just the lookups for implicit self messages.

-- Jecel


------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

I am putting all the little patches I need to make Self 4.0 work right
as modules in a special patches directory. So far I have:

    canvasPatches.self : fixes a 'gc not found' bug when Self tries to
recover colors from the colormap.
    xlibPatch.self : the _XStoreBytesInto: primitive worked on older
machines, but fails in SunOS 5.6
    webPatch.self : the format of the GET command doesn't work with the
Apache proxy server

If there is any interest, I can put these in some directory where they
can be downloaded.

I was hoping to patch Self to work with more than 256 colors (which is
really annoying), but that looks like a major rewrite instead. Another
interesting thing to have would be the code mentioned in the "Oz"
debugging article to avoid creating new worlds on the slightest crash of
the UI. Here is a case where a decent exeption system would make things
much easier.

-- Jecel
P.S.: sorry about the ads. I thought they would be shorter. Anyway, we
will have to put up with them until egroups starts accepting credit
cards :-(
P.S.2: I was going to go to OOPSLA'98 but chickened out at the last
moment. Will there be any kind of "Self get together" there this year?
Otherwise just sneak in the Squeak crowd :-). Next year there will be a
big Self BOF - count on it!


------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Welcome to the new self-interest mailing list!

The question that I get most often about Self is: who is using it?

I am (in fact, I just got myself a new Ultra 5 just for this) for a lot
of different things. I used it to extract the emails of people who had
posted to the other self-interest mailing lists since 1994, for example
(much more fun than Perl!). And I am using it to develop tinySelf, which
I hope to port to the PC in a couple of months.

At the university of Sao Paulo I had two trainees with little previous
programming experience who use Self for a whole year. That project is
over now, but they built a simple 3D wireframe system and a Petri Net
simulator.

Albertina Lourenci is using Self in her architectural PhD thesis.

Other people at LSI-USP (specially in the IC CAD group) are starting to
get interested in Self.

But I would really like to hear from anyone else who is still working
with Self.

-- Jecel Mattos de Assumpcao Jr -- mailto: jecel@...
           http://www.lsi.usp.br/~jecel/merlin.html



------------------------------------------------------------------------
Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.