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

Re: [Lxr-dev] [ lxr-Bugs-453387 ] variable 'v' range

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

Peder O. Klingenberg wrote:

>Jason Dorje Short <js...@de...> writes:
>
>>Can LXR be set up to use a remote CVS repository as its source tree?  It
>>shouldn't be hard (althoug especially slow).
>>
>
>Not at the moment.  It needs access to the cvs file tree. :(
>
This is something I would very much like to see, since if we are to 
support other SCMs we cannot rely on being able to directly access the 
underlying files.  It seems to me that it would be possible to do this. 
 CVS.pm needs access to the following info for a file:

1) The versions of that file
2) The contents of the file

cvs status -v will give you all the tagged versions, which may be OK, 
and obviously cvs co gives the contents (as is currently done).  As you 
say, this would be pretty slow without some aggressive caching, but it 
should at least work.

>>If so, this would be a good way to set up the default configuration.
>>
>
>I agree.  Automatically indexing its own CVS tree by default, perhaps?
>But unfortunately vaporware at the moment. :(
>
Indeed.  Hmm, now, should I hack on this or on the CSS/HTML re-write :-)

Malcolm

[Lxr-dev] [ lxr-Patches-453450 ] Fixing genxref

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

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

Category: Genxref
Group: Bugfix
Status: Open
Resolution: None
Priority: 5
Submitted By: Peder O. Klingenberg (pok)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fixing genxref

Initial Comment:
Relevant exerpts of mail I sent earlier today:

Basically, finding out which versions exist is moved
into the loops,
so that the CVS backend has the ability to vary the
list of versions according to which file it's looking
at.

The cost of this is that when not using this
functionality (typically when using Plain.pm) you will
be looking up a constant value for each file.

I find that the flexibility is worth the cost, but I
may be biased. :)

With the exception of the time penalty of extra lookups
of
$config->varrange('v'), this should be exactly
equivalent to the
current version unless using closures for the range
value.

(BTW, using explicit reference to
$config->{variables}{v}{range}, like in the current
genxref, is a Bad Thing (tm).  The access method has
been there forever.  I only changed the access method
to accept closures, and everything magically worked. 
Adding an explicit reference to the underlying hash is
bad, because that will return the
closure, not the result of calling the closure.)



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

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

Re: [Lxr-dev] [ lxr-Bugs-453387 ] variable 'v' range

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

Jason Dorje Short <js...@de...> writes:

> Can LXR be set up to use a remote CVS repository as its source tree?  It
> shouldn't be hard (althoug especially slow).

