ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67364
|
Mon Oct 29 17:27:12 2012 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Info | Windows | latest | Re: Comment avoir elog en français II [solved almost] |
David Pilgram wrote: |
May I make a suggestion here? Something I do for other reasons. I run two separate elog daemons, each with their own configuration files. In this case you could have one configuration file tout en française, and the other in English. This gets around the language setting being in the Global section of the configuration file elog.cfg
Of course this needs a little planning, for example a small script/batch file to start up each daemon with the correct config file. - so on my linux system, I start one with
/usr/local/sbin/elogd -p 8080 -c /home/logbooks/elogd0.cfg -d /home/logbooks
and the other with
/usr/local/sbin/elogd -p 8081 -c /home/logbooks/elogd1.cfg -d /home/logbooks
The disadvantage is that you cannot click between French and English by the tabs along the top of the elog page, you'd have to switch between browser windows.
Hope this helps.
David.
|
Does this work nice and stable for you? I've tried at the beginning to run two server on one host, one in German and the other in English.
I experienced occasional server crashes (every few days) and assumed that they were related to two mirrors running on the same host.
A mirror server just for a second language was not of big importance to me, therefore I did shut down the mirror server.
And the server stopped crashing then. Was that just coincidence?
I recognised that you are not running a mirror, you let both logbook processes access the same data. Is that save?
Did you ever see data corruption from two processes modifying the same data? Or is one of the ELOG servers not used much?
Thanks for sharing your experience!
Andreas
⇄
Detect language » English
|
67365
|
Mon Oct 29 19:10:37 2012 |
| David Pilgram | David.Pilgram@epost.org.uk | Info | Windows | latest | Re: Comment avoir elog en français II [solved almost] |
Andreas Luedeke wrote: |
David Pilgram wrote: |
May I make a suggestion here? Something I do for other reasons. I run two separate elog daemons, each with their own configuration files. In this case you could have one configuration file tout en française, and the other in English. This gets around the language setting being in the Global section of the configuration file elog.cfg
Of course this needs a little planning, for example a small script/batch file to start up each daemon with the correct config file. - so on my linux system, I start one with
/usr/local/sbin/elogd -p 8080 -c /home/logbooks/elogd0.cfg -d /home/logbooks
and the other with
/usr/local/sbin/elogd -p 8081 -c /home/logbooks/elogd1.cfg -d /home/logbooks
The disadvantage is that you cannot click between French and English by the tabs along the top of the elog page, you'd have to switch between browser windows.
Hope this helps.
David.
|
Does this work nice and stable for you? I've tried at the beginning to run two server on one host, one in German and the other in English.
I experienced occasional server crashes (every few days) and assumed that they were related to two mirrors running on the same host.
A mirror server just for a second language was not of big importance to me, therefore I did shut down the mirror server.
And the server stopped crashing then. Was that just coincidence?
I recognised that you are not running a mirror, you let both logbook processes access the same data. Is that save?
Did you ever see data corruption from two processes modifying the same data? Or is one of the ELOG servers not used much?
Thanks for sharing your experience!
Andreas
⇄
Detect language » English
|
I'd better put some caveats in here, then!
The two daemons on my host were never accessing the same subdirectories of /home/logbooks (this is my location, for ease of data backups (*)), and they were running with owner 'nobody', i.e. that's the owner of each directory. In that sense they were independant, and as I was the only user, only one daemon would be working on files at any one moment.
Next is that my system is never running for so many days uninterrupted. The computer sometimes has to be booted into Windoze to use the CAD program, or even was just shut down and switched off.
I realise now that my earlier reply may have lead people to think they could work on the same data with two separate daemons (so as to work in their own language, but the data would be in both....) but I never meant to give that impresssion. I've simply not tried it. It might work on a stand-alone system, but I don't know how elog copes with multiple users accessing data at the same time - lock files? check to see if data has been altered before allowing a submission is probably not done (it would make a branch if branches were allowed, I think) - I don't have the experience of using elog under these circumstances. I thought Philippe Rousselot wanted a French language logbook and a separate English language one. If I'm wrong there, sorry to raise his hopes.
Make a nice little project for someone to explore the limits, and maybe find what changes are needed. Not necessarily to impliment it, though.
As for data corruption, never seen any, but I suppose the general warning of keep the backups well up-to-date. I have had trouble with data, in particular moving data between logbooks, and this is one reason I have experience of how to make an elog entry using a text editor, as well as how to modify entries - to assemble scattered entries into a thread, or split a long thread into two shorter ones for ease of handling. But I don't think those were ever connected to having two deamons running on one host, it happens when just one is running.
(*) In principle, all my data can be put on a memory stick - currently 16GB - and then I can run any linux box with full access to all my data, with the memory stick mounted on /home. |
66505
|
Mon Aug 10 21:19:50 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Comment | Linux | 2.7.7-2251 | Re: Comment on: Alphabetize Quick Option filter | I've just noticed that it has also sorted another Option, which are selected as radio buttons. Again, this is a
list which has a natural - again, in this case, chronological - order.
Because of this, I'm going to have to turn off this feature as it is on my system. I hope something can be sorted
on this.
> (For some reason I could not add this in Dennis's thread.)
>
> I like this new feature, BUT
>
> I happen to have two Options: Options System, and Options Status.
>
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to.
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
>
> Options System: 3.1, NT, 2000, XP, Vista
>
> where the natural order here is chronological.
>
> Perhaps the configuration file option could be more specific, for example
>
> Sort attribute Options Status = 1
>
> which would then NOT sort Options System. If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options. |
66510
|
Tue Aug 11 08:38:56 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Comment | Linux | 2.7.7-2251 | Re: Comment on: Alphabetize Quick Option filter | Ok, that makes sense, so I changed it to
Sort Attribute Options Status = 1
as you suggested.
> (For some reason I could not add this in Dennis's thread.)
>
> I like this new feature, BUT
>
> I happen to have two Options: Options System, and Options Status.
>
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to.
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
>
> Options System: 3.1, NT, 2000, XP, Vista
>
> where the natural order here is chronological.
>
> Perhaps the configuration file option could be more specific, for example
>
> Sort attribute Options Status = 1
>
> which would then NOT sort Options System. If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options. |
66511
|
Tue Aug 11 10:07:08 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Comment | Linux | 2.7.7-2251 | Re: Comment on: Alphabetize Quick Option filter | Thanks Stefan! Works great.
> Ok, that makes sense, so I changed it to
>
> Sort Attribute Options Status = 1
>
> as you suggested.
>
> > (For some reason I could not add this in Dennis's thread.)
> >
> > I like this new feature, BUT
> >
> > I happen to have two Options: Options System, and Options Status.
> >
> > System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to.
> > Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> > sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> > this is made up)
> >
> > Options System: 3.1, NT, 2000, XP, Vista
> >
> > where the natural order here is chronological.
> >
> > Perhaps the configuration file option could be more specific, for example
> >
> > Sort attribute Options Status = 1
> >
> > which would then NOT sort Options System. If both are needed to be sorted, both should be specified, or back to
> > the original syntax which defaults to sort *all* Options. |
66515
|
Tue Aug 11 17:46:33 2009 |
| Dennis Seitz | dseitz@berkeley.edu | Comment | Linux | 2.7.7-2251 | Re: Comment on: Alphabetize Quick Option filter | Yes, many thanks, Stefan, from me, too! It's really great that you respond so quickly to requests and suggestions.
And thanks to David for the fine tuning, great suggestion.
Dennis
> Thanks Stefan! Works great.
>
> > Ok, that makes sense, so I changed it to
> >
> > Sort Attribute Options Status = 1
> >
> > as you suggested.
> >
> > > (For some reason I could not add this in Dennis's thread.)
> > >
> > > I like this new feature, BUT
> > >
> > > I happen to have two Options: Options System, and Options Status.
> > >
> > > System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to.
> > > Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> > > sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> > > this is made up)
> > >
> > > Options System: 3.1, NT, 2000, XP, Vista
> > >
> > > where the natural order here is chronological.
> > >
> > > Perhaps the configuration file option could be more specific, for example
> > >
> > > Sort attribute Options Status = 1
> > >
> > > which would then NOT sort Options System. If both are needed to be sorted, both should be specified, or back to
> > > the original syntax which defaults to sort *all* Options. |
1409
|
Tue Sep 6 09:41:04 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.6.0-b4 | Re: Comment tooltip shows comment from other logbook |
Oleg Solovyanov wrote: | I have several logbooks with Comment lines,
but the tooltip shows sometimes the correct comment,
sometimes the comment from other logbook...
I see the same behaviour also on this very page...
I use Mozilla 1.7.10.
Tried with Konqueror -> same problem. |
Should be fixed in the current CVS version (see this page) |
67603
|
Wed Nov 6 09:04:32 2013 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Mac OSX | 2.9.2-2494 | Re: Compilation failure on Mac OSX 10.9 |
A.G. Schubert wrote: |
When compiling elog on OSX 10.9 (Mavericks), I get the error below.
Elog will compile without error if I add -D_FORTIFY_SOURCE=0 to CFLAGS in Makefile, but I'm not sure whether this is a good idea.
|
All over sudden gcc comes with its own version of "strlcpy", which I had defined "manually" since many years inside ELOG. Using -DFORTIFY_SOURCE=0 will not harm, so you can use it. The "real" solution is to take our ELOG's strlcpy/strlcat, which I did on the current SVN version.
Best regards,
Stefan |
|