lxr-developer — Don't use, active developers only

[Lxr-dev] Running the LXR Tests

[Adrian I. <adr...@ho...>]

Hi All,

I've just attempted to run the LXR tests as described in lxr/tests/README and when I do so I get the following error on my Windows XP laptop using ActiveState Perl v5.8.8:

Insecure dependency in eval while running with -T switch at C:/Perl/site/lib/Test/Unit/Loader.pm line 46.

This equates to the following code:

sub compile_class {
    my $classname = shift;
    debug("  Test::Unit::Loader::compile_class($classname) called\n");
    # Check if the package exists already.
    {
        no strict 'refs';
        if (my @keys = grep { ! /::$/ } keys %{"$classname\::"}) {
            debug("    package $classname already exists (@keys); not compiling.\n");
            return;
        }
    }
    # No? Try 'require'ing it
>    eval "require $classname";
    die $@ if $@;
    debug("    $classname compiled OK as class name\n");
}

Which, if I understand the taint switch correctly, is indeed an error since in taint mode Perl inherently distrusts any data that it receives from outside the program's source. When I remove the use of the taint switch the tests all run and pass.

That's all well and good except I'm left wondering how anyone else manages to successfully run the tests with the code as it is in the CVS repository. Anyone know if this is a windows specific thing?

What I'd like to do is remove the taint switch since it's just test code and there's no security risk. Any objections?

Cheers,
Adrian

_________________________________________________________________
Beyond Hotmail — see what else you can do with Windows Live.
http://clk.atdmt.com/UKM/go/134665375/direct/01/

[Lxr-dev] [ lxr-Feature Requests-1691362 ] Add caching of annotated files to speed up access

[SourceForge.net <no...@so...>]

Feature Requests item #1691362, was opened at 2007-03-30 16:18
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1691362&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: Open
Priority: 5
Private: No
Submitted By: Paul D. Smith (psmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add caching of annotated files to speed up access

Initial Comment:
Currently all pages displayed by LXR are dynamically generated.  However, most of the content displayed is relatively static.  I propose that LXR create a cache of annotated files to speed up browsing.  Here are some specifics:

1) We already have a fileid, so the cache should be organized by fileid with an appropriate directory fan-out.  Since the fileid format is specific to the file backend, this might be a bit tricky--one possibility is to let the file backend do the fan-out with a special method.  At any rate, this ensures that all releases that use the same file version share the cache, while releases with the same file but different versions have different cached contents.

2) Only the actual annotated file should be cached: we should not cache the entire page (header/footer/etc.)  So, we don't have a completely static page, but close: we just have to generate the header/footer etc., and insert the contents of the cached file at the appropriate place.  This allows us to avoid the cache even when the list of releases/architectures/etc. changes.

3) If the fileid is truly unique (which I believe it has to be for LXR to work properly) then we don't really need to worry about a stale cache: it can never be stale because a different file will have a different fileid.  If, for some reason, that's not sufficient it's trivial enough to detect stale data using creation time on the cached file.

4) Cleaning the cache is a trickier problem.  There are a number of options here.  For simple disk space reclamation we can, for example, examine the time last accessed and clean up the cached files older than a certain date.  A cleanup script could be run daily or weekly, with various options such as a maximum cache size, or a fixed "clean anything older than X days".  An alternative to using access time (which can be problematic since backups can modify it, or maybe your filesystem is mounted noatime for efficiency reasons) is to use time last modified, and have LXR touch the file to update the modification time every time it gets the file from the cache.

Another option is to simply not clean the cache, since we don't clean out the database normally.  We should add in some code to clean the cache when we DO clean out the DB: there are options to genxref to remove releases etc.

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2009-04-08 11:20

Message:
Yep - I've just tested this and Squid successfully caches LXR output.  I
set it up as an explicit HTTP proxy (ie configured in the browser), but I'm
sure it could be configured transparently for a site's users.

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2009-04-08 10:44

Message:
It should work fine - caching behaviour is controlled by Cache-* headers in
the HTTP response, and looking at the headers that LXR spits out it rightly
does nothing to prevent caching.

I've not tried it but I see no reason why it wouldn't work.  For bonus
points LXR should probably provide better caching control in the headers to
deal with reindexing rendering the cached copy out of date.  However in the
normal case where files don't change their content it will be fine.

----------------------------------------------------------------------

Comment By: Paul D. Smith (psmith)
Date: 2009-04-08 00:01

Message:
Will that really work?  It's been a while since I've thought about this,
and even longer since I've messed with Squid, but since LXR is a CGI
interface won't it always go through the proxy to the backing server?  If
it doesn't, then how do normal dynamic CGI interfaces ever work with a
caching front-end like Squid?

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2009-04-07 23:35

Message:
Or simply configure Squid in front of LXR and let it worry about it...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1691362&group_id=27350

[Lxr-dev] [ lxr-Feature Requests-1691362 ] Add caching of annotated files to speed up access

[SourceForge.net <no...@so...>]

