TUNES Update

[Tom Novelli]

Greetings, everyone... I'm writing to bring you up to date on what little
progress has been made in the TUNES project:

1. Website

I've moved the new site to http://tunes.org/ ... It's a little spiffier now,
and I've started to address some of the shortcomings that Keith pointed
out. Further suggestions welcome!

The gory details:
The new site consists of HTML generated by the CMS, from source files in
a MySQL (soon to be SQLite) database. The old files are still there for
now, but the CMS will overwrite them if the same name is used.
(See http://tunes.org/sitemap.html for an index of old files)
I disabled the 'update_tunes' line in ~tunes/bin/junk.script -- That's
so changes made to the old "master website" (in CVS) won't interfere with
the new site. As far as the TUNES website is concerned, we don't need CVS
anymore.
I'm also planning to move all the old stuff (of some value) into a
central archive, and delete everything else, to make this less confusing for
the next maintainer.


2. Newsletter / Announcements

I will be posting an update like this at least once a month, on the mailing
list and the website, if only to say "we're still alive" and to mention a
few outside developments of interest to this group.

Any contributions (preferably at least 50 words in length) can be emailed to
me.


3. Future Directions

I'd like to start a discussion on the "ideal" framework for organizing
information, with an eye toward future versions of the website CMS. Issues
include metadata, versioning, multiple users, distributed storage and
migration.

New major versions of Python, Ruby, Perl and Javascript are in the planning
stages, probably for the next 2-4 years. They're all talking about static
typing, native compilation, real GC, and so on -- and borrowing heavily from
one another. These languages won't give up their individuality yet, but a
"common core" is entirely possible. This has the potential to make TUNES a
reality, in large part. If we do our homework, this could be an opportune
time to weigh in.

- Tom Novelli

[M. Edward (Ed) Borasky]

Post by Tom Novelli
3. Future Directions
I'd like to start a discussion on the "ideal" framework for organizing
information, with an eye toward future versions of the website CMS.
Issues include metadata, versioning, multiple users, distributed
storage and migration.
New major versions of Python, Ruby, Perl and Javascript are in the
planning stages, probably for the next 2-4 years. They're all talking
about static typing, native compilation, real GC, and so on -- and
borrowing heavily from one another. These languages won't give up
their individuality yet, but a "common core" is entirely possible.
This has the potential to make TUNES a reality, in large part. If we
do our homework, this could be an opportune time to weigh in.

Well ... I just got back from the Mountain West Ruby Conference, which
featured an implementer's summit. The "Ruby Roadmap" looks a lot like a
three-horse race. Ruby on the Java Virtual Machine looks like the horse
to beat at this stage. At least Sun is backing it up with marketing
muscle and yet keeping it open source. Number 2 is a clever hack called
Rubinius that's inspired by Smalltalk/Squeak -- do everything you can in
Ruby and only have C where it's absolutely required. And number 3 (right
now) is the so-called "MRI" (Matz' Reference Implementation).

See my blog for (a little) more detail.
http://borasky-research.blogspot.com/2007/03/and-winner-is.html. In any
event, if you're looking for the "ideal framework for organizing
information", I don't think either conventional computer science or
today's or even next year's programming languages have much to offer
that we haven't already seen. I personally think Erlang is the future,
but then, I'm a queuing theory freak and anything named after one of the
pioneers is going to get my attention.

[Armin Rigo]

Hi Tom,

[...] Python, Ruby, Perl and Javascript [...]
These languages won't give up their individuality yet,

And I certainly hope that they never will.

http://codespeak.net/pipermail/pypy-dev/2007q1/003607.html

[The context is a discussion of static soft type inference of dynamic
languages, which would be compiled to two versions of code ("fast" and
"fallback"), an approach supported by LLVM guru Chris Lattner. In that
mail I contrast it with the very different approach that we've taken in
the PyPy project.]


A bientot,

Armin

[Tom Novelli]

Post by Armin Rigo
Hi Tom,

[...] Python, Ruby, Perl and Javascript [...]
These languages won't give up their individuality yet,

And I certainly hope that they never will.

I guess we're entering the political realm now... I'll try to tread lightly....

Without competition there is no progress, that's for sure. The
one-language concept is useful for explaining Tunes to the lay person,
but it does sound a little communistic. The British/American
two-party political system is a better model (people who dislike the
status quo can join the other party, and a third party only becomes
viable when people abandon the first party). Sadly the situation in
computing resembles a fragmented European democracy where there is no
clear winner, nobody really cares except for those who are part of the
mess, and nothing gets done!

Post by Armin Rigo
http://codespeak.net/pipermail/pypy-dev/2007q1/003607.html
[The context is a discussion of static soft type inference of dynamic
languages, which would be compiled to two versions of code ("fast" and
"fallback"), an approach supported by LLVM guru Chris Lattner. In that
mail I contrast it with the very different approach that we've taken in
the PyPy project.]
A bientot,
Armin

Ok, that gives me some projects and technical issues to look into (you
can see my list at http://tunes.org/drafts/other.html). This is
basically the old Review project, but we're not making another list of
2000 toy languages :-)

I understand the fast/fallback approach... As for PyPy, the FAQ needs
work... let's see if I understand: You're profiling and JIT-compiling
the hot spots... The profiler tracks data types, and you just compile
native code for whatever types happen to be used most. And this was a
new approach when you did it with Psyco, made possible by efficient
profiling techniques. Correct?

- Tom

[Armin Rigo]

Hi Tom,

Post by Tom Novelli
I understand the fast/fallback approach... As for PyPy, the FAQ needs
work... let's see if I understand: You're profiling and JIT-compiling
the hot spots... The profiler tracks data types, and you just compile
native code for whatever types happen to be used most. And this was a
new approach when you did it with Psyco, made possible by efficient
profiling techniques. Correct?

I'm aware that it's quite undocumented yet for PyPy (we need to write a
technical report within a month). No, that's not how it works; my point
is that there is no Python-specific profiling code tracking the Python
types and producing corresponding native code. The technique is
language-independent. I'm still not managing to summarize it concisely,
though :-( I can only refer to the paper and slides for Psyco at
http://psyco.sourceforge.net/doc.html ("How does it work?" section).

PyPy itself contains a generator that produces a JIT compiler in the
style of Psyco, automatically, from a Python interpreter (which plays
the role of a formal language specification in this context). In other
words, just tweak the interpreter or replace it with an interpreter for
whatever other dynamic language you like and you get a JIT compiler for
free. (Somebody is busy writing a JavaScript interpreter in our
framework, for example.)


A bientot,

Armin.

[Tom Novelli]

On 3/22/07, Armin Rigo <***@tunes.org> wrote:
...

Post by Armin Rigo
PyPy itself contains a generator that produces a JIT compiler in the
style of Psyco, automatically, from a Python interpreter (which plays
the role of a formal language specification in this context). In other
words, just tweak the interpreter or replace it with an interpreter for
whatever other dynamic language you like and you get a JIT compiler for
free. (Somebody is busy writing a JavaScript interpreter in our
framework, for example.)

I've noticed this, and the Prolog front end, lazy evaluation, the
possibility of a persistent object store... PyPy is beginning to sound
a lot like Tunes. Impressive! (except for the 1-hour build time...
is that still true? I have yet to try this beast for myself)

Someone needs to write an "executive summary" of those Psyco slides
(and/or the source)... Maybe I'll give it a shot... I'd like to get
involved in this project if I can find the time. Python has been very
good to me :-)

Tom

[M. Edward (Ed) Borasky]

Post by Tom Novelli
New major versions of Python, Ruby, Perl and Javascript are in the
planning stages, probably for the next 2-4 years. They're all talking
about static typing, native compilation, real GC, and so on -- and
borrowing heavily from one another. These languages won't give up
their individuality yet, but a "common core" is entirely possible.
This has the potential to make TUNES a reality, in large part. If we
do our homework, this could be an opportune time to weigh in.

There are three "existing" common cores, and all three were represented
at the Ruby implementors' summit. They are the Java Virtual Machine (now
GPL, IIRC), Microsoft's Common Language Runtime, which I think is still
proprietary, and Parrot, which has some open source license but I've
forgotten which one. As I noted in my blog post, I think Parrot is a
long shot -- unless they get some industrial-strength support and soon,
we'll get to watch a phenomenon described aptly by Damon Runyon: "The
race is not always to the swift, nor the battle to the strong -- but
that's the way to bet!"

