RE: SourceNav release ...

RE: SourceNav release ...

[Simonovsky, Pavel]

		So - you mean , that in fact SN is dead , and there is no
any development team behind it? It is very important info - I suggested this
tool to 2-3 teems in our company ... I have to warn them - that it dose no
worth a waste of time... Thanks a lot !!! It is really crucial
information!!!

___________________________________ 
Simonovsky Pavel 
Multiplatform CONTROL-MNew Dimension Software 
Software Engineer 
Voice: + 972 3 7664648 
Fax: + 972 3 6451100 
Email: Pavel_Simonovsky@bmc.com 

-----Original Message-----
From:	khamis2@t-online.de [mailto:khamis2@t-online.de]
Sent:	Saturday, January 05, 2002 1:43 AM
To:	Roman Levenstein
Cc:	sourcenav@sources.redhat.com
Subject:	Re: SourceNav release ...


Roman Levenstein wrote:

>Hi,
>
>>because the actual tcl parser is written in a strange
>>
>>licenced interpreter "rex?" and redhat don't have the
>>
>>origin source code and the license to this parser.
>>Also SN tcl parser doesn't support tcl/tk8.x. So if 
>>there are enough people interested in this I would
>>
>start 
>
>>writing a new parser (using flex) for tcl that
>>
>supports
>
>>tcltk8.x (without xref).
>>
I wasn't exact here, SN tcl parser doesn't support Itcl3.0!

>
>The Rex scanner generator is a part of the Cocktail
>Toolbox, which is also used for other SN parsers such
>as  Cobol and Java parsers. 
>
Yep!

>
>
>There is a public domain version of it, which can be
>found at:
>http://www.gmd.de/SCAI/lab/adaptor/cocktail.html
>
Good to know

>
>So, there is no problem with a licence. 
>
>As for the origin source for the *.rex file, it's also
>not a problem. REX specification is generated from
>*.scan file by cg tool as far as I remember. Anyway,
>there is a description of this process in the docs.
>
>
>BTW, Cocktail is one of the best compiler construction
>toolkits and it's really very powerful and much better
>than yacc/lex. It covers the whole process of compiler
>construction- from lexical and syntax analysis up to
>code generation and register allocation. And, which is
>also very important, the generated parsers and
>scanners   are much faster than those generated by
>lex/yacc.
>
Hmm, but who is familar with this toolbox? I'm not familar with the 
cocktail toolbox
and actually don't have the time to spend time learning this language.
It's true that the parsers implemented in lex/yacc are not perfekt, but 
lex is good enough
to write a parser in the 'free' time, since SN is not developed 
officially anymore!

I would appreciate very much, if you do a hack to let tcl parser 
understands
the itcl class definition "itcl:class".

khamis

>
>Roman 
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Send your FREE holiday greetings online!
>http://greetings.yahoo.com
>
>

Re: SourceNav release ...

[Mo DeJong]

On Sun, 6 Jan 2002 02:25:59 -0600 
"Simonovsky, Pavel" <Pavel_Simonovsky@bmc.com> wrote:

> 		So - you mean , that in fact SN is dead , and there is no
> any development team behind it? It is very important info - I suggested this
> tool to 2-3 teems in our company ... I have to warn them - that it dose no
> worth a waste of time...

Well, that might be a bit too strong. I don't speak for Red Hat, but as a former member of the development team I feel safe in stating that they are no longer allocating resources to SN. Basically, it comes down to $$. If you have paying customers then you can pay the engineers and managers. This might just be my impression, but it seemed that being able to download the code for free gave people the impression that they should not have to chip in for any new development. Also, the dot crunch did not help.

I know for a fact that Ian has been doing some great work on his own time to get the development version that uses Tcl/Tk 8.3 available via CVS. It is quite an improvement over the 5.0 release. That said, what is lacking is time and resources to put out a 5.1 release. What is the solution? I am not sure. I would like to hear ideas from people on this list. I would think the right solution would provide a stable 5.1 release, but also provide a plan for 5.2 and future releases.

cheers
Mo DeJong

Re: SourceNav release ...

[Ralf Corsepius]