Feature Requests item #1691362, was opened at 2007-03-30 16:18
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1691362&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: Open
Priority: 5
Private: No
Submitted By: Paul D. Smith (psmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add caching of annotated files to speed up access

Initial Comment:
Currently all pages displayed by LXR are dynamically generated.  However, most of the content displayed is relatively static.  I propose that LXR create a cache of annotated files to speed up browsing.  Here are some specifics:

1) We already have a fileid, so the cache should be organized by fileid with an appropriate directory fan-out.  Since the fileid format is specific to the file backend, this might be a bit tricky--one possibility is to let the file backend do the fan-out with a special method.  At any rate, this ensures that all releases that use the same file version share the cache, while releases with the same file but different versions have different cached contents.

2) Only the actual annotated file should be cached: we should not cache the entire page (header/footer/etc.)  So, we don't have a completely static page, but close: we just have to generate the header/footer etc., and insert the contents of the cached file at the appropriate place.  This allows us to avoid the cache even when the list of releases/architectures/etc. changes.

3) If the fileid is truly unique (which I believe it has to be for LXR to work properly) then we don't really need to worry about a stale cache: it can never be stale because a different file will have a different fileid.  If, for some reason, that's not sufficient it's trivial enough to detect stale data using creation time on the cached file.

4) Cleaning the cache is a trickier problem.  There are a number of options here.  For simple disk space reclamation we can, for example, examine the time last accessed and clean up the cached files older than a certain date.  A cleanup script could be run daily or weekly, with various options such as a maximum cache size, or a fixed "clean anything older than X days".  An alternative to using access time (which can be problematic since backups can modify it, or maybe your filesystem is mounted noatime for efficiency reasons) is to use time last modified, and have LXR touch the file to update the modification time every time it gets the file from the cache.

Another option is to simply not clean the cache, since we don't clean out the database normally.  We should add in some code to clean the cache when we DO clean out the DB: there are options to genxref to remove releases etc.

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2009-04-08 10:44

Message:
It should work fine - caching behaviour is controlled by Cache-* headers in
the HTTP response, and looking at the headers that LXR spits out it rightly
does nothing to prevent caching.

I've not tried it but I see no reason why it wouldn't work.  For bonus
points LXR should probably provide better caching control in the headers to
deal with reindexing rendering the cached copy out of date.  However in the
normal case where files don't change their content it will be fine.

----------------------------------------------------------------------

Comment By: Paul D. Smith (psmith)
Date: 2009-04-08 00:01

Message:
Will that really work?  It's been a while since I've thought about this,
and even longer since I've messed with Squid, but since LXR is a CGI
interface won't it always go through the proxy to the backing server?  If
it doesn't, then how do normal dynamic CGI interfaces ever work with a
caching front-end like Squid?

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2009-04-07 23:35

Message:
Or simply configure Squid in front of LXR and let it worry about it...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1691362&group_id=27350

[Lxr-dev] [ lxr-Feature Requests-1691362 ] Add caching of annotated files to speed up access

[SourceForge.net <no...@so...>]

Feature Requests item #1691362, was opened at 2007-03-30 11:18
Message generated for change (Comment added) made by psmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1691362&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: Open
Priority: 5
Private: No
Submitted By: Paul D. Smith (psmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add caching of annotated files to speed up access

Initial Comment:
Currently all pages displayed by LXR are dynamically generated.  However, most of the content displayed is relatively static.  I propose that LXR create a cache of annotated files to speed up browsing.  Here are some specifics:

1) We already have a fileid, so the cache should be organized by fileid with an appropriate directory fan-out.  Since the fileid format is specific to the file backend, this might be a bit tricky--one possibility is to let the file backend do the fan-out with a special method.  At any rate, this ensures that all releases that use the same file version share the cache, while releases with the same file but different versions have different cached contents.

2) Only the actual annotated file should be cached: we should not cache the entire page (header/footer/etc.)  So, we don't have a completely static page, but close: we just have to generate the header/footer etc., and insert the contents of the cached file at the appropriate place.  This allows us to avoid the cache even when the list of releases/architectures/etc. changes.

3) If the fileid is truly unique (which I believe it has to be for LXR to work properly) then we don't really need to worry about a stale cache: it can never be stale because a different file will have a different fileid.  If, for some reason, that's not sufficient it's trivial enough to detect stale data using creation time on the cached file.

4) Cleaning the cache is a trickier problem.  There are a number of options here.  For simple disk space reclamation we can, for example, examine the time last accessed and clean up the cached files older than a certain date.  A cleanup script could be run daily or weekly, with various options such as a maximum cache size, or a fixed "clean anything older than X days".  An alternative to using access time (which can be problematic since backups can modify it, or maybe your filesystem is mounted noatime for efficiency reasons) is to use time last modified, and have LXR touch the file to update the modification time every time it gets the file from the cache.

Another option is to simply not clean the cache, since we don't clean out the database normally.  We should add in some code to clean the cache when we DO clean out the DB: there are options to genxref to remove releases etc.

----------------------------------------------------------------------

Comment By: Paul D. Smith (psmith)
Date: 2009-04-07 19:01

Message:
Will that really work?  It's been a while since I've thought about this,
and even longer since I've messed with Squid, but since LXR is a CGI
interface won't it always go through the proxy to the backing server?  If
it doesn't, then how do normal dynamic CGI interfaces ever work with a
caching front-end like Squid?

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2009-04-07 18:35

