온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노
온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노온라인카지노「╱≫ COVO7.CｏM ≫╱「메가888카지노
블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노
블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노블랙썬카지노「╱≫ COVO7.CｏM ≫╱「실시간카지노
코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노
코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노코리아카지노「╱≫ COVO7.CｏM ≫╱「다모아카지노
모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노
모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노모바일카지노「╱≫ COVO7.CｏM ≫╱「우리카지노
생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노
생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노생방송카지노「╱≫ COVO7.CｏM ≫╱「썬시티카지노
태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노
태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노태양성카지노「╱≫ COVO7.CｏM ≫╱「F1카지노
월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노
월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노월드카지노「╱≫ COVO7.CｏM ≫╱「아시안카지노
해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노
해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노해외카지노「╱≫ COVO7.CｏM ≫╱「젠틀맨카지노
Questions about UFCS and generics
proc foo[T](x: float): T = T(x) echo foo[int](1.0) #1 compiles echo 1.0.foo[int]() #2 Error: cannot instantiate: 'T' proc bar[T](x: float, _: typedesc[T]): T = T(x) echo bar(1.0, int) #3 compiles echo 1.0.bar(int) #4 compiles proc baz[T](x: float, _: T): T = T(x) echo baz(1.0, 1)#5 compiles echo 1.0.baz(1) #6 compiles proc qux(x: float, T: typedesc): T = T(x) echo qux(1.0, int) #7 triggers ^ Error here: type expected 1. Why `#2` failed to compile while `#4` and `#6` compiles just fine? 2. Why `#7` triggers the `qux` definition failed to compile? Or, why `T` can be used as return type just fine, but cannot be used as a type in the procedure body? I'm using Nim Compiler 0.14.2.
Re: Error creating a template
**OderWat** Great! Maybe **Araq** will want to include in the next build something like that? :) Personally I would not mind.
Re: writeFile with iterator
Yeah...I thought about \n higher up but didn't want to change the semantics too much. With that change my time goes down to 0.10 seconds (almost a full 3X faster than the original 0.28 --opt:size version on the same machine). About 55..60% of that 0.10 seconds is all just libc fwrite stuff. The remaining Nim probably can't be sped up much more..maybe 10% total runtime at most. file.write is just a very thin wrapper for stdC fwrite. You can see if you look at lib/system/sysio.nim (search for proc.*write.*File).
Re: Error creating a template
Works for me...
# nim c --threads:on -d:release --verbosity:0
{.experimental.}
import times
import threadpool
proc enumerableRepeat[T](value: T, n: int = -1): iterator(): T {.gcsafe.} =
result = iterator(): T {.closure.} =
var i = 0
while n == -1 or i < n:
yield value
i += 1
proc writeFile[T](filePath: string, iter: iterator():T) =
var file = open(filePath, mode=fmWrite)
for str in iter(): file.writeLine(str)
file.close()
const w = ["aa", "bb","cc"]
template parallelFor(
slice: Slice[int],
f:expr
) =
const a = slice.a
const b = slice.b
parallel:
for i in a..b: spawn f(i)
#parallelFor(0..2) do(i: int) {.closure.}: echo w[i]
parallelFor(0..2) do(i: int) {.closure.}: writeFile("dict_" & $i &
".txt",enumerableRepeat(w[i], 3_000_000))
Re: How crazy of an idea is it to turn nim into a sandboxed
Well... Writing for Linux or OS X you could use a real os sandbox and just let them do what they want. I don't know if anything besides a VM is available for windows.
Re: Error creating a template
Thank you very much for your help :)
With the pragma {.closure.} now you can use the external variables in the
template. But when you try to use my previous function (_writeFile_ from this
thread [writeFile with
iterator](http://forum.nim-lang.org///forum.nim-lang.org/t/2403))
parallelFor(0..2) do(i: int) {.closure.}: writeFile("dict_" & $i &
".txt",enumerableRepeat(w[i], 3_000_000))
I get "Error: 'spawn' takes a GC safe call expression". To the compiler did not
swear, I used the option **\--threadAnalysis:off**
But is there any other way? Is it possible to make a template **parallelFor**
(or iterator **enumerableRepeat**?) thread-safe?
Re: How crazy of an idea is it to turn nim into a sandboxed "scripting" language with macros?
I think it is completely possible, the question is just, how easy the approach is. There is nim in interpreted mode, which is run for macros at compile time. The problem is, that this version of nim can not call to C for reason unknown to me at the moment. Might be security, but it is just a raw guess. But for the worst case, you can always compile to javascript, and just run that, because javascript already has a sandbox developed for it.
How crazy of an idea is it to turn nim into a sandboxed "scripting" language with macros?
If I wanted to use nim as a modding language for my game, would it be possible to get full safety by using term rewriting macros to rewrite dangerous operations (eg file system access, network access)? Mods could be distributed as source and the game would ship with the nim compiler. When booting, it would compile the mods into a single dll. When compiling, it would inject term rewriting macros into the source which could be used to capture some operations (eg, force file i/o to only happen in a mod specific folder) or disable some completely (eg interop with C). I only have a passing knowledge of nim, is this a reasonable approach or is there some big flaw in it? If the sandbox were implemented this way, would it be fallible?
Re: Error creating a template
You could not use the global GC value of "w" in a thread. So you have to make
that const first of all.
Then going back to "basic" coding. This works:
# nim c --threads:on -d:release
{.experimental.}
import times
import threadpool
const w = ["aa", "bb","cc"]
template parallelFor(
slice: Slice[int],
f:expr
) =
const a = slice.a
const b = slice.b
parallel:
for i in a..b: spawn f(i)
proc doI(i: int) = echo w[i]
parallelFor(0..2, doI)
as does this (do syntax):
# nim c --threads:on -d:release --verbosity:0
{.experimental.}
import times
import threadpool
const w = ["aa", "bb","cc"]
template parallelFor(
slice: Slice[int],
f:expr
) =
const a = slice.a
const b = slice.b
parallel:
for i in a..b: spawn f(i)
parallelFor(0..2) do(i: int) {.closure.}: echo w[i]
Not sure if that is a compiler bug or limit to the `=>` syntax but I can't find
where to put the pragma.
Re: writeFile with iterator
Modifying where the line ending is added can be even more optimized when you change the parameter to the iterator such that the string is only changed once. E.G.: `enumerableRepeat(str & "\n", 3_000_000)` This would not even be faster if that was done more efficient than introducing a string copy. That using WriteLine() is slower is a pity though. Here we see how simple things can change the outcome a lot. I wildly guess it calls "write()" twice, which is causing more overhead than the string implementation of Nim which copies the string to add the line ending.
Re: writeFile with iterator
**cblake** I did not know that --opt: size so affects the speed. Now I will take this into account. Thank you. Replacing writeLine to write really accelerated the code is almost 1.5 times. PS: Nim really fast. You just have to know how to use :)
Re: writeFile with iterator
Also, in terms of optimization just replacing: for str in iter(): file.writeLine(str) with for str in iter(): file.write(str & "\n") yielded a 1.3X speed-up (I.e., it took the time down to 0.14 seconds).
Error creating a template
{.experimental.}
import times
import threadpool
import future
let w = ["aa", "bb","cc"]
template parallelFor(
slice: Slice[int],
f:expr
) =
const a = slice.a
const b = slice.b
parallel:
for i in a..b: spawn f(i)
It works
parallelFor 0..2, (i:int) => echo i
This does not work: Error: cannot prove: i <= 2 (bounds check)
parallelFor 0..2, (i:int) => echo w[i]
Using pragma {.boundChecks: off.} does not help. How to write the code
correctly?
Re: writeFile with iterator
Garry: --opt:size (and things like gcc -Os) instructs compilers to choose trade-offs to make object code smaller rather than faster. E.g., on Oderwat's code, I get 0.19 seconds with just -d:release (with gcc-6.1 on Linux x86_64, i7-6700k @4.5GHz). If I additionally specify --opt:size the time rises to 0.28 seconds, almost 1.5X slower. The program text segment is 80KB in the fast case but 33KB in the slow case. So, all is behaving as expected/requested.
Re: Windows Subclassing
Thanks for the clarification on casting. It has been a while, but I used nimble to get the oldwinapi package and then I just put import windows at the top of my source. However I am on a Linux box using wine, so I also have to define a nim.cfg in my source folder: i386.windows.gcc.path = "/usr/bin" i386.windows.gcc.exe = "i686-w64-mingw32-gcc" i386.windows.gcc.linkerexe = "i686-w64-mingw32-gcc" which meant I must have installed the mingw32 tool chain (I don't exactly remember - I'm 76 so sometimes suffer from oldsheimers) I also have a Makefile entry like: msnBare.exe: msnBare.nim nim --cpu:i386 --os:windows -o:msnBare.exe -r c msnBare.nim Sorry if that is not much help. I would love to see an extended tutorial on using oldwinapi - I am working mostly blind.
