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

[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: v2-dev
>Status: Closed
Resolution: Postponed
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-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: v2-dev
Status: Open
>Resolution: Postponed
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-482977 ] declarations table not in 1NF

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

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

Category: Database interface
Group: current cvs
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Malcolm Box (mbox)
Assigned to: Malcolm Box (mbox)
Summary: declarations table not in 1NF

Initial Comment:
The new declarations table is joined to indexes via
declid and langid.  But currently declid is globally
unique, so the langid field in indexes is redundant,
though it might speed up language based searching.
If declid was made non-unique across languages it would
mean that languages could manage their own namespace
without having to get a declid assigned from the
database.  However, having it unique makes the indexes
lookup faster.

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

>Comment By: Malcolm Box (mbox)
Date: 2001-12-06 06:40

Message:
Logged In: YES 
user_id=215386

The table is normalised if you consider the tuple (langid,
declid) to be the key.  Currently declid is globally unique,
but this may change.

The design is cleaner as it is, so NGTF

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

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

[Lxr-dev] [ lxr-Bugs-489129 ] lib/LXR/Lang/Generic.pm Line 45

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

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

Category: None
Group: v0.9
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Malcolm Box (mbox)
Summary: lib/LXR/Lang/Generic.pm Line 45

Initial Comment:
open (X, $config->genericconf) || die "Can't open 
$config->genericconf, $!";

is probably wrong

open (X, $config->genericconf) || die "Can't 
open ".$config->genericconf.", $!";

should do the trick ;)

regrets stefan

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

>Comment By: Malcolm Box (mbox)
Date: 2001-12-06 06:38

Message:
Logged In: YES 
user_id=215386

Thanks, good catch.

Fixed as suggested. 

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

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

[Lxr-dev] [ lxr-Bugs-489129 ] lib/LXR/Lang/Generic.pm Line 45

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

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

Category: None
Group: v0.9
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: lib/LXR/Lang/Generic.pm Line 45

Initial Comment:
open (X, $config->genericconf) || die "Can't open 
$config->genericconf, $!";

is probably wrong

open (X, $config->genericconf) || die "Can't 
open ".$config->genericconf.", $!";

should do the trick ;)

regrets stefan

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

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

[Lxr-dev] [ lxr-Feature Requests-481579 ] generate static pages

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

Feature Requests item #481579, was opened at 2001-11-13 21:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390120&aid=481579&group_id=27350

Category: General
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: generate static pages

Initial Comment:
Hi:

Although I'm still battling to make it work, it's a
great project. I just have a simple wish:

- Give lxr an option to generate static pages for a
piece of code. Take my case: I frequently have to study
some pieces of code. lxr can speed up a lot my work,
but I don't have access to a web server. What I would
like to do (and generally do with html manuals) is to
burn a cd with the code cross referenced, and be able
to browse it at leisure. I already tried to do that
with a wget -r of a branch of the linux kernel, but it
didn't work.

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

>Comment By: Malcolm Box (mbox)
Date: 2001-11-28 05:35

Message:
Logged In: YES 
user_id=215386

What was it specifically that didn't work for you?

The problem might be that in addition to each file of source
(the output of the source program) you also need the ident
output for each of the symbols used.  Which might be several
thousand.  If the symbols then are referenced in file
outside the tree you're interested in then the spider could
get confused.

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

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

[Lxr-dev] [ lxr-Feature Requests-433936 ] Remove dependance on glimpse

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

Feature Requests item #433936, was opened at 2001-06-17 08:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390120&aid=433936&group_id=27350

Category: General
Group: Next Release
Status: Open
Priority: 5
Submitted By: Malcolm Box (mbox)
>Assigned to: Arne Georg Gleditsch (argggh)
Summary: Remove dependance on glimpse

Initial Comment:
The current free text search interface relies on the
glimpse package, which is not Free software.  Thus we
should try to move to a free work-alike.

Suggestions (from Neil Slater):

I know mngosearch has been suggested before now:

http://search.mnogo.ru/

...as has htdig:

http://www.htdig.org/

However, whilst trying to locate the mngo URL, I
chanced across the
following page which also lists a number of other free
search/indexing
engines:

http://twiki.org/cgi-bin/view/Codev/SearchAttachments