Message:
Or simply configure Squid in front of LXR and let it worry about it...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1691362&group_id=27350

[Lxr-dev] [ lxr-Feature Requests-1691362 ] Add caching of annotated files to speed up access

[SourceForge.net <no...@so...>]

Feature Requests item #1691362, was opened at 2007-03-30 16:18
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1691362&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: Open
Priority: 5
Private: No
Submitted By: Paul D. Smith (psmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add caching of annotated files to speed up access

Initial Comment:
Currently all pages displayed by LXR are dynamically generated.  However, most of the content displayed is relatively static.  I propose that LXR create a cache of annotated files to speed up browsing.  Here are some specifics:

1) We already have a fileid, so the cache should be organized by fileid with an appropriate directory fan-out.  Since the fileid format is specific to the file backend, this might be a bit tricky--one possibility is to let the file backend do the fan-out with a special method.  At any rate, this ensures that all releases that use the same file version share the cache, while releases with the same file but different versions have different cached contents.

2) Only the actual annotated file should be cached: we should not cache the entire page (header/footer/etc.)  So, we don't have a completely static page, but close: we just have to generate the header/footer etc., and insert the contents of the cached file at the appropriate place.  This allows us to avoid the cache even when the list of releases/architectures/etc. changes.

3) If the fileid is truly unique (which I believe it has to be for LXR to work properly) then we don't really need to worry about a stale cache: it can never be stale because a different file will have a different fileid.  If, for some reason, that's not sufficient it's trivial enough to detect stale data using creation time on the cached file.

4) Cleaning the cache is a trickier problem.  There are a number of options here.  For simple disk space reclamation we can, for example, examine the time last accessed and clean up the cached files older than a certain date.  A cleanup script could be run daily or weekly, with various options such as a maximum cache size, or a fixed "clean anything older than X days".  An alternative to using access time (which can be problematic since backups can modify it, or maybe your filesystem is mounted noatime for efficiency reasons) is to use time last modified, and have LXR touch the file to update the modification time every time it gets the file from the cache.

Another option is to simply not clean the cache, since we don't clean out the database normally.  We should add in some code to clean the cache when we DO clean out the DB: there are options to genxref to remove releases etc.

----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2009-04-07 23:35

Message:
Or simply configure Squid in front of LXR and let it worry about it...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1691362&group_id=27350

[Lxr-dev] [ lxr-Feature Requests-1053123 ] Better Diff-Engine

[SourceForge.net <no...@so...>]

Feature Requests item #1053123, was opened at 2004-10-24 11:03
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1053123&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: Closed
Priority: 5
Private: No
Submitted By: Rumpeltux (rumpeltux)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better Diff-Engine

Initial Comment:
Hi,
the diff-engine used by LXR often produces a lot of
garbage and does not give too detailed information
about the actual differences.
What i'd like to see is st. like the engine the
wikimedia-project uses (e.g. in the wikipedia), where
even the changes in one line are highlighted...
This would be great ;)

Regards,
Rumpeltux

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1053123&group_id=27350

[Lxr-dev] [ lxr-Feature Requests-452471 ] configurable source presentation

[SourceForge.net <no...@so...>]

Feature Requests item #452471, was opened at 2001-08-18 13:39
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=452471&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: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: configurable source presentation

Initial Comment:
hi,
I've customized the LXR.0.3 Common and genxref in 
order to make the output more readable (close to an 
emcas cmode). Yet those changes are not generic, and 
fit only the needs of my company's team for C/C++ code.

whishes:
--------

* LXR should present the parsed code as an advanced 
editor would do. (i.e: highlight functions, methods,  
classes definition, includes, defines, local & global 
variables, and get rid of the standard links color...)

* The faces (or stylesheets) should be configurable.

* quick jump when possible and selected (i.e: direct 
link to function definition instead of passing by 
ident script)

linked whishes:
---------------

* LXR should be able to use cached pages (static 
preparsed files on demand): in order to balance the 
overhead of style processing.

* incremental reindex should be possible on modified 
files in src repository only.

* 1 xref DB per src file or subdir? => could solve 
scalability problems for large repositories and could 
accelerate the file processing (markupfile). yet this 
would require another db format/content for the main 
xref db in order to have the 'identifier search' 
working, and working fast whatever the size of the 
repository...

* and other minor whishes...

(sleepless) dreams:
-------------------

* have emacs interacting and working as LXR i.e; by 
mean of a switch between browse and edit modes... (if 
any of you knows something similar, please let me 
know!)


(nice and usefull tool anyway! :o)

kr,
-jmhe-

----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2009-04-07 23:19

Message:
Most of these features are now implemented in 0.9.x - give it a try!


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-18 13:56

Message:
Logged In: NO 

+ other 'todo' such as floating toolbar for mode 
selections, framing, web lxr configuration, automatic 
reindex and conf generation, diff improvements, ifdef 
parsing and parenthesis matching...

contact: jm...@ad...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=452471&group_id=27350

[Lxr-dev] LXR needs your help!

[Malcolm B. <mal...@gm...>]

