getdata-devel — General discussion of GetData development.

[getdata-devel] Perl build patch for strict CBuilder

[<sf-...@sn...>]

Hi Don-

My ExtUtils::CBuilder has 'use strict' and parses include_dirs as an
array.  This breaks when the Perl binding build with the error:
Can't use string ("../../src") as an ARRAY ref while "strict refs" in
use at /System/Library/Perl/5.10.0/ExtUtils/CBuilder/Base.pm line 92.

I've attached a patch which fixes the issue and works correctly for
Debian Sid, Ubuntu 12.04 and MacOS 10.6.8

Thanks,
Seth


diff --git a/bindings/perl/Build.PL.in b/bindings/perl/Build.PL.in
index d4e5491..ee20e9c 100644
--- a/bindings/perl/Build.PL.in
+++ b/bindings/perl/Build.PL.in
@@ -42,7 +42,7 @@ my $build = $class->new(
   dist_version_from => "GetData.pm",
   extra_compiler_flags => ['@DEFS@', '-I@top_builddir@/src'],
   extra_linker_flags => ['-L@top_builddir@/src/.libs/', '-lgetdata'],
-  include_dirs => '@top_srcdir@/src',
+  include_dirs => ['@top_srcdir@/src'],
   license => 'lgpl',
   module_name => "GetData",
   pm_files => { 'GetData.pm' => 'lib/GetData.pm' },

Re: [getdata-devel] Wrong date in the GetData changelog

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

On Tue, Mar 19, 2013 at 11:46:45AM -0400, Jaromir Capik wrote:
> Hello.
> 
> Please, fix the GetData changelog.
> Last twelve records have incorrect year in the date.
> 
> 2012 -> 2013
> 
> Thanks.

I've fixed it.  Thanks for the report.
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

[getdata-devel] Wrong date in the GetData changelog

[Jaromir C. <jc...@re...>]

Hello.

Please, fix the GetData changelog.
Last twelve records have incorrect year in the date.

2012 -> 2013

Thanks.

Regards,
Jaromir.

--
Jaromir Capik
Red Hat Czech, s.r.o.
Software Engineer / BaseOS

Email: jc...@re...
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkynova 99/71, 612 45, Brno, Czech Republic
IC: 27690016 

Re: [getdata-devel] Unexpected affix behavior in 0.8.2

[<sf-...@sn...>]

Thanks Don, that did it!

-Seth

On Wed, Mar 13, 2013 at 5:15 PM, D. V. Wiebe wrote:
> On Wed, Mar 13, 2013 at 03:08:01PM -0700, D. V. Wiebe wrote:
>> Thanks for the report.  I'll investigate.
>>
>> I'll have to think about this a bit.  Affixes have a tendency to confuse
>> me.  But, at first glance, it looks like there's at least a bug: the
>> prefix should at least be stripped from the /REFERENCE line in the child
>> dirfile.  I also don't understand why the child dirfile is being
>> rewritten, if all you've done is included it via gd_include() in the
>> parent.
>
> I think it's just the bug that I suspected: affixes aren't being
> stripped from /REFERENCE directives when they should be.  I've fixed it
> in SVN (rev 819).  There will probably be a 0.8.4 out soon.  (Apparently
> putting out a release is a good way to solicit bug reports.)
>
> If you're impatient, the following patch should apply against both 0.8.2
> and 0.8.3:
>
> -- CUT -- CUT -- CUT --
> --- src/flush.c (revision 818)
> +++ src/flush.c (revision 819)
> @@ -792,7 +792,7 @@
>    if (permissive || D->standards >= 6)
>      if (D->fragment[i].ref_name != NULL) {
>        fputs("/REFERENCE ", stream);
> -      _GD_StringEscapeise(stream, D->fragment[i].ref_name, 0, permissive,
> +      _GD_WriteFieldCode(D, stream, i, D->fragment[i].ref_name, permissive,
>            D->standards);
>        fputc('\n', stream);
>      }
> -- CUT -- CUT -- CUT --
>
> Cheers,
> -dvw
> --
> D. V. Wiebe
> ge...@ke...
> http://getdata.sourceforge.net/

Re: [getdata-devel] Unexpected affix behavior in 0.8.2

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

On Wed, Mar 13, 2013 at 03:08:01PM -0700, D. V. Wiebe wrote:
> Thanks for the report.  I'll investigate.
> 
> I'll have to think about this a bit.  Affixes have a tendency to confuse
> me.  But, at first glance, it looks like there's at least a bug: the
> prefix should at least be stripped from the /REFERENCE line in the child
> dirfile.  I also don't understand why the child dirfile is being
> rewritten, if all you've done is included it via gd_include() in the
> parent.

I think it's just the bug that I suspected: affixes aren't being
stripped from /REFERENCE directives when they should be.  I've fixed it
in SVN (rev 819).  There will probably be a 0.8.4 out soon.  (Apparently
putting out a release is a good way to solicit bug reports.)

If you're impatient, the following patch should apply against both 0.8.2
and 0.8.3:

-- CUT -- CUT -- CUT --
--- src/flush.c (revision 818)
+++ src/flush.c (revision 819)
@@ -792,7 +792,7 @@
   if (permissive || D->standards >= 6)
     if (D->fragment[i].ref_name != NULL) {
       fputs("/REFERENCE ", stream);
-      _GD_StringEscapeise(stream, D->fragment[i].ref_name, 0, permissive,
+      _GD_WriteFieldCode(D, stream, i, D->fragment[i].ref_name, permissive,
           D->standards);
       fputc('\n', stream);
     }
-- CUT -- CUT -- CUT --

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

Re: [getdata-devel] Unexpected affix behavior in 0.8.2

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

On Wed, Mar 13, 2013 at 01:22:49PM -0700, sf-...@sn... wrote:
> Hi Don et al-
> 
> I have some unexpected behavior in how getdata is handling reference
> fields in dirfile fragments that are included with affixes.  Here's
> the scenario:
> 
> 1) Create parent dirfile "./parent"
> 2) Create raw field "time" in parent
> 3) Set as reference with gd_reference(parent, "time")
> 4) Create child dirfile "./parent/child"
> 5) Create raw field "time" in child
> 6) Set as reference with gd_reference(child, "time")
> 7) Close child dirfile.
> 
> At this point, both parent and child dirfiles have a time vector which
> is set as reference as:
> time RAW UINT64 1000
> /REFERENCE time
> 
> 8) Include child with gd_include_affix(parent, "child/format", 0,
> "prefix_", NULL, GD_IGNORE_DUPS|GD_IGNORE_REFS)
> 9) Close the parent dirfile
> 
> At this point, metadata are flushed and the parent format file is
> correct but the child format file gets re-written such that the
> /REFERENCE field changes to
> /REFERENCE prefix_time
> 
> I may be misinterpreting the effect of the include flags.  If so,
> please let me know how to correct this behavior.  Ideally, I would
> like to have the child fragments remain independently valid DIRFILEs.
> 
> Thanks,
> Seth