Am Son, 2002-01-06 um 04.54 schrieb Mo DeJong:
> On Sun, 6 Jan 2002 02:25:59 -0600 
> "Simonovsky, Pavel" <Pavel_Simonovsky@bmc.com> wrote:
> 
> > 		So - you mean , that in fact SN is dead , and there is no
> > any development team behind it? It is very important info - I suggested this
> > tool to 2-3 teems in our company ... I have to warn them - that it dose no
> > worth a waste of time...
> 
> Well, that might be a bit too strong. I don't speak for Red Hat, but as a former member of the development team I feel safe in stating that they are no longer allocating resources to SN. Basically, it comes down to $$. If you have paying customers then you can pay the engineers and managers. This might just be my impression, but it seemed that being able to download the code for free gave people the impression that they should not have to chip in for any new development. Also, the dot crunch did not help.
> 
> I know for a fact that Ian has been doing some great work on his own
time to get the development version that uses Tcl/Tk 8.3 available via
CVS. It is quite an improvement over the 5.0 release. That said, what is
lacking is time and resources to put out a 5.1 release. What is the
solution? I am not sure. I would like to hear ideas from people on this
list.

OK, here is mine:

IMHO, the basic problem is to render SN into an active project.

As RH apparently is not developing actively anymore, one solution would
be to convert SN into a real OpenSource community project.

AFAIS, there would be 2 approaches to such an attempt:

1.) Apply the existing RH-infrastructure and run it
RH-conducted/assisted. 
This would require RH to provide minimal assistance and support (ML,
CVS, ftp etc) + generally OK-ing into such undertaking.

Given the existing SN-related infrastructure at RH, I fail to see why
this should not work. At that lacks are active maintainers (RH or Non-RH
person) willing to accept and apply patches + to guide people though
development.

From my POV, it's only the lack of active maintainers which currently
lets appear SN as "dumped dead code junk".

2.) To lunch a GPL'ed non-RH related project somewhere else, using RH's
SN-code as basis. IMHO, nobody actually would be interested in doing so
and I also doubt it would actually work out.

> I would think the right solution would provide a stable 5.1 release,
> but also provide a plan for 5.2 and future releases.
I fully agree.

But the only way to achieve something of this kind IMHO would be
somebody (the maintainer - who is it? Ian, you?) to show some visible
initiative - Currently, SN appears not only to be dead, but to
unmaintained.

Ralf

Re: SourceNav release ...

[Khamis Abuelkomboz]

Hi Ralf,

I find your input great. we need an "open" way to add work into SN, I 
had the idea
about taking the current redhat SN and provide my own SN release, basicly
to rework the GUI and extend the existing parsers.
As example I would like
- to integrate the symbol browser into the main window,
- add more functionality to the browser, like add/remove files, history, 
etc.
- making it possible to open more than one editor pane in a window.
- list the symbols of current edited file on the right (OLD SN 
functionality reenabled)
- etc.

Actually I already started to do this work, see 
http://oimanager.de/sn/newsngui.gif
and welcome your input.

But the problem is, where to keep the whole SN? My own web space is too 
small.

However I find puting SN into an open CVS is a first step to achieve 
this gool.

Khamis

Ralf Corsepius wrote:

>Am Son, 2002-01-06 um 04.54 schrieb Mo DeJong:
>
>>On Sun, 6 Jan 2002 02:25:59 -0600 
>>"Simonovsky, Pavel" <Pavel_Simonovsky@bmc.com> wrote:
>>
>>>		So - you mean , that in fact SN is dead , and there is no
>>>any development team behind it? It is very important info - I suggested this
>>>tool to 2-3 teems in our company ... I have to warn them - that it dose no
>>>worth a waste of time...
>>>
>>Well, that might be a bit too strong. I don't speak for Red Hat, but as a former member of the development team I feel safe in stating that they are no longer allocating resources to SN. Basically, it comes down to $$. If you have paying customers then you can pay the engineers and managers. This might just be my impression, but it seemed that being able to download the code for free gave people the impression that they should not have to chip in for any new development. Also, the dot crunch did not help.
>>
>>I know for a fact that Ian has been doing some great work on his own
>>
>time to get the development version that uses Tcl/Tk 8.3 available via
>CVS. It is quite an improvement over the 5.0 release. That said, what is
>lacking is time and resources to put out a 5.1 release. What is the
>solution? I am not sure. I would like to hear ideas from people on this
>list.
>
>OK, here is mine:
>
>IMHO, the basic problem is to render SN into an active project.
>
>As RH apparently is not developing actively anymore, one solution would
>be to convert SN into a real OpenSource community project.
>
>AFAIS, there would be 2 approaches to such an attempt:
>
>1.) Apply the existing RH-infrastructure and run it
>RH-conducted/assisted. 
>This would require RH to provide minimal assistance and support (ML,
>CVS, ftp etc) + generally OK-ing into such undertaking.
>
>Given the existing SN-related infrastructure at RH, I fail to see why
>this should not work. At that lacks are active maintainers (RH or Non-RH
>person) willing to accept and apply patches + to guide people though
>development.
>
>From my POV, it's only the lack of active maintainers which currently
>lets appear SN as "dumped dead code junk".
>
>2.) To lunch a GPL'ed non-RH related project somewhere else, using RH's
>SN-code as basis. IMHO, nobody actually would be interested in doing so
>and I also doubt it would actually work out.
>
>>I would think the right solution would provide a stable 5.1 release,
>>but also provide a plan for 5.2 and future releases.
>>
>I fully agree.
>
>But the only way to achieve something of this kind IMHO would be
>somebody (the maintainer - who is it? Ian, you?) to show some visible
>initiative - Currently, SN appears not only to be dead, but to
>unmaintained.
>
>Ralf
>
>
>