Not at the moment.  It needs access to the cvs file tree. :(

> If so, this would be a good way to set up the default configuration.

I agree.  Automatically indexing its own CVS tree by default, perhaps?
But unfortunately vaporware at the moment. :(

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

Re: [Lxr-dev] [ lxr-Bugs-453387 ] variable 'v' range

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

no...@so... wrote:
> 
> Bugs item #453387, was opened at 2001-08-20 07:58
> You can respond by visiting:
> http://sourceforge.net/tracker/?func=detail&atid=390117&aid=453387&group_id=27350
> 
> Category: genxref
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Pavel Hlavnicka (pavel_hlavnicka)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: variable 'v' range
> 
> Initial Comment:
> I downloaded devel version 0.8 (no group available :)
> 
> If you use the commented out example in the lxr.conf
> how to set the range of the variable 'v' it doesn't work.
> 
> First, at the line 74 in genxref is this variable
> accesed  directly, there should be
> @versions->varrange('v') I guess.
> 
> Second, after hacking this line it still doesn't work,
> because the $LXR::Common::pathname (used in lxr.conf)
> is not set at the time of the execution. I've no clue,
> what was the original author's intention :)
> It seems, that the range sould be read once per
> processed file, because the releases (probably) and
> revisions (for sure) may differ for each file. But I
> didn't read the code so carefully to be sure.

Can LXR be set up to use a remote CVS repository as its source tree?  It
shouldn't be hard (althoug especially slow).

If so, this would be a good way to set up the default configuration.

jason

[Lxr-dev] [ lxr-Bugs-453387 ] variable 'v' range

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

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

Category: genxref
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pavel Hlavnicka (pavel_hlavnicka)
Assigned to: Nobody/Anonymous (nobody)
Summary: variable 'v' range

Initial Comment:
I downloaded devel version 0.8 (no group available :)

If you use the commented out example in the lxr.conf
how to set the range of the variable 'v' it doesn't work.

First, at the line 74 in genxref is this variable
accesed  directly, there should be
@versions->varrange('v') I guess.

Second, after hacking this line it still doesn't work,
because the $LXR::Common::pathname (used in lxr.conf)
is not set at the time of the execution. I've no clue,
what was the original author's intention :)
It seems, that the range sould be read once per
processed file, because the releases (probably) and
revisions (for sure) may differ for each file. But I
didn't read the code so carefully to be sure.

HTH

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

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

Re: [Lxr-dev] Further testing

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

On Sun, 2001-08-19 17:56:23 +0200, Jan-Benedict Glaw <jb...@lu...>
wrote in message <200...@lu...>:
> On Sun, 2001-08-19 17:24:50 +0200, Jan-Benedict Glaw <jb...@lu...>
> wrote in message <200...@lu...>:
> > On Sun, 2001-08-19 23:40:42 +0900, Malcolm Box <ma...@br...>
> > wrote in message <3B7...@br...>:
> > > Jan-Benedict Glaw wrote:
> > Seems I'm getting nearer:

Now it really seems so!

Okay, after feeling fooled some times I can now easily produce
this "lib/module/something not found" error!

> Am I now to get happy (can't find any error) or not (there was
> error and I didn't change anything)?

> Well, I just remember... While seeing these errors, I've previously
> ./genxref'ed all single tags defined in my CVS tree. Now, no longer
> seeing those errors, I've tested the --allversions switch. I'll
> come along in some minutes with new tests:-)

Well, it's always good to remember that you've changed something,
even if you *thing* that "some minor change" wouldn't "affect
anything".

I wasn't able to hit this bug after ./genxref'ing the CVS
archive with --allversions.

I'm easily to hit it with only indexing the CVS repository
in terms of single tags.

I've now indexed all tags of interest and bingo: here it is:

I'm in ./linux/ and just restarted apache (to get rid of all
those zombies and DB connections):

Req. ./kernel/:		OK, 1 DB, 0 co zombies
Req. exit.c:		OK, 2 DB, 1 co
Req. fork.c:		OK, 3 DB, 2 co
Req. mktime.c:		OK, 4 DB, 3 co
Req. panik.c:		OK, 5 DB, 4 co
Req. printk.c:		OK, 6 DB, 5 co
Req. sched.c:		BROKEN, 6 DB, 5 co /* Not all workers used? */
Reload:			OK, 6 DB, 5 co
Req. signal.c:		OK, 6 DB, 5 co
Req. sys.c		OK, 6 DB, 5 co
Req. ./linux/include:	OK, 6 DB, 5 co
Req. a_out.h:		OK, 6 DB, 5 co
Req. const.h:		BROKEN, 6 DB, 5 co
Reload:			OK, 6 DB, 5 co
Req. ./asm/		OK
Req. io.h		OK
Req. memory.h		OK
Req. segment.h		BROKEN
Reload:			OK

So there seems to be some difference between --allversions and
for i in `cat ./cvs_tags`; do
	./genxref --url="..." --version="$i"
done

MfG, JBG

-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

Re: [Lxr-dev] Further testing

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

On Sun, 2001-08-19 17:24:50 +0200, Jan-Benedict Glaw <jb...@lu...>
wrote in message <200...@lu...>:
> On Sun, 2001-08-19 23:40:42 +0900, Malcolm Box <ma...@br...>
> wrote in message <3B7...@br...>:
> > Jan-Benedict Glaw wrote:
> Seems I'm getting nearer:
> 
> Whenever I fetch a *file* (not a directory index) one "co" is opened,
> as well as a DB connection to fetch function names/variables/...
> As I think, these DB connections are not properly closed. So
> apache (aka mod_perl) keeps them opened (which is what you see as
> idle in transaction postres processes).

Well, nearly right. "co" isn't called (maybe it is, but there's
no zombie) for a directory but only for a file.

However, retrieving a directory opens a DB connection. I just
opened (recursively) all directories available in Linux v0.12.
It's nearly fine so far:

postgres  9505  0.0  0.3  8152  476 ?        S    15:24   0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data
postgres 11567  0.0  1.8  8788 2360 ?        S    17:26   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
postgres 11571  0.0  1.8  8788 2352 ?        S    17:27   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
postgres 11577  0.0  1.8  8788 2352 ?        S    17:27   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
postgres 11597  0.0  1.8  8788 2356 ?        S    17:27   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
postgres 11613  0.0  1.8  8788 2356 ?        S    17:27   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
postgres 11618  0.0  1.8  8788 2356 ?        S    17:27   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
root     11558  0.0  2.3  4560 2956 ?        S    17:26   0:00 /usr/sbin/apache
www-data 11559  0.4  4.7  8332 6040 ?        S    17:26   0:01  \_ /usr/sbin/apache
www-data 11560  0.3  4.7  8344 6052 ?        S    17:26   0:01  \_ /usr/sbin/apache
www-data 11561  0.4  4.7  8340 6044 ?        S    17:26   0:01  \_ /usr/sbin/apache
www-data 11562  0.5  4.7  8372 6076 ?        S    17:26   0:01  \_ /usr/sbin/apache
www-data 11563  0.3  4.7  8328 6028 ?        S    17:26   0:01  \_ /usr/sbin/apache
www-data 11566  0.4  4.8  8420 6112 ?        S    17:26   0:01  \_ /usr/sbin/apache