Shockingly LXR has managed to get to v0.9.6 and thousands of downloads
without one of the crucial elements for a great piece of software.

No, not a great UI.

No, not lots of features.

No, not even very few bugs.

What LXR lacks is a logo.  How can LXR hold its head up in the
pantheon of free software when it is handicapped, nay crippled by such
a dreadful lack?

I say enough is a enough.  No longer must LXR make do with three
simple letters - from now on LXR shall have a logo to dazzle, impress
and wow its friends.

This is a call to create that logo for LXR and win fame and fortune
around the world.  (OK, I'm kidding about the fortune.  And the fame.
But anyway...)

I'm no graphic artist, as will be obvious from the feeble attempt
attached.  So please, if you can do better then send in your
suggestions and ideas to lxr...@li....  The winner will be
selected by members of the LXR mailing lists, so get your pixels or
paintbrushes out and show the world what you can do!

Cheers,

Malcolm

Re: [Lxr-dev] Further Details on What I'm Looking to Fix in LXR

[<adr...@no...>]

Hi Malcolm,

Fair enough. Some comments from me embedded in the email below ...

Adrian

PS I'm not sure if this'll get to lxr...@li... or not - I'm in the process of trying to change the email address that I've got subscribed to this ...

----- Original Message ----- 
From: "Malcolm Box" <mal...@gm...>
To: <ad...@is...>
Cc: <adr...@no...>; <lxr...@li...>
Sent: Monday, March 30, 2009 12:55 PM
Subject: Re: Further Details on What I'm Looking to Fix in LXR


Hi Adrian,

I've CC'ed lxr-developer as well to keep everyone informed as to
what's happening.

On Sun, Mar 29, 2009 at 6:16 PM,  <ad...@is...> wrote:
> Hi Malcolm,
>
> Just thought I'd let you know what bugs I'm planning to fix before I get
> onto the meaty stuff mentioned in the email I sent just now. Since there
> aren't any bugs for these things on SourceForge would you like me to raise
> some so the changes are tracked fully or shall I just submit changes to 
> CVS
> as I go along?

Yes, please raise bugs and then record the bug as fixed in the CVS
change comment.

>> Here are the bugs in the order I'm thinking of working on them:
>
> 1) Allow the scripts to be run on windows as follows:
> < #!/usr/bin/perl -T
>> #!perl -T

Is this really necessary?  On Windows, you have to type "perl genxref"
etc anyway, so the #! doesn't have bad effects.  As far as I'm aware
the #! is ignored.

Or is the problem with the source/find/ident scripts running from CGI
or mod_perl context?

[AJI] IIRC it was a problem running the scripts from a CGI context.

>
> 2) LXR::Config
> Add some minor validation and ensure that various directories exist

Great.

> 3) search
> Fix issue where swish results not being shown correctly due to pipe issues
> on windows

OK - can you test this on a Linux box as well to make sure it doesn't
break Unix?  I'm using VirtualBox (www.virtualbox.com) and Ubuntu to
have a virtual Linux server on my windows laptop - I can send you
details on how to set up if it would help.  Otherwise I can test the
patches my side.

[AJI] I think you meant www.virtualbox.org. Anyhow, I'll consider giving 
that a go. If I can get
the tests running directly on windows I might stick to just that but when I 
last gave that a go they didn't
immediately work so I might need to do as you suggest. I'll let you know.

> 4) LXR::Lang / LXR\Lang\Generic.pm
> processinclude() should check to see if the include code contains a 
> reserved
> word (e.g. #include)
>
> 5) LXR\Lang\generic.conf
> Add pre-processor keywords to the C and C++ language definitions

Both look good to me.

Cheers,

Malcolm 

Re: [Lxr-dev] Further Details on What I'm Looking to Fix in LXR

[Malcolm B. <mal...@gm...>]

Hi Adrian,

I've CC'ed lxr-developer as well to keep everyone informed as to
what's happening.

On Sun, Mar 29, 2009 at 6:16 PM,  <ad...@is...> wrote:
> Hi Malcolm,
>
> Just thought I'd let you know what bugs I'm planning to fix before I get
> onto the meaty stuff mentioned in the email I sent just now. Since there
> aren't any bugs for these things on SourceForge would you like me to raise
> some so the changes are tracked fully or shall I just submit changes to CVS
> as I go along?

Yes, please raise bugs and then record the bug as fixed in the CVS
change comment.

>> Here are the bugs in the order I'm thinking of working on them:
>
> 1) Allow the scripts to be run on windows as follows:
> < #!/usr/bin/perl –T
>> #!perl –T

Is this really necessary?  On Windows, you have to type "perl genxref"
etc anyway, so the #! doesn't have bad effects.  As far as I'm aware
the #! is ignored.

Or is the problem with the source/find/ident scripts running from CGI
or mod_perl context?

>
> 2) LXR::Config
> Add some minor validation and ensure that various directories exist

Great.

> 3) search
> Fix issue where swish results not being shown correctly due to pipe issues
> on windows