Re: SourceNav release ...

[Timothy M. Shead]

Khamis Abuelkomboz wrote:

 > Hi Ralf,
 >
 > I find your input great. we need an "open" way to add work into SN, I
 > had the idea
 > about taking the current redhat SN and provide my own SN release, basicly
 > to rework the GUI and extend the existing parsers.
 > As example I would like
 > - to integrate the symbol browser into the main window,
 > - add more functionality to the browser, like add/remove files, history,
 > etc.
 > - making it possible to open more than one editor pane in a window.
 > - list the symbols of current edited file on the right (OLD SN
 > functionality reenabled)
 > - etc.
 >
 > Actually I already started to do this work, see
 > http://oimanager.de/sn/newsngui.gif
 > and welcome your input.
 >
 > But the problem is, where to keep the whole SN? My own web space is too
 > small.

Sounds like SN ought to move to SourceForge - if Red Hat isn't going to
maintain it, there needs to be a clean break, so people stop waiting for
Red Hat to do the work ... which is not to complain about Red Hat -
they're the ones who GPL'd SN, making such a move possible.

Timothy M. Shead

Re: SourceNav release ...

[Ian Roxborough]

On 06 Jan 2002 15:35:32 +0100 Ralf Corsepius <corsepiu@faw.uni-ulm.de> wrote:
>
> As RH apparently is not developing actively anymore, one solution would
> be to convert SN into a real OpenSource community project.
> 
> AFAIS, there would be 2 approaches to such an attempt:
> 
> 1.) Apply the existing RH-infrastructure and run it
> RH-conducted/assisted. 
> This would require RH to provide minimal assistance and support (ML,
> CVS, ftp etc) + generally OK-ing into such undertaking.
> 
> Given the existing SN-related infrastructure at RH, I fail to see why
> this should not work. At that lacks are active maintainers (RH or Non-RH
> person) willing to accept and apply patches + to guide people though
> development.

Well, this is what is happening.  Sorry if it isn't as fast and high
profile as you'd like.

The only downside of this is contributors have to sign a
Copyright assignment so that Red Hat retains the copyright.
Probably the first person who would recieve one is Khamis
(the copyright assignment will only apply to worked checked
in CVS).  I should beable to accept small patches (~12 lines?)
without a copyright assignment.

Before that I need to write a "how to submit patches" web
page so I can reject patches and point people to this page
so they can get there patch into shape.  Just simple things
like having a changelog entry, matching coding style and stuff.

> From my POV, it's only the lack of active maintainers which currently
> lets appear SN as "dumped dead code junk".

Beats leaving the code to rott away in a tarball somewhere where nobody
can download it.

> 2.) To lunch a GPL'ed non-RH related project somewhere else, using RH's
> SN-code as basis. IMHO, nobody actually would be interested in doing so
> and I also doubt it would actually work out.

sourcenav.sourceforge.net?

If somebody wants to host and maintain another version of SN that is
OK by me, this would avoid copyright assignment and stuff like that.
I would not stop maintaining a copy here, not until atleast the
other version was way better . :-)

> > I would think the right solution would provide a stable 5.1 release,
> > but also provide a plan for 5.2 and future releases.
> I fully agree.
> 
> But the only way to achieve something of this kind IMHO would be
> somebody (the maintainer - who is it? Ian, you?) to show some visible
> initiative - Currently, SN appears not only to be dead, but to
> unmaintained.

Well, if I was to "pull my finger out" as they say and make this
happen (i.e. copyrights, patches page, regular approvals etc.), would
you be interested in maintaining a small part of SN?  I would like to
divide up the work (Windows port/build, parsers, db, etc.) so it
is more manageable.

Ian.

Patches...[was: Re: SourceNav release ... ]

[Ian Roxborough]

On Mon, 7 Jan 2002 13:14:12 -0800 Ian Roxborough <irox@redhat.com> wrote:
>
> Before that I need to write a "how to submit patches" web
> page so I can reject patches and point people to this page
> so they can get there patch into shape.  Just simple things
> like having a changelog entry, matching coding style and stuff.

