Re: intent to package: mocka modula-2 compiler
On 31 Aug 1998, Christian von Roques wrote:
roques>John Lapeyre <lapeyre@physics.Arizona.EDU> writes:
roques>
roques>>
roques>> >>It's possible to find simple bugs in the generated code, but it's not
roques>> >>possible to develop further without BEG.
roques>
roques>I've maintained Mocka from 1991 to 1995, and there were no significant
roques>changes since 1995.
The upstream package, or debian ?
> The above statement is true, you can find and
roques>analyze simple bugs using the generated code, if you know how BEG
roques>works and have read the .beg specification of the generated backend.
roques>But fixing them is probably not feasible for most of the usual bugs.
roques>
roques>> Good News: The author says he can contribute a C version of BEG.
roques>> I will get this as soon as possible. I already asked how free it is. In
roques>> any case, I think it is a good development.
roques>
roques>I agree, that it would be good if the source of BEG would be
roques>available, but I still can remember how difficult it has been to get
roques>Helmut Emmelmann's permission to distribute a i386-Linux-binary of
roques>BEG. [Helmut Emmelmann is the author and owner of BEG]
roques>
roques>It is not clear what is meant by `C version of BEG'. BEG is written
roques>in Modula-2 and this source can be converted to C. If this is meant
roques>by `C version of BEG', it probably is not [yet?] legal to distribute
roques>it. On the other hand, BEG usually generates backends in Modula-2,
roques>but there exists a modified version of BEG generating backends in C.
roques>If this is meant by `C version of BEG' it might be possible to
roques>distribute this as an executable.
The phrase is just as the author,
Thilo S. Gaul <gaul@ipd.info.uni-karlsruhe.de,
said it . I am confused as well. But I imagine he will clarify it.
I would reproduce his note, but maybe that's not polite.
roques>
roques>> Another point. The same group has a free Modula-2 to C
roques>> translator, which apparantly works well. I have built it, but not tested
roques>> it yet. I will package it when I get a chance.
roques>
roques>mtc is free and part of the free 1992 release of Cocktail. It is a
roques>good translator of correct Modula-2 to C. Due to its lack of
roques>correctness checks, it is not really usable as Modula-2 development
roques>environment.
I don't know anything about modula. Please advise me on anything I
upload.
roques>
roques>It would be good, if you'd package not only mtc, but all of Cocktail,
roques>probably with mtc in a separate package.
Right, that is exactly what I had thought. I have a cocktail
package finished. But when trying to make the mtc package, I noticed that
there are some binary files 'Scanner.tab', etc. which apparantly cannot be
generated from the source, and there is no info on where they come from.
I guess I could still upload mtc and cocktail, but only to non-free. Do
you know anything about this ? It annoyed me to discover it at the end
of the packaging and I dropped it. It seems like it may be a good package,
I'll finish sometime.
roques>> One more note: They like to invoke it with "mc". It was pretty
roques>> funny to see one of their scripts invoke midnight commander. I changed to
roques>> MC for no good reason. Is that reasonable? mmc , or Mc perhaps ?
roques>
roques>I'd suggest `mocka'. One doesn't have to type it very often, so the
roques>length of the name is no problem.
I think I'll go with 'mocka'.
I also packaged m2c by Vladimir Makarov. Do you know anything
about this ? I noticed that extensions and calling conventions are quite
different, among these compilers. Perhaps even the library is not
standard. Is this correct ? (I didn't have time to look too closely). m2c
can produce c code, or produce the final binary. I am noticing, that
modula compilers seem to get and use dependency info from the source.
m2c handles this ok in the examples. It looks like one has to use an
auxilliary program with mtc to generate a makefile with the proper
dependencies written in , to compile the translated C code.
John
John Lapeyre <lapeyre@physics.arizona.edu>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre
Reply to: