Mirror of forum.nim-lang.org

8771 :: Strange problem when using Futhark

• TKD (orginal) [2022-01-04T19:19:14+01:00] view original

  This code testing gsl works fine:

  
  import futhark
  
  {.passL: "-lgsl -lgslcblas".}
  
  importc:
    "gsl/gsl_sf_bessel.h"
  
  var
    x = 5.0
    y = gslSfBesselJ0(x)
  echo "J=(", x, ") = ", y
  Run

  but oddly, this does not:

  
  import futhark
  
  {.passL: "-lgsl -lgslcblas".}
  
  importc:
    "gsl/gsl_linalg.h"
  
  var
    a_data = @[ 0.18'f64, 0.60'f64, 0.57'f64, 0.96'f64, 0.41'f64, 0.24'f64, 0.99'f64, 0.58'f64, 0.14'f64, 0.30'f64, 0.97'f64, 0.66'f64, 0.51'f64, 0.13'f64, 0.19'f64, 0.85]
    b_data = @[1.0'f64, 2.0'f64, 3.0'f64, 4.0'f64]
    m = gsl_matrix_view_array(addr a_data[0], 4, 4)
  
  echo "a_data =(", a_data, ")"
  echo "b_data =(", b_data, ")"
  Run

  This is the error I get:

  
  /home/tkd/.nimble/pkgs/futhark-0.3.1/futhark.nim(440, 14) template/generic instantiation of `importcImpl` from here
  /home/tkd/.choosenim/toolchains/nim-1.6.0/lib/pure/parsejson.nim(179, 8) Error: interpretation requires too many iterations; if you are sure this is not a bug in your code, compile with `--maxLoopIterationsVM:number` (current value: 10000000)
  Run

---

• PMunch (orginal) [2022-01-05T09:44:23+01:00] view original

  Ah yes, this is a known limitation. Essentially the JSON generated to describe your C file is so big that the VM thinks it's encountered an infinite loop while parsing it. You can increase the limit as it says by passing something like --maxLoopIterationsVM:100000000 to the compiler.

---

• TKD (orginal) [2022-01-05T10:14:12+01:00] view original

  Thanks. That got rid of that problem but now it produces the error:

  : undeclared identifier: 'gsl_matrix_view_array'
  Run

  If it can find gslSfBesselJ0 in the first example above, I see no reason why it cannot fined gsl_matrix_view_array.

  I have also tried specifying the path explicitly with the same result.

---

• PMunch (orginal) [2022-01-05T11:28:20+01:00] view original

  That is because Futhark only imports the symbols found directly within the specified files. I plan to add a feature where it will import all symbols from files in a folder but until that lands you need to import the files manually. This means you need to figure out which header file actually defines that and import it as well. Note that Futhark also has pretty rudimentary macro support, so if it is a macro it might not work and you'll have to define it yourself.

---

• pietroppeter (orginal) [2022-01-05T12:28:16+01:00] view original

  Note that there is already a wrapper for gsl available: https://github.com/YesDrX/gsl-nim

---

• TKD (orginal) [2022-01-05T13:42:18+01:00] view original

  Thanks @ pietroppeter.

  I was just using gsl to test Futharks' C ffi. Once @PMunch gets it to be 100% fully operational, I believe it would be more sustainable and better for maintenance than just wrapping a library (if one has the choice).

---

• TKD (orginal) [2022-01-05T13:44:45+01:00] view original

  Thanks @PMunch. I'll try this now.

---

• giaco (orginal) [2022-01-08T06:55:49+01:00] view original

  I see you're stepping on the same problem I faced when learning how to use futhark.

  The general rule is that opir (first pass) reads the whole C code just lite clang would do, while futhark (second pass) generates wrappers only for the explicitly listed .h files to avoid excessive clutter.

  TDK, also consider that a proper wrapper is a better solution for the community (AFAIK this is also araq's opinion), but I believe futhark is a great helper for this tast too.

---