Note that there is slightly more to this work than just
ripping out glimpse, although that would be a start. 
The current code assumes that the files to be indexed
are stored in a plain directory tree, and therefore
will not work with the CVS or other File backend.  This
would really need to be fixed.

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

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

[Lxr-dev] [ lxr-Bugs-481573 ] requires non-free software for searching

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 9
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Arne Georg Gleditsch (argggh)
Summary: requires non-free software for searching

Initial Comment:
On your front page you suggest Glimpse, which is
horridly non-free:
http://www.arco.de/~kj/harvest/glimpse-license-status

This program is GPL, so a user might assume that it's
dependancies are GPL. 

Please provide hooks for Swish-E http://swish-e.org/ or
Swish++
http://homepage.mac.com/pauljlucas/software/swish/
which are GPL replacements.
If I am in error and this feature allready exists in
lxr, please change the content of http://lxr.linux.no/
to suggest Swish-E or Swish++.


I might note that I caught this as a part of our
department's implementation of Bugzilla (bonsai uses
lxr) which is a mission-critical application for
development here, and now that we know that Glimpse has
*never* been in the public domain (the source we found
had a misleading copyright file) we need to find a
replacement or pay up before the audit rolls around.

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

Comment By: Rusty Carruth (rustyc)
Date: 2001-11-14 06:25

Message:
Logged In: YES 
user_id=215914

There *is* a version of glimpse (I think around 4.0) which
does 
not require a fee.  This is the version we are using.  A
temporary workaround would be to grab that version and use
it while 
'someone' is fixing lxr to use the free alternative.