That is: one apache master, six apache workers, and six opened
DB connections.

I restart apache after I opened ./linux/kernel/ with my browser.
Retrieving "exit.c":	One opened DB connection, one co zombie (as
			a child of apache), but the HTML page
			arrived completely
Retrieving "fork.c":	2nd DB connection is opened, 2nd apache
			worker process now owns a zombied "co",
			but page os okay.
Retr. "mktime.c":	3rd DB connect, 3rc apache worker has got
			a "co" zombie, page arrived successfully.
Retr. "panik.c":	4th DB, 4th zombie, OKed page
R "printk.c":		5th DB, 5th zombie, OKed page
R "sched.c":		6th DB, 6th zombie, OKed page. Note that by
			now *all* of my apache worker processes have
			a zombie attached to them and that (I think
			so) all of them own one DB connection.
			However, I can't prove that these DB
			connections don't belong to *one* worker
			only.
R "signal.c":		Things are stable. 6 DB connections, 6
			zombies. OKed page. I don't know where
			the expected 7th co zombie has gone
			to8-)
R "sys.c":		Everything is stable at "6". OKed page.

Now I go to fetch include files (from sys.c):
"#include <errno.h>":	Stable 6pack, OKed page
"# <linux/sched.h">:	dito
"# <linux/tty.h">:	dito
"# <asm/segment.h">:	dito
"# <sys/times.h">:	dito
"# <sys/utsname.h">:	dito
"# <sys/resource.h">:	dito	# I feel fooled...

Okay, I now directly enter the ./linux/include directory:

const.h:		dito
ctypeh:			dito
errno.h:		dito	# Feeling fooled again...

Now I enter the mapped asm directory:

Mapping direction: asm/ -> asm-noarch/ -> asm/

Index of ./linux/include/asm/ is okay.

io.h:			dito
memory.h:		dito
others:			okay at "the stable six", too

So, I've now changed Vesion to 0.10, but everything is fine now.
I don't understand that. (The "lib" line is right in place...).

Am I now to get happy (can't find any error) or not (there was
error and I didn't change anything)?

Well, I just remember... While seeing these errors, I've previously
./genxref'ed all single tags defined in my CVS tree. Now, no longer
seeing those errors, I've tested the --allversions switch. I'll
come along in some minutes with new tests:-)

MfG, JBG







-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

Re: [Lxr-dev] Further testing

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

On Sun, 2001-08-19 23:40:42 +0900, Malcolm Box <ma...@br...>
wrote in message <3B7...@br...>:
> Jan-Benedict Glaw wrote:
> > Well, I think I've found some things...
> > 
> > ps axwwwf:
> > 
> > 11144 ?        Z      0:00  |   \_ [co <defunct>]
> >  8800 ?        S      0:05  \_ /usr/sbin/apache
> > 11082 ?        Z      0:00      \_ [co <defunct>]
> >  9505 pts/0    S      0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data
> > 10872 pts/0    S      0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction
> > 10874 pts/0    S      0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction
> 
> So you're seeing idle postgres processes during a execution of
> "source"?  I don't know enough about psql to know if this is normal, nor
> what sort of error this is.  Do you have any clues?

Seems I'm getting nearer:

Whenever I fetch a *file* (not a directory index) one "co" is opened,
as well as a DB connection to fetch function names/variables/...
As I think, these DB connections are not properly closed. So
apache (aka mod_perl) keeps them opened (which is what you see as
idle in transaction postres processes).

Further more, not finding libraries/modules (heck, what is it
exactly called?) starts after retrieving more or equal pages (read:
C files) from apache than there are apache child worker processes
running.

In apache, there's done some kind of round robin: Think of one
master process (getting a request) and 6 workers (sending the
requested material). The workers are handled in some kind of
ring buffer. So after a /etc/init.d/apache restart you'll
get some clean pages (as many as there are workers). Then, you'll
hit an older apache worker which already has got some opened
DB connectio.

Crash.