It's here and always was:
http://sources.redhat.com/sourcenav/contrib.html

It was already there (scroll down to "Submitting Patches").

A number of people have submitted small patches without
ChangeLog entries.  Please resubmit your patch complete
with a plain text ChangeLog entry (i.e. not part of the diff)
if you wish to have your patch include in the CVS repository.

Thanks,

  Ian.

Re: SourceNav release ...

[Eray Ozkural (exa)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ian,

Thanks a lot for all your work on sourcenav.

Is my small call graph generator included in sourcenav now? I'd posted it 
here on the list. I can sign things, too. :) A fellow hacker had even made 
some improvements to it. It was very useful for trying to understand a large 
chunk of old code in a past project I worked in.

I have an important question to ask. For the past two weeks or so we have 
been discussing how the parser backend should be in KDevelop IDE. As a 
computer scientist, I feel what the Right Thing (TM) is but as far as 
practically goes it is out of question [*].

What we have here is a class store API (which is basically a tree structure) 
that is intended to provide type information for class based languages. 
KDevelop hackers are retro-fitting a C++ parser for doing things like code 
completion.

However, my hunch is that it will not be a general purpose or complete 
solution to the problem. Neither is a perfect solution implementable in our 
humble development environment (that being ancient parser generators and data 
structure driven procedural language: C++)

The next best thing that comes to my mind is sourcenav for three reasons. It 
has solved the multiple languages & persistence problems reasonably well. 
And, it's very portable. Would you deem merit in trying to re-use code from 
source navigator in a C++ code base? (ie we would be using the C API of 
sourcenav). What advantages/disadvantages of sourcenav parser/type analysis 
backend would you think of as the sourcenav maintainer? And how should one go 
about it? (can the whole back end be made into a library?)

Regards,

[*] Doing incremental type analysis for all supported programming languages.

- -- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8PO0XfAeuFodNU5wRArM8AJ9VZfaHTfFJh4nJHo8Dd29qGEE0EACfYubQ
Egrj0otL38qswUHJriLOj4M=
=kfo5
-----END PGP SIGNATURE-----

Re: SourceNav release ...

[Mo DeJong]

On Thu, 10 Jan 2002 03:23:33 +0200
"Eray Ozkural (exa)" <erayo@cs.bilkent.edu.tr> wrote:

> I have an important question to ask. For the past two weeks or so we have 
> been discussing how the parser backend should be in KDevelop IDE. As a 
> computer scientist, I feel what the Right Thing (TM) is but as far as 
> practically goes it is out of question [*].
> 
> What we have here is a class store API (which is basically a tree structure) 
> that is intended to provide type information for class based languages. 
> KDevelop hackers are retro-fitting a C++ parser for doing things like code 
> completion.
> 
> However, my hunch is that it will not be a general purpose or complete 
> solution to the problem.

You are correct, that is not a complete solution. You can't just hack a compiler to generate symbols for your project. That works when the code is perfectly correct but it will explode on code that does not compile. You first reaction might be, "duh, of course the code needs to compile". Thing is, users need the tool to work even if the code does not compile. This fuzzy parsing functionality is not a feature you can tack on later. It needs to be part of the original parser design.

> The next best thing that comes to my mind is sourcenav for three reasons. It 
> has solved the multiple languages & persistence problems reasonably well.
> And, it's very portable. Would you deem merit in trying to re-use code from 
> source navigator in a C++ code base? (ie we would be using the C API of 
> sourcenav). What advantages/disadvantages of sourcenav parser/type analysis 
> backend would you think of as the sourcenav maintainer? And how should one go 
> about it? (can the whole back end be made into a library?)

I think the right solution is to turn the SN backend into a library. Even if you don't reuse the code, the ideas that are there have years of effort behind them and they do work. It should make use of Berkeley DB to store symbols but through an API so that people can swap out other database layers if they want to. It should also provide a nice two phase parse and dump into symbol DB sequence that is easily inspected. Just figuring out what and where the problem with a parser is can be the most difficult part of fixing a problem. Also, it is absolutely critical that a well defined regression test framework is developed as part of the library.

Of course, the tricky part is how to move forward. If you just make a KDE version of Source-Navigator then it will only be useful to KDE folk. There are plenty of other development tools that could really make use of this functionality if it was available in an well documented and easy to use library format. The larger the user base, the more bugs will get worked out. User base is important since parsers are so bug prone. This project is something I was thinking about working on, but it is quite a bit of work and will require more than one developer.

cheers
Mo

Re: SourceNav release ...

