lxr-developer Mailing List for LXR Cross Referencer (Page 3)
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...> - 2012-09-08 09:29:45
|
Bugs item #3561877, was opened at 2012-08-26 08:36 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3561877&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: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Identifier query faulty with CVS tree Initial Comment: With a source-tree under CVS, identifier search may return no result or erroneous results even if the looked-for identifier exists. This happens when the set of versions is defined by a function. This function returns the correct set when LXR is processing a file (under source) but only "head" in all other cases (directory under source, or ident). This is caused by the security check "clean_release" in Common.pm which filters the requested version against those in {'v'}{'range'}. In the mentioned cases, {'range'} is empty and default 'head' is returned. It really matters only for ident since it is always possible to change default version (from directory) once we hit a file. Suggested fix: in clean_release, test if repository is CVS and script is source; if yes, accept any version. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-09-08 02:29 Message: Fixed in 1.0 release. Patch also improved to keep version selection through directory listing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3561877&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-08-26 15:36:04
|
Bugs item #3561877, was opened at 2012-08-26 08:36 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3561877&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: 6 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Identifier query faulty with CVS tree Initial Comment: With a source-tree under CVS, identifier search may return no result or erroneous results even if the looked-for identifier exists. This happens when the set of versions is defined by a function. This function returns the correct set when LXR is processing a file (under source) but only "head" in all other cases (directory under source, or ident). This is caused by the security check "clean_release" in Common.pm which filters the requested version against those in {'v'}{'range'}. In the mentioned cases, {'range'} is empty and default 'head' is returned. It really matters only for ident since it is always possible to change default version (from directory) once we hit a file. Suggested fix: in clean_release, test if repository is CVS and script is source; if yes, accept any version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3561877&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-08-26 12:42:28
|
Feature Requests item #3561850, was opened at 2012-08-26 05:40 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3561850&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: General Group: Next Release >Status: Closed Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Propagate "Show attic files" when browsing CVS Initial Comment: When browsing a source tree stored under CVS, we might want to look at deleted files marked as "In Attic". To display their name in directory listing it is necessary to click on "Show attic files" button. Then, a click on their name should display the decorated file. Instead of that, we get "file does not exist" and we must once again click on "show attic files". Since we intentionally clicked on the attic-file link, it would be nice to avoid this second click. More over, when we are inside an Attic file and we click on an identifier, the definitions and references should also directly jump to an Attic file without the need to get rid of the "file does not exist" warning. Suggested fix: add _showattic=1 in fileref and idref if present in the URL ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-08-26 05:42 Message: Accepted for release 1.0 Only necessary to fix fileref since idref already copies all URL arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3561850&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-08-26 12:40:52
|
Feature Requests item #3561850, was opened at 2012-08-26 05:40 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3561850&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: General Group: Next Release Status: Open Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Propagate "Show attic files" when browsing CVS Initial Comment: When browsing a source tree stored under CVS, we might want to look at deleted files marked as "In Attic". To display their name in directory listing it is necessary to click on "Show attic files" button. Then, a click on their name should display the decorated file. Instead of that, we get "file does not exist" and we must once again click on "show attic files". Since we intentionally clicked on the attic-file link, it would be nice to avoid this second click. More over, when we are inside an Attic file and we click on an identifier, the definitions and references should also directly jump to an Attic file without the need to get rid of the "file does not exist" warning. Suggested fix: add _showattic=1 in fileref and idref if present in the URL ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3561850&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-08-24 13:15:08
|
Bugs item #3561288, was opened at 2012-08-24 06:15 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3561288&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: current cvs Status: Open Resolution: None Priority: 7 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Spurious symbols in usage table with MySQL Initial Comment: When comparing indexation results between MySQL, PostgreSQL and SQLite, MySQL records more symbol usages in table lxr_usages. After diff'ing the tables, it appears the extra usages hit on similar looking symbols (with a different case). MySQL manual says: "By default, string comparisons are not case sensitive and use the current character set." This may be correct for natural languages but definitely wrong for computer science and case-sensitive languages. The easiest way to solve that issue is to change the type of the columns in the table description to BINARY. Thus, we keep method common factoring in the Index class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3561288&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-08-03 18:00:00
|
Feature Requests item #2948299, was opened at 2010-02-08 22:54 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=2948299&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 Interface Group: Next Release >Status: Closed Priority: 1 Private: No Submitted By: Kovich Ian (kovichian) Assigned to: Nobody/Anonymous (nobody) Summary: Mobile UI for LXR Initial Comment: How about design an interface for mobile browsers on Android, WM and Symbian? ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-08-03 10:59 Message: If I translate "mobile" into small size screen, I don't see how I can fit the amount of displayed data on a tight area. It would be user-unfriendly. Feature request dropped unless more detailed specification is given. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=2948299&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-08-03 17:56:43
|
Feature Requests item #2808116, was opened at 2009-06-17 19: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: Closed 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: 2012-08-03 10:56 Message: Ships with release 1.0 ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-04-12 12:48 Message: This incompatibility has been discovered last week (2011-04-05) by Dr. Martin Wilck. A new feature has been added in Perl after version 5.8.8 (which is probably yours). Mine is 5.12.3 and contains this feature. Your choice is: 1/ upgrade Perl, or 2/ read Help forum, topic Help on non-regression checks after modifications; towards the end, you'll find a dirty patch to get around this incompatibility. Please send feedback. If you think it worth, I can try to use alternate syntax since this part of the code is not fully satisfactory. Regards ---------------------------------------------------------------------- Comment By: David (hawaiian717) Date: 2011-04-11 16:43 Message: Just gave 0.9.9 a try; got an error when I tried to update the index: Sequence (?|...) not recognized in regex; marked by <-- HERE in m/^ # reminder: no initial space in the grammar ([\w\#]\s*[\w]*) # reserved keyword for include construct (\s+) # space (?| <-- HERE (")(.+?)(") # C syntax | (\0<)(.+?)(\0>) # C alternate syntax | ()([\w:]+)(\b) # Perl and others ) / at lib/LXR/Lang.pm line 88. Compilation failed in require at lib/LXR/Common.pm line 50. Compilation failed in require at lib/LXR/Index.pm line 23. BEGIN failed--compilation aborted at lib/LXR/Index.pm line 23. Compilation failed in require at /var/www/html/lxr/genxref line 26. BEGIN failed--compilation aborted at /var/www/html/lxr/genxref line 26. ---------------------------------------------------------------------- Comment By: David (hawaiian717) Date: 2011-04-01 18:39 Message: Testing the patch is also on my todo list. Hopefully I'll have a chance to test this next week. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-31 10:30 Message: Reopened manually after automatic close. To be put on "todo" list for a coming release ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2011-03-31 08:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-03-17 07: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 13: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 12: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...> - 2012-08-03 17:56:08
|
Feature Requests item #3452739, was opened at 2011-12-06 12:17 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3452739&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 Priority: 3 Private: No Submitted By: arno. (arno-) Assigned to: Andre-Littoz (ajlittoz) Summary: JavaScript support Initial Comment: Hi, Here is a patch for minimal JavaScript support. My installation index a project containing (among other) many JavaScript files, and I've used this patch for many years. Regards ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-08-03 10:56 Message: Ships with release 1.0 ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-12-06 13:19 Message: Well, it is rather a "feature request" than a bug because there is not yet JavaScript support in LXR. I received a contribution from a user a couple of weeks ago about that same JavaScript support. I'll compare and merge your patches. Time permitting, I'll tru to release a new version before the beginning of next year. Stay tuned. ajl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3452739&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-08-03 17:54:49
|
Feature Requests item #1691378, was opened at 2007-03-30 08:37 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1691378&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: General Group: None >Status: Pending Priority: 5 Private: No Submitted By: Paul D. Smith (psmith) >Assigned to: Andre-Littoz (ajlittoz) Summary: Rearchitect the DB backends Initial Comment: The LXR index DB backends all use DBI, which is perfect, but they don't take enough advantage of it and thus end up duplicating a significant amount of code with all the problems that generally brings. Perl's DBI is ALREADY a generic front-end for SQL databases of all different types, so having separate LXR::Index::* subclasses for each database is largely unnecessary: all databases can use the DBI interface almost exactly the same way. There are minor differences, though, so it's not true that we can get rid of the LXR::Index::* database specific classes entirely. I propose that we make LXR::Index a proper superclass for the DB-specific subclasses, and we push up as much functionality as possible into the superclass. The subclasses should be pretty small: they will deal only with DB-specific issues (for example, auto-incremented fields which work differently in PostgreSQL and MySQL). ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-08-03 10:54 Message: This is partially done in release 1.0. The differences in SQL dialects forces to maintain different LXR::Index::* though some of them are reduced to init (to create the queries) and DESTROY. ---------------------------------------------------------------------- Comment By: AdrianIssott (adrianissott) Date: 2009-04-13 09:39 Message: I'd like to take this on as I'd also noticed a lot of redundancy in the LXR::Index modules. Malcolm can you assign it to me? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1691378&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-08-03 17:39:05
|
Bugs item #3546293, was opened at 2012-07-20 05:04 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3546293&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: 6 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Incorrect start-of-line recognition Initial Comment: Some languages or language constructs are strictly positionned at the start of lines. The identification pattern must then be anchored at the start of the line with ^ (caret). Unhappily, the parser does not pass lines but chunks beginning where the last fragment ended. The caret anchors at the start of the chunk, which is rarely the start of the line. Consequently, anchored syntactic categories will be rarely correctly recognised. A false positive is generated every time the start pattern is detected at the beginning of the chunk. Suggested fix: when initialising the parser, regexps starting with a caret are modified to match an "impossible" character after the caret and that same "impossible" character is preprended to the line when it is read. The extra character can be stripped during line numbering in the HTML generation process. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-08-03 10:39 Message: Fix involves 3 patches: 1 - SimpleParse.pm, sub init: in regexps for start, end, lock and 'atom', an eventual initial ^ is replaced by a test for byte \xFF, 2 - SimpleParse.pm, sub nextfrag: when a new line is read, byte \xFF is added at the start of the line, 3 - Markup.pm, sub htmlquote: any \xFF byte is erased (this sub is always invoked before outputting HTML chunks) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3546293&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-08-03 17:25:32
|
Bugs item #3551992, was opened at 2012-07-30 04:58 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3551992&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: Incorrect search if string contains spaces Initial Comment: Free text search (script search) If the submitted string contains spaces, HTML <FORM> submission algorithm transforms spaces into plus signs (+) gefore inserting it into the query part of the URL. Presently, search uses this string (argument _string) "as is". If, unfortunately, the string contains spaces, it is passed to glimpse with the pluses. The search will frequently results in a failure or at best in incorrect hits. Fix: add $searchtext =~ s/\+/ /g; before launching the searh in sub search. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-08-03 10:25 Message: Fixed as suggested ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3551992&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-07-30 11:58:06
|
Bugs item #3551992, was opened at 2012-07-30 04:58 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3551992&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: Incorrect search if string contains spaces Initial Comment: Free text search (script search) If the submitted string contains spaces, HTML <FORM> submission algorithm transforms spaces into plus signs (+) gefore inserting it into the query part of the URL. Presently, search uses this string (argument _string) "as is". If, unfortunately, the string contains spaces, it is passed to glimpse with the pluses. The search will frequently results in a failure or at best in incorrect hits. Fix: add $searchtext =~ s/\+/ /g; before launching the searh in sub search. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3551992&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-07-22 15:50:14
|
Bugs item #3535240, was opened at 2012-06-14 09:30 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&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: genxref Group: current cvs >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: squall.ho (squallho) Assigned to: Andre-Littoz (ajlittoz) Summary: Typo error when check swish-e Initial Comment: at line 240, the wrong typo of $toolloc = `which swhish-e 2>/dev/null`; an extra "h" will make the $toolloc always be empty, since there is no binary named sw"h"ish-e. should be correct as $toolloc = `which swish-e 2>/dev/null`; ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-07-22 08:50 Message: Typo corrected in CVS Still considering whether to change "which" to "command" or not. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-06-25 07:10 Message: jbglaw, sorry! I misintrepreted 'command -v' for a "template" where command would be replaced by swish-e, glimpse or anything else. It is OK on my system. To your knowledge, is 'which' deprecated? is 'command' guaranteed to be accepted in ANY implementation of Perl? Regards, ajl ---------------------------------------------------------------------- Comment By: Jan-Benedict Glaw (jbglaw) Date: 2012-06-25 06:00 Message: `command -v ....' should basically do what `which' did: jbglaw@pluto:~$ command -v vim /usr/bin/vim Does it behave differently on your system? So I'd just use $toolloc = `command -v swish-e 2>/dev/null`; ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-06-24 02:58 Message: Thanks for pointing out the typo. To jbglaw: Why do you recommend not to use 'which'? I want to get the path to the executable, while 'command -v' will only print identification and version information. But portability-wise, I may be wrong. Instead of comparing path with value of parameter 'xxx-bin', I should blindly use parameter 'xxx-bin' with -v option and see if it returns the correct name for the tool. What is your opinion? ---------------------------------------------------------------------- Comment By: Jan-Benedict Glaw (jbglaw) Date: 2012-06-15 07:08 Message: Please don't use `which' any longer. To my knowledge, `command -v ...' is a portable replacement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-07-20 12:04:09
|
Bugs item #3546293, was opened at 2012-07-20 05:04 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3546293&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: 6 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Incorrect start-of-line recognition Initial Comment: Some languages or language constructs are strictly positionned at the start of lines. The identification pattern must then be anchored at the start of the line with ^ (caret). Unhappily, the parser does not pass lines but chunks beginning where the last fragment ended. The caret anchors at the start of the chunk, which is rarely the start of the line. Consequently, anchored syntactic categories will be rarely correctly recognised. A false positive is generated every time the start pattern is detected at the beginning of the chunk. Suggested fix: when initialising the parser, regexps starting with a caret are modified to match an "impossible" character after the caret and that same "impossible" character is preprended to the line when it is read. The extra character can be stripped during line numbering in the HTML generation process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3546293&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-07-20 11:54:11
|
Bugs item #3546289, was opened at 2012-07-20 04:54 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3546289&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: current cvs Status: Open Resolution: None Priority: 3 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Unable to connect to PostgreSQL database Initial Comment: Under some obscure circumstances (related to PostgreSQL or Linux distro upgrade???), LXR can't connect to PostgreSQL through Unix domain socket. Work around is to connect through TCP socket. To play it safe, parameter 'dbname' in lxr.conf can be modified to include ';host=localhost' after the DB name to force TCP socket. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3546289&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-07-20 11:44:28
|
Bugs item #3535241, was opened at 2012-06-14 09:38 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535241&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: genxref Group: current cvs >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: squall.ho (squallho) >Assigned to: Andre-Littoz (ajlittoz) Summary: Lost a space when open swish-e.conf file Initial Comment: In the line 514 to 519, when execute swish-e with assigned swish-e.conf path by .$config->{'swishconf'} An error of can't open file "swish-e.conf-f" was reported. This is due to a missed "space" before "-f" at next line. The original line 518 . "-f ".$config->swishdir."/".$releaseid.".index" should be . " -f ".$config->swishdir."/".$releaseid.".index" ^^^ a space before -f ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-07-20 04:44 Message: Fixed in CVS as suggested ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535241&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-07-20 11:35:43
|
Bugs item #3535240, was opened at 2012-06-14 09:30 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&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: genxref Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: squall.ho (squallho) >Assigned to: Andre-Littoz (ajlittoz) Summary: Typo error when check swish-e Initial Comment: at line 240, the wrong typo of $toolloc = `which swhish-e 2>/dev/null`; an extra "h" will make the $toolloc always be empty, since there is no binary named sw"h"ish-e. should be correct as $toolloc = `which swish-e 2>/dev/null`; ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-06-25 07:10 Message: jbglaw, sorry! I misintrepreted 'command -v' for a "template" where command would be replaced by swish-e, glimpse or anything else. It is OK on my system. To your knowledge, is 'which' deprecated? is 'command' guaranteed to be accepted in ANY implementation of Perl? Regards, ajl ---------------------------------------------------------------------- Comment By: Jan-Benedict Glaw (jbglaw) Date: 2012-06-25 06:00 Message: `command -v ....' should basically do what `which' did: jbglaw@pluto:~$ command -v vim /usr/bin/vim Does it behave differently on your system? So I'd just use $toolloc = `command -v swish-e 2>/dev/null`; ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-06-24 02:58 Message: Thanks for pointing out the typo. To jbglaw: Why do you recommend not to use 'which'? I want to get the path to the executable, while 'command -v' will only print identification and version information. But portability-wise, I may be wrong. Instead of comparing path with value of parameter 'xxx-bin', I should blindly use parameter 'xxx-bin' with -v option and see if it returns the correct name for the tool. What is your opinion? ---------------------------------------------------------------------- Comment By: Jan-Benedict Glaw (jbglaw) Date: 2012-06-15 07:08 Message: Please don't use `which' any longer. To my knowledge, `command -v ...' is a portable replacement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-06-25 14:10:36
|
Bugs item #3535240, was opened at 2012-06-14 09:30 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&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: genxref Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: squall.ho (squallho) Assigned to: Nobody/Anonymous (nobody) Summary: Typo error when check swish-e Initial Comment: at line 240, the wrong typo of $toolloc = `which swhish-e 2>/dev/null`; an extra "h" will make the $toolloc always be empty, since there is no binary named sw"h"ish-e. should be correct as $toolloc = `which swish-e 2>/dev/null`; ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-06-25 07:10 Message: jbglaw, sorry! I misintrepreted 'command -v' for a "template" where command would be replaced by swish-e, glimpse or anything else. It is OK on my system. To your knowledge, is 'which' deprecated? is 'command' guaranteed to be accepted in ANY implementation of Perl? Regards, ajl ---------------------------------------------------------------------- Comment By: Jan-Benedict Glaw (jbglaw) Date: 2012-06-25 06:00 Message: `command -v ....' should basically do what `which' did: jbglaw@pluto:~$ command -v vim /usr/bin/vim Does it behave differently on your system? So I'd just use $toolloc = `command -v swish-e 2>/dev/null`; ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-06-24 02:58 Message: Thanks for pointing out the typo. To jbglaw: Why do you recommend not to use 'which'? I want to get the path to the executable, while 'command -v' will only print identification and version information. But portability-wise, I may be wrong. Instead of comparing path with value of parameter 'xxx-bin', I should blindly use parameter 'xxx-bin' with -v option and see if it returns the correct name for the tool. What is your opinion? ---------------------------------------------------------------------- Comment By: Jan-Benedict Glaw (jbglaw) Date: 2012-06-15 07:08 Message: Please don't use `which' any longer. To my knowledge, `command -v ...' is a portable replacement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-06-25 13:00:51
|
Bugs item #3535240, was opened at 2012-06-14 09:30 Message generated for change (Comment added) made by jbglaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&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: genxref Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: squall.ho (squallho) Assigned to: Nobody/Anonymous (nobody) Summary: Typo error when check swish-e Initial Comment: at line 240, the wrong typo of $toolloc = `which swhish-e 2>/dev/null`; an extra "h" will make the $toolloc always be empty, since there is no binary named sw"h"ish-e. should be correct as $toolloc = `which swish-e 2>/dev/null`; ---------------------------------------------------------------------- Comment By: Jan-Benedict Glaw (jbglaw) Date: 2012-06-25 06:00 Message: `command -v ....' should basically do what `which' did: jbglaw@pluto:~$ command -v vim /usr/bin/vim Does it behave differently on your system? So I'd just use $toolloc = `command -v swish-e 2>/dev/null`; ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-06-24 02:58 Message: Thanks for pointing out the typo. To jbglaw: Why do you recommend not to use 'which'? I want to get the path to the executable, while 'command -v' will only print identification and version information. But portability-wise, I may be wrong. Instead of comparing path with value of parameter 'xxx-bin', I should blindly use parameter 'xxx-bin' with -v option and see if it returns the correct name for the tool. What is your opinion? ---------------------------------------------------------------------- Comment By: Jan-Benedict Glaw (jbglaw) Date: 2012-06-15 07:08 Message: Please don't use `which' any longer. To my knowledge, `command -v ...' is a portable replacement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-06-24 09:58:29
|
Bugs item #3535240, was opened at 2012-06-14 09:30 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&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: genxref Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: squall.ho (squallho) Assigned to: Nobody/Anonymous (nobody) Summary: Typo error when check swish-e Initial Comment: at line 240, the wrong typo of $toolloc = `which swhish-e 2>/dev/null`; an extra "h" will make the $toolloc always be empty, since there is no binary named sw"h"ish-e. should be correct as $toolloc = `which swish-e 2>/dev/null`; ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-06-24 02:58 Message: Thanks for pointing out the typo. To jbglaw: Why do you recommend not to use 'which'? I want to get the path to the executable, while 'command -v' will only print identification and version information. But portability-wise, I may be wrong. Instead of comparing path with value of parameter 'xxx-bin', I should blindly use parameter 'xxx-bin' with -v option and see if it returns the correct name for the tool. What is your opinion? ---------------------------------------------------------------------- Comment By: Jan-Benedict Glaw (jbglaw) Date: 2012-06-15 07:08 Message: Please don't use `which' any longer. To my knowledge, `command -v ...' is a portable replacement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-06-15 14:08:47
|
Bugs item #3535240, was opened at 2012-06-14 09:30 Message generated for change (Comment added) made by jbglaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&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: genxref Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: squall.ho (squallho) Assigned to: Nobody/Anonymous (nobody) Summary: Typo error when check swish-e Initial Comment: at line 240, the wrong typo of $toolloc = `which swhish-e 2>/dev/null`; an extra "h" will make the $toolloc always be empty, since there is no binary named sw"h"ish-e. should be correct as $toolloc = `which swish-e 2>/dev/null`; ---------------------------------------------------------------------- Comment By: Jan-Benedict Glaw (jbglaw) Date: 2012-06-15 07:08 Message: Please don't use `which' any longer. To my knowledge, `command -v ...' is a portable replacement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-06-14 16:38:50
|
Bugs item #3535241, was opened at 2012-06-14 09:38 Message generated for change (Tracker Item Submitted) made by squallho You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535241&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: genxref Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: squall.ho (squallho) Assigned to: Nobody/Anonymous (nobody) Summary: Lost a space when open swish-e.conf file Initial Comment: In the line 514 to 519, when execute swish-e with assigned swish-e.conf path by .$config->{'swishconf'} An error of can't open file "swish-e.conf-f" was reported. This is due to a missed "space" before "-f" at next line. The original line 518 . "-f ".$config->swishdir."/".$releaseid.".index" should be . " -f ".$config->swishdir."/".$releaseid.".index" ^^^ a space before -f ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535241&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-06-14 16:30:27
|
Bugs item #3535240, was opened at 2012-06-14 09:30 Message generated for change (Tracker Item Submitted) made by squallho You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&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: genxref Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: squall.ho (squallho) Assigned to: Nobody/Anonymous (nobody) Summary: Typo error when check swish-e Initial Comment: at line 240, the wrong typo of $toolloc = `which swhish-e 2>/dev/null`; an extra "h" will make the $toolloc always be empty, since there is no binary named sw"h"ish-e. should be correct as $toolloc = `which swish-e 2>/dev/null`; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3535240&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-22 12:56:18
|
Bugs item #3520299, was opened at 2012-04-22 05:56 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3520299&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: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Incorrect DB purge with --reindexall Initial Comment: Applies to all versions of LXR, probably since 0.9.3 in 2004! Statements delete_releases and delete_files have implicit interrelatioship: a "release" is some alias to a base "revision" file. A base "revision" can thus only be deleted when all "releases" pointing to it have been destroyed. In the present implementation, "releases" are first deleted. Then base "revisions" are scanned: at that time, there is not any more "releases" thus the delete statement for table 'files' can't succeed since it can't compared the files' fileid to releases' (which no longer exist). This leaves the 'files' records in the DB. In the case of the kernel, that amounts to more than 37000 items per version. When reindexing, it is very likely that the new "revision" for the file will be different (it is almost certain with the VCSes, only slightly probable with plain files). This means the orphaned "revisions" will not be reused and new records will be created. DB grows uselessly and performance is impacted. Even without that, the whole process is too slow (same order of magnitude as the indexing itself!) since it involves a selective query with references to several tables. The first issue ('files' table) could be resolved with a reference count. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3520299&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-21 08:34:28
|
Bugs item #1085321, was opened at 2004-12-14 11:08 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1085321&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: v0.9.3 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: George Cross (gccross) Assigned to: AdrianIssott (adrianissott) Summary: updated Oracle.pm and initdb_oracle.sql Initial Comment: I recently installed LXR using an Oracle 8.1.7 database. I had to modify the Oracle.pm and initdb_oracle.sql files to make it work. Here they have been attached. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-21 01:34 Message: Closed because it seems other patches have been applied since then. I blindly trust my predecessors for having checked the patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1085321&group_id=27350 |
6 messages has been excluded from this view by a project administrator.
