in reply to Re^2: Need Help Porting XS Modules to Windows
in thread Need Help Porting XS Modules to Windows

The funny thing is that src\xs_arrays.c only uses the three constants CblasNoTrans,CblasTrans,CblasConjTrans from BLAS header and does the rest of the array manipulation by hand

So, in src/xs_arrays.c, I've replaced: 
#include <Accelerate/Accelerate.h>

[download]
with: 
typedef enum {CblasNoTrans=111, CblasTrans=112, CblasConjTrans=113} CB
+LAS_TRANSPOSE;

[download]
and that enables xs_arrays.c to be compiled.
The same alteration needs also to be made to src/xs_stat.c.

But lib/ICC/Support/Lapack.xs also includes Accelerate/Accelerate.h - only this time the above "typedef enum ..." is insufficient as a replacement.
So I've included some additional definitions to Lapack.xs (from cblas.h): 
typedef enum {CblasNoTrans=111, CblasTrans=112, CblasConjTrans=113} CB
+LAS_TRANSPOSE;
typedef enum {CblasRowMajor=101, CblasColMajor=102} CBLAS_LAYOUT;
typedef enum {CblasUpper=121, CblasLower=122} CBLAS_UPLO;
typedef enum {CblasNonUnit=131, CblasUnit=132} CBLAS_DIAG;
typedef enum {CblasLeft=141, CblasRight=142} CBLAS_SIDE;
typedef int __CLPK_integer;
typedef double __CLPK_doublereal;

[download]
That just about enables the thing to compile, but having altered Lapack.xs, I inevitably get the following errors: 
lib\\ICC\\Support\\Lapack.xs:1:1: error: stray '\357' in program
 &#65279;/*
 ^
lib\\ICC\\Support\\Lapack.xs:1:2: error: stray '\273' in program
 &#65279;/*
  ^
lib\\ICC\\Support\\Lapack.xs:1:3: error: stray '\277' in program
 &#65279;/*
   ^

[download]
and I don't know why such a complaint is being made about a file that appears to be entirely valid.

I've run out of time for tonight.

Cheers,
Rob

Replies are listed 'Best First'.
Re^4: Need Help Porting XS Modules to Windows
by Anonymous Monk on Oct 01, 2018 at 13:43 UTC
    appears to be entirely valid

    Exactly! :)

    Someone had forgotten a ZERO WIDTH NO-BREAK SPACE (which is encoded to ef bb bf in UTF-8) in the beginning of the file. Programmers' text editors usually highlight such "strange" characters, but in this case, my copy of Vim says that a three-byte file with this code point consists of "0 lines and 3 characters", but looks entirely empty.

[reply]
[d/l]
[select]

      A ZERO WIDTH NO-BREAK SPACE shares the same codepoint with the BYTE ORDER MARK (U+00FEFF).

      If the BOM character appears in the middle of a data stream, Unicode says it should be interpreted as a "zero-width non-breaking space" (inhibits line-breaking between word-glyphs). In Unicode 3.2, this usage is deprecated in favor of the "Word Joiner" character, U+2060.1 This allows U+FEFF to be only used as a BOM.

      A BOM is required for UTF-16 (because of endianness UTF-16be vs UTF-16le). In UTF-8 encoded files, a BOM is optional and advised to omit.

      "The Unicode Standard 5.0, Chapter 2:General Structure" (PDF). p. 36. Retrieved 2008-11-30. Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature

      Read this very nice article. It is about perl6, but there is no code in there whatsoever, so it have easily been written in the earlier days of perl5 but with new insights.


      Enjoy, Have FUN! H.Merijn
[reply]
[d/l]
[select]
        Thank you! I should have recognised the U+FEFF codepoint as BOM, but I relied on Perl's charnames::viacode to produce the name for me. Indeed, a BOM in the beginning of a file is much less surprising.
[reply]
[d/l]
[select]
      Programmers' text editors usually highlight such "strange" characters

      Yes, I don't use a Programmers' text editor.
      Is there a way to remove the garbage using Windows' notepad or wordpad ?
      Otherwise, I guess I can use perl to remove it.

      Cheers,
      Rob
[reply]
        Notepad's "save as" "ANSI" should at least get rid of the BOM, and "save as" Unicode adds it…
[reply]

In Section Seekers of Perl Wisdom