lxr-developer — Don't use, active developers only

Re: [Lxr-dev] cvsignore file

[Malcolm B. <ma...@br...>]

Jason Dorje Short wrote:
> 
> A file called .cvsignore should be created within the root LXR
> directory, and the following contents added to it:

Done - thanks for pointing that out.  I'd forgotten about .cvsignore
files!

Malcolm

RE: [Lxr-dev] genxref hangs after genindex phase

[CORRAL,JOSEPH (HP-Boise,ex1) <jos...@hp...>]

> -----Original Message-----
> From: Malcolm Box [mailto:ma...@br...]
> Sent: Tuesday, August 14, 2001 8:11 AM
> To: lxr...@li...
> Subject: Re: [Lxr-dev] genxref hangs after genindex phase
> 
> 
> "CORRAL,JOSEPH (HP-Boise,ex1)" wrote:
> > 
> > I tried to index my repository using genxref 1.21, and it 
> got hung up on me.
> > It stalled after the genindex phase.  From what I can tell, 
> the problem was
> > in the following lines.
> > 
> > 066 foreach (@versions) {
> > 067  genindex('/', $_);
> > 068  genrefs('/', $_);
> > 069 }
> > 
> > $_ is not local and it is changed while genindex is 
> executed, and this
> > causes a problem when line 68 is executed.
> > 
> > I have submitted a simple patch, 450662, that uses a local 
> variable instead.
> > Everything seems to be working for me now.  Let me know if 
> I've missed
> > something.
> 
> Thanks, I've applied a variation on this patch.
> 
> Just out of interest, are you using the CVS backend or the Plain one -
> with a combination of Plain & Mysql here, the previous version worked
> ok, and I'm curious which module is tramping on $_

I am using the CVS backend.
Cheers,
JEC


> 
> Cheers,
> 
> Malcolm
> 
> _______________________________________________
> Lxr-developer mailing list
> Lxr...@li...
> http://lists.sourceforge.net/lists/listinfo/lxr-developer
> 

[Lxr-dev] cvsignore file

[Jason D. S. <js...@de...>]

A file called .cvsignore should be created within the root LXR
directory, and the following contents added to it:

lxr.conf
html-dir.html
html-head.html
html-search.html
html-tail.html

This will cause CVS to ignore these files (as it should).

jason

[Lxr-dev] Re: [Lxr-commits] CVS: lxr/lib/LXR Tagger.pm,1.16,1.17

[Malcolm B. <ma...@br...>]

Jens-Uwe Mager wrote:
> 
> Would it be possible to make the diffs -u (unified format)? That is much
> easier to read.

It would, so I've changed it over to produce unified diffs.  I hope...

Malcolm

[Lxr-dev] lxr 0.8 released

[Malcolm B. <ma...@br...>]

Hi all,

I've just released version 0.8 of the lxr.  This is still a development
release, but it marks a major step towards the 1.0 release.  Thanks to
all the people who sent in patches or filed bug reports for their help
in getting this release ready.

Here's the changes and new features (those I can remember, anyway):

* Generic language support added.  All languages supported by ctags
5.0.1 can now be used with lxr - just add some information to
lib/LXR/Lang/generic.conf to configure
* Filename <-> language mapping now controlled by lxr.conf
* New templates to make setting up clearer
* Java browsing now works
* Much improved C++ support
* In multi-language environments, keywords in a language are no longer
hyperlinked if a different language happens to have them as an
identifier
* Memory leak in genxref fixed
* genxref now has working --allversions support
* Which files to treat as images is now configured from lxr.conf 
* Binary files in the CVS backend work properly thanks to pok.

Please download this new version and try it out - as always, bouquets
and brickbats are both welcome.

Cheers,

Malcolm

[Lxr-dev] Should CVS messages go to this list?

[Malcolm B. <ma...@br...>]

Hi all,

Having created the lxr-commits list specifically for notifications of
CVS commits, it occurred to me that other developers might prefer the
messages to go to this list rather than have YAML (Yet Another Mailing
List) to deal with.

So what's the opinion - should they go to just lxr-commits, to just
lxr-developer or to both?

Cheers,

Malcolm

Re: [Lxr-dev] genxref hangs after genindex phase

[Malcolm B. <ma...@br...>]

