Great work

Great work

[Kristoffer Lawson]

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/

Re: Great work

[Mo DeJong]

On Fri, 21 Jul 2000, Kristoffer Lawson wrote:
 
> 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.

See the documentation for the Tcl interface to the DB. That should
at least get your started.

http://sources.redhat.com/sourcenav/online-docs/progref/dbaseAPI.html#pgfId-996849

As for extending the Tcl support, we have talked about this at
length and we think the best approach would be to use the Tcl
parser API exposed by regular Tcl at the C layer. We currently
use our own parser written for Tcl. To be honest, it would
be better to toss out our Tcl parser and use the one from
the Tcl core, and since the Tcl core is already part of
SN, it is just waiting for someone to come along and
use it :)

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

Yes, this is another weak area in our Tcl parser. It was written before
Tcl namespaces were in Tcl, so it has no namespace support.
 
> - 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.

Tcl is very dynamic, so in general you can not assume that any command
does anything. You need to make some assumptions otherwise you will
get nowhere fast. Set should at least know if it is a local var,
a global var, or a class instance or class common (static) var, but,
this is not always possible.

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

You will need to hack it to fix that.

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

The emacs/xemacs stuff is in there for hackers, so if you have any
problems you will need to fix them on your own. When you do, please
send us the patches so the next guy will not need to.

later
Mo DeJong
Red Hat Inc

Re: Great work

[Kristoffer Lawson]

On Fri, 21 Jul 2000, Mo DeJong wrote:

> use our own parser written for Tcl. To be honest, it would
> be better to toss out our Tcl parser and use the one from
> the Tcl core, and since the Tcl core is already part of
> SN, it is just waiting for someone to come along and
> use it :)

Yes these indeed sounds very sensible.
>  
> Tcl is very dynamic, so in general you can not assume that any command
> does anything. You need to make some assumptions otherwise you will
> get nowhere fast. Set should at least know if it is a local var,
> a global var, or a class instance or class common (static) var, but,
> this is not always possible.

Yes, exactly. But I think the suggested model would be quite sufficient
and at least errenous behaviour would not occur (ie. instance variables
or data appearing as global variables). Ie:

- set commands inside curly bracketrs are not handled in any way, unless:

- if they appear inside the command parameter for while, for, foreach,
eval, namespace eval, proc etc. 

It does require more work (as you have to specify each of those
exceptions), but it also means that "set" syntax appearing in unrecognized
situations is not misunderstood.
> 
> > - 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)
> 
> The emacs/xemacs stuff is in there for hackers, so if you have any
> problems you will need to fix them on your own. When you do, please
> send us the patches so the next guy will not need to.

OK, if I have time I'll look into that. Meanwhile is there anybody who
might have a clue about that? Using M-. to lookup a symbol is a documented
feature of "using emacs with Source Navigator" so it might be something
small.

OTOH if the in-built editor could do emacs-style indentation I might
be quite tempted to use it (as it *does* integrate nicely with the IDE).
I realize that's a big requirement but possibly something to look at in
the future.

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