[Eray Ozkural (exa)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mo,

On Thursday 10 January 2002 19:45, Mo DeJong wrote:
>
> You are correct, that is not a complete solution. You can't just hack a
> compiler to generate symbols for your project. That works when the code is
> perfectly correct but it will explode on code that does not compile. You
> first reaction might be, "duh, of course the code needs to compile". Thing
> is, users need the tool to work even if the code does not compile. This
> fuzzy parsing functionality is not a feature you can tack on later. It
> needs to be part of the original parser design.
>

Yes, I'm familiar with parsing issues since I had some minor involvement with 
NLP subject. You would typically need to build your CFG parser fault-tolerant 
from the ground up.

> I think the right solution is to turn the SN backend into a library. Even
> if you don't reuse the code, the ideas that are there have years of effort
> behind them and they do work. It should make use of Berkeley DB to store
> symbols but through an API so that people can swap out other database
> layers if they want to. It should also provide a nice two phase parse and
> dump into symbol DB sequence that is easily inspected. Just figuring out
> what and where the problem with a parser is can be the most difficult part
> of fixing a problem. Also, it is absolutely critical that a well defined
> regression test framework is developed as part of the library.
>

I've looked at the code more closely now. I have some involvement with the 
code luckily, and it seems pretty clean to me. In particular I like the 
Berkeley DB design since that is the best solution to persistence on a GNU 
system. Abstracting the API is a good thing, but as a replacement I can't 
spot any good db code. It looks like the symbol extraction process has also 
been generalized a bit, so it gives us a framework to add support for new 
languages.

> Of course, the tricky part is how to move forward. If you just make a KDE
> version of Source-Navigator then it will only be useful to KDE folk. There
> are plenty of other development tools that could really make use of this
> functionality if it was available in an well documented and easy to use
> library format. The larger the user base, the more bugs will get worked
> out. User base is important since parsers are so bug prone. This project is
> something I was thinking about working on, but it is quite a bit of work
> and will require more than one developer.
>

I can volunteer for this project. Here is my plan:

1) Refactor sourcenav such that it can be built/used as a standalone 
programming-tool library. I'va already commenced work in this area. It 
doesn't seem to be hard.

2) Provide a generic C++ library that wraps C API.

3) A separate "kodenavigator" library that provides GUI components to 
sourcenav functions.

How does that sound?

Thanks,

- -- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8SJnsfAeuFodNU5wRAs9eAJ96oXZFnxjHvy7y+Sotlek6tA8JWwCeLzUJ
7urBCcYhlEK9QYsqLk+EdHI=
=EqUN
-----END PGP SIGNATURE-----

Re: SourceNav release ...

[Mo DeJong]

On Fri, 18 Jan 2002 23:55:53 +0200
"Eray Ozkural (exa)" <erayo@cs.bilkent.edu.tr> wrote:

...

> > I think the right solution is to turn the SN backend into a library. Even
> > if you don't reuse the code, the ideas that are there have years of effort
> > behind them and they do work. It should make use of Berkeley DB to store
> > symbols but through an API so that people can swap out other database
> > layers if they want to. It should also provide a nice two phase parse and
> > dump into symbol DB sequence that is easily inspected. Just figuring out
> > what and where the problem with a parser is can be the most difficult part
> > of fixing a problem. Also, it is absolutely critical that a well defined
> > regression test framework is developed as part of the library.
> 
> I've looked at the code more closely now. I have some involvement with the 
> code luckily, and it seems pretty clean to me. In particular I like the 
> Berkeley DB design since that is the best solution to persistence on a GNU 
> system. Abstracting the API is a good thing, but as a replacement I can't 
> spot any good db code. It looks like the symbol extraction process has also 
> been generalized a bit, so it gives us a framework to add support for new 
> languages.

There are always alternatives in the DB arena. Abstracting the DB interface
so that it does not strictly rely on Berkeley DB was all I meant. Attempting to
rewrite working code to make the DB layer more generic is about as much
fun as poking yourself in the eye (the SN code is guilty of this).

> > Of course, the tricky part is how to move forward. If you just make a KDE
> > version of Source-Navigator then it will only be useful to KDE folk. There
> > are plenty of other development tools that could really make use of this
> > functionality if it was available in an well documented and easy to use
> > library format. The larger the user base, the more bugs will get worked
> > out. User base is important since parsers are so bug prone. This project is
> > something I was thinking about working on, but it is quite a bit of work
> > and will require more than one developer.
> >
> 
> I can volunteer for this project. Here is my plan:
>
> 1) Refactor sourcenav such that it can be built/used as a standalone 
> programming-tool library. I'va already commenced work in this area. It 
> doesn't seem to be hard.
> 
> 2) Provide a generic C++ library that wraps C API.
>
> 3) A separate "kodenavigator" library that provides GUI components to 
> sourcenav functions.
> 
> How does that sound?