"CORRAL,JOSEPH (HP-Boise,ex1)" wrote:
> 
> I tried to index my repository using genxref 1.21, and it got hung up on me.
> It stalled after the genindex phase.  From what I can tell, the problem was
> in the following lines.
> 
> 066 foreach (@versions) {
> 067  genindex('/', $_);
> 068  genrefs('/', $_);
> 069 }
> 
> $_ is not local and it is changed while genindex is executed, and this
> causes a problem when line 68 is executed.
> 
> I have submitted a simple patch, 450662, that uses a local variable instead.
> Everything seems to be working for me now.  Let me know if I've missed
> something.

Thanks, I've applied a variation on this patch.

Just out of interest, are you using the CVS backend or the Plain one -
with a combination of Plain & Mysql here, the previous version worked
ok, and I'm curious which module is tramping on $_

Cheers,

Malcolm

[Lxr-dev] CVS commits notification

[Malcolm B. <ma...@br...>]

Hi all,

I've set up a new list to recieve automatic notification of commits to
the lxr repository.  It's called lxr...@li...
(unsurprisingly!) and you can subscribe at
http://lists.sourceforge.net/lists/listinfo/lxr-commits

Cheers,

Malcolm

[Lxr-dev] genxref hangs after genindex phase

[CORRAL,JOSEPH (HP-Boise,ex1) <jos...@hp...>]

I tried to index my repository using genxref 1.21, and it got hung up on me.
It stalled after the genindex phase.  From what I can tell, the problem was
in the following lines.

066 foreach (@versions) {
067  genindex('/', $_);
068  genrefs('/', $_);
069 }

$_ is not local and it is changed while genindex is executed, and this
causes a problem when line 68 is executed.

I have submitted a simple patch, 450662, that uses a local variable instead.
Everything seems to be working for me now.  Let me know if I've missed
something.

Regards,

Joseph

[Lxr-dev] [ lxr-Patches-450662 ] Bug fix for Bug 450660

[<no...@so...>]

Patches item #450662, was opened at 2001-08-13 18:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390119&aid=450662&group_id=27350

Category: Genxref
Group: Bugfix
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph Corral (jcorral)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug fix for Bug 450660

Initial Comment:
I have changed the calls to genindex and genrefs in 
genxref to use a local variable, rather than $_, and 
everything seems to be working.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390119&aid=450662&group_id=27350

[Lxr-dev] [ lxr-Bugs-450660 ] genxref 1.21 hangs after genindex phase

[<no...@so...>]

Bugs item #450660, was opened at 2001-08-13 17:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=450660&group_id=27350

Category: genxref
Group: current cvs
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph Corral (jcorral)
Assigned to: Nobody/Anonymous (nobody)
Summary: genxref 1.21 hangs after genindex phase

Initial Comment:
After checking out version 1.21 of genxref and 
attempting to re-index my repository, I found that it 
hangs immediately after the genindex phase.  My guess 
would be that the value of $_ has changed by the time 
line 68,   genrefs('/', $_);, is executed.

JEC

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=450660&group_id=27350

Re: [Lxr-dev] Re: move to lxr.tigris.org?

[Malcolm B. <ma...@br...>]

Jens-Uwe Mager wrote:
> 
> On Thu, Aug 09, 2001 at 12:36:57AM +0900, Malcolm Box wrote:
> > I like what you're trying to do with tigris.org, and I'm sure we will be
> > able to collaborate on various things (like support for subversion in
> > lxr) despite not being hosted on the same site.
> 
> Isn't tigris.org python oriented? I am pretty fond of perl and I see no
> reason to switch to python. If I remember right they changed the cons build
> system project from perl to python.

It doesn't appear to be.  Looking around, there seemed to be more Java
than anything else.  Even if we were to move to tigis.org (which we're
not), it would be a folly to re-implement lxr in Python.  Whether or not
people prefer perl or python, there's lots of code for lxr and it's in
perl, so perl it will stay :-)

Of course, what we *really* need is a common object system so you can
mix and match perl, python, java, c/c++ etc.....

Malcolm

Re: [Lxr-dev] Re: move to lxr.tigris.org?

[Per K. G. <pk...@ne...>]

* Malcolm Box
| As for actually switching to tigris.org for hosting, I'm less keen.  The
| move to sourceforge was recent enough that I have no wish to go through
| the hassles of another move, and I'm not convinced that the benefits of
| tigris.org are sufficently strong at the moment to make it worth while. 
| Of course, if the majority of the developers want to move and there's
| volunteers to do it, then that's fine.  But I won't be volunteering
| :-)

