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

Accelerate is Apple's implementation of BLAS and LAPACK, very old linear algebra libraries. A good free implementation of BLAS (and a part of LAPACK) for Windows is OpenBLAS. (A very good one, but only available to academics or for a fee, is Intel MKL.) On non-Apple platforms C source code should #include <cblas.h> or mkl.h, depending on preprocessor directives. I'm not sure whether it's possible to get a free LAPACK implementation for Windows without having a Fortran compiler, though.

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. (At least that's what it seemed to me while I skimmed the file.)

Replies are listed 'Best First'.
Re^3: Need Help Porting XS Modules to Windows
by syphilis (Archbishop) on Oct 01, 2018 at 13:10 UTC
    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
[reply]
[d/l]
[select]
      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]
        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]

In Section Seekers of Perl Wisdom