OK - can you test this on a Linux box as well to make sure it doesn't
break Unix?  I'm using VirtualBox (www.virtualbox.com) and Ubuntu to
have a virtual Linux server on my windows laptop - I can send you
details on how to set up if it would help.  Otherwise I can test the
patches my side.

> 4) LXR::Lang / LXR\Lang\Generic.pm
> processinclude() should check to see if the include code contains a reserved
> word (e.g. #include)
>
> 5) LXR\Lang\generic.conf
> Add pre-processor keywords to the C and C++ language definitions

Both look good to me.

Cheers,

Malcolm

[Lxr-dev] [ lxr-Bugs-2721915 ] Install script

[SourceForge.net <no...@so...>]

Bugs item #2721915, was opened at 2009-03-30 11:43
Message generated for change (Tracker Item Submitted) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2721915&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Malcolm Box (mbox)
Assigned to: Malcolm Box (mbox)
Summary: Install script

Initial Comment:
LXR needs an install script that automates the installation.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2721915&group_id=27350

[Lxr-dev] [ lxr-Feature Requests-1898059 ] cursor in the input box

[SourceForge.net <no...@so...>]

Feature Requests item #1898059, was opened at 2008-02-20 17:38
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1898059&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: Closed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Malcolm Box (mbox)
Summary: cursor in the input box

Initial Comment:
Hi,

First of all, thank you for the great work.
I am not sure if this has been discussed before but if not, I would like to ask if you can make a small change to put the cursor in search input box by default so that I don't have to move my mouse to go to input box to type the keyword to search.

In fact, google also does this so I found it very conveneint to type the keyword as soon as I get there.

Thank you.

----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2009-03-30 11:37

Message:
Good suggestion!

I've implemented this in CVS - you can get this working on an existing
install by grabbing the new versions of templates/html* from CVS.

Otherwise it will be in the next release (0.9.7).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-03-13 13:15

Message:
e8llju 16430490 3017ym [URL=http://refruit.com/rsstmp/mietwagen/] mietwagen
[/URL] <a href="http://refruit.com/rsstmp/mietwagen/"> mietwagen </a>
http://refruit.com/rsstmp/mietwagen/ 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390120&aid=1898059&group_id=27350

Re: [Lxr-dev] LXR project coming back to life

[<ad...@is...>]

Hi Malcolm,

I certainly noticed all the emails :) As it happens I'm in the process of getting started on making some changes myself after promising you a few months ago that I'd do so. 

I'm going to fix a few bugs (which don't seem to be listed on SourceForge) and then look at adding the following new functionality:
* Allow reserved words to be specified using a regular expression. Mainly to to fix bug 1832713: Implement case-insensitive language processing.
* Update the processing of includes so any files not found using incprefix are looked up in the database. If a single match is found then the include becomes a link to that file whilst if multiple matches are found then the include becomes a link to the search page for that file.
* Update the detection of symbols so that only symbols for the language of the file being processed are marked up. E.g. C++ symbols won't be shown in a make file etc.

More on the above anon ...

Adrian

> -----Original Message-----
> From: ext Malcolm Box [mailto:mal...@gm...]
> Sent: 26 March 2009 18:02
> To: lxr...@li...
> Subject: [Lxr-dev] LXR project coming back to life
> 
> Hi,
> 
> You might have noticed the recent flurry of activity on lxr-developer
> (assuming anyone is still reading these mails).  Thanks to the state
> of the economy, I now have more time on my hands and am planning to
> spend more time working on the LXR.  Sorry for the 3 year hiatus - and
> if anyone else wants to take over/become a maintainer I'm more than
> happy to hand over the reins.
> 
> The codebase at SF is now a bit old and tired, and Arne's LXRng has
> some nice new features.  My hope/plan is to:
> 
> - Resolve all the remaining bugs reported, and apply any outstanding
> patches etc. to the 0.9.x tree
> - Release v1.0.0 at last
> - Start on a major refresh/overhaul of LXR, merging/incorporating the
> work Arne's done on LXRng.
> 
> Main goals for the overhaul from my point of view are:
> 
> - Much improved browsing experience, using AJAX etc to provide a much
> smoother searching and browsing experience.
> - Move to a proper web framework for the frontend (currently seriously
> considering Django) so that setup, caching, templates and providing a
> RESTful API are all easier.
> - Improve the speed and accuracy of the genxref process
> 
> Any comments or criticism would be welcome!
> 
> Malcolm
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Lxr-developer mailing list
> Lxr...@li...
> https://lists.sourceforge.net/lists/listinfo/lxr-developer

>

Re: [Lxr-dev] LXR project coming back to life

[Paul S. <ps...@ne...>]

On Thu, 2009-03-26 at 14:01 -0400, Malcolm Box wrote:
> You might have noticed the recent flurry of activity on lxr-developer
> (assuming anyone is still reading these mails).

I'm still reading, and greatly appreciate the fact that LXR has new
life!  I don't have time to get involved (:-() but I like the directions
you are talking about.

Good stuff!

[Lxr-dev] LXR project coming back to life

[Malcolm B. <mal...@gm...>]

Hi,

