Mozart development

[Torsten Anders]

Dear Filip,

On 08.02.2007, at 12:32, Filip Konvička wrote:
> Hi Torsten,
>> Dear all,
>> As you know, the core Mozart development cooled down somewhat. On the  
>> other hand, we have now the infrastructure for a community-driven  
>> development (e.g. developers can register at  
>> http://gforge.info.ucl.ac.be/projects/mozart/ and the MEP scheme  
>> controls the language development).
> I think that there is no urgent need for core development. However,  
> there are some core-level bugs that need attention, and the lack of  
> core developers/hackers activity is a problem here. I'm afraid that  
> the people that could fix these are involved in other projects and  
> eventually will forget how "it worked" (or how "it should have  
> worked"). So I can't miss this opportunity ;-) to urge whoever thinks  
> he understands the stuff to at least make some comments for future  
> adventurers.
>
> Then again, maybe porting to 64 bits could be considered needed and  
> core-level....but I don't know whether it is more development than  
> hacking.

I certainly did not question that Mozart is a mature platform as it is.  
But as you suggest yourself, software is largely a service instead of a  
ready-made product (cf.  
http://www.catb.org/~esr/writings/magic-cauldron/magic-cauldron.html).

> By the way, while I'm still knee-deep in my project, I'm still  
> planning to fix stdio processing on Windows (and I think there's  
> something wrong with pipe processing, too).

Thanks!

>> - Unicode support: e.g., http://www.snowlion.nl/mozart/ and  
>> http://www.mozart-oz.org/mogul/info/fkonvick/unicode.html (I may get  
>> back to people like Maarten van den Dungen and Vladimir Zykov who  
>> were very much iinterested in Unicode support for Mozart and offered  
>> their help -- without much response at a time when Mozart development  
>> was still rather closed)
> I would hesitate to call my contribution "Unicode support" :-) because  
> it is in fact a bunch of functions that do utf8 --> ucs4 and ucs4 -->  
> cpXYZ. But then again, what else do you need :-) lol

;-)

>> An important but somewhat hard question is this: how can the  
>> development of individual Oz contributions be maintained by the  
>> community? In particular, how are orphaned Mogul packages maintained?  
>> For example, ozh  
>> (http://www.mozart-oz.org/mogul/info/franzen/ozh.html) still supports  
>> only Mozart 1.2.5. Filip Konvicka provided a patch for 1.3.*  
>> (http://lists.gforge.info.ucl.ac.be/pipermail/mozart-users/2006/ 
>> 008016.html), but that patch hasn't been merged into the ozh Mogul  
>> package.
> I've been thinking of this too. I tried to contact the author of ozh  
> but I think he is not reachable at the original address anymore, so I  
> thought of creating a clone contribution "ozh2". What do you think of  
> this?

I think this is a general problem. Starting an ozh2 where you are the  
author is quasi a 'hack' which only solves an immediate need. Taking  
over maintainance of ozh would be another solution. But both options  
are probably too much for an occasional patch.

Would it perhaps be a good idea to move some or even all Mogul packages  
over to gforge.info.ucl.ac.be and allow registered developers to fix  
things? To avoid any irritation, we may introduce a distinction between  
individually maintained Mogul packages (the only approach so far), and  
packages maintained by the community. The author may decide whether  
she/he permits community maintenance. The problem remains for packages  
whose author does not respond. In that case, we may consider starting a  
community branch (e.g. ozh2).

What do you think?

Best,
Torsten

--
Torsten Anders
Sonic Arts Research Centre • Queen's University Belfast
Frankstr. 49 • D-50996 Köln
Tel: +49-221-3980750
http://strasheela.sourceforge.net
http://www.torsten-anders.de