getdata-devel — General discussion of GetData development.

Re: [getdata-devel] MinGW patches

[Peter K. <syn...@gm...>]

> 
> I've posted some tarballs of 0.7.1rc1, if you prefer that to SVN:
>

Thanks, but using svn is ok. Could you add the property to handle
line endings platform specific:

svn propset svn:eol-style native -R *

Peter

Re: [getdata-devel] MinGW patches

[Peter K. <syn...@gm...>]

On 14.10.2010 02:44, D. V. Wiebe wrote:
> With GD_NO_C99_API defined to one, I can compile the GetData C library
> both with 'gcc --ansi' and with g++.  (As advertised, this will disable
> the C99 API in getdata.h completely, effectively GD_C89_API is always
> defined.  But this should be transparent to kst, since the C++ bindings
> are unaffected.)

When I switch msvc to ansi-C without extensions (e.g. no off_t but _off_t)
I still get many errors. Seems -ansi is not ansi under gcc.
Maybe -ansi -pedantic?

> 
> Thanks for the update; I'll work on putting out a release, and maybe we
> can get back to looking for a solution.
> 
> Cheers,
> -dvw

Re: [getdata-devel] Test for file fials when building getdata for openSUSE Factory

[D. V. W. <ge...@ke...>]

On Fri, Nov 26, 2010 at 07:22:14PM +0100, Christian Trippe wrote:
> Thanks for the quick response!
> 
> Am Donnerstag, 25. November 2010, 21:27:45 schrieb D. V. Wiebe:
> > On Thu, Nov 25, 2010 at 07:25:17PM +0100, Christian Trippe wrote:
> > > Hi,
> > > 
> > > I am trying to package getdata for openSUSE. This works fine for openSUSE
> > > 11.3, however for openSUSE Factory one of the test fails (the test called
> > > file) and asks to contact this mailinglist. This is what I have done now.
> > > Thanks in advance for any advice.
> > > 
> > > You find the build log with the failed test under
> > > https://build.opensuse.org/package/rawlog?arch=x86_64&package=getdata&pro
> > > ject=home%3Achristiantrippe%3Abranches%3AKDE%3ADistro%3AFactory&repositor
> > > y=openSUSE_Factory
> > > 
> > > Please CC me on replies as I am not subscribed to the mailinglist.
> > > 
> > > Kind regards
> > > Christian
> > 
> > That's rather odd; that one's not much of a test. I'd be inclined to
> > believe it's a bug in the test itself, given that everthing else seems
> > to work.
> > 
> > We have just released GetData-0.7.0.  I'd be curious to know if you see
> > the same behaviour with it.  I certainly reccomend upgrading, numerous
> > bugs have been fixed (although I don't recall anything that would change
> > that test, per se).
> 
> I was not aware of this release, I had looked for the newest version on the 
> last weekend. With the 0.7.0 release the file test no longer fails.
> However another test (meta_vectors_del) is failing now for openSUSE Factory 
> which works fine for 11.3

There does indeed appear to be some indecorous memory access occurring
somewhere, but it's not immediately apparent what it is.  I'll continue
to investigate, and let you know what I find.

Thanks for the report,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] Test for file fials when building getdata for openSUSE Factory

[Christian T. <ct...@gm...>]

Thanks for the quick response!

Am Donnerstag, 25. November 2010, 21:27:45 schrieb D. V. Wiebe:
> On Thu, Nov 25, 2010 at 07:25:17PM +0100, Christian Trippe wrote:
> > Hi,
> > 
> > I am trying to package getdata for openSUSE. This works fine for openSUSE
> > 11.3, however for openSUSE Factory one of the test fails (the test called
> > file) and asks to contact this mailinglist. This is what I have done now.
> > Thanks in advance for any advice.
> > 
> > You find the build log with the failed test under
> > https://build.opensuse.org/package/rawlog?arch=x86_64&package=getdata&pro
> > ject=home%3Achristiantrippe%3Abranches%3AKDE%3ADistro%3AFactory&repositor
> > y=openSUSE_Factory
> > 
> > Please CC me on replies as I am not subscribed to the mailinglist.
> > 
> > Kind regards
> > Christian
> 
> That's rather odd; that one's not much of a test. I'd be inclined to
> believe it's a bug in the test itself, given that everthing else seems
> to work.
> 
> We have just released GetData-0.7.0.  I'd be curious to know if you see
> the same behaviour with it.  I certainly reccomend upgrading, numerous
> bugs have been fixed (although I don't recall anything that would change
> that test, per se).

I was not aware of this release, I had looked for the newest version on the 
last weekend. With the 0.7.0 release the file test no longer fails.
However another test (meta_vectors_del) is failing now for openSUSE Factory 
which works fine for 11.3
From the build log:


*** glibc detected 
*** /usr/src/packages/BUILD/getdata-0.7.0/test/.libs/nmeta_vectors_del: 
free(): invalid pointer: 0x0804d3a0 ***
 ======= Backtrace: =========
 /lib/libc.so.6(+0x6df0b)[0xb768ff0b]
 /lib/libc.so.6(cfree+0xd9)[0xb7694a59]
 /usr/src/packages/BUILD/getdata-0.7.0/src/.libs/libgetdata.so.4(gd_delete+0x422)
