exit status of elog, posted by Heiko Scheit on Thu Jul 4 17:09:09 2002
|
The exit status of elog is always 1. It should be zero for
a successful submission. |
Re: Participation on development of ELOG, posted by Heiko Scheit on Wed Feb 19 14:48:56 2003
|
> > We are interested in using your ELOG (which we consider to be a wonderful
> > application) even more. We would like to make a few adaptations in your
> > source code, above all to add some functionality that we are missing.
> >
> > I was wondering if there is a way we could coordinate the development
> > together. For instance, would it be of your interest to receive the code
> > adaptations we do and implement it in your future releases?
>
> Sure, I'm very interested in those and ready to merge it into the main
> development tree.
>
> - Stefan
I think it is very good to include this in elog, but,
since this is also a big security risk (especially if people are
running elogd as root) I would suggest a compile time option to
enable this, like: gcc... -DALLOW_SCRIPT ...
The default should be that it is disabled.
Maybe one should only allow it if the user running elogd is NOT root.
Heiko |
missing '.' in emails, posted by Heiko Scheit on Wed May 7 16:04:45 2003
|
missing '.' in emails
-----------------------
A dot '.' at the beginning of a line is not transmitted via email.
It is stored in the entry properly though.
Test:
./There is a dot just before '/There...'
Greetings, Heiko
Well it seems here it is working fine...
. |
not proper HTML, posted by Heiko Scheit on Thu Jul 31 16:02:41 2003
|
I just upgraded from 2.3.5 to 2.3.9.
There are some errors in the generated HTML. Most of the time
the browser renders everything correctly but sometimes not. Please
check especially (http://validator.w3.org/):
- http://midas.psi.ch/elogdemo/Database/7
There are too many <table> tags before the attribute list:
'Type', 'Operating system',... This should be just one table and
not each row a separate table. Also the first <table> tag lies
outside a <td> tag of the enclosing table.
- http://midas.psi.ch/elogdemo/forum/ |
problem with boolean attributes, posted by Heiko Scheit on Fri Aug 1 13:18:42 2003
|
Boolean attributes were not displayed correctly in version 2.3.9.
Patch is attached. |
width of the textarea is too large (after reply), posted by Heiko Scheit on Mon Aug 4 14:02:52 2003
|
The width of the textarea after pressing reply is too large.
The problem is that the algorithm that searches for the longes line
looks for the next '\r' which it does not find and therefore takes the
number of characters in the text to be the width of the longest line.
To search for '\n' instead should solve the problem. Please find the
diff output below.
$ diff -c elogd.c elogd.c~
*** elogd.c Mon Aug 4 13:57:35 2003
--- elogd.c~ Fri Aug 1 13:13:09 2003
***************
*** 6028,6035 ****
p = text;
do
{
! /* pend = strchr(p, '\r'); */
! pend = strchr(p, '\n');
if (pend == NULL)
pend = p+strlen(p);
--- 6028,6034 ----
p = text;
do
{
! pend = strchr(p, '\r');
if (pend == NULL)
pend = p+strlen(p);
|
speed is very slow if logbook contains many entries, posted by Heiko Scheit on Wed Nov 12 12:25:44 2003
|
This is not really a bug, but elogd was getting really slow with our
logbook. It took about 4 1/2 seconds just to get the default page in
threaded mode with 15 entries. The logbook has in total about 2000
entries, though.
After playing around with the compiler option '-gp' and gprof the
problem was found: loc() is called about 18000 times per logbook
access! (Attached you can find the gprof output. There might be
other places where to save time: e.g. getcfg().) The function loc()
calls stat every time to check if the language file was updated and
this takes a long time especially over NFS.
The quick solution for me was to just replace loc() with 'char
*loc(char *orig) {return orig;}'. Therefore, I cannot use the
localization that I used anymore, which is not a big problem at the
moment. After that the time to download the default page was only
0.16 s; almost a factor of 30 faster!
I would suggest to only read the language file (AND also the config
file!) once upon startup. After changing things one has to restart
elogd, which is not so nice, but the long delay is not acceptable.
Another option not to restart elogd is to make elogd respond to a
signal (e.g. kill -HUP) to reread the config and language files. |
segmentation fault, posted by Heiko Scheit on Fri Feb 13 12:18:19 2004
|
Around line 2240 (in loc()) in elogd.c the following is written,
which results in an infinite loop, since loc() recursively with
the same argument "Change %s".
/* special case: "Change %s" */
if (strstr(orig, "Change ")) {
sprintf(result, loc("Change %s"), orig + 7);
return result;
}
For now I just commented these lines. |