ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
1741
|
Thu Mar 2 07:15:27 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.6.1-1622 | Re: Inline images URL not working |
Alexandre Gauthier wrote: | Whenever I try to insert an inline picture by using the elog:1741/1 paths with ELCode, the link becomes "logbookname2/1" (Where logbookname is the name of my logbook) and hence, doesn't work. I recall that it worked once. The image did not display, but the URL seemed correct... |
The problem has been fixed in version 2.6.1-3, so just upgrade.
Alexandre Gauthier wrote: | EDIT: i inserted a space in the elog URL above because regardless of the code brackets, it would still get interpreted. |
You have to put a "\" in front of everything which should not get converted into a link, so elog:1741/1 does not get interpreted. |
1742
|
Thu Mar 2 14:35:54 2006 |
| Alexandre Gauthier | supernaut@underwares.org | Bug report | Linux | 2.6.1-1622 | Re: Re: Inline images URL not working |
Stefan Ritt wrote: |
Alexandre Gauthier wrote: | Whenever I try to insert an inline picture by using the elog:1741/1 paths with ELCode, the link becomes "logbookname2/1" (Where logbookname is the name of my logbook) and hence, doesn't work. I recall that it worked once. The image did not display, but the URL seemed correct... |
The problem has been fixed in version 2.6.1-3, so just upgrade.
Alexandre Gauthier wrote: | EDIT: i inserted a space in the elog URL above because regardless of the code brackets, it would still get interpreted. |
You have to put a "\" in front of everything which should not get converted into a link, so elog:1741/1 does not get interpreted. |
Hello
This is what I have done, I checked out the trunk from subversion and built it inside my powerpc QEMU. I just updated the executables and the elcode.js file, and now it works.
Thanks! |
1743
|
Thu Mar 2 23:32:25 2006 |
| Steve Jones | steve.jones@freescale.com | Request | All | 2.6.1 | Top Groups and logbook directorys |
I am re-working our elog setup and am seriously looking at using the "Top Group" feature. What I like best is the ability to create [global] configurations for a group (or type) of logbook when I host multiple types on the same server. I also like being able to specify a different password file, etc.
A limitation that I run into is I would really like the actual directory names used for storing the logbooks for the different types to be identical - which isn't possible when all logbooks (regardless of context) exist at the same directory level. For example, I might have:
3 physical locations: ABC, DEF, GHI
For each location I want to maintain two *groups* of logbooks - CircuitTests and BoardTests. What I would like to end up with is:
- CircuitTests
----ABC
----DEF
----GHI
- BoardTests
----ABC
----DEF
----GHI
Under current elog this is not possble as far as I know. Since each logbook is a physical directory, each logbook requires a unique name. The concept of a named [global] area fills the bill for all things but it would be nifty if one could do:
[global circuittests]
Logbook dir = circuittestlogbooks
[global boardtests]
Logbook dir = boardtestlogbooks
I suppose the poorman's way of doing this is for each logbook to do the following:
[ABC]
Subdir = boardtestlogbooks/ABC
[DEF]
Subdir = boardtestlogbooks/DEF
[GHI]
Subdir = boardtestlogbooks/GHI
or something like that, but I was hopic for something a little more integrated - like creating the hierarchical stuff via the GUI. Anyway, this probably sounds like a major overhaul, which definitely wouldn't be worth it unless I have completely missed something glaringly obvious.
Thanks! |
1744
|
Fri Mar 3 16:48:01 2006 |
| Alexandre Gauthier | supernaut@underwares.org | Bug fix | Mac OSX | SVN 1668 | Makefile patch for OS X 10.4 |
Hello,
I had trouble compiling elog on Mac OS X 10.4, and so, I hacked the makefile around...
I had to remove the -lutil flag that was passed to ld, for some reason. My guess is that it is not needed anymore with OS X 10.4... Also, the current install section of the makefile crapped out when using /usr/bin/install, I had to use install from gnu fileutils, which I installed through fink, which took precedence in my path... (/sw/bin/install), since bsd fileutil doesn't like the -D option.
For some reason, the paths to "install" in the makefile are either defined by the $(INSTALL) variable, or called directly. This seems not to be very consistent... In any case, I just changed it to use "install", no matter where it was in my path.
I'm currently hacking up something more elegant soon enough...
Also, I noticed that the binary produced was inconsistent and sluggish with the default wild CFLAGs, so I brought them back to something a bit more casual for Darwin. I used -Os because that's what Apple uses to build most OS X software. I also use -Os in my blackdog builds (which is an embedded PowerPC device) since space and memory *does* matters.
Well, here's the patch. I doubt it will be useful to anyone except for those who have gnu fileutils installed through fink, in their paths, and find themselves unable to build elog on OS X. |
1745
|
Fri Mar 3 18:02:59 2006 |
| Steve Jones | steve.jones@freescale.com | Request | All | 2.6.1 | Allow $attributes in "Comment = " option |
Is it possible to allow $attribute substitutions in the "Comment =" option for logbooks? |
1746
|
Sat Mar 4 05:17:14 2006 |
| Glenn Horton-Smith | gahs@phys.ksu.edu | Request | All | 2.6.1-1668 | require smileys to have whitespace on either side? |
It would be nice if elog would only interpret something as a smiley if it is surrounded by whitespace. It can be particularly annoying that an 8 followed by a right paren becomes a "cool" smiley -- e.g., a parenthetical reference to event eighteen (18) becomes mangled... [That was "18" inside the parens.]
Is there already a way to solve this issue (other than always previewing your entries and adding spaces before parans)? Is the feature hard to implement? |
1747
|
Sat Mar 4 06:04:53 2006 |
| Steve Jones | steve.jones@freescale.com | Request | All | 2.6.1 | Re: Top Groups and logbook directorys |
Steve Jones wrote: | I am re-working our elog setup and am seriously looking at using the "Top Group" feature. What I like best is the ability to create [global] configurations for a group (or type) of logbook when I host multiple types on the same server. I also like being able to specify a different password file, etc.
A limitation that I run into is I would really like the actual directory names used for storing the logbooks for the different types to be identical - which isn't possible when all logbooks (regardless of context) exist at the same directory level. For example, I might have:
3 physical locations: ABC, DEF, GHI
For each location I want to maintain two *groups* of logbooks - CircuitTests and BoardTests. What I would like to end up with is:
- CircuitTests
----ABC
----DEF
----GHI
- BoardTests
----ABC
----DEF
----GHI
Under current elog this is not possble as far as I know. Since each logbook is a physical directory, each logbook requires a unique name. The concept of a named [global] area fills the bill for all things but it would be nifty if one could do:
[global circuittests]
Logbook dir = circuittestlogbooks
[global boardtests]
Logbook dir = boardtestlogbooks
I suppose the poorman's way of doing this is for each logbook to do the following:
[ABC]
Subdir = boardtestlogbooks/ABC
[DEF]
Subdir = boardtestlogbooks/DEF
[GHI]
Subdir = boardtestlogbooks/GHI
or something like that, but I was hopic for something a little more integrated - like creating the hierarchical stuff via the GUI. Anyway, this probably sounds like a major overhaul, which definitely wouldn't be worth it unless I have completely missed something glaringly obvious.
Thanks! |
Steve Jones wrote: | Perhaps it is best to ignore this -- I went for a workaround that I like. I am running into a few quirky things with Top Group but it is likely due to the fact that I have never used it. |
|
1748
|
Sat Mar 4 06:08:29 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.6.1-1660 | Crafted URL causes elog to coredump |
While playing with TOP GROUP I managed to get elog 2.6.1 1660 on Solaris 9 to coredump. Since I didn't really understand TOP GROUP I tried a URL where I had http://elog.server.com/topgroupname/logbookname. Putting that logbookname at the end caused elog to dump.
Can this be reproduced by others? |