(We found that version of glimpse by looking around on the
'net till we found it.)

rc


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

Comment By: Malcolm Box (mbox)
Date: 2001-11-14 00:06

Message:
Logged In: YES 
user_id=215386

I agree, depending on non-free software for a tool like LXR
is not a good thing.  Moving over to one of the free
alternatives is on the to-do list.

If you wanted to go ahead and provide the hooks for a
replacement, I'd be very happy to incorporate the patch in
the LXR.

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

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

[Lxr-dev] [ lxr-Bugs-483898 ] "** Fatal: Can't locate" Errors

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

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

Category: Browsing
Group: v0.9
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Hideaki Suzuki (h1suzuki)
>Assigned to: Malcolm Box (mbox)
>Summary: "** Fatal: Can't locate" Errors

Initial Comment:
Lxr 0.9 from the latest cvs cannot generate html of 
unknown type files. i.e. files w/ unspecified 
extentions.
for instance, if you click on "Makefile.linux" which 
is supposedly the linux version of a Makefile, you 
can't grab the browsably generated html code from lxr, 
but you'll get something like

-----------
** Fatal: Can't locate LXR/Lang/Generic.pm in @INC 
(@INC contains: /usr/lib/perl5/5.6.0/i386-
linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6
.0/i386-
linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/sit
e_perl . /etc/httpd/ /etc/httpd/lib/perl) at (eval 18) 
line 3.

** Fatal: Can't locate object method "new" via 
package "LXR::Lang::Generic" at (eval 19) line 1.

** Fatal: Unable to create LXR::Lang::Generic Lang 
object,  at xxxx/lxr/lib/LXR/Common.pm line 71.
-----------

instead.

it is more preferable to make a plain text output 
<pre>ed w/ the html header/footers than a crash in 
perl.

tia.


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

>Comment By: Malcolm Box (mbox)
Date: 2001-11-28 05:09

Message:
Logged In: YES 
user_id=215386

Fixed by adding a PERL5LIB line to .htaccess.
Due to the way mod_perl works, any additions to @INC made by
the script are only used on the first compile of the
script.  So if we need to load a module after that then it
won't work, hence the transient errors.

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

Comment By: Hideaki Suzuki (h1suzuki)
Date: 2001-11-21 04:09

Message:
Logged In: YES 
user_id=254086

my lxr testbed from the latest cvs already has had "use lib 
do {....};" at the top of the "source" script.

PerlSetEnv does helps in my case.
i appreciate your comment & hope the investigation will 
turn out nicely.

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

Comment By: Malcolm Box (mbox)
Date: 2001-11-20 19:37

Message:
Logged In: YES 
user_id=215386

This "Can't locate" bug is under investigation, but at the
moment there's no easy way to reliably reproduce it, nor to
fix it.

I don't think this is specific to unknown filetypes - I've
seen this error occur in other situations.

You could try adding:

use lib do { $0 =~ m{(.*)/} ? "$1/lib" : "lib" };

to the top of the "source" script (after "use strict;") and
see if this helps.

Otherwise, you can add a line like:

PerlSetEnv PERL5LIB /path/to/lxr/lxr/lib

to your .htaccess file which might help.

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

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

Re: [Lxr-dev] Problem with genxref and PostgreSQL

[Arne G. G. <ar...@li...>]

* Jan-Benedict Glaw
> Unable to create LXR::Lang::Generic Lang object, Can't locate object
> method "fetchrow_array" via package "decl_select" at
> lib/LXR/Index/Postgres.pm line 289.
>
>
> Any hints there on?

This is also a result of the database layout changes.  There are
patches to be found in the mailinglist archives, but it would probably
be nice if they found their way into CVS as well.  Guys?


							Arne.

[Lxr-dev] Problem with genxref and PostgreSQL

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

Hi!

I'm trying to index a CVS tree:

weiss-ich-doch-nicht:/home/data/lxr$ ./genxref
--url="http://weiss-ich-doch-nicht.microdata-pos.de/lxr"
--version=v_0_01
*** / v_0_01 
*** /boot/ v_0_01 
*** /boot/boot.s v_0_01 
*** /boot/head.s v_0_01 
*** /fs/ v_0_01 
*** /fs/Makefile v_0_01 
Unable to create LXR::Lang::Generic Lang object, Can't locate object
method "fetchrow_array" via package "decl_select" at
lib/LXR/Index/Postgres.pm line 289.


Any hints there on?

MfG, JBG

-- 
Jan-Benedict Glaw   .   jb...@lu...   .   +49-172-7608481
	http://lug-owl.de/~jbglaw/software/snapshot2cvs/

[Lxr-dev] PostgreSQL backend

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

Hi!

My box is alive again, so I'm starting testing...

First of all, current initdb-postgres is broken in several
ways:

- My PostgreSQL soesn't know about "tinyint", so I changed
  it so read like "smallint".

- Table "declarations" is referenced before it gets created.
  Bad...

- Still a remaining bug. I cannot create table "indexes":

	NOTICE:  CREATE TABLE will create implicit trigger(s)
		 for FOREIGN KEY check(s)
	NOTICE:  Illegal FOREIGN KEY definition REFERENCES
		 "declarations"
	ERROR:   number of key attributes in referenced table
		 must be equal to foreign key
		 
  Could somebody please look at this?

Here's my preliminary patch to start hacking:


Index: initdb-postgres
===================================================================
RCS file: /cvsroot/lxr/lxr/initdb-postgres,v
retrieving revision 1.4
diff -u -r1.4 initdb-postgres
--- initdb-postgres	2001/11/18 03:31:33	1.4
+++ initdb-postgres	2001/11/27 10:59:41
@@ -28,11 +28,18 @@
 
 );
 
+create table declarations
+	(declid     smallint not null,
+	langid		smallint not null,
+	declaration	char(255) not null,
+	primary key (declid, langid)
+); 
+
 create table indexes (
 	symid		int		references symbols,
 	fileid		int		references files,
 	line		int,
-	langid		tinyint not null references declarations,
+	langid		smallint not null references declarations,
 	type		smallint not null references declarations,
 	relsym		int		references symbols
 );
@@ -54,13 +61,6 @@
 	status		smallint,
 	primary key	(fileid)
 );
-create table declarations
-	(declid     smallint not null,
-	langid		tinyint not null,
-	declaration	char(255) not null,
-	primary key (declid, langid)
-); 
-
 create index indexindex on indexes using btree (symid);
 create index symbolindex on symbols using btree (symname);
 create index usageindex on usage using btree (symid);

-- 
Jan-Benedict Glaw   .   jb...@lu...   .   +49-172-7608481
	http://lug-owl.de/~jbglaw/software/snapshot2cvs/

Re: [Lxr-dev] Swish-E

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