Thanks for the report.  I'll investigate.

I'll have to think about this a bit.  Affixes have a tendency to confuse
me.  But, at first glance, it looks like there's at least a bug: the
prefix should at least be stripped from the /REFERENCE line in the child
dirfile.  I also don't understand why the child dirfile is being
rewritten, if all you've done is included it via gd_include() in the
parent.

You should be able to keep a child dirfile as an independently valid
dirfile, if they start out as one.  If you can't, it's either a bug or
a deficiency in the Dirfile Standards.

In the short term, try protecting the metadata of the child dirfile
after creating it and just before closing it (ie. between steps 6
and 7):

6.5) gd_alter_protection(child, GD_PROTECT_FORMAT, GD_ALL_FRAGMENTS);

That should prevent rewriting of the child/format file by the parent, at
the cost of not being able to modify its metadata.

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

[getdata-devel] Unexpected affix behavior in 0.8.2

[<sf-...@sn...>]

Hi Don et al-

I have some unexpected behavior in how getdata is handling reference
fields in dirfile fragments that are included with affixes.  Here's
the scenario:

1) Create parent dirfile "./parent"
2) Create raw field "time" in parent
3) Set as reference with gd_reference(parent, "time")
4) Create child dirfile "./parent/child"
5) Create raw field "time" in child
6) Set as reference with gd_reference(child, "time")
7) Close child dirfile.

