Problem with Syslog-NG 3.2.5 on Aix 7.1 ... It coredumps..
Hello All, I am hoping someone out there has a working installation of 3.2.5 on Aix 7.1 and can help me get mine working. I am currently trying to use a self-compiled version of 3.2.5 on an Power7 CPU Aix 7.1 TL1 SP3 box. I was able to get Syslog-NG to compile on Aix 7.1 after I mangled a new libtool release into the source so it would compile shared objects. Unfortunately, when I start syslog-ng it core dumps repeatedly. Core dumps start filling up /sftw/syslog-ng/var and a ps -ef shows only the "supervising syslog-ng process". a dbx syslog-ng gives this output... [root@mlwitt71]:[/sftw/syslog-ng/sbin] > dbx syslog-ng Type 'help' for help. [using memory image in core.10092546.01150742] reading symbolic information ... Segmentation fault in alloca at 0xd2970930 ($t1) 0xd2970930 (alloca+0x8) 800c0000 lwz r0,0x0(r12) (dbx) where alloca() at 0xd2970930 evt_str_append_escape_bs() at 0xd2970520 evtrec_format_plain() at 0xd296feb4 evt_format() at 0xd2970104 msg_event_send(e = 0x00000005), line 166 in "messages.c" main_loop_run(cfg = (nil)), line 148 in "main.c" main(argc = 1, argv = 0x2ff227f4), line 470 in "main.c" (dbx) I have also tried using the Syslog-ng rpm's from perzl & Bull. Both of them core dump as well, so I went back to trying to get a self-compiled release to work as I have some control over that. I used IBM VisualAge C/C++ v11.1.0.9 as the C compiler. [root@mlwitt71]:[/sftw/syslog-ng/sbin] > lslpp -L | grep vac vac.Bnd 11.1.0.1 C F XL C for AIX Media Defined vac.C 11.1.0.9 C F IBM XL C Compiler vac.aix53.lib 11.1.0.9 C F XL C for AIX Libraries for AIX vac.include 11.1.0.9 C F IBM XL C Compiler Include vac.lib 11.1.0.9 C F XL C for AIX Libraries vacpp.Bnd 11.1.0.1 C F IBM XL C/C++ Media Defined vacpp.cmp.aix53.lib 11.1.0.9 C F IBM XL C/C++ Libraries for AIX vacpp.cmp.core 11.1.0.9 C F IBM XL C/C++ Compiler vacpp.cmp.include 11.1.0.9 C F IBM XL C/C++ Compiler Include vacpp.cmp.lib 11.1.0.9 C F IBM XL C/C++ Libraries vacpp.cmp.rte 11.1.0.9 C F IBM XL C/C++ Compiler vacpp.cmp.tools 11.1.0.9 C F IBM XL C/C++ Tools vacpp.tnb 11.1.0.1 C F IBM XL C/C++ Evaluation I mangled libtool 2.4.2 into the source directories so it would detect/compile shared libraries (it wouldn't otherwise). I compiled and installed eventlog 0.2.12 in /sftw/syslog-ng, I also compiled OpenSSL 1.0.0g into it staticly. I am initially trying to start it using the default configuration files. There were no errors during the compile, and a syslog-ng -s did NOT coredump. I believe syslog-ng is using the following libraries and their locations (dynamically linked). [root@mlwitt71]:[/sftw/syslog-ng/sbin] > ldd syslog-ng syslog-ng needs: /sftw/syslog-ng/lib/libsyslog-ng.a(libsyslog-ng.so.0) /usr/lib/libnsl.a(shr.o) /opt/freeware/lib/libgmodule-2.0.so /opt/freeware/lib/libglib-2.0.so /usr/lib/libpthread.a(shr_xpg5.o) /usr/lib/libc.a(shr.o) /sftw/syslog-ng/lib/libevtlog.a(libevtlog.so.0) /usr/lib/librtl.a(shr.o) /opt/freeware/lib/libpcre.a(libpcre.so.0) /usr/lib/libthread.a(shr.o) /usr/lib/libpthreads_compat.a(shr.o) /usr/lib/libpthreads.a(shr_xpg5.o) /usr/lib/libtli.a(shr.o) /opt/freeware/lib/libglib-2.0.a(libglib-2.0.so.0) /opt/freeware/lib/libintl.a(libintl.so.1) /usr/lib/libiconv.a(shr4.o) /usr/lib/libpthreads.a(shr_comm.o) /unix /usr/lib/libcrypt.a(shr.o) /usr/lib/libpthreads.a(shr.o) /usr/lib/libc.a(pse.o) and the configure command when compiling from source was: ./configure --prefix=/sftw/syslog-ng \ --disable-spoof-source \ --enable-dynamic-linking \ --enable-debug \ --enable-ssl and I added -g to the CFLAGS I am using glib2-2.28.6-1 from perzl as well.. I plan on removing the --enable-debug if I can get it working Any ideas? Jonathan Kaufman
I had the same issue using Sun Studio for building 64-bit binaries on Solaris. Could you apply this patch to eventlog, rebuild it and retry? --- src/evtstr.c-orig 2010-12-03 14:44:25.000000000 +0100 +++ src/evtstr.c 2010-12-03 14:45:21.000000000 +0100 @@ -48,6 +48,7 @@ #ifdef _MSC_VER #include <malloc.h> #endif +#include <alloca.h> /* event string handling */ On Thu, Mar 1, 2012 at 3:21 PM, Jonathan Kaufman <jkaufman@footlocker.com> wrote:
Hello All, I am hoping someone out there has a working installation of 3.2.5 on Aix 7.1 and can help me get mine working.
I am currently trying to use a self-compiled version of 3.2.5 on an Power7 CPU Aix 7.1 TL1 SP3 box. I was able to get Syslog-NG to compile on Aix 7.1 after I mangled a new libtool release into the source so it would compile shared objects.
Unfortunately, when I start syslog-ng it core dumps repeatedly.
Core dumps start filling up /sftw/syslog-ng/var and a ps -ef shows only the "supervising syslog-ng process".
a dbx syslog-ng gives this output...
[root@mlwitt71]:[/sftw/syslog-ng/sbin] > dbx syslog-ng Type 'help' for help. [using memory image in core.10092546.01150742] reading symbolic information ...
Segmentation fault in alloca at 0xd2970930 ($t1) 0xd2970930 (alloca+0x8) 800c0000 lwz r0,0x0(r12) (dbx) where alloca() at 0xd2970930 evt_str_append_escape_bs() at 0xd2970520 evtrec_format_plain() at 0xd296feb4 evt_format() at 0xd2970104 msg_event_send(e = 0x00000005), line 166 in "messages.c" main_loop_run(cfg = (nil)), line 148 in "main.c" main(argc = 1, argv = 0x2ff227f4), line 470 in "main.c" (dbx)
I have also tried using the Syslog-ng rpm's from perzl & Bull. Both of them core dump as well, so I went back to trying to get a self-compiled release to work as I have some control over that.
I used IBM VisualAge C/C++ v11.1.0.9 as the C compiler.
[root@mlwitt71]:[/sftw/syslog-ng/sbin] > lslpp -L | grep vac vac.Bnd 11.1.0.1 C F XL C for AIX Media Defined vac.C 11.1.0.9 C F IBM XL C Compiler vac.aix53.lib 11.1.0.9 C F XL C for AIX Libraries for AIX vac.include 11.1.0.9 C F IBM XL C Compiler Include vac.lib 11.1.0.9 C F XL C for AIX Libraries vacpp.Bnd 11.1.0.1 C F IBM XL C/C++ Media Defined vacpp.cmp.aix53.lib 11.1.0.9 C F IBM XL C/C++ Libraries for AIX vacpp.cmp.core 11.1.0.9 C F IBM XL C/C++ Compiler vacpp.cmp.include 11.1.0.9 C F IBM XL C/C++ Compiler Include vacpp.cmp.lib 11.1.0.9 C F IBM XL C/C++ Libraries vacpp.cmp.rte 11.1.0.9 C F IBM XL C/C++ Compiler vacpp.cmp.tools 11.1.0.9 C F IBM XL C/C++ Tools vacpp.tnb 11.1.0.1 C F IBM XL C/C++ Evaluation
I mangled libtool 2.4.2 into the source directories so it would detect/compile shared libraries (it wouldn't otherwise).
I compiled and installed eventlog 0.2.12 in /sftw/syslog-ng, I also compiled OpenSSL 1.0.0g into it staticly.
I am initially trying to start it using the default configuration files.
There were no errors during the compile, and a syslog-ng -s did NOT coredump.
I believe syslog-ng is using the following libraries and their locations (dynamically linked).
[root@mlwitt71]:[/sftw/syslog-ng/sbin] > ldd syslog-ng syslog-ng needs: /sftw/syslog-ng/lib/libsyslog-ng.a(libsyslog-ng.so.0) /usr/lib/libnsl.a(shr.o) /opt/freeware/lib/libgmodule-2.0.so /opt/freeware/lib/libglib-2.0.so /usr/lib/libpthread.a(shr_xpg5.o) /usr/lib/libc.a(shr.o) /sftw/syslog-ng/lib/libevtlog.a(libevtlog.so.0) /usr/lib/librtl.a(shr.o) /opt/freeware/lib/libpcre.a(libpcre.so.0) /usr/lib/libthread.a(shr.o) /usr/lib/libpthreads_compat.a(shr.o) /usr/lib/libpthreads.a(shr_xpg5.o) /usr/lib/libtli.a(shr.o) /opt/freeware/lib/libglib-2.0.a(libglib-2.0.so.0) /opt/freeware/lib/libintl.a(libintl.so.1) /usr/lib/libiconv.a(shr4.o) /usr/lib/libpthreads.a(shr_comm.o) /unix /usr/lib/libcrypt.a(shr.o) /usr/lib/libpthreads.a(shr.o) /usr/lib/libc.a(pse.o)
and the configure command when compiling from source was:
./configure --prefix=/sftw/syslog-ng \ --disable-spoof-source \ --enable-dynamic-linking \ --enable-debug \ --enable-ssl
and I added -g to the CFLAGS
I am using glib2-2.28.6-1 from perzl as well.. I plan on removing the --enable-debug if I can get it working
Any ideas?
Jonathan Kaufman
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Awesome! Thank you very much. Just in case anyone else is working on Aix 7.1 builds of Syslog-NG here is what worked (or didn't) for me. 1. Update to the LATEST version of IBM VisualAge C/C++, I couldn't get it to compile until I updated to the 2012 patch set (I was at the early 2011 patch set) for V11 2. There were also a few Aix APARs that would have affected compiling code dealing with the assembler or whatnot. I sidestepped them and upgraded to the latest TL and SP (TL1 SP3) 3. I couldn't get the bundled libtool that is included with the Syslog-NG source to recognize that you can create shared libraries, so I couldn't create shared libraries for the modules (that was an issue) I "upgraded" the bundled libtool to 2.4.2 which fixed it so I could created shared libraries for the modules. The make install didn't copy them, so I had to do it manually but at least it works. I would expect this isn't the preferred method for fixing this, but so far it doesn't seem to have a downside. 4. I had the libiconv library from perzl.org loaded for a different application, and if Syslog-NG used that either during compile or runtime it would coredump. Moral of the story seems to be to use the IBM libiconv library. 5. And lastly Sandor's suggestion. Add the alloca.h include to evtstr.c if you are using the IBM VisualAge compiler you may be able to use the -ma compiler option. I don't know if it does the same thing, but if I used the option (and didn't add it to the source) syslog-ng didn't core. I will likely just add it to the source, but thought to mention the -ma option *seems* to work just the same. Hopefully this will be the last of my instability woes on Aix 7.1 with Syslog-NG. Jonathan Kaufman |------------> | From: | |------------>
--------------------------------------------------------------------------------------------------------------------------------------------------| |Sandor Geller <Sandor.Geller@morganstanley.com> | --------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> --------------------------------------------------------------------------------------------------------------------------------------------------| |"Syslog-ng users' and developers' mailing list" <syslog-ng@lists.balabit.hu> | --------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> --------------------------------------------------------------------------------------------------------------------------------------------------| |03/01/2012 11:03 AM | --------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> --------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [syslog-ng] Problem with Syslog-NG 3.2.5 on Aix 7.1 ... It coredumps.. | --------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Sent by: | |------------> --------------------------------------------------------------------------------------------------------------------------------------------------| |syslog-ng-bounces@lists.balabit.hu | --------------------------------------------------------------------------------------------------------------------------------------------------|
I had the same issue using Sun Studio for building 64-bit binaries on Solaris. Could you apply this patch to eventlog, rebuild it and retry? --- src/evtstr.c-orig 2010-12-03 14:44:25.000000000 +0100 +++ src/evtstr.c 2010-12-03 14:45:21.000000000 +0100 @@ -48,6 +48,7 @@ #ifdef _MSC_VER #include <malloc.h> #endif +#include <alloca.h> /* event string handling */ On Thu, Mar 1, 2012 at 3:21 PM, Jonathan Kaufman <jkaufman@footlocker.com> wrote:
Hello All, I am hoping someone out there has a working installation of 3.2.5
on
Aix 7.1 and can help me get mine working.
I am currently trying to use a self-compiled version of 3.2.5 on an Power7 CPU Aix 7.1 TL1 SP3 box. I was able to get Syslog-NG to compile on Aix 7.1 after I mangled a new libtool release into the source so it would compile shared objects.
Unfortunately, when I start syslog-ng it core dumps repeatedly.
Core dumps start filling up /sftw/syslog-ng/var and a ps -ef shows only the "supervising syslog-ng process".
a dbx syslog-ng gives this output...
[root@mlwitt71]:[/sftw/syslog-ng/sbin] > dbx syslog-ng Type 'help' for help. [using memory image in core.10092546.01150742] reading symbolic information ...
Segmentation fault in alloca at 0xd2970930 ($t1) 0xd2970930 (alloca+0x8) 800c0000 lwz r0,0x0(r12) (dbx) where alloca() at 0xd2970930 evt_str_append_escape_bs() at 0xd2970520 evtrec_format_plain() at 0xd296feb4 evt_format() at 0xd2970104 msg_event_send(e = 0x00000005), line 166 in "messages.c" main_loop_run(cfg = (nil)), line 148 in "main.c" main(argc = 1, argv = 0x2ff227f4), line 470 in "main.c" (dbx)
I have also tried using the Syslog-ng rpm's from perzl & Bull. Both of them core dump as well, so I went back to trying to get a self-compiled release to work as I have some control over that.
I used IBM VisualAge C/C++ v11.1.0.9 as the C compiler.
[root@mlwitt71]:[/sftw/syslog-ng/sbin] > lslpp -L | grep vac vac.Bnd 11.1.0.1 C F XL C for AIX Media Defined vac.C 11.1.0.9 C F IBM XL C Compiler vac.aix53.lib 11.1.0.9 C F XL C for AIX Libraries for AIX vac.include 11.1.0.9 C F IBM XL C Compiler Include vac.lib 11.1.0.9 C F XL C for AIX Libraries vacpp.Bnd 11.1.0.1 C F IBM XL C/C++ Media Defined vacpp.cmp.aix53.lib 11.1.0.9 C F IBM XL C/C++ Libraries for AIX vacpp.cmp.core 11.1.0.9 C F IBM XL C/C++ Compiler vacpp.cmp.include 11.1.0.9 C F IBM XL C/C++ Compiler Include vacpp.cmp.lib 11.1.0.9 C F IBM XL C/C++ Libraries vacpp.cmp.rte 11.1.0.9 C F IBM XL C/C++ Compiler vacpp.cmp.tools 11.1.0.9 C F IBM XL C/C++ Tools vacpp.tnb 11.1.0.1 C F IBM XL C/C++ Evaluation
I mangled libtool 2.4.2 into the source directories so it would detect/compile shared libraries (it wouldn't otherwise).
I compiled and installed eventlog 0.2.12 in /sftw/syslog-ng, I also compiled OpenSSL 1.0.0g into it staticly.
I am initially trying to start it using the default configuration files.
There were no errors during the compile, and a syslog-ng -s did NOT coredump.
I believe syslog-ng is using the following libraries and their locations (dynamically linked).
[root@mlwitt71]:[/sftw/syslog-ng/sbin] > ldd syslog-ng syslog-ng needs: /sftw/syslog-ng/lib/libsyslog-ng.a(libsyslog-ng.so.0) /usr/lib/libnsl.a(shr.o) /opt/freeware/lib/libgmodule-2.0.so /opt/freeware/lib/libglib-2.0.so /usr/lib/libpthread.a(shr_xpg5.o) /usr/lib/libc.a(shr.o) /sftw/syslog-ng/lib/libevtlog.a(libevtlog.so.0) /usr/lib/librtl.a(shr.o) /opt/freeware/lib/libpcre.a(libpcre.so.0) /usr/lib/libthread.a(shr.o) /usr/lib/libpthreads_compat.a(shr.o) /usr/lib/libpthreads.a(shr_xpg5.o) /usr/lib/libtli.a(shr.o) /opt/freeware/lib/libglib-2.0.a(libglib-2.0.so.0) /opt/freeware/lib/libintl.a(libintl.so.1) /usr/lib/libiconv.a(shr4.o) /usr/lib/libpthreads.a(shr_comm.o) /unix /usr/lib/libcrypt.a(shr.o) /usr/lib/libpthreads.a(shr.o) /usr/lib/libc.a(pse.o)
and the configure command when compiling from source was:
./configure --prefix=/sftw/syslog-ng \ --disable-spoof-source \ --enable-dynamic-linking \ --enable-debug \ --enable-ssl
and I added -g to the CFLAGS
I am using glib2-2.28.6-1 from perzl as well.. I plan on removing the --enable-debug if I can get it working
Any ideas?
Jonathan Kaufman
______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq Visit us on-line at footlocker.com. The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although the Company attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses.
I don't want to expose my ignorance or publish comments that may be misinterpreted as derogatory to folks that are not developers. If there isn't a developer's only list, then I will open discussions on this list, but I am going to need a bit of "hand holding" as I come up to speed on the code base before I can attempt to fix what I still think is a huge memory leak. Evan.
Hi Evan, currently there is no separate list for developers. Regards, Robert On Wednesday, March 7, 2012 20:02 CET, Evan Rempel <erempel@uvic.ca> wrote:
I don't want to expose my ignorance or publish comments that may be misinterpreted as derogatory to folks that are not developers.
If there isn't a developer's only list, then I will open discussions on this list, but I am going to need a bit of "hand holding" as I come up to speed on the code base before I can attempt to fix what I still think is a huge memory leak.
Evan. ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
I am having difficulties understanding the code that handles the LogQueueFifo objects. For instance static void log_queue_fifo_push_head(LogQueue *s, LogMessage *msg, const LogPathOptions *path_options) { LogQueueFifo *self = (LogQueueFifo *) s; LogMessageQueueNode *node; ... I don't understand how a LogQueue* can be passed in, and then cast to a LogQueueFifo* when the structs are not the same. Then fields in the LogQueueFifo* are referenced but they won't have any meaning because the LogQueue* didn't have the same data at the same location. I am a little rusty in C, so can someone explain this to me please? Evan.
Evan Rempel <erempel@uvic.ca> writes:
I am having difficulties understanding the code that handles the LogQueueFifo objects.
For instance
static void log_queue_fifo_push_head(LogQueue *s, LogMessage *msg, const LogPathOptions *path_options) { LogQueueFifo *self = (LogQueueFifo *) s; LogMessageQueueNode *node;
...
I don't understand how a LogQueue* can be passed in, and then cast to a LogQueueFifo* when the structs are not the same. Then fields in the LogQueueFifo* are referenced but they won't have any meaning because the LogQueue* didn't have the same data at the same location.
I am a little rusty in C, so can someone explain this to me please?
What happens here, is that this function is a callback, which has a generic prototype, but one that will always get a LogQueueFifo passed to it. A LogQueueFifo can also serve as a LogQueue, since its first member *is* a LogQueue struct, so when cast over, it will Just Work. LogQueueFifo is a child object of LogQueue. And due to the way these callbacks work (see log_queue_fifo_new()), we can be sure that a callback like this will always get a LogQueueFifo, therefore, the cast from parent type to child type is safe. Since we passed a pointer, the rest of the LogQueueFifo structure will be there in the memory too, and once we did the cast, they become accessible too. Hope that sheds some light on it. -- |8]
Hi All! 2012. 03. 7, szerda keltezéssel 21.24-kor Evan Rempel ezt írta:
I am having difficulties understanding the code that handles the LogQueueFifo objects.
For instance
static void log_queue_fifo_push_head(LogQueue *s, LogMessage *msg, const LogPathOptions *path_options) { LogQueueFifo *self = (LogQueueFifo *) s; LogMessageQueueNode *node;
The LogQueueFifo structure is defined like this: typedef struct _LogQueueFifo { LogQueue super; /* scalable qoverflow implementation */ struct list_head qoverflow_output; [...] You could spot that the first member of the LogQueueFifo is LogQueue type and also important that not a pointer but an embedded field. With this and knowing the method how the C create this type of embedding structures you could cast a LogQueueFifo type to LogQueue. This is some type of poor's man inheritance in C. -- Attila Szalay Product Security Specialist e-mail: attila.szalay@balabit.com phone: +36 1 398 6707 BalaBit IT Security www.balabit.com H-1117 Budapest, Aliz street 2. This Communication is Confidential. We only send and receive email on the basis of the term set out at http://www.balabit.com/disclaimer/.
Hi, Jonathan, Sandor, thanks for the report and the proposed fix. I've commited it to eventlog git tree. On Thu, 2012-03-01 at 13:03 -0600, Jonathan Kaufman wrote:
Awesome!
Thank you very much.
Just in case anyone else is working on Aix 7.1 builds of Syslog-NG here is what worked (or didn't) for me.
1. Update to the LATEST version of IBM VisualAge C/C++, I couldn't get it to compile until I updated to the 2012 patch set (I was at the early 2011 patch set) for V11 2. There were also a few Aix APARs that would have affected compiling code dealing with the assembler or whatnot. I sidestepped them and upgraded to the latest TL and SP (TL1 SP3) 3. I couldn't get the bundled libtool that is included with the Syslog-NG source to recognize that you can create shared libraries, so I couldn't create shared libraries for the modules (that was an issue) I "upgraded" the bundled libtool to 2.4.2 which fixed it so I could created shared libraries for the modules. The make install didn't copy them, so I had to do it manually but at least it works. I would expect this isn't the preferred method for fixing this, but so far it doesn't seem to have a downside. 4. I had the libiconv library from perzl.org loaded for a different application, and if Syslog-NG used that either during compile or runtime it would coredump. Moral of the story seems to be to use the IBM libiconv library. 5. And lastly Sandor's suggestion. Add the alloca.h include to evtstr.c if you are using the IBM VisualAge compiler you may be able to use the -ma compiler option. I don't know if it does the same thing, but if I used the option (and didn't add it to the source) syslog-ng didn't core. I will likely just add it to the source, but thought to mention the -ma option *seems* to work just the same.
Hopefully this will be the last of my instability woes on Aix 7.1 with Syslog-NG.
-- Bazsi
Before I report a bug/feature change I would like to ask if there was any reason that the JSON output for multi-value items simply joins them with a comma rather than turning them into a JSON array. Most notably the TAGS field is put out by format-json shows something like; "TAGS": ".source.patterndb,.classifier.cluster,.net.connected" where these are autopoluated by the patterndb .source.patterndb,.classifier.cluster and this one is added by a specific tabs entry in my patterndb. <tags> <tag>.net.connect</tag> </tags> -- Evan Rempel
Evan Rempel <erempel@uvic.ca> writes:
Before I report a bug/feature change I would like to ask if there was any reason that the JSON output for multi-value items simply joins them with a comma rather than turning them into a JSON array.
Most notably the TAGS field is put out by format-json shows something like;
"TAGS": ".source.patterndb,.classifier.cluster,.net.connected"
where these are autopoluated by the patterndb
.source.patterndb,.classifier.cluster
and this one is added by a specific tabs entry in my patterndb.
<tags> <tag>.net.connect</tag> </tags>
This is because "TAGS" itself is stored like this internally, and the JSON output doesn't do any post-processing on the values. It's been on my TODO list for a while, and once the JSON output understands how to build arrays and nested structures properly (which is being done as part of a GSoC project this summer, FYI), then we can - and will - figure something out to handle TAGS sanely, and present them as arrays when that's the desired format. How that will be done is another matter, but it's something I need too, and preferably sooner than later. I'll happily discuss my current ideas if you're interested, and of course, opinions about the implementation ideas would be more than welcome too. -- |8]
participants (8)
-
Balazs Scheidler
-
Evan Rempel
-
Fekete Róbert
-
Gergely Nagy
-
Gergely Nagy
-
Jonathan Kaufman
-
Sandor Geller
-
Szalay Attila