[0xb77a0092]
 /usr/src/packages/BUILD/getdata-0.7.0/test/.libs/nmeta_vectors_del[0x804888c]
 /lib/libc.so.6(__libc_start_main+0xfe)[0xb7638bfe]
 /usr/src/packages/BUILD/getdata-0.7.0/test/.libs/nmeta_vectors_del[0x8048741]
 ======= Memory map: ========
 08048000-08049000 r-xp 00000000 03:01 
1180548                            /usr/src/packages/BUILD/getdata-0.7.0/test/.libs/nmeta_vectors_del
 08049000-0804a000 r--p 00001000 03:01 
1180548                            /usr/src/packages/BUILD/getdata-0.7.0/test/.libs/nmeta_vectors_del
 0804a000-0804b000 rw-p 00002000 03:01 
1180548                            /usr/src/packages/BUILD/getdata-0.7.0/test/.libs/nmeta_vectors_del
 0804b000-0806c000 rw-p 0804b000 00:00 0                                  
[heap]
 b75c8000-b75e4000 r-xp 00000000 03:01 
1794100                            /lib/libgcc_s.so.1
 b75e4000-b75e5000 r--p 0001b000 03:01 
1794100                            /lib/libgcc_s.so.1
 b75e5000-b75e6000 rw-p 0001c000 03:01 
1794100                            /lib/libgcc_s.so.1
 b75e6000-b75e7000 rw-p b75e6000 00:00 0 
 b75e7000-b75ea000 r-xp 00000000 03:01 
1794069                            /lib/libdl-2.11.2.so
 b75ea000-b75eb000 r--p 00002000 03:01 
1794069                            /lib/libdl-2.11.2.so
 b75eb000-b75ec000 rw-p 00003000 03:01 
1794069                            /lib/libdl-2.11.2.so
 b75ec000-b75ed000 rw-p b75ec000 00:00 0 
 b75ed000-b7615000 r-xp 00000000 03:01 
1794071                            /lib/libm-2.11.2.so
 b7615000-b7616000 r--p 00027000 03:01 
1794071                            /lib/libm-2.11.2.so
 b7616000-b7617000 rw-p 00028000 03:01 
1794071                            /lib/libm-2.11.2.so
 b7617000-b7620000 r-xp 00000000 03:01 
1099090                            /usr/lib/libltdl.so.7.2.1
 b7620000-b7621000 r--p 00008000 03:01 
1099090                            /usr/lib/libltdl.so.7.2.1
 b7621000-b7622000 rw-p 00009000 03:01 
1099090                            /usr/lib/libltdl.so.7.2.1
 b7622000-b7785000 r-xp 00000000 03:01 
1794063                            /lib/libc-2.11.2.so
 b7785000-b7786000 ---p 00163000 03:01 
1794063                            /lib/libc-2.11.2.so
 b7786000-b7788000 r--p 00163000 03:01 
1794063                            /lib/libc-2.11.2.so
 b7788000-b7789000 rw-p 00165000 03:01 
1794063                            /lib/libc-2.11.2.so
 b7789000-b778c000 rw-p b7789000 00:00 0 
 b778f000-b77db000 r-xp 00000000 03:01 
1173398                            /usr/src/packages/BUILD/getdata-0.7.0/src/.libs/libgetdata.so.4.0.0
 b77db000-b77dc000 r--p 0004c000 03:01 
1173398                            /usr/src/packages/BUILD/getdata-0.7.0/src/.libs/libgetdata.so.4.0.0
 b77dc000-b77dd000 rw-p 0004d000 03:01 
1173398                            /usr/src/packages/BUILD/getdata-0.7.0/src/.libs/libgetdata.so.4.0.0
 b77dd000-b77de000 rw-p b77dd000 00:00 0 
 b77de000-b77fc000 r-xp 00000000 03:01 
1794196                            /lib/ld-2.11.2.so
 b77fc000-b77fd000 r--p 0001d000 03:01 
1794196                            /lib/ld-2.11.2.so
 b77fd000-b77fe000 rw-p 0001e000 03:01 
1794196                            /lib/ld-2.11.2.so
 bfe75000-bfe8a000 rw-p 7ffffffea000 00:00 0                              
[stack]
 ffffe000-fffff000 r-xp ffffe000 00:00 0                                  
[vdso]
 /bin/sh: line 5: 14092 Aborted                 ${dir}$tst
 FAIL: nmeta_vectors_del



Kind regards,
Christian

Re: [getdata-devel] Test for file fials when building getdata for openSUSE Factory

[D. V. W. <ge...@ke...>]

On Thu, Nov 25, 2010 at 07:25:17PM +0100, Christian Trippe wrote:
> Hi,
> 
> I am trying to package getdata for openSUSE. This works fine for openSUSE 
> 11.3, however for openSUSE Factory one of the test fails (the test called 
> file) and asks to contact this mailinglist. This is what I have done now.
> Thanks in advance for any advice.
> 
> You find the build log with the failed test under 
> https://build.opensuse.org/package/rawlog?arch=x86_64&package=getdata&project=home%3Achristiantrippe%3Abranches%3AKDE%3ADistro%3AFactory&repository=openSUSE_Factory
> 
> Please CC me on replies as I am not subscribed to the mailinglist.
> 
> Kind regards
> Christian

That's rather odd; that one's not much of a test. I'd be inclined to
believe it's a bug in the test itself, given that everthing else seems
to work.