At this point, both parent and child dirfiles have a time vector which
is set as reference as:
time RAW UINT64 1000
/REFERENCE time

8) Include child with gd_include_affix(parent, "child/format", 0,
"prefix_", NULL, GD_IGNORE_DUPS|GD_IGNORE_REFS)
9) Close the parent dirfile

At this point, metadata are flushed and the parent format file is
correct but the child format file gets re-written such that the
/REFERENCE field changes to
/REFERENCE prefix_time

I may be misinterpreting the effect of the include flags.  If so,
please let me know how to correct this behavior.  Ideally, I would
like to have the child fragments remain independently valid DIRFILEs.

Thanks,
Seth

[getdata-devel] GetData-0.8.3 released

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

GetData-0.8.3 has been released.  You may download it from your local
SourceForge mirror:

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

This is a bug-fix release, addressing bugs found after the release of 0.8.2.
Most notably, it fixes bugs which prevented GetData from working on big-ended
platforms, but it also fixes a few other minor bugs.

Also, since we had them lying around, this release introduces the MATLAB
bindings for GetData.  They're still somewhat experimental at this point,
and have not been well tested; use with caution.

Full release notes are provided at the bottom of the release page linked
above.

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

Re: [getdata-devel] Documentation: fragments

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

On Thu, Mar 07, 2013 at 02:26:29PM -0500, Barth Netterfield wrote:
> It is not clear (at least to me) what fragments are from the documentation.

Yeah.  The documentation isn't great.  Which documentation have you been
reading?  Man pages?  Webpages?

"Fragment" started off as "format-file fragment".

I tried calling fragments "format files", but I found that made the
documentation confusing, too, since there's a distinction between
"the file called 'format'" and "a file containg structural metatadata".

Would calling them "metadata files" or something, be clearer?
"Metafiles"?  "Structure files"?  "Catalogue files"?

"Metadata" isn't terribly clear, either, since there's also "content
metadata" (ie. /META fields).

"Fragment" has also grown to refer to refer to the portion of a dirfile
defined in one particular format file (and anything it /INCLUDES).  In
this case then it's a "dirfile fragment".

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

[getdata-devel] Documentation: fragments

[Barth N. <bar...@ut...>]

It is not clear (at least to me) what fragments are from the documentation.

-- 
Barth Netterfield
University of Toronto
416-845-0946

[getdata-devel] Project SVN repository URL changed

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

As part of Sourceforge's perpetual reinvention of itself, GetData's
subversion repository URL has changed.  The new repository root URL is:

  svn://svn.code.sourceforge.net/p/getdata/code

