[Rd] Wrong bug ID & URL in Daily News about R-devel/NEWS
I was browsing some recent R news at http://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2016/01/03#n2016-01-03 And reading this item: "tapply() has been made considerably more efficient without changing functionality, thanks to proposals from Peter Haverty and Suharto Anggono. (PR#16488)" But I found that the link in the item goes to a page about the GUI, not tapply: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16488 It should go to this page for the tapply speed-up: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16640 This is probably just a simple typo, since a quick check of other links to bugs in the news showed they were all ok. Anyway, I couldn't see any webmaster contact details on http://developer.r-project.org/ so hopefully this list message will reach the right person. Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wrong bug ID & URL in Daily News about R-devel/NEWS
On 03/01/2016 4:03 AM, Ben Marwick wrote: I was browsing some recent R news at http://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2016/01/03#n2016-01-03 And reading this item: "tapply() has been made considerably more efficient without changing functionality, thanks to proposals from Peter Haverty and Suharto Anggono. (PR#16488)" But I found that the link in the item goes to a page about the GUI, not tapply: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16488 It should go to this page for the tapply speed-up: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16640 This is probably just a simple typo, since a quick check of other links to bugs in the news showed they were all ok. Anyway, I couldn't see any webmaster contact details on http://developer.r-project.org/ so hopefully this list message will reach the right person. This is a good place to post typos in the documentation. I'll fix this one. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, AIX 64-bit builds - trying to understand root cause for message: "Error: Line starting 'Package: tools ...' is malformed!"
On 2016-01-01 23:48, peter dalgaard wrote:
Nice catch you two!!!
Happy New Year
-pd
I am much happier with this great start!
Simon - which compiler)s) did you use: xlc and xlfortran, or gcc/gfortran?
I have made some changes to configure(.ac) so maybe my problems are
self-inflicted. But would be good to know what environment you are using.
Thanks for looking - and finding!!!
Michael
On 01 Jan 2016, at 22:06 , Simon Urbanek wrote:
Ok, found the problem - on platforms that support it TRE uses wint_t (from
wchar.h) as its type for characters (tre_cint_t) which on AIX is *signed* int.
TRE uses liberally conversions between int and tre_cint_t apparently assuming
that the latter is unsigned so conversions back to int are suitable for
comparisons etc. On other platforms wint_t is unsigned so it works. Manually
defining tre_cint_t to unsigned int fixes the issue.
Cheers,
Simon
On Jan 1, 2016, at 12:20 PM, Simon Urbanek wrote:
Michael,
thanks, I'll have a look once my PDP VMs are up again (later today). This may
be a signedness issue although it's unclear why other platforms wouldn't be
affected.
Cheers,
Simon
On Dec 31, 2015, at 10:14 AM, Michael Felt wrote:
On 2015-12-30 09:58, Michael Felt wrote:
On 2015-12-29 11:02, Michael Felt wrote:
This seems to be a problem that goes back a long time - and I hope someone who
understands what tre is suppossed to be doing will look at this.
A short history of other people who have reported on this on different versions
of AIX. I shall only add that I get the same results on AIX 5.3 TL7, AIX 6.1
TL9 and AIX 7.1 TL3.
Basically, with settings that work for AIX and 32-bit - the only changes being
-maix32 becomes -maix64
and
export OBJECT_MODE=32 becomes export OBJECT_MODE=64
Then to shorten the 'make' bla bla, first run just make, then
cd src/library/tools
make -s sysdata
http://article.gmane.org/gmane.comp.lang.r.devel/38817/match=package+tools+malformed
http://article.gmane.org/gmane.comp.lang.r.devel/36886/match=package+tools+malformed
http://article.gmane.org/gmane.comp.lang.r.devel/23372/match=package+tools+malformed
Date: 2010-01-25 06:55:41 GMT (5 years, 48 weeks, 1 day, 20 hours and 30
minutes ago)
To that, to get debug data, I have
* added -DTRE_DUGUG to src/extra/tre/Makefile # ALL_CFLAGS = $(ALL_CFLAGS_LO)
-DTRE_DEBUG
* rm src/extra/tre/tre-match-parallel.o
* find . -name \*.so -exec rm {} \;
* make
* cd src/library/tools
* make -s sysdata
Attached are the two script files of the screen output. The 32-bit one is more
verbose - and contains magically lines such as:
found match 3037fd14 (while "found" does not occur in the 64-bit output)
root@x069:[/data/prj/cran/64/R-aix-3.2.3/src/library/tools]wc /tmp/sysdata.??.*
4730 14123 139916 /tmp/sysdata.32.text
13123688 40528 /tmp/sysdata.64.text
6042 17811 180444 total
root@x069:[/data/prj/cran/64/R-aix-3.2.3/src/library/tools]grep -c found
/tmp/sysdata.??.*
/tmp/sysdata.32.text:19
/tmp/sysdata.64.text:0
Hope this brings us (or me), closer to a resolution to an old concern.
And, best wishes for the new year!
Michael
Still hoping for someones curiosity/willingness.
The differences show up in the first comparision that is made (of the string
"3.2.3" it seems) - 32-bit is on the left, 64-bit on the right.
Script command is started on Tue Dec 29 08:39:16 UTC 2015.
| Script command is started on Tue Dec 29 08:39:56 UTC 2015.
root@x069:[/data/prj/cran/32/R-aix-3.2.3/src/library/tools]make -s sysdata
| root@x069:[/data/prj/cran/64/R-aix-3.2.3/src/library/tools]make -s sysdata
installing 'sysdata.rda'
| installing 'sysdata.rda'
tre_tnfa_run_parallel, input type 1
| tre_tnfa_run_parallel, input type 1
length: -1
| length: -1
pos:chr/code | states and tags
| pos:chr/code | states and tags
-+
| -+
init> 30380200 3038014c 30380098 |
init> 110cc3040 110cc2f28 110cc2e10
match end offset = -1
| match end offset = -1
tre_tnfa_run_parallel, input type 1
| tre_tnfa_run_parallel, input type 1
length: -1
| length: -1
pos:chr/code | states and tags
| pos:chr/code | states and tags
-+
| -+
init> 3037fb88 |
init> 110c
Re: [Rd] R, AIX 64-bit builds - trying to understand root cause for message: "Error: Line starting 'Package: tools ...' is malformed!"
On 2016-01-03 16:59, Michael Felt wrote: On 2016-01-01 23:48, peter dalgaard wrote: Nice catch you two!!! Happy New Year -pd I am much happier with this great start! Simon - which compiler)s) did you use: xlc and xlfortran, or gcc/gfortran? I have made some changes to configure(.ac) so maybe my problems are self-inflicted. But would be good to know what environment you are using. Using the dist, plus the following change: diff -ru R-3.2.3.dist/src/extra/tre/tre-internal.h R-3.2.3.1/src/extra/tre/tre-internal.h --- R-3.2.3.dist/src/extra/tre/tre-internal.h 2014-06-13 22:15:07.0 + +++ R-3.2.3.1/src/extra/tre/tre-internal.h 2016-01-03 16:08:31.0 + @@ -47,7 +47,7 @@ #ifdef TRE_WCHAR /* Wide characters. */ - typedef wint_t tre_cint_t; + typedef uint16_t tre_cint_t; #define TRE_CHAR_MAX WCHAR_MAX #ifdef TRE_MULTIBYTE @@ -78,7 +78,7 @@ #else /* !TRE_WCHAR */ /* 8 bit characters. */ - typedef short tre_cint_t; + typedef uint16_t tre_cint_t; #define TRE_CHAR_MAX 255 #define TRE_MB_CUR_MAX 1 @@ -118,7 +118,7 @@ #define tre_ctype(s) wctype(s) #else /* !TRE_USE_SYSTEM_WCTYPE */ /* Define our own versions of iswctype() and wctype(). */ - typedef int (*tre_ctype_t)(tre_cint_t); + typedef uint16_t (*tre_ctype_t)(tre_cint_t); #define tre_isctype(c, type) ( (type)(c) ) tre_ctype_t tre_ctype(const char *name); #endif /* !TRE_USE_SYSTEM_WCTYPE */ I get the same result as with my modified configure(.ac), namely: make[4]: Entering directory '/data/prj/cran/64/R-aix-3.2.3/src/library/grDevices' byte-compiling package 'grDevices' Warning in solve.default(rgb) : unable to load shared object '/data/prj/cran/64/R-aix-3.2.3/modules//lapack.so': rtld: 0712-001 Symbol _gfortran_pow_i4_i4 was referenced from module /data/prj/cran/64/R-aix-3.2.3/lib/libRlapack.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol _gfortran_compare_string/data/prj/cran/64/R-aix-3.2.3/lib/libRlapack.so was referenced from module /data/prj/cran/64/R-aix-3.2.3/lib/libRlapack.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol _gfortran_concat_string was referenced from module /data/prj/cran/64/R-aix-3.2.3/lib/libRlapack.so(), but a runtime definition of the symbol was not found. rtld: 0712-002 fatal error: exiting. Error in solve.default(rgb) : LAPACK routines cannot be loaded Error: unable to load R code in package 'grDevices' Execution halted My expectation is that this has to do with some incorrect flags being passed to the linker (not getting the 64-bit libraries of the compiler). I have had several long discussions with an AIX gcc specialist and he has given me several recommendations for changes to the flags used for creating shared libraries. I shall continue looking into this. I am happy it is not my configure.ac changes - and I have a few ideas on how to resolve in configure.ac and/or in m4 files. MF Thanks for looking - and finding!!! Michael On 01 Jan 2016, at 22:06 , Simon Urbanek wrote: Ok, found the problem - on platforms that support it TRE uses wint_t (from wchar.h) as its type for characters (tre_cint_t) which on AIX is *signed* int. TRE uses liberally conversions between int and tre_cint_t apparently assuming that the latter is unsigned so conversions back to int are suitable for comparisons etc. On other platforms wint_t is unsigned so it works. Manually defining tre_cint_t to unsigned int fixes the issue. Cheers, Simon On Jan 1, 2016, at 12:20 PM, Simon Urbanek wrote: Michael, thanks, I'll have a look once my PDP VMs are up again (later today). This may be a signedness issue although it's unclear why other platforms wouldn't be affected. Cheers, Simon On Dec 31, 2015, at 10:14 AM, Michael Felt wrote: On 2015-12-30 09:58, Michael Felt wrote: On 2015-12-29 11:02, Michael Felt wrote: This seems to be a problem that goes back a long time - and I hope someone who understands what tre is suppossed to be doing will look at this. A short history of other people who have reported on this on different versions of AIX. I shall only add that I get the same results on AIX 5.3 TL7, AIX 6.1 TL9 and AIX 7.1 TL3. Basically, with settings that work for AIX and 32-bit - the only changes being -maix32 becomes -maix64 and export OBJECT_MODE=32 becomes export OBJECT_MODE=64 Then to shorten the 'make' bla bla, first run just make, then cd src/library/tools make -s sysdata http://article.gmane.org/gmane.comp.lang.r.devel/38817/match=package+tools+malformed http://article.gmane.org/gmane.comp.lang.r.devel/36886/match=package+tools+malformed http://article.gmane.org/gmane.comp.lang.r.devel/23372/match=package+tools+malformed Date: 2010-01-25 06:55:41 GMT (5 years, 48 weeks, 1 day, 20 hours and 30 minutes ago) To that, to get debug data, I have * added -DTRE_DUGUG to src/extra/tre/Makefile #
Re: [Rd] R, AIX 64-bit builds - trying to understand root cause for message: "Error: Line starting 'Package: tools ...' is malformed!"
On 2016-01-03 17:28, Michael Felt wrote:
On 2016-01-03 16:59, Michael Felt wrote:
On 2016-01-01 23:48, peter dalgaard wrote:
Nice catch you two!!!
Happy New Year
-pd
I am much happier with this great start!
Simon - which compiler)s) did you use: xlc and xlfortran, or
gcc/gfortran?
I have made some changes to configure(.ac) so maybe my problems are
self-inflicted. But would be good to know what environment you are
using.
Using the dist, plus the following change:
diff -ru R-3.2.3.dist/src/extra/tre/tre-internal.h
R-3.2.3.1/src/extra/tre/tre-internal.h
--- R-3.2.3.dist/src/extra/tre/tre-internal.h 2014-06-13
22:15:07.0 +
+++ R-3.2.3.1/src/extra/tre/tre-internal.h 2016-01-03
16:08:31.0 +
@@ -47,7 +47,7 @@
#ifdef TRE_WCHAR
/* Wide characters. */
- typedef wint_t tre_cint_t;
+ typedef uint16_t tre_cint_t;
#define TRE_CHAR_MAX WCHAR_MAX
#ifdef TRE_MULTIBYTE
@@ -78,7 +78,7 @@
#else /* !TRE_WCHAR */
/* 8 bit characters. */
- typedef short tre_cint_t;
+ typedef uint16_t tre_cint_t;
#define TRE_CHAR_MAX 255
#define TRE_MB_CUR_MAX 1
@@ -118,7 +118,7 @@
#define tre_ctype(s) wctype(s)
#else /* !TRE_USE_SYSTEM_WCTYPE */
/* Define our own versions of iswctype() and wctype(). */
- typedef int (*tre_ctype_t)(tre_cint_t);
+ typedef uint16_t (*tre_ctype_t)(tre_cint_t);
#define tre_isctype(c, type) ( (type)(c) )
tre_ctype_t tre_ctype(const char *name);
#endif /* !TRE_USE_SYSTEM_WCTYPE */
I get the same result as with my modified configure(.ac), namely:
make[4]: Entering directory
'/data/prj/cran/64/R-aix-3.2.3/src/library/grDevices'
byte-compiling package 'grDevices'
Warning in solve.default(rgb) :
unable to load shared object
'/data/prj/cran/64/R-aix-3.2.3/modules//lapack.so':
rtld: 0712-001 Symbol _gfortran_pow_i4_i4 was referenced
from module /data/prj/cran/64/R-aix-3.2.3/lib/libRlapack.so(),
but a runtime definition
of the symbol was not found.
rtld: 0712-001 Symbol
_gfortran_compare_string/data/prj/cran/64/R-aix-3.2.3/lib/libRlapack.so was
referenced
from module /data/prj/cran/64/R-aix-3.2.3/lib/libRlapack.so(),
but a runtime definition
of the symbol was not found.
rtld: 0712-001 Symbol _gfortran_concat_string was referenced
from module /data/prj/cran/64/R-aix-3.2.3/lib/libRlapack.so(),
but a runtime definition
of the symbol was not found.
rtld: 0712-002 fatal error: exiting.
Error in solve.default(rgb) : LAPACK routines cannot be loaded
Error: unable to load R code in package 'grDevices'
Execution halted
My expectation is that this has to do with some incorrect flags being
passed to the linker (not getting the 64-bit libraries of the
compiler). I have had several long discussions with an AIX gcc
specialist and he has given me several recommendations for changes to
the flags used for creating shared libraries. I shall continue looking
into this.
I am happy it is not my configure.ac changes - and I have a few ideas
on how to resolve in configure.ac and/or in m4 files.
MF
FYI: Still running into problems in grDevices using
/data/prj/cran/${RELEASE}/configure --disable-lto --prefix=/opt \
--disable-R-shlib --enable-R-static-lib \
--with-cairo=no --with-libpng=no --with-jpeglib=no
--with-libtiff=no \
--with-readline=no --with-x=no
So, Simon - very interested in your environment and whether make
completes successfully - to the end.
p.s. - I am a bit surprised about the messages below (line 4) because I
am assuming that shared libraries are not being used (with
--disable-R-shlib --enable-R-static-lib ).
fyi - from memory - but my expectation is that it has to do with the
-bexpall and an incorrect library search path being inserted. The symbol
is in /opt/lib/ppc64 archives:
root@x069:[/opt/lib/ppc64]nm -X64 -Ae *.a | grep __register_frame_info_table
libgcc_s.a[shr.o]: .__register_frame_info_table T 268466492 116
libgcc_s.a[shr.o]: .__register_frame_info_table_bases T
268466364 120
libgcc_s.a[shr.o]: __register_frame_info_table D 536877472
libgcc_s.a[shr.o]: __register_frame_info_table d 536877472 24
libgcc_s.a[shr.o]: __register_frame_info_table_bases D 536880832
libgcc_s.a[shr.o]: __register_frame_info_table_bases d
536880832 24
libstdc++.a[libstdc++.so.6]: .__register_frame_info_table T 269107692
libstdc++.a[libstdc++.so.6]: .__register_frame_info_table t
269107692 40
libstdc++.a[libstdc++.so.6]: __register_frame_info_table U -
libstdc++.a[libstdc++.so.6]: __register_frame_info_table d
537156720 8
But these are not being found, rather specified. Somehow the default
behavior of gcc (i.e., the flags it passes to ld are being overruled).
It will take time, but I shall find them.
make[4]: Entering directory
'/data/prj/cran/64/R-aix-3.2.3/src/library/grDevices'
byte-compiling package 'grDevices'
*** caught segfault ***
address 6c207
[Rd] trivial typo in R for windows FAQ
In https://cran.r-project.org/bin/windows/base/rw-FAQ.html#Package-TclTk-does-not-work_002e : "This [is] part of the R installation, so it should be there." cheers Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, AIX 64-bit builds - trying to understand root cause for message: "Error: Line starting 'Package: tools ...' is malformed!"
Michael,
I'm using xlc + xlf - the exact flags are
configure CC=xlc_r CXX=xlc++_r F77=xlf_r FC=xlf95_r LIBS='-L/opt/freeware/lib
/opt/freeware/lib/libiconv.a -lpthread' --prefix=/opt/freeware
CPPFLAGS=-I/opt/freeware/include
with export OBJECT_MODE=64 in the env (and libiconv from perzl.org RPMs - iconv
is a serious pain).
I have changed the TRE typedef from "wint_t" to "unsigned int" since that is
what the other platforms use anyway.
On my AIX7 VM I'm running out of memory in xz when lazy-loading is enabled
which his odd - the VM has 4Gb which one would think should be enough. The
symptom is that installing MASS fails when creating lazy-load rds or the same
happens when running make check as memCompress() test for xz fails. I wish
there was a way to disable xz altogether..
I'd like to get IBM compilers to work first since those are the official ones.
I may try gcc later, but I'm really interested in the IBM ones because that
gives us a good non-GNU test (e.g., TRE fails in JIT due some alleged GNUisms
so you can't use the strict compiler mode).
Cheers,
Simon
On Jan 3, 2016, at 10:59 AM, Michael Felt wrote:
> On 2016-01-01 23:48, peter dalgaard wrote:
>> Nice catch you two!!!
>>
>> Happy New Year
>> -pd
> I am much happier with this great start!
>
> Simon - which compiler)s) did you use: xlc and xlfortran, or gcc/gfortran?
>
> I have made some changes to configure(.ac) so maybe my problems are
> self-inflicted. But would be good to know what environment you are using.
>
> Thanks for looking - and finding!!!
>
> Michael
>>> On 01 Jan 2016, at 22:06 , Simon Urbanek
>>> wrote:
>>>
>>> Ok, found the problem - on platforms that support it TRE uses wint_t (from
>>> wchar.h) as its type for characters (tre_cint_t) which on AIX is *signed*
>>> int. TRE uses liberally conversions between int and tre_cint_t apparently
>>> assuming that the latter is unsigned so conversions back to int are
>>> suitable for comparisons etc. On other platforms wint_t is unsigned so it
>>> works. Manually defining tre_cint_t to unsigned int fixes the issue.
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>> On Jan 1, 2016, at 12:20 PM, Simon Urbanek
>>> wrote:
>>>
Michael,
thanks, I'll have a look once my PDP VMs are up again (later today). This
may be a signedness issue although it's unclear why other platforms
wouldn't be affected.
Cheers,
Simon
On Dec 31, 2015, at 10:14 AM, Michael Felt wrote:
> On 2015-12-30 09:58, Michael Felt wrote:
>> On 2015-12-29 11:02, Michael Felt wrote:
>>> This seems to be a problem that goes back a long time - and I hope
>>> someone who understands what tre is suppossed to be doing will look at
>>> this.
>>>
>>> A short history of other people who have reported on this on different
>>> versions of AIX. I shall only add that I get the same results on AIX
>>> 5.3 TL7, AIX 6.1 TL9 and AIX 7.1 TL3.
>>>
>>> Basically, with settings that work for AIX and 32-bit - the only
>>> changes being
>>> -maix32 becomes -maix64
>>> and
>>> export OBJECT_MODE=32 becomes export OBJECT_MODE=64
>>>
>>> Then to shorten the 'make' bla bla, first run just make, then
>>>
>>> cd src/library/tools
>>> make -s sysdata
>>>
>>> http://article.gmane.org/gmane.comp.lang.r.devel/38817/match=package+tools+malformed
>>> http://article.gmane.org/gmane.comp.lang.r.devel/36886/match=package+tools+malformed
>>> http://article.gmane.org/gmane.comp.lang.r.devel/23372/match=package+tools+malformed
>>> Date: 2010-01-25 06:55:41 GMT (5 years, 48 weeks, 1 day, 20 hours and
>>> 30 minutes ago)
>>>
>>> To that, to get debug data, I have
>>>
>>> * added -DTRE_DUGUG to src/extra/tre/Makefile # ALL_CFLAGS =
>>> $(ALL_CFLAGS_LO) -DTRE_DEBUG
>>> * rm src/extra/tre/tre-match-parallel.o
>>> * find . -name \*.so -exec rm {} \;
>>> * make
>>> * cd src/library/tools
>>> * make -s sysdata
>>>
>>> Attached are the two script files of the screen output. The 32-bit one
>>> is more verbose - and contains magically lines such as:
>>> found match 3037fd14 (while "found" does not occur in the 64-bit output)
>>>
>>> root@x069:[/data/prj/cran/64/R-aix-3.2.3/src/library/tools]wc
>>> /tmp/sysdata.??.*
>>> 4730 14123 139916 /tmp/sysdata.32.text
>>> 13123688 40528 /tmp/sysdata.64.text
>>> 6042 17811 180444 total
>>>
>>> root@x069:[/data/prj/cran/64/R-aix-3.2.3/src/library/tools]grep -c
>>> found /tmp/sysdata.??.*
>>> /tmp/sysdata.32.text:19
>>> /tmp/sysdata.64.text:0
>>>
>>>
>>> Hope this brings us (or me), closer to a resolution to an old concern.
>>>
>>> And, best wishes for the new year!
>>>
>>> Michael
>>>
>>>
>> Still hoping for someones curiosity/willingness.
>>
>> The differences s
Re: [Rd] R, AIX 64-bit builds - trying to understand root cause for message: "Error: Line starting 'Package: tools ...' is malformed!"
I would be "pleased" if you would try packages - i.e., none of "Toolbox" or Perzl rpm's. The iconv I supply might not be working as is (I will need to install a new system to check). However, this is why I have been testing with R-3.2.3 - to side-step the system library dependencies. re: xz - I have "installp" version - and any of my packages should work side-by-side with the Toolbox/.rpm files - my PATH prefix is /opt (so, /opt/bin and /opt/sbin rather than /usr/bin, /usr/local/bin (etc.). I am testing on a Power6, usually with 2 to 4G RAM active. When I get the compile to finish I will up to 8G to test some data processing that fails with the 32-bit limitations. Another question: are you also getting lots of duplicate symbol warnings? Curious me. If you are I would like to send my modifications to configure(.ac) for you to test (I put .ac in () because I am actually editting configure atm but shall put them into configure.ac when I finish) FYI: I shall be downloading the "try and buy" xlc and xlfortran - and I think you will certainly prefer my packaging then as they work without the libgc dependencies that many of the rpm packages need. And, at your option - we can take this discussion over tools - "out of forums". Or at least start a new thread. re: unsigned short - I have adopted the convention to use the *NN_t types after running into a problem with unsigned longlong (from a very old program). It goes back many years - and maybe they have finalized short to mean 16-bits - but I remember when short was meant to help when moving from 16-bit to 32-bit and the "word" size changed - i.e., int became 32-bit same as long. nd for a long (no pun intended) long was 32-bit and long long was 64-bit. Those definitions are extinct. imho - the standard for wint_t is wrong as well - based on an assumption about how "short" is defined. And, I consider it poor practice that there are som many cases of type cast switches between ushort and int. Michael On 04-Jan-16 01:26, Simon Urbanek wrote: Michael, I'm using xlc + xlf - the exact flags are configure CC=xlc_r CXX=xlc++_r F77=xlf_r FC=xlf95_r LIBS='-L/opt/freeware/lib /opt/freeware/lib/libiconv.a -lpthread' --prefix=/opt/freeware CPPFLAGS=-I/opt/freeware/include with export OBJECT_MODE=64 in the env (and libiconv from perzl.org RPMs - iconv is a serious pain). I have changed the TRE typedef from "wint_t" to "unsigned int" since that is what the other platforms use anyway. On my AIX7 VM I'm running out of memory in xz when lazy-loading is enabled which his odd - the VM has 4Gb which one would think should be enough. The symptom is that installing MASS fails when creating lazy-load rds or the same happens when running make check as memCompress() test for xz fails. I wish there was a way to disable xz altogether.. I'd like to get IBM compilers to work first since those are the official ones. I may try gcc later, but I'm really interested in the IBM ones because that gives us a good non-GNU test (e.g., TRE fails in JIT due some alleged GNUisms so you can't use the strict compiler mode). Cheers, Simon On Jan 3, 2016, at 10:59 AM, Michael Felt wrote: On 2016-01-01 23:48, peter dalgaard wrote: Nice catch you two!!! Happy New Year -pd I am much happier with this great start! Simon - which compiler)s) did you use: xlc and xlfortran, or gcc/gfortran? I have made some changes to configure(.ac) so maybe my problems are self-inflicted. But would be good to know what environment you are using. Thanks for looking - and finding!!! Michael On 01 Jan 2016, at 22:06 , Simon Urbanek wrote: Ok, found the problem - on platforms that support it TRE uses wint_t (from wchar.h) as its type for characters (tre_cint_t) which on AIX is *signed* int. TRE uses liberally conversions between int and tre_cint_t apparently assuming that the latter is unsigned so conversions back to int are suitable for comparisons etc. On other platforms wint_t is unsigned so it works. Manually defining tre_cint_t to unsigned int fixes the issue. Cheers, Simon On Jan 1, 2016, at 12:20 PM, Simon Urbanek wrote: Michael, thanks, I'll have a look once my PDP VMs are up again (later today). This may be a signedness issue although it's unclear why other platforms wouldn't be affected. Cheers, Simon On Dec 31, 2015, at 10:14 AM, Michael Felt wrote: On 2015-12-30 09:58, Michael Felt wrote: On 2015-12-29 11:02, Michael Felt wrote: This seems to be a problem that goes back a long time - and I hope someone who understands what tre is suppossed to be doing will look at this. A short history of other people who have reported on this on different versions of AIX. I shall only add that I get the same results on AIX 5.3 TL7, AIX 6.1 TL9 and AIX 7.1 TL3. Basically, with settings that work for AIX and 32-bit - the only changes being -maix32 becomes -maix64 and export OBJECT_MODE=32 becomes export OBJECT_MODE=64 Then to shorten the 'mak
