dynlib never works for me when interfacing with external library

It still did notwork. I will have a look at the whole thing again this weekend.

dynlib never works for me when interfacing with external library

I do not think it is either because I create the library myself using :

dynlib never works for me when interfacing with external library

Just a typo. Fixed.

dynlib never works for me when interfacing with external library

Everytime I specify a dynlib in a proc, the library can never be found and is never loaded: Example: proc fooLoad(file_name: cstring, data: ptr ptr UncheckedArray[cdouble], numel: var cint): cint {.importc: "foo_load", dynlib: "libfootest.so".} Run I always get the e

Passing an optional proc is not working

I just tried `testFoo` like so and it works: testFoo("Passing optional proc does not work", f = some[Foofunc](foo)) Run However, should the compiler not be able to infer the _Foofunc_ signature without the user specifying it?

Passing an optional proc is not working

Why does passing this optional proc not work or what am I doing wrong? import options type FooFunc = proc(x: int) proc foo(x: int) = echo "It works OK!!!" proc testFoo(param1: string, f = none(FooFunc)) = echo "param1 = ", param1 if f.isSome:

How to write the Nim version of a C function pointer and pass it as argument to C function

Great! Thanks @PMunch.

How to write the Nim version of a C function pointer and pass it as argument to C function

Can I ask another question relating to double pointers. Given the following C function: int calc_jac(double y[], double** jac) { double r = 6.0e7 * y[0]; jac[1][0] = r; jac[0][0] = -0.04 - 1.0e4 * y[1] - r jac[0][1] = -0.04 - 1.0e4 * y[0]

How to write the Nim version of a C function pointer and pass it as argument to C function

Great. This works! Thank you.

How to write the Nim version of a C function pointer and pass it as argument to C function

Given the following C function from a library I want to link to: typedef void (*fptr_f) (double, double *, double *, void *); void foo(_fptr_f f, double *y, void *_data); Run I have written the following Nim equivalent: type fptr_f = proc(t: cdouble,

Sum types, 2024 variant

Hi Araq I know you must have but would you consider borrowing the design of F#'s discriminated unions. I think it has the most comforting and user-friendly design and Nim syntax should be able to reproduce it with its own particular finish.

How to pass an optional table as an argument to a function?

Thanks @araq, @cblake and @Isofruit, using the optional named table solves the problem as does the 2-procs solution.

How to pass an optional table as an argument to a function?

I need to check to see if the table exists so as to create one based on the passed-in collection if it does not. I could check if it is empty but I want to give the user the option of not having to pass in the argument

How to pass an optional table as an argument to a function?

Why does this `proc` definition not work and how to fix it? proc testTableOptiion*[T]( collection: seq[T], table: Option[Table[T, float]] = none( Table[T, float] )): T = ... Run This results in the error: `no generic parameters allowed for Table` or sometimes `

Automatic Differentiation/Differentiable Programming Library

Thanks @mratsim and @Vindaar for the detailed replies. I will have a look at these and evaluate.

Automatic Differentiation/Differentiable Programming Library

Is there an automatic differentiation library in Nim that is fit for use for both ML and partial differential equations. If not (as I have not found any fully-developed one so far), does anyone know of a C library with a nice interface that I use instead?

Concepts in Nim v2

My misunderstanding! I fixed this now. It should indeed be 'Die' as the sample parameter.

Concepts in Nim v2

Yes, it is defining a distribution as something that can be sampled. In the old form of 'concepts', this would be an infinite recursion as has been explained to me already in some other thread but my understanding is that in this new, unfinished form of 'concepts', `procs` with a `Self` paramete

Concepts in Nim v2

Then, there is no need for the concept if I use 'Die'. See my reply to sls1005.

Concepts in Nim v2

Is 'concepts' is being polished/refurbished as a major feature in v2 - I hope it is. I am assuming the code below is a known problem; compilation is slow and nothing is produced as output. This is on devel 1.9.5. type Distribution = concept proc sample(d: Self): float

Table lookup problem

Thanks. I just updated my devel to the latest version and it works! I was using `1.9.5 git hash: 2054f1c3a9c78ac13593e90845807e9e64f22553` but I am now on `1.95 git hash: 9ddd768cce291e5c562cde23baeeefb47aa79c86`.

Table lookup problem

By fail, I mean it does not produce the correct answer. The output should be 0.99 but the second `getOrDefault` produces 0.0.

Table lookup problem

Can someone help me understand what is going on here. The first `getOrDefault` works but not the second and how can the second be fixed. Everything I have tried fails. type FooTable = Table[string, int] Bar = Table[FooTable, float] let bars = { { "b": 0 }.to

Why does this code using 'concepts' fail?

Many thanks for this @pietroppeter. This clarfies things.

Why does this code using 'concepts' fail?

This fails with `dist.sample_dist() is int too nested for type matching`. Is there a fix? {.experimental.} Run import std/[random] randomize() type Distribution = concept dist dist.sample_dist() is int Die = obj

Built-in (whole) array programming in Nim v2 or even sooner for scientific computing

I believe that being able to do array programming in the same way as Modern Fortran will be a huge boon and benefit. I know this can be done via macros easily or through a library (e.g., Arraymancer) but having it built-in would be excellent for scientific computing. A goal would be to be able

Default values for type(object) fields

Thanks. These are very useful.

Default values for type(object) fields

Thanks for this. I will use this in the interim whilst the RFC is being worked on.

Default values for type(object) fields

Excellent. I will subscribe to the PR. Thanks.

Default values for type(object) fields

I was just coding up an object that theoretically should have about 50 fields with well-defined initial values. Then, I found out that Nim does not support initial values for type (object) fields, e.g., type Foo = object a: float = 11.0 # Error b: float = 0.00

Strange problem when using Futhark

Thanks @PMunch. I'll try this now.

Strange problem when using Futhark

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).

Strange problem when using Futhark

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

Strange problem when using Futhark

4, 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, "