Menu
▾
▴
rlib-devel — RLIB Development Mailing List
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(4) |
Mar
(10) |
Apr
(2) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(9) |
| 2005 |
Jan
(2) |
Feb
|
Mar
(8) |
Apr
(46) |
May
(16) |
Jun
(69) |
Jul
(27) |
Aug
(12) |
Sep
|
Oct
(11) |
Nov
|
Dec
(14) |
| 2006 |
Jan
(22) |
Feb
(4) |
Mar
(9) |
Apr
(1) |
May
|
Jun
(4) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(5) |
Nov
(2) |
Dec
(16) |
| 2007 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
(3) |
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(14) |
Sep
(10) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(3) |
Mar
|
Apr
(2) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Zoltan B. <zb...@du...> - 2006-01-05 22:20:48
|
Hi, I just noticed that every input modules and rlib.so.1.3.7 are linked to=20 everything that was detected during ./configure, e.g. postgres.so is linked to=20 libmysqlclient.so and libodbc.so, too. They don't need to be, and it defeats the very=20 purpose of using dynamically opened input modules and the fine grained RPM packaging is al= so broken in this context. E.g. rlib-odbc cannot be installed where e.g.=20 mysql isn't installed. I have solved it in the attached patch. Now everything is linked to the u= sed libraries only. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Bob D. <bd...@si...> - 2006-01-01 21:04:22
|
Hi, Sorry for the delayed response. First can you send patches in unified diff format so they are easier to read. (diff -u) Your patch would break RLIB detecting if it should build Python bindings. Before I could apply the acsite.m4 stuff I would need to better understand why it's better across distributions. What's wrong w/ the existing detection? config.h.in is generated w/ autoheader when you run autogen.sh before you build from CVS I have no idea why the documentation does not compile :( I am in the process of moving all RLIB documentation to a wiki (newrlib.sicom.com) Thanks! - Bob On Wed, 2005-12-28 at 15:59 +0100, Aldo Nicolas Bruno wrote: > > Hi, I've had problems compiling rlib (lastest CVS) with python support > on my Debian Sid/PPC > > I fixed the problems by adding a macro to acsite.m4 and modifying > configure.in and bindings/python/Makefile.am > > I've attached the patch and the acsite.m4 > > I've also noticed that the config.h.in was missing from CVS > Also the documentation does not compile, I don't know exacty why. I've > attached the gzipped book.log > > Best regards > > -- > > Aldo Nicolas Bruno > Referente del LUG San Fidenzio - http://www.lugsanfidenzio.org/ > Sviluppatore del progetto GEPAL - http://www.gepal.org/ > Home page: http://aldox86.blogspot.com/ -- Bob Doan <bd...@si...> |
|
From: Zoltan B. <zb...@du...> - 2005-12-31 22:06:05
|
Hi, and here's another patch for the RPM spec file, so newer rpmbuilds accept it. Happy New Year! Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi Bob Doan =C3=ADrta: >Applied! > >Thanks! > >- Bob > >On Wed, 2005-12-28 at 12:03 +0100, Zoltan Boszormenyi wrote: > =20 > >>Hi, >> >>here is another small patch, to avoid truncation of a UTF-8 string >>when the alignment is centered. >> >>Best regards, >>Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi >> >> =20 >> |
|
From: Bob D. <bd...@si...> - 2005-12-31 16:07:37
|
Applied! Thanks! - Bob On Wed, 2005-12-28 at 12:03 +0100, Zoltan Boszormenyi wrote: > Hi, > > here is another small patch, to avoid truncation of a UTF-8 string > when the alignment is centered. > > Best regards, > Zoltán Böszörményi > -- Bob Doan <bd...@si...> |
|
From: Bob D. <bd...@si...> - 2005-12-31 16:07:28
|
Hi, All applied! Works on FC4 Thanks! - bob On Wed, 2005-12-28 at 00:47 +0100, Zoltan Boszormenyi wrote: > Hi, > > I finally fixed all the problems that caused crashes or truncated UTF-8 > strings > in the current RLIB CVS. All patches are attached. Use only these patches, > some patches I previously sent are wrong. Description follows. > > rlib-1.3.7-charencoder-fix.patch > > Don't memset() a NULL pointer. > g_iconv() doesn't allocate the output buffer, use g_convert_with_iconv() > instead. > More verbose explanation was sent earlier. > > rlib-1.3.7-layout.c-64bit-fix.patch > > On 64-bit systems, gsize isn't the same size as guint. So, don't pass > an address of a smaller sized variable to a function that expects > a larger storage, it will corrupt the stack and cause crashes elsewhere. > > rlib-1.3.7-resolution.c-fix.patch > > Always return an allocated string. > The function returns a string, not an integer. This caused empty fields > and/or crashes in the report depending on the moon phase... > > rlib-1.3.7-layout-string-resize.patch > > Resize the allocated buffer if needed to avoid crashes. > > rlib-1.3.7-formatstring-align-fix.patch > > Don't truncate UTF-8 strings. > > Now if someone can test all these on systems with a newer GCC, > e.g. later 4.0.x or 4.1, preferably FC4 or FC5test, I would be happy. > Even happier if no other problems appear. :-) The new GCC versions > in newer Fedora Core are known to be stricter. > > Best regards, > Zoltán Böszörményi > -- Bob Doan <bd...@si...> |
|
From: Aldo N. B. <al...@gm...> - 2005-12-28 14:59:54
|
Hi, I've had problems compiling rlib (lastest CVS) with python support on my Debian Sid/PPC I fixed the problems by adding a macro to acsite.m4 and modifying configure.in and bindings/python/Makefile.am I've attached the patch and the acsite.m4 I've also noticed that the config.h.in was missing from CVS Also the documentation does not compile, I don't know exacty why. I've attached the gzipped book.log Best regards -- Aldo Nicolas Bruno Referente del LUG San Fidenzio - http://www.lugsanfidenzio.org/ Sviluppatore del progetto GEPAL - http://www.gepal.org/ Home page: http://aldox86.blogspot.com/ |
|
From: Zoltan B. <zb...@du...> - 2005-12-28 10:55:33
|
Hi, here is another small patch, to avoid truncation of a UTF-8 string when the alignment is centered. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Zoltan B. <zb...@du...> - 2005-12-27 23:14:09
|
Hi, I finally fixed all the problems that caused crashes or truncated UTF-8=20 strings in the current RLIB CVS. All patches are attached. Use only these patches= , some patches I previously sent are wrong. Description follows. rlib-1.3.7-charencoder-fix.patch Don't memset() a NULL pointer. g_iconv() doesn't allocate the output buffer, use g_convert_with_iconv()=20 instead. More verbose explanation was sent earlier. rlib-1.3.7-layout.c-64bit-fix.patch On 64-bit systems, gsize isn't the same size as guint. So, don't pass an address of a smaller sized variable to a function that expects a larger storage, it will corrupt the stack and cause crashes elsewhere. rlib-1.3.7-resolution.c-fix.patch Always return an allocated string. The function returns a string, not an integer. This caused empty fields and/or crashes in the report depending on the moon phase... rlib-1.3.7-layout-string-resize.patch Resize the allocated buffer if needed to avoid crashes. rlib-1.3.7-formatstring-align-fix.patch Don't truncate UTF-8 strings. Now if someone can test all these on systems with a newer GCC, e.g. later 4.0.x or 4.1, preferably FC4 or FC5test, I would be happy. Even happier if no other problems appear. :-) The new GCC versions in newer Fedora Core are known to be stricter. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Zoltan B. <zb...@du...> - 2005-12-27 14:50:33
|
Hi, I'm slowly progressing in fixing RLIB on x86-64. I found another crasher=20 bug, this time in a 64-bit unclean code. guint and gsize aren't the same size=20 on x86-64. Now it doesn't crash for me anymore but it still gives me empty fields=20 in the PDF report. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Zoltan B. <zb...@du...> - 2005-12-26 22:08:34
|
Hi, Zoltan Boszormenyi =EDrta: > Bob Doan =EDrta: > >> On Sat, 2005-12-17 at 16:46 +0100, Zoltan Boszormenyi wrote: >> =20 >> >>> Hi, >>> >>> long time no see, erm, write? :-) >>> =20 >> >> >> Hey! >> >> =20 >> >>> I tried the latest CVS version of RLIB and I noticed two things. >>> >>> First, it didn't build by running rpmbuild because the rlib.spec.in=20 >>> wasn't >>> updated when the postgre -> posgres renaming was done. >>> =20 >> >> >> Applied thanks! >> =20 >> > > You're welcome. :-) > >>> Second, it crashes on reports that worked earlier. I tried to track=20 >>> it down, >>> what I found out is that 1.3.5 works but 1.3.6 doesn't. I don't have=20 >>> a 32 bit >>> machine at hand, so I don't know whether it's just a 64-bit=20 >>> uncleanliness or >>> something else. Still hunting... >>> =20 >> >> >> Yea.. I changed things around quite a bit in order to support the "mem= o" >> fields. Valgrind?? It's clean for me on 32 bit >> >> - Bob > Please, disregard my previous analysis and patch. Here's a better one. It's still stands that g_iconv() doesn't allocate the output buffer but g_convert() and g_convert_with_iconv() do. As a converter is already initialized with g_iconv_open() it's better to use g_convert_with_iconv()= . In libsrc/charencoder.c::rlib_charencoder_convert() there are three possible paths, two allocates the result string with g_strdup() but the third that uses g_iconv doesn't. Using g_convert_with_iconv() in the third path makes this function behave consistently and closes one crasher bug. Deleting the memset() in this function avoids another crash, as the pointer passed here is mostly NULL. There is another crasher bug in libsrc/layout.c, the loop starting at line 606 extends the string with spaces and the loop condition goes to the very end of the allocated string. The variable assignment after the loop "*ptr =3D '\0';" writes one byte after the allocated space= . Changing the loop condition from (lim-- > 0) to (--lim > 0) closes this b= ug. OK, RLIB now doesn't crash when it's compiled using GCC 4.0 but the fields in the report PDF is empty. When I compile it with gcc-3.4= .4 it still crashes but even valgrind doesn't show anything. I just get a "NUTS we crashed" message. :-( Going back to 1.3.5 makes my crashes go away. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Zoltan B. <zb...@du...> - 2005-12-21 22:55:55
|
Bob Doan =EDrta:
>On Sat, 2005-12-17 at 16:46 +0100, Zoltan Boszormenyi wrote:
> =20
>
>>Hi,
>>
>>long time no see, erm, write? :-)
>> =20
>>
>
>Hey!
>
> =20
>
>>I tried the latest CVS version of RLIB and I noticed two things.
>>
>>First, it didn't build by running rpmbuild because the rlib.spec.in was=
n't
>>updated when the postgre -> posgres renaming was done.
>> =20
>>
>
>Applied thanks!
> =20
>
You're welcome. :-)
>>Second, it crashes on reports that worked earlier. I tried to track it =
down,
>>what I found out is that 1.3.5 works but 1.3.6 doesn't. I don't have a=20
>>32 bit
>>machine at hand, so I don't know whether it's just a 64-bit uncleanline=
ss or
>>something else. Still hunting...
>> =20
>>
>
>Yea.. I changed things around quite a bit in order to support the "memo"
>fields. Valgrind?? It's clean for me on 32 bit
>
>- Bob
> =20
>
I got this short log from valgrind-3.1.0:
****************************************************
=3D=3D25122=3D=3D Memcheck, a memory error detector.
=3D=3D25122=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Sewar=
d et al.
=3D=3D25122=3D=3D Using LibVEX rev 1471, a library for dynamic binary tra=
nslation.
=3D=3D25122=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LL=
P.
=3D=3D25122=3D=3D Using valgrind-3.1.0, a dynamic binary instrumentation =
framework.
=3D=3D25122=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Sewar=
d et al.
=3D=3D25122=3D=3D For more details, rerun with: -v
=3D=3D25122=3D=3D
1
2
3
4
5
rep
=3D=3D25122=3D=3D Invalid write of size 1
=3D=3D25122=3D=3D at 0x4A1AED0: memset (mac_replace_strmem.c:464)
=3D=3D25122=3D=3D by 0x4C4E608: rlib_charencoder_convert (charencoder.=
c:62)
=3D=3D25122=3D=3D by 0x4C36707: rlib_resolve_field_value (resolution.c=
:81)
=3D=3D25122=3D=3D by 0x4C3A6FB: rlib_operand_get_value (pcode.c:784)
=3D=3D25122=3D=3D by 0x4C3A89A: execute_pcode (pcode.c:862)
=3D=3D25122=3D=3D by 0x4C3D92C: rlib_pcode_operator_iif=20
(pcode_op_functions.c:1008)
=3D=3D25122=3D=3D by 0x4C3A871: execute_pcode (pcode.c:866)
=3D=3D25122=3D=3D by 0x4C3A981: rlib_execute_pcode (pcode.c:891)
=3D=3D25122=3D=3D by 0x4C3FD32: rlib_process_expression_variables=20
(variables.c:123)
=3D=3D25122=3D=3D by 0x4C376E0: rlib_resolve_report_fields (resolution=
.c:351)
=3D=3D25122=3D=3D by 0x4C2E6CA: rlib_evaulate_single_report_variables=20
(reportgen.c:569)
=3D=3D25122=3D=3D by 0x4C2ECA5: rlib_make_report (reportgen.c:614)
=3D=3D25122=3D=3D Address 0x0 is not stack'd, malloc'd or (recently) fre=
e'd
** NUTS.. WE CRASHED
=3D=3D25122=3D=3D
=3D=3D25122=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 11=
from 4)
=3D=3D25122=3D=3D malloc/free: in use at exit: 607,205 bytes in 839 block=
s.
=3D=3D25122=3D=3D malloc/free: 7,619 allocs, 6,780 frees, 13,266,761 byte=
s=20
allocated.
=3D=3D25122=3D=3D For counts of detected errors, rerun with: -v
=3D=3D25122=3D=3D searching for pointers to 839 not-freed blocks.
=3D=3D25122=3D=3D checked 1,497,592 bytes.
=3D=3D25122=3D=3D
=3D=3D25122=3D=3D LEAK SUMMARY:
=3D=3D25122=3D=3D definitely lost: 5 bytes in 1 blocks.
=3D=3D25122=3D=3D possibly lost: 0 bytes in 0 blocks.
=3D=3D25122=3D=3D still reachable: 607,200 bytes in 838 blocks.
=3D=3D25122=3D=3D suppressed: 0 bytes in 0 blocks.
=3D=3D25122=3D=3D Use --leak-check=3Dfull to see details of leaked memory=
.
****************************************************
And it seems to be caused by this difference between 1.3.5 and 1.3.6:
diff -urN rlib-1.3.5/libsrc/resolution.c rlib-1.3.6/libsrc/resolution.c
--- rlib-1.3.5/libsrc/resolution.c 2005-08-15 21:02:36.000000000 +02=
00
+++ rlib-1.3.6/libsrc/resolution.c 2005-11-01 16:53:40.000000000 +01=
00
@@ -59,9 +59,8 @@
gchar * rlib_resolve_field_value(rlib *r, struct rlib_resultset_field=20
*rf) {
struct input_filter *rs =3D INPUT(r, rf->resultset);
#if !DISABLE_UTF8
- gchar encoded_buf[MAXSTRLEN];
gsize slen, elen;
- gchar *ptr=3D encoded_buf;
+ gchar *ptr =3D NULL;
#endif
gchar *str;
@@ -79,8 +78,7 @@
else {
slen =3D strlen(str);
elen =3D MAXSTRLEN;
- rlib_charencoder_convert(rs->info.encoder, &str, &slen,=20
&ptr, &elen);
- return g_strdup(encoded_buf);
+ return rlib_charencoder_convert(rs->info.encoder, &str,=20
&slen, &ptr, &elen);
}
#endif
}
"ptr" is NULL and rlib_charencoder_convert does a memset() on that.
Deleting the memset() line wouldn't solve it, there are two other problem=
s
with this change in RLIB-1.3.6.
First, g_iconv() is only a wrapper over native iconv() and that doesn't=20
allocate
the output buffer for you, you have to pass an address of a pointer to an
already allocated buffer.
Second, rlib_charencoder_convert() returns a gint, the result of g_iconv(=
)
which is the number of a non-reversible conversions. Just like native=20
iconv().
Attached is patch which restores rlib_resolve_field_value() into a=20
working state
but not blindly to the original. I kept your intent of reducing stack usa=
ge.
After fixing it I found the same problem in=20
layout.c::rlib_layout_text_string(), too.
And every other call sites of rlib_encode_text() and=20
rlib_charencoder_convert()
should be audited, too.
And I got one double free() or free() without malloc() below.
****************************************************
=3D=3D12883=3D=3D Memcheck, a memory error detector.
=3D=3D12883=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Sewar=
d et al.
=3D=3D12883=3D=3D Using LibVEX rev 1471, a library for dynamic binary tra=
nslation.
=3D=3D12883=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LL=
P.
=3D=3D12883=3D=3D Using valgrind-3.1.0, a dynamic binary instrumentation =
framework.
=3D=3D12883=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Sewar=
d et al.
=3D=3D12883=3D=3D For more details, rerun with: -v
=3D=3D12883=3D=3D
1
2
3
4
5
rep
=3D=3D12883=3D=3D Invalid free() / delete / delete[]
=3D=3D12883=3D=3D at 0x4A195DD: free (vg_replace_malloc.c:235)
=3D=3D12883=3D=3D by 0x4C3A584: rlib_value_free (pcode.c:745)
=3D=3D12883=3D=3D by 0x4C3D3B7: rlib_pcode_operator_val=20
(pcode_op_functions.c:885)
=3D=3D12883=3D=3D by 0x4C3A941: execute_pcode (pcode.c:866)
=3D=3D12883=3D=3D by 0x4C3D9FC: rlib_pcode_operator_iif=20
(pcode_op_functions.c:1010)
=3D=3D12883=3D=3D by 0x4C3A941: execute_pcode (pcode.c:866)
=3D=3D12883=3D=3D by 0x4C3AA51: rlib_execute_pcode (pcode.c:891)
=3D=3D12883=3D=3D by 0x4C3FE02: rlib_process_expression_variables=20
(variables.c:123)
=3D=3D12883=3D=3D by 0x4C377B0: rlib_resolve_report_fields (resolution=
.c:353)
=3D=3D12883=3D=3D by 0x4C2E78A: rlib_evaulate_single_report_variables=20
(reportgen.c:568)
=3D=3D12883=3D=3D by 0x4C2ED65: rlib_make_report (reportgen.c:613)
=3D=3D12883=3D=3D by 0x4C359AB: rlib_execute (api.c:202)
=3D=3D12883=3D=3D Address 0x8B3B2A1 is 1 bytes inside a block of size 1,=
024 alloc'd
=3D=3D12883=3D=3D at 0x4A18A86: malloc (vg_replace_malloc.c:149)
=3D=3D12883=3D=3D by 0x4C367B6: rlib_resolve_field_value (resolution.c=
:80)
=3D=3D12883=3D=3D by 0x4C3A7CB: rlib_operand_get_value (pcode.c:784)
=3D=3D12883=3D=3D by 0x4C3A96A: execute_pcode (pcode.c:862)
=3D=3D12883=3D=3D by 0x4C3D9FC: rlib_pcode_operator_iif=20
(pcode_op_functions.c:1010)
=3D=3D12883=3D=3D by 0x4C3A941: execute_pcode (pcode.c:866)
=3D=3D12883=3D=3D by 0x4C3AA51: rlib_execute_pcode (pcode.c:891)
=3D=3D12883=3D=3D by 0x4C3FE02: rlib_process_expression_variables=20
(variables.c:123)
=3D=3D12883=3D=3D by 0x4C377B0: rlib_resolve_report_fields (resolution=
.c:353)
=3D=3D12883=3D=3D by 0x4C2E78A: rlib_evaulate_single_report_variables=20
(reportgen.c:568)
=3D=3D12883=3D=3D by 0x4C2ED65: rlib_make_report (reportgen.c:613)
=3D=3D12883=3D=3D by 0x4C359AB: rlib_execute (api.c:202)
=3D=3D12883=3D=3D
=3D=3D12883=3D=3D Conditional jump or move depends on uninitialised value=
(s)
=3D=3D12883=3D=3D at 0x4A1AEDD: memset (mac_replace_strmem.c:464)
=3D=3D12883=3D=3D by 0x4C4E6D8: rlib_charencoder_convert (charencoder.=
c:62)
=3D=3D12883=3D=3D by 0x4C2EF82: ??? (layout.c:122)
=3D=3D12883=3D=3D by 0x4C2FB47: ??? (layout.c:384)
=3D=3D12883=3D=3D by 0x4C317E2: ??? (layout.c:945)
=3D=3D12883=3D=3D by 0x4C32A33: ??? (layout.c:1088)
=3D=3D12883=3D=3D by 0x4C32BF7: rlib_layout_report_output (layout.c:11=
05)
=3D=3D12883=3D=3D by 0x4C30058: rlib_layout_init_part_page (layout.c:1=
209)
=3D=3D12883=3D=3D by 0x4C2EB57: rlib_make_report (reportgen.c:619)
=3D=3D12883=3D=3D by 0x4C359AB: rlib_execute (api.c:202)
=3D=3D12883=3D=3D by 0x4B1E214: report_szallito (in=20
/usr/lib64/libptgriport.so.1.0.0)=3D=3D12883=3D=3D by 0x400A80: (withi=
n=20
/usr/bin/ptgriport)
=3D=3D12883=3D=3D
=3D=3D12883=3D=3D Invalid write of size 1
=3D=3D12883=3D=3D at 0x4A1AED0: memset (mac_replace_strmem.c:464)
=3D=3D12883=3D=3D by 0x4C4E6D8: rlib_charencoder_convert (charencoder.=
c:62)
=3D=3D12883=3D=3D by 0x4C2EF82: ??? (layout.c:122)
=3D=3D12883=3D=3D by 0x4C2FB47: ??? (layout.c:384)
=3D=3D12883=3D=3D by 0x4C317E2: ??? (layout.c:945)
=3D=3D12883=3D=3D by 0x4C32A33: ??? (layout.c:1088)
=3D=3D12883=3D=3D by 0x4C32BF7: rlib_layout_report_output (layout.c:11=
05)
=3D=3D12883=3D=3D by 0x4C30058: rlib_layout_init_part_page (layout.c:1=
209)
=3D=3D12883=3D=3D by 0x4C2EB57: rlib_make_report (reportgen.c:619)
=3D=3D12883=3D=3D by 0x4C359AB: rlib_execute (api.c:202)
=3D=3D12883=3D=3D by 0x4B1E214: report_szallito (in=20
/usr/lib64/libptgriport.so.1.0.0)=3D=3D12883=3D=3D by 0x400A80: (withi=
n=20
/usr/bin/ptgriport)
=3D=3D12883=3D=3D Address 0x8B7CCA0 is 0 bytes after a block of size 1,0=
24 alloc'd
=3D=3D12883=3D=3D at 0x4A18A86: malloc (vg_replace_malloc.c:149)
=3D=3D12883=3D=3D by 0x3B52A2CAAE: g_malloc (in=20
/usr/lib64/libglib-2.0.so.0.400.8)
=3D=3D12883=3D=3D by 0x4C2FB32: ??? (layout.c:383)
=3D=3D12883=3D=3D by 0x4C317E2: ??? (layout.c:945)
=3D=3D12883=3D=3D by 0x4C32A33: ??? (layout.c:1088)
=3D=3D12883=3D=3D by 0x4C32BF7: rlib_layout_report_output (layout.c:11=
05)
=3D=3D12883=3D=3D by 0x4C30058: rlib_layout_init_part_page (layout.c:1=
209)
=3D=3D12883=3D=3D by 0x4C2EB57: rlib_make_report (reportgen.c:619)
=3D=3D12883=3D=3D by 0x4C359AB: rlib_execute (api.c:202)
=3D=3D12883=3D=3D by 0x4B1E214: report_szallito (in=20
/usr/lib64/libptgriport.so.1.0.0)=3D=3D12883=3D=3D by 0x400A80: (withi=
n=20
/usr/bin/ptgriport)
=3D=3D12883=3D=3D by 0x4E874BA: __libc_start_main (in /lib64/tls/libc-=
2.3.6.so)
=3D=3D12883=3D=3D
=3D=3D12883=3D=3D Invalid write of size 1
=3D=3D12883=3D=3D at 0x4A1AEDD: memset (mac_replace_strmem.c:464)
=3D=3D12883=3D=3D by 0x4C4E6D8: rlib_charencoder_convert (charencoder.=
c:62)
=3D=3D12883=3D=3D by 0x4C2EF82: ??? (layout.c:122)
=3D=3D12883=3D=3D by 0x4C2FB47: ??? (layout.c:384)
=3D=3D12883=3D=3D by 0x4C317E2: ??? (layout.c:945)
=3D=3D12883=3D=3D by 0x4C32A33: ??? (layout.c:1088)
=3D=3D12883=3D=3D by 0x4C32BF7: rlib_layout_report_output (layout.c:11=
05)
=3D=3D12883=3D=3D by 0x4C30058: rlib_layout_init_part_page (layout.c:1=
209)
=3D=3D12883=3D=3D by 0x4C2EB57: rlib_make_report (reportgen.c:619)
=3D=3D12883=3D=3D by 0x4C359AB: rlib_execute (api.c:202)
=3D=3D12883=3D=3D by 0x4B1E214: report_szallito (in=20
/usr/lib64/libptgriport.so.1.0.0)=3D=3D12883=3D=3D by 0x400A80: (withi=
n=20
/usr/bin/ptgriport)
=3D=3D12883=3D=3D Address 0x8B7CCA1 is 1 bytes after a block of size 1,0=
24 alloc'd
=3D=3D12883=3D=3D at 0x4A18A86: malloc (vg_replace_malloc.c:149)
=3D=3D12883=3D=3D by 0x3B52A2CAAE: g_malloc (in=20
/usr/lib64/libglib-2.0.so.0.400.8)
=3D=3D12883=3D=3D by 0x4C2FB32: ??? (layout.c:383)
=3D=3D12883=3D=3D by 0x4C317E2: ??? (layout.c:945)
=3D=3D12883=3D=3D by 0x4C32A33: ??? (layout.c:1088)
=3D=3D12883=3D=3D by 0x4C32BF7: rlib_layout_report_output (layout.c:11=
05)
=3D=3D12883=3D=3D by 0x4C30058: rlib_layout_init_part_page (layout.c:1=
209)
=3D=3D12883=3D=3D by 0x4C2EB57: rlib_make_report (reportgen.c:619)
=3D=3D12883=3D=3D by 0x4C359AB: rlib_execute (api.c:202)
=3D=3D12883=3D=3D by 0x4B1E214: report_szallito (in=20
/usr/lib64/libptgriport.so.1.0.0)=3D=3D12883=3D=3D by 0x400A80: (withi=
n=20
/usr/bin/ptgriport)
=3D=3D12883=3D=3D by 0x4E874BA: __libc_start_main (in /lib64/tls/libc-=
2.3.6.so)
=3D=3D12883=3D=3D
=3D=3D12883=3D=3D More than 100000 total errors detected. I'm not report=
ing any=20
more.
=3D=3D12883=3D=3D Final error counts will be inaccurate. Go fix your pro=
gram!
=3D=3D12883=3D=3D Rerun with --error-limit=3Dno to disable this cutoff. =
Note
=3D=3D12883=3D=3D that errors may occur in your program without prior war=
ning from
=3D=3D12883=3D=3D Valgrind, because errors are no longer being displayed.
=3D=3D12883=3D=3D
valgrind: m_mallocfree.c:170 (mk_plain_bszB): Assertion 'bszB !=3D 0' fai=
led.
=3D=3D12883=3D=3D at 0x600110F8: report_and_quit (m_libcassert.c:122)
=3D=3D12883=3D=3D by 0x60011364: vgPlain_assert_fail (m_libcassert.c:1=
85)
=3D=3D12883=3D=3D by 0x6001A917: vgPlain_arena_malloc (m_mallocfree.c:=
170)
=3D=3D12883=3D=3D by 0x600335C2: vgPlain_cli_malloc (replacemalloc_cor=
e.c:101)
=3D=3D12883=3D=3D by 0x6000157C: vgMAC_malloc (mac_malloc_wrappers.c:1=
92)
=3D=3D12883=3D=3D by 0x6003522E: do_client_request (scheduler.c:987)
=3D=3D12883=3D=3D by 0x60034BBE: vgPlain_scheduler (scheduler.c:721)
=3D=3D12883=3D=3D by 0x6004787E: thread_wrapper (syswrap-linux.c:86)
=3D=3D12883=3D=3D by 0x60047975: run_a_thread_NORETURN (syswrap-linux.=
c:119)
sched status:
running_tid=3D1
Thread 1: status =3D VgTs_Runnable
=3D=3D12883=3D=3D at 0x4A18A86: malloc (vg_replace_malloc.c:149)
=3D=3D12883=3D=3D by 0x4ECCA12: vasprintf (in /lib64/tls/libc-2.3.6.so=
)
=3D=3D12883=3D=3D by 0x3B52A4A1EF: g_vasprintf (in=20
/usr/lib64/libglib-2.0.so.0.400.8)=3D=3D12883=3D=3D by 0x3B52A3AF69:=20
g_strdup_vprintf (in /usr/lib64/libglib-2.0.so.0.400.8)
=3D=3D12883=3D=3D by 0x4C3845F: rlogit (util.c:195)
=3D=3D12883=3D=3D by 0x4C384A4: ??? (util.c:90)
=3D=3D12883=3D=3D by 0x4E9940F: (within /lib64/tls/libc-2.3.6.so)
=3D=3D12883=3D=3D by 0x4C4E6D8: rlib_charencoder_convert (charencoder.=
c:62)
=3D=3D12883=3D=3D by 0x4C2EF82: ??? (layout.c:122)
=3D=3D12883=3D=3D by 0x4C2FB47: ??? (layout.c:384)
=3D=3D12883=3D=3D by 0x4C317E2: ??? (layout.c:945)
=3D=3D12883=3D=3D by 0x4C32A33: ??? (layout.c:1088)
=3D=3D12883=3D=3D by 0x4C32BF7: rlib_layout_report_output (layout.c:11=
05)
=3D=3D12883=3D=3D by 0x4C30058: rlib_layout_init_part_page (layout.c:1=
209)
=3D=3D12883=3D=3D by 0x4C2EB57: rlib_make_report (reportgen.c:619)
=3D=3D12883=3D=3D by 0x4C359AB: rlib_execute (api.c:202)
=3D=3D12883=3D=3D by 0x4B1E214: report_szallito (in=20
/usr/lib64/libptgriport.so.1.0.0)=3D=3D12883=3D=3D by 0x400A80: (withi=
n=20
/usr/bin/ptgriport)
=3D=3D12883=3D=3D by 0x4E874BA: __libc_start_main (in /lib64/tls/libc-=
2.3.6.so)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
****************************************************
Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi
|
|
From: Bob D. <bd...@si...> - 2005-12-19 20:40:24
|
Hym... You can use query="'something'" in the XML Would that do??? On Sat, 2005-12-17 at 21:22 +0100, Zoltan Boszormenyi wrote: > Hi, > > I have a problem creating a report in RLIB in which I would like to > put fields from a one-row query into either ReportHeader or PageHeader. > If I define my queries in this order: > > rlib_add_query_as(r, "mainsource", query2, "headerquery"); > rlib_add_query_as(r, "mainsource", query1, "list"); > > then only the first row of the list appears. If they are defined in > reverse order, > everything appears correctly, but from the fact above, I guess the my > "headerquery" > is actually run for every row of my "list" query. > > Hence the request for enhancement: I would like RLIB to recognize this > condition > automatically or some queries could be tagged for such application. > It would obviously increase performance as these kinds of queries would > run through > only once. > > The same applies for PageHeader with a little twist. There may be > applications > where a PageHeader would be the same on every page or they may differ. > If a query has only one row, it's field values should be presented on > every page. > If the query has more than one row, then it should be selectable whether > the data from the first row would appear on every page or the rows are > iterated > for the pages. You could probably use a N to 1 follower here and align the datafield with r.pageno Cheers - Bob |
|
From: Bob D. <bd...@si...> - 2005-12-19 20:37:40
|
On Sat, 2005-12-17 at 16:46 +0100, Zoltan Boszormenyi wrote: > Hi, > > long time no see, erm, write? :-) Hey! > > I tried the latest CVS version of RLIB and I noticed two things. > > First, it didn't build by running rpmbuild because the rlib.spec.in wasn't > updated when the postgre -> posgres renaming was done. Applied thanks! > > Second, it crashes on reports that worked earlier. I tried to track it down, > what I found out is that 1.3.5 works but 1.3.6 doesn't. I don't have a > 32 bit > machine at hand, so I don't know whether it's just a 64-bit uncleanliness or > something else. Still hunting... Yea.. I changed things around quite a bit in order to support the "memo" fields. Valgrind?? It's clean for me on 32 bit - Bob |
|
From: Zoltan B. <zb...@du...> - 2005-12-19 09:23:54
|
Hi, long time no see, erm, write? :-) I tried the latest CVS version of RLIB and I noticed two things. First, it didn't build by running rpmbuild because the rlib.spec.in wasn'= t updated when the postgre -> posgres renaming was done. Second, it crashes on reports that worked earlier. I tried to track it do= wn, what I found out is that 1.3.5 works but 1.3.6 doesn't. I don't have a=20 32 bit machine at hand, so I don't know whether it's just a 64-bit uncleanliness= or something else. Still hunting... Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Zoltan B. <zb...@du...> - 2005-12-19 09:22:25
|
Hi, I have a problem creating a report in RLIB in which I would like to put fields from a one-row query into either ReportHeader or PageHeader. If I define my queries in this order: rlib_add_query_as(r, "mainsource", query2, "headerquery"); rlib_add_query_as(r, "mainsource", query1, "list"); then only the first row of the list appears. If they are defined in=20 reverse order, everything appears correctly, but from the fact above, I guess the my=20 "headerquery" is actually run for every row of my "list" query. Hence the request for enhancement: I would like RLIB to recognize this=20 condition automatically or some queries could be tagged for such application. It would obviously increase performance as these kinds of queries would=20 run through only once. The same applies for PageHeader with a little twist. There may be=20 applications where a PageHeader would be the same on every page or they may differ. If a query has only one row, it's field values should be presented on=20 every page. If the query has more than one row, then it should be selectable whether the data from the first row would appear on every page or the rows are=20 iterated for the pages. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Bob D. <bd...@si...> - 2005-12-01 19:14:04
|
RLIB 1.3.6 is released! RLIB 1.3.6 adds support for precalculated variable values, multi line fields (memo fields), and meta data. Precaculated variable values give you the variable value as it would normally be at the end of the report or break footer (If you have reset on breaks). This way you can have the totals and subtotals in header sections, or use these values in expressions on normal detail lines. Multi Line Fields (Memo Fields) allow you to have text span more then one line in a column. An example of this would be comment field. See: http://rlib.sicom.com/multiline.pdf MetaData allows you to define data field types coming from data sources. If you had a field that need to always be upper case you can now define that in metadata, instead of calling "upper" on every instance of its usage. Error reporting continues to improve. Enjoy! Download it from sourceforge.net - Bob |
|
From: Bob D. <bd...@si...> - 2005-10-28 12:33:37
|
You have to compile RLIB. What operating system are you using? - bob On Fri, 2005-10-28 at 10:55 +0700, Pic...@KA... wrote: > > I'm using PHP > and I had download RLIB Report engine to build report > in example.php it contain " dl(rlib.so)" > > I'm try to search rlib.so where is it but not found. > Would u help me please ? > > Thank you . > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Ksec IT Support > Pichai Kainak > Pic...@Ka... > Tel. : 026960109 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > |
|
From: <Pic...@KA...> - 2005-10-28 03:56:17
|
I'm using PHP and I had download RLIB Report engine to build report in example.php it contain " dl(rlib.so)" I'm try to search rlib.so where is it but not found. Would u help me please ? Thank you . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ksec IT Support Pichai Kainak Pic...@Ka... Tel. : 026960109 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
|
From: Bob D. <bd...@si...> - 2005-10-26 13:56:38
|
Hi, I don't have MacOSX Binaries but I would be happy to help you get RLIB built if you would be willing to package it for MaxOSX. What problems are you running into?? On Wed, 2005-10-26 at 08:39 -0400, Jeff Kopmanis wrote: > Rlib's a great program, but I'm have a devil of a time getting it to compile > under MacOSX. I'm not particularly picky about binaries, so is there anyone > out there that's put together a binary or even a .pkg package that we could > install? Seems like the Mac world could really benefit from Rlib if it were > a bit more accessable. > > If not, if anyone's got it to compile, I'd appreciate any build notes you > could pass along. > > -Jeff. :) > > -- University of Michigan Department of Mathematics -- > Jeff Kopmanis, Supervisor, Information Technology Group > B736 East Hall, 530 Church St., Ann Arbor, MI 48109-1043 > Office: 734-615-6038 http://www-personal.umich.edu/~kopmanis > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Rlib-devel mailing list > Rli...@li... > https://lists.sourceforge.net/lists/listinfo/rlib-devel |
|
From: Jeff K. <kop...@um...> - 2005-10-26 12:39:30
|
Rlib's a great program, but I'm have a devil of a time getting it to compile under MacOSX. I'm not particularly picky about binaries, so is there anyone out there that's put together a binary or even a .pkg package that we could install? Seems like the Mac world could really benefit from Rlib if it were a bit more accessable. If not, if anyone's got it to compile, I'd appreciate any build notes you could pass along. -Jeff. :) -- University of Michigan Department of Mathematics -- Jeff Kopmanis, Supervisor, Information Technology Group B736 East Hall, 530 Church St., Ann Arbor, MI 48109-1043 Office: 734-615-6038 http://www-personal.umich.edu/~kopmanis |
|
From: Bob D. <bd...@si...> - 2005-10-25 15:35:52
|
All, I have a pre release of RLIB 1.3.6 I would like you to try http://www.sicom.com/~bdoan/rlib-1.3.6.tar.gz The big changes include: 1) Multi Line Support (Comment Fields, Memo Fields.. what ever you want to call them) See: http://www.sicom.com/~bdoan/report.pdf 2) Official MetaData Support. This allows you to tell rlib that a "field" is a specific formula and to use it that way across the report.. Ie: <MetaData> <MetaData name="somenumberfield" value="val(somenumberfield)"/> <MetaData name="last_name" value="upper(last_name)"/> </MetaData> Anywhere in the report you can reference the above fields normally and will be what you requested (In the case of somenumberfield it will always be val'd) 3) Precalculated variable values! This is useful if you need the break subtotal in the break header (Or Earlier). Or If you want to have the report totals at the top of the report. This slows RLIB down a tad because it has to now be a two pass layout engine. To use it include precalculate="yes" in the variable definition 4) RPDF is now a lot faster *********************** There's a good chance I could have broke the layout engine (Especially for non English speaking folks) Please let me know how it goes *********************** 5) Also suppressPageHeaderFirstPage works again Enjoy! - bob |
|
From: Bob D. <bd...@si...> - 2005-10-07 20:01:06
|
Hymmmmm... I ** guess ** that will work. Understand you take a major performance hit for doing it that way. I'm assuming ATT has a lot more then 5k of telephone calls. If you want reports of 10,000+ pages in PDF to be under a few seconds you will have to use the detail section. If you don't care about speed do what you want ;) - Bob On Fri, 2005-10-07 at 15:42 -0400, Denis Kokarev wrote: > Thanks, Bob. You may want to fix betabook.pdf on page 9 where it says: > > Breaks also have BreakFields. An expression on how it breaks. There > can be more then one and > it has a value. The value is an expression. > > We're trying to generate report templates automatically, that's why > always trying to use Breaks, even for detail reports. > > > Bob Doan wrote: > > Lisa, > > > > Having multiple break fields as you have defined is not officially > > supported in RLIB 1.3.x > > > > I also don't think it's an issue because you were not outputting rows, > > but rather the break footer for common rows. (Hence the different number > > of rows) > > > > The new way of doing it is with a simple expression: > > > > <Break name="Detail" newpage="no"> > > <BreakFields> > > <BreakField value="Conn_Date+Conn_Time+Orig"/> > > </BreakFields> > > <BreakFooter> > > > > That said, I think you are a little confused w/ breaks?? Maybe?? > > > > I've attached a reworked example of what you sent. (att.xml) > > > > It uses the "Detail" section of RLIB (this way all rows come out). I > > also added in a very simple break as an example (Show a big line of text > > when the date changes). > > > > > > Cheers > > > > - Bob > > > > > > ____________________________________________________________________ > > > > <?xml version="1.0"?> > > <!DOCTYPE report> > > <Report fontSize="8"> > > <ReportHeader> > > <Output> > > <Line/> > > <Line fontsize="12"><literal width="80" align="center" bold="yes">Standard Call Detail</literal></Line> > > <Line/> > > <HorizontalLine bgcolor="'black'"/> > > <Line/> > > </Output> > > </ReportHeader> > > > > <Breaks> > > <Break name="Detail" newpage="no"> > > <BreakFields> > > <BreakField value="Conn_Date"/> > > </BreakFields> > > <BreakFooter> > > <Output> > > <Line bold="yes" fontSize="30"> > > <literal>A DAY HAS PASSED</literal> > > </Line> > > </Output> > > </BreakFooter> > > </Break> > > </Breaks> > > > > <ReportFooter> > > <Output> > > <HorizontalLine bgcolor="'black'"/> > > <Line> > > <field value="''" width="12"/> > > <literal width="1"/> > > <field value="''" width="8"/> > > <literal width="1"/> > > <field value="''" width="15"/> > > <literal width="1"/> > > <field value="''" width="15"/> > > <literal width="1"/> > > <field value="''" width="15"/> > > <literal width="1"/> > > <field value="''" width="10"/> > > <literal width="1"/> > > <field value="''" width="10"/> > > <literal width="1"/> > > </Line> > > </Output> > > </ReportFooter> > > > > <Detail> > > <FieldHeaders> > > <Output> > > <Line> > > <field value="'Connect'" width="12" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="'Connect'" width="8" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="'Originating'" width="15" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="'Dialed'" width="15" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="'RTN'" width="15" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="'Elapsed'" width="10" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="'CDC'" width="10" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > </Line> > > <Line> > > <field value="'Date'" width="12" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="'Time'" width="8" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="'Number'" width="15" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="'Number'" width="15" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="''" width="15" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="'Time'" width="10" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > <field value="''" width="10" align="center" bold="yes" bgcolor="'silver'"/> > > <literal width="1"/> > > </Line> > > </Output> > > </FieldHeaders> > > <FieldDetails> > > <Output> > > <Line> > > <field value="Conn_Date" width="12" align="right" /> > > <literal width="1"/> > > <field value="Conn_Time" width="8" align="right" /> > > <literal width="1"/> > > <field value="Orig" width="15" align="right" /> > > <literal width="1"/> > > <field value="Dial" width="15" align="right" /> > > <literal width="1"/> > > <field value="Rtn" width="15" align="right" /> > > <literal width="1"/> > > <field value="val(Elapsed_Time)" width="10" align="right" /> > > <literal width="1"/> > > <field value="val(Cdc)" width="10" align="right" format="'%2d'" /> > > <literal width="1"/> > > </Line> > > </Output> > > </FieldDetails> > > </Detail> > > > > > > <Variables> > > </Variables> > > </Report> > > |
|
From: Lisa M. K. <li...@re...> - 2005-10-07 19:44:14
|
Thanks Bob! -Lisa Bob Doan wrote: >Lisa, > >Having multiple break fields as you have defined is not officially >supported in RLIB 1.3.x > >I also don't think it's an issue because you were not outputting rows, >but rather the break footer for common rows. (Hence the different number >of rows) > >The new way of doing it is with a simple expression: > ><Break name="Detail" newpage="no"> > <BreakFields> > <BreakField value="Conn_Date+Conn_Time+Orig"/> > </BreakFields> ><BreakFooter> > >That said, I think you are a little confused w/ breaks?? Maybe?? > >I've attached a reworked example of what you sent. (att.xml) > >It uses the "Detail" section of RLIB (this way all rows come out). I >also added in a very simple break as an example (Show a big line of text >when the date changes). > > >Cheers > >- Bob > > |
|
From: Denis K. <ko...@re...> - 2005-10-07 19:43:11
|
Thanks, Bob. You may want to fix betabook.pdf on page 9 where it says: Breaks also have BreakFields. An expression on how it breaks. There can be more then one and it has a value. The value is an expression. We're trying to generate report templates automatically, that's why always trying to use Breaks, even for detail reports. Bob Doan wrote: >Lisa, > >Having multiple break fields as you have defined is not officially >supported in RLIB 1.3.x > >I also don't think it's an issue because you were not outputting rows, >but rather the break footer for common rows. (Hence the different number >of rows) > >The new way of doing it is with a simple expression: > ><Break name="Detail" newpage="no"> > <BreakFields> > <BreakField value="Conn_Date+Conn_Time+Orig"/> > </BreakFields> ><BreakFooter> > >That said, I think you are a little confused w/ breaks?? Maybe?? > >I've attached a reworked example of what you sent. (att.xml) > >It uses the "Detail" section of RLIB (this way all rows come out). I >also added in a very simple break as an example (Show a big line of text >when the date changes). > > >Cheers > >- Bob > > >------------------------------------------------------------------------ > ><?xml version="1.0"?> ><!DOCTYPE report> ><Report fontSize="8"> ><ReportHeader> ><Output> > <Line/> > <Line fontsize="12"><literal width="80" align="center" bold="yes">Standard Call Detail</literal></Line> > <Line/> > <HorizontalLine bgcolor="'black'"/> > <Line/> ></Output> ></ReportHeader> > ><Breaks> > <Break name="Detail" newpage="no"> > <BreakFields> > <BreakField value="Conn_Date"/> > </BreakFields> > <BreakFooter> > <Output> > <Line bold="yes" fontSize="30"> > <literal>A DAY HAS PASSED</literal> > </Line> > </Output> > </BreakFooter> > </Break> ></Breaks> > ><ReportFooter> > <Output> > <HorizontalLine bgcolor="'black'"/> > <Line> > <field value="''" width="12"/> > <literal width="1"/> > <field value="''" width="8"/> > <literal width="1"/> > <field value="''" width="15"/> > <literal width="1"/> > <field value="''" width="15"/> > <literal width="1"/> > <field value="''" width="15"/> > <literal width="1"/> > <field value="''" width="10"/> > <literal width="1"/> > <field value="''" width="10"/> > <literal width="1"/> > </Line> > </Output> ></ReportFooter> > ><Detail> > <FieldHeaders> > <Output> > <Line> > <field value="'Connect'" width="12" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="'Connect'" width="8" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="'Originating'" width="15" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="'Dialed'" width="15" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="'RTN'" width="15" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="'Elapsed'" width="10" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="'CDC'" width="10" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > </Line> > <Line> > <field value="'Date'" width="12" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="'Time'" width="8" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="'Number'" width="15" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="'Number'" width="15" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="''" width="15" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="'Time'" width="10" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > <field value="''" width="10" align="center" bold="yes" bgcolor="'silver'"/> > <literal width="1"/> > </Line> > </Output> > </FieldHeaders> > <FieldDetails> > <Output> > <Line> > <field value="Conn_Date" width="12" align="right" /> > <literal width="1"/> > <field value="Conn_Time" width="8" align="right" /> > <literal width="1"/> > <field value="Orig" width="15" align="right" /> > <literal width="1"/> > <field value="Dial" width="15" align="right" /> > <literal width="1"/> > <field value="Rtn" width="15" align="right" /> > <literal width="1"/> > <field value="val(Elapsed_Time)" width="10" align="right" /> > <literal width="1"/> > <field value="val(Cdc)" width="10" align="right" format="'%2d'" /> > <literal width="1"/> > </Line> > </Output> > </FieldDetails> ></Detail> > > ><Variables> ></Variables> ></Report> > > |
|
From: Bob D. <bd...@si...> - 2005-10-07 19:29:06
|
Lisa, Having multiple break fields as you have defined is not officially supported in RLIB 1.3.x I also don't think it's an issue because you were not outputting rows, but rather the break footer for common rows. (Hence the different number of rows) The new way of doing it is with a simple expression: <Break name="Detail" newpage="no"> <BreakFields> <BreakField value="Conn_Date+Conn_Time+Orig"/> </BreakFields> <BreakFooter> That said, I think you are a little confused w/ breaks?? Maybe?? I've attached a reworked example of what you sent. (att.xml) It uses the "Detail" section of RLIB (this way all rows come out). I also added in a very simple break as an example (Show a big line of text when the date changes). Cheers - Bob |
6 messages has been excluded from this view by a project administrator.