I personally don't like virtual machines. We have over five decades of
evolution of hardware, architectures, compiler technology, operating
system technology, language design, theoretical computer science, etc.,
under our collective belts and *still* people find it necessary to put
one extra layer between the user and the solution to his problem -- an
"ideal virtual machine" that "simplifies" the porting of software from
one type of hardware to another at the cost of speed of execution.
*Real* users have *real* problems, so they need *real* machines!

At the language level, I think there already is a common core. And I
think it's Smalltalk. At least that's the impression I get from hanging
out with Ruby hackers -- they seem to think Ruby will be Smalltalk when
it's done. :) I'm not sure there's a common core at the OS level yet --
the Windows kernel and all the Unix-alike kernels are fundamentally
different in a number of non-trivial ways. So that's the level where I
think there's the greatest opportunity for innovation -- a microkernel,
if you will, that can efficiently support Windows and Unix. To some
extent, the Xen hypervisor with the Intel hardware assists is close, as
is some of the work related to Dresden's DROPS project.

[Robin Green]

On Tue, 20 Mar 2007 08:44:19 -0700

a microkernel, if you will, that can efficiently
support Windows and Unix. To some extent, the Xen hypervisor with the
Intel hardware assists is close

but paravirtualisation is closer:

http://lists.xensource.com/archives/html/xen-users/2007-02/msg00545.html

