SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Sat, 14 Jan 2006 00:42:21 PST8
From:	"Gregory W. Smith" <gsmith@well.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Pushing ahead

Content Type: text/plain

Lynn Maxson wrote:
> Now Watcom comes as a complete IDE, while GCC does not.
> The difference lies in the supplied editor: Watcom has one,
> GCC does not. Supposedly Watcom's editor uses a form of VIM
> also available to the GCC user.

I have not looked at the Watcom IDE, but I am fairly certain
that it is NOT based on VIM. (Just because the default install
of OS/2 has tedit installed, that does not mean that epm is
based on tedit.) So I very much doubt that a Unix screen editor
(VIM) that evolved from a simple line editor (ed) was used as
the basis of a editor that makes use of the native GUI of the
operating system.

> Just when I thought we might
> focus on an editor such a VIM up pops a presentation using
> JEdit, a JAVA-based editor. Yet another reason for some
> trepid user to hold off contributing.

And other presentations have used edit, preditor, epm, emacs,
and tedit. I selected VIM since it was a typical open source
project with about 1000 pages of C source code. If I had known
that using jEdit to display C source code would have caused
such confusion, I would have stayed with EPM. I was trying to
focus on organizing a source tree with 1000 pages of code and
building the executable from that 1000 pages of code.

> Now I haven't pursued JEdit, but saw PL/I among the
> languages its syntax checking supported. I didn't see that in
> VIM. Thus I tend to favor JEdit at the moment...until we have
> produced its "permanent" replacement.

Well, jEdit is about 2000 pages of Java source code. The build
process does not use a separate make utility. Also, the package
naming conventions are reflected in how you organize the source
tree.

> So Sheridan correctly points out the expanded and complete
> role the editor plays in my "scheme" of things. As my
> "scheme's" normally executes interpretively and optionally in
> compile mode, we should have a far greater interest in how
> Python generates code than either of the two compilers we
> have considered thus far.

OK. So we now have one subproject: an interpreter to run through
the datastore as it is generated by the editor interface. Is this
a complete duplication of the existing GCC or Watcom compilers?
Or do we modify the existing compilers?

> Let us be clear on this point. Every IDE begins with an editor.
> The most ambitious IDE underway, Eclipse, begins with an
> editor. The Watcom IDE, for example, offers access to all
> functions through the editor interface. So we introduce
> nothing new in that respect. Therein on that point we cannot
> argue.

So an alternate approach might be to develop an Eclipse plug-in
to add the data store with automatic invocation of the GCC or
Watcom compilers.

> I suggest then that we pick one open source editor, e.g. JEdit,
> get comfortable with its internals, and use it as the starting
> point. That should give us familiarity with GUI programming of
> the user interface. We should have the confidence we need
> at that point to go forward.

OK, so we are starting with 2000 pages of Java code for the editor.
The compilers are written in C. (I have no idea how many pages the
compiler code is when it is printed out.) Which language should we
use for the datastore, Java or C?
--
Gregory W. Smith (WD9GAY) gsmith@well.com

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 14 | January | 2006 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.