oopic-compiler-devel

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

[Brian <bri...@po...>]

All--

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!

I've read through most of the archives, and it sounds like you all have
put a lot of thought into this project.  I do have a couple of
observations:

--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 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?   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, 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.


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

  --Brian

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...>

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

[Brian <bri...@po...>]

On Wed, May 26, 2004 at 05:29:26AM +0100, Neil Durant wrote:
> 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?

That would be something I'd be interested in working on!

  --Brian

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

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

Brian wrote:
> On Wed, May 26, 2004 at 05:29:26AM +0100, Neil Durant wrote:
> > 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?
> 
> That would be something I'd be interested in working on!

I guess the SCP side of it wouldn't be too hard - just sending the
appropriate commands to the appropriate serial port.  However the parallel
port side of it would require implementing an I2C master, which wouldn't be
quite so straightforward.

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

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

[D. D. M. <dd...@mc...>]

Hi Brian,

> I'd be interested to hear Andy's/Daniel's thoughts on Python.

I guess that is my cue....

I'm personally indifferent to language choice.  My experience has led to a
somewhat jaded view of the intensity of most of the 'language wars'; and has
shown me all require a mastery of the grammar/syntax and an appreciation of the
applicability of the specific competency of the tool to the application
(remember the adage, when a carpenter has only a hammer, everything looks like a
nail).

I'll be learning a bit about compiler design & code generation whatever the
decisions.

