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

[Lxr-dev] [ lxr-Bugs-478616 ] Last-Modified: Thu, 01 Jan 1970 00:00:00

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

Bugs item #478616, was opened at 2001-11-06 02:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=478616&group_id=27350

Category: Browsing
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Last-Modified: Thu, 01 Jan 1970 00:00:00

Initial Comment:
lxr provides a wrong Last-Modified field on
popular web sites, like cvs.gnome.org or mozilla:

wget -S http://lxr.mozilla.org/seamonkey/source/
or
wget -S http://cvs.gnome.org/lxr/source

..
..
4 Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT
..
..



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

>Comment By: Malcolm Box (mbox)
Date: 2001-11-13 23:40

Message:
Logged In: YES 
user_id=215386

I cannot reproduce this - both the URLs you supply give back
correct last-modified dates (or at least, not 1970 dates). 
Testing against the current CVS lxr also shows correct dates.

Looking at the code, I can see no way that such a date would
be printed with the current code - it explicitly checks for
the case when the time returned is 0 (ie start of epoch) and
doesn't return a header.

Note that this is not the place to report problems with
installations of the lxr such as at mozilla or gnome, since
we have no idea what code they are running.  Please only
report bugs against an installation that you are running
using the lxr code from here, so we can have a chance to
track down any bug and fix it.



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

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

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

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

Bugs item #481597, was opened at 2001-11-13 23:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=481597&group_id=27350

Category: Lang support
Group: current cvs
Status: Open
Resolution: None
Priority: 6
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.

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

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

[Lxr-dev] [ lxr-Feature Requests-481579 ] generate static pages

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

Feature Requests item #481579, was opened at 2001-11-13 21:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390120&aid=481579&group_id=27350

Category: General
Group: None
Status: Open
Priority: 5
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.

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

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

[Lxr-dev] [ lxr-Bugs-481573 ] requires non-free software for searching

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

Bugs item #481573, was opened at 2001-11-13 20:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=481573&group_id=27350

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: requires non-free software for searching

Initial Comment:
On your front page you suggest Glimpse, which is
horridly non-free:
http://www.arco.de/~kj/harvest/glimpse-license-status

This program is GPL, so a user might assume that it's
dependancies are GPL. 

Please provide hooks for Swish-E http://swish-e.org/ or
Swish++
http://homepage.mac.com/pauljlucas/software/swish/
which are GPL replacements.
If I am in error and this feature allready exists in
lxr, please change the content of http://lxr.linux.no/
to suggest Swish-E or Swish++.


I might note that I caught this as a part of our
department's implementation of Bugzilla (bonsai uses
lxr) which is a mission-critical application for
development here, and now that we know that Glimpse has
*never* been in the public domain (the source we found
had a misleading copyright file) we need to find a
replacement or pay up before the audit rolls around.

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

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

[Lxr-dev] [ lxr-Bugs-478616 ] Last-Modified: Thu, 01 Jan 1970 00:00:00

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

Bugs item #478616, was opened at 2001-11-06 02:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=478616&group_id=27350

Category: Browsing
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Last-Modified: Thu, 01 Jan 1970 00:00:00

Initial Comment:
lxr provides a wrong Last-Modified field on
popular web sites, like cvs.gnome.org or mozilla:

wget -S http://lxr.mozilla.org/seamonkey/source/
or
wget -S http://cvs.gnome.org/lxr/source

..
..
4 Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT
..
..



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

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

[Lxr-dev] VHDL support and other stuff

[Robin T. <Rob...@te...>]

Hi there,

I'm hacking VHDL support into lxr and have come across a few things I'd like to
comment on. I have it fully working now but based on the 0.8 release (I'm
firewalled so CVS access in N/A). I'm relying on an external parser (lex&yecc
based skeleton I ripped from the net) because VHDL is a pain to parse. The main
changes are kept in LXR::Lang::VHDL.
A few other changes are necessary though.

