public inbox for sourcenav@sourceware.org
 help / color / mirror / Atom feed
From: Kristoffer Lawson <setok@fishpool.com>
To: sourcenav@sources.redhat.com
Subject: Great work
Date: Fri, 21 Jul 2000 10:18:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.21.0007211922170.19085-100000@gfanrend.fishpool.fi> (raw)

Just tested the software out briefly and based on what I've seen of it the
programme really does look and feel good. 

A few initial questions:

- As you use Tcl throughout the system (a good thing indeed!) I wondered
if it might be possible to build a parser in Tcl instead of
C? Specifically, is there a Tcl API like the C API for handling the
project database? (True, building one on top of the C API is not a big
chore). Specifically I would like support for XOTcl (www.xotcl.org) and
OTcl.

OTOH it probably wouldn't be horribly difficult to edit the Tcl parser.
The idea would be that:

Class Foo -superclass Bar  ;#  Create Foo class, the superclass is Bar
Foo instproc  ;# Create method in Foo
Foo proc  ;# Create procedure in Foo (not seen in the object instance)
          ;# Basically just means the parser should handle local variables
          ;# as local instead of global (as it does now with anything that
          ;# doesn't occur inside a proc command parameter).
Foo ob   ;# Create object 'ob' of type 'Foo'

The simple case should not be difficult but of course the problem with the
dynamic nature of XOTcl is that you can add and remove methods, change an
object's class or superclass at any point during run-time. How have you dealt 
with it when dealing with Tcl namespaces, which are quite dynamic
themselves?


- Is the Tcl parser behaviour correct when assuming that any "set"
statement inside curly brackets is actually setting a global variable? I
think by default it shouldn't do anything (ie. not add a variable to the
variable list) and have exceptions to the rule when dealing with while,
for, proc etc. The reason for this is that inside curlies I might have
data that might look like I'm setting a variable but actually I'm not. It
might just be plain data, or maybe I'm sending the code to another
interpreter or whatever.

This is related to the previous comment because currently XOTcl instance
variables appear as "global variables" which is not correct. While it
naturally would be nice if the environment recognized them as instance
variables I believe it's better not to recognize them at all than to mark
them as globals.


- I seem to be having problems with emacs/Xemacs and the IDE (btw. I think
it's great that you have put in extra effort to get emacs to interact with
the IDE). When looking up for a symbol with M-. I get the following error:

(1) (error/warning) Error in process filter: (void-variable DisplayableOb)


Keep up the good work. I'm sure I'll have more to say when I play around
with it more ;-)


         -     ---------- = = ---------//--+
         |    /     Kristoffer Lawson      |  www.fishpool.fi|.com
         +-> |    setok@fishpool.com       |  - - --+------
             |-- Fishpool Creations Ltd - /         |
             +-------- = - - - = ---------      /~setok/

             reply	other threads:[~2000-07-21 10:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-21 10:18 Kristoffer Lawson [this message]
2000-07-21 10:40 ` Mo DeJong
2000-07-21 11:14   ` Kristoffer Lawson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.21.0007211922170.19085-100000@gfanrend.fishpool.fi \
    --to=setok@fishpool.com \
    --cc=sourcenav@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).