Whatever is done, I think I'd recommend a complete toolkit as the
end-deliverable.  Something like what Eric Weddington did for the AVR
microprocessor with the WinAVR toolkit that bundles all of the required/optional
components (see www.AVRfreaks.net and http://sourceforge.net/projects/winavr).

Why I'm involved:  I am one of those that got burnt by a botched IDE
installation, but mostly am interested in the puzzle of the figuring out the
internals of the OOpic, especially the VC stuff.

Best Regards,
Daniel

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

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

D. Daniel McGlothin wrote:
> Whatever is done, I think I'd recommend a complete toolkit as the
> end-deliverable.  Something like what Eric Weddington did for the AVR
> microprocessor with the WinAVR toolkit that bundles all of the required/optional
> components (see www.AVRfreaks.net and http://sourceforge.net/projects/winavr).

What tools did you have in mind, besides a compiler and possible IDE ?

I guess the cross-platform OOPic code uploader would be one tool.

And one thing I think could be useful would be an assembler that assembles
the Forth-like OOPic op-codes into hex.  It would be trivial to do, and it
could be useful to test ideas before implementing new language features,
and testing out optimisation techniques etc.

Any other ideas?

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

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

[D. D. M. <dd...@mc...>]

What I had in mind was:

	a. The tools the project generates
	b. The tools the project uses to construct (a).
	c. The support environment stuff required for (b).

Thus, given recent discussion, it would include compiler, downloader, IDE (if
generated), source for the previous, Python (for Win, Max, Un*x), *lex, *yac,
etc.  Don't forget to include documentation for all.

The thinking is that the easier it is for a relative novice to acquire/use, the
more wide-spread our toolchain may become.

Of course, there is a maintenance effort to keep track of current releases of
the above.

Best Regards,
Daniel

> -----Original Message-----
> From: oop...@li...
> [mailto:oop...@li...]On Behalf Of
> Neil Durant
> Sent: Friday, May 28, 2004 4:40 PM
> To: oop...@li...
> Subject: Re: [Oopic-compiler-devel] Hello from the new guy
>
>
> D. Daniel McGlothin wrote:
> > Whatever is done, I think I'd recommend a complete toolkit as the
> > end-deliverable.  Something like what Eric Weddington did for the AVR
> > microprocessor with the WinAVR toolkit that bundles all of the
> required/optional
> > components (see www.AVRfreaks.net and
> http://sourceforge.net/projects/winavr).
>
> What tools did you have in mind, besides a compiler and possible IDE ?
>
> I guess the cross-platform OOPic code uploader would be one tool.
>
> And one thing I think could be useful would be an assembler that assembles
> the Forth-like OOPic op-codes into hex.  It would be trivial to do, and it
> could be useful to test ideas before implementing new language features,
> and testing out optimisation techniques etc.
>
> Any other ideas?
>
> Neil
> --
> Neil Durant
> <nd...@us...>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Oopic-compiler-devel mailing list
> Oop...@li...
> https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel
>
>

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

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

Interesting idea.  This would also encourage people to join in with the
development effort, if the 'toolkit' they download contains everything, any
extra tools, all documentation, known bugs (if any!), new features for each
release etc.

The question of whether we ship tools we don't maintain (eg Python if we go
down that route, *lex, yacc/bison etc) is a tricky one.  If someone's
installing our stuff and already has some of those tools installed, do they
use ours or their existing ones?  Plus, how completely would we support
platforms?  If we're shipping platform dependent tools (the Python
interpreter for example, if we use Python) then we could potentially be
shipping a dozen different ones (for different Linux distributions,
FreeBSD, etc etc).

You're right about the maintenance effort, but it shouldn't be problematic
if we're using version control (CVS or whatever).

D. Daniel McGlothin wrote:
> What I had in mind was:
> 
> 	a. The tools the project generates
> 	b. The tools the project uses to construct (a).
> 	c. The support environment stuff required for (b).
> 
> Thus, given recent discussion, it would include compiler, downloader, IDE (if
> generated), source for the previous, Python (for Win, Max, Un*x), *lex, *yac,
> etc.  Don't forget to include documentation for all.
> 
> The thinking is that the easier it is for a relative novice to acquire/use, the
> more wide-spread our toolchain may become.
> 
> Of course, there is a maintenance effort to keep track of current releases of
> the above.
> 
> Best Regards,
> Daniel
> 
> > -----Original Message-----
> > From: oop...@li...
> > [mailto:oop...@li...]On Behalf Of
> > Neil Durant
> > Sent: Friday, May 28, 2004 4:40 PM
> > To: oop...@li...
> > Subject: Re: [Oopic-compiler-devel] Hello from the new guy
> >
> >
> > D. Daniel McGlothin wrote:
> > > Whatever is done, I think I'd recommend a complete toolkit as the
> > > end-deliverable.  Something like what Eric Weddington did for the AVR
> > > microprocessor with the WinAVR toolkit that bundles all of the
> > required/optional
> > > components (see www.AVRfreaks.net and
> > http://sourceforge.net/projects/winavr).
> >
> > What tools did you have in mind, besides a compiler and possible IDE ?
> >
> > I guess the cross-platform OOPic code uploader would be one tool.
> >
> > And one thing I think could be useful would be an assembler that assembles
> > the Forth-like OOPic op-codes into hex.  It would be trivial to do, and it
> > could be useful to test ideas before implementing new language features,
> > and testing out optimisation techniques etc.
> >
> > Any other ideas?
> >
> > Neil
> > --
> > Neil Durant
> > <nd...@us...>
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: Oracle 10g
> > Get certified on the hottest thing ever to hit the market... Oracle 10g.
> > Take an Oracle 10g class now, and we'll give you the exam FREE.
> > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> > _______________________________________________
> > Oopic-compiler-devel mailing list
> > Oop...@li...
> > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel
> >
> >
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Oopic-compiler-devel mailing list
> Oop...@li...
> https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel
> 

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

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

[Brian <bri...@po...>]

On Fri, May 28, 2004 at 10:30:38PM +0100, Neil Durant wrote:
> The question of whether we ship tools we don't maintain (eg Python if we go
> down that route, *lex, yacc/bison etc) is a tricky one.  

I'm not aware of any projects that use Python *and* package Python as
part of the distribution (I've not come across any Perl apps either
that do this).  I believe the way to handle this is to (1) ensure
backwards-compatibility as versions of system tool X change, and
(2) specify a minimum version of support for that system tool.

If you start packaging the system tools as part of the toolkit, it
will make it look like you offer support for those system tools as
well.  That is probably a closed can of worms asking to be opened. 

> If someone's
> installing our stuff and already has some of those tools installed, do they
> use ours or their existing ones?  

That's a road we don't want to travel down.  If we do our part right,
it won't matter what version of tools the end user has installed, as
long as conditions (1) and (2) above are met.

Most *nix users would not stand to have system tools installed, and
would probably resist any attempt to do so.  Personally, I would not
want to install any application or toolkit on my *nix or OS X boxes
that required me to use the system tools as shipped with the app. 

> Plus, how completely would we support
> platforms?  If we're shipping platform dependent tools (the Python
> interpreter for example, if we use Python) then we could potentially be
> shipping a dozen different ones (for different Linux distributions,
> FreeBSD, etc etc).