1) The %type_names in Common.pm are hashed from chars. With VHDL I have about
20 new types and letter allocation is getting ugly. Is there another way of
doing this. I could think of using numbers and an array instead. The db
overhead is minimal and the type is referenced few places.
I could produce a patch but I'm not dealing with C or C++ files, so I cannot
offer to fully test the (e)ctags implementation.
I'm also thinking about making this language dependent. Something like
major.minor numbers in UNIX devices. Major is the language and minor is the
local specific set.

2) The find and search is using $config->sourceroot to remove leading path so
it fits to source. However, glimpse has a nasty way of expanding symlinks so
the glimpse path and the sourceroot is not the same. I have something like this
in mind (hand edited diff against 0.8 ;-):

--- ../../lxrsrc/lxr/find	Tue Oct 16 22:38:37 2001
+++ find	Wed Oct 31 17:17:21 2001
@@ -58,11 +58,11 @@
 	    return;
 	}
 	print("<hr>\n");
+	$glimpseroot = $config->glimpseroot;
-	$sourceroot = $config->sourceroot;
 	while($file = <FILELLISTING>) {
+	    $file =~ s/^$glimpseroot//;
-	    $file =~ s/^$sourceroot//;
 	    if($file =~ /$searchtext/) {
 		print(&fileref("$file", "find-file", "/$file"),"<br>\n");

The same applies for search... Is that acceptable to include?

3) Just wondering. How could we go about dealing with an external C based
parser. Including it in the project would increase the noise (and portability).
Rewriting it into perl would be nice but quite a pain because VHDL is context
sensitive and generally stateful (and I like lex and yacc for doing this).
Right now it might make sense to keep VHDL out from the releases and offer a
language addon.


BTW, thanks for all this great work in lxr.

Regards.

Robin.
 
-- 
ASIC Design Engineer
Tellabs Denmark A/S

Direct: +45 4473 2942
rob...@te...

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

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

Bugs item #476775, was opened at 2001-10-31 06:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=476775&group_id=27350

Category: Browsing
Group: current cvs
Status: Open
Resolution: None
Priority: 5
Submitted By: Malcolm Box (mbox)
Assigned to: Nobody/Anonymous (nobody)
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: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=476775&group_id=27350

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

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

Bugs item #476773, was opened at 2001-10-31 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=476773&group_id=27350

Category: Browsing
Group: current cvs
Status: Open
Resolution: None
Priority: 7
Submitted By: Malcolm Box (mbox)
Assigned to: Nobody/Anonymous (nobody)
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.

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

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

[Lxr-dev] [ lxr-Bugs-476695 ] Java interfaces display as docs

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

Bugs item #476695, was opened at 2001-10-31 01:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=476695&group_id=27350

Category: Lang support
Group: current cvs
Status: Open
Resolution: None
Priority: 8
Submitted By: Malcolm Box (mbox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Java interfaces display as docs

Initial Comment:
When doing an ident search for a Java interface, it
will be listed in the output as a "documentation
entry".  This is because the 'i' character is mapped to
"documentation entry" by Common.pm

The simple solution is to change this mapping, but the
problem goes deeper than that.  The output of ctags is
not consistent across different languages.  For
example, "m" can mean method, module, macros, class
member or mixins.

The solution will be to change the db structure to use
an int for the type, and provide ctags -> int mappings
for each language.  There should be enough space in a 8
bit int for all different concepts across all languages.

Even better might be to give each language its own
translation strings, so that Java methods are displayed
as methods, not functions etc.  However, currently
ident does not interface to Lang.pm, so the mapping
would have to be part of a global namespace.

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

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

[Lxr-dev] [ lxr-Bugs-447979 ] Java import hyperlinking

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

Bugs item #447979, was opened at 2001-08-04 11:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=447979&group_id=27350

Category: Browsing
Group: current cvs
Status: Open
Resolution: None
Priority: 5
Submitted By: Malcolm Box (mbox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Java import hyperlinking

Initial Comment:
Java import statement hyperlinking is not as good as it
could be, since it doesn't link to the file being
imported.


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

>Comment By: Malcolm Box (mbox)
Date: 2001-10-31 01:05

Message:
Logged In: YES 
user_id=215386

This also doesn't work properly for package statements at
the moment.

Ideally, a package statement would provide a fileref to the
specified directory (assuming it's in the tree).

import should provide a fileref to the relevant package, or
a direct link to the right class/interface.  To do this will
involve tagging classes/interfaces as belonging to packages
so that we can search for them easily.

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

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

[Lxr-dev] [ lxr-Feature Requests-466170 ] Expanded CSS support

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

Feature Requests item #466170, was opened at 2001-09-28 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390120&aid=466170&group_id=27350

Category: Browsing Interface
Group: None
Status: Open
Priority: 5
Submitted By: Joseph Wilhelm (tarken)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expanded CSS support

Initial Comment:
I had just one small requested addition to the CSS. It 
would be nice to see, with the blame-annotated source, 
alternating colors the way Bonsai does; switching 
colors with each different blame. Just a small 
cosmetic addition. :)

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

>Comment By: Malcolm Box (mbox)
Date: 2001-10-31 00:41

Message:
Logged In: YES 
user_id=215386

What blame-annotated source?  I don't know of any blame
annotated output from LXR, only from cvsweb.

Could you explain what you mean?

Malcolm

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

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

Re: [Lxr-dev] Reaching 1.0

[Per K. G. <pk...@ne...>]

On Wed, 2001-10-24 at 17:35, Malcolm Box wrote:
> I think we are reaching the point where we could declare a 1.0
release.

That is good news. 

> The major features that I wanted to see in the lxr are there - CSS
> support, faster indexing, generic language support and more compliant
> HTML output.
> 
> What do you think - are we at the point where we could declare a 1.0
> release and move on to the next major development cycle, or are we >
still
> missing key features, bug fixes or stability?

There are currently 6 open bugs in the bugtracker. I don't think we
should declare 1.0 before all of them are resolved. We could either
decide that a bug is no problem for 1.0 or we should fix it. 

Another thing is that I think that 1.0 should be able to index the
entire linux-kernel and run on lxr.linux.no. It must of course be me who
does this testing. 

We should also decide on which database backends to support. We should
not ship backends that do not work. Have anyone ever gotten the DBFile
backend to work?

                                            Per Kristian

Re: [Lxr-dev] Reaching 1.0

[Malcolm B. <ma...@br...>]

Pavel Hlavnicka wrote:
> 
> Just for better look: what about checking the HTML conformance. What
> version? Currently documents declare 3.2. Did somebody test the
> conformance? What about upgrade to 4?

As of version 0.9 the templates declare the output to be HTML 4.01
Transitional (or they should ;-).  I've run the source output through
the validator at www.w3c.org and it passes.  I've also run the ident
output through it, but not the diff or search/find output.  I don't
expect those to be a problem, but it might be worth you checking. 

The other thing to do is to validate the CSS that we ship - as yet I
haven't done this.

> I know, this is not important, but reaching the release version is a
> challenge to test it.

Absolutely - we shouldn't display the logo if we're not doing the right
thing.

Cheers,

Malcolm

Re: [Lxr-dev] Re: [ lxr-Patches-455555 ] date/time ISO8601

[Pavel H. <pa...@gi...>]

I'm living in country where we speak czech and must say, that 
overlooking localization problems is very common problem :).. but in 
this case it is not a big trouble, I guess.

Of course, extracting current locale-dependent stuff from code and 
keeping it in mind in the future is good idea, but note, that once you 
create locale specific versions, you need people for maintenence.

I'm happ w/ English.

Pavel

Malcolm Box wrote:

> no...@so... wrote:
> 
>>Initial Comment:
>>Why lxr HEAD is using the old American date format and
>>http://lxr.linux.no/source/ is using ISO8601 ?
>>
>>Could you get the code from http://lxr.linux.no/source/
>>to use ISO8601 since this one is tested ?
>>If you can't just apply my patch.
>>
> 
> This bug/patch brings up an interesting question regarding localisation
> support in LXR.  Currently all the templates that are shipped and all
> the output is in English.  To support other languages, changing the
> templates is easy, but some of output is hardcoded in the perl in
> English/US locale.
> 
> Examples of the latter are:
> 
> * Date output
> * Strings searched for to find a file description
> * Filenames for directory description
> 
> in fact a lot of the stuff in Local.pm.
> 
> So I guess the question is, do we want to go to the effort of supporting
> the LXR in other languages?  Does anyone on this list care enough to do
> it and to maintain another language version?
> 
> If we do go for multi-lingual support, what's the right way to make the
> hard-coded output localisable in perl?
> 
> My feeling is that it is a lot of work for limited benefit - if someone
> did want to customise this, it would mean hacking Local.pm and some of
> the scripts in a site specific way, but it would not be hard, whereas
> putting in generic support is a harder.  But then English is my native
> language ;-)
> 
> Cheers,
> 
> Malcolm
> 
> _______________________________________________
> Lxr-developer mailing list
> Lxr...@li...
> https://lists.sourceforge.net/lists/listinfo/lxr-developer
> 


-- 
Pavel Hlavnicka
Ginger Alliance
www.gingerall.com

[Lxr-dev] Re: [ lxr-Patches-455555 ] date/time ISO8601

[Malcolm B. <ma...@br...>]

no...@so... wrote:
> Initial Comment:
> Why lxr HEAD is using the old American date format and
> http://lxr.linux.no/source/ is using ISO8601 ?
> 
> Could you get the code from http://lxr.linux.no/source/
> to use ISO8601 since this one is tested ?
> If you can't just apply my patch.

This bug/patch brings up an interesting question regarding localisation
support in LXR.  Currently all the templates that are shipped and all
the output is in English.  To support other languages, changing the
templates is easy, but some of output is hardcoded in the perl in
English/US locale.

Examples of the latter are:

* Date output
* Strings searched for to find a file description
* Filenames for directory description

in fact a lot of the stuff in Local.pm.

So I guess the question is, do we want to go to the effort of supporting
the LXR in other languages?  Does anyone on this list care enough to do
it and to maintain another language version?

If we do go for multi-lingual support, what's the right way to make the
hard-coded output localisable in perl?

My feeling is that it is a lot of work for limited benefit - if someone
did want to customise this, it would mean hacking Local.pm and some of
the scripts in a site specific way, but it would not be hard, whereas
putting in generic support is a harder.  But then English is my native
language ;-)

