ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
629
|
Wed Jul 28 21:49:32 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.5.3 | Re: 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.
Can you try if you can reproduce the problem with the current version? I tried
your settings and could not reproduce it. I remember that I fixed some problems
with quick filters, but that was some time ago (Apr 04). If the problem
persists, can you send me your exact elogd.cfg? |
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. |
627
|
Wed Jul 28 21:34:35 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 2.5.3 | Re: Date format problem in "Thread display = " |
> I get the following in my THREADED logbook view:
>
> "Adding new services, planned for 1090519200. Last revised: Thu Jul 15
> 18:03:52 2004"
That should be fixed by the current version. Please update. |
626
|
Wed Jul 28 21:29:28 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | All | 2.5.3 | Re: WISHLIST: Type <attribute> = user |
Acknowledged. Added your vote to the wishlist. |
625
|
Wed Jul 28 21:25:52 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | | Windows | 2.53. | Re: Fixed Attribute Reply |
> Hi Stefan
> YOu have been a great help on the Elog problem solving .
> I have another sort of bug , when i have a attribute type as date.
> And i have fixed the attribute on reply , i actually get a string of
> number when i reply , and the date becomes not the orginal date in the
> first message.
>
> So the way i work ard is that i did not place the date field in the fixed
> attribute reply which i will run the risk of pple modifying that entry .
> Can this be fix?
Yes, I fixed this. Revision 1.412 under CVS, new snapshot for Windows at the
download page. |
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. |
623
|
Wed Jul 28 16:13:04 2004 |
| Ulrich Trüssel | ulrich.truessel@familienhund.ch | Bug report | Windows | 2.5.3 snap | Re: List Dispaly produces wrong output in 2.5.3 built 23.7.04 (snapshot) |
Thank you very much Stefan!!!
Also the horizontal alignement with "Format = 1" looks much better as before
with standard css files! Really great work!
> > 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.
>
> I fixed that problem. Please get the snapshot from July 28th 14:16. |
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. |