The struct is not defined in the generated file when you use the `header`
pragma. It only includes the header at the top of the file.
Hello,
I tested your code on a similar configuration (Linux 64-bit i7-2675QM 2.20GHz).
With an input of 500 billions, the system had to make use of the swap and then
crashed.
Moreover for 50 billions, with `--gc:none`:
$ /usr/bin/time ./twinprimes_ssozp5a2a
Enter integer numb
Isn't it
// foo.h
struct foo
{
void (*bar)(int *fuz);
};
or is it a c++ header ?
Anyway, you can try something like this
type
foo {.importc:"foo", header:"foo.h"} = object
bar: proc(fuz: var cint) {.cdecl.}
Hello,
`File` and `Dbconn` point to resources handled by C libraries (`File` is
actually C stdlib's `FILE*` for the C target), and as such should not be messed
up with directly. For files, after closing, the C stdlib will see it doesn't
point to an opened file and will set `errno` etc... (Nim c
@Udiknedormin Here you can use `static` types that passes data to macros
instead of a `NimNode`
import macros
const module {.strdefine.}: string = "math"
macro importconst(name: static[string]): untyped =
#let value = name.symbol.getImpl
#echo "variable
Well, this version seems to work:
import future, typetraits
type
Functor[A] = concept f
type MatchedGenericType[T] = stripGenericParams(f.type)[T]
# `f` will be a value of a type such as `Option[T]`
# `MatchedGenericType` will become the `Opt
This workaround worked for me, but it is still hacky. Assuming the header file
is in the same directory than the nim file:
from os import splitPath
{.passC:"-I" & currentSourcePath().splitPath.head .}
Not tested, but the following could work.
const myHeader =
Hello,
I also got this error on OSX with an older Mac ( MacBookPro Late 2011). I got
this error too on the Linux partition (KDE Neon =~ Ubuntu 16.04) using clang
(oddly, gcc is fine).
The program is compiled with `-mavx2`, but the cpu of my Mac supports up to AVX
instructions. Depending on the
AFAIK the compiler instantiates generics only when they are used. Here the
compiler considered the generated Shape as a generic type with no parameters,
which is legal, but seems unusable.
type Obj[] = object # no error
var x: Obj # Error: invalid type: 'Obj'
Hello,
It looks like you add generic parameters to your generated type even when there
isn't any. I suggest you put an Empty node when you have no generic parameters,
by changing the line 147 of your pastebin by:
var genericParams = if genericParXs.len == 0: newNimNode(nnkEmpty) el
@luked2 I see, this confirms what I suspected in my post above (which appeared
recently due to moderation).
Thanks ! Yes that's what I was looking for, I didn't dig enough in the manual,
as usual.
Hello,
That is pretty cool and I am interested also in that. I have taken a look and I
have some remarks.
If I understood correctly your approach, the marked code is selected at runtime
according to the CPU properties. To be able to run on different architectures,
the general code must be comp
Hello, I played a bit with it (config: i5-2675QM Linux 64-bit gcc 64-bit gcc
5.4.0 nim 0.17.2 julia 0.6.1), and I found also that, with the `-d:release`
flag, that the Nim version is 3-4x slower than the Julia one.
However, with different flags to the C compiler, the results varied
considerably
14 matches
Mail list logo
