* Re: Current Status of Insight
@ 2005-05-14 22:13 Paul Schlie
2005-05-16 5:35 ` Steven Johnson
2005-05-16 16:10 ` Christopher Faylor
0 siblings, 2 replies; 10+ messages in thread
From: Paul Schlie @ 2005-05-14 22:13 UTC (permalink / raw)
To: insight
>> 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.)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Current Status of Insight 2005-05-14 22:13 Current Status of Insight Paul Schlie @ 2005-05-16 5:35 ` Steven Johnson 2005-05-16 13:18 ` Insight and Licencing of TCL/TK Code Steven Johnson 2005-05-17 19:33 ` Current Status of Insight Fernando Nasser 2005-05-16 16:10 ` Christopher Faylor 1 sibling, 2 replies; 10+ messages in thread From: Steven Johnson @ 2005-05-16 5:35 UTC (permalink / raw) To: insight 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Insight and Licencing of TCL/TK Code 2005-05-16 5:35 ` Steven Johnson @ 2005-05-16 13:18 ` Steven Johnson 2005-05-16 13:31 ` Duane Ellis 2005-05-17 19:33 ` Current Status of Insight Fernando Nasser 1 sibling, 1 reply; 10+ messages in thread From: Steven Johnson @ 2005-05-16 13:18 UTC (permalink / raw) To: insight 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Insight and Licencing of TCL/TK Code 2005-05-16 13:18 ` Insight and Licencing of TCL/TK Code Steven Johnson @ 2005-05-16 13:31 ` Duane Ellis 2005-05-16 13:39 ` Jon Beniston 0 siblings, 1 reply; 10+ messages in thread From: Duane Ellis @ 2005-05-16 13:31 UTC (permalink / raw) To: sjohnson; +Cc: insight >> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Insight and Licencing of TCL/TK Code 2005-05-16 13:31 ` Duane Ellis @ 2005-05-16 13:39 ` Jon Beniston 2005-05-16 14:15 ` Steven Johnson 0 siblings, 1 reply; 10+ messages in thread From: Jon Beniston @ 2005-05-16 13:39 UTC (permalink / raw) To: duane_ellis, sjohnson; +Cc: insight > > > >> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Insight and Licencing of TCL/TK Code 2005-05-16 13:39 ` Jon Beniston @ 2005-05-16 14:15 ` Steven Johnson 2005-05-16 16:12 ` Christopher Faylor 0 siblings, 1 reply; 10+ messages in thread From: Steven Johnson @ 2005-05-16 14:15 UTC (permalink / raw) To: insight 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Insight and Licencing of TCL/TK Code 2005-05-16 14:15 ` Steven Johnson @ 2005-05-16 16:12 ` Christopher Faylor 0 siblings, 0 replies; 10+ messages in thread From: Christopher Faylor @ 2005-05-16 16:12 UTC (permalink / raw) To: Steven Johnson, insight 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Current Status of Insight 2005-05-16 5:35 ` Steven Johnson 2005-05-16 13:18 ` Insight and Licencing of TCL/TK Code Steven Johnson @ 2005-05-17 19:33 ` Fernando Nasser 1 sibling, 0 replies; 10+ messages in thread From: Fernando Nasser @ 2005-05-17 19:33 UTC (permalink / raw) To: Steven Johnson; +Cc: insight 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Current Status of Insight 2005-05-14 22:13 Current Status of Insight Paul Schlie 2005-05-16 5:35 ` Steven Johnson @ 2005-05-16 16:10 ` Christopher Faylor 2005-05-16 17:18 ` Paul Schlie 1 sibling, 1 reply; 10+ messages in thread From: Christopher Faylor @ 2005-05-16 16:10 UTC (permalink / raw) To: Paul Schlie, insight 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Current Status of Insight 2005-05-16 16:10 ` Christopher Faylor @ 2005-05-16 17:18 ` Paul Schlie 0 siblings, 0 replies; 10+ messages in thread From: Paul Schlie @ 2005-05-16 17:18 UTC (permalink / raw) To: Christopher Faylor, insight > 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.) ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-05-17 19:33 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-05-14 22:13 Current Status of Insight Paul Schlie 2005-05-16 5:35 ` Steven Johnson 2005-05-16 13:18 ` Insight and Licencing of TCL/TK Code Steven Johnson 2005-05-16 13:31 ` Duane Ellis 2005-05-16 13:39 ` Jon Beniston 2005-05-16 14:15 ` Steven Johnson 2005-05-16 16:12 ` Christopher Faylor 2005-05-17 19:33 ` Current Status of Insight Fernando Nasser 2005-05-16 16:10 ` Christopher Faylor 2005-05-16 17:18 ` Paul Schlie
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).