We have just released GetData-0.7.0.  I'd be curious to know if you see
the same behaviour with it.  I certainly reccomend upgrading, numerous
bugs have been fixed (although I don't recall anything that would change
that test, per se).

If you'd prefer to stick with 0.6.3, I might be able to figure out
what's going on if you could pass '--enable-debug' to ./configure, and
send or post the resulting logs.  It's unlikely we'd put out a 0.6.4,
but if it's something simple, I might be able to produce a patch.

Cheers,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

[getdata-devel] Test for file fials when building getdata for openSUSE Factory

[Christian T. <ct...@gm...>]

Hi,

I am trying to package getdata for openSUSE. This works fine for openSUSE 
11.3, however for openSUSE Factory one of the test fails (the test called 
file) and asks to contact this mailinglist. This is what I have done now.
Thanks in advance for any advice.

You find the build log with the failed test under 
https://build.opensuse.org/package/rawlog?arch=x86_64&package=getdata&project=home%3Achristiantrippe%3Abranches%3AKDE%3ADistro%3AFactory&repository=openSUSE_Factory

Please CC me on replies as I am not subscribed to the mailinglist.

Kind regards
Christian

Re: [getdata-devel] MinGW patches

[Peter K. <syn...@gm...>]

On 23.11.2010 02:42, D. V. Wiebe wrote:
> On Mon, Nov 22, 2010 at 12:02:15PM +0100, Peter K?mmel wrote:
>> Then you will be really surprised to hear this: MSVC requires all local
>> variables to be declared at the beginning of a function.
>>
>> Seems mixing code and variable definitions is a C++/C99 feature:
>>
>>   -Wdeclaration-after-statement (C only)
>>       Warn when a declaration is found after a statement in a block.
>>       This construct, known from C++, was introduced with ISO C99 and is
>>       by default allowed in GCC.  It is not supported by ISO C90 and was
>>       not supported by GCC versions before GCC 3.0.
> 
> Yeah, okay, that's certainly true.  I'm kind of surprised 'gcc -ansi'
> didn't complain about it.  I guess it's less ANSI-compliant than they
> advertise.
> 
>> This helps a lot! But there are still some issues. The biggest show-stopper
>> for C-only compiler is above msvc requirement. Compiled as C++ at least some
>> files make no problems.
>>
>> I assume therefore, that after the decision how we handle the declaration
>> problem it becomes straight forward to finish the msvc support.
>>
>> So do we want to to touch every file and move every local variable declaration
>> in every function to make it compile with -Werror=declaration-after-statement?
>>
>> Peter
> 
> Yeah, I think we should fix the declarations.  There's no point in
> claiming to be ANSI compliant if it's not.  I'll add it to the list.

Respect! It will be so much stupid moving of code.

> 
> Thanks,
> -dvw

Re: [getdata-devel] GetData 0.7.0 released

[Peter K. <syn...@gm...>]

On 23.11.2010 02:36, D. V. Wiebe wrote:
> GetData 0.7.0 has been released.  It may be downloaded from your local
> SourceForge mirror:
> 
> http://sourceforge.net/projects/getdata/files/getdata/0.7.0/
> 
> GetData 0.7.0 comes with a large API change: almost every function in
> the C API has been renamed to provide better namespace encapsulation.
> This was required to build GetData on MacOS X.  GetData is now supported
> under MacOS X and well as Cygwin and Win32 using MinGW.  (Some work has
> been done to allow building GetData witn MSVC, but more work remains.)
> 
> GetData also 0.7.0 introduces Dirfile Standards Version 8.  This new
> Standards Verison introduces the DIVIDE, RECIP and CARRAY field types.
> An ASCII conversion utility, dirfile2ascii, written by Matthew Truch, is
> also included in this package.
> 
> The release notes contain a complete list of the changes and numerous
> bug fixes from the previous release:
> 
> http://sourceforge.net/projects/getdata/files/getdata/0.7.0/RELEASE_NOTES-0.7.0/view
> 
> Cheers,
> -dvw

Great, OX support!
I already used it to create a Kst2 .dmg which comes with the dirfile/getdata plugin:
http://sourceforge.net/projects/kst/files/Snapshots/kst2-alpha-2.dmg

Peter

Re: [getdata-devel] MinGW patches

[D. V. W. <ge...@ke...>]

On Mon, Nov 22, 2010 at 12:02:15PM +0100, Peter K?mmel wrote:
> Then you will be really surprised to hear this: MSVC requires all local
> variables to be declared at the beginning of a function.
> 
> Seems mixing code and variable definitions is a C++/C99 feature:
> 
>   -Wdeclaration-after-statement (C only)
>       Warn when a declaration is found after a statement in a block.
>       This construct, known from C++, was introduced with ISO C99 and is
>       by default allowed in GCC.  It is not supported by ISO C90 and was
>       not supported by GCC versions before GCC 3.0.

Yeah, okay, that's certainly true.  I'm kind of surprised 'gcc -ansi'
didn't complain about it.  I guess it's less ANSI-compliant than they
advertise.

> This helps a lot! But there are still some issues. The biggest show-stopper
> for C-only compiler is above msvc requirement. Compiled as C++ at least some
> files make no problems.
> 
> I assume therefore, that after the decision how we handle the declaration
> problem it becomes straight forward to finish the msvc support.
> 
> So do we want to to touch every file and move every local variable declaration
> in every function to make it compile with -Werror=declaration-after-statement?
> 
> Peter

