Re: why var can not be declared this way?
According to Nim manual: [https://nim-lang.org/docs/manual.html#statements-and-expressions-if-statement](https://nim-lang.org/docs/manual.html#statements-and-expressions-if-statement) _In if statements new scopes begin immediately after the if /elif/else keywords and ends after the corresponding then block._ For example: if true: let foo = 1 # Error: undeclared identifier: 'foo' echo foo Run You can write shorter code by using if expression and tuple unpacking [https://nim-lang.org/docs/manual.html#statements-and-expressions-if-expression](https://nim-lang.org/docs/manual.html#statements-and-expressions-if-expression) [https://nim-lang.org/docs/manual.html#statements-and-expressions-tuple-unpacking](https://nim-lang.org/docs/manual.html#statements-and-expressions-tuple-unpacking) proc f(size=1) = let (widFrame, hiFrame) = if size == 1: (320, 200) else: (3200, 2000) echo (widFrame, hiFrame) f(1) f(2) Run
Re: why var can not be declared this way?
read-only -> using let proc f(size=1) = let (widFrame, hiFrame) = if size == 1: (320, 200) else: (3200, 2000) echo (widFrame, hiFrame) f() Run
Re: why var can not be declared this way?
`var` is Not read-only.
why var can not be declared this way?
for proc f(size=1) = if size == 1: var widFrame = 320 hiFrame = 200 else: var widFrame = 3200 hiFrame = 2000 echo (widFrame, hiFrame) f() Run I get t_bug.nim(11, 11) Error: undeclared identifier: 'widFrame' Run Why? I know there is a solution proc f(size=1) = var widFrame:int = 0 hiFrame:int = 0 if size == 1: (widFrame, hiFrame) = (320, 200) else: (widFrame, hiFrame) = (3200, 2000) echo (widFrame, hiFrame) f() Run but in fact widFrame and hiFrame should be read-only if the parameter size is given, what I expect is proc f(size=1) = if size == 1: var widFrame = 320 hiFrame = 200 else: var widFrame = 3200 hiFrame = 2000 echo (widFrame, hiFrame) f() Run which of cause failed with message t_bug.nim(11, 11) Error: undeclared identifier: 'widFrame'. What is the solution for this case? Thanks
Re: async in a thread; crashes
Thank you @mikra for takeing time to look at it! works!
Re: async in a thread; crashes
Hi, try this (works for me) and I put some comments in it:
import locks
import os
import asyncdispatch
import asynchttpserver, asyncdispatch
var L: Lock
type Context = ref object {.pure.}
num: int
str: string
proc th(ctxP: pointer) {.thread.} =
var server = newAsyncHttpServer()
proc cb(req: Request) {.async.} =
var idx: int = 0
if not tryAcquire(L): return
var ctx = cast[ptr Context](ctxP) # never cast ptr to ref
# within different thread
# GC_ref ctx # not needed because ctx is not owned by this thread
ctx[].num.inc()
idx = ctx[].num
sleep(200) # sleep while locking to get the: "could not acquire lock"
msg
# GC_unref ctx #
release(L)
await req.respond(Http200, "Hello World " & $idx)
proc aprint(): Future[void] {.async.} =
while true:
echo "hello"
await sleepAsync 1000
asyncCheck aprint()
asyncCheck server.serve(Port(8080), cb)
runForever()
initLock(L)
let ctx = Context(num: 0, str: "")
var ctxP = ctx.unsafeAddr
# GC_ref ctx # parentthread is owner of ctx (I think its not needed because
of the
# endless loop)
var networkThread: Thread[pointer]
networkThread.createThread(th, ctxP)
while true:
if not tryAcquire(L):
echo "could not aquire lock"
sleep(50)
continue
ctx.num.inc
echo(ctx.num)
release(L)
sleep(2500)
Run
GC V2 features
I was reading about the 6 GC that Nim has to choose, I cant find any documentation and `V2` is not a concrete algorithm, can someone explain please ?. TLDR description: * `markAndSweep`: Fastest, uses more RAM. * `Boehm`: Slowest, uses less RAM. * `Go`: Go lang like implementation. * `Regions`: Kinda slow-ish, works by regions of memory. * `RefC`: Reference counting, default. * `none`: No GC. * `V2`: **? ? ?** Thanks.
async in a thread; crashes
i'm fighting with an async in a thread example, does one have a tip where my
big mistake is? It works for a few http request then crashes, it crashes faster
in release, but not crashes withouth gc (or not discovered yet...)
import locks
import os
import asyncdispatch
import asynchttpserver, asyncdispatch
var L: Lock
type Context = ref object {.pure.}
num: int
str: string
proc th(ctxP: pointer) {.thread.} =
var server = newAsyncHttpServer()
proc cb(req: Request) {.async.} =
var idx: int = 0
if not tryAcquire(L): return
var ctx = cast[ref Context](ctxP)
GC_ref ctx #
ctx[].num.inc()
idx = ctx[].num
GC_unref ctx #
release(L)
await req.respond(Http200, "Hello World " & $idx)
proc aprint(): Future[void] {.async.} =
while true:
echo "hello"
await sleepAsync 5000
asyncCheck aprint()
asyncCheck server.serve(Port(8080), cb)
runForever()
initLock(L)
var ctx = Context(num: 0, str: "")
var ctxP = ctx.addr
GC_ref ctx #
var networkThread: Thread[pointer]
networkThread.createThread(th, ctxP)
while true:
if not tryAcquire(L):
echo "could not aquire lock"
sleep(50)
continue
ctx.num.inc
echo(ctx.num)
release(L)
sleep(2500)
Run
it crashes with:
10004
10263
hello
Traceback (most recent call last)
threadAsync.nim(30) th
asyncdispatch.nim(1651) runForever
asyncdispatch.nim(1516) poll
asyncdispatch.nim(1282) runOnce
asyncdispatch.nim(191) processPendingCallbacks
asyncmacro.nim(36) serve_continue
asynchttpserver.nim(309) serveIter
asyncmacro.nim(307) processClient
asyncmacro.nim(36) processClient_continue
asynchttpserver.nim(281) processClientIter
asyncfutures.nim(77) newFutureVar
asyncfutures.nim(59) newFuture
strmantle.nim(63)nimIntToStr
gc.nim(475) newObj
SIGSEGV: Illegal storage access. (Attempt to read from nil?)
Error: execution of an external program failed:
'/home/david/nimPlayground/threadAsync '
Run
I've stressed it with:
true; do curl 127.0.0.1:8080; done
Run
Re: R-style logical vector operations in Nim?
Thanks for the clarification. Regarding the ifelse task with 1000 elements: does anyone know how big the relative performance gain of array vs. sequence would be? Otherwise, I will benchmark this, but unfortunately this will take some time...
Re: Hitting a SIGSEGV in the garbage collector
Are you using raw pointers or multithreading somewhere? Are you calling a C library perhaps?
Re: Hitting a SIGSEGV in the garbage collector
Well, it's probably something I'm doing. It fails on both Ubuntu Linux 16.04 and Windows 10 (both amd-64). I'll do some more digging before expecting anyone else to spend time looking at it. Are there any settings one can use to e.g. find "shouldn't happen" memory overwrite problems, short of running with Valgrind or similar? Failure occurred with various of the GCs, so I have to take another look at my code.
Re: Hitting a SIGSEGV in the garbage collector
* We need a real test case, reduced or not. * We also need to know your CPU/OS combination. * We need to know which of the `--gc:boehm|refc|markAndSweep` GCs produce the problem. > Any ideas on how best to debug this type of situation? Try Nim's different GC options. > Are there known issues with GC on 0.19.0 which have been fixed since it was > released? The GCs have no known issues that would produce the behaviour you're describing.
Hitting a SIGSEGV in the garbage collector
I'm trying to port a library and hitting a problem in the GC. I'm not sure I can reduce it to a small program which exhibits the problem. The key bits are: $ nim --version Nim Compiler Version 0.19.0 [Linux: amd64] Compiled at 2018-09-26 Copyright (c) 2006-2018 by Andreas Rumpf git hash: f6c5c636bb1a1f4e1301ae0ba5a8afecef439132 active boot switches: -d:release $ nimble test ... Traceback (most recent call last) test1.nim(31)test1 config.nim(448) failingProc gc.nim(493) newObjRC1 gc.nim(185) decRef SIGSEGV: Illegal storage access. (Attempt to read from nil?) Run The lines in config.nim in `failingProc` where it happens are 447var s = $text 448result.text = s Run and these lines have been executed many times through successive calls to `failingProc` from the test. The `text` variable is initialised at the top of `failingProc` using var text : seq[Rune] = @[] Run and the intervening lines just add some runes to it before the failing line. If I add various `echo` lines, the location of the failure above the GC call moves around (e.g. to `system.nim(216)`). There's nothing special about N where it fails on the N th call to `failingProc` \- with extra `echo` lines, it fails at a different time during processing with those lines in gc.nim. Any ideas on how best to debug this type of situation? Are there known issues with GC on 0.19.0 which have been fixed since it was released?
Re: R-style logical vector operations in Nim?
R (and C++) vectors equivalent in Nim are sequences. Tuples are fine if you work with a limited fixed size of elements but otherwise use sequences or dedicated data structure (either [Neo's vectors](https://github.com/unicredit/neo) or [Arraymancer's tensors](https://github.com/unicredit/neo)).
Re: Got "Warning: < is deprecated [Deprecated]"
and maybe a form so that people can submit such errors unless the github book repo is already used as such.
Re: Got "Warning: < is deprecated [Deprecated]"
@dom96 I think you should have an errata web page for rhe Nim in Action to cover such cases.
Re: Got "Warning: < is deprecated [Deprecated]"
use `..<` without space between `..` and `<`
Re: Nim T-shirts and mugs now available
I wish that tee spring wasn't so awful about shipping fees, but I picked up both.
Re: should `computedGoto` be always implied ? (ie make computedGoto noop)
You are probably right, I've been away from this level of implementation for the last decade, but I was under the impression that if the branch target is fully known enough cycles in advance (as could be in this case if the jump table is in L1, if loading of ebp was pushed further back, and which IIRC LuaJIT2 does do) there is, in fact, no prediction involved. I'm likely wrong, though, and extrapolated the state of the art farther than where it actually is.
Re: R-style logical vector operations in Nim?
Please see also this post from [stackoverflow](https://stackoverflow.com/questions/53084192/r-style-logical-vector-operation-in-nim#new-answer) \- suggesting tuple-skills for operands.