You might have noticed the recent flurry of activity on lxr-developer
(assuming anyone is still reading these mails).  Thanks to the state
of the economy, I now have more time on my hands and am planning to
spend more time working on the LXR.  Sorry for the 3 year hiatus - and
if anyone else wants to take over/become a maintainer I'm more than
happy to hand over the reins.

The codebase at SF is now a bit old and tired, and Arne's LXRng has
some nice new features.  My hope/plan is to:

- Resolve all the remaining bugs reported, and apply any outstanding
patches etc. to the 0.9.x tree
- Release v1.0.0 at last
- Start on a major refresh/overhaul of LXR, merging/incorporating the
work Arne's done on LXRng.

Main goals for the overhaul from my point of view are:

- Much improved browsing experience, using AJAX etc to provide a much
smoother searching and browsing experience.
- Move to a proper web framework for the frontend (currently seriously
considering Django) so that setup, caching, templates and providing a
RESTful API are all easier.
- Improve the speed and accuracy of the genxref process

Any comments or criticism would be welcome!

Malcolm

[Lxr-dev] [ lxr-Bugs-476773 ] Shouldn't install global signal handlers

[SourceForge.net <no...@so...>]

Bugs item #476773, was opened at 2001-10-31 14:33
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=476773&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: Wont Fix
Priority: 7
Private: No
Submitted By: Malcolm Box (mbox)
Assigned to: Malcolm Box (mbox)
Summary: Shouldn't install global signal handlers

Initial Comment:
Currently Common.pm installs global signal handlers for
DIE and WARN.  This means that all scripts running
under mod_perl will use these handlers, even if they
are not part of LXR.

This is wrong.

----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:46

Message:
The whole of the browsing interface to LXR needs to be rewritten as current
system is a bit of a mess.  Signal handlers are the least of the problems
:)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=476773&group_id=27350

[Lxr-dev] [ lxr-Bugs-476775 ] mod_perl coding style should be checked

[SourceForge.net <no...@so...>]

Bugs item #476775, was opened at 2001-10-31 14:34
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=476775&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: Wont Fix
Priority: 5
Private: No
Submitted By: Malcolm Box (mbox)
Assigned to: Malcolm Box (mbox)
Summary: mod_perl coding style should be checked

Initial Comment:
The mod_perl coding hints from
http://www.perlreference.com/mod_perl/guide/porting.html
should be checked through and applied.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=476775&group_id=27350

[Lxr-dev] [ lxr-Bugs-481597 ] Should index X::Y() as well as Y()

[SourceForge.net <no...@so...>]

Bugs item #481597, was opened at 2001-11-14 07:17
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=481597&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: 3
Private: No
Submitted By: Malcolm Box (mbox)
Assigned to: Malcolm Box (mbox)
Summary: Should index X::Y() as well as Y()

Initial Comment:
For C++ and other OO languages, we should index both
the full scoped name of the function (ie
Class::Function()) as well as just Function().

This looks easy(ish) to do - ctags already spits out
the class of a method in the extended information, and
it would be easy to insert another entry for the full
name.  References would be harder - it's much more
difficult if not impossible to determine what function
a callsite will actually resolve to except by doing a
full compile.  So we might have to settle for indexing
the declarations of the fully scoped names but not the
references, or strip out scope when running ident.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-28 13:06

Message:
Logged In: NO 

Also C++ namespace scoping does not work... and is similar
in syntax.. not sure if another bug should be created or not...

//in somefile.h
namespace ns{ class Foo{};};

//in some_other_file.cpp
void func(){
   ns::Foo f;  //<-- will not be linked 
}

unfortunately, his affects about 90% of my code... 

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-28 13:05

Message:
Logged In: NO 

Also C++ namespace scoping does not work... and is similar
in syntax.. not sure if another bug should be created or not...

//in somefile.h
namespace ns{ class Foo{};};

//in some_other_file.cpp
void func(){
   ns::Foo f;  //<-- will not be linked 
}

unfortunately, his affects about 90% of my code... 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=481597&group_id=27350

[Lxr-dev] [ lxr-Bugs-500773 ] no revisions are available on any page

[SourceForge.net <no...@so...>]

Bugs item #500773, was opened at 2002-01-08 11:30
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=500773&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: v0.9
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Bartlomiej Pater (noster)
Assigned to: Nobody/Anonymous (nobody)
Summary: no revisions are available on any page

Initial Comment:
hello,

I have problem with 0.9 version of lxr. After I have finally came to a solution with how to make it to read sources from CVS (I have to adopt config file - see below) I am unable to browse it. When I look into database created by genxref (see attachment) it seems it finds the files and their versions correctly. But when I try to browse it I can only see some 'head' tag/version. If I put versions in "range" variable in the config file it is ok, and I can do everything, but I need CVS support to know the version numbers everytime they change.

I have also tried version from CVS [about week ago] but with the same effect.