Yeah, I think we should fix the declarations.  There's no point in
claiming to be ANSI compliant if it's not.  I'll add it to the list.

Thanks,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

[getdata-devel] GetData 0.7.0 released

[D. V. W. <ge...@ke...>]

GetData 0.7.0 has been released.  It may be downloaded from your local
SourceForge mirror:

http://sourceforge.net/projects/getdata/files/getdata/0.7.0/

GetData 0.7.0 comes with a large API change: almost every function in
the C API has been renamed to provide better namespace encapsulation.
This was required to build GetData on MacOS X.  GetData is now supported
under MacOS X and well as Cygwin and Win32 using MinGW.  (Some work has
been done to allow building GetData witn MSVC, but more work remains.)

GetData also 0.7.0 introduces Dirfile Standards Version 8.  This new
Standards Verison introduces the DIVIDE, RECIP and CARRAY field types.
An ASCII conversion utility, dirfile2ascii, written by Matthew Truch, is
also included in this package.

The release notes contain a complete list of the changes and numerous
bug fixes from the previous release:

http://sourceforge.net/projects/getdata/files/getdata/0.7.0/RELEASE_NOTES-0.7.0/view

Cheers,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] MinGW patches

[Peter K. <syn...@gm...>]

On 14.10.2010 02:44, D. V. Wiebe wrote:
> On Wed, Oct 13, 2010 at 11:12:09PM +0200, Peter K?mmel wrote:
>> Am Dienstag, den 12.10.2010, 18:25 -0700 schrieb D. V. Wiebe:
>>> Yeah, right, that sounds familiar now. I apparently *do* set
>>> __MSVCRT_VERSION__ to 0x0601, though I couldn't recall why.  Thanks.  I
>>> should probably add a comment about that...
>>>
>>> And, while I'm thinking about it, are you happy with the current GetData
>>> HEAD and MSVC++?  The BLASTpol-ers were asking me for a release before
>>> their upcoming campaign.
>>>
>>> -dvw
>>
>> I'm happy with HEAD and MinGW, but for MSVC HEAD is without use.
>> And I would not wait for MSVC support with the next release.
>>
>> Peter
> 
> Ah, too bad, although perhaps I forgot to tell you that I C89-ified the code?
> Try defining GD_NO_C99_API in config.h, which should reduce everything to
> straight C89.  I'd be kind of surprised if MSVC couldn't handle ANSI C.

Then you will be really surprised to hear this: MSVC requires all local
variables to be declared at the beginning of a function.

Seems mixing code and variable definitions is a C++/C99 feature:

  -Wdeclaration-after-statement (C only)
      Warn when a declaration is found after a statement in a block.
      This construct, known from C++, was introduced with ISO C99 and is
      by default allowed in GCC.  It is not supported by ISO C90 and was
      not supported by GCC versions before GCC 3.0.

> 
> With GD_NO_C99_API defined to one, I can compile the GetData C library
> both with 'gcc --ansi' and with g++.  (As advertised, this will disable
> the C99 API in getdata.h completely, effectively GD_C89_API is always
> defined.  But this should be transparent to kst, since the C++ bindings
> are unaffected.)

This helps a lot! But there are still some issues. The biggest show-stopper
for C-only compiler is above msvc requirement. Compiled as C++ at least some
files make no problems.

I assume therefore, that after the decision how we handle the declaration
problem it becomes straight forward to finish the msvc support.

So do we want to to touch every file and move every local variable declaration
in every function to make it compile with -Werror=declaration-after-statement?

Peter


> 
> Thanks for the update; I'll work on putting out a release, and maybe we
> can get back to looking for a solution.
> 
> Cheers,
> -dvw

Re: [getdata-devel] MinGW patches

[Peter K. <syn...@gm...>]

