Re: Current Status of Insight

Re: Current Status of Insight

[Paul Schlie]

>> But what Java does not have - is a command line it is
>> compiled langauge Tcl/Tk - it is some what enherent.
>
> Well, something similar could be implemented in Java with BeanShell
> (http://www.beanshell.org/). jEdit uses this.

It seems a lot simpler to simply encourage Insight/GDB as it present stands,
to be officially (or even semi-officially) considered as part of the GDB
release, and maintained as interest allows along side if it; and remain
complemented with the separately maintained TK/TCL library etc. as may be
necessary in parallel; similar to the way it is now, but without the sigma
of "it's dead" lying over it's head.

(Although I'm personally not fan of TK/TCL, I seriously doubt any attempted
re-architecture would end up being more productive than disruptive; so an
in-place successive refinement seems simplest and most logical.)

Re: Current Status of Insight

[Steven Johnson]

Paul Schlie wrote:

>>>But what Java does not have - is a command line it is
>>>compiled langauge Tcl/Tk - it is some what enherent.
>>>      
>>>
>>Well, something similar could be implemented in Java with BeanShell
>>(http://www.beanshell.org/). jEdit uses this.
>>    
>>
>
>  
>
Wouldnt a front end to GDB written in Java, and using MI be Eclipse 
CDT?  Surely it would be better to contribute to that project, if thats 
what people wanted, rather than do it again?  The Eclipse CDT GDB Front 
end certainly seems to need a lot of work, especially where access to 
the GDB command line, and embedded development are concerned (I cant 
find how to do a "Load" from the interface, for example).  [This is not 
a criticism of Eclipse/CDT or the work they have already done, which is 
a lot, just an observation.]

>It seems a lot simpler to simply encourage Insight/GDB as it present stands,
>to be officially (or even semi-officially) considered as part of the GDB
>release, and maintained as interest allows along side if it; and remain
>complemented with the separately maintained TK/TCL library etc. as may be
>necessary in parallel; similar to the way it is now, but without the sigma
>of "it's dead" lying over it's head.
>
>  
>
I would agree with that.

>(Although I'm personally not fan of TK/TCL, I seriously doubt any attempted
>re-architecture would end up being more productive than disruptive; so an
>in-place successive refinement seems simplest and most logical.)
>
>  
>
I would agree with that also.

I also would have thought, from the FSF view, "JAVA" would be more evil 
[def: less compaitble with the ideals of the FSF] than "tcl" because 
"JAVA" isnt really free.  Im sure most people have seen the message on 
the FSF sites about Java.

It seems to me that the less we need to do, the more likely it is its 
that it is going to get done.

On the point about branching, if its not necessary, then im not pushing 
it.  The less we need to do the better.

It does appear however that there are a lot of people that "care about 
Insight".

So the first challenge is to create a Snapshot of the current 
development, so people can easily download it, and the stigma of "its 
dead" can start to go away.

The second will be to get the "People that care about Insight" to 
actively contribute, so that it can be an even better tool.

Re-synching with the GDB source tree as at 6.3 wouldnt be good,  GDB 6.3 
(as released) has at least one nasty bug for embedded systems, 
preventing it downloading properly (fixed in CVS).  So it probably isnt 
appropriate to rewind the GDB portion to GDB 6.3 stage.  Which leaves us 
with CVS_HEAD.

What about we made a snapshot of CVS_HEAD, with the current GDB Version 
Number GDB6.3.50.whatever.

Put a link to it on the web site to the snapshot, say something about it 
being a beta release for the next "Stable" which will be released 
shortly after the next GDB is released.  That it is considered better to 
use this Beta than the previous stable release Insight 5.3, due to the 
numerous changes that have been made with GDB and Insight in the mean 
time, and request people to both:
(a) test it in their environments
(b) submit improvements or changes.
(c) put their hand up to help with continued maintenance, or it will die 
off. So if you use it, get involved, or get used to a different tool.

Every so often, (Every couple of months, or after a mojor change/bug 
fix) we make another "Beta" snapshot, when people feel its a good time, 
and stable enough.

Make a TODO, expanding on what Fernando wrote, covering what people 
think the deficiencies are, including the list of code that needs to be 
replaced to have all the source FSF assigned. (If it isnt going to be 
assigned by Redhat).

Also, just as an observation, it appears a lot of the people who are 
currently using Insight are using it in the embedded space.  I would be 
interested to know how many are using CVS_HEAD for embedded, or are you 
using Insight 5.3 or some other version?  Im having real difficulty with 
GDB 6.3 (and the things it does to a target) in the embedded space, and 
im wondering if its just me, or what?

If we can generate enough interest to get it being re-released in synch 
with GDB, then we could start worrying about wholesale changes.

There shouldnt be a lot of work to this first stage, so im putting up my 
hand to do it, but im going to need help getting there (in the form of 
guidance, etc).

Also, im in no way trying to imply the great work of Keith Seitz and 
others maintaining Insight to this stage is nothing short of fantastic, 
and I applaud their hard work and dedication.  Without it, Insight would 
be a footnote in history, and not just hiding in the shadows.  I also 
dont profess to know very much about the deeper workings of Insight.  
There is no way I could currently fill the shoes of Keith or the other 
major maintainers for the amount of actual coding and testing they do.  
All this is really about (from my perspective) is preparing releases, so 
the project at least looks as active, as it in reality is.

Comments?

Steven Johnson

Insight and Licencing of TCL/TK Code

[Steven Johnson]

This is a follow on from "The current status of insight'.  It occurs to 
me that there is actually a legal problem with the TCL/TK Sources of 
insight not being assigned to the FSF.

It would seem to me (as i stare at the code, and without checking CVS at 
all).  That there must, over the life of insight, have been a number of 
patches made to the TCL/TK code, from people that are not employees of 
Redhat or Cygnus.  Now those people, if they are contributing anything 
of substance will probably have completed assignments with the FSF (like 
i did ages ago). But they would not have assigned their changes to 
redhat.  So now, there are files, that contain Redhat copyright, that 
have been modified, and those modifications are presumably assigned to 
the FSF, but certainly Redhat can not claim copyright over them.  Yet 
the files as they stand, claim copyright over the entire contents, 
including the contributed parts, that have not been assigned to Redhat.

Isnt this a problem?

Certainly if I were to submit TCL/TK code (which the way im going, im 
about to), i would not be assigning it's copyright to Redhat.

How is this dealt with?  is that really the cruxt of the problem? 

If so, it would seem like there is almost an obligation to "officialy" 
effect the assignment, so that this work of others is properly 
copyrighted, as intended by the various contributors?  Even checking CVS 
wouldnt categorically decide the issue of who owns each patch, as the 
patch may have been applied by an employee of Redhat, but may very well 
of been submitted by an external party.  The only way to unscramble the 
Egg as it were would be to do a trawl of every maintainers email, to 
find the ultimate source of each patch.  A task that is infeasible.

Steven Johnson

Re: Insight and Licencing of TCL/TK Code

[Duane Ellis]

>> Certainly if I were to submit TCL/TK code (which the way
   im going, im about to), i would not be assigning it's
   copyright to Redhat.

See:

http://www.fsf.org/licensing/licenses/why-assign.html

RE: Insight and Licencing of TCL/TK Code

[Jon Beniston]

> 
> 
> >> Certainly if I were to submit TCL/TK code (which the way
>    im going, im about to), i would not be assigning it's
>    copyright to Redhat.
> 
> See:
> 
> http://www.fsf.org/licensing/licenses/why-assign.html
> 

Maybe he'd be happy to assign it to the FSF, but not to RedHat.

Cheers,
Jon

Re: Insight and Licencing of TCL/TK Code

[Steven Johnson]

Jon Beniston wrote:

>>    
>>
>>>>Certainly if I were to submit TCL/TK code (which the way
>>>>        
>>>>
>>   im going, im about to), i would not be assigning it's
>>   copyright to Redhat.
>>
>>See:
>>
>>http://www.fsf.org/licensing/licenses/why-assign.html
>>
>>    
>>
>
>Maybe he'd be happy to assign it to the FSF, but not to RedHat.
>
>  
>
Precisely my point, I already have an assignment on file with the FSF 
for any submissions i make to GDB.  I would consider changes to the 
TCL/TK Code of insight to be submissions to GDB.  But the file has 
"Copyright Redhat".  Im sure the code in those files isnt all from 
RedHat.  So how can they claim the copyright for the whole file?  I am 
happy to assign to the FSF.

BTW, I know the "Claim copyright to the whole file" is an accident of 
history, and not some nefarious plot or intentional scheme from the part 
of Redhat or Cygnus to disenfrancise contributors who thought they were 
contributing to GDB under assignments to the FSF.  I dont blame Redhat 
for it, im just pointing out the difficulty moving forward of 
perpetuating it. 

If we submit in future, should we wrap our TCL/TK submissions in 
"Portion Copyright FSF Start" and "End" so that in the event of a 
re-write of the rest down the line, at least the stuff that Redhat didnt 
author doesnt have to be re-invented.

It doesnt help anything else already in there that would fall under this 
cateogry, but maybe in future, we should consider it.

I also noticed this issue seems limited to the TCL/TK portions of 
insight, i havent noticed any Redhat copyrights in the C code that 
interfaces the core of GDB with the TCL/TK Code.

Steven.

Re: Current Status of Insight

[Christopher Faylor]

On Sat, May 14, 2005 at 06:13:42PM -0400, Paul Schlie wrote:
>>> But what Java does not have - is a command line it is
>>> compiled langauge Tcl/Tk - it is some what enherent.
>>
>> Well, something similar could be implemented in Java with BeanShell
>> (http://www.beanshell.org/). jEdit uses this.
>
>It seems a lot simpler to simply encourage Insight/GDB as it present stands,
>to be officially (or even semi-officially) considered as part of the GDB
>release, and maintained as interest allows along side if it; and remain
>complemented with the separately maintained TK/TCL library etc. as may be
>necessary in parallel; similar to the way it is now, but without the sigma
>of "it's dead" lying over it's head.

The project is only "dead" because no one is actively caring for it.
Making it part of gdb does not mean that someone will magically appear
to keep it alive.  You still need people to do that.

We CAN fix this.  All that we need are volunteers to keep insight
healthy.  While it would be nice to have insight officially part of gdb,
it has managed to survive fairly well for a long time in its present
state.

This is FREE SOFTWARE we're talking about.  There is no reason for anything
to die when the source code is available as long as people are actively
interested in maintaining it.

cgf

Re: Insight and Licencing of TCL/TK Code

[Christopher Faylor]

On Tue, May 17, 2005 at 01:18:37AM -1100, Steven Johnson wrote:
>I also noticed this issue seems limited to the TCL/TK portions of 
>insight, i havent noticed any Redhat copyrights in the C code that 
>interfaces the core of GDB with the TCL/TK Code.

So, since Red Hat doesn't care, we can just start accepting patches for
insight from people who already have gdb assignments with the FSF.

Then, if/when insight is assigned to the FSF there won't be any issues
with the code.

cgf

Re: Current Status of Insight

[Paul Schlie]

> From: Christopher Faylor <me@cgf.cx>
>> On Sat, May 14, 2005 at 06:13:42PM -0400, Paul Schlie wrote:
>>>> But what Java does not have - is a command line it is
>>>> compiled langauge Tcl/Tk - it is some what enherent.
>>> 
>>> Well, something similar could be implemented in Java with BeanShell
>>> (http://www.beanshell.org/). jEdit uses this.
>> 
>> It seems a lot simpler to simply encourage Insight/GDB as it present stands,
>> to be officially (or even semi-officially) considered as part of the GDB
>> release, and maintained as interest allows along side if it; and remain
>> complemented with the separately maintained TK/TCL library etc. as may be
>> necessary in parallel; similar to the way it is now, but without the sigma
>> of "it's dead" lying over it's head.
> 
> The project is only "dead" because no one is actively caring for it.
> Making it part of gdb does not mean that someone will magically appear
> to keep it alive.  You still need people to do that.
> 
> We CAN fix this.  All that we need are volunteers to keep insight
> healthy.  While it would be nice to have insight officially part of gdb,
> it has managed to survive fairly well for a long time in its present
> state.
> 
> This is FREE SOFTWARE we're talking about.  There is no reason for anything
> to die when the source code is available as long as people are actively
> interested in maintaining it.

Thanks for the clarification, I was mistakenly under the impression that
it was potentially more politically complicated than that for some reason
(possibly as it seemed somewhat unsympathetically needlessly divorced from
GDB's development I guess, but good to know otherwise; and will help as I
can, although likely very limitedly, as I'm very unfamiliar with Tk/Tcl,
which seems fairly critical.)

Re: Current Status of Insight

[Fernando Nasser]

Steven Johnson wrote:
> Paul Schlie wrote:
> 
>>>> But what Java does not have - is a command line it is
>>>> compiled langauge Tcl/Tk - it is some what enherent.
>>>>     
>>>
>>> Well, something similar could be implemented in Java with BeanShell
>>> (http://www.beanshell.org/). jEdit uses this.
>>>   
>>
>>
>>  
>>
> Wouldnt a front end to GDB written in Java, and using MI be Eclipse 
> CDT?  Surely it would be better to contribute to that project, if thats 
> what people wanted, rather than do it again?  The Eclipse CDT GDB Front 
> end certainly seems to need a lot of work, especially where access to 
> the GDB command line, and embedded development are concerned (I cant 
> find how to do a "Load" from the interface, for example).  [This is not 
> a criticism of Eclipse/CDT or the work they have already done, which is 
> a lot, just an observation.]
> 

Unfortunately that code is tightly coupled with Eclipse.  Ans many 
people don't want to use Eclipse, just a debugger GUI.



> 
> I also would have thought, from the FSF view, "JAVA" would be more evil 
> [def: less compaitble with the ideals of the FSF] than "tcl" because 
> "JAVA" isnt really free.  Im sure most people have seen the message on 
> the FSF sites about Java.
> 

That is moot.  The MI interface is standard and decouples whatever GUI 
it is from GDB.

One can write it under whichever license, whichever language, anything.

There are many GUIs already written with MI that fall in all possible 
categories you can imagine.

MI is not an API, it is a line protocol where messages are exchanged in 
an ASCII format.  Think of it as a SOAP poor cousin.