Re: [Oopic-compiler-devel] Hello from the new guy

[Neil D. <nd...@us...>]

Brian wrote:
> Neil asked me to introduce myself as the new guy...there's not much to
> say, other than my programming background is mostly in algorithms and
> signal/image processing, with a smattering of languages (C++ and Perl
> are my faves, though).  My interests in this group lie mainly with a
> port that will work under *nix and Mac OS X.  I currently run the
> OOPic IDE under wine, but I would prefer something a bit more stable!

Welcome to the group!

> --There's been talk of writing code to support several different
> platforms, including DOS, Windows, Linux, and Mac OS.  Is it the
> group's goal to write a replacement IDE/compiler, or to make the OOPic
> accessible to platforms not currently supported?  I'd be mostly
> interested in helping with a port that runs on a platform not
> currently supported... 

I think each of us have our own reasons.  However I think the most
fundamental reason for this project is that the only available compiler for
the OOPic is closed-source and there is little chance of much development
in that area from Savage Innovations.  So getting bugs fixed, better
language support, and support for non-Windows platforms are all pretty
remote hopes.

Writing a new, open-source compiler means that if someone has a need, for
example to run it on some obscure BSD operating system, or if they want an
OOPic compiler for a language other than C/Java/Basic, it can be done
without too many headaches.  It opens up the possibility of each of our
various personal interests becoming a reality.

My own interest is primarily to provide a good solid OOPic compiler that
runs under Linux.  I also have a Mac PowerBook, and would love the compiler
to run on that too.

My other interests are in improving language support, so that we can use
more standard C syntax, we can declare arrays which work in EEPROM (but use
standard C syntax), we can use #includes etc.  Once you decide to write a
new compiler, loads of opportunities appear for language improvements.

The other thing is that we're currently focussing on the compiler aspect,
which is currently only available as a closed-source product.  Along with a
good programmer's editor and a code uploader, it's basically all you need
to develop for the OOPic on any platform we can support, so in doing the
compiler we open up the OOPic to people on all those platforms.

Actually speaking of a code uploader, it would be nice to have one that
work on different platforms, and that could use either parallel or serial
SCP for program uploads.  Should we develop one of these too?

Perhaps later on we'll look into creating a cross-platform IDE that doesn't
crash and doesn't rely on VB!

> --I noticed the consensus is to use C for this project.  While I'm
> comfortable with that, won't this become something of a maintenance
> nightmare to support several different platforms?

It shouldn't be.  Remember, this is only for the compiler, which takes in
one or more text files, and outputs a binary file and perhaps a text file
or two.  No user interface beyond a few command-line parameters!!  These
are things the C Standard Library can handle, and targetting different
platforms should be easy, and perhaps trivial.

It also means we can ship a single executible file if we want to, with no
dependencies or fancy installer required.

> Has any consideration been given to writing some or all of this project
> in a truly portable language such as Python?  There are several Python
> parser generators available (http://www.python.org/topics/parsing.html)
> that would make porting to different platforms a snap

It's worth considering, definitely.  Although we all agreed on C pretty
quickly, there wasn't much discussion about alternatives.  I don't know
Python, but I've looked at it a little in the past and it's one of those
languages I've wanted to learn for a while.

It would certainly make cross-platform support easy, as you say.  However,
some points against might be:

1) How many of us know Python well enough to embark upon a compiler-writing
project?

2) We would presumably require end-users to have Python installed in order
to run the compiler.  This shouldn't be a problem, but it would complicate
matters from an installer point of view.

I'd be happy to go down the Python route if that became the general
concensus, but I think there'd be a bit of a learning curve involved.  I
can imagine some of the features Python has over C such as OO support,
powerful containers such as hashes, queues, lists etc, would make some
aspects of development considerably easier.

I'd be interested to hear Andy's/Daniel's thoughts on Python.  I think it's
a very interesting idea, and could certainly be beneficial, once we're over
the initial learning curve.

> ...and would ease the support for several GUI front-ends (there is Python
> "glue" for many GUI libraries, including Mac's native libraries and a
> number of libraries, such at GTK+).  Work on a GUI front-end could be
> done pretty much independently from the parser/compiler/loader once an
> interface has been designed; working in parallel on the front end and
> back end would really save time and effort.

Well at the moment, as I say, we're focussing entirely on the compiler,
which should ideally be a command-line driven tool that anyone can use with
any editor, IDE or whatever.  So I don't think the advantages gained by
having cross-platform GUI toolkits available really counts for the
compiler.

Having said that, using a language that supported (or had libraries for)
useful containers on different platforms could certainly be beneficial.

However if/when we were to develop an IDE, then Python could certainly be a
strong contender.  We would definitely have to use a language where there
was a strong cross-platform GUI toolkit available.  Some contenders might
be:

* Python
* Java
* C++ with the QT GUI toolkit (runs on Win, *nix, OSX)

> Hope no one take offense to these observations...I'm willing to help
> with whatever I can.  

Not at all, we're all friends here and all ideas are worth airing and
discussing.

Neil
-- 
Neil Durant
<nd...@us...>