Re: [DotGNU]Dotgnu written in C#?

[James Michael DuPont]

Legal Disclaimer :

I do not claim to be speaking for the DotGnu or GNU Project. The views
expressed here not to be taken in any way other than just being an
individual opinion.

I am not "out to get GNU" and is not trying to "conform GNU".

I may, on occasion give suggestions and/or advice, but in no way is the
reader obligated to follow the suggestion and/or advice -- I do not
claim to be counselor or authoritive on any level.

Basically, I am just speaking for myself, not DotGNU or the GNU
project.

--- DrDiettrich <address@hidden> wrote:
> Rhys Weatherley wrote:
> > The goal of pnetC is to be able to run any arbitrary ANSI/Posix C
> code on top
> > of the CLI in bytecode-compiled form.
> 
> This is fine, but...
>  
> > There are literally thousands of interesting Free Software
> libraries written
> > in C that can be leveraged once we have the basic platform in
> place.  Much
> > more than C#, VB, Java, etc can provide on their own.
> 
> I found serious problems with GNU/FSF software, which I would like to
> discuss now. 

I love it. I am not he only one with problems.

> the FSF, for defending the freedom of source code, the actual
> procedures
> unfortunately restrict the use of just that freely available source
> code
> to specific platforms. At least has an author the right and chance to

Yes. That is one way to look at it. 


> If you think that source code and a compiler is sufficient to really
> create running programs, then you certainly never tried to build even
> the simplest GNU program on a non-Unix system :-(

I wound not go so far. Pnet builds on many many systems. You can build
it on windows, and many other non-unix systems, with the right tools.
I think these make and autoconf tools are pragmatic and not meant to
make more dependancies, the source code to them are all available. You
can compile bash on any platform.

> 
> 
> 2) Before the compiler can produce object code, the sources must run
> through the preprocessor. In this stage any number of dependencies
> and
> modifications can be introduced by #defines and #includes. In most C
> projects it's near impossible to figure out, which code really will
> be
> compiled, without inspecting the output of the preprocessor.

You need better diagnositic tools? include2dot is one.
Otherswise -save-temps when compiling helps alot.

> 3) Before the preprocessor can run, some source files must be
> configured, and the #defines for the preprocessor must be defined.
> With
> enough dependencies it's almost impossible to determine a working
> configuration manually.

This is a very pragmatic system. the configure scripts are painful but
useful.

> 
> 4) The source processors are called from make, based on Makefile(s).
> These files also can contain references to other programs, which may
> report errors and stop the whole build process.

that is true.

> 
> 5) The host and target platform specific settings must be determined.
> Since the user cannot do this himself, without appropriate
> documentation, ./config must be used to evaluate the environment(s)
> and
> create the makefiles and the according settings. Unfortunately config
> has some fixed opinions about platforms, and consequently will deny
> service for totally or partially unknown platforms, like Windows.

use cygwin. www.cygwin.com

> In practice every step will fail on the first try, unless the project
> has been extended to properly work on a specific host/target
> combination, and the user has set up his system with all (really?)
> required tools and libraries of the appropriate version.

use cygwin. www.cygwin.com


> This is why I consider the currently available "free" software to be
> not
> really free, in contrast this software is bound to a specific but
> unspecified environment. And what's worse, software which is written
> only for a specific platform, or software which is written for an
> unspecified platform? :-(

The software is truly free, It has been ported many times to many
plaforms.

> IMO all of the steps above the mere compilation should be eliminated
> from a really free software project.

Do you know FrankZappa song, Free as the wind?
http://www.science.uva.nl/~robbert/zappa/albums/You_Are_What_You_Is/01.html

FREE IS WHEN YOU DON'T HAVE TO
PAY FOR NOTHING
OR DO NOTHING
WE WANT TO BE FREE
FREE AS THE WIND


> All dependencies between code
> modules must be described in a compiler and platform independend way.

they are. The compile just does not tell you about them.


> This is why I vote for a (new?) Integrated Development Environment,
> which replaces the current config-make-install chain, and most
> pertaining tools. 

Great. Join the introspector.sf.project and help out.


> I also vote for an (automated?) translation of existing C projects
> into
> C#. 

A good step in that direction would be the extraction of all this
information from the compiler? The extraction of this information from
bash, from make, from m4? 

What if you could translate all these config and makefiles into an
intermediate language that was unified into an IDE. With a
visualization toolkit, IDE hooks, and an Import and Export routines.

Also a proof engine for appling rules and patterns to the existing
code, users and developers can add in new patterns that will transform
idoioms into explicit statements.

All of these tools can be built on top of the existing tools, because
they are free. The introspector aims at building interfaces to the free
software tools in order to make them more user friendly, but also
remain compatible. Rewriting everything makes no sense.

>Then the better error checking features of C# (or at least C++)
> can
> be used to comb out some lurking bugs in many projects, and the
> resulting source code will be really platform independent. Let pure
> or
> extended C code die away ASAP, in favor of more stable, portable and
> bugfree software!
> 
> BTW, by the migration of C code to C++ or C# I don't mean necessarily
> introducing classes and other OO stuff. In contrast I mean the
> elimination of typecasts and #defines and #ifs as far as possible, in
> general all provisions which allow an compiler to check the source
> code
> in the best possible way. A migration to C++ will allow to still use
> gcc
> for the creation of native executables, if this really is a
> requirement.

I think c# is nice, but what you want is the introspector.

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com