Am Dienstag, den 12.10.2010, 18:25 -0700 schrieb D. V. Wiebe:
> On Sat, Sep 25, 2010 at 12:18:53PM +0200, Peter K?mmel wrote:
> > On 25.09.2010 11:18, Peter K?mmel wrote:
> > > 
> > >>> Index: src/internal.h
> > >>> ===================================================================
> > >>> --- src/internal.h	(Revision 446)
> > >>> +++ src/internal.h	(Arbeitskopie)
> > >>> @@ -243,7 +243,7 @@
> > >>>  typedef struct stat64 gd_stat64_t;
> > >>>  #elif HAVE_STRUCT___STAT64
> > >>>  typedef struct __stat64 gd_stat64_t;
> > >>> -#elif defined __CYGWIN__ || defined __APPLE__
> > >>> +#elif defined __CYGWIN__ || defined __APPLE__ || __MINGW32__
> > >>>  typedef struct stat gd_stat64_t;
> > >>>  #endif
> > >>
> > >> (I can't check this right now, but, as far as I can recall): MinGW
> > >> should be using struct __stat64 (from the MSVCRT) as gd_stat64, so
> > >> try defining HAVE_STRUCT___STAT64 (with three underscores in a row)
> > >> in config.h.
> > > 
> > > It's _stati64, see attached patch.
> > 
> > When support for "Win95 OSR 2" is dropped
> >     http://lists.fedoraproject.org/pipermail/mingw/2009-March/000957.html
> > -D__MSVCRT_VERSION__=0x0601 could be used and we don't need the patch.
> > 
> > I assume the auto build system already sets __MSVCRT_VERSION__ to 0x0601
> > or higher. So ignore the patch.
> > 
> > Peter
> 
> Yeah, right, that sounds familiar now. I apparently *do* set
> __MSVCRT_VERSION__ to 0x0601, though I couldn't recall why.  Thanks.  I
> should probably add a comment about that...
> 
> And, while I'm thinking about it, are you happy with the current GetData
> HEAD and MSVC++?  The BLASTpol-ers were asking me for a release before
> their upcoming campaign.
> 
> -dvw

I'm happy with HEAD and MinGW, but for MSVC HEAD is without use.
And I would not wait for MSVC support with the next release.

Peter

Re: [getdata-devel] MinGW patches

[D. V. W. <ge...@ke...>]

On Sat, Sep 25, 2010 at 12:18:53PM +0200, Peter K?mmel wrote:
> On 25.09.2010 11:18, Peter K?mmel wrote:
> > 
> >>> Index: src/internal.h
> >>> ===================================================================
> >>> --- src/internal.h	(Revision 446)
> >>> +++ src/internal.h	(Arbeitskopie)
> >>> @@ -243,7 +243,7 @@
> >>>  typedef struct stat64 gd_stat64_t;
> >>>  #elif HAVE_STRUCT___STAT64
> >>>  typedef struct __stat64 gd_stat64_t;
> >>> -#elif defined __CYGWIN__ || defined __APPLE__
> >>> +#elif defined __CYGWIN__ || defined __APPLE__ || __MINGW32__
> >>>  typedef struct stat gd_stat64_t;
> >>>  #endif
> >>
> >> (I can't check this right now, but, as far as I can recall): MinGW
> >> should be using struct __stat64 (from the MSVCRT) as gd_stat64, so
> >> try defining HAVE_STRUCT___STAT64 (with three underscores in a row)
> >> in config.h.
> > 
> > It's _stati64, see attached patch.
> 
> When support for "Win95 OSR 2" is dropped
>     http://lists.fedoraproject.org/pipermail/mingw/2009-March/000957.html
> -D__MSVCRT_VERSION__=0x0601 could be used and we don't need the patch.
> 
> I assume the auto build system already sets __MSVCRT_VERSION__ to 0x0601
> or higher. So ignore the patch.
> 
> Peter

Yeah, right, that sounds familiar now. I apparently *do* set
__MSVCRT_VERSION__ to 0x0601, though I couldn't recall why.  Thanks.  I
should probably add a comment about that...

And, while I'm thinking about it, are you happy with the current GetData
HEAD and MSVC++?  The BLASTpol-ers were asking me for a release before
their upcoming campaign.

-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] MinGW patches

[Peter K. <syn...@gm...>]

On 25.09.2010 11:18, Peter Kümmel wrote:
> 
>>> Index: src/internal.h
>>> ===================================================================
>>> --- src/internal.h	(Revision 446)
>>> +++ src/internal.h	(Arbeitskopie)
>>> @@ -243,7 +243,7 @@
>>>  typedef struct stat64 gd_stat64_t;
>>>  #elif HAVE_STRUCT___STAT64
>>>  typedef struct __stat64 gd_stat64_t;
>>> -#elif defined __CYGWIN__ || defined __APPLE__
>>> +#elif defined __CYGWIN__ || defined __APPLE__ || __MINGW32__
>>>  typedef struct stat gd_stat64_t;
>>>  #endif
>>
>> (I can't check this right now, but, as far as I can recall): MinGW
>> should be using struct __stat64 (from the MSVCRT) as gd_stat64, so
>> try defining HAVE_STRUCT___STAT64 (with three underscores in a row)
>> in config.h.
> 
> It's _stati64, see attached patch.

When support for "Win95 OSR 2" is dropped
    http://lists.fedoraproject.org/pipermail/mingw/2009-March/000957.html
-D__MSVCRT_VERSION__=0x0601 could be used and we don't need the patch.

I assume the auto build system already sets __MSVCRT_VERSION__ to 0x0601
or higher. So ignore the patch.

Peter

Re: [getdata-devel] MinGW patches

[Peter K. <syn...@gm...>]

>> Index: src/internal.h
>> ===================================================================
>> --- src/internal.h	(Revision 446)
>> +++ src/internal.h	(Arbeitskopie)
>> @@ -243,7 +243,7 @@
>>  typedef struct stat64 gd_stat64_t;
>>  #elif HAVE_STRUCT___STAT64
>>  typedef struct __stat64 gd_stat64_t;
>> -#elif defined __CYGWIN__ || defined __APPLE__
>> +#elif defined __CYGWIN__ || defined __APPLE__ || __MINGW32__
>>  typedef struct stat gd_stat64_t;
>>  #endif
> 
> (I can't check this right now, but, as far as I can recall): MinGW
> should be using struct __stat64 (from the MSVCRT) as gd_stat64, so
> try defining HAVE_STRUCT___STAT64 (with three underscores in a row)
> in config.h.

It's _stati64, see attached patch.

Peter

Re: [getdata-devel] Compile with -Wall breaks on non-gnu compilers

[D. V. W. <ge...@ke...>]

On Thu, Sep 16, 2010 at 07:19:05AM -0700, Ted Kisner wrote:
> Hi there,
> 
> I noticed in a recent checkout of trunk that the "-Wall" option is still being used.  This causes some compilers (notably PGI) to refuse to compile the source and spit out an "unknown option" error.
> 
> Currently I patch the source and remove all these from the Makefile.am's when building on the systems at NERSC.
> 
> Would it be possible to get rid of this hard-coded option?  You can always specify "-Wall" as part of the CFLAGS / CXXFLAGS / FFLAGS during configure, so it you want to test everything before a release this can still be done.
> 
> I have attached a patch against revision 446 that removes the "-Wall" from all automake files.
> 
> Thanks for your thoughts.
> 
> -Ted

Right, hardcoded -Wall's should be gone.  configure will check whether
the compiler likes it, and use it only if it does (as it already did
with -Wextra).

Cheers,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] [Getdata-commits] SF.net SVN: getdata:[446] trunk/getdata

[D. V. W. <ge...@ke...>]

On Wed, Sep 15, 2010 at 07:21:04AM +0200, Peter Kuemmel wrote:
> > Log Message:
> > -----------
> > As Ted points out, EOF isn't really a good member name.
> 
> Very good, I also had trouble with this naming.
> 
> 
> Aren't these functions in principle const member functions?
>     
>     off_t EoF(const char *field_code) const;
> 
> Peter

Yeah, good point.  Why don't I go through and mark all the const
members.

Thanks,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

[getdata-devel] Compile with -Wall breaks on non-gnu compilers

[Ted K. <tsk...@gm...>]

Hi there,

I noticed in a recent checkout of trunk that the "-Wall" option is still being used.  This causes some compilers (notably PGI) to refuse to compile the source and spit out an "unknown option" error.

Currently I patch the source and remove all these from the Makefile.am's when building on the systems at NERSC.

Would it be possible to get rid of this hard-coded option?  You can always specify "-Wall" as part of the CFLAGS / CXXFLAGS / FFLAGS during configure, so it you want to test everything before a release this can still be done.

I have attached a patch against revision 446 that removes the "-Wall" from all automake files.

Thanks for your thoughts.

-Ted

[getdata-devel] MinGW patches

[Peter K. <syn...@gm...>]

Attached a patch to compile getdata with mingw without cygwin.

Peter

Re: [getdata-devel] [Getdata-commits] SF.net SVN: getdata:[446] trunk/getdata

[Peter K. <syn...@gm...>]

> Log Message:
> -----------
> As Ted points out, EOF isn't really a good member name.

Very good, I also had trouble with this naming.


Aren't these functions in principle const member functions?
    
    off_t EoF(const char *field_code) const;

Peter

[getdata-devel] getdata-commits

[D. V. W. <ge...@ke...>]

As requested by Peter, I've created a mailing list for SVN commits.  You
won't be able to post to it, but I believe you can subscribe to it here:

http://lists.sourceforge.net/lists/listinfo/getdata-commits

It might even work!

Cheers,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] GETDATA_C89_API

[D. V. W. <ge...@ke...>]

On Sun, Sep 05, 2010 at 10:29:49PM +0200, Peter K?mmel wrote:
> Am Dienstag, den 31.08.2010, 19:41 -0700 schrieb D. V. Wiebe:
> > I'm a bit leery of doing it this way since it relies on std::complex
> > storing its data in RAM in Fortran order, when the C++98 standard leaves
> > the storage format of std::complex implementation dependent.  (The
> > proposed C++0x standard intends to fix this, but let's not hold our
> > breath for that.)
> 
> Doesn't the current code use creal() and cimag() so the RAM order isn't
> important:
> 
> +#  define creal(v) v.real()
> +#  define cimag(v) v.imag()

GetData assumes Fortran-ordering when reading complex data from disk.
(I also suspect I've type-punned complex data into purely real data
in places.)  Both of these could be dealt with.

This past weekend I hacked together an ANSI C version of GetData, which
still requires some finishing work, but can be compiled without
knowledge of C99.  I'm curious what it does to the library's performance.
I'm sort of interested in seeing how your C++ version does as well.
Perhaps I can come up with some sort of usable polymorphic system.
Thanks for the std::complex patch; I'll try to shoehorn it into my
working copy.

> Starting the msvc port ends in much stupid work,
> http://websvn.kde.org/branches/work/kst/portto4/kst/misc/getdata-windows/msvc.patch?revision=1157304&view=markup

The explicit pointer casts are probably a good idea regardless; most of
the rest appears to be related to the complex stuff.

> and not being sure if I'm on the right way I've stopped and gave mingw a
> try. And is was much simpler! I only had to patch a bit: 
> http://websvn.kde.org/branches/work/kst/portto4/kst/misc/getdata-windows/mingw.patch?view=markup
> most of the patch is a cleanup of the c++ headers and is not depended to
> mingw (I should already have posted this part to getdata.)

I think I've done a lot of the MinGW stuff already.  At one point I
could build trunk with MinGW, but it's possible I've since broken it
again.  I'll recheck.
 
> Kst need also the C++ binding, and I'm not sure if it uses complex data.

That's actually something of a blessing since any changes made to the
C-library are hidden from kst.

Cheers,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] GETDATA_C89_API