Cheers,

Malcolm

[Lxr-dev] [ lxr-Bugs-474752 ] Tabwidth of files should be configurable

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

Bugs item #474752, was opened at 2001-10-24 22:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=474752&group_id=27350

Category: Browsing
Group: current cvs
Status: Open
Resolution: None
Priority: 4
Submitted By: Malcolm Box (mbox)
Assigned to: Malcolm Box (mbox)
Summary: Tabwidth of files should be configurable

Initial Comment:
Currently tabs are always 8 spaces wide on display
(unless there is an emacs tabwidth line in the file).

This should be made configurable, either on a
per-language or per-site basis.

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

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

[Lxr-dev] Reaching 1.0

[Malcolm B. <ma...@br...>]

Hi,

I think we are reaching the point where we could declare a 1.0 release.

The major features that I wanted to see in the lxr are there - CSS
support, faster indexing, generic language support and more compliant
HTML output.

What do you think - are we at the point where we could declare a 1.0
release and move on to the next major development cycle, or are we still
missing key features, bug fixes or stability?

Malcolm

[Lxr-dev] [ lxr-Bugs-453387 ] variable 'v' range

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

Bugs item #453387, was opened at 2001-08-20 07:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=453387&group_id=27350

Category: genxref
>Group: current cvs
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Pavel Hlavnicka (pavel_hlavnicka)
Assigned to: Peder O. Klingenberg (pok)
Summary: variable 'v' range

