Dr. Thomas Tensi <t.tensi@[EMAIL PROTECTED]
> wrote:
> Hi all,
>
> I am not sure if this is the right place to post since
> obviously all discussions about Modula-3 are now happening
> in the developer lists at Elegosoft.
This newsgroup has never been very active, even in the old
days when there were several hundred people using M3
around the world :-)
> Nevertheless I post here because I have had the
> misconception that no further development is going on for
> Modula-3 as there were no announcements or discussions in
> this newsgroup. This also led me to do some duplicate work
> because I didn't know about other people contributing.
Well, there has been some lack of official releases and
announcements, but there are some active projects going
on. I hope that we will be able to produce a new CM3
release within the next weeks which includes all these
additions.
> Is this split of discussion really intended? When does
> one post into the developer forum at Elegosoft and when
> into this newsgroup?
Good question ;-)
> Currently I am working on enhancing the current CM3
> distribution for Windows and have some questions:
>
> - I have developed VBScripts as replacements for the
> standard Unix scripts do-*-cm3.sh. Now I have noticed
> that Randy Coleburn and Jay Krell have already done
> CMD-files for that independently (but I had my stuff
> completed by then, see above).
>
> My implementation consists of VBScript "modules"
> (=fragments) with defined interfaces which encapsulate
> services and are automatically linked into scripts for
> the windows scripting host engine. I tried to capture
> the modular spirit of Modula-3 in them.
>
> The advantage of this technique is that the standard
> windows approach to scripting is used and by that the
> scripts are also easily extensible towards graphical
> user interfaces. The VBScript language is quite
> expressive and those scripts can be debugged with
> standard windows tools.
>
> Is anyone interested that I add them to the CM3 file
> tree?
If it's useful you should add it to the tree (in a separate
directory). I don't know about VBScript and haven't used
M3 on Windows for some time, so I cannot really *****s
its value.
> - I am trying to set up a simple no-brainer installation for
> Windows based on the freely available Visual C toolkit
> (where Jay Krell has already done some significant work
> on). Part of it is setting up the cm3.cfg file.
>
> What is the concept of change for this file?
> o Is it configured initially and then left untouched?
> o Is it typically configured manually?
> o Is it even set up specifically for each project?
Usually it is configured initially by the installation program
and then extended or changed manually from time to time (if you
install more packages or libraries, for example). It should
not be touched very often though I think.
> My idea is to have an installation script generate this
> file semi-automatically with more or less user
> intervention. But this might not be in line with the
> typical Unix usage pattern...
>
> By the way: should we drop the configuration stuff for
> Reactor from it (as long as it is not available)?
I hope that Reactor will be part of the next release (though
not under this name).
> - The Trestle implementation for Windows is a bit flaky.
> Randy told us in some post from 2003 that he had
> "polished up" that ****t and might be able to contribute
> the sources.
Yes, it would be great if somebody could improve the Windows
Trestle implementation. I'd also appreciate work on any
other aspect of the Windows platform (including readdition
of the NT386GNU target).
> Does anyone know about the status of that?
Perhaps you should indeed post this to the devel list, too,
in order to get more answers ;-)?
Olaf
|