[Peter K. <syn...@gm...>]

Am Dienstag, den 31.08.2010, 19:41 -0700 schrieb D. V. Wiebe:
> On Thu, Jul 29, 2010 at 12:01:19PM +0200, Peter K?mmel wrote:
> > >> Additionally maybe we catch some wrong implicit casts when compiling
> > >> with the stronger typechecks of C++. For instance I wondered about
> > >> this in add.c's _GD_Add function:
> > >>
> > >>     E->cm[i] = E->m[i];
> > >>     E->cb[i] = E->b[i];
> > >>
> > >> cm[i] is complex number, but m[i] is only a double:
> > > 
> > > Yeah, I'm relying on the mandated behaviour of C99 type promotion here.
> > > This only happens when the parameters are purely real, so I want cm[i]
> > > to be equal to m[i].  C99 says this assignment will result in what I
> > > want, ie.:
> > > 
> > > creal(cm[i]) = m[i]
> > > cimag(cm[i]) = 0
> > > 
> > > I can't imagine what C++ might think about this, but since C++-98
> > > doesn't know about C99-complex data storage, I wouldn't be surprised if
> > > it complains.
> > 
> > When I use std::complex for E->cm also C++ compiles the original code.
> > 
> > Therefore, not supporting C89 compilers, I think the best and most generic
> > route would be to make the code C++ compilable. Find attached a patch
> > with the necessary changes for compiling add.c, most is straight forward.
> > 
> > If you also think this the way to go I could port the rest of the code
> > and send patches to the list.
> > 
> > Peter
> 
> Peter,
> 
> Sorry for the delayed response.  I've been distracted by other things.