Sounds good, as long as #3 (or any other GUI front end) is left outside the scope
of the project. I think a key to success will be minimizing external dependencies
so that code can easily be incorporated into other projects. Then there is the
old C vs C++ debate and the discussion of which lame/broken compilers
should be supported.

I would be very interested in helping you get this project going. My initial focus
would be on a regression test suite and a Java parser. What comes next is
the age old question of labels and resources. This project will need a name and
a home. Sourceforge has some great features, but the mailing list archives
are really lame. I have always been impressed by the folks that run sourceware
(aka sources.redhat.com), but I don't know if it is the best place for such a
project.

reactions?
Mo

Re: SourceNav release ...

[Ian Roxborough]

On Fri, 18 Jan 2002 06:58:06 -0800 Mo DeJong <supermo@bayarea.net> wrote:
>
> I would be very interested in helping you get this project going. My initial focus
> would be on a regression test suite and a Java parser. What comes next is
> the age old question of labels and resources. This project will need a name and
> a home. Sourceforge has some great features, but the mailing list archives
> are really lame. I have always been impressed by the folks that run sourceware
> (aka sources.redhat.com), but I don't know if it is the best place for such a
> project.
> 
> reactions?

If you want to host it on sources.redhat.com then I'm sure I could
get a second mailing list created (sn-lib? or whatever) and create a 
module in the "sources.redhat.com:/sourcenav" repository for the
project.  It seems like this would able to stay seperate from SN,
so I don't see any copyright issues.  Of course sourceforge is pretty
cool as well and there is already one SN based project there.

Ian.

Re: SourceNav release ...

[Mo DeJong]

Ralf Corsepius wrote:

> IMHO, the basic problem is to render SN into an active project.
> As RH apparently is not developing actively anymore, one
> solution would be to convert SN into a real OpenSource
> community project.

...

> From my POV, it's only the lack of active maintainers
> which currently lets appear SN as "dumped dead code junk".

...

> But the only way to achieve something of this kind IMHO
> would be somebody (the maintainer - who is it? Ian, you?)
> to show some visible initiative - Currently, SN appears
> not only to be dead, but to unmaintained.

Well, who is going to do the work? It seems the real problem
here is one of perception. Currently, there is no person who
has the "job" of maintaining SN. Ian helps out in his spare time
but it is not part of his job description. Even if we had such a
person devoted to SN full time, would that magically produce
patches from the community? History would indicate that a
couple of patches would be donated, but not many. Read over
the mailing list archives if you don't believe me.


Khamis Abuelkomboz wrote:

> I find your input great. we need an "open" way to add work
> into SN, I had the idea about taking the current redhat SN
> and provide my own SN release, basicly to rework the GUI
> and extend the existing parsers.

There are two problems here and they depend on how you define "open".
First, there is the issue of how patches are integrated into the tree
and who gets write access to the CVS. An open patch review seems to
be the most fair way to deal with this issue. Second, there is the RH
copyright assignment paperwork. Both Khamis and I have refused to
sign these agreements which means it could be difficult to move forward
with the current hosting situation.

Timothy Shead wrote:

> Sounds like SN ought to move to SourceForge - if Red Hat
> isn't going to maintain it, there needs to be a clean
> break, so people stop waiting for Red Hat to do the work
> ... which is not to complain about Red Hat -
> they're the ones who GPL'd SN, making such a move possible.

This might be a good idea, but I am not certain. Putting it up on
SourceForge does not sprinkle the project with magic pixy dust.
Work will still need to be done, and that means someone will
actually need to do the work or pay someone to do it. You can't
just rely on the "net community" to come along and fix problems.
This "just turn is into an open source project" idea was already
attempted, in 2000. The result is where we are now, wondering
what to try next. 

cheers
Mo

Re: SourceNav release ...

[Khamis Abuelkomboz]