You can't hold everyone's hands.  The end user must take some
responsiblity for making sure their system tools support the toolkit.
We can help through the installation process to identify deficiencies
a particular system may have, and direct the end user to where they
can obtain the system tools necessary for the toolkit.

  --Brian

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

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

Brian wrote:
> On Fri, May 28, 2004 at 10:30:38PM +0100, Neil Durant wrote:
> > The question of whether we ship tools we don't maintain (eg Python if we go
> > down that route, *lex, yacc/bison etc) is a tricky one.  
> 
> I'm not aware of any projects that use Python *and* package Python as
> part of the distribution (I've not come across any Perl apps either
> that do this).  I believe the way to handle this is to (1) ensure
> backwards-compatibility as versions of system tool X change, and
> (2) specify a minimum version of support for that system tool.

Agreed.

> If you start packaging the system tools as part of the toolkit, it
> will make it look like you offer support for those system tools as
> well.  That is probably a closed can of worms asking to be opened. 

Agreed.

> Most *nix users would not stand to have system tools installed, and
> would probably resist any attempt to do so.  Personally, I would not
> want to install any application or toolkit on my *nix or OS X boxes
> that required me to use the system tools as shipped with the app. 

Agreed - and some people might be suspicious of us distributing things like
Perl or Python or anything like that, which would be picked up and used by
system scripts etc.

> You can't hold everyone's hands.  The end user must take some
> responsiblity for making sure their system tools support the toolkit.
> We can help through the installation process to identify deficiencies
> a particular system may have, and direct the end user to where they
> can obtain the system tools necessary for the toolkit.

I guess we could hold the Windows users' hands - they're unlikely to have
any dependencies installed already (unlike any *nix systems).

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

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

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

Having done a bit more pondering, just following up my own posting...

Neil Durant wrote:
> Brian wrote:
> > Has any consideration been given to writing some or all of this project
> > in a truly portable language such as Python?
> 
> 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.

The converse of point (2) is that we would only need to ship one compiler,
for any platform, ie we wouldn't even need different builds for different
platforms.

The more I think about this Python idea, the more intrigued I am.

Andy, any thoughts?

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

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

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

Me again...

I don't think my reply to this was especially clear (it's 5.38am here -
long night!).

Brian wrote:
> 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 think our goal is to achieve both of those aims (although initially just
for the compiler).

We want a single compiler, written from the ground up, that will work on
all popular platforms, so it would make the OOPic accessible to non-Windows
platforms, and would provide an alternative to the existing tools (and a
superior alternative!) on the Windows platform.

And in doing this we want to improve the language support substantially,
and make error reporting better (that one won't be hard!!).

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

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

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

Brian wrote:
> --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?   Has any
> consideration been given to writing some or all of this project in a
> truly portable language such as Python?

I've been playing with Python a bit over the last week or so, and I love
it!!  It seems very easy to get into, and quick to develop with.

Furthermore, it's really straightforward to use pieces of C code within a
Python program, and in fact some people apparently use Python for
prototyping, and then work through the various Python modules rewriting
them in C/C++ if and when they need extra speed (however Python is very
fast anyway).  Translated into our project, it means we could write in
Python, and in the unlikely scenario that we need to use C for something,
we could, without any problem.

Another nifty thing is that you can create "frozen binaries" which are
single executible files that contain the compiled Python byte-code, along
with a small Python virtual machine.  In other words, you can ship this
single executable, with nothing else, and it'll run on the chosen target
platform.  This will make life extremely easy for installing the OOPic
compiler on Windows machines, as we would not need an installer, and would
not have to worry about installing Python etc.  Ideal for OOPic users who
just want an easy life.

Another really nifty thing about Python is that you can run your code, with
no need to port, on Palm and PocketPC based PDAs, Ataris, Amigas, VMS
mainframes and Cray supercomputers!  Although I doubt there'll be many
OOPic users doing this, it's a pretty cool selling point that our compiler
would run on all of those platforms as well as the usual Windows/Mac/Linux.

In fact the Palm aspect is interesting, because of the SCP example in
Dennis' book.  In conjunction with what he writes, you could use a
Palm-based PDA as a development environment, editing/compiling code and
uploading it to the OOPic, entirely separated from a conventional computer!

So I think my current vote is swinging more over to the Python side now,
than the C side.... :-)   Anyone else got any further thoughts?

Still looking forward to Andy's thoughts on all this......

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