On Wed, 2001-11-21 at 23:04, Arne Georg Gleditsch wrote:
> Patch follows.  Note though, that the way I've implemented this seems
> to require Swish-E newer than the currently stable 2.0.5.  This might
> or might not be a problem.  Anyway, have a look at it.

I tried the non-development version during the weekend and found the
indexer to be extremely slow. It used a lot of memory, and made my
machine crawl under heavy swappping. It actually took so long that I
never got around to start writing any code for using Swish-E, so it's
great that you got around to do it. 

                                           Per Kristian

[Lxr-dev] Swish-E

[Arne G. G. <ar...@li...>]

Since someone suggested Swish-E as a replacement for Glimpse, I had a
look at this today.  I'm extremely impressed.  While Swish-E doesn't
report line numbers or text excerpts with its results, it is extremely
fast at indexing (and searching).  I ran 2.4.15pre6 through it in just
over 2 minutes.  Hooking it into genxref added 20% or somewhat to
that, but then you get the LXR backend-abstraction in between there.
(So it should work with the CVS backend, but I didn't test that.)

I've hooked Swish-E (version 2.1-dev-24) into "genxref" and "search"
with relatively little work.  The implementation uses the old "one
freetext index database per version"-scheme, but could, with
relatively little work, have used the "one revision indexed only once
regardless of the amount of versions it belongs to"-scheme.  I'm not
sure if it would be much of a win, but it might be worth looking into
sometime.  I've kept the glimpse bits in "search" (which was a
horrible piece of code, it wasn't even under use strict) in case
someone wants to rehook Glimpse into LXR.  Glimpse has some
advantages, as noted above, so I suppose it is conceivable.

Patch follows.  Note though, that the way I've implemented this seems
to require Swish-E newer than the currently stable 2.0.5.  This might
or might not be a problem.  Anyway, have a look at it.


							Arne.

Re: [Lxr-dev] New database structure about to land

[Arne G. G. <ar...@li...>]

* Malcolm Box
> Interesting suggestion, but I don't think so.  The error I see is
> usually for Generic.pm from somewhere in Common.pm.  The thing is,
> Common.pm is in lib/LXR as well, so how did the script manage to find
> Common.pm and then be unable to find lib/LXR/Lang?
>
> As I understand the search mechanism in perl, first you replace the ::
> with /, then search each directory in @INC for the file X/Y/Z.pm (for
> module X::Y::Z).  So if you can find lib/LXR/Common.pm from LXR::Common,
> surely you can find lib/LXR/Lang/Generic.pm from LXR::Lang::Generic? 

Indeed.  This is probably one of the nuisances of mod_perl.  Take a
look at http://perl.apache.org/guide/porting.html#_INC_and_mod_perl.
Short summary: @INC will only be what it would normally be (with
regards to "use lib" and other in-script modifications) the first time
you run the script.  After that, it'll be reset to the default again.

This means that all the modules you didn't load the very first time
you ran the script will be subject to the original @INC search path
when you try to load them.  So, if your apache/mod_perl-process is
fresh when you try to load a file using LXR::Lang::Generic, you'll be
ok.  If it isn't and something not using LXR::Lang::Generic was the
first thing handed out by the apache/mod_perl-process you happen to be
served by now, you'll have to load it afresh without your "use
lib"-modified @INC to support you.  Given that there's probably at
least a handful of separate apache-processes making up your web
server, the amount of randmoness in the system makes the bug rather
elusive.  I've found that

PerlSetEnv PERL5LIB lib

in .htaccess actually does it for me.  I think this (or an @INC-
modifying script loaded via PerlRequire as the one you use) should
probably be distributed with LXR.


							Arne.

[Lxr-dev] [ lxr-Bugs-483898 ] "** Fatal: Can't locate" Errors

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

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

Category: Browsing
Group: v0.9
Status: Open
Resolution: None
Priority: 8
Submitted By: Hideaki Suzuki (h1suzuki)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "** Fatal: Can't locate" Errors

Initial Comment:
Lxr 0.9 from the latest cvs cannot generate html of 
unknown type files. i.e. files w/ unspecified 
extentions.
for instance, if you click on "Makefile.linux" which 
is supposedly the linux version of a Makefile, you 
can't grab the browsably generated html code from lxr, 
but you'll get something like

-----------
** Fatal: Can't locate LXR/Lang/Generic.pm in @INC 
(@INC contains: /usr/lib/perl5/5.6.0/i386-
linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6
.0/i386-
linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/sit
e_perl . /etc/httpd/ /etc/httpd/lib/perl) at (eval 18) 
line 3.

** Fatal: Can't locate object method "new" via 
package "LXR::Lang::Generic" at (eval 19) line 1.

** Fatal: Unable to create LXR::Lang::Generic Lang 
object,  at xxxx/lxr/lib/LXR/Common.pm line 71.
-----------

instead.

it is more preferable to make a plain text output 
<pre>ed w/ the html header/footers than a crash in 
perl.

tia.


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

>Comment By: Hideaki Suzuki (h1suzuki)
Date: 2001-11-21 04:09

Message:
Logged In: YES 
user_id=254086

my lxr testbed from the latest cvs already has had "use lib 
do {....};" at the top of the "source" script.

PerlSetEnv does helps in my case.
i appreciate your comment & hope the investigation will 
turn out nicely.

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

Comment By: Malcolm Box (mbox)
Date: 2001-11-20 19:37

Message:
Logged In: YES 
user_id=215386

This "Can't locate" bug is under investigation, but at the
moment there's no easy way to reliably reproduce it, nor to
fix it.

I don't think this is specific to unknown filetypes - I've
seen this error occur in other situations.

You could try adding:

use lib do { $0 =~ m{(.*)/} ? "$1/lib" : "lib" };

to the top of the "source" script (after "use strict;") and
see if this helps.

Otherwise, you can add a line like:

PerlSetEnv PERL5LIB /path/to/lxr/lxr/lib

to your .htaccess file which might help.

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

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

[Lxr-dev] [ lxr-Bugs-483898 ] "** Fatal: Can't locate" Errors

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

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

Category: Browsing
Group: v0.9
Status: Open
Resolution: None
>Priority: 8
Submitted By: Hideaki Suzuki (h1suzuki)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "** Fatal: Can't locate" Errors

Initial Comment:
Lxr 0.9 from the latest cvs cannot generate html of 
unknown type files. i.e. files w/ unspecified 
extentions.
for instance, if you click on "Makefile.linux" which 
is supposedly the linux version of a Makefile, you 
can't grab the browsably generated html code from lxr, 
but you'll get something like

-----------
** Fatal: Can't locate LXR/Lang/Generic.pm in @INC 
(@INC contains: /usr/lib/perl5/5.6.0/i386-
linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6
.0/i386-
linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/sit
e_perl . /etc/httpd/ /etc/httpd/lib/perl) at (eval 18) 
line 3.

** Fatal: Can't locate object method "new" via 
package "LXR::Lang::Generic" at (eval 19) line 1.

** Fatal: Unable to create LXR::Lang::Generic Lang 
object,  at xxxx/lxr/lib/LXR/Common.pm line 71.
-----------

instead.

it is more preferable to make a plain text output 
<pre>ed w/ the html header/footers than a crash in 
perl.

tia.


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

>Comment By: Malcolm Box (mbox)
Date: 2001-11-20 19:37

Message:
Logged In: YES 
user_id=215386

This "Can't locate" bug is under investigation, but at the
moment there's no easy way to reliably reproduce it, nor to
fix it.

I don't think this is specific to unknown filetypes - I've
seen this error occur in other situations.

You could try adding:

use lib do { $0 =~ m{(.*)/} ? "$1/lib" : "lib" };

to the top of the "source" script (after "use strict;") and
see if this helps.

Otherwise, you can add a line like:

PerlSetEnv PERL5LIB /path/to/lxr/lxr/lib

to your .htaccess file which might help.

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

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

Re: [Lxr-dev] New database structure about to land

[Kristoffer G. <to...@pi...>]

[ Arne Georg Gleditsch ]

> d.declid in Kristoffer's Postgres.pm patch (in the setting of
> $indexes_select) should be d.declaration as far as I'm able to see.
> That's the way it looks in Mysql.pm, at least.