Initial Comment:
I downloaded devel version 0.8 (no group available :)

If you use the commented out example in the lxr.conf
how to set the range of the variable 'v' it doesn't work.

First, at the line 74 in genxref is this variable
accesed  directly, there should be
@versions->varrange('v') I guess.

Second, after hacking this line it still doesn't work,
because the $LXR::Common::pathname (used in lxr.conf)
is not set at the time of the execution. I've no clue,
what was the original author's intention :)
It seems, that the range sould be read once per
processed file, because the releases (probably) and
revisions (for sure) may differ for each file. But I
didn't read the code so carefully to be sure.

HTH

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

Comment By: Joseph Wilhelm (tarken)
Date: 2001-09-26 08:13

Message:
Logged In: YES 
user_id=326177

Okay.. as far as I know, this is complete.  I took the list 
of reserved words from the list on php.net.

'php' => {
		  'reserved' => 
['and','$argv','$argc','break','case','class',
					
	 'continue','default','do','die','echo','else',
					
	 'elseif','empty','endfor','endforeach','endif',
					
	 'endswitch','endwhile','E_ALL','E_PARSE','E_ERROR',
					
	 'E_WARNING','exit','extends','FALSE','for','foreach
',
					
	 'function','HTTP_COOKIE_VARS','HTTP_GET_VARS',
					
	 'HTTP_POST_VARS','HTTP_POST_FILES','HTTP_ENV_VARS',
					
	 'HTTP_SERVER_VARS','if','global','list','new','not'
,
					
	 'NULL','or','parent','PHP_OS','PHP_SELF','PHP_VERSI
ON',
					
	 'print','return','static','switch','stdClass',
					
	 'this','TRUE','var','xor','virtual','while','__FILE
__',
					
	 '__LINE__','__sleep','__wakeup'
						],
		  'spec' => ['comment',  '/\*',       '\*/',
				
	 'comment',  '//',            "\$",
				
	 'comment',  '#',             "\$",
				
	 'string',   '"',             '"',
				
	 'string',   "'",             "'",
				
	 'include',  'require',      "\$",
				
	 'include',  'include',      "\$",
				
	 'include',  'require_once', "\$",
				
	 'include',  'include_once', "\$"
					],
		},


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