I'm happy to see I've not frightened you in some way ;)

> I'm a bit leery of doing it this way since it relies on std::complex
> storing its data in RAM in Fortran order, when the C++98 standard leaves
> the storage format of std::complex implementation dependent.  (The
> proposed C++0x standard intends to fix this, but let's not hold our
> breath for that.)

Doesn't the current code use creal() and cimag() so the RAM order isn't
important:

+#  define creal(v) v.real()
+#  define cimag(v) v.imag()

> 
> I think it might be best to simply choose the lowest common denominator,
> and do the C89 thing.  Unfortunately, there are now public functions
> which pass complex data by value, so I'll have to figure out what to do
> about that.
> 
> I haven't been keeping up with the kst mailing list.  Did you manage to
> compile GetData under MSVC?  Also, can you remind me: does kst2 link to
> the C++ bindings, or does it use GetData's C API directly?  Oh, and does
> kst2 make use of native complex data?  Or is it still doing everything
> in doubles?

Starting the msvc port ends in much stupid work,
http://websvn.kde.org/branches/work/kst/portto4/kst/misc/getdata-windows/msvc.patch?revision=1157304&view=markup
and not being sure if I'm on the right way I've stopped and gave mingw a
try. And is was much simpler! I only had to patch a bit: 
http://websvn.kde.org/branches/work/kst/portto4/kst/misc/getdata-windows/mingw.patch?view=markup
most of the patch is a cleanup of the c++ headers and is not depended to
mingw (I should already have posted this part to getdata.)

Kst need also the C++ binding, and I'm not sure if it uses complex data.

Peter

Re: [getdata-devel] getdata on OS X

[D. V. W. <ge...@ke...>]

On Wed, Sep 01, 2010 at 08:46:36AM -0700, Ted Kisner wrote:
>    Ok, after installing a newer version of libtool, I noticed a few things
>    building svn trunk:
>    1.  In order to run "make dist", you actually need to be on a system where
>    you have run configure and enabled all bindings (even IDL).  Fortunately I
>    had access to such a system...

Ah, now that sounds like a bug.  I'll look into it.  Thanks.  (You're probably
the second person ever to run "make dist".)

>    2.  Compiling on OS X 10.6.4 (64 bit) with gcc-mp-4.4 and friends from
>    macports, the C++ bindings fail to build.  The problem is the "EOF"
>    function, which on case-insensitive systems conflicts with the "eof"
>    function.  Renaming this function (e.g. "GEOF") in both
>    cxx/getdata/dirfile.h and cxx/dirfile.cpp allows everything to compile.

Yeah, that was an admittedly poor choice for a name on my part.  I'll fix it.