I just want to agree with Malcolm here. I will be watching Tigris.org
closely, but I don't think it would be wise of us to change right now.
If we sometime find out that Tigris.org will service us much better it
could be worth it, but at the moment I am sure that a move will be
harmful to LXR as a project. If Tigris.org is serious about using LXR,
I hope that they will understand that it will serve them the best as
well if the development of LXR is successful. If we had considered
Tigris.org earlier the outcome might have been different, but at the
moment I believe it is too late to change. 


                                                   Per Kristian

Re: [Lxr-dev] Re: move to lxr.tigris.org?

[Jens-Uwe M. <ju...@he...>]

On Thu, Aug 09, 2001 at 12:36:57AM +0900, Malcolm Box wrote:
> I like what you're trying to do with tigris.org, and I'm sure we will be
> able to collaborate on various things (like support for subversion in
> lxr) despite not being hosted on the same site.

Isn't tigris.org python oriented? I am pretty fond of perl and I see no
reason to switch to python. If I remember right they changed the cons build
system project from perl to python.

-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	ju...@he...

[Lxr-dev] Re: move to lxr.tigris.org?

[Malcolm B. <ma...@br...>]

Jason Robbins wrote:
>   I noticed your project on sourceforge and I think it is a great
> idea.  Actually, it is very much in line with the tigris.org mission
> statement of building a better open source project hosting toolset and
> promoting open source software engineering tools in general.
> 
> My goal is to actually use ctags and lxr on tigris.org as the main
> source code browsing tool.  But, I also see a lot of overlap in your
> lxr tool and my broader goals for "tools for software understanding"
> to be developed in the tigris.org community.  The current tigris.org
> projects get a lot of good "foot traffic" because of popular projects
> like ArgoUML, Scarab, and Subversion.

I'm glad you think the tool is useful, and I'd like to see it used on
Tigris.org.  If there's anything you need to make this happen, then do
give a shout on the lxr...@li... mailing list and we'll do
what we can.


> Why switch from sourceforge.net to tigris.org?
> 
> + we are building a better hosting platform that might include your
> tool.
> 
> + community is focused on open source software engineering tools and
> already has a lot of interested engineers and relevant projects, which
> is likely to lead to more actual contributors to your project.
> 
> + better security
> 
> + easier web publishing with version control
> 

As for actually switching to tigris.org for hosting, I'm less keen.  The
move to sourceforge was recent enough that I have no wish to go through
the hassles of another move, and I'm not convinced that the benefits of
tigris.org are sufficently strong at the moment to make it worth while. 
Of course, if the majority of the developers want to move and there's
volunteers to do it, then that's fine.  But I won't be volunteering :-)

I like what you're trying to do with tigris.org, and I'm sure we will be
able to collaborate on various things (like support for subversion in
lxr) despite not being hosted on the same site.

Regards,

Malcolm

[Lxr-dev] [ lxr-Bugs-449164 ] Memory leak in genxref

[<no...@so...>]

Bugs item #449164, was opened at 2001-08-08 08:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=449164&group_id=27350

Category: genxref
Group: current cvs
Status: Open
Resolution: None
Priority: 8
Submitted By: Malcolm Box (mbox)
Assigned to: Malcolm Box (mbox)
Summary: Memory leak in genxref

Initial Comment:
Using genxref to index source causes memory useage to
grow continuously until all available memory is
consumed

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=449164&group_id=27350

Re: [Lxr-dev] DB connection bug

[Malcolm B. <ma...@br...>]

"Peder O. Klingenberg" wrote:
> 
> Malcolm Box <ma...@br...> writes:
> 
> > I have a possible fix that I'm testing out at the moment with Mysql.pm
> > (I don't have Postgres installed yet).  This is to make the $dbh handle
> > local to each Mysql object ie $self->{dbh} rather than a package
> > variable.  I've also made all the sql statements object variables rather
> > than package ones.
> >
> > This then lets the connection be closed via a DESTROY subroutine
> > whenever the index object goes out of scope.
> 
> Wow, what syncronicity.
> 
> I've done the same thing with Postgres.  While this solves the problem
> seen with genxref, I now get complaints about not being able to call
> commit during global gc or destruction or something (I don't recall
> the exact message) during execution of the source script.  I haven't
> quite figured that out yet.

I'm not seeing any errors, but then again I'm not calling commit :-)  If
I try calling commit, I get a message saying that it's ineffective when
autocommit is in operation.  All this is with MySQL.