Comment By: Malcolm Box (mbox)
Date: 2001-09-26 02:33

Message:
Logged In: YES 
user_id=215386

Is there any chance you could post the stuff you added to
generic.conf to get php working?  I'm trying to flesh the
file out, since it currently doesn't support a lot of the
languages that ctags can cope with.

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

Comment By: Joseph Wilhelm (tarken)
Date: 2001-09-17 13:48

Message:
Logged In: YES 
user_id=326177

Hmm, on my last follow-up to this, perhaps it didn't work 
properly.  I added a 'php' entry to generic.conf so that 
everything should work great in my PHP files... but I'm not 
getting any cross-references on functions or anything else. 
All I'm getting them on is require()'ed files in the 
current directory.  Also, I looked at the lxr database in 
MySQL... and it's completely empty.  Perhaps this is 
evidence that genxref didn't do quite what it was supposed 
to? :)

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

Comment By: Joseph Wilhelm (tarken)
Date: 2001-09-17 12:53

Message:
Logged In: YES 
user_id=326177

Actually I got this fixed on my copy by making the line 
look like this:
    @versions = eval($config->{variables}{v}{range});
Instead of:
    @versions = @{$config->{variables}{v}{range}};

And it's working perfectly now :)

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

Comment By: Peder O. Klingenberg (pok)
Date: 2001-08-20 11:17

Message:
Logged In: YES 
user_id=222352

See patch 453450.

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