Eray Ozkural (exa) wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Mo,
>
>On Thursday 10 January 2002 19:45, Mo DeJong wrote:
>
>>You are correct, that is not a complete solution. You can't just hack a
>>compiler to generate symbols for your project. That works when the code is
>>perfectly correct but it will explode on code that does not compile. You
>>first reaction might be, "duh, of course the code needs to compile". Thing
>>is, users need the tool to work even if the code does not compile. This
>>fuzzy parsing functionality is not a feature you can tack on later. It
>>needs to be part of the original parser design.
>>
>
>Yes, I'm familiar with parsing issues since I had some minor involvement with 
>NLP subject. You would typically need to build your CFG parser fault-tolerant 
>>from the ground up.
>
>>I think the right solution is to turn the SN backend into a library. Even
>>if you don't reuse the code, the ideas that are there have years of effort
>>behind them and they do work. It should make use of Berkeley DB to store
>>symbols but through an API so that people can swap out other database
>>layers if they want to. It should also provide a nice two phase parse and
>>dump into symbol DB sequence that is easily inspected. Just figuring out
>>what and where the problem with a parser is can be the most difficult part
>>of fixing a problem. Also, it is absolutely critical that a well defined
>>regression test framework is developed as part of the library.
>>
>
>I've looked at the code more closely now. I have some involvement with the 
>code luckily, and it seems pretty clean to me. In particular I like the 
>Berkeley DB design since that is the best solution to persistence on a GNU 
>system. Abstracting the API is a good thing, but as a replacement I can't 
>spot any good db code. It looks like the symbol extraction process has also 
>been generalized a bit, so it gives us a framework to add support for new 
>languages.
>
>>Of course, the tricky part is how to move forward. If you just make a KDE
>>version of Source-Navigator then it will only be useful to KDE folk. There
>>are plenty of other development tools that could really make use of this
>>functionality if it was available in an well documented and easy to use
>>library format. The larger the user base, the more bugs will get worked
>>out. User base is important since parsers are so bug prone. This project is
>>something I was thinking about working on, but it is quite a bit of work
>>and will require more than one developer.
>>
>
>I can volunteer for this project. Here is my plan:
>
>1) Refactor sourcenav such that it can be built/used as a standalone 
>programming-tool library. I'va already commenced work in this area. It 
>doesn't seem to be hard.
>
>2) Provide a generic C++ library that wraps C API.
>
>3) A separate "kodenavigator" library that provides GUI components to 
>sourcenav functions.
>
>How does that sound?
>
abstracting the db stuff is a good idea. Ian brought once the idea of 
making an xml interface for
importing/reading symbol informations from/into the database, put this 
into a library. this would
abstract the database layer with an open interface. The question is, how 
much work has to be done to make such
an interface!

khamis

Re: SourceNav release ...

[Eray Ozkural (exa)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 18 January 2002 16:58, Mo DeJong wrote:
> On Fri, 18 Jan 2002 23:55:53 +0200
> "Eray Ozkural (exa)" <erayo@cs.bilkent.edu.tr> wrote:
>
>
> There are always alternatives in the DB arena. Abstracting the DB interface
> so that it does not strictly rely on Berkeley DB was all I meant.
> Attempting to rewrite working code to make the DB layer more generic is
> about as much fun as poking yourself in the eye (the SN code is guilty of
> this).
>

Well we can lower the priority of an abstract DB interface then. ;)

> Sounds good, as long as #3 (or any other GUI front end) is left outside the
> scope of the project. I think a key to success will be minimizing external
> dependencies so that code can easily be incorporated into other projects.
> Then there is the old C vs C++ debate and the discussion of which
> lame/broken compilers should be supported.
>

Sure. A GUI front end can be hosted on KDE CVS. Possibly kdenonbeta, it might 
be too alpha to include it in kdevelop.

> I would be very interested in helping you get this project going. My
> initial focus would be on a regression test suite and a Java parser. What
> comes next is the age old question of labels and resources. This project
> will need a name and a home. Sourceforge has some great features, but the
> mailing list archives are really lame. I have always been impressed by the
> folks that run sourceware (aka sources.redhat.com), but I don't know if it
> is the best place for such a project.
>

I first thought "libsourcenav" since that is what we are doing: making it 
work better as a library rather than a stand alone application. It would also 
mark the descent of the project better. For a fancier name, I thought 
"sourcemine" since we could actually run data mining programs such as 
association rule mining or sequence rule mining on databases derived from 
sourcenav project databases. Frequency mining is my current research subject, 
so I tend to think of applications of data mining rather quickly. :)

Thanks,

- -- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8SaUGfAeuFodNU5wRAnOEAJ4pyLACkFJgEh25kCGTKhc2cnsydgCfYD3T
r4Vn1UEfvjnd7B0pi1+GxAc=
=PU57
-----END PGP SIGNATURE-----

Re: SourceNav release ...