>    3.  When running "make check", I think I see the same problem that is
>    being discussed on the kst mailing list:
>    /bin/sh ../libtool --tag=CC   --mode=link gcc-mp-4.4 -std=gnu99  -m64 -O3
>    -march=native   -o add_cpolynom add_cpolynom.o ../src/libgetdata.la 
>    libtool: link: gcc-mp-4.4 -std=gnu99 -m64 -O3 -march=native -o
>    .libs/add_cpolynom add_cpolynom.o  ../src/.libs/libgetdata.dylib -lz -lbz2
>    gcc-mp-4.4 -std=gnu99 -DHAVE_CONFIG_H -I. -I../src -Wall -Wextra -I../src
>    -D__TEST__=\"add_crecip.o\"    -m64 -O3 -march=native -MT add_crecip.o -MD
>    -MP -MF .deps/add_crecip.Tpo -c -o add_crecip.o add_crecip.c
>    mv -f .deps/add_crecip.Tpo .deps/add_crecip.Po
>    /bin/sh ../libtool --tag=CC   --mode=link gcc-mp-4.4 -std=gnu99  -m64 -O3
>    -march=native   -o add_crecip add_crecip.o ../src/libgetdata.la 
>    libtool: link: gcc-mp-4.4 -std=gnu99 -m64 -O3 -march=native -o
>    .libs/add_crecip add_crecip.o  ../src/.libs/libgetdata.dylib -lz -lbz2
>    gcc-mp-4.4 -std=gnu99 -DHAVE_CONFIG_H -I. -I../src -Wall -Wextra -I../src
>    -D__TEST__=\"add_crecip89.o\"    -m64 -O3 -march=native -MT add_crecip89.o
>    -MD -MP -MF .deps/add_crecip89.Tpo -c -o add_crecip89.o add_crecip89.c
>    add_crecip89.c: In function 'main':
>    add_crecip89.c:22: error: incompatible type for argument 4 of
>    'gd_add_crecip'
>    ../src/getdata.h:368: note: expected 'complex double' but argument is of
>    type 'double *'
>    add_crecip89.c:33: error: subscripted value is neither array nor pointer
>    add_crecip89.c:33: error: subscripted value is neither array nor pointer
>    add_crecip89.c:34: error: subscripted value is neither array nor pointer
>    add_crecip89.c:34: error: subscripted value is neither array nor pointer
>    make[2]: *** [add_crecip89.o] Error 1
>    make[1]: *** [check-am] Error 2
>    make: *** [check-recursive] Error 1

Not quite sure what's going on here; there are still a few rough edges in
trunk.  C89-ifying the whole thing might address this, but I'll keep it
in mind regardless.

>    Overall, however, I am happy that I can now distribute a temporary tarball
>    for use on OS X within a couple different experiments that I'm involved
>    with- Thanks for all your work keeping the dirfile flame alive :-)
>    -Ted

Glad it's useful.  Keep the bug reports coming.

Cheers,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] getdata on OS X

[Ted K. <tsk...@gm...>]

Ok, after installing a newer version of libtool, I noticed a few things building svn trunk:

1.  In order to run "make dist", you actually need to be on a system where you have run configure and enabled all bindings (even IDL).  Fortunately I had access to such a system...

2.  Compiling on OS X 10.6.4 (64 bit) with gcc-mp-4.4 and friends from macports, the C++ bindings fail to build.  The problem is the "EOF" function, which on case-insensitive systems conflicts with the "eof" function.  Renaming this function (e.g. "GEOF") in both cxx/getdata/dirfile.h and cxx/dirfile.cpp allows everything to compile.

3.  When running "make check", I think I see the same problem that is being discussed on the kst mailing list:

/bin/sh ../libtool --tag=CC   --mode=link gcc-mp-4.4 -std=gnu99  -m64 -O3 -march=native   -o add_cpolynom add_cpolynom.o ../src/libgetdata.la 
libtool: link: gcc-mp-4.4 -std=gnu99 -m64 -O3 -march=native -o .libs/add_cpolynom add_cpolynom.o  ../src/.libs/libgetdata.dylib -lz -lbz2
gcc-mp-4.4 -std=gnu99 -DHAVE_CONFIG_H -I. -I../src -Wall -Wextra -I../src -D__TEST__=\"add_crecip.o\"    -m64 -O3 -march=native -MT add_crecip.o -MD -MP -MF .deps/add_crecip.Tpo -c -o add_crecip.o add_crecip.c
mv -f .deps/add_crecip.Tpo .deps/add_crecip.Po
/bin/sh ../libtool --tag=CC   --mode=link gcc-mp-4.4 -std=gnu99  -m64 -O3 -march=native   -o add_crecip add_crecip.o ../src/libgetdata.la 
libtool: link: gcc-mp-4.4 -std=gnu99 -m64 -O3 -march=native -o .libs/add_crecip add_crecip.o  ../src/.libs/libgetdata.dylib -lz -lbz2
gcc-mp-4.4 -std=gnu99 -DHAVE_CONFIG_H -I. -I../src -Wall -Wextra -I../src -D__TEST__=\"add_crecip89.o\"    -m64 -O3 -march=native -MT add_crecip89.o -MD -MP -MF .deps/add_crecip89.Tpo -c -o add_crecip89.o add_crecip89.c
add_crecip89.c: In function 'main':
add_crecip89.c:22: error: incompatible type for argument 4 of 'gd_add_crecip'
../src/getdata.h:368: note: expected 'complex double' but argument is of type 'double *'
add_crecip89.c:33: error: subscripted value is neither array nor pointer
add_crecip89.c:33: error: subscripted value is neither array nor pointer
add_crecip89.c:34: error: subscripted value is neither array nor pointer
add_crecip89.c:34: error: subscripted value is neither array nor pointer
make[2]: *** [add_crecip89.o] Error 1
make[1]: *** [check-am] Error 2
make: *** [check-recursive] Error 1


Overall, however, I am happy that I can now distribute a temporary tarball for use on OS X within a couple different experiments that I'm involved with- Thanks for all your work keeping the dirfile flame alive :-)

-Ted


On Aug 31, 2010, at 7:42 PM, D. V. Wiebe wrote:

> Big caveat: in addition to OS X and Windows support, 0.7 (and trunk)
> breaks API compatibility with previous versions.  "Breaks" might not be
> a strong enough verb.
> 
> Check out the SVN if you're interested.  If you get impatient for a
> release let me know, and I can see whether buttoning up what's there now
> would be worth it.