Yep, seems you're right.  I was a bit confused by the fact that it's
declid and langid that are the primary keys of declarations and
referenced from indexes.

-- 
Kristoffer.

Re: [Lxr-dev] New database structure about to land

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

Arne Georg Gleditsch wrote:

>* Malcolm Box
>
>>indexes.type is still indexes.type, but it now references
>>declarations.declid.  indexes.langid references declarations.langid. 
>>Non-normalised I know - see the bug report ;-)
>>
>
>Ah, like so.  But if langid is a functional dependency of declid,
>couldn't you just make declid the primary key of declarations and be
>done with it?  You could even remove langid from the indexes table,
>possibly with a significant size gain.
>
Yes, you could.  The current code is stuck in a half-way house between 
my original idea (declid is the one and only key) and a proposal from 
Robin that a (langid, declid) tuple would be better.

What we've ended up with is that the indexes table assumes that the 
(langid, declid) tuple is the foreign key, while because of how the 
declarations table is generated is actually just using declid as the 
primary key.

I'm tempted to more to the tuple as the key, since this makes it easier 
to filter indexes by language without joining onto declarations.  It 
seems to me that langid could become a reasonably useful thing to have 
in the indexes table, rather than hanging out in the declarations table 
where it doesn't really fit as dependant info.

>Anyway, I still think I'm right.  d.declid in Kristoffer's Postgres.pm
>patch (in the setting of $indexes_select) should be d.declaration as
>far as I'm able to see.  That's the way it looks in Mysql.pm, at least.
>
Yes, in indexes_select the value that is to be returned from the select 
should be d.declaration, as that is the string that gets displayed.