Since this approach gets rid of the warnings and seems to work well, I'm
going to go ahead and submit it.

Now there's just the matter of the memory leak that seems to be there -
genxref balloons to more than 30Mb when indexing my test tree, and I
don't see any reason for that sort of memory consumption.

Cheers,

Malcolm

[Lxr-dev] [ lxr-Bugs-447980 ] Generic config missing

[<no...@so...>]

Bugs item #447980, was opened at 2001-08-04 11:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=447980&group_id=27350

Category: Lang support
Group: current cvs
Status: Open
Resolution: None
Priority: 5
Submitted By: Malcolm Box (mbox)
Assigned to: Malcolm Box (mbox)
Summary: Generic config missing

Initial Comment:
The generic.conf file for Generic.pm does not have
entries for most of the languages that ctags supports. 
This means that these languages cannot be used, even
though the code support is in place.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=447980&group_id=27350

[Lxr-dev] [ lxr-Bugs-447979 ] Java import hyperlinking

[<no...@so...>]

Bugs item #447979, was opened at 2001-08-04 11:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=447979&group_id=27350

Category: Browsing
Group: current cvs
Status: Open
Resolution: None
Priority: 5
Submitted By: Malcolm Box (mbox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Java import hyperlinking

Initial Comment:
Java import statement hyperlinking is not as good as it
could be, since it doesn't link to the file being
imported.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=447979&group_id=27350

Re: [Lxr-dev] DB connection bug

[<pe...@kl...>]

Malcolm Box <ma...@br...> writes:

> I have a possible fix that I'm testing out at the moment with Mysql.pm
> (I don't have Postgres installed yet).  This is to make the $dbh handle
> local to each Mysql object ie $self->{dbh} rather than a package
> variable.  I've also made all the sql statements object variables rather
> than package ones.
> 
> This then lets the connection be closed via a DESTROY subroutine
> whenever the index object goes out of scope.  

Wow, what syncronicity.

I've done the same thing with Postgres.  While this solves the problem
seen with genxref, I now get complaints about not being able to call
commit during global gc or destruction or something (I don't recall
the exact message) during execution of the source script.  I haven't
quite figured that out yet.

...Peder...
-- 
Cogito ergo panta rei.

[Lxr-dev] DB connection bug

[Malcolm B. <ma...@br...>]

Kevin Way wrote:
 
> Any chance you've made progress on the DB connection bug?

I have a possible fix that I'm testing out at the moment with Mysql.pm
(I don't have Postgres installed yet).  This is to make the $dbh handle
local to each Mysql object ie $self->{dbh} rather than a package
variable.  I've also made all the sql statements object variables rather
than package ones.

This then lets the connection be closed via a DESTROY subroutine
whenever the index object goes out of scope.  I think this is a nice
solution since I can't find any guarantee on the ordering of END blocks
between packages which Peder has pointed out could cause the problem.
I plan to test this change for a bit here and then release it if it
continues to work.  

I imagine a similar approach would work for Postgres as well.

Cheers,

Malcolm

Re: [Lxr-dev] genxref and warnings from cvs co (was: /bin/true as a zombie)

[<pe...@kl...>]

Kevin Way <kev...@ov...> writes:

> Any chance you've made progress on the DB connection bug?

Not really, but I have made some progress on the co thing instead,
which was at least for me several different bugs.

1) Somehow the %cvs hash wasn't cleared when new files were being
   parsed.  The result was that we'd try to check out non-existant
   versions.  One-line fix, I think I already committed that one.  I
   do _so_ hate global variables.

2) Some of my CVS files contained symbols pointing to non-existant
   versions.  Since LXR always translates symbols to versions before
   checking out, that also resulted in trying to check out
   non-existant versions, and also resulted in the branching errors.
   The fix I have is that I run a consistency check on the symbols,
   deleting the ones that have no corresponding version.
   Unfortunately that seems to make genxref even slower.  Noticeably
   slow.  Alternatively that may have been a problem with our server,
   which had problems with one of its CPUs, its swap and at least some
   of its raid disks yesterday.  

   I'd like some feedback on wether this seems like an acceptable fix,
   or wether we'd rather just live with co failing from time to time.

3) I had some errors where co complained about premature end of file
   or someting.  These were on binary files (jpegs), and it's entirely
   possible that the files are corrupt.  I have ignored these for now.


...Peder...
-- 
Cogito ergo panta rei.

Re: [Lxr-dev] Re: /bin/true as a zombie

