lxr-developer Mailing List for LXR Cross Referencer (Page 4)
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-04-21 08:25:45
|
Bugs item #3520039, was opened at 2012-04-21 01:10 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3520039&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: SCM support Group: current cvs >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: With CVS, only 'head' release displayed Initial Comment: CVS release 1.95 for Common.pm tried to sort global variable initialisation by moving $pathname after varaible 'v' being set to the value of $releaseid. Unhappily there is an egg-and-hen problem since $releaseid is set by sub clean_release which references {'variables'}{'v'}{'range'}. It is usually OK but it may be a sub (as in the CVS example in lxr.conf) to compute the range with a call to the SCM class object with argument $pathname to hold the file name. Since it is undefined at that time, CVS object returns 'head' by default. Afterwards, it is impossible to change version. GIT uses a different scheme (reading the stored list of releases from a file) and is not affected by this race condition. Plain files usually explicitly enumerates the versions and are also not affected. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-21 01:25 Message: There is practically no perfect way to break this vicious circle. Since clean-release only aims at "canonise" $pathname by ensuring a trailing slash if it is a directory, it seems acceptable to set $pathname to the URL path temporarily (i.e. only for the purpose of computing the versions set of the current file) which means subs allreleases and allrevisions must not rely on $pathname having the / suffix if it is a directory. Thus the critical section now reads: $pathname = $HTTP->{'path_info'}; # <- added line $releaseid = clean_release($config->variable('v')); $config->variable('v', $releaseid); $pathname = fixpaths($HTTP->{'path_info'}); For efficiency, the second $pathname = could even be written: $pathname = fixpaths($pathname); and it gives a visual clue that it is not an accidental duplication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3520039&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-21 08:12:22
|
Bugs item #3519397, was opened at 2012-04-18 23:59 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3519397&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: 7 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Apache not accessing LXR root directory Initial Comment: LXR 0.11 Under some Linux distributions, Apache does not interpret the Alias directive given in apache-lxrserver.conf and defaults to input in /var/www/ This is caused by a confusion on syntax between Alias and AliasMatch directives. Alias should not contain regexp meta-characters: a ^ (start anchor) has been written before /lxr. Some distros are more permissive than others, ignoring the caret while others do not match the character against the URL. Suggested fix: remove caret. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-21 01:12 Message: Caret removed in template file apache-lxrserver.conf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3519397&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-21 08:10:47
|
Bugs item #3520039, was opened at 2012-04-21 01:10 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3520039&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: SCM support Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: With CVS, only 'head' release displayed Initial Comment: CVS release 1.95 for Common.pm tried to sort global variable initialisation by moving $pathname after varaible 'v' being set to the value of $releaseid. Unhappily there is an egg-and-hen problem since $releaseid is set by sub clean_release which references {'variables'}{'v'}{'range'}. It is usually OK but it may be a sub (as in the CVS example in lxr.conf) to compute the range with a call to the SCM class object with argument $pathname to hold the file name. Since it is undefined at that time, CVS object returns 'head' by default. Afterwards, it is impossible to change version. GIT uses a different scheme (reading the stored list of releases from a file) and is not affected by this race condition. Plain files usually explicitly enumerates the versions and are also not affected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3520039&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-19 06:59:10
|
Bugs item #3519397, was opened at 2012-04-18 23:59 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3519397&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: 7 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Apache not accessing LXR root directory Initial Comment: LXR 0.11 Under some Linux distributions, Apache does not interpret the Alias directive given in apache-lxrserver.conf and defaults to input in /var/www/ This is caused by a confusion on syntax between Alias and AliasMatch directives. Alias should not contain regexp meta-characters: a ^ (start anchor) has been written before /lxr. Some distros are more permissive than others, ignoring the caret while others do not match the character against the URL. Suggested fix: remove caret. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3519397&group_id=27350 |
|
From: bfffffff8 c. <bff...@ya...> - 2012-04-18 02:38:29
|
Hi there!
I've been torturing myself away for the past two days trying to get LXR working on my Debian 6 and CentOS 6.2.
I've been going through all the code, doing this and doing that and, well, pretty much pulling my hair out :p
I do apologize greatly if any of these problems have already been discussed elsewhere, I have been searching
through the lists but have come up empty.
I seem to have hit a dead end and thus I seek your help. My configurations are such:
Server #1- Debian 6.0.2
- Apache 2.2.16 (Prefork)
- perl 5.10.1-17squeeze3
- lxr version 0.11.1
- installed to /opt/lxr
Server #2 - CentOS 6.2 (SELinux permissive)
- Apache 2.2.15 (Prefork)
- perl 5.10.1
- lxr version 0.11
- installed to /opt/lxr
LXR on my CentOS seems pretty stable at the moment, though I had to make many changes to get it working.
Firstly, there are issues with the apache configuration, permissions issues. I refer to apache-lxrserver.conf
where the "Alias ^/lxr /opt/lxr" is found. The first issue for both Servers was that this Alias wasn't
working - at all. I noticed after stracing apache that it kept trying to open files in /var/www/html/lxr (for centos)
and /var/www/lxr (for debian). The problem seems to be that the Alias directive is tabbed in the configuration
file...but that didn't fix it completely either. I had to remove the '^' regex for the alias mapping to work.
I haven't used apache in a long time so I'm not really sure why it isn't working.
Another problem was the missing lxrconf.d directory, though minor. After fixing that, and fixing the
templates/ chmod problem I was still left with templates/html/*.html not being able open() - apache would
always get EACCES - on CentOS AND Debian. I checked all the SELinux policies and they were fine.
I fixed this problem by cp'ing everything from templates/html (and changing the lxr.conf to point to root lxr dir)
(including the lxr.css file which also wouldn't open)to the root lxr directory - /opt/lxr - that finally fixed that problem.
But on Server #1 (Debian) this problemgot even worse because I found myself having to copy ALL the perl libraries
from /opt/lxr/lib/* tothe root directory...and a whole other copying around...I can't even recall now since it's an entire mess.
There was also the problem of ExecCGI on the Debian server - the scripts (source/search/etc) just
wouldn't execute...I kept getting:
[error] Options ExecCGI is off in this directory/opt/lxr/source
I managed to fix this by modifying the .htaccess file to say Options +ExecCGI (adding the + operand).
This wasn't necessary on the CentOS server...
The current problem for the Debian server is that some files just don't show up.
The LXR HTML Header shows up but no source code. What complicates
this problem much more is that the same file will open on some browsers and not on others. An strace of
apache during the time when a browser sends a request for a file which doesn't display source code is such:
[pid 3970] open("/opt/indexed-src/v3.2.1/servers/ext2/open.c", O_RDONLY) = 14
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/fs.h", {st_mode=S_IFREG|0644, st_size=872, ...}) = 0
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/sys/stat.h", 0x2b716a75fd90) = -1 ENOENT (No such file or directory)
[pid 3970] stat("/opt/indexed-src/v3.2.1/include/sys/stat.h", {st_mode=S_IFREG|0644, st_size=6987, ...}) = 0
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/sys", 0x2b716a75fd90) = -1 ENOENT (No such file or directory)
[pid 3970] stat("/opt/indexed-src/v3.2.1/include/sys", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/string.h", 0x2b716a75fd90) = -1 ENOENT (No such file or directory)
[pid 3970] stat("/opt/indexed-src/v3.2.1/include/string.h", {st_mode=S_IFREG|0644, st_size=4452, ...}) = 0
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/minix/com.h", 0x2b716a75fd90) = -1 ENOENT (No such file or directory)
[pid 3970] stat("/opt/indexed-src/v3.2.1/include/minix/com.h", {st_mode=S_IFREG|0644, st_size=51895, ...}) = 0
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/minix", 0x2b716a75fd90) = -1 ENOENT (No such file or directory)
[pid 3970] stat("/opt/indexed-src/v3.2.1/include/minix", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/buf.h", {st_mode=S_IFREG|0644, st_size=2237, ...}) = 0
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/inode.h", {st_mode=S_IFREG|0644, st_size=4779, ...}) = 0
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/super.h", {st_mode=S_IFREG|0644, st_size=6191, ...}) = 0
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/minix/vfsif.h", 0x2b716a75fd90) = -1 ENOENT (No such file or directory)
[pid 3970] stat("/opt/indexed-src/v3.2.1/include/minix/vfsif.h", {st_mode=S_IFREG|0644, st_size=4142, ...}) = 0
[pid 3970] stat("/opt/indexed-src/v3.2.1/servers/ext2/minix", 0x2b716a75fd90) = -1 ENOENT (No such file or directory)
[pid 3970] stat("/opt/indexed-src/v3.2.1/include/minix", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 3970] --- SIGPIPE (Broken pipe) @ 0 (0) ---
It happens every time - the SIGPIPE...I suspect this causes the problem but I am not sure yet where it is coming from.
There were/are more problems that I have run into but I am unable to recall them all at present! Oh! There seems to be a problem
with the lighthttpd configuration. This is lighttpd v1.4.28 on the Debian server - when I run the lighttpd -t -f lxrconf.d/lighttp-lxrserver.conf
command I get the following:
2012-04-18 06:30:00: (configfile.c.964) opening configfile /etc/lighttpd/conf.d/ssi.conf failed: No such file or directory
2012-04-18 06:30:00: (configfile.c.918) source: /opt/lxr/templates/lighttpd/lighttpd-lxr-modules.conf line: 137 pos: 8 parser failed somehow near here: (EOL)
2012-04-18 06:30:00: (configfile.c.918) source: lxrconf.d/lighttp-lxrserver.conf line: 111 pos: 16 parser failed somehow near here: (EOL)
- However when I run the same command on my CentOS server I get Syntax OK! Strange...I think when I've figured out all these issues I'd like
to try and set this thing up on Nginx...Anyway any potential insight will be very much appreciated! Sorry for the long post! Thanks! |
|
From: SourceForge.net <no...@so...> - 2012-04-14 08:03:50
|
Bugs item #3517685, was opened at 2012-04-14 00:50 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3517685&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: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Glipse search denied in some Linux distributions Initial Comment: Depending on the Linux distribution, glimpse invocation (in 0.11 and beta 0.12) may fail with error message: /usr/bin/glimpse: unmatched '[', ']' (use \[, \] to search for [, ]) This is known to happen under Gentoo (reported by conquistdor in the Help forum), but not under Fedora. The cause is in the file filter that exclude file whose name end in ,v (CVS database) and ~ (editor backup). The filter is coded as a complex "positive" pattern defining all accepted filenames (that's the logical negation of the exclusion). The filter is passed to glimpse with -F option. Glimpse seems to have trouble to process the union of two negations followed by the "end of string" anchor $ under some distributions. -F may be used to pass more directives than just a pattern to agrep: the -F argument may contain a full set of agrep options and arguments. Since agrep has an "exclude" option, the complex negated pattern may be replaced by a much simpler exclusion pattern preceded by the -v agrep option. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-14 01:03 Message: In sub glimpsesearch, the following option to glimpse -F (\\,[^v\\~]|[^\\,][^\\~])\$ is changed to -F '-v (\\,v\|\\~)\$' This simpler pattern seems better accepted across distributions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3517685&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-14 07:50:38
|
Bugs item #3517685, was opened at 2012-04-14 00:50 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3517685&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: 6 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Glipse search denied in some Linux distributions Initial Comment: Depending on the Linux distribution, glimpse invocation (in 0.11 and beta 0.12) may fail with error message: /usr/bin/glimpse: unmatched '[', ']' (use \[, \] to search for [, ]) This is known to happen under Gentoo (reported by conquistdor in the Help forum), but not under Fedora. The cause is in the file filter that exclude file whose name end in ,v (CVS database) and ~ (editor backup). The filter is coded as a complex "positive" pattern defining all accepted filenames (that's the logical negation of the exclusion). The filter is passed to glimpse with -F option. Glimpse seems to have trouble to process the union of two negations followed by the "end of string" anchor $ under some distributions. -F may be used to pass more directives than just a pattern to agrep: the -F argument may contain a full set of agrep options and arguments. Since agrep has an "exclude" option, the complex negated pattern may be replaced by a much simpler exclusion pattern preceded by the -v agrep option. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3517685&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-07 11:05:00
|
Bugs item #2714744, was opened at 2009-03-26 08:43 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2714744&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: 3 Private: No Submitted By: Malcolm Box (mbox) Assigned to: Andre-Littoz (ajlittoz) Summary: Tagger & Plain.pm inefficient Initial Comment: Tagger.pm uses Files::tmpfile to get a file for indexing. In the plain file case, this is created by copying the existing file into a temporary file. After indexing the temporary file is then deleted. Should fix the interface from Tagger.pm to Files.pm to simply get a read-only reference to the file, and close it when no longer needed. Leave it up to Files.pm to worry about where/how it's on the disk. Alternatively on Unix systems Plain.pm could just create a hardlink and give that back to Tagger.pm, but this isn't portable. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-07 04:05 Message: Accurate time for 3.1 kernel is 5 hours 46 minutes 56 seconds. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-06 10:29 Message: Made extensive tests and I'm a bit disappointed. The overall time-improvement seems to be 10-15% only. It means either the Linux caching mechanism is very very efficient or other factors dominate indexation time. One of these could be --reindexall processing. On a moderately sized test (8 LXR releases), genxref takes 70 seconds (high-end computer, 4GB memory, 3,4GHz, fast SATA) for a first indexation (empty database) and 88 seconds with --reindexall. In both cases, fluctuation on run time is about +-1 second. For Linux kernel 3.1 (more than 31,000 files), genxref takes 3 hours 53 minutes 58 seconds (single run, no deviation computed) with a fresh database while --reindexall gives 5 hours 30 minutes!!! Unless you want to keep cross-references on other versions, it is much better to erase the database first then to use --reindexall. Another examination shows that ctags step is quite fast (ctags is compiled, not interpreted) while the references step is slow. Most of the time is spent in SimpleParse.pm's nextfrag subroutine. A real improvement would result from using a compiled parser and probably all the more if it is a real finite state automaton parser instead of the surrogate regexp-based Perl-interpreted parser. Also what happens during glimpseindex step is not clear: A line "This is glimpseindex version ..." is printed, then nothing more during a very long time (kernel case) as if glimpseindex was frozen (but it is not). This needs some explanation or caveat from glimpse team. What also puzzles me: I made tests on my old low-end laptop (512 MB memory, 650 MHz, standard PATA) with the LXR sample. The results do not reflect the clock ratio between the machines. I should have a penalty with the slow PC (less memory to hold the caches) while it behaves better: 3 minutes 58 seconds average against 1 minute 12 seconds (same sample). Ratio is 3.3 for clock ratio 5.23. All times used were 'real' results from time. I have not done the comparisons on 'user' and 'sys'. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-03-29 12:06 Message: Files.pm interface changed as follows: - method tmpfile renames to realfilename to return a filename containing text requested as file and version - new method releaserealfilename to tell when the real filename is no longer needed. Plain.pm: - realfilename returns the OS absolute path to the requested file version - releaserealfilename does nothing CVS.pm, BK.pm (this one on a guess, result not tested) - realfilename makes a temp copy of the requested file version and returns the OS absolute path of the temp file -releaserealfilename deletes the temps file Git.pm: no fix because Git support is broken in CPAN library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2714744&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-06 17:29:29
|
Bugs item #2714744, was opened at 2009-03-26 08:43 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2714744&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: 3 Private: No Submitted By: Malcolm Box (mbox) Assigned to: Andre-Littoz (ajlittoz) Summary: Tagger & Plain.pm inefficient Initial Comment: Tagger.pm uses Files::tmpfile to get a file for indexing. In the plain file case, this is created by copying the existing file into a temporary file. After indexing the temporary file is then deleted. Should fix the interface from Tagger.pm to Files.pm to simply get a read-only reference to the file, and close it when no longer needed. Leave it up to Files.pm to worry about where/how it's on the disk. Alternatively on Unix systems Plain.pm could just create a hardlink and give that back to Tagger.pm, but this isn't portable. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-06 10:29 Message: Made extensive tests and I'm a bit disappointed. The overall time-improvement seems to be 10-15% only. It means either the Linux caching mechanism is very very efficient or other factors dominate indexation time. One of these could be --reindexall processing. On a moderately sized test (8 LXR releases), genxref takes 70 seconds (high-end computer, 4GB memory, 3,4GHz, fast SATA) for a first indexation (empty database) and 88 seconds with --reindexall. In both cases, fluctuation on run time is about +-1 second. For Linux kernel 3.1 (more than 31,000 files), genxref takes 3 hours 53 minutes 58 seconds (single run, no deviation computed) with a fresh database while --reindexall gives 5 hours 30 minutes!!! Unless you want to keep cross-references on other versions, it is much better to erase the database first then to use --reindexall. Another examination shows that ctags step is quite fast (ctags is compiled, not interpreted) while the references step is slow. Most of the time is spent in SimpleParse.pm's nextfrag subroutine. A real improvement would result from using a compiled parser and probably all the more if it is a real finite state automaton parser instead of the surrogate regexp-based Perl-interpreted parser. Also what happens during glimpseindex step is not clear: A line "This is glimpseindex version ..." is printed, then nothing more during a very long time (kernel case) as if glimpseindex was frozen (but it is not). This needs some explanation or caveat from glimpse team. What also puzzles me: I made tests on my old low-end laptop (512 MB memory, 650 MHz, standard PATA) with the LXR sample. The results do not reflect the clock ratio between the machines. I should have a penalty with the slow PC (less memory to hold the caches) while it behaves better: 3 minutes 58 seconds average against 1 minute 12 seconds (same sample). Ratio is 3.3 for clock ratio 5.23. All times used were 'real' results from time. I have not done the comparisons on 'user' and 'sys'. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-03-29 12:06 Message: Files.pm interface changed as follows: - method tmpfile renames to realfilename to return a filename containing text requested as file and version - new method releaserealfilename to tell when the real filename is no longer needed. Plain.pm: - realfilename returns the OS absolute path to the requested file version - releaserealfilename does nothing CVS.pm, BK.pm (this one on a guess, result not tested) - realfilename makes a temp copy of the requested file version and returns the OS absolute path of the temp file -releaserealfilename deletes the temps file Git.pm: no fix because Git support is broken in CPAN library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2714744&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-03 16:31:02
|
Feature Requests item #3512017, was opened at 2012-03-27 10:11 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3512017&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: 6 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Automatic release numbering Initial Comment: When preparing a release, it all too easy to forget to bump the $lxrversion in file $LXRversion.pm. It would be nice it script makerelease.pl could do the job since it knows the exact release number it is working on. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-03 09:31 Message: Included in CVS, will be publicly available in 0.12 release ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3512017&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-03 16:29:32
|
Feature Requests item #741648, was opened at 2003-05-22 04:16 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=741648&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: None >Status: Deleted Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: More info from dentifier search display. Initial Comment: The identifier search such as: http://sourcenav/lxr/ident?v=<version>?i=<ident> does not return enough information compared with the freetext search. It would be perfect if each indentifier in the list displayed the content of the line as well, just like the freetext search. Thanks ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-03 09:29 Message: Feature request deleted as per the remark. ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2011-04-02 09:08 Message: Free text search operates on text. Thus when a match is found, the line of occurrence is for free. Ident looks only through its indexed data base where only the "coordinates" of occurrences are recorded (file, release, line number, type). Accessing the line would considerably impact performance. Would this penalty be generally accepted? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=741648&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-03 16:28:09
|
Feature Requests item #481579, was opened at 2001-11-13 21:00 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=481579&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: Deleted Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: generate static pages Initial Comment: Hi: Although I'm still battling to make it work, it's a great project. I just have a simple wish: - Give lxr an option to generate static pages for a piece of code. Take my case: I frequently have to study some pieces of code. lxr can speed up a lot my work, but I don't have access to a web server. What I would like to do (and generally do with html manuals) is to burn a cd with the code cross referenced, and be able to browse it at leisure. I already tried to do that with a wget -r of a branch of the linux kernel, but it didn't work. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-03 09:28 Message: Feature request closed since it looks to me as diverging considerably from LXR principles. Anyway, if you want to navigate locally on a source tree, it is simple to install LXR and the source tree on one's computer. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-16 10:56 Message: Logged In: NO take a look at httrack. it's much better than wget for spidering web sites. there are times where wget gets confused but httrack doesn't. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-12-23 21:18 Message: Logged In: NO I think you will find GLOBAL useful. GLOBAL is a tags system without www interface. It also can generate static HTML. Follow this link: www.tamacom.com/global ---------------------------------------------------------------------- Comment By: Malcolm Box (mbox) Date: 2001-11-28 05:35 Message: Logged In: YES user_id=215386 What was it specifically that didn't work for you? The problem might be that in addition to each file of source (the output of the source program) you also need the ident output for each of the symbols used. Which might be several thousand. If the symbols then are referenced in file outside the tree you're interested in then the spider could get confused. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=481579&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-03 16:10:33
|
Bugs item #998386, was opened at 2004-07-26 17:35 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=998386&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: Out of Date Priority: 5 Private: No Submitted By: Malcolm Box (mbox) Assigned to: Dave Brondsema (brondsem) Summary: Freetext index rebuilt unnecessarily Initial Comment: The new freetext indexing first algorithm doesn't check if the file was already indexed before re-freetext indexing it. The result is that on an unchanged tree a large amount of unnecessary indexing takes place. The code should check whether the file has been modified or not been indexed and if so, only then index it. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-03 09:10 Message: IMHO it looks like Tagger.pm icludes such a feature => closing that bug ajlittoz ---------------------------------------------------------------------- Comment By: Dave Brondsema (brondsem) Date: 2004-07-27 13:45 Message: Logged In: YES user_id=341298 I'm not understanding. Did it do this before? I don't see how. Isn't that the freetext indexer's responsibility? Or did genxref do it somehow? ---------------------------------------------------------------------- Comment By: Malcolm Box (mbox) Date: 2004-07-27 00:53 Message: Logged In: YES user_id=215386 This is using swish-e - haven't tested glimpse, but don't see any logic that would prevent it. ---------------------------------------------------------------------- Comment By: Dave Brondsema (brondsem) Date: 2004-07-26 17:56 Message: Logged In: YES user_id=341298 With glimpse or swish-e? Or both? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=998386&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-02 19:04:51
|
Bugs item #3514226, was opened at 2012-04-02 11:31 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3514226&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: current cvs >Status: Closed Resolution: Fixed Priority: 8 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Access denied to templates directory Initial Comment: Script initial-config.sh leaves templates directory with permissions r--r--r-- instead of r-xr-xr-x. No further acces is possible. Fix: change chmod command to chmod a=rx templates/ ---------------------------------------------------------------------- Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-02 12:04 Message: Fixed Files copied to lxrconf.d are also chmod'ed to rwxr-xr-x to be sure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3514226&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-02 19:04:05
|
Bugs item #3514226, was opened at 2012-04-02 11:31 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3514226&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: current cvs Status: Open >Resolution: Fixed Priority: 8 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Access denied to templates directory Initial Comment: Script initial-config.sh leaves templates directory with permissions r--r--r-- instead of r-xr-xr-x. No further acces is possible. Fix: change chmod command to chmod a=rx templates/ ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-04-02 12:04 Message: Fixed Files copied to lxrconf.d are also chmod'ed to rwxr-xr-x to be sure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3514226&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-04-02 18:31:53
|
Bugs item #3514226, was opened at 2012-04-02 11:31 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3514226&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: current cvs Status: Open Resolution: None Priority: 8 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Access denied to templates directory Initial Comment: Script initial-config.sh leaves templates directory with permissions r--r--r-- instead of r-xr-xr-x. No further acces is possible. Fix: change chmod command to chmod a=rx templates/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3514226&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-03-29 19:06:14
|
Bugs item #2714744, was opened at 2009-03-26 08:43 Message generated for change (Settings changed) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2714744&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: 3 Private: No Submitted By: Malcolm Box (mbox) >Assigned to: Andre-Littoz (ajlittoz) Summary: Tagger & Plain.pm inefficient Initial Comment: Tagger.pm uses Files::tmpfile to get a file for indexing. In the plain file case, this is created by copying the existing file into a temporary file. After indexing the temporary file is then deleted. Should fix the interface from Tagger.pm to Files.pm to simply get a read-only reference to the file, and close it when no longer needed. Leave it up to Files.pm to worry about where/how it's on the disk. Alternatively on Unix systems Plain.pm could just create a hardlink and give that back to Tagger.pm, but this isn't portable. ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-03-29 12:06 Message: Files.pm interface changed as follows: - method tmpfile renames to realfilename to return a filename containing text requested as file and version - new method releaserealfilename to tell when the real filename is no longer needed. Plain.pm: - realfilename returns the OS absolute path to the requested file version - releaserealfilename does nothing CVS.pm, BK.pm (this one on a guess, result not tested) - realfilename makes a temp copy of the requested file version and returns the OS absolute path of the temp file -releaserealfilename deletes the temps file Git.pm: no fix because Git support is broken in CPAN library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2714744&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-03-27 17:11:40
|
Feature Requests item #3512017, was opened at 2012-03-27 10:11 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3512017&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 Priority: 6 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Automatic release numbering Initial Comment: When preparing a release, it all too easy to forget to bump the $lxrversion in file $LXRversion.pm. It would be nice it script makerelease.pl could do the job since it knows the exact release number it is working on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3512017&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-03-27 17:01:53
|
Bugs item #3510741, was opened at 2012-03-24 01:07 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3510741&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: 7 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: diff in 'many variables' context: incorrect versions Initial Comment: If a diff markup is requested in a context where many variables can be selected (e.g. kernel browsing with architectures and sub-architectures enabled), the "version" selection step does not hand over the correct variable name/value to diff. The final name/value retained may well be totally irrevelant to the architecture under scrutiny. As a side-improvement, use the 'when' attributes to limit the number of proposed choices (in the message, since only the "active" variables are displayed in the header). ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-03-27 10:01 Message: Fix to this bug involved a redesign of the way the request is submitted to diff. Formely, two argument variables were used: _diffvar contained the name of the variable to compare to and _diffval the value. To be able to handle an indefinite number of variables, the full reference set of values is passed as argument ~xx=value where xx is the name of the variable. The target set is defined through xx=value (link insterface which can provide only one variable) or !xx=value (buttons-and-menus interface where any number of variables can be clicked). As a side-effect, argument variables _file and _dir are no longer used since the reference set ~xx and new sub unmappath allow to reverse the effects of 'maps' before reapplying the rules with the new set xx and/or !xx. The new cleaner design removed the need for $incargs{} marker in the templates since everything needed is already in urlargs{}. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3510741&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-03-27 16:51:51
|
Bugs item #3510739, was opened at 2012-03-24 01:00 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3510739&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: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Include path remapping randomly fails Initial Comment: Navigating through the kernel source with architecture and sub-architectures requires that 'maps' rules are applied in a definite order since they are cumulative. Remapping rules are stored in Perl hash. Application is requested by a "for each (%maps)" instruction which pulls the rule in random order ("to protect against attacks", Perldoc says). The consequence is the order of the rules is not preserved, thus some dependent rules may be applied before the master rule and they will fail. However, it may work correctly sometimes which hides the bug. Anyway, this is not satisfactory. Suggestion: change rules storage from hash to array to control the application order. Is there an impact on performance? ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-03-27 09:51 Message: 'maps' parameter changed from hash to array. This change involved a minor modification in sub mappath. A new sub unmappath has been created to "reverse" (when this is possible) the effects of mappath. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3510739&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-03-27 08:20:02
|
Bugs item #3511790, was opened at 2012-03-26 23:53 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3511790&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: 7 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: treeextract renaming incomplete (Template.pm) Initial Comment: When changing treeextract to targetextract, an occurrence was left out in sub captionexpand. This bug does not show if 'caption' parameter exists since its value is used. Otherwise, a sensible value is computed from URL through sub targetextract (or supposed to since the name was not changed here). ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-03-27 01:20 Message: Created a branch fix-0-11-0 in CVS and fixed sub name. Fix also applied in main trunk. Version 0.11.1 released. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3511790&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-03-27 06:53:38
|
Bugs item #3511790, was opened at 2012-03-26 23:53 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3511790&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: 7 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: treeextract renaming incomplete (Template.pm) Initial Comment: When changing treeextract to targetextract, an occurrence was left out in sub captionexpand. This bug does not show if 'caption' parameter exists since its value is used. Otherwise, a sensible value is computed from URL through sub targetextract (or supposed to since the name was not changed here). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3511790&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-03-24 08:15:51
|
Feature Requests item #3495902, was opened at 2012-02-29 23:57 Message generated for change (Comment added) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3495902&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: Add "context" variables Initial Comment: The Linux kernel runs on many different architectures. The specific parts are located in subdirectories of /arch. This is easily handled with the 'a' (architecture) variable and one 'incprefix' and one 'maps' directives. However some architectures have variants with specific code in other subdirectories. These could also be handled by other variables, but this gives many, many buttons or link lines in the page header (leading to visual confusion and bad legibility). Since these variables are meaningful only in the context of their associated 'a' value, it is much better to display them only if the 'a' variable has the appropriate value. This could be done by defining a new attribute in 'variables' as 'when' => 'string containing a conditional expr' e.g. { 'arm_mach' => { 'name' => 'Arm machine' , 'when' => '"$a" eq "arm" , 'range' => [qw(at91 bcmring ... )] } } The 'when' attribute is evaluated when there is need to display variables list. Should it also be evaluated when variable value is substituted? Are there circumstances that require to drop meaningless variables? ---------------------------------------------------------------------- >Comment By: Andre-Littoz (ajlittoz) Date: 2012-03-24 01:15 Message: This feature has been implemented in CVS, will be available in 0.12 release. To facilitate its use, a new script will be added to collect relevant information for kernel tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=3495902&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-03-24 08:07:08
|
Bugs item #3510741, was opened at 2012-03-24 01:07 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3510741&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: 7 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: diff in 'many variables' context: incorrect versions Initial Comment: If a diff markup is requested in a context where many variables can be selected (e.g. kernel browsing with architectures and sub-architectures enabled), the "version" selection step does not hand over the correct variable name/value to diff. The final name/value retained may well be totally irrevelant to the architecture under scrutiny. As a side-improvement, use the 'when' attributes to limit the number of proposed choices (in the message, since only the "active" variables are displayed in the header). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3510741&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2012-03-24 08:00:17
|
Bugs item #3510739, was opened at 2012-03-24 01:00 Message generated for change (Tracker Item Submitted) made by ajlittoz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3510739&group_id=27350 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Browsing Group: current cvs Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andre-Littoz (ajlittoz) Assigned to: Andre-Littoz (ajlittoz) Summary: Include path remapping randomly fails Initial Comment: Navigating through the kernel source with architecture and sub-architectures requires that 'maps' rules are applied in a definite order since they are cumulative. Remapping rules are stored in Perl hash. Application is requested by a "for each (%maps)" instruction which pulls the rule in random order ("to protect against attacks", Perldoc says). The consequence is the order of the rules is not preserved, thus some dependent rules may be applied before the master rule and they will fail. However, it may work correctly sometimes which hides the bug. Anyway, this is not satisfactory. Suggestion: change rules storage from hash to array to control the application order. Is there an impact on performance? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=3510739&group_id=27350 |
6 messages has been excluded from this view by a project administrator.
