Re: compiling elog on AMD64, posted by Heiko Scheit on Sun Nov 21 00:46:28 2004
|
> > When compiling elogd on AMD64 (in 64 bit mode) there are many
> > warnings like these:
> >
> > src/regex.c:3769: warning: cast from pointer to integer of different size
> > src/regex.c:3769: warning: cast from pointer to integer of different size
> > src/regex.c:3775: warning: cast to pointer from integer of different size
> >
> > The reason is the (int) cast, which (I think) is not necessary.
>
> Unfortunately I don't have a 64-bit compiler to try. Can you please check if
> elogd.c has similar warnings or only regex.c?
elogd.c shows the same warnings.
> The ones in elogd.c I can fix,
> but regex.c is straight from the GNU C library, so we would have to wait intil
> they fix it. Or can you get it from the 64-bit C library? The point is that I
> need the source code, so that I can compile it under Windows as well. Can you
> try to compile elogd without regex.c, like
>
> gcc -g -O -W -Wall -o elogd src/elogd.c
This works OK.
|
implement 'hide attribute' and 'sort attribute', posted by Heiko Scheit on Thu Dec 2 14:39:50 2004
|
Could you implement a 'hide attribute' and 'sort attribute' config option?
While sort is probably not so easy to do the hide option would already
be very useful. What I want to do is to use elog to collect bibtex entries
which are then used to generate a bibtex file. So, e.g. if the entry
type 'Article' is selected I would like that all fields that do not make
sense are hidden. Currently I just lock them. The config looks like
this:
Attributes = Login, Bibtex Key, Entry Type, Address,
Annote, Author, Booktitle, Chapter, Crossref, Edition, Editor, Howpublished,
Institution, Journal, Key, Month, Note, Number, Organization, Pages,
Publisher, School, Series, Title, Type, Volume, Year, URL, Short Comment
Options Entry Type = Article{1}, Book{2}, Booklet{3}, InBook{4},
InCollection{5}, InProceedings{6}, Manual{7}, MastersThesis{8}, Misc{9},
PhDThesis{a}, Proceedings{b}, TechReport{c}, Unpublished{d}
Required Attributes = Entry Type
; ARTICLE
{1} Comment Author = [required]
{1} Comment Journal = [required]
{1} Comment Title = [required]
{1} Comment Year = [required]
{1} Locked Attributes = Address, Annote, Booktitle, Chapter, Crossref,
Edition, Editor, Howpublished, Institution, Key, Organization, Publisher,
School, Series, Type
Instead of Locking the attributes, hiding them altogether would make the
entry form look much nicer.
A further improvement would be to sort the attributes, e.g. for author I
would sort the like this, i.e. the more important entries first:
{1} Sort Attributes = Author, Title, Journal, Volume, Pages, Year, Month,
Number, Note
Attributes not mentioned in the sort line could then be displayed
in any order. |
forum entries not displayed in correct order, posted by Heiko Scheit on Sun Dec 19 16:55:03 2004
|
I just submitted a reply to elog:847 (the reply is elog:853).
Normally the thead containing the reply should now be listed as
the top thread. Instead only the original message of the thread
(elog:820) is listed but the remaining messages in the thread are not
listed. It seems the problem is that for elog:820 the 'reply to this'
header is missing. And elog:820 and elog:824 are the same messages
except that for elog:824 the subject is missing. Actually ALL attributes
for elog:824 are missing.
I guess you could fix things up if you:
- add 'reply to this: 823' to elog:820
- remove entry elog:824 |
admin menu, posted by Heiko Scheit on Sun Dec 19 17:11:07 2004
|
Could you implemet and option 'admin menu' which gets displayed
when an 'admin' is logged in. This menu could e.g. also include 'Delete'
while the normal menu would not. |
Re: implement 'hide attribute' and 'sort attribute', posted by Heiko Scheit on Mon Jan 10 19:44:16 2005
|
> > Could you implement a 'hide attribute' and 'sort attribute' config option?
>
> I implemented it as 'hidden attributes = <list>' and 'sort attributes'.
'sort attributes' sorts the logbook entries when they are displayed. Or?
What I want is to rearrange the entry mask. E.g. if 'Entry type' article is
selected then the attributes 'Author', 'Journal', 'Title', and 'Year'
should be listed first, as they are required for this bibtex entry type.
Is it possible with the current elogd version to also sort (rearrange) the
attributes in the entry mask? If yes, how?
Thanks for your time. |
Re: implement 'hide attribute' and 'sort attribute', posted by Heiko Scheit on Mon Jan 10 20:52:13 2005
|
> > 'sort attributes' sorts the logbook entries when they are displayed. Or?
>
> Right
>
> > What I want is to rearrange the entry mask. E.g. if 'Entry type' article is
> > selected then the attributes 'Author', 'Journal', 'Title', and 'Year'
> > should be listed first, as they are required for this bibtex entry type.
> > Is it possible with the current elogd version to also sort (rearrange) the
> > attributes in the entry mask? If yes, how?
>
> Attributes are shown in the order you specify them in the config file, so what about
>
> Attributes = Entry type, Author, Journal, Title, Year ???
Because for 'Entry type'='InProceedings' one needs:
'Author', 'Title', 'Booktitle', 'Year', 'Volume', 'Number'.
So, depending on the entry type that was chosen the entry mask should change,
with the required fields first and the not valid fields should not be shown
at all, which can nicely be done with the 'hidden attributes' config option.
Only the sorting (of the entry mask!) is missing! :) |
Problem with 'Show Attributes' option, posted by Heiko Scheit on Sat Feb 19 18:39:52 2005
|
There is a problem with the 'Show Attributes' option
causing the 'Format ...' options to be ignored.
See attachment for patch. |
Segmentation fault when searching for empty regex, posted by Heiko Scheit on Mon Apr 11 13:52:29 2005
|
Segmentation fault when searching for empty regex
--------------------------------------------------
Searching for a regex like 'm*', which also includes zero 'm's, an empty
expression is found indefinitely in 'highlight_searchtext(...)', which
eventually results in an overflow of 'pt1'. The patch below fixes this
particular problem, but I would guess there are many other regular
expressions that would lead to an overflow of 'pt1', so its size
should definitely be checked before every 'strcpy(pt1,...)' and
the loop be aborted accordingly. (Or 'pt1' should be allocated
and enlarged dynamically.)
*** 14777,14782 ****
--- 14777,14784 ----
if (status != REG_NOMATCH) {
size = pmatch[0].rm_so;
+ if (size == 0) break; /* check for zero size -> infinite loop */
+
/* copy first part original text */
memcpy(pt1, pt, size);
pt1 += size;
***************
*** 14788,14795 ****
--- 14790,14799 ----
/* see also rsputs2(char* ) */
if (hidden)
+ /* need to check size of pt1 !!! */
strcpy(pt1,
"\001B\004style=\003color:black;background-color:#ffff66\003\002");
else
+ /* need to check size of pt1 !!! */
strcpy(pt1, "<B style=\"color:black;background-color:#ffff66\">");
pt1 += strlen(pt1);
***************
*** 14802,14814 ****
--- 14806,14821 ----
/* add coloring 2nd part */
if (hidden)
+ /* need to check size of pt1 !!! */
strcpy(pt1, "\001/B\002");
else
+ /* need to check size of pt1 !!! */
strcpy(pt1, "</B>");
pt1 += strlen(pt1);
}
} while (status != REG_NOMATCH);
+ /* need to check size of pt1 !!! */
strcpy(pt1, pt);
} |
|