(Oh, yes, and there are all those zombie co's as well...)

Something then closes these DB connections (I've not got any
clue about this. It even might be that the apache master process
detects some trouble and kills one of it's worker threads and
restarts a new one).

Those new threads are ready to feed *one* clean page again...

MfG, JBG

-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

Re: [Lxr-dev] Further testing

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

On Sun, 2001-08-19 17:11:50 +0200, Jan-Benedict Glaw <jb...@lu...>
wrote in message <200...@lu...>:
> On Sun, 2001-08-19 23:40:42 +0900, Malcolm Box <ma...@br...>
> wrote in message <3B7...@br...>:
> > Jan-Benedict Glaw wrote:
> > > 10874 pts/0    S      0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction
> > 
> > So you're seeing idle postgres processes during a execution of
> > "source"?  I don't know enough about psql to know if this is normal, nor
> > what sort of error this is.  Do you have any clues?
> 
> If I remember correctly you can see this between sending a request
> and fetching the last resulting row. So you haven't fetched all
> the data.

Testing some more lets me conclude that you see this if you only
have an opened connection which served some data at any given time
before. So this is a stale (once used, but not closed) DB handle
on Perl's DBI side.

MfG, JBG

-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

Re: [Lxr-dev] Further testing

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

On Sun, 2001-08-19 23:40:42 +0900, Malcolm Box <ma...@br...>
wrote in message <3B7...@br...>:
> Jan-Benedict Glaw wrote:
> >  9505 pts/0    S      0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data
> > 10872 pts/0    S      0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction
> > 10874 pts/0    S      0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction
> 
> So you're seeing idle postgres processes during a execution of
> "source"?  I don't know enough about psql to know if this is normal, nor
> what sort of error this is.  Do you have any clues?

If I remember correctly you can see this between sending a request
and fetching the last resulting row. So you haven't fetched all
the data.

MfG, JBG

-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

Re: [Lxr-dev] Further testing

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

On Sun, 2001-08-19 23:38:19 +0900, Malcolm Box <ma...@br...>
wrote in message <3B7...@br...>:
> Jan-Benedict Glaw wrote:
> > ** Fatal: Can't locate LXR/Lang/Generic.pm in @INC (@INC contains: /
> > usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /
> > usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/
> > lib/site_perl /usr/lib/perl5/5.6 /usr/lib/perl5/5.005 . /etc/apache/
> >              /etc/apache/lib/perl) at (eval 20) line 3.
> > 
> >  ** Fatal: Can't locate object method "new" via package "LXR::Lang::
> > Generic" (perhaps you forgot to load "LXR::Lang::Generic"?) at (eval
> >                              21) line 1.
> > 
> > ** Fatal: Unable to create LXR::Lang::Generic Lang object, at /home/
> >                data/lxr-cvs/lib/LXR/Common.pm line 84.
> 
> This looks very much like the error that's caused by not being able to
> find/load a library.  Was this error message created before/after you
> re-added the "lib" line?

I see these in both cases.

> I've seen this message both with and without that line, and I have to
> say it confuses me, since I can't work out why the library is not found.

Well... "Can't locate xxx.om in @INC..." All pathes in this "@INC"
thing seem to be somewhat correct. There's only one path which
may vary: ".".  Is there any way to get the current working directory?

> > 
> > ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c
> > 
> > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing
> > 
> > ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c
> > 
> > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing
> 
> No idea about this one - though obviously it is now finding the library,
> which is bizarre.

Two possibilities:

	- It might be an error which occures because Perl failed
	  to load some of its modules/libs/whatever ("@INC" ...)
	- One request was send (through an persistent connection),
	  but not all results where fetched. Then, one had send
	  another requese...

I feel it's the firs possibility of those two:-)

> > The third load then looks better:
> > Does anybody have some hint how to get the complete page just at
> > the first shoot?

> Nope - these are the sort of problems that not finding the libraries
> seem to cause, but as you say, only on the first time through.  As the
> scripts are running under mod_perl, perhaps the changes to @INC are
> being stored from invocation to invocation, but for some reason are not
> happening early enough to enable the loading on the first path.