Malcolm

Re: [Lxr-dev] New database structure about to land

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

Arne Georg Gleditsch wrote:
> 
>  <Files ~ (find|search|source|ident|diff|cgi-bin)$>
>  SetHandler perl-script
>  PerlHandler Apache::Registry
> +PerlSetEnv PERL5LIB /home/argggh/src/ping/lxr/lib
>  </Files>
> 
> A bit gross perhaps, but it works.

I do something similar using startup.pl or by putting links in
/usr/lib/perl5 somewhere.  Again, gross, but it works.  Now if only I
could work out why it doesn't work ;-)

> > - Fixed the occasional typo; a forgotten $ and a place where a field
> >   in the database had changed name from type to declid.
> 
> I think d.type is now d.declaration, actually, but I'm not sure.
> Malcolm?

indexes.type is still indexes.type, but it now references
declarations.declid.  indexes.langid references declarations.langid. 
Non-normalised I know - see the bug report ;-)
 
> Additionally, I tried indexing 2.4.8 on my laptop using this setup.  I
> had to restart the indexing process a few times, and in so doing I
> ended up profiling genxref a bit and trimming the database-activity
> some.  I think something like this would be nice:

<snip patch>

Funnily enough I thought of this too the other day - sharing the
generic.conf stuff definitely makes sense.  Patch going in. 

Cheers,

Malcolm

Re: [Lxr-dev] New database structure about to land

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

Hi all,

Robin Theander wrote:
> 
> Hi all,
> 
> Kristoffer Gleditsch wrote:
> > I run into the error mentioned in <200...@lu...>
> > pretty often: "** Fatal: Can't locate LXR/Lang/Generic.pm in @INC
> > (@INC contains: ...".  It's the same module it complains about every
> > time, but I'm not very familiar with mod_perl, so I don't know where
> > to start debugging it.
> 
> I have seen this as well. The lib/LXR stuff looked a bit odd to me and after I
> added a link LXR -> lib/LXR problems has gone away.

/me too ;-)

This is something that seems to occur on a maddeningly non-repeatable
basis.

> Is the lib directory in the way?

Interesting suggestion, but I don't think so.  The error I see is
usually for Generic.pm from somewhere in Common.pm.  The thing is,
Common.pm is in lib/LXR as well, so how did the script manage to find
Common.pm and then be unable to find lib/LXR/Lang?

As I understand the search mechanism in perl, first you replace the ::
with /, then search each directory in @INC for the file X/Y/Z.pm (for
module X::Y::Z).  So if you can find lib/LXR/Common.pm from LXR::Common,
surely you can find lib/LXR/Lang/Generic.pm from LXR::Lang::Generic? 
What makes things even stranger is that a reload of the page usually
clears the error - and I would have thought that a path error would be
permanent.

