<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Arg.<BR>
<BR>
<BR>
Change does not equal instability.<BR>
Status quo does not equal better.<BR>
<BR>
Do you want 64bit LONGINT? Maybe, maybe not.<BR>
<BR>
Do you want every integer comparison to needlessly use a temporary on the stack and extra instructions?<BR>
Maybe, maybe not.<BR>
<BR>
Do you want the tables in hand.c statically linked?<BR>
Maybe, maybe not.<BR>
They caused quite a headache albeit<BR>
briefly, when we weren't statically linking them. Standalone apps worked fine, dynamically<BR>
linked exhibited odd behavior. The odd behavior was "just" gui drawn incorrectly, but was actually<BR>
indicative of deep problems.<BR>
<BR>
Do you want dead buggy code sitting around, waiting to be silently used as m3front changes?<BR>
(e.g. some forms of extract look wrong).<BR>
<BR>
A giant lock in ThreadWin32? vs. the simple pattern documented on the web and what Java uses?<BR>
Granted, I removed the threadpool, maybe too much simplicity and not enough efficiency?<BR>
(But have you noticed how much ThreadWin32.m3 did churn through the years anyway?)<BR>
<BR>
Can you point to actual bugs?<BR>
Granted, I don't have specifics in many cases either, such as the bad perf of the giant lock,<BR>
but everyone knows about them.<BR>
The system builds itself. I probably rest too much on that, granted.<BR>
m3-sys/m3tests does pretty well (some stuff does need looking at).<BR>
I try to add more test coverage when I make changes, but I am lazy, granted.<BR>
<BR>
<BR>
Some non-zero level of progress is presumably desired.<BR>
The Unix interface was painful to maintain and buggy and tended toward unsafety but claiming safety.<BR>
It is much improved now. Much safer, much easier to port. A little less efficient. Sort off less<BR>
amenable to cross building, though really hand.c and lack of an assembler and linker are enough to kill cross builds.<BR>
The system has never as far I know been really cross buildable, without gcc/binutils support -- has<BR>
always needed an assembler and linker, and usually needed a C compiler. (NT386 doesn't need an assembler).<BR>
<BR>
<BR>
Just because interface Unix allowed for compiling more code in the past did not make it better or more correct.<BR>
In fact possibly the opposite. Granted, we should try have it all -- correctness, features, maintability, efficiency.<BR>
There was a lot of cruft in there getting copied from port to port without being revisited.<BR>
Stuff having to do with Linux 1.x was in various ports.<BR>
Every major version of FreeBSD implied extra work. We had FreeBSD, FreeBSD2, FreeBSD3, FreeBSD4.<BR>
(There are still problems here actually, FreeBSD7 64bit I believe broke the ABI in networking,<BR>
and we still have the related structs I think -- there is still bad stuff in interface Unix, just<BR>
a lot less now. I still want to whittle it down more.)<BR>
<BR>
<BR>
There is still code in the system that redeclares struct tm incorrectly, attempting to workaround<BR>
interface Unix deficiency, when in fact interface Unix was correctly limited (the fields at the end,<BR>
and perhaps the order of the fields). In the web browsers as I recall (which never seemed<BR>
to work much in the first place, but they did/do build and come up).<BR>
<BR>
<BR>
> > agnostic intermediate form targeting a JIT.<BR><BR>
<BR>
Other than NT386, our portability rests on gcc and Posix, which are very portable<BR>
with very little effort. I haven't seen any JIT that is as portable.<BR>
<BR>
For example there are a few systems we can't run Hudson on because it uses Java.<BR>
e.g. MIPS64_OPENBSD, PPC32_OPENBSD <BR>
I would actually like to generate C to gain even more portability.<BR>
Granted, JIT has the nice property of target-independent distributable binaries.<BR>
"Package building" matrix could be cut down.<BR>
<BR>
Generating C can get you target-independent source distributions, as most things use.<BR>
(Granted, compilers are somewhat special, except that the world long ago<BR>
got past not having a C compiler).<BR>
<BR>
<BR>
Targeting a JIT will probably be way more work than anyone has put into this system in over a decade.<BR>
Still, not a bad idea. It lets you reuse other people's code generators similarly to how we reuse gcc.<BR>
<BR>
<BR>
Java has been made portable to any processor, running Linux.<BR>
But not yet to other operating systems.<BR>
<BR>
<BR>
I think without too much work, we could use our exiting IL that parse.c reads.<BR>
It'd just need more context in places, to avoid a need for globals.<BR>
You could just write an interpreter.<BR>
It wouldn't be fast, but it would gain more portability probably.<BR>
Probably not the best idea though.<BR>
<BR>
<BR>
Also, the Java JIT, as one example, is among the more portable, and among<BR>
the more difficult to target. It doesn't model a CPU as you might expect.<BR>
It models more so the Java programming language.<BR>
Which includes non-optional safety.<BR>
<BR>
<BR>
You'd have better luck probably with mono/CLR, not sure as to the level of portability.<BR>
Mono is pretty widely ported though.<BR>
<BR>
<BR>
Really though, gcc+Posix provides a huge amount of portability with very little effort<BR>
on our part. The larger work is really obtaining, housing, powering, installing the various systems.<BR>
If you go the C/portable-JIT route, what you really do is you just stop testing<BR>
the various targets, for better and worse, probably perfectly ok.<BR>
Just as nobody tests hello world on every system. They just<BR>
know it works because it is so portable.<BR>
<BR>
<BR> > webcard, postcard, Deckscape and Webscape and m3-mail packages and m3-lectern
<BR>
<BR>
They don't compile?<BR>
<BR>
<BR>
> > rather old release (5.3.1 if memory serves, <BR>
<BR>
<BR>
You can keep using it?<BR>
<BR>
Maybe compare that version to current and see if there are particular problems?<BR>
<BR>
<BR>
> > BTW the version number should figure at a prominent place in every release.<BR>
<BR>
<BR>
cm3 -version?<BR>
<BR>
<BR>
As to where Tony and I should argue, well, that's not a generally answerable question.<BR>
I find that a conversation involving just two people not ideal, no matter who they are.<BR>
Being under outside scrutiny increases civility, sometimes add more than two opinions, etc.<BR>
<BR>
<BR>
I grant that m3 is such a small community that we don't have an m3-users vs. m3-devel group,<BR>
and m3-devel is woefully small, and the two groups a bit inappropriately mixed.<BR>
<BR>
<BR>
- Jay<BR> <BR>> Date: Sun, 14 Mar 2010 01:54:41 +0000<BR>> From: dabenavidesd@yahoo.es<BR>> To: m3devel@elegosoft.com; dmuysers@hotmail.com<BR>> Subject: Re: [M3devel] bandwith<BR>> <BR>> Hi all:<BR>> I think is an interesting topic, however I disagree with you in the old version mentioned because since then CM3 has evolved a lot in threading, garbage collection and gcc based backend packages, just to name a few.<BR>> I however seem to recall some discussions, but unfortunately there wasn't sometimes an ending point (i.e my discussion), however without more participation it really becomes boring at one point I expect to be fully honest I do have fun compiling things but probably the community lacks more understanding of the system itself or of the current issues to work in that which needs to be done. Track system by itself is great but probably we haven't used yet in its full potential and that's the reason I waited for so long to report things that would be useful before in ticket trac system (nor I did have the idea to ask you). Current situation in this matter is going better I think.<BR>> Therefore there could be plenty of opportunities of things to work on in a fashionable way if we may.<BR>> I don't know but I think the current stability should be the worrisome and the history of this could go back to C interfaces and son on. I haven't asked yet where are the Unix INTERFACE constants and members which are need for packages that before where compiling that use this low-level style like browsers webcard, postcard, Deckscape and Webscape and m3-mail packages and m3-lectern which I could get to compile some time before this Unix changes.<BR>> However I know that some bugs they had I expect to be gone because this changes brought many other improvements to overall programming environment.<BR>> Besides this, software engineering tools could be made aware of the project like this one done for pm3:<BR>> http://libresoft.dat.escet.urjc.es/cvsanal/pm3-cvs/index.php?menu=Index<BR>> (the manual of it on http://gsyc.es/~carlosgc/files/cvsanaly.pdf software on http://tools.libresoft.es/cvsanaly?rev=1248394389)<BR>> I know there is also a Modula-3 aware re engineering tools it was done by Peter Klien at Aachen University I know there was supossed to be a working prototype at some point available for download<BR>> http://pi.informatik.uni-siegen.de/stt/23_3/05_Dissertationen/klein.pdf<BR>> This kind of tools could be managed to get integrated with M3clipse plugin work done by Bert Laverman which just lacks semantic analysis, and cm3ide which may bundle cvsup and or dcvs as a way of distributed software configuration management and development environment perhaps with Elego Compact (and don't forget Obliq packages, I remember a Professor told me that it competed at some point with JavaScript to be scripting language for the web. It has even type inference algorithm now so who knows why isn't used in our community, I know I will try to get into it but it needs time; there are some examples in Professor's courses that could help to this, besides other things of M3 system level demo applications too)<BR>> Thanks for your comments I hope this helps a bit<BR>> <BR>> <BR>> --- El sáb, 13/3/10, Dirk Muysers <dmuysers@hotmail.com> escribió:<BR>> <BR>> > De: Dirk Muysers <dmuysers@hotmail.com><BR>> > Asunto: [M3devel] bandwith<BR>> > Para: m3devel@elegosoft.com<BR>> > Fecha: sábado, 13 de marzo, 2010 17:20<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > I don't know if other<BR>> > people have the same feeling, <BR>> > but I think that Messrs. Krell and Hosking<BR>> > should keep their polemics to <BR>> > themselves and let the<BR>> > community partake only <BR>> > in the result of<BR>> > a constructive consensus.<BR>> > <BR>> > <BR>> > As a USER of the m3<BR>> > compiler on windows, I <BR>> > find the recent developments scary, so I prefer<BR>> > to<BR>> > stick to my installed<BR>> > rather old release (5.3.1 if <BR>> > memory serves, BTW the version number should<BR>> > figure at a prominent<BR>> > place in every <BR>> > release.) I am afraid that M3 is going the way of fubar and<BR>> > I<BR>> > am slowly loosing<BR>> > interest.<BR>> > <BR>> > To make it work for all<BR>> > these different platforms <BR>> > seems a herculean task<BR>> > and rather <BR>> > pointless<BR>> > endeavour. Why not use all<BR>> > that energy to <BR>> > try a radically<BR>> > disruptive strategy such as <BR>> > a platform<BR>> > agnostic intermediate form<BR>> > targeting a <BR>> > JIT.<BR>> > <BR>> > Let<BR>> > me apologize in advance to the whole <BR>> > community for the present fit of an old men's<BR>> > anger.<BR>> > d.<BR>> > muysers <BR>> > <BR>> <BR>> <BR>> <BR> </body>
</html>