for read-only access.  (For write access use https:// or svn+ssh://).
The web-browser has also moved; it is now here:

  http://sourceforge.net/p/getdata/code/

They seem to have re-created the repository from a dump; the UUID has
changed.  This means "svn switch --relocate" won't work.  You'll have to
do a fresh check-out.

As a side-effect, apparently the commit email script that posted to
the getdata-commits mailing list has gone AWOL.  It looks like
there's now a RSS feed, though, so maybe that's sufficient?

  http://sourceforge.net/p/getdata/code/feed/

If so, we might think about retiring the -commits list.  I'll
investigate fixing it.

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

Re: [getdata-devel] [PATCH] set gd_unaligned_ok for ppc64 as well

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

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

[getdata-devel] 382 of 906 tests failed on powerpc

[Dinar V. <k0...@op...>]

Hi,
on powerpc, both 32 and 64bit tests are failing.
Looks like a BigEndian issue.

Please find log attached.

Dinar,

[getdata-devel] [PATCH] set gd_unaligned_ok for ppc64 as well

[Dinar V. <k0...@op...>]

Index: getdata-0.8.2/configure.ac
===================================================================
--- getdata-0.8.2.orig/configure.ac
+++ getdata-0.8.2/configure.ac
@@ -326,7 +326,7 @@ echo "*** Checking host environment"
 echo
 AC_MSG_CHECKING([whether ${host} supports fast unaligned memory access])
 case "${host}" in
-  i?86-*-*|powerpc-*-*|x86_64-*-*) gd_unaligned_ok=yes;
+  i?86-*-*|powerpc*-*|x86_64-*-*) gd_unaligned_ok=yes;
   AC_DEFINE([UNALIGNED_ACCESS_OK], [1],
             [Define to 1 if the platform supports fast unaligned
memory access])
   ;;

[getdata-devel] GetData 0.8.2 released.

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

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

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

GetData 0.8.2 is a bug-fix release, correcting a few errors found after
the release of 0.8.1:

* trailink symlinks in paths no longer confuse the library
* reading the first sample of an MPLEX mo longer causes an internal error

Full release notes are provided at the bottom of the release page linked
above.

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

Re: [getdata-devel] Problem with symlinks to dirfiles in 0.8.1

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

On Sat, Dec 08, 2012 at 05:37:33PM +1300, Steve Benton wrote:
> Hi getdata,
> 
> There seems to be a problem in 0.8.1 by which getdata doesn't open
> symlinks to dirfiles. (This only applies at the top level; the path to
> the dirfile can contain symlinks.) This was originally noticed with kst,
> but I've reproduced it using dirfile2ascii, so it seems to be a getdata
> error.

Boooo.

I see what's going on.  You can work around it in 0.8.1 by adding a
trailing slash (ie. "/data/test.lnk/" should work).  This bug
certainly exists in 0.8.0, but is likely masked by an unrelated
segfault in most cases.

Let me try testing it a bit more, but I think it's an easy fix.  I'll
put out a fix as soon as I can.

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

[getdata-devel] Problem with symlinks to dirfiles in 0.8.1

[Steve B. <sb...@ph...>]

Hi getdata,

There seems to be a problem in 0.8.1 by which getdata doesn't open
symlinks to dirfiles. (This only applies at the top level; the path to
the dirfile can contain symlinks.) This was originally noticed with kst,
but I've reproduced it using dirfile2ascii, so it seems to be a getdata
error.

For example:
$ ls -l /data/
drwxr--r-- 9 sjb sjb 4096 Dec  7 13:47 etc
drwxrwxrwx 9 sjb sjb 4096 Dec  7 13:47 rawdir
lrwxrwxrwx 1 sjb sjb   33 Nov 30 15:54 test.lnk ->
/data/rawdir/1354064663.y_0662673
$ ./dirfile2ascii --first-frame=0:30 /data/test.lnk INDEX IFEL_1_GY
IFEL_2_GY
GetData error: Not a dirfile: /
$ ./dirfile2ascii --first-frame=0:30 /data/rawdir/1354064663.y_0662673
INDEX IFEL_1_GY IFEL_2_GY
0.000000 2013.265920 2013.265920
0.050000 2013.265920 2013.265920
0.100000 2013.265920 2013.265920
0.150000 2013.265920 2013.265920
0.200000 2013.265920 2013.265920
0.250000 2013.265920 2013.265920
0.300000 2013.265920 2013.265920
  ... etc ...

For now I have reverted to 0.7.3 and have not tested 0.8.0.

Cheers,
-Steve

Re: [getdata-devel] Ubuntu packaging

[Steve B. <sb...@ph...>]

I will also register a bug tracker, so that ubuntu reports (if any
arise) can flow upstream. Is the correct behaviour just to email this list?

