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

Re: [Lxr-dev] Tag "head" in its timeline (was: /bin/true as a zombie)

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

Per Kristian Gjermshus wrote:

>That is true. What we should probably do is to have some sort of
>utility that can remove unwanted revisions from the database. I think
>it should be up to the user to decide how and when this deletion
>should be done. One option could be to keep all revisions newer than
>the last version for instance. One of my motives for this is to enable
>lxr to implement (or merge in) the features of both cvsweb and bonsai. 
>
That's exactly what I want to see - some way of removing unused entries 
from the database.  Alas I have not come up with the magic SQL 
incantations required yet - perhaps I'll try this weekend to see what I 
can do.

Logically we need to first find all fileids that are not in any release

select f.fileid from files f, releases r where f.fileid not in {select 
fileid from releases};

Then for these fileids, we need to zap any entries in the indexes table 
where the symbol only appears in file(s) in the list.  This is 
complicated - I can't work out how the SQL would look, not being 
terribly familiar with it.  Then cleaning up the useage, status and 
symbols table should be easy.

Cheers,

Malcolm

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

[Jan-Benedict G. <jb...@lu...>]

On Thu, Aug 02, 2001 at 09:45:26AM +0200, 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.

I don't like to search a tree for all tags and take those as
--allversions. I think the "old" way in having a file (or this
Perl'ish "qw" list) in which all versions are listed is better.

There, you've got a list _the user supplied_. She may want to
only show off a number of versions, but not all of those.

It is not that handy to call genxref with all wanted versions if
you could simply take them from a file:-)


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

Which is bad. I'd loke to only have those versions which have
a user-given tag, and only those the user really *wants* to see.
So keep the traditional version list and loop over it:-)

> by the name of 'range'.  Would you be happy if --allversions just used
> the range in lxr.conf?

Yes! I think this actually is what I would prefer:-)

MfG, JBG

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

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

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.

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

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

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.

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?

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?

...Peder...
-- 
This must be Thursday.  I never could get the hang of Thursdays.

Re: [Lxr-dev] Tag "head" in its timeline (was: /bin/true as a zombie)

[Per K. G. <pe...@if...>]

