It seems GC_ref doesn't help. If you use ORC, it'll still fail.
$ nim c --gc:orc --app:lib --outdir:. ext.nim
Hint: used config file
'/Users/gcao/.choosenim/toolchains/nim-1.6.0/config/nim.cfg' [Conf]
Hint: used config file
Oh one fun bit: I was able to get about `0.70 ms` total round trip RPC calls
using an [STM Nucleo H745ZI
board](https://www.mouser.com/ProductDetail/STMicroelectronics/NUCLEO-H745ZI-Q?qs=%2B6g0mu59x7JZtCCSR0CW2g%3D%3D)!
Note that it's on a local switch and the raw ping time averages about `0.3
First of all, at least on Linux the system doesn't search for the shared
library in the current directory, so I had to patch the code to test it. Second
of all, you need `GC_ref` in `test` so that, when destroying from the main app,
the reference counts becomes 0 and the ref actually gets
Greetings, I've been working on [Nephyr](https://github.com/EmbeddedNim/nephyr)
a wrapper around the Zephyr RTOS! Zephyr is a fantastic truly open source
initiative that has backing from multiple hardware vendors including many of
the biggest ones like Nordic, TI, NXP, and Intel among others.
`nim_gdb` for windows is `nim_gdb.bat` I think. Also, what @quantimnot says
It is probably caused by ORC. I have this in config.nims
switch("d", "release")
switch("d", "ssl")
switch("gc", "orc")
switch("outdir", "bin")
Run
The main issue here is that you're passing a GC'd reference from one instance
of the Nim GC to another, which is not really allowed as `refc` is a
thread-local GC.
Nim 1.6 throws same error.
Hi,
With below code I'm getting a strange error with no stack trace. Any
suggestions?
app.nim
import dynlib
type
Value* = ref object
P* = proc(): Value {.nimcall.}
when isMainModule:
var lib = loadLib("libext.dylib")
var test: P =
> I've been thinking of porting NuttX and littleVGL to Nim; but Zephyr is also
> on my radar.
littleVGL would be really useful! I've not used NuttX but let me know if you'd
like to include it in EmbeddedNim.
> Somebody any idea? If it's not the compiler flags then maybe it could be
> xtensa gcc using glibc instead of newlib (I didn't specify this), but that's
> just a wild (and probably wrong) guess...
That'd seem a good guess. Mixing C libraries doesn't usually go too well.
Though there may be
I've been thinking of porting NuttX and littleVGL to Nim; but Zephyr is also on
my radar.
https://play.nim-lang.org/#ix=3Ebk
There's
[parseHexStr](https://nim-lang.org/docs/strutils.html#parseHexStr%2Cstring)
which maybe helpful
I don't think it's productive to discuss this: there is no chance Nim will
change such a fundamental part of it's syntax. I'm locking this thread.
Coming from python ... and new (happy) nim'er ;-)
I've choose nim, over rust, just because I prefer the nim syntax (a lot!) (and
nim interfaces very well with python !!!)
Indent war, was a lot present 20years ago in python discussions ... But now,
still python is number1 (tiobe): the debat is
True. If you don't want semicolons, you can do this instead:
(if true:
echo "You can do this if you want"
(block:
echo "but everyone will hate you"
)
)
Run
To make this compile, it should be
if true: (
echo "You can do this if you want"; # note here
block: (
echo "but everyone will hate you"
)
)
Run
Plus, the semicolon will give some extra hate :o)
`if true: ( echo "You can do this if you want" block: ( echo "but everyone will
hate you" ) ) `
Run
Thanks !
#! nim c -d:danger -r
import nimSHA2
import nimcrypto
import times
import libsha / sha256
let x=10_000_000
var t=getTime()
for i in 0 .. x:
let h=sha256hexdigest($i) # libsha
echo "LIBSHA: ",getTime() - t
Tools that throw away whitespace are broken tools. Broken tools should not
guide syntax design.
what exactly is your point? you just rebutted both of your options
22 matches
Mail list logo
