lxr-developer Mailing List for LXR Cross Referencer (Page 34)
Brought to you by:
ajlittoz
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
(21) |
Jul
(14) |
Aug
(83) |
Sep
(23) |
Oct
(37) |
Nov
(52) |
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(28) |
Feb
(40) |
Mar
(21) |
Apr
(8) |
May
(21) |
Jun
(13) |
Jul
(9) |
Aug
(5) |
Sep
(8) |
Oct
(7) |
Nov
(2) |
Dec
|
2003 |
Jan
(2) |
Feb
(1) |
Mar
(11) |
Apr
(4) |
May
(6) |
Jun
(15) |
Jul
(4) |
Aug
(4) |
Sep
(9) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2004 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(5) |
Jun
(9) |
Jul
(47) |
Aug
(1) |
Sep
(1) |
Oct
(7) |
Nov
|
Dec
(1) |
2005 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(10) |
May
(9) |
Jun
(15) |
Jul
(3) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(10) |
Dec
(4) |
2006 |
Jan
(1) |
Feb
|
Mar
(9) |
Apr
(5) |
May
(1) |
Jun
(6) |
Jul
(2) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(3) |
2007 |
Jan
(2) |
Feb
(1) |
Mar
(32) |
Apr
(3) |
May
(3) |
Jun
(16) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(3) |
2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
(46) |
Apr
(70) |
May
(15) |
Jun
(13) |
Jul
(1) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2010 |
Jan
(5) |
Feb
(4) |
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(7) |
Nov
(6) |
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
(85) |
Apr
(18) |
May
(4) |
Jun
(3) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(20) |
2012 |
Jan
(17) |
Feb
(16) |
Mar
(13) |
Apr
(18) |
May
|
Jun
(6) |
Jul
(6) |
Aug
(10) |
Sep
(15) |
Oct
(10) |
Nov
(25) |
Dec
(1) |
From: <no...@so...> - 2002-06-01 07:12:32
|
Patches item #563217, was opened at 2002-06-01 00:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390119&aid=563217&group_id=27350 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Catch refs in lines ending in comments Initial Comment: This fixes a bug that many people have complained about. It catches references on lines containing comments and quoted text. See the developer mailing list for full details. The fix is trivial. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390119&aid=563217&group_id=27350 |
From: <no...@so...> - 2002-06-01 07:08:18
|
Bugs item #523647, was opened at 2002-02-27 15:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=523647&group_id=27350 Category: genxref Group: v0.9 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: misses some refernces to symbols. Initial Comment: LXR version 0.91 I think - downloaded it from sourceforge about 2 weeks ago. There doesn't seem to be any version info in any of the files. Latest entry in CHANGELOG is '2002-02-03 11:29 mbox' No error messages. Using mysql db. Indexing plain files. The bug: I have a C file with the line ct += kill_task(ptask, sig, 0); /* ANUPBS */ When I run genxref on the project containing this file it fails to find the reference to kill_task. If you look at the 'useage' table in mysql there's no entry for that symbol in that file. If I change the line to ct += kill_task(ptask, sig, 0); and rerun genxref it seems to work just fine - genxref finds the reference to kill_task, there's an entry in useage, and an identifier search in the browser finds it. A problem with the C comment parsing perhaps? Cheers, David Houlder dav...@an... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-01 00:08 Message: Logged In: NO This problem has annoyed me enough that I tracked it down. The problem seems to be with LXR/Lang/Generic.pm, line 168: @lines = ($frag =~ /(.*?\n)/g, $frag =~ /[^\n]*$/); specifically, the second regexp match. When LXR hits an expression that ends in /* comment */, then the $frag will not end in a newline. The fix is trivial, just put parens around the second regexp like this: @lines = ($frag =~ /(.*?\n)/g, $frag =~ /([^\n]*)$/); For curiosity's sake I ran the old and new versions against the redhat 7.3 linux kernel, and it catches an extra 99 references to jiffies. Interestingly, it looks like lines containg quoted text also were subject to this problem. I'll submit a patch for this. ---------------------------------------------------------------------- Comment By: Malcolm Box (mbox) Date: 2002-05-21 03:28 Message: Logged In: YES user_id=215386 There are definitely some problems in the referencing code - several people have reported missing references. The problem seems to lie in the LXR::SimpleParse and Generic::referencefile() code which is rather unclear and depends on some fairly dodgy regexps. If you wanted to spend some time stepping through this code and isolating the bug it would be very useful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=523647&group_id=27350 |
From: <no...@so...> - 2002-05-28 12:06:20
|
Bugs item #481597, was opened at 2001-11-13 23:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=481597&group_id=27350 Category: Lang support Group: current cvs Status: Open Resolution: None Priority: 6 Submitted By: Malcolm Box (mbox) Assigned to: Malcolm Box (mbox) Summary: Should index X::Y() as well as Y() Initial Comment: For C++ and other OO languages, we should index both the full scoped name of the function (ie Class::Function()) as well as just Function(). This looks easy(ish) to do - ctags already spits out the class of a method in the extended information, and it would be easy to insert another entry for the full name. References would be harder - it's much more difficult if not impossible to determine what function a callsite will actually resolve to except by doing a full compile. So we might have to settle for indexing the declarations of the fully scoped names but not the references, or strip out scope when running ident. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-28 05:06 Message: Logged In: NO Also C++ namespace scoping does not work... and is similar in syntax.. not sure if another bug should be created or not... //in somefile.h namespace ns{ class Foo{};}; //in some_other_file.cpp void func(){ ns::Foo f; //<-- will not be linked } unfortunately, his affects about 90% of my code... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-28 05:05 Message: Logged In: NO Also C++ namespace scoping does not work... and is similar in syntax.. not sure if another bug should be created or not... //in somefile.h namespace ns{ class Foo{};}; //in some_other_file.cpp void func(){ ns::Foo f; //<-- will not be linked } unfortunately, his affects about 90% of my code... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=481597&group_id=27350 |
From: <no...@so...> - 2002-05-28 12:05:22
|
Bugs item #481597, was opened at 2001-11-13 23:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=481597&group_id=27350 Category: Lang support Group: current cvs Status: Open Resolution: None Priority: 6 Submitted By: Malcolm Box (mbox) Assigned to: Malcolm Box (mbox) Summary: Should index X::Y() as well as Y() Initial Comment: For C++ and other OO languages, we should index both the full scoped name of the function (ie Class::Function()) as well as just Function(). This looks easy(ish) to do - ctags already spits out the class of a method in the extended information, and it would be easy to insert another entry for the full name. References would be harder - it's much more difficult if not impossible to determine what function a callsite will actually resolve to except by doing a full compile. So we might have to settle for indexing the declarations of the fully scoped names but not the references, or strip out scope when running ident. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-28 05:05 Message: Logged In: NO Also C++ namespace scoping does not work... and is similar in syntax.. not sure if another bug should be created or not... //in somefile.h namespace ns{ class Foo{};}; //in some_other_file.cpp void func(){ ns::Foo f; //<-- will not be linked } unfortunately, his affects about 90% of my code... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=481597&group_id=27350 |
From: <no...@so...> - 2002-05-22 11:40:57
|
Bugs item #559121, was opened at 2002-05-22 11:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=559121&group_id=27350 Category: genxref Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Andy Baskett (abaskett) Assigned to: Nobody/Anonymous (nobody) Summary: Out of memory errors during genxref Initial Comment: I'm not sure where the problem arises - I have spent hours (8+) attempting to debug the code and looked through CVS to see where previous leaks were fixed but to no avail. My MySQL "lxr.files" table currently contains 4400 files. My repository contains thousands of font files and other non-indexable files. My repository contains hundreds of files generated with old (9+ years) versions of RCS which results in "co" errors. Using Devel::Leak I believe the biggest leak is when "co" fails - under these circumstances I think the FileHandle is not "undef" but actually contains the error message from "co". Perhaps parsing this causes a problem? In any case Devel::Leak shows each file generates 2 leaks per file (even when indexing successfully) - I think %files lib/LXR/Index/Mysql.pl causes one as it keeps getting appended - is it possible to include % files = undef in the "empty_cache" function? Other than that I am at a loss for ideas. I am running very old versions of perl and MySQL which I hope to update and may be the cause, but I expect they are not the only reason for the problem. I am running: LXR 0.9.1 mysql 3.22.30 ectags 5.0.1 HP-UX 10.20 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=559121&group_id=27350 |
From: <no...@so...> - 2002-05-21 10:28:49
|
Bugs item #523647, was opened at 2002-02-28 08:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=523647&group_id=27350 Category: genxref Group: v0.9 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: misses some refernces to symbols. Initial Comment: LXR version 0.91 I think - downloaded it from sourceforge about 2 weeks ago. There doesn't seem to be any version info in any of the files. Latest entry in CHANGELOG is '2002-02-03 11:29 mbox' No error messages. Using mysql db. Indexing plain files. The bug: I have a C file with the line ct += kill_task(ptask, sig, 0); /* ANUPBS */ When I run genxref on the project containing this file it fails to find the reference to kill_task. If you look at the 'useage' table in mysql there's no entry for that symbol in that file. If I change the line to ct += kill_task(ptask, sig, 0); and rerun genxref it seems to work just fine - genxref finds the reference to kill_task, there's an entry in useage, and an identifier search in the browser finds it. A problem with the C comment parsing perhaps? Cheers, David Houlder dav...@an... ---------------------------------------------------------------------- >Comment By: Malcolm Box (mbox) Date: 2002-05-21 19:28 Message: Logged In: YES user_id=215386 There are definitely some problems in the referencing code - several people have reported missing references. The problem seems to lie in the LXR::SimpleParse and Generic::referencefile() code which is rather unclear and depends on some fairly dodgy regexps. If you wanted to spend some time stepping through this code and isolating the bug it would be very useful. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=523647&group_id=27350 |
From: <no...@so...> - 2002-05-21 10:23:56
|
Bugs item #556309, was opened at 2002-05-15 22:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=556309&group_id=27350 Category: genxref Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andy Baskett (abaskett) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to create LXR::Lang::Generic Lang Initial Comment: I am running: LXR 0.9.1 mysql 3.22.30 ectags 5.0.1 HP-UX 10.20 When running genxref --url=http://server/lxr -- version=head with the config set to run against both a directory or CVS repository I get the following error: Unable to create LXR::Lang::Generic Lang object, Died at lib/LXR/Lang/Generic.pm line 263 I have successfully been running lxr.0.3 and have transposed (what I hope are) the necessary values of the lxr.conf file into the new format. I've tried this same with lxr.0.8 and get the following error (which I think is probably caused by the same thing looking at the code): Can't use an undefined value as a HASH reference at lib/LXR/Lang/Generic.pm line 62. lxr.0.3 runs fine and I'm content running that for now, but would like to try 0.9.1 on HP-UX 10.20 (which I guess may be the problem as I've not found any other similar reports on Linux). Thanks in advance for any solutions. ---------------------------------------------------------------------- >Comment By: Malcolm Box (mbox) Date: 2002-05-21 19:23 Message: Logged In: YES user_id=215386 I'm using perl 5.6.1, so your (very) old version of perl may be to blame. If you can, try upgrading to a more recent version of perl. If that cures the problem, I can add a perl version check to the code to catch this sort of problem in the future. ---------------------------------------------------------------------- Comment By: Andy Baskett (abaskett) Date: 2002-05-16 01:10 Message: Logged In: YES user_id=36654 In the end changing it to: my $tmpstr = '$generic_config = '.<CONF>.";"; eval ($tmpstr); #$generic_config = eval ("\n#line 1 \generic.conf\\n".<CONF>); I expect my perl is dubious though. ---------------------------------------------------------------------- Comment By: Andy Baskett (abaskett) Date: 2002-05-16 00:05 Message: Logged In: YES user_id=36654 Eventually tracked it down to the following line in lib/LXR/Lang/Generic.pm: $generic_config = eval ("\n#line 1 \generic.conf\\n".<CONF>); (Forgive me for not providing a line number but I expect mine no longer match). Importing the entire generic.conf file and creating the $generic_config hash manually fixes my problem - my Perl version is: This is perl, version 5.005_02 built for PA-RISC1.1 Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=556309&group_id=27350 |
From: <no...@so...> - 2002-05-21 10:21:20
|
Bugs item #558607, was opened at 2002-05-21 19:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=558607&group_id=27350 Category: Browsing Group: current cvs Status: Open Resolution: None Priority: 2 Submitted By: Malcolm Box (mbox) Assigned to: Nobody/Anonymous (nobody) Summary: Use of internal-gopher-* images Initial Comment: The source browsing feature of lxr uses Netscape's internal-gopher-* images in the directory listings. These are not available on all browsers. This creates a poor display with lots of broken images showing. Either we should use the Apache default icons, or ship the Mozilla icons with lxr and use those. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=558607&group_id=27350 |
From: <no...@so...> - 2002-05-18 10:56:58
|
Bugs item #557601, was opened at 2002-05-18 03:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=557601&group_id=27350 Category: None Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Mistake in file INSTALL Initial Comment: In chapter "Create lxr installation directory" There are missed strings after: "Now you have to put the perl modules that LXR uses into a directory on your system that will be searched by mod_perl when the LXR scripts are executed. Execute". Sorry for my English. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=557601&group_id=27350 |
From: <no...@so...> - 2002-05-15 16:10:46
|
Bugs item #556309, was opened at 2002-05-15 13:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=556309&group_id=27350 Category: genxref Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andy Baskett (abaskett) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to create LXR::Lang::Generic Lang Initial Comment: I am running: LXR 0.9.1 mysql 3.22.30 ectags 5.0.1 HP-UX 10.20 When running genxref --url=http://server/lxr -- version=head with the config set to run against both a directory or CVS repository I get the following error: Unable to create LXR::Lang::Generic Lang object, Died at lib/LXR/Lang/Generic.pm line 263 I have successfully been running lxr.0.3 and have transposed (what I hope are) the necessary values of the lxr.conf file into the new format. I've tried this same with lxr.0.8 and get the following error (which I think is probably caused by the same thing looking at the code): Can't use an undefined value as a HASH reference at lib/LXR/Lang/Generic.pm line 62. lxr.0.3 runs fine and I'm content running that for now, but would like to try 0.9.1 on HP-UX 10.20 (which I guess may be the problem as I've not found any other similar reports on Linux). Thanks in advance for any solutions. ---------------------------------------------------------------------- >Comment By: Andy Baskett (abaskett) Date: 2002-05-15 16:10 Message: Logged In: YES user_id=36654 In the end changing it to: my $tmpstr = '$generic_config = '.<CONF>.";"; eval ($tmpstr); #$generic_config = eval ("\n#line 1 \generic.conf\\n".<CONF>); I expect my perl is dubious though. ---------------------------------------------------------------------- Comment By: Andy Baskett (abaskett) Date: 2002-05-15 15:05 Message: Logged In: YES user_id=36654 Eventually tracked it down to the following line in lib/LXR/Lang/Generic.pm: $generic_config = eval ("\n#line 1 \generic.conf\\n".<CONF>); (Forgive me for not providing a line number but I expect mine no longer match). Importing the entire generic.conf file and creating the $generic_config hash manually fixes my problem - my Perl version is: This is perl, version 5.005_02 built for PA-RISC1.1 Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=556309&group_id=27350 |
From: <no...@so...> - 2002-05-15 15:05:39
|
Bugs item #556309, was opened at 2002-05-15 13:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=556309&group_id=27350 Category: genxref Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andy Baskett (abaskett) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to create LXR::Lang::Generic Lang Initial Comment: I am running: LXR 0.9.1 mysql 3.22.30 ectags 5.0.1 HP-UX 10.20 When running genxref --url=http://server/lxr -- version=head with the config set to run against both a directory or CVS repository I get the following error: Unable to create LXR::Lang::Generic Lang object, Died at lib/LXR/Lang/Generic.pm line 263 I have successfully been running lxr.0.3 and have transposed (what I hope are) the necessary values of the lxr.conf file into the new format. I've tried this same with lxr.0.8 and get the following error (which I think is probably caused by the same thing looking at the code): Can't use an undefined value as a HASH reference at lib/LXR/Lang/Generic.pm line 62. lxr.0.3 runs fine and I'm content running that for now, but would like to try 0.9.1 on HP-UX 10.20 (which I guess may be the problem as I've not found any other similar reports on Linux). Thanks in advance for any solutions. ---------------------------------------------------------------------- >Comment By: Andy Baskett (abaskett) Date: 2002-05-15 15:05 Message: Logged In: YES user_id=36654 Eventually tracked it down to the following line in lib/LXR/Lang/Generic.pm: $generic_config = eval ("\n#line 1 \generic.conf\\n".<CONF>); (Forgive me for not providing a line number but I expect mine no longer match). Importing the entire generic.conf file and creating the $generic_config hash manually fixes my problem - my Perl version is: This is perl, version 5.005_02 built for PA-RISC1.1 Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=556309&group_id=27350 |
From: <no...@so...> - 2002-05-15 13:04:13
|
Bugs item #556309, was opened at 2002-05-15 13:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=556309&group_id=27350 Category: genxref Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andy Baskett (abaskett) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to create LXR::Lang::Generic Lang Initial Comment: I am running: LXR 0.9.1 mysql 3.22.30 ectags 5.0.1 HP-UX 10.20 When running genxref --url=http://server/lxr -- version=head with the config set to run against both a directory or CVS repository I get the following error: Unable to create LXR::Lang::Generic Lang object, Died at lib/LXR/Lang/Generic.pm line 263 I have successfully been running lxr.0.3 and have transposed (what I hope are) the necessary values of the lxr.conf file into the new format. I've tried this same with lxr.0.8 and get the following error (which I think is probably caused by the same thing looking at the code): Can't use an undefined value as a HASH reference at lib/LXR/Lang/Generic.pm line 62. lxr.0.3 runs fine and I'm content running that for now, but would like to try 0.9.1 on HP-UX 10.20 (which I guess may be the problem as I've not found any other similar reports on Linux). Thanks in advance for any solutions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=556309&group_id=27350 |
From: <no...@so...> - 2002-05-09 11:06:45
|
Bugs item #471858, was opened at 2001-10-17 05:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=471858&group_id=27350 Category: Browsing Group: current cvs Status: Open Resolution: None >Priority: 7 Submitted By: Per Kristian Gjermshus (pergj) Assigned to: Malcolm Box (mbox) Summary: Some characters in files create trouble Initial Comment: I have a directory in my source-tree containing the string 'c-++'. It is not possible to browse these directories. ---------------------------------------------------------------------- >Comment By: Malcolm Box (mbox) Date: 2002-05-09 20:06 Message: Logged In: YES user_id=215386 Bug 536369 is a duplicate of this. ---------------------------------------------------------------------- Comment By: Malcolm Box (mbox) Date: 2001-10-23 23:16 Message: Logged In: YES user_id=215386 Looks like this is caused by the httpwash function being over-zealous at stripping out characters. Perhaps we can get away with not washing variables - it seems that there are few dangerous calls that use web-provided parameters, and we could simply check at these places for troublesome characters, rather than globally restrict them. This is related to the glimpse RE bug as well ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=471858&group_id=27350 |
From: <no...@so...> - 2002-05-09 11:05:58
|
Bugs item #536369, was opened at 2002-03-29 02:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=536369&group_id=27350 Category: None Group: v0.9.1 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: opendir doesn't work? Initial Comment: I have downloaded & installed the latest lxr version. I have always preferred python, php or csh-gawk-grep-sed to do scripting stuff over perl, so i will need your help here :) My problem is that when i point my browser to http://localhost/lxr/source i get a message that my src directory can't be read (although it is guo+xrw) So even though i get the header stuff of the page, etc i don't get the contents of the src dir in the browser. Error is in : lib/LXR/File/Plain.pm line 104 So what can the problem be? I know that somehow apache must have access to that directory. I put a link from /usr/local/lxr to my source dir, so that permissions in .htacess apply to src dir too, but i still can't have access to the src dir !!! How can i solve this ?? Now, i tried to debug Plain.pm, by printing some stuff, but the fact is i keep getting the error for line 104 again, although it is now 107! I have diabled caching in the browser, so i guess it is apache who has cached the Plain.pm How can i solve this too?? Many thanks ! Manolis Perakakis ---------------------------------------------------------------------- Comment By: Robbie Ye (robbieye) Date: 2002-05-01 15:39 Message: Logged In: YES user_id=507870 Yes, both ways worked, so either of these two: 1) Remove the http_wash() call and do a direct assignment in httpinit() $HTTP->{'path_info'} = http_wash($ENV{'PATH_INFO'}); i.e. $HTTP->{'path_info'} = $ENV{'PATH_INFO'}; 2) Comment out "$t =~ s/\+/ /g;", the 5th line in http_wash() function. Last time I forgot to hit refresh button after changing the Common.pm so what i saw is the cached page. Thanks a lot! Robbie ---------------------------------------------------------------------- Comment By: Malcolm Box (mbox) Date: 2002-04-30 19:33 Message: Logged In: YES user_id=215386 The problem is in http_wash in Common.pm. This function is quite aggressive in cleaning "special" characters out of input values, to prevent security attacks. I haven't done a full security check to see whether this could be relaxed somewhat, but if you're not so concerned about security the easiest thing to do is to remove the call to http_wash: $HTTP->{'path_info'} = http_wash($ENV{'PATH_INFO'}); in the httpinit function in Common.pm. ---------------------------------------------------------------------- Comment By: Robbie Ye (robbieye) Date: 2002-04-28 14:32 Message: Logged In: YES user_id=507870 Hi, I have an error reported at the same file, same line number, i.e. Plain.pm line 104. The complete error message is like this: ** Fatal: Can't open /home/robbieye/indexed-src/GEANT4/4.0/source/digits hits/ at /home/robbieye/lxr-0.9.1//lib/LXR/Files/Plain.pm line 104. I am using LXR 0.9.1 to cross reference Geant4 4.0 package. Every directory in the source tree is cross referenced and browsable except for this particular one with a '+' in the directory name: "digits+hits". So apparently the perl scripts changed the '+' to ' ' and so the opendir() fails Now let me explain my story more precisely. So, most of the things work fine, except for the following case. When I browse the parent directory of "digits+hits", which is: http://localhost.localdomain:8080/lxr/GEANT4/source/source/ On the shown page, there is a link to the sub directory "digits+hits", the link is shown correctly as:http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%2Bhits/ Then when I clicked on this link, the returned URL in the browser's (i'm using Opera) address bar is: http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%2Bhits/ So this is still correct. But the return page itself contains the error message: ** Fatal: Can't open /home/robbieye/indexed-src/GEANT4/4.0/source/digits hits/ at /home/robbieye/lxr-0.9.1//lib/LXR/Files/Plain.pm line 104. Also, the directory title in the page is showed as "GEANT4/ source/ digits hits/", so the '+' is substituted by a blank space somehow. And when I move my browser to the "digits hits" portion of this erroroneous link, it reads: http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%20hits/, so the "%2B" is changed to "%20" in the address. I knew little about Perl to fix the problem myself, can someone out there help me with this? Thank you very much, I'd be more than happy to verify your solutions! Actually i tried to look into the Perl scripts, and I stop at the function http_wash in file /lib/LXR/Common.pm and comment out the line: "$t =~ s/\+/ /g;", but the error is still there(i didn't restart my browser though). Robbie <rob...@cc...> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=536369&group_id=27350 |
From: <no...@so...> - 2002-05-09 11:04:59
|
Bugs item #526664, was opened at 2002-03-07 07:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=526664&group_id=27350 Category: SCM support Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Malcolm Box (mbox) Summary: CVS {default}=head != co default Initial Comment: I tried lxr 0.91's ability to cross-reference directly from CVS, specified v{default}=head in the config. I expected lxr to build its cross-reference data based on the same revision that one would get if he does a simple 'cvs co' (without any revision or tag specified). However this does not work as expected for a particular project where we make use of a vendor branch. I attached the head of one of the affected RCS files, where: "cvs co" would retrieve 1.1.1.2 lxr however indexes 1.1 as the head lxr seems to internally translate the 'head' into '1.1'. If there is some other way to specify "the revision that cvs would checkout by default" then consider this report to be just a "documentation bug report"; I'd like to know what v{default} setting would make lxr behave as I expect... ---------------------------------------------------------------------- Comment By: Kolja Waschk (kawk) Date: 2002-03-08 20:21 Message: Logged In: YES user_id=478715 The following patch fixed the issue for us. It considers the 'branch' info in the RCS header (just below 'head') and searches for the latest revision in the named branch, substituting it for 'head'. (Note: probably it would be wiser to make the result available as version='default' instead of 'head' to retain backwards compatibility) --- CVS.pm-orig Fri Mar 8 11:27:03 2002 +++ CVS.pm Fri Mar 8 11:28:07 2002 @@ -360,6 +360,17 @@ /^@/s && substr($_, 1, -1) || $_ } $v =~ /(\w+)\s*((?:[^;@]+|@[^@]*@)*);/gs }; } + + if(defined (my $k=$cvs{'header'}{'branch'})) + { + $k=~s/\./\./g; # quote dots in branch number + $k=(grep(/^$k\.\d+$/, keys %{$cvs{'branch'}}))[0]; # get ANY revision on branch + if(defined $k) + { + while($cvs{'branch'}{$k}{'next'}) { $k = $cvs{'branch'}{$k}{'next'}; } + $cvs{'header'}{'symbols'}{'head'} = $k; + } + } $cvs{'desc'} = shift(@cvs) =~ /\s*desc\s+((?:[^\n@]+|@[^@]*@)*)\n/s; $cvs{'desc'} =~ s/^@|@($|@)/$1/gs; ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-07 07:14 Message: Logged In: NO aah, two corrections. my correct e-mail is 'ka...@ma...', and it seems the file didn't get attached, so I include it here (hopefully it remains intelligible, sorry): head 1.1; branch 1.1.1; access; symbols as_of_2002_03_06:1.1.1.2 as_of_2002_03_04:1.1.1.2 as_of_2002_02_26:1.1.1.2 as_of_2002_02_21:1.1.1.2 as_of_2002_01_29:1.1.1.1 ps:1.1.1; locks; strict; comment @ * @; expand @o@; 1.1 date 2002.02.26.13.50.33; author kawk; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2002.02.26.13.50.33; author kawk; state Exp; branches; next 1.1.1.2; 1.1.1.2 date 2002.02.26.14.02.20; author kawk; state Exp; branches; next ; desc @@ 1.1 log @Initial revision @ text @ /* SOURCE FILE: xyz.c ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=526664&group_id=27350 |
From: <no...@so...> - 2002-05-09 11:04:54
|
Bugs item #554063, was opened at 2002-05-09 20:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=554063&group_id=27350 Category: Browsing Group: current cvs Status: Open Resolution: None >Priority: 5 Submitted By: Malcolm Box (mbox) >Assigned to: Malcolm Box (mbox) Summary: Title not produced for sourcedirs Initial Comment: titleexpand() in Common.pm does not produce a title value for the HTML page when displaying a source directory. The fix is to add " || $who eq 'sourcedir' " to the first if condition. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=554063&group_id=27350 |
From: <no...@so...> - 2002-05-09 11:04:54
|
Bugs item #519945, was opened at 2002-02-19 21:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=519945&group_id=27350 Category: None Group: v0.9 Status: Open Resolution: None Priority: 5 Submitted By: Shree Kumar (shreekumar) >Assigned to: Malcolm Box (mbox) Summary: definitions are also references Initial Comment: LXR 0.9.1 [as well as older versions] shows definition also in the list of references. eg consider a file test.c --- #define TEST 1 -- Searching for "TEST" will show that it is 1. a macro defined at line 1, file test.c and 2. referenced in test.c at line 1 If the number of definitions is small, this is OK. But when the number of definitions is large, finding which of the references are actually references becomes a pain. The easiest solution for this would be to remove all definitions from the references list. If this is acceptable, I have a patch ready [the backend is MySQL] ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=519945&group_id=27350 |
From: <no...@so...> - 2002-05-09 11:04:22
|
Bugs item #554063, was opened at 2002-05-09 20:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=554063&group_id=27350 Category: Browsing Group: current cvs Status: Open Resolution: None Priority: 3 Submitted By: Malcolm Box (mbox) Assigned to: Nobody/Anonymous (nobody) Summary: Title not produced for sourcedirs Initial Comment: titleexpand() in Common.pm does not produce a title value for the HTML page when displaying a source directory. The fix is to add " || $who eq 'sourcedir' " to the first if condition. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=554063&group_id=27350 |
From: <no...@so...> - 2002-05-09 00:50:42
|
Patches item #553958, was opened at 2002-05-09 00:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390119&aid=553958&group_id=27350 Category: Other Group: Bugfix Status: Open Resolution: None Priority: 5 Submitted By: Marco Aurélio Graciotto Silva (magsilva) Assigned to: Nobody/Anonymous (nobody) Summary: Minor INSTALL correction Initial Comment: As someone has already pointed out, it's missing some text in INSTALL. The patch solves (at least try to) it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390119&aid=553958&group_id=27350 |
From: <no...@so...> - 2002-05-09 00:42:33
|
Patches item #553956, was opened at 2002-05-09 00:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390119&aid=553956&group_id=27350 Category: DB backends Group: Experimental Status: Open Resolution: None Priority: 5 Submitted By: Marco Aurélio Graciotto Silva (magsilva) Assigned to: Nobody/Anonymous (nobody) Summary: File search using filenames stored in DB Initial Comment: I saw the patch from Shree Kumar and I got quite amused. I was, till now, using a hack to find files. With his patches, I saw light at the tunnel's end. I ported it to PostgreSQL, quite easy. However, when I run it, my harddisk screamed and postmaster used all the cpu for minutes. So I changed the query to something like this: ("select distinct f.filename ". "from files f, releases r ". "where r.release = ? ". "and f.fileid = r.fileid "); With this query, everything run much smoother. It seems to work actually, at least it finds some files. To this patch work, the find's patch from Shree Kumar is needed (my patches are only about the db backends) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390119&aid=553956&group_id=27350 |
From: Malcolm B. <ma...@br...> - 2002-05-01 12:01:02
|
Arne Georg Gleditsch wrote: >This is a bit non-obvious, and I'm happy to see that you're able to >summarise the issue so clearly when someone suggests to mangle stuff >we've actually struggled a fair bit with in the past. :) As a note, >Plain.pm includes the file size in the revision string, which means >that files would have to have the same timestamp and size as well as >different contents for LXR to fail to index changed files. > I hadn't realised that size was included - that makes it even more robust. Certainly the terminology of releases, revisions etc is not that clear - it took me a while to get my head round it. Moving to the idea of being able to index a "HEAD" revision (ie one that is evolving) clearly challenges some of the assumptions in the code, though not the overall semantic model. >As far as solutions to this problem go; even with Plain.pm we have >some notion of the set of files belonging to a particular release. >Thus, when indexing a release and encountering a (filename, >revision)-tuple belonging to it, we could invalidate all non-matching >(filename, *)-tuples marked as belonging to the same release (and no >other releases). In doing this, we would also need to invalidate the >reference-information for this release. As long as we do that we'd be >home free as far as database integrity is concerned, as far as I can >see. > Indeed, this works very well. I have got it going for the Postgres backend, since the nice referential integrity triggers make this kind of cascading delete very easy. Unfortunately I haven't completed the port to the MySQL backend, since that takes much more manual grovelling to clean up. This also won't be hitting the CVS repository for a while since the code is on a laptop which is being shipped from Japan to the UK and so is now bobbing around on the Pacific ocean at a guess :-) Of course, I might get frustrated enough with the bug to just re-code the fix, but the "drop and rebuild the db every now and then" fix is working for me at the moment. >(A possible shortcut would be to index (filename, rev2) before >(possibly) invalidating the information for (filename, rev1) and only >invalidate the reference-information if we find that the two define >non-matching sets of symbols.) > It's probably more effort to track the new stuff and compare with the old than simply to delete and re-add. The big problem (that's just occurred to me) is with the useage table. If the new revision of the file defines new symbols, then for total accuracy all existing files need to be re-referenced to see if they use that symbol. Luckily it's extremely unlikely that someone would add a new symbol in a file that retrospectively re-defines symbols in other files, but I guess it is a theoretical possibility. This is also the reason why a "index file, reference file" loop doesn't work, rather than the "index all files", "reference all files" approach taken at the moment. Cheers, Malcolm P.S. Good to see you back on the list again :-) |
From: Arne G. G. <ar...@li...> - 2002-05-01 11:31:22
|
* Malcolm Box > Again, moving discussion of this to the list. Forgive me for butting in this late, I'm just trying to catch up. I'll just add a few comments to this issue. Just whack me if I'm stating stuff you've already covered. > Plain.pm then emulates this by using timestamps as the revision > history of the file. Therefore if you have two directories v1 and v2, > and they both contain a file X with the same timestamp, LXR will treat > them as the same file. The easiest way to see this is to symlink > between the two version directories - indexing will occur only once. > This mechanism only has one way of breaking - two files with the same > name and timestamp that are actually not identical. However, it would > be a strange revision control system that would give you such files - > most systems either give you the time of checkin (in which case the > timestamps would not be identical) or the time of checkout (similarly, > the timestamps should not be equal since the two files probably > weren't written at the same time). The result of this is that with > Plain.pm LXR will sometimes index the file more often that it needs > to, but it should not decide not to index it when it does need to. > Using the Plain.pm backend essentially trades off diskspace for ease > of use. This is a bit non-obvious, and I'm happy to see that you're able to summarise the issue so clearly when someone suggests to mangle stuff we've actually struggled a fair bit with in the past. :) As a note, Plain.pm includes the file size in the revision string, which means that files would have to have the same timestamp and size as well as different contents for LXR to fail to index changed files. As far as solutions to this problem go; even with Plain.pm we have some notion of the set of files belonging to a particular release. Thus, when indexing a release and encountering a (filename, revision)-tuple belonging to it, we could invalidate all non-matching (filename, *)-tuples marked as belonging to the same release (and no other releases). In doing this, we would also need to invalidate the reference-information for this release. As long as we do that we'd be home free as far as database integrity is concerned, as far as I can see. (A possible shortcut would be to index (filename, rev2) before (possibly) invalidating the information for (filename, rev1) and only invalidate the reference-information if we find that the two define non-matching sets of symbols.) Arne. |
From: <no...@so...> - 2002-05-01 06:39:18
|
Bugs item #536369, was opened at 2002-03-28 12:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=536369&group_id=27350 Category: None Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: opendir doesn't work? Initial Comment: I have downloaded & installed the latest lxr version. I have always preferred python, php or csh-gawk-grep-sed to do scripting stuff over perl, so i will need your help here :) My problem is that when i point my browser to http://localhost/lxr/source i get a message that my src directory can't be read (although it is guo+xrw) So even though i get the header stuff of the page, etc i don't get the contents of the src dir in the browser. Error is in : lib/LXR/File/Plain.pm line 104 So what can the problem be? I know that somehow apache must have access to that directory. I put a link from /usr/local/lxr to my source dir, so that permissions in .htacess apply to src dir too, but i still can't have access to the src dir !!! How can i solve this ?? Now, i tried to debug Plain.pm, by printing some stuff, but the fact is i keep getting the error for line 104 again, although it is now 107! I have diabled caching in the browser, so i guess it is apache who has cached the Plain.pm How can i solve this too?? Many thanks ! Manolis Perakakis ---------------------------------------------------------------------- Comment By: Robbie Ye (robbieye) Date: 2002-05-01 02:39 Message: Logged In: YES user_id=507870 Yes, both ways worked, so either of these two: 1) Remove the http_wash() call and do a direct assignment in httpinit() $HTTP->{'path_info'} = http_wash($ENV{'PATH_INFO'}); i.e. $HTTP->{'path_info'} = $ENV{'PATH_INFO'}; 2) Comment out "$t =~ s/\+/ /g;", the 5th line in http_wash() function. Last time I forgot to hit refresh button after changing the Common.pm so what i saw is the cached page. Thanks a lot! Robbie ---------------------------------------------------------------------- Comment By: Malcolm Box (mbox) Date: 2002-04-30 06:33 Message: Logged In: YES user_id=215386 The problem is in http_wash in Common.pm. This function is quite aggressive in cleaning "special" characters out of input values, to prevent security attacks. I haven't done a full security check to see whether this could be relaxed somewhat, but if you're not so concerned about security the easiest thing to do is to remove the call to http_wash: $HTTP->{'path_info'} = http_wash($ENV{'PATH_INFO'}); in the httpinit function in Common.pm. ---------------------------------------------------------------------- Comment By: Robbie Ye (robbieye) Date: 2002-04-28 01:32 Message: Logged In: YES user_id=507870 Hi, I have an error reported at the same file, same line number, i.e. Plain.pm line 104. The complete error message is like this: ** Fatal: Can't open /home/robbieye/indexed-src/GEANT4/4.0/source/digits hits/ at /home/robbieye/lxr-0.9.1//lib/LXR/Files/Plain.pm line 104. I am using LXR 0.9.1 to cross reference Geant4 4.0 package. Every directory in the source tree is cross referenced and browsable except for this particular one with a '+' in the directory name: "digits+hits". So apparently the perl scripts changed the '+' to ' ' and so the opendir() fails Now let me explain my story more precisely. So, most of the things work fine, except for the following case. When I browse the parent directory of "digits+hits", which is: http://localhost.localdomain:8080/lxr/GEANT4/source/source/ On the shown page, there is a link to the sub directory "digits+hits", the link is shown correctly as:http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%2Bhits/ Then when I clicked on this link, the returned URL in the browser's (i'm using Opera) address bar is: http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%2Bhits/ So this is still correct. But the return page itself contains the error message: ** Fatal: Can't open /home/robbieye/indexed-src/GEANT4/4.0/source/digits hits/ at /home/robbieye/lxr-0.9.1//lib/LXR/Files/Plain.pm line 104. Also, the directory title in the page is showed as "GEANT4/ source/ digits hits/", so the '+' is substituted by a blank space somehow. And when I move my browser to the "digits hits" portion of this erroroneous link, it reads: http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%20hits/, so the "%2B" is changed to "%20" in the address. I knew little about Perl to fix the problem myself, can someone out there help me with this? Thank you very much, I'd be more than happy to verify your solutions! Actually i tried to look into the Perl scripts, and I stop at the function http_wash in file /lib/LXR/Common.pm and comment out the line: "$t =~ s/\+/ /g;", but the error is still there(i didn't restart my browser though). Robbie <rob...@cc...> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=536369&group_id=27350 |
From: <no...@so...> - 2002-04-30 10:33:22
|
Bugs item #536369, was opened at 2002-03-29 02:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=536369&group_id=27350 Category: None Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: opendir doesn't work? Initial Comment: I have downloaded & installed the latest lxr version. I have always preferred python, php or csh-gawk-grep-sed to do scripting stuff over perl, so i will need your help here :) My problem is that when i point my browser to http://localhost/lxr/source i get a message that my src directory can't be read (although it is guo+xrw) So even though i get the header stuff of the page, etc i don't get the contents of the src dir in the browser. Error is in : lib/LXR/File/Plain.pm line 104 So what can the problem be? I know that somehow apache must have access to that directory. I put a link from /usr/local/lxr to my source dir, so that permissions in .htacess apply to src dir too, but i still can't have access to the src dir !!! How can i solve this ?? Now, i tried to debug Plain.pm, by printing some stuff, but the fact is i keep getting the error for line 104 again, although it is now 107! I have diabled caching in the browser, so i guess it is apache who has cached the Plain.pm How can i solve this too?? Many thanks ! Manolis Perakakis ---------------------------------------------------------------------- >Comment By: Malcolm Box (mbox) Date: 2002-04-30 19:33 Message: Logged In: YES user_id=215386 The problem is in http_wash in Common.pm. This function is quite aggressive in cleaning "special" characters out of input values, to prevent security attacks. I haven't done a full security check to see whether this could be relaxed somewhat, but if you're not so concerned about security the easiest thing to do is to remove the call to http_wash: $HTTP->{'path_info'} = http_wash($ENV{'PATH_INFO'}); in the httpinit function in Common.pm. ---------------------------------------------------------------------- Comment By: Robbie Ye (robbieye) Date: 2002-04-28 14:32 Message: Logged In: YES user_id=507870 Hi, I have an error reported at the same file, same line number, i.e. Plain.pm line 104. The complete error message is like this: ** Fatal: Can't open /home/robbieye/indexed-src/GEANT4/4.0/source/digits hits/ at /home/robbieye/lxr-0.9.1//lib/LXR/Files/Plain.pm line 104. I am using LXR 0.9.1 to cross reference Geant4 4.0 package. Every directory in the source tree is cross referenced and browsable except for this particular one with a '+' in the directory name: "digits+hits". So apparently the perl scripts changed the '+' to ' ' and so the opendir() fails Now let me explain my story more precisely. So, most of the things work fine, except for the following case. When I browse the parent directory of "digits+hits", which is: http://localhost.localdomain:8080/lxr/GEANT4/source/source/ On the shown page, there is a link to the sub directory "digits+hits", the link is shown correctly as:http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%2Bhits/ Then when I clicked on this link, the returned URL in the browser's (i'm using Opera) address bar is: http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%2Bhits/ So this is still correct. But the return page itself contains the error message: ** Fatal: Can't open /home/robbieye/indexed-src/GEANT4/4.0/source/digits hits/ at /home/robbieye/lxr-0.9.1//lib/LXR/Files/Plain.pm line 104. Also, the directory title in the page is showed as "GEANT4/ source/ digits hits/", so the '+' is substituted by a blank space somehow. And when I move my browser to the "digits hits" portion of this erroroneous link, it reads: http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%20hits/, so the "%2B" is changed to "%20" in the address. I knew little about Perl to fix the problem myself, can someone out there help me with this? Thank you very much, I'd be more than happy to verify your solutions! Actually i tried to look into the Perl scripts, and I stop at the function http_wash in file /lib/LXR/Common.pm and comment out the line: "$t =~ s/\+/ /g;", but the error is still there(i didn't restart my browser though). Robbie <rob...@cc...> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=536369&group_id=27350 |
From: <no...@so...> - 2002-04-28 05:32:20
|
Bugs item #536369, was opened at 2002-03-28 12:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=536369&group_id=27350 Category: None Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: opendir doesn't work? Initial Comment: I have downloaded & installed the latest lxr version. I have always preferred python, php or csh-gawk-grep-sed to do scripting stuff over perl, so i will need your help here :) My problem is that when i point my browser to http://localhost/lxr/source i get a message that my src directory can't be read (although it is guo+xrw) So even though i get the header stuff of the page, etc i don't get the contents of the src dir in the browser. Error is in : lib/LXR/File/Plain.pm line 104 So what can the problem be? I know that somehow apache must have access to that directory. I put a link from /usr/local/lxr to my source dir, so that permissions in .htacess apply to src dir too, but i still can't have access to the src dir !!! How can i solve this ?? Now, i tried to debug Plain.pm, by printing some stuff, but the fact is i keep getting the error for line 104 again, although it is now 107! I have diabled caching in the browser, so i guess it is apache who has cached the Plain.pm How can i solve this too?? Many thanks ! Manolis Perakakis ---------------------------------------------------------------------- Comment By: Robbie Ye (robbieye) Date: 2002-04-28 01:32 Message: Logged In: YES user_id=507870 Hi, I have an error reported at the same file, same line number, i.e. Plain.pm line 104. The complete error message is like this: ** Fatal: Can't open /home/robbieye/indexed-src/GEANT4/4.0/source/digits hits/ at /home/robbieye/lxr-0.9.1//lib/LXR/Files/Plain.pm line 104. I am using LXR 0.9.1 to cross reference Geant4 4.0 package. Every directory in the source tree is cross referenced and browsable except for this particular one with a '+' in the directory name: "digits+hits". So apparently the perl scripts changed the '+' to ' ' and so the opendir() fails Now let me explain my story more precisely. So, most of the things work fine, except for the following case. When I browse the parent directory of "digits+hits", which is: http://localhost.localdomain:8080/lxr/GEANT4/source/source/ On the shown page, there is a link to the sub directory "digits+hits", the link is shown correctly as:http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%2Bhits/ Then when I clicked on this link, the returned URL in the browser's (i'm using Opera) address bar is: http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%2Bhits/ So this is still correct. But the return page itself contains the error message: ** Fatal: Can't open /home/robbieye/indexed-src/GEANT4/4.0/source/digits hits/ at /home/robbieye/lxr-0.9.1//lib/LXR/Files/Plain.pm line 104. Also, the directory title in the page is showed as "GEANT4/ source/ digits hits/", so the '+' is substituted by a blank space somehow. And when I move my browser to the "digits hits" portion of this erroroneous link, it reads: http://localhost.localdomain:8080/lxr/GEANT4/source/source/digits%20hits/, so the "%2B" is changed to "%20" in the address. I knew little about Perl to fix the problem myself, can someone out there help me with this? Thank you very much, I'd be more than happy to verify your solutions! Actually i tried to look into the Perl scripts, and I stop at the function http_wash in file /lib/LXR/Common.pm and comment out the line: "$t =~ s/\+/ /g;", but the error is still there(i didn't restart my browser though). Robbie <rob...@cc...> ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=536369&group_id=27350 |