lxr-developer Mailing List for LXR Cross Referencer (Page 11)
Brought to you by:
ajlittoz
Menu
▾
▴
lxr-developer — Don't use, active developers only
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: SourceForge.net <no...@so...> - 2011-03-09 14:52:07
|
Bugs item #3204285, was opened at 2011-03-09 15:51 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204285&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: None Status: Open >Resolution: Works For Me >Priority: 2 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: HTML code not enough XML compliant (cosmetic) Initial Comment: LXR v0.9.8 File source generates HTML page which may contain informative data structured in paragraphs. These paragraphs are opened with <p> tag but never closed. This is OK for HTML but is not in the spirit of XML. The proposed patch add a </p> tag at the end of the concerned paragraphs. File: source 110225 direxpand !-154,154 ! . " does not exist.</i>\n</p>\n"); !-156,156 ! "\<p align=\"center\">\n<i>This directory might exist in other versions, try 'Show attic files' or select a different Version.</i>\n</p>\n" -------------------------- and of patch ------------------------ 110225 printfile !-293,293 ! "\<p align=\"center\">\n<i>The file $pathname does not exist.</i>\n</p>\n" !-296,296 ! "\<p align=\"center\">\n<i>This file might exist in other versions, try 'Show attic files' or select a different Version.</i>\n</p>\n" ---------------- end of patch ----------------------- 110225 source init code !-308,308 ! print("\<p align=\"center\">\n<i>The file $pathname does not exist.</i>\n</p>\n"); ------------------ end of patch ---------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204285&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:51:37
|
Bugs item #3204285, was opened at 2011-03-09 15:51 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204285&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: HTML code not enough XML compliant (cosmetic) Initial Comment: LXR v0.9.8 File source generates HTML page which may contain informative data structured in paragraphs. These paragraphs are opened with <p> tag but never closed. This is OK for HTML but is not in the spirit of XML. The proposed patch add a </p> tag at the end of the concerned paragraphs. File: source 110225 direxpand !-154,154 ! . " does not exist.</i>\n</p>\n"); !-156,156 ! "\<p align=\"center\">\n<i>This directory might exist in other versions, try 'Show attic files' or select a different Version.</i>\n</p>\n" -------------------------- and of patch ------------------------ 110225 printfile !-293,293 ! "\<p align=\"center\">\n<i>The file $pathname does not exist.</i>\n</p>\n" !-296,296 ! "\<p align=\"center\">\n<i>This file might exist in other versions, try 'Show attic files' or select a different Version.</i>\n</p>\n" ---------------- end of patch ----------------------- 110225 source init code !-308,308 ! print("\<p align=\"center\">\n<i>The file $pathname does not exist.</i>\n</p>\n"); ------------------ end of patch ---------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204285&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:45:38
|
Bugs item #3204266, was opened at 2011-03-09 15:45 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204266&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lang support Group: None Status: Open >Resolution: Works For Me >Priority: 7 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Fragment recognition too rudimentary (parsing) Initial Comment: LXR uses a very simple parser to isolate homogeneous fragment of source file to ease recognition of keywords and variables. It tries to wipe out strings, comments and include constructs, so that what is left is composed only of operators and variables. In some circumstances, the parser leaves strings before seeing the end of the string, e.g. in "A string with \" inside". The parser thinks "A string with \" is the string, the inside may be a variable and a new string is then opened out of sync. The cause is a simplistic parse based on pattern-matching with opening and closing delimiters for context. There is a need for an other kind of objects which maintain the parser in the same state when detected. What happens is data represented by the regexp associated to these objects is "swallowed" and nothing happens because they cannot be classified as opening or closing delimiters (provided it is possible, i.e. they do not appear also as these delimiters). For that, 'spec' of generic.conf is modified to have 4 parameters insted of 3: 'spec' => [ context_name, open_pattern, close_pattern, stay_pattern, ... ] (which, by the way, means a huge rewrite of generic.conf) In the case of C strings, we can now have (extract only): 'string', '"', '"', '\\\\"', But it is not enough; we must take care that this stay_pattern is considered BEFORE end_pattern because the latter is a prefix of the former and the expected match leng of stay_pattern is longer than that of end_pattern. Unhappily, there is no way to guarantee that all patterns of a 'spec' can be sorted such that they'll match from the most specific to the less specific. The proposed patch tries to solve that, but there will always be situations where it will fail. It is a consequence of pattern-matching parsing. Using a finite state automaton only to find candidate identifiers is not really worth it. Other bug loosely related: When the line is split according to all patterns of a spec, it must be determined if one element is an opening delimiter. The answer is positive if there is an exact match, that is the pattern extends from the start ^ to the end $. These anchors are added to the ends of the merged regexp containing all the patterns as a sequence of alternatives. It means that only the first delimiter is constrained to start at the beginning of the string and the last delimiter to end at the end of the string. This leads to false detection of short delimiters in the middle of strings. This is also addressed in the proposed patch. !-37 110307 (after line 37 in sub init, add:) !my @stay; # Fragment maintaining current context !-49 110307 (after line 49, add:) ! @stay = (); !-58,58 110307 (replace line 58 with:) ! while (@_ = splice(@blksep, 0, 4)) { !-61 110307 (after line 61, add:) ! push(@stay, $_[3]); !-74 110307 (after line 74, add:) ! ! foreach (@stay) { ! next if $_ eq ''; ! $split = "$_|" . $split; ! } ------------------- end of patch ------------- in sub init & nextfrag nextfrag sometimes matches erroneously delimiters because ^ and $ surround the merged patterns of all alternatives. ^ and $ should be put arround each alternative to ensure that the delimiter will match as a wholle and not as a part of the fragment. !-68,68 110307 init ! $open .= "^($_)\$|"; !-138,138 110307 nextfrag ! if ($frags[0] =~ /$open/) { !-150,150 110307 nextfrag ! if (defined($frag) && (@_ = $frag =~ /$open/)) { ------------------------ end of patch --------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204266&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:45:05
|
Bugs item #3204266, was opened at 2011-03-09 15:45 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204266&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lang support Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Fragment recognition too rudimentary (parsing) Initial Comment: LXR uses a very simple parser to isolate homogeneous fragment of source file to ease recognition of keywords and variables. It tries to wipe out strings, comments and include constructs, so that what is left is composed only of operators and variables. In some circumstances, the parser leaves strings before seeing the end of the string, e.g. in "A string with \" inside". The parser thinks "A string with \" is the string, the inside may be a variable and a new string is then opened out of sync. The cause is a simplistic parse based on pattern-matching with opening and closing delimiters for context. There is a need for an other kind of objects which maintain the parser in the same state when detected. What happens is data represented by the regexp associated to these objects is "swallowed" and nothing happens because they cannot be classified as opening or closing delimiters (provided it is possible, i.e. they do not appear also as these delimiters). For that, 'spec' of generic.conf is modified to have 4 parameters insted of 3: 'spec' => [ context_name, open_pattern, close_pattern, stay_pattern, ... ] (which, by the way, means a huge rewrite of generic.conf) In the case of C strings, we can now have (extract only): 'string', '"', '"', '\\\\"', But it is not enough; we must take care that this stay_pattern is considered BEFORE end_pattern because the latter is a prefix of the former and the expected match leng of stay_pattern is longer than that of end_pattern. Unhappily, there is no way to guarantee that all patterns of a 'spec' can be sorted such that they'll match from the most specific to the less specific. The proposed patch tries to solve that, but there will always be situations where it will fail. It is a consequence of pattern-matching parsing. Using a finite state automaton only to find candidate identifiers is not really worth it. Other bug loosely related: When the line is split according to all patterns of a spec, it must be determined if one element is an opening delimiter. The answer is positive if there is an exact match, that is the pattern extends from the start ^ to the end $. These anchors are added to the ends of the merged regexp containing all the patterns as a sequence of alternatives. It means that only the first delimiter is constrained to start at the beginning of the string and the last delimiter to end at the end of the string. This leads to false detection of short delimiters in the middle of strings. This is also addressed in the proposed patch. !-37 110307 (after line 37 in sub init, add:) !my @stay; # Fragment maintaining current context !-49 110307 (after line 49, add:) ! @stay = (); !-58,58 110307 (replace line 58 with:) ! while (@_ = splice(@blksep, 0, 4)) { !-61 110307 (after line 61, add:) ! push(@stay, $_[3]); !-74 110307 (after line 74, add:) ! ! foreach (@stay) { ! next if $_ eq ''; ! $split = "$_|" . $split; ! } ------------------- end of patch ------------- in sub init & nextfrag nextfrag sometimes matches erroneously delimiters because ^ and $ surround the merged patterns of all alternatives. ^ and $ should be put arround each alternative to ensure that the delimiter will match as a wholle and not as a part of the fragment. !-68,68 110307 init ! $open .= "^($_)\$|"; !-138,138 110307 nextfrag ! if ($frags[0] =~ /$open/) { !-150,150 110307 nextfrag ! if (defined($frag) && (@_ = $frag =~ /$open/)) { ------------------------ end of patch --------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204266&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:14:26
|
Bugs item #3204202, was opened at 2011-03-09 14:52 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204202&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lang support Group: current cvs Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: #directives not always recognised Initial Comment: C syntax allows to have spaces between # and directive names. This is correctly reflected in generic.conf patterns but not in isreserved code. The reserved keyword list in generic.conf uses the compact form of the directive. Side effect of the proposed patch: do not forget to remove also spaces in Fortran key words the day they are implemented. In Generic.pm, sub isreserved !-170 110307 (after line 170, insert:) ! $frag =~ s/\s//g ; # for those who write # include --------------- end of patch -------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204202&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:13:47
|
Bugs item #3204197, was opened at 2011-03-09 14:47 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204197&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lang support Group: None Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect identifier recognition Initial Comment: LXR v0.9.8 Generic.pm::processcode uses a pattern for identifier recognition that encompasses all forms of identifiers in all languages. In Perl, identifiers may begin with a hyphen -. When this pattern is used for C, Pascal, Fortran, ... it may erroneously capture a variable preceded by the operator - (or part of --) and this string cannot be matched against the variable. It is preferable to customize the pattern per language. Thus, 'spec' in generic.conf is extended with a new key 'identdef' with the syntax: 'identdef' => pattern_string pattern_string is not surrounded by pattern delimiters. It will be used by processcode to tag identifiers AND reserved words. It MUST then encompass these 2 classes of symbols. Do not add \b at the end, it will be done for you. Since it becomes a critical part of the process, a sensible default is always created (with the pattern used in version 0.9.8). Proposed patch for Generic.pm in sub new !-51 110304 (after line 51, insert:) ! $$self{'langmap'}{$lang}{'identdef'} = '[-\w~\#][\w]*' ! unless defined $self->langinfo('identdef'); ! -------------------------------- end of patch -------------------------------------- in sub processcode NOTE: this part of the patch is the same as the second part of patch for bug 3204171 !155,155 110303 remove processreserved ! my $source = $$code; ! my $answer = ''; ! my $identdef = $self->langinfo('identdef'); !-158,165 110303 replace regexp substitution ! while ( $source =~ s/^(.*?)($identdef)\b//s){ ! $answer .= "$1" . ! ( $self->isreserved($2) ! ? "<span class='reserved'>$2</span>" ! : ! ( $index->issymbol($2, $$self{'releaseid'}) ! ? join($2, @{$$self{'itag'}}) ! : $2 ! ) ! ); ! } ! $$code = $answer . $source; --------------------------- end of patch ------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204197&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:12:32
|
Bugs item #3204145, was opened at 2011-03-09 14:01 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204145&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Display something if initialization failed Initial Comment: LXR v0.8.9 In case something goes wrong with initialization (config read in), LXR silently dies (from the user point of view). Error message is sent to server error log which cannot be read by ordinary user. In the best case, displayed page does not change hinting at a no-op for the click. In the worst case, you get a blank screen which is really puzzling. If it is not too bad, try to send an error page (only case presently managed: no baseurl found). For that, modify Config.pm so that a new property of object $config signals the cause of error. This property has been chosen to be 'configerror'. It is created when Config.pm::initialize detects an error. Caller may then test for this existence of this property and act accordingly. Since this error signalling was needed by my use of URL to tell which tree to display in a multi-tree DB, there is also an addition to manipulate the URL to provide a meaningful informative message. In my usage, the tree name is located right before the script (i.e. source, ident, ...). It is printed in the message to show the eventual typo. In lxr.conf, you may add a global parameter like: 'treeextract' => '([^/]*)/[^/]*$' which is pattern against the SCRIPT_NAME part of the URL. $1 is used in the error message. If you need grouping before your target, use (?: instead of (. Proposed patch: 1- Common.pm in sub httpinit: !-496,496 110226 (replace line 496 with:) ! if (exists $config->{'configerror'}) { ! makeerrorpage('htmlfatal'); ! die "Can't find config for " . $HTTP->{'this_url'}; ! }; ----------------------- end of patch ------------------------------- Create anew sub makeerrorpage to issue an error page instead of 'Die'ing silently. Since LXR is badly initialized, use as few features as possible. For instance, if you don't trust a smart lxr.conf, don't use 'stylesheet' in your error page template. Anyway, if 'stylesheet' does not exist, the page is still built without substitution; it might do funny things to the UA but anyhow the page is displayed with default styles. Added a 'treeextract' parameter to provide a pattern (regexp) to extract the source tree name from URL since where to put it is a matter of personal taste. If 'treeextract' does not exist, extract the second to last part of SCRIPT_NAME. !-895 110226 & 110301 (after line 895, insert:) !sub makeerrorpage { ! my $who = shift; ! my $tmplname; ! my $template = "<html><body><hr>\n" ! . "<div align='center'>\n" ! . "<h1>Unrecoverable Error</h1><br>\n" ! . "\$tree unknown\n" ! . "</div>\n</body></html>\n"; ! ! $tmplname = $who; ! ! if ($config->value($tmplname)) { ! if (open(TEMPL, $config->value($tmplname))) { ! local ($/) = undef; ! $template = <TEMPL>; ! close(TEMPL); ! } else { ! warning("Template " . $config->value($tmplname) . " does not exist in ".`pwd`); ! } ! } ! ! print("Content-Type: text/html; charset=iso-8859-1\n"); ! print("\n"); ! ! my $treeextract = '([^/]*)/[^/]*$'; # default: capture second to last fragment ! if (exists ($config->{'treeextract'})) { ! $treeextract = $config->treeextract; ! } ! ! print( ! expandtemplate( ! $template, ! ( ! 'tree' => sub { $_ = $ENV{'SCRIPT_NAME' }; m!$treeextract!; return $1; }, ! 'stylesheet' => sub { stylesheet(@_) }, ! ) ! ) ! ); ! $config = undef; ! $files = undef; ! $index = undef; !} ! ----------------- end of patch ---------------- 2- Config.pm in sub initialize In case something goes wrong with initialization (config read in), LXR silently dies (from the user point of view). Create 'configerror' to tell caller something went screwy. Value explains why. Don't do it for genxref, since it is executed from the console and STDERR is displayed normally. There, it is better to stop the script. !-111,112 110226 (replace lines 111 and 112 with:) ! if(!exists $self->{baseurl}) { ! if("genxref" ne ($0 =~ /([^\/]*)$/)) { ! $$self{'configerror'} = "nobaseurl"; return 1; ! } elsif($url =~ m!http://.+\.!) { ----------------- end of patch ----------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204145&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:11:48
|
Bugs item #3204114, was opened at 2011-03-09 13:30 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204114&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Display nicely non ISO-8859-1 trees Initial Comment: LXR v0.9.8 LXR sends an HTTP header advertising for ISO-8859-1 content which is not always the case with Unicode becoming ubiquitous. This can be circumvented by creating a new tree-specific parameter for the charset to use with the tree. Its syntax is: 'encoding' => 'iso-8859-1' # default value in order not to disrupt LXR operation Instead of 'iso-8859-1', you can use any IANA defined charset. This involves patches in several files: 1- Common.pm In sub printhttp, send correct header: -448,448 110227 (replace line 448 with:) print("Content-Type: text/html; charset=", $config->{'encoding'}, "\n"); ---------------------- end of patch -------------------- In sub makeheader, add a variable substitution in case an HTML template wants to use 'encoding' for example in a <meta > tag: -852 110227 (insert after line 852:) 'encoding' => sub { return $config->{'encoding'}; }, --------------------- end of patch ------------------------ 2- Config.pm In sub initialize Make sure parameter 'encoding' has a reasonable default value -109 110227 (insert after line 109) $$self{'encoding'} = "iso-8859-1" unless (exists $self->{'encoding'}); ---------------------------- end of patch ----------------- 3- html-head.html With the introduction of the 'encoding' config parameter to advertise the character set used in the content, add the following line after <title>: -4 (insert after line 4) <meta http-equiv="content-type" content="text/html; charset=$encoding"> ---------------------- end of patch --------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204114&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:11:07
|
Bugs item #3204096, was opened at 2011-03-09 13:14 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204096&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open >Resolution: Works For Me >Priority: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Useless link on every line number Initial Comment: LXR v0.9.8 File Common.pm, sub markupfile All lines of a file can be the target of a link. For that, they are tagged with an anchor <a name=#line>#line</a>. But in the standard implementation they also contain href=(to itself) which does not make sense since we'll never need to jump from "here" to the "same place". Getting rid of the href= will also contribute transferring less data. Upon return &fileref(1,"fline",$pathname,1) is split in @ltag to later easily generate the tag. In the proposed change, the split is modified to "forget" the href: instead of /^(<a)(.*\#)001(\">)1(<\/a>)$/ use /^(<a.*?)(?:href.*\#)001(\">)1(<\/a>)$/ and change accordingly @ltag @ltag BEFORE: 0 - <a (with name= appended) 1 - class ... href="...# 2 - "> 3 - </a> @ltag AFTER: 0 - <a class... (with name=" appended) -- double quote needed 2 - "> 3 - </a> which sums up to: -263,265 110226 (replace lines 263 to 265) my @ltag = &fileref(1, "fline", $pathname, 1) =~ /^(<a.*?)(?:href.*\#)001(\">)1(<\/a>)$/; $ltag[0] .= 'name="'; $ltag[2] .= " "; --------------- end of patch ---------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204096&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:10:15
|
Bugs item #3204089, was opened at 2011-03-09 13:07 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204089&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Image files never displayed Initial Comment: LXR v0.9.8 Graphic file cannot be displayed because synthesized URL is a query for LXR to process a source file instead of a simple file path. Proposed patch for Common.pm: -316,321 110307 (replace lines 316 to 321 with:) &$outfun("<ul><table><tr><th valign=\"center\"><b>Image: </b></th></tr>\n"); &$outfun("<tr><td>"); &$outfun("<img src=\"$config->{virtroot}" . $pathname . "\" border=\"0\"" . " alt=\"$pathname cannot be displayed by this browser\">\n"); &$outfun("</td></tr></table></ul>"); --------------- end of patch ----------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204089&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:09:39
|
Bugs item #3204085, was opened at 2011-03-09 13:02 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204085&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Pattern graphicfile never matches Initial Comment: LXR v0.9.8 For an obscure reason (Perl syntax shortcoming or bug in current Linux Perl interpreter), test for "graphic" files in pattern /$config->graphicfile/ (Common.pm line 315) never succeeds. It looks like references $config->... cannot be use in a regexp no matter how you parenthesize them. To correct, proceed in two steps. Proposed patch: in Common.pm -260 110307 (after line 260, insert:) my $graphic = $config->graphicfile; -315,315 110307 (replace line 315 with:) } elsif ($pathname =~ /$graphic/) { ------------- end of patch ---------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204085&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:08:58
|
Bugs item #3204218, was opened at 2011-03-09 15:08 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204218&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lang support Group: None Status: Open >Resolution: Works For Me Priority: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Empty comment block at beginning of line Initial Comment: With comments spanning multiple lines, an extraneous <span class="comment"></span> is left at the beginning of the line following the comment block. This is caused by the \n of every line being changed to </span>\n<span class="comment">. Though harmless, it is inelegant. It can easily be removed, contributing to transmit less data. Proposed patch: In Lang, sub processcomment !-87 110304 (after line 87, insert:) ! $$frag =~ s#<span class=\"comment\"></span>$## ; #remove excess marking -------------------- end of patch ---------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204218&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:08:33
|
Bugs item #3204218, was opened at 2011-03-09 15:08 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204218&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lang support Group: None Status: Open Resolution: None >Priority: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Empty comment block at beginning of line Initial Comment: With comments spanning multiple lines, an extraneous <span class="comment"></span> is left at the beginning of the line following the comment block. This is caused by the \n of every line being changed to </span>\n<span class="comment">. Though harmless, it is inelegant. It can easily be removed, contributing to transmit less data. Proposed patch: In Lang, sub processcomment !-87 110304 (after line 87, insert:) ! $$frag =~ s#<span class=\"comment\"></span>$## ; #remove excess marking -------------------- end of patch ---------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204218&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:08:06
|
Bugs item #3204218, was opened at 2011-03-09 15:08 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204218&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lang support Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Empty comment block at beginning of line Initial Comment: With comments spanning multiple lines, an extraneous <span class="comment"></span> is left at the beginning of the line following the comment block. This is caused by the \n of every line being changed to </span>\n<span class="comment">. Though harmless, it is inelegant. It can easily be removed, contributing to transmit less data. Proposed patch: In Lang, sub processcomment !-87 110304 (after line 87, insert:) ! $$frag =~ s#<span class=\"comment\"></span>$## ; #remove excess marking -------------------- end of patch ---------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204218&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 14:00:28
|
Bugs item #3204208, was opened at 2011-03-09 15:00 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204208&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lang support Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Script language not always recognised Initial Comment: LXR v0.9.8 In Lang.pm When trying to determine script language, test is for the beginning of the last part of a path, i.e. /interp. Matches if key of 'interpreters' is a prefix of the script interpreter name. Unhappily, prevents LXR-scripts from being recognised as they do not include a path. Test changed to match 'interpreters' name at end of string (without /) Potential problem: it is no longer a prefix test; are there cases where it matters? !-53,53 110227 (replace line 53 of new with:) ! if ($shebang =~ /$patt$/) { ---------------------- end of path -------------------------------- There is a related issue: Some files which are not scripts contain an emacs specification telling which language is used (e.g. the *.conf files in LXR). In that case, parse the spec to extract the language name and act just as if it was a script. !-46,46 110308 (replace line 46 with:) ! my $line = $fh->getline; ! ($line =~ /^\#!\s*(\S+)/s) ! || ($line =~ /^.*-[*]-.*?[ \t;]mode:[ \t]*(\w+).*-[*]-/); --------------------------- end of patch ------------------------------ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204208&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 13:53:11
|
Bugs item #3204197, was opened at 2011-03-09 14:47 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204197&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Lang support Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect identifier recognition Initial Comment: LXR v0.9.8 Generic.pm::processcode uses a pattern for identifier recognition that encompasses all forms of identifiers in all languages. In Perl, identifiers may begin with a hyphen -. When this pattern is used for C, Pascal, Fortran, ... it may erroneously capture a variable preceded by the operator - (or part of --) and this string cannot be matched against the variable. It is preferable to customize the pattern per language. Thus, 'spec' in generic.conf is extended with a new key 'identdef' with the syntax: 'identdef' => pattern_string pattern_string is not surrounded by pattern delimiters. It will be used by processcode to tag identifiers AND reserved words. It MUST then encompass these 2 classes of symbols. Do not add \b at the end, it will be done for you. Since it becomes a critical part of the process, a sensible default is always created (with the pattern used in version 0.9.8). Proposed patch for Generic.pm in sub new !-51 110304 (after line 51, insert:) ! $$self{'langmap'}{$lang}{'identdef'} = '[-\w~\#][\w]*' ! unless defined $self->langinfo('identdef'); ! -------------------------------- end of patch -------------------------------------- in sub processcode NOTE: this part of the patch is the same as the second part of patch for bug 3204171 !155,155 110303 remove processreserved ! my $source = $$code; ! my $answer = ''; ! my $identdef = $self->langinfo('identdef'); !-158,165 110303 replace regexp substitution ! while ( $source =~ s/^(.*?)($identdef)\b//s){ ! $answer .= "$1" . ! ( $self->isreserved($2) ! ? "<span class='reserved'>$2</span>" ! : ! ( $index->issymbol($2, $$self{'releaseid'}) ! ? join($2, @{$$self{'itag'}}) ! : $2 ! ) ! ); ! } ! $$code = $answer . $source; --------------------------- end of patch ------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204197&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 13:52:22
|
Bugs item #3204202, was opened at 2011-03-09 14:52 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204202&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lang support Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: #directives not always recognised Initial Comment: C syntax allows to have spaces between # and directive names. This is correctly reflected in generic.conf patterns but not in isreserved code. The reserved keyword list in generic.conf uses the compact form of the directive. Side effect of the proposed patch: do not forget to remove also spaces in Fortran key words the day they are implemented. In Generic.pm, sub isreserved !-170 110307 (after line 170, insert:) ! $frag =~ s/\s//g ; # for those who write # include --------------- end of patch -------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204202&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 13:47:08
|
Bugs item #3204197, was opened at 2011-03-09 14:47 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204197&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect identifier recognition Initial Comment: LXR v0.9.8 Generic.pm::processcode uses a pattern for identifier recognition that encompasses all forms of identifiers in all languages. In Perl, identifiers may begin with a hyphen -. When this pattern is used for C, Pascal, Fortran, ... it may erroneously capture a variable preceded by the operator - (or part of --) and this string cannot be matched against the variable. It is preferable to customize the pattern per language. Thus, 'spec' in generic.conf is extended with a new key 'identdef' with the syntax: 'identdef' => pattern_string pattern_string is not surrounded by pattern delimiters. It will be used by processcode to tag identifiers AND reserved words. It MUST then encompass these 2 classes of symbols. Do not add \b at the end, it will be done for you. Since it becomes a critical part of the process, a sensible default is always created (with the pattern used in version 0.9.8). Proposed patch for Generic.pm in sub new !-51 110304 (after line 51, insert:) ! $$self{'langmap'}{$lang}{'identdef'} = '[-\w~\#][\w]*' ! unless defined $self->langinfo('identdef'); ! -------------------------------- end of patch -------------------------------------- in sub processcode NOTE: this part of the patch is the same as the second part of patch for bug 3204171 !155,155 110303 remove processreserved ! my $source = $$code; ! my $answer = ''; ! my $identdef = $self->langinfo('identdef'); !-158,165 110303 replace regexp substitution ! while ( $source =~ s/^(.*?)($identdef)\b//s){ ! $answer .= "$1" . ! ( $self->isreserved($2) ! ? "<span class='reserved'>$2</span>" ! : ! ( $index->issymbol($2, $$self{'releaseid'}) ! ? join($2, @{$$self{'itag'}}) ! : $2 ! ) ! ); ! } ! $$code = $answer . $source; --------------------------- end of patch ------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204197&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 13:23:53
|
Bugs item #3204171, was opened at 2011-03-09 14:23 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204171&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Garbled output for include files Initial Comment: LXR v0.9.8 If include filename is <span or contains class or reserved, HTML output is garbled with <span > block embedded in <pan > block. This is the same bug as that related to variable using HTML keywords and attributes (span, class, reserved). Its cause is the same: a 2-stage process where substitutions from the first are not protected against substitutions of the second. Proposed patch: 1- Lang.pm 110304 processinclude Same design flaw as in processcode (Generic.pm): all replacement/markings should be processed simultaneously. Since we are supposed to find a single include in the fragment, it can be dealt with without loop. Beware! It has been very tedious to debug. !-77,80 110304 (replace lines 77 to 80 with:) ! my $source = $$frag; ! ! $source =~ s/^ # reminder: no initial space in the grammar ! ([\w\#]\s*[\w]*) # reserved keyword for include construct ! (\s+) # space ! (?| (\")(.+?)(\") # C syntax ! | (\0<)(.+?)(\0>) # C alternate syntax ! | ()([\w:]+)(\b) # Perl and others ! ) ! //sx ; ! $$frag = ( $self->isreserved($1) ! ? "<span class='reserved'>$1</span>" ! : "$1" ! ) ! . "$2$3" ! . &LXR::Common::incref($4, "include" ,$4 ,$dir) ! . "$5" ! . $source; # tail if any (e.g. in Perl) --------------------- end of patch ----------------------- 2- Generic.pm Since this bug is closely related to the one for variables span class and reserved, I give the associated patch here for sub processcode This sub HTML-marks the sequences of character equal to a reserved word, then does the same for identifiers. If it happens that one identifier looks the same as an HTML tag, attribute or attribute value, the HTML marking gets marked itself. W3C says HTML sentences cannot be embedded inside a <...>. The net result is the browser gets confused and displays garbage. HTML-markings must be protected from rescan of file fragment. The only way to do it safely, whatever the other processings, is to do all replacements simultaneously, so that they are mutually exclusive. It has been chosen to scan the fragment from left to right without backtracking: candidate prefixes are removed from the fragment and processed for replacement. The replacement result is then appended to a string. This string is returned as the value of the sub when scanning is complete. NOTE: lines containing $identdef are related language dependent recognition of identifiers (patch dated 110304) !155,155 110303 (replace line 155 with the following, effectively removing processreserved) ! my $source = $$code; ! my $answer = ''; ! my $identdef = $self->langinfo('identdef'); !-158,165 110303 replace regexp substitution ! while ( $source =~ s/^(.*?)($identdef)\b//s){ ! $answer .= "$1" . ! ( $self->isreserved($2) ! ? "<span class='reserved'>$2</span>" ! : ! ( $index->issymbol($2, $$self{'releaseid'}) ! ? join($2, @{$$self{'itag'}}) ! : $2 ! ) ! ); ! } ! $$code = $answer . $source; --------------------------- end of patch ------------------------ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204171&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 13:01:08
|
Bugs item #3204145, was opened at 2011-03-09 14:01 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204145&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Display something if initialization failed Initial Comment: LXR v0.8.9 In case something goes wrong with initialization (config read in), LXR silently dies (from the user point of view). Error message is sent to server error log which cannot be read by ordinary user. In the best case, displayed page does not change hinting at a no-op for the click. In the worst case, you get a blank screen which is really puzzling. If it is not too bad, try to send an error page (only case presently managed: no baseurl found). For that, modify Config.pm so that a new property of object $config signals the cause of error. This property has been chosen to be 'configerror'. It is created when Config.pm::initialize detects an error. Caller may then test for this existence of this property and act accordingly. Since this error signalling was needed by my use of URL to tell which tree to display in a multi-tree DB, there is also an addition to manipulate the URL to provide a meaningful informative message. In my usage, the tree name is located right before the script (i.e. source, ident, ...). It is printed in the message to show the eventual typo. In lxr.conf, you may add a global parameter like: 'treeextract' => '([^/]*)/[^/]*$' which is pattern against the SCRIPT_NAME part of the URL. $1 is used in the error message. If you need grouping before your target, use (?: instead of (. Proposed patch: 1- Common.pm in sub httpinit: !-496,496 110226 (replace line 496 with:) ! if (exists $config->{'configerror'}) { ! makeerrorpage('htmlfatal'); ! die "Can't find config for " . $HTTP->{'this_url'}; ! }; ----------------------- end of patch ------------------------------- Create anew sub makeerrorpage to issue an error page instead of 'Die'ing silently. Since LXR is badly initialized, use as few features as possible. For instance, if you don't trust a smart lxr.conf, don't use 'stylesheet' in your error page template. Anyway, if 'stylesheet' does not exist, the page is still built without substitution; it might do funny things to the UA but anyhow the page is displayed with default styles. Added a 'treeextract' parameter to provide a pattern (regexp) to extract the source tree name from URL since where to put it is a matter of personal taste. If 'treeextract' does not exist, extract the second to last part of SCRIPT_NAME. !-895 110226 & 110301 (after line 895, insert:) !sub makeerrorpage { ! my $who = shift; ! my $tmplname; ! my $template = "<html><body><hr>\n" ! . "<div align='center'>\n" ! . "<h1>Unrecoverable Error</h1><br>\n" ! . "\$tree unknown\n" ! . "</div>\n</body></html>\n"; ! ! $tmplname = $who; ! ! if ($config->value($tmplname)) { ! if (open(TEMPL, $config->value($tmplname))) { ! local ($/) = undef; ! $template = <TEMPL>; ! close(TEMPL); ! } else { ! warning("Template " . $config->value($tmplname) . " does not exist in ".`pwd`); ! } ! } ! ! print("Content-Type: text/html; charset=iso-8859-1\n"); ! print("\n"); ! ! my $treeextract = '([^/]*)/[^/]*$'; # default: capture second to last fragment ! if (exists ($config->{'treeextract'})) { ! $treeextract = $config->treeextract; ! } ! ! print( ! expandtemplate( ! $template, ! ( ! 'tree' => sub { $_ = $ENV{'SCRIPT_NAME' }; m!$treeextract!; return $1; }, ! 'stylesheet' => sub { stylesheet(@_) }, ! ) ! ) ! ); ! $config = undef; ! $files = undef; ! $index = undef; !} ! ----------------- end of patch ---------------- 2- Config.pm in sub initialize In case something goes wrong with initialization (config read in), LXR silently dies (from the user point of view). Create 'configerror' to tell caller something went screwy. Value explains why. Don't do it for genxref, since it is executed from the console and STDERR is displayed normally. There, it is better to stop the script. !-111,112 110226 (replace lines 111 and 112 with:) ! if(!exists $self->{baseurl}) { ! if("genxref" ne ($0 =~ /([^\/]*)$/)) { ! $$self{'configerror'} = "nobaseurl"; return 1; ! } elsif($url =~ m!http://.+\.!) { ----------------- end of patch ----------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204145&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 12:14:57
|
Bugs item #3204096, was opened at 2011-03-09 13:14 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204096&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Useless link on every line number Initial Comment: LXR v0.9.8 File Common.pm, sub markupfile All lines of a file can be the target of a link. For that, they are tagged with an anchor <a name=#line>#line</a>. But in the standard implementation they also contain href=(to itself) which does not make sense since we'll never need to jump from "here" to the "same place". Getting rid of the href= will also contribute transferring less data. Upon return &fileref(1,"fline",$pathname,1) is split in @ltag to later easily generate the tag. In the proposed change, the split is modified to "forget" the href: instead of /^(<a)(.*\#)001(\">)1(<\/a>)$/ use /^(<a.*?)(?:href.*\#)001(\">)1(<\/a>)$/ and change accordingly @ltag @ltag BEFORE: 0 - <a (with name= appended) 1 - class ... href="...# 2 - "> 3 - </a> @ltag AFTER: 0 - <a class... (with name=" appended) -- double quote needed 2 - "> 3 - </a> which sums up to: -263,265 110226 (replace lines 263 to 265) my @ltag = &fileref(1, "fline", $pathname, 1) =~ /^(<a.*?)(?:href.*\#)001(\">)1(<\/a>)$/; $ltag[0] .= 'name="'; $ltag[2] .= " "; --------------- end of patch ---------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204096&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 12:08:45
|
Bugs item #3204089, was opened at 2011-03-09 13:07 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204089&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) >Summary: Image files never displayed Initial Comment: LXR v0.9.8 Graphic file cannot be displayed because synthesized URL is a query for LXR to process a source file instead of a simple file path. Proposed patch for Common.pm: -316,321 110307 (replace lines 316 to 321 with:) &$outfun("<ul><table><tr><th valign=\"center\"><b>Image: </b></th></tr>\n"); &$outfun("<tr><td>"); &$outfun("<img src=\"$config->{virtroot}" . $pathname . "\" border=\"0\"" . " alt=\"$pathname cannot be displayed by this browser\">\n"); &$outfun("</td></tr></table></ul>"); --------------- end of patch ----------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204089&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 12:07:50
|
Bugs item #3204089, was opened at 2011-03-09 13:07 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204089&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Image files never dispalyed Initial Comment: LXR v0.9.8 Graphic file cannot be displayed because synthesized URL is a query for LXR to process a source file instead of a simple file path. Proposed patch for Common.pm: -316,321 110307 (replace lines 316 to 321 with:) &$outfun("<ul><table><tr><th valign=\"center\"><b>Image: </b></th></tr>\n"); &$outfun("<tr><td>"); &$outfun("<img src=\"$config->{virtroot}" . $pathname . "\" border=\"0\"" . " alt=\"$pathname cannot be displayed by this browser\">\n"); &$outfun("</td></tr></table></ul>"); --------------- end of patch ----------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204089&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-09 12:02:28
|
Bugs item #3204085, was opened at 2011-03-09 13:02 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204085&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Pattern graphicfile never matches Initial Comment: LXR v0.9.8 For an obscure reason (Perl syntax shortcoming or bug in current Linux Perl interpreter), test for "graphic" files in pattern /$config->graphicfile/ (Common.pm line 315) never succeeds. It looks like references $config->... cannot be use in a regexp no matter how you parenthesize them. To correct, proceed in two steps. Proposed patch: in Common.pm -260 110307 (after line 260, insert:) my $graphic = $config->graphicfile; -315,315 110307 (replace line 315 with:) } elsif ($pathname =~ /$graphic/) { ------------- end of patch ---------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204085&group_id=27350 |
|
From: Malcolm B. <mal...@gm...> - 2011-03-08 21:57:51
|
Hi, As you may have noticed, the LXR desperately needs to get moving again. The last LXR release was over a year ago, yet the project still has plenty left to do. There are lots of bugs and patches on the issue tracker, and there's plenty of scope for new development, for example in giving the LXR a modern web front end or in radically improving the language understanding. Sadly I'm no longer able to give the time to LXR that it needs, and thus am retiring as maintainer and project owner. If LXR matters to you, and you want to see it develop and improve, please come forward to take over the reins. You can do so either directly to me ( mb...@us...) or via the lxr-developer mailing list. All the best, Malcolm (Ex) LXR maintainer |
6 messages has been excluded from this view by a project administrator.