Intel hardware-assisted virtualisation isn't as efficient as
paravirtualisation (at least for Linux, and I have no reason to think
Windows would be any different).

[Massimo Dentico]

On Tuesday, March 20, 2007 4:44 PM

Post by M. Edward (Ed) Borasky
..
I'm not sure there's a common core at the OS level yet
-- the Windows kernel and all the Unix-alike kernels are
fundamentally different in a number of non-trivial ways.
So that's the level where I think there's the greatest
opportunity for innovation -- a microkernel, if you will,

Please, read here:

http://tunes.org/wiki/No-Kernel
(click on "object": nothing to do with OO)

http://tunes.org/wiki/Microkernel_Debate

http://tunes.org/wiki/GO%21

http://tunes.org/wiki/Multipop

http://tunes.org/wiki/Genera


Hey, this is not his fault, most of the nodes
are hidden somewhere. I'm literally cursing..
I have difficulties to retrieve my own contributions!

This because listings in categories were lost
in translation from Cliki to MediaWiki.

On our old wiki

http://tunes.org/wiki/Main_Page

if you see something like, for example:

/("paradigm" :attribute :topic :match :exact)

here

http://tunes.org/wiki/Programming_Languages

it is a listing of nodes in category "paradigm"
in our old Cliki.

I had started with a manual conversion, some times
ago, but there was a problem, an interference between
categories and redirections (if you come from a redir,
it not shown the listing of nodes in such category
at the bottom of page). So, I gave up.

If someone has suggestions.. please, speak now!

Post by M. Edward (Ed) Borasky
that can efficiently support Windows and Unix.
..

ARGH! Both stratification of crap over crap.
I'm dreaming liberation from these nightmares
even before coming to TUNES.


Regards.
--
Massimo Dentico