Don't think so. I feel it's because it wasn't able to co some
file... (Or to check it out only partially: I've got zombie
co's...)

> I'm afraid mod_perl/Perl gurus are going to be needed for this one - any
> takers?

Well... What is the easiest way to achive this:

	When exec'ing come helper command (rcsdiff, co, ...), first
	write a log into /var/log/lxr.log containing the full
	invocation command as well as the current working directory.

MfG, JBG

-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

Re: [Lxr-dev] Searching ./lib

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

On Sun, 2001-08-19 23:25:16 +0900, Malcolm Box <ma...@br...>
wrote in message <3B7...@br...>:
> Jan-Benedict Glaw wrote:
> > Why did you do this change? For me, it breaks finding all that
> > stuff in ./lib . Or is there another workaround for this I
> > missed?

> Neither of these are ideal, but equally having that line in didn't seem
> to work reliably either.  If it is helping some people I'm happy to
> re-instate it, but I'd really rather discover precisely why the right
> librarys are sometimes not found, and make sure to really fix things. 
> Any volunteers to track this down are very welcome!

I've not yet got a solution, but kind of "feeling". First of all, 
I cannot do programming in Perl. I don't know about tha language:-(
But I'm a C programmer so I can have these feelings.

My feeling wrt these "not finding some module" (is it called a
module?) is that it occures when some file could not be found or
accessed in any way. So, there are no "co" zombies, there are no
"xxxx not found" messages. These appear if (sometimes, as mentioned)
I access a mapped file (#include <asm/xxx.h>). Then, I've got
zombies, the I've got stale DB connects (or missing ones...), then
I've got error messages.

So it seems to be somewhere around the mapping code.

Being here, I've got one more question. In ./lxr.conf, I have:

         'a' => {'name'    => 'Architecture',
                 'range'   => [qw(i386 alpha arm cris ia64 m68k mips mips64 parisc ppc s390 s390x sh sparc sparc64 noarch)],
                 'default' => 'noarch'},

and

     'maps' => {
         '/include/asm-noarch/' => '/include/asm/',
         '/include/asm[^\/]*/' => '/include/asm-$a/',
         '/arch/[^\/]+/'       => '/arch/$a/',
     },

Could you explain to me why "maps" gets applied in reverse order
(ie. from last to first line) instead from first to last time?!
Could you explain to me in which way the order is determined?

MfG, JBG

-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

Re: [Lxr-dev] Further testing

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

Jan-Benedict Glaw wrote:
> Well, I think I've found some things...
> 
> ps axwwwf:
> 
>  8786 ?        S      0:00 /usr/sbin/apache
>  8787 ?        S      0:01  \_ /usr/sbin/apache
>  8788 ?        S      0:02  \_ /usr/sbin/apache
> 11126 ?        Z      0:00  |   \_ [co <defunct>]
>  8789 ?        S      0:04  \_ /usr/sbin/apache
> 11132 ?        Z      0:00  |   \_ [co <defunct>]
>  8790 ?        S      0:02  \_ /usr/sbin/apache
> 11138 ?        Z      0:00  |   \_ [co <defunct>]
>  8791 ?        S      0:02  \_ /usr/sbin/apache
> 11144 ?        Z      0:00  |   \_ [co <defunct>]
>  8800 ?        S      0:05  \_ /usr/sbin/apache
> 11082 ?        Z      0:00      \_ [co <defunct>]
>  9505 pts/0    S      0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data
> 10872 pts/0    S      0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction
> 10874 pts/0    S      0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction

So you're seeing idle postgres processes during a execution of
"source"?  I don't know enough about psql to know if this is normal, nor
what sort of error this is.  Do you have any clues?

Malcolm

Re: [Lxr-dev] Further testing

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

Jan-Benedict Glaw wrote:
> For those very old Linux kernels (v 0.01, 0.10, 0.11, 0.12) I've
> adden another "architecture", noarch. /asm-noarch/ gets mapped
> back to pure /asm/ because these old kernels had nothing else
> than i386 support. Loading pages sometimes gives me errors like

> ** Fatal: Can't locate LXR/Lang/Generic.pm in @INC (@INC contains: /
> usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /
> usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/
> lib/site_perl /usr/lib/perl5/5.6 /usr/lib/perl5/5.005 . /etc/apache/
>              /etc/apache/lib/perl) at (eval 20) line 3.
> 
>  ** Fatal: Can't locate object method "new" via package "LXR::Lang::
> Generic" (perhaps you forgot to load "LXR::Lang::Generic"?) at (eval
>                              21) line 1.
> 
> ** Fatal: Unable to create LXR::Lang::Generic Lang object, at /home/
>                data/lxr-cvs/lib/LXR/Common.pm line 84.

This looks very much like the error that's caused by not being able to
find/load a library.  Was this error message created before/after you
re-added the "lib" line?

I've seen this message both with and without that line, and I have to
say it confuses me, since I can't work out why the library is not found.

<snip>

> ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing
> 
> ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c
> 
> ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing
> 
> ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c
> 
> ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing

No idea about this one - though obviously it is now finding the library,
which is bizarre.

> The third load then looks better:
> Does anybody have some hint how to get the complete page just at
> the first shoot?

Nope - these are the sort of problems that not finding the libraries
seem to cause, but as you say, only on the first time through.  As the
scripts are running under mod_perl, perhaps the changes to @INC are
being stored from invocation to invocation, but for some reason are not
happening early enough to enable the loading on the first path.

I'm afraid mod_perl/Perl gurus are going to be needed for this one - any
takers?

Malcolm

Re: [Lxr-dev] Searching ./lib

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

Jan-Benedict Glaw wrote:
> Forst of all: I've just cvs co'ed the current LXR. It's fantastic!
> It ./genxref's my CVS tree into a postgres based DB, and it
> delivers web pages as it should. The configuration changed
> quite a bit, but I got through is once more:-) So: It's *good*
> *work*!

Thank you - it's nice to know that the lxr is appreciated.  The latest
release should be a lot better than previous ones - a lot of cleanup &
debugging has gone on.

> Why did you do this change? For me, it breaks finding all that
> stuff in ./lib . Or is there another workaround for this I
> missed?