My configuration:
- gnu-linux-i386pc [debian sid]
- apache 1.3.22
- mysql 3.23.46
- perl 5.6.1 and 5.005 [v6.3 whatever it means - I'm not perl guru]
- libdbi-perl 1.20
- libdbd-mysql-perl 1.2216

I have tried it also at different machine but with very similiar configuration and with the same effect.


----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:43

Message:
Configuration shown below fixes the problem.

----------------------------------------------------------------------

Comment By: Bartlomiej Pater (noster)
Date: 2002-01-08 11:47

Message:
Logged In: YES 
user_id=22605

this is the way I had to change the config to make it work
at all [well, part of it]:

'range'   => sub { return ($files->allreleases("/"),
$files->allrevisions("/"))                                 
      },


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=500773&group_id=27350

[Lxr-dev] [ lxr-Bugs-516464 ] symbols treated as ordinary literals

[SourceForge.net <no...@so...>]

Bugs item #516464, was opened at 2002-02-12 15:54
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=516464&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: v0.9
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Pavel Hlavnicka (pavel_hlavnicka)
Assigned to: Nobody/Anonymous (nobody)
Summary: symbols treated as ordinary literals

Initial Comment:
I'm not sure, whether it is bug or my local
installation problem.

>From time to time (it seems, that it usually happens,
if I click a link to source on the identifiers search
page) are indexed symbols displayed as an ordinary
text. There is no <a> markup in the page source. 

The simple reaload of the page always helps.

Has anybody seen something similar?

(I'm running 0.91)

----------------------------------------------------------------------

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2002-02-25 08:31

Message:
Logged In: YES 
user_id=302801

Some global initialization problem seems be quite possible.
The frequency of the unexpected behavior matches this idea.

... and the behavior is as you said: all markup is correct,
but no symbols are linked (no <a> in the sources).

I'll try the single user mode and let you know.

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2002-02-20 03:51

Message:
Logged In: YES 
user_id=215386

Hmm, I haven't heard of anyone else seeing this.  You could
try running apache in single (debug) mode where it doesn't
fork new processes.  Often a bug that disappears on reload
is caused by initialisation problems and debug mode helps
show these up.

When you get no links, does the code come up as plain text
or is it marked up with comments, line numbers etc but just
without the indentifiers linked?

If you are still seeing this problem, please post more
details to the lxr-developer list and hopefully someone will
be able to track it down.

Thanks,

Malcolm



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=516464&group_id=27350

[Lxr-dev] [ lxr-Bugs-519945 ] definitions are also references

[SourceForge.net <no...@so...>]

Bugs item #519945, was opened at 2002-02-19 12:56
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=519945&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: v0.9
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Shree (shreekumar)
Assigned to: Malcolm Box (mbox)
Summary: definitions are also references

Initial Comment:
LXR 0.9.1 [as well as older versions] shows definition 
also in the list of references.

eg consider a file test.c
---
#define TEST 1
--

Searching for "TEST" will show that it is
1. a macro defined at line 1, file test.c and
2. referenced in test.c at line 1

If the number of definitions is small, this is OK. But 
when the number of definitions is large, finding which 
of the references are actually references becomes a 
pain.

The easiest solution for this would be to remove all 
definitions from the references list.

If this is acceptable, I have a patch ready [the 
backend is MySQL]

----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:36

Message:
This is by design - the definition is a reference to the file.

Having multiple definitions should be rare, since most languages require a
single definition...


----------------------------------------------------------------------

Comment By: Heikki Toivonen (hjtoi)
Date: 2004-03-12 16:17

Message:
Logged In: YES 
user_id=972898

Can you attach a patch, please?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=519945&group_id=27350

[Lxr-dev] [ lxr-Bugs-559121 ] Out of memory errors during genxref

[SourceForge.net <no...@so...>]

Bugs item #559121, was opened at 2002-05-22 12:40
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=559121&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: v0.9.1
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Andy Baskett (abaskett)
Assigned to: Nobody/Anonymous (nobody)
Summary: Out of memory errors during genxref

Initial Comment:
I'm not sure where the problem arises - I have spent 
hours (8+) attempting to debug the code and looked 
through CVS to see where previous leaks were fixed 
but to no avail.  
My MySQL "lxr.files" table currently contains 4400 files.
My repository contains thousands of font files and 
other non-indexable files.
My repository contains hundreds of files generated 
with old (9+ years) versions of RCS which results 
in "co" errors.

Using Devel::Leak I believe the biggest leak is 
when "co" fails - under these circumstances I think the 
FileHandle is not "undef" but actually contains the  
error message from "co". Perhaps parsing this causes 
a problem?

In any case Devel::Leak shows each file generates 2 
leaks per file (even when indexing successfully) - I 
think %files lib/LXR/Index/Mysql.pl causes one as it 
keeps getting appended - is it possible to include %
files = undef in the "empty_cache" function?

Other than that I am at a loss for ideas.
I am running very old versions of perl and MySQL 
which I hope to update and may be the cause, but I 
expect they are not the only reason for the problem.

I am running:
LXR 0.9.1
mysql 3.22.30
ectags 5.0.1
HP-UX 10.20


----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:31

Message:
Running against a very large repository works here, and several memory
leaks have been fixed since the 0.9.1 release.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-01 15:31

Message:
Logged In: NO 

Similar case here, also indexing a CVS tree. The "Out of
memory!" occurs always at the same point, in just a few
minutes, after indexing a few hundred files.

OpenBSD 3.0
perl-5.6.1 (official obsd pkg)
LXR 0.9.1
mysql-3.23.37 (official obsd pkg, on remote host running
OBSD 2.9)
ectags 5.2.3
swish-e 2.1-dev-25 (didn't get to the point of actually
running it)

$ ulimit -a
time(cpu-seconds)    unlimited
file(blocks)         unlimited
coredump(blocks)     unlimited
data(kbytes)         65536
stack(kbytes)        4096
lockedmem(kbytes)    61366
memory(kbytes)       184100
nofiles(descriptors) 64
processes            64

The funny thing is that it when run under perl debugger
(perl -d genxref ...) it kept working for many hours, having
indexed thousands of files.
`ulimit -a` returns the same values, not matter if run
inside the perl debugger or not.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=559121&group_id=27350

[Lxr-dev] [ lxr-Bugs-568493 ] low performance in Files::tmpfile

[SourceForge.net <no...@so...>]

Bugs item #568493, was opened at 2002-06-13 13:26
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=568493&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: v0.9.1
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Gregor Hartmann (grex)
Assigned to: Malcolm Box (mbox)
Summary: low performance in Files::tmpfile

Initial Comment:
When using Plain.pm the file is copied entirely to the tmp dir.
Would a Symbolic link be enough here at least for UNX?

Maybe the Files module could be changed to supply two methods

AcquireTempFile( ... )
ReleaseTempFile( ... )

AcquireTempFile could then in the case of Plain files just return the original filename while
ReleaseTempFile does nothing. Ths is to avoid unlinking the files if they are no real tempfiles but the 
original.

I could do this but first wanted to hear if there is any problem.


----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:29

Message:
Same problem as 2714744.



----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2004-04-21 23:57

Message:
Logged In: YES 
user_id=215386

I don't see a problem with this, there is a clear point at
which to clean up (where the file is currently deleted). 
This would probably improve performance for the Plain method.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=568493&group_id=27350

[Lxr-dev] [ lxr-Bugs-695699 ] Cannot search for quote characters

[SourceForge.net <no...@so...>]

Bugs item #695699, was opened at 2003-03-01 19:35
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=695699&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Jon Foster (jongfoster)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot search for quote characters

Initial Comment:
Hi,

I was trying to do a freetext search on lxr.linux.no
for the string "0" - the quote characters are part of
the search.  Clicking search takes me to this URL:
http://lxr.linux.no/search?string=%220%22

Which just displays:
Abort!
** Aborting: Illegal characters in HTTP-parameters.

It seems perfectly reasonable to me to want to search
for a C quoted string in a C program.

Similarly, searching for '0' (including the single
quotes) takes me to this URL:
http://lxr.linux.no/search?string=%270%27
Which has the same error message.

I suspect that this is an anti-script-kiddie feature
(if you are passing strings on the command line and
want to prevent quoting attacks like the recent KDE
3.0.4 hole), so maybe this is a RFE (check everything
is quote-safe then disable the anti-script-kiddie
feature) rather than a bug.

Kind regards,

Jon Foster.


----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:28

Message:
Searching for '0' or "0" now work for me.

----------------------------------------------------------------------

Comment By: Jon Foster (jongfoster)
Date: 2003-03-01 19:38

Message:
Logged In: YES 
user_id=199289

Hi,

Sorry for the spam, I should have spotted this related issue
before I submitted:

Bug 463138 - Unable to enter full glimpse REs
https://sourceforge.net/tracker/index.php?func=detail&aid=463138&group_id=27350&atid=390117

Kind regards,

Jon Foster


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=695699&group_id=27350

[Lxr-dev] [ lxr-Bugs-695699 ] Cannot search for quote characters

[SourceForge.net <no...@so...>]

Bugs item #695699, was opened at 2003-03-01 19:35
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=695699&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Jon Foster (jongfoster)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot search for quote characters

Initial Comment:
Hi,

I was trying to do a freetext search on lxr.linux.no
for the string "0" - the quote characters are part of
the search.  Clicking search takes me to this URL:
http://lxr.linux.no/search?string=%220%22

Which just displays:
Abort!
** Aborting: Illegal characters in HTTP-parameters.

It seems perfectly reasonable to me to want to search
for a C quoted string in a C program.

Similarly, searching for '0' (including the single
quotes) takes me to this URL:
http://lxr.linux.no/search?string=%270%27
Which has the same error message.

I suspect that this is an anti-script-kiddie feature
(if you are passing strings on the command line and
want to prevent quoting attacks like the recent KDE
3.0.4 hole), so maybe this is a RFE (check everything
is quote-safe then disable the anti-script-kiddie
feature) rather than a bug.

Kind regards,

Jon Foster.


----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:28

Message:
Searching for '0' or "0" now work for me.

----------------------------------------------------------------------

Comment By: Jon Foster (jongfoster)
Date: 2003-03-01 19:38

Message:
Logged In: YES 
user_id=199289

Hi,

Sorry for the spam, I should have spotted this related issue
before I submitted:

Bug 463138 - Unable to enter full glimpse REs
https://sourceforge.net/tracker/index.php?func=detail&aid=463138&group_id=27350&atid=390117

Kind regards,

Jon Foster


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=695699&group_id=27350