On 12-10-22 12:40 PM, Steve Benton wrote:
> Hi getdata,
>
> I've been revisiting ubuntu packaging, and some of this bears discussion.
>
> First, an update for the "Get GetData" part of the web page: ubuntu
> releases newer than 12.04 Precise don't need to use a PPA, they will get
> a version of the package pulled in from debian. The PPA will be for
> pre-precise users, and for those that want more bleeding edge packages.
>
> Otherwise, the current use of the PPA ~stevebenton/kst2 is a little
> tacky, and I would prefer to create a getdata team on launchpad, to make
> the PPA ~getdata/ppa.
>
> I will also start using launchpad/bazaar to maintain the packaging
> information, so anyone in the getdata team (on launchpad) will be
> allowed to contribute, if anyone is so inclined.
>
> Launchpad also has a feature that allows automatic building and
> publishing of daily-updated packages. This would require importing code
> from the sourceforge svn server to a launchpad bazaar server, which is
> also automated. However, for a mature project without many (any?)
> bleeding-edge testers on ubuntu, I don't think this is necessary.
>
> Thoughts?
> -Steve

[getdata-devel] Ubuntu packaging

[Steve B. <sb...@ph...>]

Hi getdata,

I've been revisiting ubuntu packaging, and some of this bears discussion.

First, an update for the "Get GetData" part of the web page: ubuntu
releases newer than 12.04 Precise don't need to use a PPA, they will get
a version of the package pulled in from debian. The PPA will be for
pre-precise users, and for those that want more bleeding edge packages.

Otherwise, the current use of the PPA ~stevebenton/kst2 is a little
tacky, and I would prefer to create a getdata team on launchpad, to make
the PPA ~getdata/ppa.

I will also start using launchpad/bazaar to maintain the packaging
information, so anyone in the getdata team (on launchpad) will be
allowed to contribute, if anyone is so inclined.

Launchpad also has a feature that allows automatic building and
publishing of daily-updated packages. This would require importing code
from the sourceforge svn server to a launchpad bazaar server, which is
also automated. However, for a mature project without many (any?)
bleeding-edge testers on ubuntu, I don't think this is necessary.

Thoughts?
-Steve

[getdata-devel] make check fail for python interface

[Sigurd K. N. <s.k...@as...>]

Hi!

I am trying to install getdata on a linux system with pyton 2.6, and
while configure and make work fine, for make check, the two
python-related checks fail. The system is:

 Linux glamdring 2.6.18-308.13.1.el5xen #1 SMP Tue Aug 21 19:13:16 EDT
 2012 x86_64 x86_64 x86_64 GNU/Linux

And the tests fail due to a segmentation fault immediately when trying
to load the C extension. gdb shows that this happens in PyEval_GetFrame,
and according to valgrind, an invalid jump is happening here. So
probably something is seriously wrong with the shared library it is
trying to load (i.e. pygetdata.so).

Anyway, the output of make check tells me to contact this address, so
here you go.

Sigurd.

[getdata-devel] GetData-0.8.1 released

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

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

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

GetData 0.8.1 is a bug-fix release, correcting a few errors found after the release of 0.8.0,
mostly involving memory errors.

Full release notes are provided at the bottom of the release page linked above.

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

Re: [getdata-devel] GetData 0.8.0 released.

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

On 16.07.2012 23:33, D. V. Wiebe wrote:
>
> Yeah, I figured out how to run MSVC.  I haven't checked whether it works
> with kst-2, thought.  I'd be happy if you could test that.
>

It builds fine with Kst, but I haven't tested if it works. But with
all the tests on the getadata side I assume there are no problems

>> One small issue: many tests fail when mingw is used with cmd.exe.
>
> How do you run mingw with cmd.exe?  I managed to figure out how to get
> cmake to make a Makefile which uses make-mingw32 (or whatever its
> called).
>