The short answer is that I removed this because it wasn't working for
me.  Even with this line, sometimes I would get "not found" errors.  I
could never determine exactly why it would fail sometimes and work
others, so I removed this line as a contributor to the chaos.  The
work-around that I use is to explicitly link the lxr/lib directory into
my /usr/lib/perrl5/site_perl directory, or to add the right path to the
startup.perl script in the mod_perl distribution.

Neither of these are ideal, but equally having that line in didn't seem
to work reliably either.  If it is helping some people I'm happy to
re-instate it, but I'd really rather discover precisely why the right
librarys are sometimes not found, and make sure to really fix things. 
Any volunteers to track this down are very welcome!

Cheers,

Malcolm

Re: [Lxr-dev] Further testing

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

On Sun, 2001-08-19 15:58:57 +0200, Jan-Benedict Glaw <jb...@lu...>
wrote in message <200...@lu...>:
> On Sun, 2001-08-19 15:45:31 +0200, Jan-Benedict Glaw <jb...@lu...>
> wrote in message <200...@lu...>:
> 
> > So it's close getting perfect:-)
> 
> Oh, I was too fast:-(
> 
> For those very old Linux kernels (v 0.01, 0.10, 0.11, 0.12) I've
> adden another "architecture", noarch. /asm-noarch/ gets mapped
> back to pure /asm/ because these old kernels had nothing else
> than i386 support. Loading pages sometimes gives me errors like

[...]
> qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
> 1.1   www-data  001 ** Warning: DBD::Pg::st execute failed: PQsendQuer
> 
> ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing 
> ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c
> ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing 
> ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c
> ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing 

Well, I think I've found some things...

ps axwwwf:

 8786 ?        S      0:00 /usr/sbin/apache
 8787 ?        S      0:01  \_ /usr/sbin/apache
 8788 ?        S      0:02  \_ /usr/sbin/apache
11126 ?        Z      0:00  |   \_ [co <defunct>]
 8789 ?        S      0:04  \_ /usr/sbin/apache
11132 ?        Z      0:00  |   \_ [co <defunct>]
 8790 ?        S      0:02  \_ /usr/sbin/apache
11138 ?        Z      0:00  |   \_ [co <defunct>]
 8791 ?        S      0:02  \_ /usr/sbin/apache
11144 ?        Z      0:00  |   \_ [co <defunct>]
 8800 ?        S      0:05  \_ /usr/sbin/apache
11082 ?        Z      0:00      \_ [co <defunct>]
 9505 pts/0    S      0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data
10872 pts/0    S      0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
10874 pts/0    S      0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      

MfG, JBG

-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

Re: [Lxr-dev] Further testing

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

On Sun, 2001-08-19 15:45:31 +0200, Jan-Benedict Glaw <jb...@lu...>
wrote in message <200...@lu...>:

> So it's close getting perfect:-)

Oh, I was too fast:-(

For those very old Linux kernels (v 0.01, 0.10, 0.11, 0.12) I've
adden another "architecture", noarch. /asm-noarch/ gets mapped
back to pure /asm/ because these old kernels had nothing else
than i386 support. Loading pages sometimes gives me errors like

------------------------ first time loaded --------------------
Penguin      Cross-Referencing Linux            [ source navigation ]
            Linux/ include/ asm/ io.h                 [ diff markup ]
                                                [ identifier search ]
                                                  [ freetext search ]
                                                      [ file search ]
        Version:          [ v_0_12 ] [ v_0_11 ] [ v_0_10 ] [ v_0_01 ]
                      [ i386 ] [ alpha ] [ arm ] [ cris ] [ ia64 ] [
        Architecture:   m68k ] [ mips ] [ mips64 ] [ parisc ] [ ppc ]
                      [ s390 ] [ s390x ] [ sh ] [ sparc ] [ sparc64 ]
                                                           [ noarch ]
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

** Fatal: Can't locate LXR/Lang/Generic.pm in @INC (@INC contains: /
usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /
usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/
lib/site_perl /usr/lib/perl5/5.6 /usr/lib/perl5/5.005 . /etc/apache/
             /etc/apache/lib/perl) at (eval 20) line 3.

 ** Fatal: Can't locate object method "new" via package "LXR::Lang::
Generic" (perhaps you forgot to load "LXR::Lang::Generic"?) at (eval
                             21) line 1.

** Fatal: Unable to create LXR::Lang::Generic Lang object, at /home/
               data/lxr-cvs/lib/LXR/Common.pm line 84.

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

Loading it once again gives:

----------------------- First Reload --------------------------------
Penguin      Cross-Referencing Linux            [ source navigation ]
            Linux/ include/ asm/ io.h                 [ diff markup ]
                                                [ identifier search ]
                                                  [ freetext search ]
                                                      [ file search ]
        Version:          [ v_0_12 ] [ v_0_11 ] [ v_0_10 ] [ v_0_01 ]
                      [ i386 ] [ alpha ] [ arm ] [ cris ] [ ia64 ] [
        Architecture:   m68k ] [ mips ] [ mips64 ] [ parisc ] [ ppc ]
                      [ s390 ] [ s390x ] [ sh ] [ sparc ] [ sparc64 ]
                                                           [ noarch ]
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
1.1   www-data  001 ** Warning: DBD::Pg::st execute failed: PQsendQuer