* Malcolm Box
| >I have been thinking about this as well. The ideal situation would be
| >if it was a way to index every revision of every file. It would then
| >be possible to select which version of a file to view, independently
| > from the version tags.
| I'm not convinced this would work well on heavily used repositories -
| many of the versions checked in will have little or no lasting value,
| so indexing them would simply eat up space with no benefit.  Since a
| release is automatically something that people care about (else it
| wouldn't have been a release), simply indexing the releases seems to
| me to make more sense.  The linux code testbed for the lxr is atypical
| here, since the indexer is not running off the real Linux development
| repository.  So all versions of the files in the CVS repository are
| created by importing releases, resulting in all versions needing to be
| indexed.  This is certainly not true of other users of the lxr who run
| it against a live development repository.

That is true. What we should probably do is to have some sort of
utility that can remove unwanted revisions from the database. I think
it should be up to the user to decide how and when this deletion
should be done. One option could be to keep all revisions newer than
the last version for instance. One of my motives for this is to enable
lxr to implement (or merge in) the features of both cvsweb and bonsai. 

                                                 Per Kristian

Re: [Lxr-dev] Tag "head" in its timeline (was: /bin/true as a zombie)

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

pe...@if... wrote:

>I have been thinking about this as well. The ideal situation would be
>if it was a way to index every revision of every file. It would then
>be possible to select which version of a file to view, independently
>from the version tags. 
>
I'm not convinced this would work well on heavily used repositories - 
many of the versions checked in will have little or no lasting value, so 
indexing them would simply eat up space with no benefit.  Since a 
release is automatically something that people care about (else it 
wouldn't have been a release), simply indexing the releases seems to me 
to make more sense.  

The linux code testbed for the lxr is atypical here, since the indexer 
is not running off the real Linux development repository.  So all 
versions of the files in the CVS repository are created by importing 
releases, resulting in all versions needing to be indexed.  This is 
certainly not true of other users of the lxr who run it against a live 
development repository.

Cheers,

Malcolm

Re: [Lxr-dev] Tag "head" in its timeline (was: /bin/true as a zombie)

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

Jason Dorje Short wrote:

>"Peder O. Klingenberg" wrote:
>
>>Shouldn't be.  In the process of indexing (in Tagger.pm), the pathname
>>and symbol ('head') is looked up to find the actual revision of the
>>file (like '1.4').  The filename and revision is a key in the files
>>table in the database.  As the revision associated with the 'head' is
>>changed, so will the file-id in the database.  The file-id determines
>>if lxr thinks the file has been indexed before or not.
>>
Yep, this is the files table in the datamodel.  This table maintains a 
unique fileid for each (pathname, version) tuple - so the same pathname 
can have multiple fileids as new versions of the file are indexed.  The 
releases table then says which fileids comprise a release.

>Does that mean that repeatedly re-indexing on "head" will leave the old
>indexes around, and thus the database will continually grow?  That's
>less than ideal (although a small problem compared to others...).
>
Yes, this will indeed happen.   Currently there is no way to remove the 
data associated with a fileid that is no longer referenced by a release. 
 This is a problem for one of the sites I manage, since the source tree 
evolves quickly and a newly created index is over 1Gb, wasting space is 
a problem.  However, as yet I have not worked out the relevant SQL magic 
to discover which fileids are not associated with a release, and then 
which identifiers etc are found only in those files.  It may well be a 
non-trivial exercise.

Of course, dropping all the tables and re-indexing works, but since it 
takes over a week for the index to be built from scratch, it's hardly 
ideal :-)

Cheers,

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:09:31PM +0200, Jan-Benedict Glaw wrote:
> I've tested again. It now gets all versions (read: cvs tags). However,
> "co" is complaining sometimes:
> 
> < .... >
> --- /mm/memory.c 381
> co: /home/data/CVSROOT/linux//mm/memory.c,v: no side branches present for 1.4
> < .... >
> 
> Any clue about that?

I actually get that, and one other error while it performs the checkout.

*** /src/lkm/vinum/vinumkw.h
--- /src/lkm/vinum/vinumkw.h RELENG_2_2 1.3.0.2
--- /src/lkm/vinum/vinumkw.h 194
co: /home/mosch/fbsd//src/lkm/vinum/Attic/vinumkw.h,v: revision 1.3.0 absent
--- /src/lkm/vinum/vinumkw.h RELENG_3_0_0_RELEASE 1.1.1.1
--- /src/lkm/vinum/vinumkw.h 195
--- /src/lkm/vinum/vinumkw.h VINUM 1.1.1

I'll see if I can find out what's happening there after I get some lunch,
unless there's somebody who already knows...

Kevin Way

Re: [Lxr-dev] some odd problems

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

Jason Dorje Short wrote:
> 
> I'm using the CVS version of LXR on a Red Hat 7.1/i686 machine.  I'm
> using the Postgres database to cross-reference the code for NetHack.

After re-indexing (using yesterday's version of genxref), I still get
the error message:

> disconnect(DBI::db=HASH(0x81c1124)) invalidates 1 active statement.
> Either destroy statement handles or call finish on them before
> disconnecting. at lib//LXR/Index/Postgres.pm line 272.

However, now the indexing does seem to be completed, so that source
browsing works as normal.  There are no more errors of this type during
source browsing:

> ** Warning: DBD::Pg::st execute failed: ERROR:  Attribute 'symid' not found
> ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing

It seems likely that the first error message comes from trying to
disconnect the database connection before postgres is finished
processing.

jason

Re: [Lxr-dev] Tag "head" in its timeline (was: /bin/true as a zombie)

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

"Peder O. Klingenberg" wrote:
> 
> Jan-Benedict Glaw <jb...@lu...> writes:
> 
> > This leads me to some question: how does genxref react on the fact
> > that "head" may be something different each time it is called? For
> > example I could now run a genxref on the current linux kernel, and
> > I could do this 2 weeks later again. The first "head" would
> > mean all those revisions as of the older kernel's version, the
> > second "head" would be a more recent kernel. Any conflicts there?
> 
> Shouldn't be.  In the process of indexing (in Tagger.pm), the pathname
> and symbol ('head') is looked up to find the actual revision of the
> file (like '1.4').  The filename and revision is a key in the files
> table in the database.  As the revision associated with the 'head' is
> changed, so will the file-id in the database.  The file-id determines
> if lxr thinks the file has been indexed before or not.

Does that mean that repeatedly re-indexing on "head" will leave the old
indexes around, and thus the database will continually grow?  That's
less than ideal (although a small problem compared to others...).

jason

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

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

"Peder O. Klingenberg" wrote:

> See if it works better now.  I've reverted to the old behaviour in
> genxref.
> 
> The patch that tried to precompute the versions to index (patch
> #432351 "genxref usability patch" by Jason Short) states that "The
> --allversions option should now work (it didn't before, seemingly
> because of a bug)."
> 
> Without more information on exactly how it didn't work, a
> demonstration of the bug, etc, it's not really possible for me to
> determine if my changes have retriggered that last bug, so that's not
> tested, sorry.  What I do know is that the fix was conceptually
> wrong.
> 
> So Jason, if you're reading this, could you please provide some more
> details about the bug you were seeing with --allversions?

Unfortunately, I don't remember exactly what I thought the "bug" was at
the time.  I do know that --allversions didn't work for me at the time,
and that I fixed it.

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.  The current/former behavior is to traverse
the tree, and for each file index it for all possible versions.  One
possible problem here is that the tree may not be the same for all
versions - in particular, for the (non-CVS) tree I'm indexing, earlier
versions have an entirely different directory structure.

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.

jason

Re: [Lxr-dev] Tag "head" in its timeline (was: /bin/true as a zombie)

[<pe...@if...>]

* Peder O. Klingenberg
| Shouldn't be.  In the process of indexing (in Tagger.pm), the pathname
| and symbol ('head') is looked up to find the actual revision of the
| file (like '1.4').  The filename and revision is a key in the files
| table in the database.  As the revision associated with the 'head' is
| changed, so will the file-id in the database.  The file-id determines
| if lxr thinks the file has been indexed before or not.

I have been thinking about this as well. The ideal situation would be
if it was a way to index every revision of every file. It would then
be possible to select which version of a file to view, independently
from the version tags. 

                                           Per Kristian

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

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

Jan-Benedict Glaw <jb...@lu...> writes:

> I've tested again. It now gets all versions (read: cvs tags). 

Good.

> However, "co" is complaining sometimes:

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.

> At least, it gets more and more perfect:-)

It sucks marginally less for each checkin, but it still beats most
industrial vaucuum cleaners ;)

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

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

[Jan-Benedict G. <jb...@lu...>]

On Wed, Aug 01, 2001 at 01:31:46PM +0200, Peder O. Klingenberg wrote:
> pe...@kl... (Peder O. Klingenberg) writes:
> 
> > Jan-Benedict Glaw <jb...@lu...> writes:
> >
> > > It now seems to recognize revisions of a file correctly. However,
> > > it's still only indexing "head" when called with --allversions.
> > 
> > I'll fix that sometime today, I guess.
> 
> The patch that tried to precompute the versions to index (patch
> #432351 "genxref usability patch" by Jason Short) states that "The
> --allversions option should now work (it didn't before, seemingly
> because of a bug)."

I've tested again. It now gets all versions (read: cvs tags). However,
"co" is complaining sometimes:

---------------------------- cut -------------------------------
### /mm/memory.c
--- /mm/memory.c head 1.4
/mm/memory.c was already referenced
--- /mm/memory.c jbglaw_0_13 1.4
/mm/memory.c was already referenced
--- /mm/memory.c jbglaw_0_13_b 1.4.0.2
--- /mm/memory.c 381
co: /home/data/CVSROOT/linux//mm/memory.c,v: no side branches present for 1.4
--- /mm/memory.c v_0_01 1.1
--- /mm/memory.c 382
+++ 1
--- /mm/memory.c v_0_10 1.2
--- /mm/memory.c 383
+++ 265
--- /mm/memory.c v_0_11 1.3
--- /mm/memory.c 384
+++ 278
--- /mm/memory.c v_0_12 1.4
/mm/memory.c was already referenced
---------------------------- cut -------------------------------

Any clue about that?

At least, it gets more and more perfect:-)

MfG, JBG

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

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

pe...@kl... (Peder O. Klingenberg) writes:

> Jan-Benedict Glaw <jb...@lu...> writes:
>
> > It now seems to recognize revisions of a file correctly. However,
> > it's still only indexing "head" when called with --allversions.
> 
> I'll fix that sometime today, I guess.

See if it works better now.  I've reverted to the old behaviour in
genxref.

The patch that tried to precompute the versions to index (patch
#432351 "genxref usability patch" by Jason Short) states that "The
--allversions option should now work (it didn't before, seemingly
because of a bug)."

Without more information on exactly how it didn't work, a
demonstration of the bug, etc, it's not really possible for me to
determine if my changes have retriggered that last bug, so that's not
tested, sorry.  What I do know is that the fix was conceptually
wrong.

So Jason, if you're reading this, could you please provide some more
details about the bug you were seeing with --allversions?

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

Re: [Lxr-dev] Tag "head" in its timeline (was: /bin/true as a zombie)

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

Jan-Benedict Glaw <jb...@lu...> writes:

> This leads me to some question: how does genxref react on the fact
> that "head" may be something different each time it is called? For
> example I could now run a genxref on the current linux kernel, and
> I could do this 2 weeks later again. The first "head" would
> mean all those revisions as of the older kernel's version, the
> second "head" would be a more recent kernel. Any conflicts there?

Shouldn't be.  In the process of indexing (in Tagger.pm), the pathname
and symbol ('head') is looked up to find the actual revision of the
file (like '1.4').  The filename and revision is a key in the files
table in the database.  As the revision associated with the 'head' is
changed, so will the file-id in the database.  The file-id determines
if lxr thinks the file has been indexed before or not.

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

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

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

Jan-Benedict Glaw <jb...@lu...> writes:

> This bug is pinned down. 

Good.

> It now seems to recognize revisions of a file correctly. However,
> it's still only indexing "head" when called with --allversions.

This is with the newest genxref, right?  The problem there is the same
as before, namely that when you give it --allversions, it just looks
up all the versions of the root of your source tree, and assumes
that is all the versions there are.  Which is wildly wrong.  For CVS
use, you really need to test each file.

I'll fix that sometime today, I guess.

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

[Lxr-dev] Tag "head" in its timeline (was: /bin/true as a zombie)

[Jan-Benedict G. <jb...@lu...>]

On Wed, Aug 01, 2001 at 10:31:08AM +0200, Peder O. Klingenberg wrote:
> Jan-Benedict Glaw <jb...@lu...> writes:
> > > > ### /mm/Makefile  
> > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > Hmmm. Yes, there are 6 {tag,branche}s for that file:
> > 
> > www-data@mirror:/home/data/CVSROOT/linux/mm$ head  -n 11 Makefile,v 
> > head    1.4;
    ^^^^

This leads me to some question: how does genxref react on the fact
that "head" may be something different each time it is called? For
example I could now run a genxref on the current linux kernel, and
I could do this 2 weeks later again. The first "head" would
mean all those revisions as of the older kernel's version, the
second "head" would be a more recent kernel. Any conflicts there?

MfG, JBG

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

[Jan-Benedict G. <jb...@lu...>]

On Wed, Aug 01, 2001 at 10:31:08AM +0200, Peder O. Klingenberg wrote:
> Jan-Benedict Glaw <jb...@lu...> writes:
> > www-data@mirror:/home/data/CVSROOT/linux/mm$ head  -n 11 Makefile,v 
> > head    1.4;
> > access;
> > symbols
> >         jbglaw_0_13:1.4
> >         jbglaw_0_13_b:1.4.0.2
> >         v_0_12:1.4
> >         v_0_11:1.3
> >         v_0_10:1.2
> >         v_0_01:1.1;
> > locks; strict;
> > comment @# @;
> 
> I squashed this one, I think.  Stupid regexp-bug in CVS.pm trying to
> determine the actual revision.  Trying to match a number like 1.4, it
> instead matched the first 0 in the symbol.

This bug is pinned down. It now seems to recognize revisions of a
file correctly. However, it's still only indexing "head" when called
with --allversions.

MfG, JBG

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

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

Jan-Benedict Glaw <jb...@lu...> writes:

> > > ### /mm/Makefile  
> > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > 
> > Hm.  It gets as far as trying to check out the file, but seems to
> > somehow get confused over which version to check out.  Trying six
> > times would indicate that it's trying to check out six different
> > versions.  Or something.
> 
> Hmmm. Yes, there are 6 {tag,branche}s for that file:
> 
> www-data@mirror:/home/data/CVSROOT/linux/mm$ head  -n 11 Makefile,v 
> head    1.4;
> access;
> symbols
>         jbglaw_0_13:1.4
>         jbglaw_0_13_b:1.4.0.2
>         v_0_12:1.4
>         v_0_11:1.3
>         v_0_10:1.2
>         v_0_01:1.1;
> locks; strict;
> comment @# @;

I squashed this one, I think.  Stupid regexp-bug in CVS.pm trying to
determine the actual revision.  Trying to match a number like 1.4, it
instead matched the first 0 in the symbol.

Updated CVS.pm checked in.

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

[Lxr-dev] trouble with postgres -- connection closing

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

i'm attempting to use lxr to index the FreeBSD kernel source tree, in CVS
format, in the first pass i'm just indexing the head.  i'm doing this on a
redhat 7.1 machine, with postgresql 7.1.2, for what it's worth.

after a little over two minutes if i'm hitting already referenced code, or
after a long, variable amount of time if it's actually using the database
i end up getting the error:

DBD::Pg::st execute failed: PQsendQuery() -- There is no connection to the =
backend. at lib//LXR/Index/Postgres.pm line 253.

I'm not sure how I should go about adding in something that does...

if (!$dbh->ping()) {=20
	$dbh =3D DBI->connect($dbname);
	$die($DBI::errstr) unless $dbh;
}

because then I also have to update all the $foo_select, $foo_nextval,
$foo_insert, $foo_update vars whould would still be referencing an invalid
database handle.

Anybody have any suggestions for how they feel this bug should be fixed?

Kevin Way

[Lxr-dev] some odd problems

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

I'm using the CVS version of LXR on a Red Hat 7.1/i686 machine.  I'm
using the Postgres database to cross-reference the code for NetHack.

genxref runs fine on the first 10 or so code versions, however in the
middle of indexing one version listed it dies with the following
message:

disconnect(DBI::db=HASH(0x81c1124)) invalidates 1 active statement.
Either destroy statement handles or call finish on them before
disconnecting. at lib//LXR/Index/Postgres.pm line 272.

If I repeat the genxref call, it ends up giving the same error.  If I
restart the postgres daemon, it still gives the same error.

(Now, the version it dies on is the _first_ one listed, but certainly
not the first one indexed.  Does genxref index them in reverse order? 
Alphabetical?)


At the end of this, if I use LXR to view the source through HTTP, I get
all sorts of errors like:

** Warning: DBD::Pg::st execute failed: ERROR:  Attribute 'symid' not
found
** Warning: DBD::Pg::st fetchrow_array failed: no statement executing

However, these seem to be inconsistent, perhaps not appearing all the
time (?).  Also, nothing is referenced.

http://devon.dhs.org/lxr/nethack/source
http://devon.dhs.org/lxr/nethack/source/src/botl.c

I've used the old (0.3) version of LXR successfully on this same code:
http://nethack.dhs.org/.


This doesn't seem like a very helpful report, but I don't know what else
to say...

jason short

[Lxr-dev] [ lxr-Patches-446603 ] ectags deprecated --lang option

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

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

Category: Genxref
Group: Bugfix
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Way (mosch)
Assigned to: Nobody/Anonymous (nobody)
Summary: ectags deprecated --lang option

Initial Comment:
ectags has eliminated --lang, in favor of
--language-force.  This change was made in Generic.pm,
but not in C.pm

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

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

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

[Jan-Benedict G. <jb...@lu...>]

On Tue, Jul 31, 2001 at 01:32:02PM +0200, Peder O. Klingenberg wrote:
> Jan-Benedict Glaw <jb...@lu...> writes:
> 
> > > Yep.  It's a bug in the database interface libraries.
> > 
> > Do you know in which part of it? LXR's handler routines? Perl'S DBI
> > interface? Or in PostgreSQL's libpq?
> 
> My current theory is that it's in the interaction between Perls DBI
> and LXRs Postgres and MySQL modules.  It's discussed in the bugracker
> at SF, See
> <https://sourceforge.net/tracker/index.php?func=detail&aid=428513&group_id=27350&atid=390117>

I've done further tests.

- Drop database lxr-cvs
- Create DB lxr-cvs
- psql lxr-cvs --> \i initdb-postgres
- ./genxref --url="http://mirror.microdata-pos.de/lxr-cvs" --allversions
	--> Indexes only head, without database error
	--> all other tags are ignored
- ./genxref --url="http://mirror.microdata-pos.de/lxr-cvs" --allversions
	--> Prints warnings that those files were already referenced and
	    exits with database error
	--> Only head is indexed, all other tags are ignored

The used genxref is current sourceforge CVS.

MfG, JBG

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

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

Jan-Benedict Glaw <jb...@lu...> writes:

> > Yep.  It's a bug in the database interface libraries.
> 
> Do you know in which part of it? LXR's handler routines? Perl'S DBI
> interface? Or in PostgreSQL's libpq?

My current theory is that it's in the interaction between Perls DBI
and LXRs Postgres and MySQL modules.  It's discussed in the bugracker
at SF, See
<https://sourceforge.net/tracker/index.php?func=detail&aid=428513&group_id=27350&atid=390117>

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

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

[Jan-Benedict G. <jb...@lu...>]

On Tue, Jul 31, 2001 at 12:51:07PM +0200, Peder O. Klingenberg wrote:
> Jan-Benedict Glaw <jb...@lu...> writes:
> 
> > [...]
> > ### /lib/wait.c  
> > --- /lib/wait.c head 1.2
> > /lib/wait.c was already referenced
> > ### /lib/write.c  
> > --- /lib/write.c head 1.2
> > /lib/write.c was already referenced
> 
> Did you empty the database before running genxref?  Otherwise you may

Not exactly...

> have stuff lying around in the tables that makes genxref think you
> already indexed these files.
> 
> > ### /mm/Makefile  
> > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low
> 
> Hm.  It gets as far as trying to check out the file, but seems to
> somehow get confused over which version to check out.  Trying six
> times would indicate that it's trying to check out six different
> versions.  Or something.

Hmmm. Yes, there are 6 {tag,branche}s for that file:

www-data@mirror:/home/data/CVSROOT/linux/mm$ head  -n 11 Makefile,v 
head    1.4;
access;
symbols
        jbglaw_0_13:1.4
        jbglaw_0_13_b:1.4.0.2
        v_0_12:1.4
        v_0_11:1.3
        v_0_10:1.2
        v_0_01:1.1;
locks; strict;
comment @# @;



"jbglaw_0_13_b" is a branch, everything else is a tag.

> > Which is also triggered with the older CVS version of gnexref you mentioned
> > above.
> 
> Yep.  It's a bug in the database interface libraries.

Do you know in which part of it? LXR's handler routines? Perl'S DBI
interface? Or in PostgreSQL's libpq?

> > If it could help you, I'd package my complete LXR installation (
> > functional and non-functional as well) and send it to you...
> 
> Yes, thank you, that would be good.  Especially if you include the CVS
> tree you're trying to index (it's a good thing it's linux kernels, so
> I don't have to sign anything :) ).  I don't need the ping version,
> only the sourceforge version.

Okay, I'll send it in PM shortly... Thank you so far!

MfG, JBG