Here you could download mingw-w64 GCC 4.7.1 for i686 or for 64 bit:

     sourceforge.net/projects/mingwbuilds/files/windows-host

then add mingw/bin to PATH and call

    cmake -G"MinGW Makefiles" ..\trunk\cmake

There is no make only 'mingw32-make'


>> Can I commit attached patch? But I'm not sure if cygwin/msys which
>> have 'rm' also set _WIN32.
>
> Please.  I can test cygwin/msys if you'd like.  If necessary, they can
> be excluded via the preprocessor.

OK committed.

Peter

Re: [getdata-devel] GetData 0.8.0 released.

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

On Sat, Jul 14, 2012 at 09:25:11PM +0200, Peter K?mmel wrote:
> On 05.07.2012 02:56, D. V. Wiebe wrote:
> >GetData 0.8.0 has been released.  It may be downloaded from your local
> >SourceForge mirror:
> >
> >http://sourceforge.net/projects/getdata/files/getdata/0.8.0/
> >
> >GetData introduces Dirfile Standards Version 9.  This new Standards
> >Version adds the MPLEX and WINDOW field types, and field name aliases,
> >the ability to modify field names provided in an /INCLUDE, and support
> >for the zzip compression of data.
> >
> >Additionally, GetData 0.8.0 introduces the ability to do automatic
> >sequential reads or writes, write support for gzip compressed Dirfiles,
> >and various other improvements and bug fixes.  This release also adds
> >Perl to the list of supported bindings.
> >
> >Full release notes are provided at the bottom of the release page
> >indicated above.
> >
> >Cheers,
> >-dvw
> 
> You also fixed the cmake files, great!

Yeah, I figured out how to run MSVC.  I haven't checked whether it works
with kst-2, thought.  I'd be happy if you could test that.

> One small issue: many tests fail when mingw is used with cmd.exe.

How do you run mingw with cmd.exe?  I managed to figure out how to get
cmake to make a Makefile which uses make-mingw32 (or whatever its
called).

> Can I commit attached patch? But I'm not sure if cygwin/msys which
> have 'rm' also set _WIN32.

Please.  I can test cygwin/msys if you'd like.  If necessary, they can
be excluded via the preprocessor.

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

Re: [getdata-devel] GetData 0.8.0 released.

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

On 05.07.2012 02:56, D. V. Wiebe wrote:
> GetData 0.8.0 has been released.  It may be downloaded from your local
> SourceForge mirror:
>
> http://sourceforge.net/projects/getdata/files/getdata/0.8.0/
>
> GetData introduces Dirfile Standards Version 9.  This new Standards
> Version adds the MPLEX and WINDOW field types, and field name aliases,
> the ability to modify field names provided in an /INCLUDE, and support
> for the zzip compression of data.
>
> Additionally, GetData 0.8.0 introduces the ability to do automatic
> sequential reads or writes, write support for gzip compressed Dirfiles,
> and various other improvements and bug fixes.  This release also adds
> Perl to the list of supported bindings.
>
> Full release notes are provided at the bottom of the release page
> indicated above.
>
> Cheers,
> -dvw

You also fixed the cmake files, great!

One small issue: many tests fail when mingw is used with cmd.exe.

Can I commit attached patch? But I'm not sure if cygwin/msys which
have 'rm' also set _WIN32.

Peter

Re: [getdata-devel] GetData 0.8.0 released.

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

Am Mittwoch, 11. Juli 2012, 17:58:58 schrieb D. V. Wiebe:
> One memory audit later, I think I've found the bug.  I'll try to get a
> new verious out soon with this fix a few other fixes people have found.
> 
Thanks for the info.

As a matter of fact I still get this error with gcc46 on openSUSE 12.1 with 
getdata-0.8.0. It was only "fixed" for the upcoming 12.2 release which uses 
gcc47. But today I tried the version from svn (rev 744) and there the test 
passes also for 12.1.

So it seems you have fixed the bug.

Kind regards
Christian