** Warning: DBD::Pg::st fetchrow_array failed: no statement executing 

** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c

** Warning: DBD::Pg::st fetchrow_array failed: no statement executing 

** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c

** Warning: DBD::Pg::st fetchrow_array failed: no statement executing 

#define outb(value,port) \
                002 __asm__ ("outb %%al,%%dx"::"a" (value),"d"** Warni

** Warning: DBD::Pg::st fetchrow_array failed: no statement executing 

** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c

** Warning: DBD::Pg::st fetchrow_array failed: no statement executing 

 (port))
                003
                004
                005 #define inb(port) ({ \
                006 unsigned char _v; \
                007 __asm__ volatile ("inb %%dx,%%al":"=a" (_v):"d"** 

** Warning: DBD::Pg::st fetchrow_array failed: no statement executing 

 (port)); \
                008 _v; \
                009 })
                010
                011 #define outb_p(value,port) \
                012 __asm__ ("outb %%al,%%dx\n" \
                013                 "\tjmp 1f\n" \
                014                 "1:\tjmp 1f\n" \
                015                 "1:"::"a" (value),"d"** Warning: D

** Warning: DBD::Pg::st fetchrow_array failed: no statement executing 

 (port))
                016
[...]
---------------------------------------------------------------------

The third load then looks better:

------------------------ Second Reload -------------------------------
Penguin      Cross-Referencing Linux            [ source navigation ]
            Linux/ include/ asm/ io.h                 [ diff markup ]
                                                [ identifier search ]
                                                  [ freetext search ]
                                                      [ file search ]
        Version:          [ v_0_12 ] [ v_0_11 ] [ v_0_10 ] [ v_0_01 ]
                      [ i386 ] [ alpha ] [ arm ] [ cris ] [ ia64 ] [
        Architecture:   m68k ] [ mips ] [ mips64 ] [ parisc ] [ ppc ]
                      [ s390 ] [ s390x ] [ sh ] [ sparc ] [ sparc64 ]
                                                           [ noarch ]
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
1.1   www-data  001 #define outb(value,port) \
                002 __asm__ ("outb %%al,%%dx"::"a" (value),"d" (port))
                003
                004
                005 #define inb(port) ({ \
                006 unsigned char _v; \
                007 __asm__ volatile ("inb %%dx,%%al":"=a" (_v):"d" (p
                008 _v; \
                009 })
                010
                011 #define outb_p(value,port) \
                012 __asm__ ("outb %%al,%%dx\n" \
                013                 "\tjmp 1f\n" \
                014                 "1:\tjmp 1f\n" \
                015                 "1:"::"a" (value),"d" (port))
                016
                017 #define inb_p(port) ({ \
                018 unsigned char _v; \
                019 __asm__ volatile ("inb %%dx,%%al\n" \
                020         "\tjmp 1f\n" \
                021         "1:\tjmp 1f\n" \
                022         "1:":"=a" (_v):"d" (port)); \
                023 _v; \
                024 })
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
[ source navigation ] [ diff markup ] [ identifier search ] [ freetext
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
This page was automatically generated by the LXR             HTML 3.2
engine.                                                      Checked!
Arne Georg Gleditsch and Per Kristian Gjermshus
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
---------------------------------------------------------------------

Does anybody have some hint how to get the complete page just at
the first shoot?

MfG, JBG

-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

[Lxr-dev] Further testing

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

Hi!

I just continued testing current CVS version of lxr. I didn't find
any unusual things any more. Even --allversions seems to run fine!

So there's only that one issue with (not) searching for perl
files in ./lib/ I wrote about yesterday^Wthis night.

So it's close getting perfect:-)

MfG, JBG

-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

[Lxr-dev] Searching ./lib

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

Hi!

It's me again...

Forst of all: I've just cvs co'ed the current LXR. It's fantastic!
It ./genxref's my CVS tree into a postgres based DB, and it
delivers web pages as it should. The configuration changed
quite a bit, but I got through is once more:-) So: It's *good*
*work*!

But allow one more question:

mirror:/home/data/lxr-cvs/lxr# diff -u ../../lxr/source source 
--- ../../lxr/source    Tue Oct 31 13:52:10 2000
+++ source      Sun Aug 19 01:43:07 2001
@@ -23,10 +23,9 @@
 
 $CVSID = '$Id: source,v 1.26 2001/08/04 17:55:37 mbox Exp $ ';
 
 use strict;
-use lib do { $0 =~ m{(.*)/} ? "$1/lib" : "lib" };
 
 use LXR::Common qw(:html);
 use Local;