[Eray Ozkural (exa)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 19 January 2002 01:25, Ian Roxborough wrote:
>
> If you want to host it on sources.redhat.com then I'm sure I could
> get a second mailing list created (sn-lib? or whatever) and create a
> module in the "sources.redhat.com:/sourcenav" repository for the
> project.  It seems like this would able to stay seperate from SN,
> so I don't see any copyright issues.  Of course sourceforge is pretty
> cool as well and there is already one SN based project there.

sources.redhat.com would be great! It still needs some more work though. Then 
we can import a tarball to CVS. A mailing list would also be nice. What do 
you think the name of the project should be?

Sincerely,

- -- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8SaXffAeuFodNU5wRAq4KAJ9RHUb7+ZDqZG1DHIOvMtZNxJLt+gCdEFVh
Xa/AUrilBkFqGhhWDFGd+xw=
=ezNI
-----END PGP SIGNATURE-----

Re: SourceNav release ...

[Khamis Abuelkomboz]

Roman Levenstein wrote:

>Hi,
>
>>because the actual tcl parser is written in a strange
>>
>>licenced interpreter "rex?" and redhat don't have the
>>
>>origin source code and the license to this parser.
>>Also SN tcl parser doesn't support tcl/tk8.x. So if 
>>there are enough people interested in this I would
>>
>start 
>
>>writing a new parser (using flex) for tcl that
>>
>supports
>
>>tcltk8.x (without xref).
>>
I wasn't exact here, SN tcl parser doesn't support Itcl3.0!

>
>The Rex scanner generator is a part of the Cocktail
>Toolbox, which is also used for other SN parsers such
>as  Cobol and Java parsers. 
>
Yep!

>
>
>There is a public domain version of it, which can be
>found at:
>http://www.gmd.de/SCAI/lab/adaptor/cocktail.html
>
Good to know

>
>So, there is no problem with a licence. 
>
>As for the origin source for the *.rex file, it's also
>not a problem. REX specification is generated from
>*.scan file by cg tool as far as I remember. Anyway,
>there is a description of this process in the docs.
>
>
>BTW, Cocktail is one of the best compiler construction
>toolkits and it's really very powerful and much better
>than yacc/lex. It covers the whole process of compiler
>construction- from lexical and syntax analysis up to
>code generation and register allocation. And, which is
>also very important, the generated parsers and
>scanners   are much faster than those generated by
>lex/yacc.
>
Hmm, but who is familar with this toolbox? I'm not familar with the 
cocktail toolbox
and actually don't have the time to spend time learning this language.
It's true that the parsers implemented in lex/yacc are not perfekt, but 
lex is good enough
to write a parser in the 'free' time, since SN is not developed 
officially anymore!

I would appreciate very much, if you do a hack to let tcl parser 
understands
the itcl class definition "itcl:class".

khamis

>
>Roman 
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Send your FREE holiday greetings online!
>http://greetings.yahoo.com
>
>

Re: SourceNav release ...

[Roman Levenstein]

Hi,

>because the actual tcl parser is written in a strange

>licenced interpreter "rex?" and redhat don't have the

>origin source code and the license to this parser.
>Also SN tcl parser doesn't support tcl/tk8.x. So if 
>there are enough people interested in this I would
start 
>writing a new parser (using flex) for tcl that
supports
>tcltk8.x (without xref).

The Rex scanner generator is a part of the Cocktail
Toolbox, which is also used for other SN parsers such
as  Cobol and Java parsers. 

There is a public domain version of it, which can be
found at:
http://www.gmd.de/SCAI/lab/adaptor/cocktail.html

So, there is no problem with a licence. 

As for the origin source for the *.rex file, it's also
not a problem. REX specification is generated from
*.scan file by cg tool as far as I remember. Anyway,
there is a description of this process in the docs.

BTW, Cocktail is one of the best compiler construction
toolkits and it's really very powerful and much better
than yacc/lex. It covers the whole process of compiler
construction- from lexical and syntax analysis up to
code generation and register allocation. And, which is
also very important, the generated parsers and
scanners   are much faster than those generated by
lex/yacc.

Roman 



__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

Re: SourceNav release ...

[Khamis Abuelkomboz]

Except my additions and bug fixes there is at this time no other work.
Especially regarding parsers (c++ and java) nothing happens and will
happen in the next time.

Actually I'm interested to know

- how many people use SN to browse into tcl language?
- how many people use cross-reference to tcl language?

because the actual tcl parser is written in a strange licenced 
interpreter "rex?" and
redhat don't have the origin source code and the license to this parser.
Also SN tcl parser doesn't support tcl/tk8.x. So if there are enough people
interested in this I would start writing a new parser (using flex) for 
tcl that supports
tcltk8.x (without xref).

P.S. the tcl xref is pretty ugly and doesn't provide any interesting 
information.

Khamis

klmcw yahoo wrote:

>Is there another release scheduled for SourceNav ?
>
>I love the tool, but it fails to cross-reference most of the projects I
>have to deal with.
>Thanks.
>-Kevin
>
>
>

SourceNav release ...

[klmcw yahoo]

Is there another release scheduled for SourceNav ?

I love the tool, but it fails to cross-reference most of the projects I
have to deal with.
Thanks.
-Kevin