Re: Cannot load shared library when using -d:release?

2016-08-16 Thread sdwfrost
Dear @mbaulch, Yes, that fixed it. It's not obvious (at least to me) why this would happen, when another, very similar, example doesn't have this problem:

Re: Cannot load shared library when using -d:release?

2016-08-16 Thread mbaulch
This is only a guess, but I wonder if _dead code elimination_ is (for some reason) removing the hooks to your library. Try compiling with nim c -d:release --deadCodeElim:off sir instead. Does that help?

Re: Go-lang like interface

2016-08-16 Thread Krux02
@andrea I will test it a bit more and make sure that id doesn't have obvious bugs. I am also thinking of using concepts to make sure only data can be casted to an interface type that actually is compatible, and get nice error messages in case it doesn't work. Also the type switch or emty

Cannot load shared library when using -d:release?

2016-08-16 Thread sdwfrost
Dear All, I'm a Nim newbie, so forgive any possible naivete...I've put together a package for probability distributions/random numbers, and one of my examples runs with 'nim c sir' but cannot find the shared library when I use 'nim c -d:release sir':

Re: Macro vs template: array base type change at declaration

2016-08-16 Thread coffeepot
I was just considering this situation last night when playing with opengl. OderWat - that's the solution I'm using, but it does get a bit awkward sometimes: import opengl var x: array[4, GLVectorf2] = [ [1.0.GLFloat, 1.0], [1.0.GLFloat, 1.0],

Three of the construction of bridge construction

2016-08-16 Thread zhangxiaosan
Lanzhou Airport expansion project won the airfield runway China State Construction Engineering "Luban" (National Quality Award) and Gansu Construction Engineering "Flying Award"; loyalty and future interchange was named Northwest've mid-2001 Organizing Committee "Northwest landmark" in 2003

Re: Reading large files using Nim

2016-08-16 Thread Krux02
@jlp965 Even the blocks that are not "asked for" use up virtual address space. You can already see that in the api of memfiles. You get a pointer and a size. You don't get blocks that you then can put manually at an address you like. The memory mapped file uses one continuous block of memory in

Re: Reading large files using Nim

2016-08-16 Thread _tulayang
You just need **8192 B** (64 bit CPU) for you large files. Whenever you actually does not need all 16GB data. Try: import os, posix const BufSize = 8192 filename = "/home/king/test.txt" var pos = 0 size = 0 f: File buf:

Re: Go-lang like interface

2016-08-16 Thread Krux02
@Tarmean I now also did what you did, and I am posting my code here. I don't update the original post, because it would require me to either update the entire code there and rewrite things, or break compatibility with the example and the macro code. So I just post it here: import

Re: Reading large files using Nim

2016-08-16 Thread jlp765
@andrea has a [spills module](http://forum.nim-lang.org///andreaferretti.github.io/spills/) that pages a seq to/from disk (IIRC). This may help or give you some ideas. I don't agree with @Krux02 because the memfiles reads in multiple (one or more) block of the file, where each block is

Re: Reading large files using Nim

2016-08-16 Thread Krux02
To tell you the difference. Memfiles does not actually put the entire file in memory, but makes you belive it is. It uses the memory mapping unit that is normally used for ram swapping, but in this context it reads the context of the file as soon as the file is accessed. This needs the size of

Re: Macro vs template: array base type change at declaration

2016-08-16 Thread OderWat
You can write: const data = [0xFD.byte, 0x10, 0x20, 0x30] or const data = [0xFD.uint32, 0x10, 0x20, 0x30] It will inherit size and type automatically.

Macro vs template: array base type change at declaration

2016-08-16 Thread lucian
Initial problem is: # Error: type mismatch: got (Array constructor[0..3, int]) but expected 'array[0..3, byte]' const data: array[4,byte] = [0xFD, 0x10, 0x20, 0x30] Because typing _'u8_ or _'u32_ or similar is no fun for large const arrays, I thought let's use some sort