[Malcolm B. <ma...@br...>]

Peder O. Klingenberg wrote:

>Jason Dorje Short <js...@de...> writes:
>
>>No doubt I'm missing something, but I don't understand why my change was
>>conceptually wrong.  I took each version to be indexed, and traversed
>>the tree for that version.  
>>
>But you can't find the versions to be indexed by asking for the
>versions of the root of the tree.  In a CVS tree, each file can have a
>differing number of versions, have completely different tags, etc.
>
Absolutely true.  Simply because files are in the same CVS archive 
doesn't mean that they are even logically in the same project, let alone 
the same release!  However, with the plain file storage, the versions 
are physically separate, and in other SCM systems they could either be 
physically separate (a different pathname) or simply different versions.

>>The current/former behavior is to traverse the tree, and for each
>>file index it for all possible versions.  
>>
>
>Yes, that was the point.  Unless you specify a version, you get all
>the versions a file has to offer.
>
>That was at least the concept I had of --allversions, and your patch
>didn't fit that concept.  Hence conceptually wrong.  It may of course
>well be that my concepts are different from yours, in which case it's
>a matter of opinion which version (pun intended) to hold as the
>correct one.
>
I think this is the key difference between people using CVS.pm and those 
using Plain.pm.  You can't traverse a filetree in Plain.pm and ask what 
versions the file has, since the different versions have different 
locations.  On the other hand, with CVS each file can have multiple 
versions.

>>BTW, the new genxref doesn't work for me again.  It runs through all
>>versions just as if everything had already been indexed, even
>>immediately after I drop and re-create the database.
>>
Same for me here - file->allversions() doesn't seem to work for 
Plain.pm.  I think some test code for the lxr is badly needed :-)

>Maybe this is because Plain.pm and CVS.pm disagree on how to compute
>allreleases?  I've never looked at Plain.pm, so I don't know.
>
That would appear to be the problem, looking at Plain.pm

>It seems to me that this is an area that needs more customization,
>because we obviously disagree, and I suspect that we both have equally
>valid views.  And as it so happens, we have a configuration variable
>by the name of 'range'.  Would you be happy if --allversions just used
>the range in lxr.conf?
>
That seems to me to be the best solution - then the user gets to pick 
what versions are indexed, and it's easy to make range be equivalent to 
the current "allversions" for the CVS backend.

>I've already patched Config.pm to accept closures for this variable in
>order to get the cgi scripts to display versions based on the versions
>of each file, so I think I could make this work for me.
>
>It would still need to use the original control flow in order to allow
>the flexibility I need, but specifying a constant range list (or file)
>in lxr.conf should give the same semantics as precomputing the
>versions to index, should it not?
>
It would, yes.

Malcolm

Re: [Lxr-dev] genxref and warnings from cvs co (was: /bin/true as a zombie)

[Kevin W. <kev...@ov...>]

On Wed, Aug 01, 2001 at 02:24:44PM +0200, Peder O. Klingenberg wrote:
> 
> Yes, I saw that here as well.  Currently I'm chasing the DB connection
> bug, which is really beginning to irritate me.  When I have a grip on
> that, I'll look at the co thing.

Any chance you've made progress on the DB connection bug?

Re: [Lxr-dev] Re: /bin/true as a zombie

[Jason D. S. <js...@de...>]

"Peder O. Klingenberg" wrote:
> 
> Jason Dorje Short <js...@de...> writes:
> 
> > No doubt I'm missing something, but I don't understand why my change was
> > conceptually wrong.  I took each version to be indexed, and traversed
> > the tree for that version.
> 
> But you can't find the versions to be indexed by asking for the
> versions of the root of the tree.  In a CVS tree, each file can have a
> differing number of versions, have completely different tags, etc.

Here is my problem...I didn't realize it was "asking".

> It may of course
> well be that my concepts are different from yours, in which case it's
> a matter of opinion which version (pun intended) to hold as the
> correct one.

My opinion is that it should work for everyone :-)

Obviously, right now things will work for _either_ CVS or static.

> It seems to me that this is an area that needs more customization,
> because we obviously disagree, and I suspect that we both have equally
> valid views.  And as it so happens, we have a configuration variable
> by the name of 'range'.  Would you be happy if --allversions just used
> the range in lxr.conf?

Actually, that's what I thought it *was* doing, which is why I thought
my code was good.

Yes, I would be much happier if that's what happened.  What happens
right now?  Does it index every possible version?

jason