[Gd-hackers] A Dylan based RTOS as Pilot Project to establish a OD

[Peter Robisch]

> Andreas Bogk:
> At the moment, we hope to find somebody to build a business
> on the IP stack we're working on, and sponsor development from that.

Good to hear that you, Andreas and I think Hannes, are working on such a
project which will enable the Dylan community to search for sponsors. 

The intention of my mail was to discussing some ideas how to win sponsor for
the Dylan community. My suggested "pilot customer" was

>      RTOS software vendors as QXN. 
>      (RTOS real-time operation system)
>      QXN's RTOS is currently C-based, but 
>      why not in the future Dylan based?

Andreas Bogk's response was:

>  Two issues here.
>  First: our GC isn't real-time yet, so hard real-time, which 
>         is the target customers of QNX, is out of the question.
>  Second: I don't think they would be interested in throwing 
>          away QNX. Their customers pretty much depend on 
>          the infrastructure

Let me comment on your response:

I would not try to sell a real-time framework to RTOS specialist like QNX.
Real-time stuff is their competence not ours. Instead I see that their RTOS
is C based with all the deficiencies a C-based code compared to Dylan one
will have related to OS engineering. (I think the Dylan community has
profound specialist to explain in detail. :-) ). First we would sell the
elegance of the language and the code. 

After warming them up for Dylan, we could try to sell a current project. For
example Peter Housel's CPR (C Program Representation) Project is a good
candidate, as it will allow them to integrate their existing C code smoothly
to a new Dylan environment. 

What you describe as issues are in my view aspects we have to consider in
work out a roadmap that we will present to them. So we have to restate the
issues as aspects to consider, for example, in this way:

* First: How is the current GC API prepared to support a real-time GC?
         Which code would require a reengineering to support the 
         requirements of a real-time GC?

* Second: How can we show that moving to Dylan can be done in a smooth way
         that would not require that their customer have to throw away old
         code at once. 

Working it out further "How do we pitch Dylan to RTOS vendors?" is a task
which could be supported by several community members. May be we can
reactive ex Dylan people for this. Related to your stated issues it would be
helpful to get a comment
* from Ravenbrook 
  http://www.ravenbrook.com/project/mps/master/manual/wiki/gc.html 
* or other ex Dylan people like : Ian Piumarta
  http://www-sor.inria.fr/~piumarta/cv/index.html 

Winning those and other to preparing Dylan roadmaps would be a great help
for the Dylan community. IMHO it would be good if we present roadmaps to
potential contributors. If we can present profound roadmaps this would be
even better.

The current tasks are much simpler. As Hannes Mehnert wrote in one of his
mails:

 * website renewal (I like the new python.org website)
 * library unification of opendylan and gwydion (as far as possible)
 * repository cleanup (trunk/fundev => opendylan, trunk/src => gwydion)
 * start of gtk2 backend for DUIM
 * documentation

Related to the point "website renewal": I like the subversion website. It
provides navigation to a "roadmap" side:
   see http://subversion.tigris.org/roadmap.html 

I like to see something similar on the Dylan community website. Why do we
not integrate a "roadmap" namespace into the wiki. But this I idea I will
explain in another mail during the up-coming week.

Greetings

  Pet-ro