So this one has me flumoxed - I need to find some good ways to debug
mod_perl and track down what's going on.  Assistance welcome.

Malcolm

[Lxr-dev] [ lxr-Bugs-483898 ] "** Fatal: Can't locate" Errors

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

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

Category: Browsing
Group: v0.9
Status: Open
Resolution: None
Priority: 5
Submitted By: Hideaki Suzuki (h1suzuki)
Assigned to: Nobody/Anonymous (nobody)
Summary: "** Fatal: Can't locate" Errors

Initial Comment:
Lxr 0.9 from the latest cvs cannot generate html of 
unknown type files. i.e. files w/ unspecified 
extentions.
for instance, if you click on "Makefile.linux" which 
is supposedly the linux version of a Makefile, you 
can't grab the browsably generated html code from lxr, 
but you'll get something like

-----------
** Fatal: Can't locate LXR/Lang/Generic.pm in @INC 
(@INC contains: /usr/lib/perl5/5.6.0/i386-
linux /usr/lib/perl5/5.6.0 /usr/lib/perl5/site_perl/5.6
.0/i386-
linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/sit
e_perl . /etc/httpd/ /etc/httpd/lib/perl) at (eval 18) 
line 3.

** Fatal: Can't locate object method "new" via 
package "LXR::Lang::Generic" at (eval 19) line 1.

** Fatal: Unable to create LXR::Lang::Generic Lang 
object,  at xxxx/lxr/lib/LXR/Common.pm line 71.
-----------

instead.

it is more preferable to make a plain text output 
<pre>ed w/ the html header/footers than a crash in 
perl.

tia.


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

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

Re: [Lxr-dev] New database structure about to land

[Arne G. G. <ar...@li...>]

* Malcolm Box
> indexes.type is still indexes.type, but it now references
> declarations.declid.  indexes.langid references declarations.langid. 
> Non-normalised I know - see the bug report ;-)

Ah, like so.  But if langid is a functional dependency of declid,
couldn't you just make declid the primary key of declarations and be
done with it?  You could even remove langid from the indexes table,
possibly with a significant size gain.

Anyway, I still think I'm right.  d.declid in Kristoffer's Postgres.pm
patch (in the setting of $indexes_select) should be d.declaration as
far as I'm able to see.  That's the way it looks in Mysql.pm, at least.


							Arne.

Re: [Lxr-dev] VHDL support and other stuff

[Robin T. <Rob...@te...>]

Hi Malcolm,

Malcolm Box wrote:
> A random thought that strayed across my neurones - what would be the
> effort to get your parser integrated into ctags?  I think ctags has a
> reasonably well-defined extension system, and if it was in ctags then
> (a) all the LXR support would be in place and (b) all the other tools
> like emacs/vi etc that use ctags would also benefit.

I also crossed my mind. I can think of one problem. The lex/yacc parser is not
very "robust". If the grammar is wrong the parser quits. I don't know what is
required for a ctags parser. If it should continue parsing to grab as many
idents as possible even in case of syntax errors, my parser has a problem.

And second, I already have the new rewritten GPL'ed parser running. The lxr
perl overhead is small (when the new db structure is implemented). Only
Lang/VHDL.pm should be added beside the parser which is 3 files (Makefile,
vhdl.lex and vhdl.yacc).

When I get bored I'll take a look at ctags.

Robin.

-- 
ASIC Design Engineer
Tellabs Denmark A/S

Direct: +45 4473 2942
rob...@te...

Re: [Lxr-dev] New database structure about to land

[Robin T. <Rob...@te...>]

Hi all,

Kristoffer Gleditsch wrote:
> I run into the error mentioned in <200...@lu...>
> pretty often: "** Fatal: Can't locate LXR/Lang/Generic.pm in @INC
> (@INC contains: ...".  It's the same module it complains about every
> time, but I'm not very familiar with mod_perl, so I don't know where
> to start debugging it.

I have seen this as well. The lib/LXR stuff looked a bit odd to me and after I
added a link LXR -> lib/LXR problems has gone away.

Is the lib directory in the way?

Robin.

-- 
ASIC Design Engineer
Tellabs Denmark A/S

Direct: +45 4473 2942
rob...@te...