Why did you do this change? For me, it breaks finding all that
stuff in ./lib . Or is there another workaround for this I
missed?

MfG, JBG
PS: Even those database errors (closed connection before END) went
    away! Good work!
-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481

Re: [Lxr-dev] [ lxr-Patches-452422 ] html validator

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

Malcolm Box wrote:
> 
> no...@so... wrote:
> <snip>
> > A potential problem is that the image is only supposed
> > to be used on HTML pages that validate, which some
> > (perhaps most) of LXR is not.  The solution here, of
> > course, is to fix the HTML.
> 
> I haven't checked the html output - does it not verify against 3.2?  If
> not then we should stop displaying the icon.  Having said that I'm about
> to start a serious re-jig of the output side of lxr anyway...

No, it doesn't verify.  The first thing it notes is that html-head.html
has some spurious backslashes in it, but when this is fixed the checker
complains that in the code
  <th width="5%">
the % sign is not allowed.  This seems odd to me; I always thought that
was standard.  The checker says there may be a missing header needed to
declare the extensions being used.

I'm not sure what to make of it.  If I understood it, I'd probably have
gone ahead and fixed it...

> > I believe the templates should be very generic.  This
> > isn't the only problem with them, there's also the
> > broken penguin picture (which is not generic at all).
> 
> I agree - I think the templates could use a general overhaul, so I will
> hold off applying this patch in the hopes someone will take the time to
> do a complete overhaul.
> 
> If the html does validate, I think having the icon is appropriate so
> should stay in the template.  As for the rest, perhaps "This is a demo
> lxr site" sort of text would be best for the distributed templates?

I'd rather the templates be actually usable by a new LXR site.  This
should be easy enough to do.

BTW, my patch leaves the icon in the template, it just links to it
remotely instead of (incorrectly) assuming it's stored locally.

jason

Re: [Lxr-dev] [ lxr-Patches-452422 ] html validator

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

no...@so... wrote:
<snip>
> A potential problem is that the image is only supposed
> to be used on HTML pages that validate, which some
> (perhaps most) of LXR is not.  The solution here, of
> course, is to fix the HTML.

I haven't checked the html output - does it not verify against 3.2?  If
not then we should stop displaying the icon.  Having said that I'm about
to start a serious re-jig of the output side of lxr anyway...
 
> I believe the templates should be very generic.  This
> isn't the only problem with them, there's also the
> broken penguin picture (which is not generic at all).

I agree - I think the templates could use a general overhaul, so I will
hold off applying this patch in the hopes someone will take the time to
do a complete overhaul.

If the html does validate, I think having the icon is appropriate so
should stay in the template.  As for the rest, perhaps "This is a demo
lxr site" sort of text would be best for the distributed templates?

Malcolm

[Lxr-dev] [ lxr-Patches-452422 ] html validator

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Short (jdorje)
Assigned to: Nobody/Anonymous (nobody)
Summary: html validator

Initial Comment:
The HTML validator link included in the standard
template is broken, and links is to a local image that
won't exist.

The attached patch fixes and improves this link.  It
links to a script that specifically checks the
referring page - thus any LXR page can be checked.  It
also uses their given HTML code for accessing the "html
checked" image.

A potential problem is that the image is only supposed
to be used on HTML pages that validate, which some
(perhaps most) of LXR is not.  The solution here, of
course, is to fix the HTML.

I believe the templates should be very generic.  This
isn't the only problem with them, there's also the
broken penguin picture (which is not generic at all).

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

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

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

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

"Peder O. Klingenberg" wrote:
> Could people please test this before I commit?

Looking at this patch, it seems to suffer from one problem.  That is
that if you are using the Plain.pm backend, you must know which release
you are using before you attempt the getdir operation.  The current
version of genxref does this by reading the range variable at the head
of the indexing loop - I don't see how this patch fits in with this.

On a meta level, do we really need the ability to have the versions
specified by a closure - if the range of versions changes based on
pathnames then it's unlikely that the browsing will work smoothly, let
alone the the indexing.

I'd be very reluctant to see this patch applied before we thrash out
precisely what it is that is wanted here - for both the plain and cvs
backends.

Perhaps you could kick off by outline what it is you want to be able to
do with a CVS archive?

Malcolm

[Lxr-dev] patch tracking (was Re: /bin/true as a zombie)

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

"Peder O. Klingenberg" wrote:
> Here is a patch against current CVS tree.  It's actually been
> sitting in my tree since before Malcolms last mail on the subject, but
> like I said, I've been busy.
> 
> Could people please test this before I commit?

IMO for patch tracking it's much easier to use SF's patch tracker.  Just
submit your patch and Malcolm has things set up to send a notification
e-mail.  Then nobody has to worry about either keeping the patch around
in their mailbox or searching the list archives for it.

jason

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

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

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

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

I think I prefer them to be separate lists.  Easier to sort that way.

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