Comment By: Peder O. Klingenberg (pok)
Date: 2001-08-20 10:59

Message:
Logged In: YES 
user_id=222352

No, it doesn't work at the moment, because genxref is
broken.  I have fixed it, but the patch has not been
committed yet.  Your hunch is correct, it's intended to be
called per file.

Stay tuned.

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

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

[Lxr-dev] [ lxr-Bugs-471857 ] Failure checking of ectags broken

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

Bugs item #471857, was opened at 2001-10-16 13:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=471857&group_id=27350

Category: Lang support
Group: current cvs
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Per Kristian Gjermshus (pergj)
Assigned to: Per Kristian Gjermshus (pergj)
Summary: Failure checking of ectags broken

Initial Comment:
In Generic.pm exuberant-ctags is opened as a pipe with
open().
The the return value of open is checked, but this only
checks if
the fork creating the process was successful. If there
is no
ectags installed or if the invocation went wong no
sensible
error message is displayed. The return value of the
process
should be checked more carefully.

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

Comment By: Malcolm Box (mbox)
Date: 2001-10-17 17:22

Message:
Logged In: YES 
user_id=215386

The implicit fork version of open is "|-" which we don't
use, we use the straight pipe open.  Testing this with

open X, "/usr/bin/not_there" or die "Failed";

reliably prints "Failed" rather than having the fork
succeed.

According to perldoc -f open, there is no more information
in the return value of open() that we could check - it's
undefined if it failed, non-zero (and the pid of the child)
if it succeeded.

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

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

[Lxr-dev] [ lxr-Bugs-474444 ] exuberant ctags options

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

Bugs item #474444, was opened at 2001-10-24 05:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=474444&group_id=27350

Category: Lang support
Group: current cvs
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: exuberant ctags options

Initial Comment:
With:
Exuberant Ctags 3.2.4,

--lang=c
is in the info-page.

However,

Index: lib/LXR/Lang/Generic.pm
===================================================================
RCS file: /cvsroot/lxr/lxr/lib/LXR/Lang/Generic.pm,v
retrieving revision 1.5
diff -r1.5 Generic.pm
69c69
<                                       
"--language-force=$langforce",
---
>                                       
"--lang=$langforce",

--language-force generates a silent error
where genxref continues blindly without
storing anything in indexes or symbols.

--fortran-types=+L also breaks. If labels
are the point, capital L should probably be
common l.


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

>Comment By: Malcolm Box (mbox)
Date: 2001-10-24 08:30

Message:
Logged In: YES 
user_id=215386

lxr works with exuberant ctags version 5 or above, where the
options that are used match those in lxr.

I suggest upgrading your ctags installation to make lxr work
properly.

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

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

[Lxr-dev] [ lxr-Bugs-474444 ] exuberant ctags options

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

Bugs item #474444, was opened at 2001-10-24 05:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=474444&group_id=27350

Category: Lang support
Group: current cvs
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: exuberant ctags options

Initial Comment:
With:
Exuberant Ctags 3.2.4,

--lang=c
is in the info-page.

However,

Index: lib/LXR/Lang/Generic.pm
===================================================================
RCS file: /cvsroot/lxr/lxr/lib/LXR/Lang/Generic.pm,v
retrieving revision 1.5
diff -r1.5 Generic.pm
69c69
<                                       
"--language-force=$langforce",
---
>                                       
"--lang=$langforce",

--language-force generates a silent error
where genxref continues blindly without
storing anything in indexes or symbols.

--fortran-types=+L also breaks. If labels
are the point, capital L should probably be
common l.


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

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

[Lxr-dev] [ lxr-Bugs-471858 ] Some characters in files create trouble

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

Bugs item #471858, was opened at 2001-10-16 13:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=471858&group_id=27350

Category: Browsing
Group: current cvs
Status: Open
Resolution: None
Priority: 5
Submitted By: Per Kristian Gjermshus (pergj)
Assigned to: Per Kristian Gjermshus (pergj)
Summary: Some characters in files create trouble

