lxr-developer Mailing List for LXR Cross Referencer (Page 9)
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-25 19:54:24
|
Bugs item #3234266, was opened at 2011-03-22 09:46 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3234266&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: Closed Resolution: Fixed Priority: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Bad template designation for footer Initial Comment: LXR 0.9.8 and previous versions Common.pm When makefooter was created by copy-and-paste from makeheader, specific template selection was not adjusted from sourcedirhead to sourcedirtail. Typo corrected in CVS for next release 0.9.9 ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-22 09:47 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3234266&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-22 08:47:14
|
Bugs item #3234266, was opened at 2011-03-22 09:46 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3234266&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: Fixed Priority: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Bad template designation for footer Initial Comment: LXR 0.9.8 and previous versions Common.pm When makefooter was created by copy-and-paste from makeheader, specific template selection was not adjusted from sourcedirhead to sourcedirtail. Typo corrected in CVS for next release 0.9.9 ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-22 09:47 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3234266&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-22 08:46:33
|
Bugs item #3234266, was opened at 2011-03-22 09:46 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3234266&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: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Bad template designation for footer Initial Comment: LXR 0.9.8 and previous versions Common.pm When makefooter was created by copy-and-paste from makeheader, specific template selection was not adjusted from sourcedirhead to sourcedirtail. Typo corrected in CVS for next release 0.9.9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3234266&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-18 07:52:31
|
Bugs item #3220139, was opened at 2011-03-17 16:08 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3220139&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: Closed >Resolution: Remind >Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Security fix: robot snooping Initial Comment: Within 24 hours after clicking on "html 4 verified" logo (and having received a positive check from W3C), Microsoft's robot Bingbot tried to crawl and index my machine. My test tree lies in a very private part of my computer and is connected to the Net on an unusual port (in the private range). The only explanation for this intrusion is that W3C validation sites are compromised. To prevent such intrusion, comment out the link under HTML logo. If production site admins want the validation feature, they can uncomment the link. Does it sound sane? ---------------------------------------------------------------------- Comment By: Malcolm Box (mbox) Date: 2011-03-17 19:01 Message: That doesn't seem like a good fix since it removes an easy way for our users to check that we really are compliant. If your machine is on the internet and serving files, then it *will* be discovered and crawled by someone. There's enough places where traces of activity will be left. LXR could include a robots.txt file to block access to (well behaved) robots unless the admin deliberately turns the block off. That would seem like a good thing to do, especially since crawling a LXR tree is likely to go wrong in interesting ways. We could also add a warning note in the install instructions not to run LXR with a public webserver unless you want your source code exported to the world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3220139&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-17 18:01:52
|
Bugs item #3220139, was opened at 2011-03-17 15:08 Message generated for change (Comment added) made by mbox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3220139&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: 9 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Security fix: robot snooping Initial Comment: Within 24 hours after clicking on "html 4 verified" logo (and having received a positive check from W3C), Microsoft's robot Bingbot tried to crawl and index my machine. My test tree lies in a very private part of my computer and is connected to the Net on an unusual port (in the private range). The only explanation for this intrusion is that W3C validation sites are compromised. To prevent such intrusion, comment out the link under HTML logo. If production site admins want the validation feature, they can uncomment the link. Does it sound sane? ---------------------------------------------------------------------- >Comment By: Malcolm Box (mbox) Date: 2011-03-17 18:01 Message: That doesn't seem like a good fix since it removes an easy way for our users to check that we really are compliant. If your machine is on the internet and serving files, then it *will* be discovered and crawled by someone. There's enough places where traces of activity will be left. LXR could include a robots.txt file to block access to (well behaved) robots unless the admin deliberately turns the block off. That would seem like a good thing to do, especially since crawling a LXR tree is likely to go wrong in interesting ways. We could also add a warning note in the install instructions not to run LXR with a public webserver unless you want your source code exported to the world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3220139&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-17 15:08:39
|
Bugs item #3220139, was opened at 2011-03-17 16: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=3220139&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: 9 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Security fix: robot snooping Initial Comment: Within 24 hours after clicking on "html 4 verified" logo (and having received a positive check from W3C), Microsoft's robot Bingbot tried to crawl and index my machine. My test tree lies in a very private part of my computer and is connected to the Net on an unusual port (in the private range). The only explanation for this intrusion is that W3C validation sites are compromised. To prevent such intrusion, comment out the link under HTML logo. If production site admins want the validation feature, they can uncomment the link. Does it sound sane? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3220139&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-17 14:54:12
|
Bugs item #3116715, was opened at 2010-11-23 17:00 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3116715&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: dcochlin (dcochlin) Assigned to: Andre-Littoz (ajlittoz) Summary: C/C++ language: #elsif should be #elseif Initial Comment: - generic.conf should define #elseif instead of #elsif. - Python language could use a triple quote comment 'comment' => ('"""', '"""'), ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-17 15:54 Message: The parser has been fixed. At the same time #elif has been put in the reserved words for C and C++ in lieu of #elsif. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-17 15:54 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-13 09:19 Message: The directive is #elif, not #elseif nor #elsif. The correct word has been put into the projected generic.conf. However, since there is a lot of work on generic.conf related to generic parsing, this minor correction is postponed to the parsing issue release. ---------------------------------------------------------------------- Comment By: Damian Nycz (dnycz) Date: 2011-01-29 18:14 Message: In C/C++ language there is no '#elseif' nor '#elsif'; there is '#elif'; generic.conf should define '#elif' instead of '#elsif'. There is missing '#line' directive in C/C++. There is missing 'compl' C++ keyword. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3116715&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-17 14:30:27
|
Feature Requests item #3219549, was opened at 2011-03-17 12:10 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3219549&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: Language support Group: None Status: Closed Priority: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) >Assigned to: Andre-Littoz (ajlittoz) Summary: Cope with language-specific syntax for include Initial Comment: Presently LXR is able to detect 'include' constructs but it is process in the C spirit, i.e. what follows the keyword is supposed to be the filename with standard OS path. In Perl, the include object after 'use' may contain :: separators instead of / and does not include the file extension like .pm. It would be nice if processinclude may take into account the syntax of the language to manipulate the file argument before handing it over to incref. This could be done through a new parameter in generic.cong language description while retaining the present processing as a default. For Perl, we could have: , 'include' => { 'directive' => '([\\w]+)(\s+)()([\\w:]+)(\\b)' , 'global' => [ '::', '/' ] , 'last' => [ '$', '.pm' ] } 'directive' is used to split the fragment coming from parsing into the keyword $1, some space $2, the target file $3 and the rest of the fragment $4. The target file is first submitted to 'first' one-shot substitution, then to 'global' repeated substitution (with g modifier) and finally to 'last' one-shot substitution. The above example says: replace all occurrences of :: by /. In the end add extension .pm to resultant path. At this step we have a "standard" filename which can be handed to the common incref processing. If it hits a known file, it can be highlighted and can be clicked. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-17 15:26 Message: Added in CVS Made a mistake in comment: 'directive' must split into FIVE (5) strings: keyword $1, space $2, left delim $3, target file $4, right delim $5. Any string may be empty. This involves creating a processinclude inside generic.conf and modifying the language specifications. C and C++ nedd none (default processing). Coded 'include' for Perl. Didn't try for Python. LIMITATION: can handle only one include object per include directive. Consequently does not handle Python general case, which would require more changes in parsing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3219549&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-17 14:29:44
|
Feature Requests item #2808116, was opened at 2009-06-18 04:06 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=2808116&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: Language support Group: None >Status: Pending Priority: 5 Private: No Submitted By: David (hawaiian717) >Assigned to: Andre-Littoz (ajlittoz) Summary: Handling of Python import Initial Comment: It would be nice if Python import statements were handled similar to C #includes, where the file links to the included file. It appears that currently, certain imported modules will link to a keyword search and others will be unlinked. Syntax for the import statement can be found here: http://docs.python.org/reference/simple_stmts.html#the-import-statement ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-17 15:29 Message: I have added a generic processing. Read feature request "cope with language-specific syntax for include files" to see if that suits your needs. To test, either extract from CVS or wait for the 0.9.9 release, due very soon. Please give feed back. ---------------------------------------------------------------------- Comment By: David (hawaiian717) Date: 2009-06-30 22:53 Message: Sorry for the delay in responding, I had a few other things come up before I could get back to this. I've attached an HTML file with some sample output (I removed some of the header info, but you should still get the idea). "time" is a standard Python module, so I wouldn't necessarily expect LXR to be able to link to it. "version", "management", and "device" are all in the same directory as the test file. One thing to note is that the include statement doesn't include the .py filename extension. ---------------------------------------------------------------------- Comment By: AdrianIssott (adrianissott) Date: 2009-06-19 21:50 Message: David, please could you provide some examples of when the import statements aren't linking to the included file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=2808116&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-17 11:10:44
|
Feature Requests item #3219549, was opened at 2011-03-17 12:10 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3219549&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: Language support Group: None Status: Open Priority: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Nobody/Anonymous (nobody) Summary: Cope with language-specific syntax for include Initial Comment: Presently LXR is able to detect 'include' constructs but it is process in the C spirit, i.e. what follows the keyword is supposed to be the filename with standard OS path. In Perl, the include object after 'use' may contain :: separators instead of / and does not include the file extension like .pm. It would be nice if processinclude may take into account the syntax of the language to manipulate the file argument before handing it over to incref. This could be done through a new parameter in generic.cong language description while retaining the present processing as a default. For Perl, we could have: , 'include' => { 'directive' => '([\\w]+)(\s+)()([\\w:]+)(\\b)' , 'global' => [ '::', '/' ] , 'last' => [ '$', '.pm' ] } 'directive' is used to split the fragment coming from parsing into the keyword $1, some space $2, the target file $3 and the rest of the fragment $4. The target file is first submitted to 'first' one-shot substitution, then to 'global' repeated substitution (with g modifier) and finally to 'last' one-shot substitution. The above example says: replace all occurrences of :: by /. In the end add extension .pm to resultant path. At this step we have a "standard" filename which can be handed to the common incref processing. If it hits a known file, it can be highlighted and can be clicked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3219549&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-14 20:43:05
|
Bugs item #2950793, was opened at 2010-02-12 19:55 Message generated for change (Comment added) made by mbox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2950793&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: Database interface Group: None Status: Pending Resolution: Out of Date Priority: 5 Private: No Submitted By: Patrick Gartung (gartung) Assigned to: Nobody/Anonymous (nobody) Summary: genxref --reindexall with MySQL causes unknown table error Initial Comment: Running genxref --reindexall when using MySQL 4.x produces an unkonown table error from mysql server. Using the syntax suggested at this site http://www.portfolioofpb.com/blog/mysql-sql-error-unknown-table-in-MULTI+DELETE-solved I modified lib/LXR/Index/Mysql.pm to use the correct syntax for mysql 4.x ---------------------------------------------------------------------- >Comment By: Malcolm Box (mbox) Date: 2011-03-14 20:43 Message: Maintaining compatibility with MySQL 4.x is useful as there are plenty of places still running this. Does the proposed change work on 5.x - if so it seems it would be worth keeping this in the main trunk. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-13 08:32 Message: MySQL 4.x ended 31 December 2010. Consequently is there still a need for including this correction in the main line? If somebody does need it, please resubmit and I'll create a (short lived) branch in the CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2950793&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-13 08:32:47
|
Bugs item #2950793, was opened at 2010-02-12 20:55 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2950793&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: Database interface Group: None >Status: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: Patrick Gartung (gartung) Assigned to: Nobody/Anonymous (nobody) Summary: genxref --reindexall with MySQL causes unknown table error Initial Comment: Running genxref --reindexall when using MySQL 4.x produces an unkonown table error from mysql server. Using the syntax suggested at this site http://www.portfolioofpb.com/blog/mysql-sql-error-unknown-table-in-MULTI+DELETE-solved I modified lib/LXR/Index/Mysql.pm to use the correct syntax for mysql 4.x ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-13 09:32 Message: MySQL 4.x ended 31 December 2010. Consequently is there still a need for including this correction in the main line? If somebody does need it, please resubmit and I'll create a (short lived) branch in the CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2950793&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-13 08:19:20
|
Bugs item #3116715, was opened at 2010-11-23 17:00 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3116715&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: Pending >Resolution: Later Priority: 5 Private: No Submitted By: dcochlin (dcochlin) Assigned to: Andre-Littoz (ajlittoz) Summary: C/C++ language: #elsif should be #elseif Initial Comment: - generic.conf should define #elseif instead of #elsif. - Python language could use a triple quote comment 'comment' => ('"""', '"""'), ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-13 09:19 Message: The directive is #elif, not #elseif nor #elsif. The correct word has been put into the projected generic.conf. However, since there is a lot of work on generic.conf related to generic parsing, this minor correction is postponed to the parsing issue release. ---------------------------------------------------------------------- Comment By: Damian Nycz (dnycz) Date: 2011-01-29 18:14 Message: In C/C++ language there is no '#elseif' nor '#elsif'; there is '#elif'; generic.conf should define '#elif' instead of '#elsif'. There is missing '#line' directive in C/C++. There is missing 'compl' C++ keyword. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3116715&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-12 15:33:15
|
Bugs item #2778652, was opened at 2009-04-22 16:27 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2778652&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: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: Malcolm Box (mbox) Assigned to: Malcolm Box (mbox) Summary: Filenames with % break Initial Comment: Filenames with a % character in them cannot be browsed - the filename is truncated at the % and source reports that the file does not exist. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 16:33 Message: Has been fixed in a version before 0.9.8 ---------------------------------------------------------------------- Comment By: Malcolm Box (mbox) Date: 2009-05-14 23:28 Message: Correction - filenames with a %3 or %n where n is a numeric character break. % followed by a letter is OK. Presumably this is caused by a bug in the URL-encoding/decoding functions ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2778652&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-12 15:07:05
|
Bugs item #2783472, was opened at 2009-04-29 10:23 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2783472&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: v0.9.6 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: .htaccess-apache2 doesn't work under Apache2.2 Initial Comment: [Wed Apr 29 10:14:16 2009] [alert] [client x.x.x.x] [snip]/xref/.htaccess: This package can't be used under threaded MPMs at /usr/lib/perl5/ModPerl/RegistryPrefork.pm line 12.\nCompilation failed in require at (eval 2) line 3.\n ~/xref$ /usr/sbin/apache2 -V Server version: Apache/2.2.8 (Ubuntu) Server built: Jun 25 2008 13:50:52 Server's Module Magic Number: 20051115:11 Server loaded: APR 1.2.11, APR-Util 1.2.12 Compiled using: APR 1.2.11, APR-Util 1.2.12 Architecture: 32-bit Server MPM: Worker threaded: yes (fixed thread count) forked: yes (variable process count) Server compiled with.... -D APACHE_MPM_DIR="server/mpm/worker" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="" -D SUEXEC_BIN="/usr/lib/apache2/suexec" -D DEFAULT_PIDLOG="/var/run/apache2.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types" -D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf" mod_perl from: libapache2-mod-perl2 2.0.3-2ubuntu2 ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 16:07 Message: Cannot reproduce bug. If problem persists, resubmit stating which LXR and Perl versions are used ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2783472&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-12 13:48:04
|
Bugs item #2955434, was opened at 2010-02-20 04:09 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2955434&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: Deleted >Resolution: Duplicate Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong coloring Initial Comment: Hi, Have a look here http://lxr.linux.no/linux+v2.6.32/net/core/utils.c#L65 .. for some reason all the line after the first ' is colored green .. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 14:48 Message: One year later, does not seem to be something wrong. Maybe, it was related to the parse method in SimpleParse.pm. Consequently, I tag this bug as duplicate, change its category from browsing to lang support and delete it since the parsing bugs will all be corrected at the same time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2955434&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2011-03-12 13:38:34
|
Bugs item #3204285, was opened at 2011-03-09 15:51 Message generated for change (Comment added) 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: Closed Resolution: Works For Me Priority: 2 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) 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 ---------------------- ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 14:38 Message: Incorporated a slightly modified version of the fix: use name of variable 'v' instead of Version to make intent more clear. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 14:38 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- 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-12 13:11:09
|
Bugs item #3204218, was opened at 2011-03-09 15:08 Message generated for change (Comment added) 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: Closed >Resolution: Fixed Priority: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) 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 ---------------------- ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 14:11 Message: Incorporated fix ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 14:11 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- 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-12 13:06:35
|
Bugs item #3204208, was opened at 2011-03-09 15:00 Message generated for change (Comment added) 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) 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 ------------------------------ ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 14:06 Message: Incorporated fix ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 14:06 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- 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-12 12:57:25
|
Bugs item #3204197, was opened at 2011-03-09 14:47 Message generated for change (Comment added) 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) 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 ------------------------- ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 13:57 Message: Fixed simultaneously with 3089456 ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 13:57 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- 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-12 11:22:34
|
Bugs item #3204202, was opened at 2011-03-09 14:52 Message generated for change (Comment added) 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) 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 -------------------------- ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 12:22 Message: Ignore spaces between # and directive when looking up ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 12:22 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- 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-12 11:04:45
|
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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) 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 --------------------- ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 12:04 Message: Chose to send only an HTTP header and no <meta > to avoid a potential conflict. No need then to modify the template html-head.html ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 12:04 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- 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-12 10:24:59
|
Bugs item #3204096, was opened at 2011-03-09 13:14 Message generated for change (Comment added) 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: Closed >Resolution: Fixed Priority: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) 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 ---------- ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 11:24 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- 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-12 10:11:52
|
Bugs item #3204089, was opened at 2011-03-09 13:07 Message generated for change (Comment added) 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) 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 ----------------- ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 11:11 Message: Solved simultaneously with 3204085 ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 11:11 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- 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-12 10:10:35
|
Bugs item #3204085, was opened at 2011-03-09 13:02 Message generated for change (Comment added) 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) 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 ---------------- ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 11:10 Message: Solve simultaneously with 3204089 ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-12 11:10 Message: This has now been fixed in CVS. If you can install the new version and check that it solves your problem, then it would be very useful. Thanks for reporting this defect and helping to make LXR better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3204085&group_id=27350 |
6 messages has been excluded from this view by a project administrator.
