ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66906
|
Wed Sep 15 01:54:56 2010 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Linux | All | 2.8.0-2313 | Re: Searching Logbooks | Hi Stefan,
I was rather hoping that was *not* going to be your answer.
I much prefer the plain ascii file format, for it allows me to edit it for "mistakes" post submission,
shall we say.
> > Hi Stefan,
> >
> > I'm starting to get a similar problem to Lance's ("SQL Database"). Searching is beginning to take time.
> >
> > In searching, I either can search one logbook (still relatively quick), or all of them.
> >
> > I have my logbooks in groups, and often I know which group I want to search, and it would make the searching
> > much quicker were the search confined to just that group. I don't think I've missed anything in the
> > documentation on this matter.
> >
> > If not a change to the elog program, is there another way of (say) arranging the logbooks that will achieve this?
>
> You can't do that right now. I would have to extend the functionality to allow searching in groups. Also have a look
> at https://midas.psi.ch/elogs/Forum/66901. Maybe that helps a bit in meantime. |
66993
|
Wed Jan 19 18:19:49 2011 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Windows | V2.8. | Re: Modification aren't accepted |
bob wrote: |
Stefan Ritt wrote: |
bob wrote: |
hello,
At home, when I change the config *. cfg, the modifications are not taken in consideration
Have you got a idea ?
Thanks a lot ! 
Bob
|
Not really, you are the first one reporting this issue. Just some thoughts:
- Can you see the changes if you look at elogd.cfg with a text editor such as notepad?
- Some write protection of elogd.cfg
- Do you have more than one server running at the same time and changing the wrong one's config?
- Stefan
|
>- Can you see the changes if you look at elogd.cfg with a text editor such as notepad?
I change the configuration directly on elogd.cfg, (after i save and update my web page, and i not modification immediately)
>- Some write protection of elogd.cfg
no
- Do you have more than one server running at the same time and changing the wrong one's config?
i have one server with elog
|
Let me report when I see this behaviour.
If I use a text editor on elog.cfg directly, while elog is running, then when I save the file, the new elog.cfg is in place,
but the running elog is still running with the old configuration. You have to restart elog for it to read the new config file and
use the new settings.
This does not apply if you edit elog.cfg via the "config" option in the menu command, where elog will read the new elog.cfg
just after it has been saved.
The reason I sometimes edit the file directly is if I want to create a new logbook, but with all the configuration of another logbook,
and it's quickest to cut-and-paste, change the heading, create a new directory and restart elog.
This may be completely off what is being reported. |
66998
|
Thu Jan 20 18:51:53 2011 |
| David Pilgram | David.Pilgram@epost.org.uk | Request | Linux | 2.8.1-2353 | Wishlist: Roption | Hi Stefan,
Roptions, or Radio Buttons. Do you recall that on old
radios, if you gently pressed a button you could release whichever
button was already in, without selecting the new button; in other
words no selection made.
I'd like this same facility with elog. Now I know that it can be
done by (for example) in the config file preselecting one of the
selections on reply- or indeed one that does not exist to "clear" it,
but in this case that is not the route I'd want to take every time.
What I'd like is a (optional) button along with all the others, which
if you click on it, it will clear any selection for that particular Roption.
At present, once an Roption has been selected, it will persist in all
replies unless or until an alternative choice is made. Alternatively, if
no selection has been made, then there is no selection on the reply, either.
[Unless something in the elog.cfg file].
Regards,
David.
|
67000
|
Fri Jan 21 11:28:02 2011 |
| David Pilgram | David.Pilgram@epost.org.uk | Request | Linux | 2.8.1-2353 | Re: Wishlist: Roption | > > I'd like this same facility with elog. Now I know that it can be
> > done by (for example) in the config file preselecting one of the
> > selections on reply- or indeed one that does not exist to "clear" it,
> > but in this case that is not the route I'd want to take every time.
>
> What about defining an additional option "unspecified". So you have
>
> Roptions attr = option1, option2, option3, none
>
> Whenever you click on "none", the selection is removed from the other options. The HTML standard unfortunately does
> not foresee radio buttons not being selected, so I would have to tweak it somehow to get exactly what you want.
Hadn't realised the standard was written that way.
What you propose seems fine to me.
David. |
67077
|
Thu Jun 2 14:57:39 2011 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 2.7 | Re: editor dosn't work |
Sara Vanini wrote: |
Hi,
when I try to edit an entry of my ELOG, the display shows the editor window blank, without all the previous content of the entry, and it is not possibile to write in it. It worked since yesterday, when ELOG tried to save a new entry but the disk was full. ELOG was srewed up. I deleted the buggy entry and now I can display all the previuos entries, but I cannot edit anymore... Please help!
Sara
|
I've a little experience of digging myself out of (in my case, self-induced) problems using ELOG. I'm also aware that I may be the least experienced/qualified user..
First: Archive your work directories. Then at least whatever you do from here, you've got the status quo to fall back on. Also, record anything you can remember (ID number, thread, etc) of the deleted entry/entries.
I've found that ELOG can hang in an infinite loop if it tries to find an entry that is no longer there - and that depends upon how you approach the point where the missing entry would be. ELOG's own delete works fine in normal circumstances. I'm talking about abnormal circumstances, for example when idiots (me) are playing around with the yymmdda.log files, or *possibly* if the disk is full, and you then try deleting the entry that caused the full disk problem. Whether that is what you are seeing, I cannot say at present.
However, to progress this: When you are stuck, unable to edit anything, in a[nother] terminal, try the process report
ps -A
two or three times, with a short interval between commands. (Or other switches if you know how to select to view the elogd process on your system). If elogd is using seconds of CPU time between each ps command, it's probably in an infinite loop. If you need to be sure, wait a minute and check again. If so, you'll have to stop the daemon, possibly requiring a computer reboot. In my experience, ELOG does not get stuck in an infinite loop when just indexing the pages when the daemon starts, but experts may well know better.
This may at least diagnose whether you cannot edit because ELOG is stuck in an infinite loop, or has some other cause.
If it is the infinite loop, the trick is to find which entry causes the loop without getting stuck in that loop next time around.
David Pilgram. |
67079
|
Thu Jun 2 20:20:19 2011 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 2.7 | Re: editor dosn't work |
Sara Vanini wrote: |
David Pilgram wrote: |
Sara Vanini wrote: |
Hi,
when I try to edit an entry of my ELOG, the display shows the editor window blank, without all the previous content of the entry, and it is not possibile to write in it. It worked since yesterday, when ELOG tried to save a new entry but the disk was full. ELOG was srewed up. I deleted the buggy entry and now I can display all the previuos entries, but I cannot edit anymore... Please help!
Sara
|
I've a little experience of digging myself out of (in my case, self-induced) problems using ELOG. I'm also aware that I may be the least experienced/qualified user..
First: Archive your work directories. Then at least whatever you do from here, you've got the status quo to fall back on. Also, record anything you can remember (ID number, thread, etc) of the deleted entry/entries.
I've found that ELOG can hang in an infinite loop if it tries to find an entry that is no longer there - and that depends upon how you approach the point where the missing entry would be. ELOG's own delete works fine in normal circumstances. I'm talking about abnormal circumstances, for example when idiots (me) are playing around with the yymmdda.log files, or *possibly* if the disk is full, and you then try deleting the entry that caused the full disk problem. Whether that is what you are seeing, I cannot say at present.
However, to progress this: When you are stuck, unable to edit anything, in a[nother] terminal, try the process report
ps -A
two or three times, with a short interval between commands. (Or other switches if you know how to select to view the elogd process on your system). If elogd is using seconds of CPU time between each ps command, it's probably in an infinite loop. If you need to be sure, wait a minute and check again. If so, you'll have to stop the daemon, possibly requiring a computer reboot. In my experience, ELOG does not get stuck in an infinite loop when just indexing the pages when the daemon starts, but experts may well know better.
This may at least diagnose whether you cannot edit because ELOG is stuck in an infinite loop, or has some other cause.
If it is the infinite loop, the trick is to find which entry causes the loop without getting stuck in that loop next time around.
David Pilgram.
|
Hi David,
you have been very helpful indeed. The problem was the one you spot, I've deleted the buggy entry removing the ***.log file, and this caused disaster..... now it is working again, thanks a lot, I have all my PhD thesis in ELOG....
Sara
|
Don't get too excited yet!
When you reply to an entry in ELOG, then some additional data is added to that original entry.
So, if you reply today (say 02/06/11) to an entry made yesterday, then you will find that the file 110602a.log has a large change (the new entry in full, plus elog extra codes), *and* an additional line added into 110601a.log. Deleting 110602a.log will not remove the line in 110601a.log, and that could still cause problems, that is, wandering into an infinite loop.
To save a lot of effort, I'll suggest that you (a) keep the back-ups up to date, and keep two (the latest and the one before that); (b) proceed carefully at least to start with. If you fall into the infinite loop again, then flag it up and I (or someone else) will be able to give further pointers.
David Pilgram.
So unless you are sure that |
67087
|
Wed Jul 6 12:36:33 2011 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 2.9.0-2413 | Re: ELOG deamon stuck in find_thread_head() |
Soren Poulsen wrote: |
Soren Poulsen wrote: |
soren poulsen wrote: |
ELOG seems to enter a loop when you do certain opeations on certain messages: I moved a message to a different logbook and the deamon just gets stuck.
If I restart the daemon, the message was in fact moved: I can move it back to its original destination without problems.
I started in GDB and break with ctrl-C when the process gets stuck, to be told :
Program received signal SIGINT, Interrupt.
0x000000000040a968 in find_thread_head ()
I then made a core dump.
I put the files here: http://cern.ch/poulsen2/elog-error-report-110430.zip (they are too big to upload).
I get into the same problem in other circumstances such as when opening some threads (maybe because they contain "Reply-to" references to non-existing messages, but I have problems reproducing this on the test installation.
I should maybe also submit the incriminating thread.
Soren
|
1. It appears that some times find_thread_head is called with message references that do not exist. That is not good.
I put in a little check like this before seeing if the message has an "in_reply_to" reference:
The line:
if (lbs->el_index[i].in_reply_to)
becomes:
if (i < *lbs->n_el_index && lbs->el_index[i].in_reply_to)
2. The trouble started when I deleted a message in the middle of a thread, which left the thread badly "connected" (references to a deleted message).
3. Also, when a thread is badly connected, it is a problem moving messages to a different logbook. ELOG complains that it cannot access the message (with the invalid reference). But ELOG should ignore it, since the message was deleted.
Soren
|
It would be nice to have this corrected. The problem occurs when you select (read) a message which refers to another message via "In-reply-to", and this message does not exist.
Soren
|
Soren, you're not alone! I've had similar problems, as did Sara Vanini (elog:67077).
In my case, it is because the "move" or "copy" function does not move all the messages in very long threads. To be more precise, elog will crash in the attempt to move a long thread - say over 40 replies, I don't know for sure. Sometimes it has already moved the entire thread before it crashes, sometimes not. I'd not flagged it up as an issue because I could not be sure it was not a memory issue with the old (>12 years) linux box I was using earlier this year, but it still happens on this new (to me, only 3 years old) linux box.
Whether it is the number of entries, the total memory size of the thread or some combination, I don't know.
I've found that in the "move" case, it has not deleted all the messages from the donor thread, so that there is a semi-thread still hidden there. Should one by chance select that semi-thread, (because it is found during a search) elog goes into infinate loop, which requires a reboot of this linux box to fix. Certainly the pinning down the issue to the missing entry referenced by an <i>In reply to:</i> explains this part of the issue. Of course, deletion of one entry within a thread, or other adjustments will do the same thing, just as you (Soren) point out above.
If it happens to me, I will go in to the yymmdda.log files and fix the problem, be it deleting the entries of the semi-thread, moving across missing entries from the donor to the acceptor logbooks, adjusting the <i>Reply:</i> and <i>In reply to:</i> lines, but that is quite a time consuming and error prone exercise. |
67088
|
Wed Jul 6 12:45:19 2011 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | All | 2.9.0-2411 | Attachments in a different logbook to the entry logbook | Is it possible to have an attachment to an entry in a different directory to the working directory of the logbook being used?
By which I mean, if you have in logbook hidden the attachment files
../logbooks/hidden/110705_235520_whatthis-0.png
../logbooks/hidden/110705_235520_whatthis.pdf
that an entry in another logbook, public, can use the entries in hidden to show them (and do everything that you can do with an attachment)
without making another copy in public?
I see that if, working in public, you attach the .pdf file in hidden, the files get copied across as
../logbooks/public/110705_235520_whatthis-0.png
../logbooks/public/110705_235520_whatthis.pdf
that is, with the original (hidden) timestamp, and no second time stamp superimposed. From which you can gather I've been playing around, manually editing a yymmdda.log file to try and get the result I want, even if for the moment it cannot be done via elog; but without success, although there were some bizarre interpretations by the elog program of the edited yymmdda.log file, depending upon what I tried.
For one entry, it is of course no big deal, copying the files into the public directory, but if you are dealing with multiple huge entries, it does seem wasteful of HD space
But my reason for this is that hidden has restricted access, whereas public has general access. The attachments themselves are not restricted, but comments, history etc around them in the restricted access logbook should not become available to the general viewer. |
|