ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
642
|
Mon Aug 2 14:56:56 2004 |
| Heiko Scheit | h.scheit@mpi-hd.mpg.de | Bug report | Linux | 2.5.4 | too many <table> tags |
There are too many <table> tags when displaying a singel entry. E.g.
in http://midas.psi.ch/elogs/Config+Examples/1 the row 'Configuration Name'
is not aligned with the others (see attachment).
Looking at the HTML one sees that there are <table> tags for each row
which should not be there:
<tr><td><table width="100%" cellpadding=0 cellspacing=0><tr><td nowrap
class="attribname">Author:</td><td class="attribvalue">
Stefan Ritt </td>
</tr></table></td></tr> |
641
|
Mon Aug 2 09:05:48 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug fix | Linux | 2.5.3 | Re: speeding up elog : gcc compile optimizations |
> Is there something else which is making this difficult to do?
Not really, but hsearch() & Co. are not available under Windows, so I have to extract the
source code from the GNU C libarary or so. Since the last discussion I had lots of other
topics on my to-do list, such as mirroring and cloning, but the speed issue is getting more
and more up on the priority list. |
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? |
639
|
Fri Jul 30 12:26:10 2004 |
| Guenter Nowak | Guenter.Nowqak@t-systems.at | | | | Re: ?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
Thanks! |
638
|
Fri Jul 30 09:15:39 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | | | | Re: ?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
Now it works. Updated elog version under CVS and as a snapshot (see Download Page) |
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 |
635
|
Wed Jul 28 22:33:08 2004 |
| Steve Jones | steve.jones@freescale.com | 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.
Thanks! |
634
|
Wed Jul 28 22:32:39 2004 |
| Steve Jones | steve.jones@freescale.com | 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.
Thanks! |