ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
617
|
Thu Jul 22 16:50:19 2004 |
| Todd Corsa | tcorsa@bnl.gov | Bug report | Linux | 2.5.3 | Bugs in newer updates w/ Debian install? |
I just updated ELOG using the latest elogd.c, and now my Quick Filters seem
to stop working after the first or second filter attempt. I find that if I
allow fewer quick filter options it seems to work more consistently. For
example:
Example 1-
Quick filter = Date
The date filter will work without a problem no matter how many times I use
it.
Example 2-
Quick filter = Date, Category, Status, Priority
The first filter I use will work, but upon trying a new filter, or just a
new option in the same filter, all options return to "All Entries" and no
filter options have any effect on the view.
If I exit the log book, and come back in, it works for the first filter
attempt, then stops again.
This used to work fine prior to the update. I should also mention that the
original installation of ELOG was from the Debian package. At that point,
nothing was where the documentation said it should be (e.g. elogd.cfg was
called elog.conf and was placed in the /etc/ directory). Everything worked
fine, so I left it alone. When I recompiled with the newer elogd.c,
anything that required a path was hosed, so I now have to specify the
resource directory and the path to the conf file when starting ELOG. I
don't know why this would affect the Quick Filter, and I'd assume that it
would just stop working all together. Also, when I recompiled using "gcc -
O -o elogd elogd.c", I received the following warning:
elogd.c:546: warning: conflicting types for built-in function `logf'
Any suggestions?
Thanks!
Todd |
618
|
Tue Jul 27 17:56:56 2004 |
| Ulrich Trüssel | ulrich.truessel@familienhund.ch | Bug report | Windows | 2.5.3 snap | List Dispaly produces wrong output in 2.5.3 built 23.7.04 (snapshot) |
I did not have the following problem in any snapshot before 23.7.04 .
Actually I do not have a possibility to test the snapshot under an other
system than win xp pro sp 1 (fully pached).
Using my logbooks as well as the demo logbook works well under older
snapsgots of 2.5.3 as well as long as the "List Display = <attributes>" is
not used!
Using "List Display = <attributes>" produces an ususal output with the text
field content in the first row and a row title of the first 3 letters.
Ex.:
Attributes = Customername, Customeraddres
List Display = Customername, Customeraddres
Output:
¦Cus¦Customeraddres¦
If no record is in the logbook, only the "Cus" is dispalyed! Removing "List
Display = <attributes>" produces a normal output with same logbook!
By the way: Thnak's for the Format in the entry/edit view!!! |
619
|
Tue Jul 27 18:33:52 2004 |
| Fred Hooper | fhooper@sushisoft.com | Bug fix | Linux | 2.5.3 | speeding up elog : gcc compile optimizations |
Elog is a great program, but it can be slow.
I noticed that the gcc compiler options in the tarball Makefile were not
conducive to speed. There, I tried changing the gcc options to:
CFLAGS = -O3 -funroll-loops -fomit-frame-pointer -W -Wall
for version 2.5.3, the compile worked, and the program appears to work as
normal, but a bit faster. I have not benchmarked it, but I think it should
offer a nominal increase in speed.
In particular, I removed the "-g" profiling option, which is not needed for
production code, and can be safely removed. In addition, I put in slightly
aggressive optimization settings, so if this doesn't work for you, you can
first try removing the -f setting, and then backing off the optimization to -O2.
Other may want to post other settings that work for them. |
622
|
Wed Jul 28 15:03:17 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug fix | Linux | 2.5.3 | Re: speeding up elog : gcc compile optimizations |
> I noticed that the gcc compiler options in the tarball Makefile were not
> conducive to speed. There, I tried changing the gcc options to:
>
> CFLAGS = -O3 -funroll-loops -fomit-frame-pointer -W -Wall
Thank your for this hint, I changed my Makefile for the production code. However, I
could not feel any difference between the two options. The real problem is the
function getcfg(), which gets called many thousand times internally and has to parse
elogd.cfg each time. Once I implement a hash table for that function, elogd should
become faster by at least a factor of two. |
624
|
Wed Jul 28 18:25:32 2004 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.5.4? | getcfg problem in v1.410: Truncation of long config strings |
Just compiled 1.410 and have run into an issue that *may* have been
introduced in 1.393.
Config file directives such as "Welcome title" could be very long strings.
After compiling 1.410, our "Welcome title" is truncated and, while I haven't
counted the actual chars, I suspect that the truncation happens at 1024
characters. The procedure 'getcfg' has a declared passed paramater "int
vsize".
I haven't looked to see if this effects any other large configuration
strings that are managed by "getcfg" but this procedure is perhaps the most
popular one by far in elog. |
628
|
Wed Jul 28 21:39:21 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 2.5.3 | Re: BUG?: Preset text = causes replication of text when re-editing a logbook entry. |
> With the "Preset text = " specified, when re-editing a logbook entry (say to
> correct a spelling error) the text of the "Message" is replicated and placed
> directly below the original text.
That should be fixed since revision 1.370 from Jul 7th, 2004. Please update. |
637
|
Fri Jul 30 02:03:59 2004 |
| Guenter Nowak | Guenter.Nowqak@t-systems.at | | | | ?cmd=New&pType=PC does not work |
according to the users guide,
http://midas.psi.ch/elogs/Database/?cmd=New&pType=PC
should create an entry with the type value set to PC, but this doesn't work |
640
|
Sat Jul 31 16:55:21 2004 |
| Fred Hooper | fhooper@sushisoft.com | Bug fix | Linux | 2.5.3 | Re: speeding up elog : gcc compile optimizations |
> > I noticed that the gcc compiler options in the tarball Makefile were not
> > conducive to speed. There, I tried changing the gcc options to:
> >
> > CFLAGS = -O3 -funroll-loops -fomit-frame-pointer -W -Wall
>
> Thank your for this hint, I changed my Makefile for the production code. However, I
> could not feel any difference between the two options. The real problem is the
> function getcfg(), which gets called many thousand times internally and has to parse
> elogd.cfg each time. Once I implement a hash table for that function, elogd should
> become faster by at least a factor of two.
Yeah - What's up with that?
I have seen this discussed before - Seems like it should be a priority to get this
fixed, as doing a hash table is straightforward, and the speed increase should be pretty
health - there are several c libraries available - check out "man 3 hsearch" for the
POSIX hash table management that already available. Other c library searches that you
could use include bsearch (binary tree), tsearch (tree searching), btree (b+ tree).
However, the easiest and most obvious one to use for elog appears to be a simple hash
table search (hsearch).
Is there something else which is making this difficult to do? |