Initial Comment:
I have a directory in my source-tree containing the
string
'c-++'. It is not possible to browse these directories.



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

>Comment By: Malcolm Box (mbox)
Date: 2001-10-23 07:16

Message:
Logged In: YES 
user_id=215386

Looks like this is caused by the httpwash function being over-zealous at stripping out characters.

Perhaps we can get away with not washing variables - it seems that there are few dangerous calls that use web-provided parameters, and we could simply check at these places for troublesome characters, rather than globally restrict them.

This is related to the glimpse RE bug as well

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

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

Re: [Lxr-dev] httpclean error

[Malcolm B. <ma...@br...>]

Hi Joseph,

Joseph Wilhelm wrote:

> [Thu Oct 18 10:45:42 2001] [error] Bareword "httpclean" not allowed 
> while "strict subs" in use at /.../lxr/source line 305.
>
>  
>
> I haven't had a chance to look into this error yet, but has anybody 
> else seen this error, or might know where it comes from? (I also tried 
> restarting Apache to make sure there were no hanging modules that 
> might be causing this)
>
 The error message means that you cannot call a subroutine that has not 
been defined yet with "strict subs" is in operation.  However, Common.pm 
does define this subroutine and export it, so there should be no problems.

I've seen this and it seems to be caused by having an old version of 
Common.pm loaded in the web server.  For me, restarting Apache cured the 
problem.

You could check that the @EXPORT_OK array in Common.pm does include 
httpclean in case somehow the CVS update has not worked correctly.

Cheers,

Malcolm

[Lxr-dev] httpclean error

[Joseph W. <jwi...@ou...>]

I just did an update from CVS, set up my config again, and found the
following error as soon as I hit LXR on the web:

[Thu Oct 18 10:45:42 2001] [error] Bareword "httpclean" not allowed while
"strict subs" in use at /.../lxr/source line 305.

I haven't had a chance to look into this error yet, but has anybody else
seen this error, or might know where it comes from? (I also tried restarting
Apache to make sure there were no hanging modules that might be causing
this)

--Joseph Wilhelm

Re: [Lxr-dev] $baseurl wierdness

[Jens-Uwe M. <ju...@he...>]

On Thu, Oct 18, 2001 at 08:51:23AM +0900, Malcolm Box wrote:
> Jens-Uwe Mager wrote:
> > 
> > I have had some problems getting the style sheet version of lxr going,
> > and the problem appears to be the following in html-head.html:
> > 
> > <base href="$baseurl" >
> > 
> > In my case I always get what looks like $thisurl substituted. If I put
> > in a fixed URL to my LXR installation it works fine.
> 
> $baseurl comes from the lxr.conf file - does your lxr.conf set up the
> right value?

Yes, definitely. It looks like this:
'baseurl'          => 'http://ans.helios.de/local/dev/lxr',
'virtroot'         => '/local/dev/lxr',


> Does the rest of your configuration work OK?  I've had odd problems when
> the $baseurl in the config file didn't match the URL that Apache was
> feeding in (FQDN v IP address usually), and that caused all sorts of
> strange symptoms.  If $baseurl is not set up properly, most stuff should
> be failing.

If I display the source to source in my browser I get:

<!-- <base href="http://ans.helios.de/local/dev/lxr/source/" > -->
<base href="http://ans.helios.de/local/dev/lxr/" >
<link href="templates/lxr.css" rel="STYLESHEET" type="text/css">

And my template looks like this:

<!-- <base href="$baseurl" > -->
<base href="http://ans.helios.de/local/dev/lxr/" >
<link href="$stylesheet" rel="STYLESHEET" type="text/css">

All the other URL's generated by the perl code look fine. All the fixed
URL's by the way spoil any attempts to use lxr via SSL, by the way. I
did for some previous version of lxr an ugly hack, but in the current
state I have not yet tried to make SSL work again.

-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	ju...@he...