{.compileTime.} will not do the work. In generated C code, value is copied into
a just before a is used.
Remember to use "search" on
[https://nim-lang.org/docs/lib.html](https://nim-lang.org/docs/lib.html).
Aside from your question, I think the algorithm module is a little bit wierd:
only a few functions, and reverse is in it. In my humble opinion, reverse does
not look like an algorithm. ^_^
I am following your RFC.
In my opinion, let variables are already "readonly" once they got assigned.
{.readonly.} pragma seems a little bit redundant. The problem here is that,
from the perspective of nim compiler, when to initialize let variables? While
some can be initialized in compile time
Yes, this is exactly what I am looking for. Next time I should do some research
before initiating a thread, ^_^.
Why? This is bad, in my opinion.
Hi all,
I am investigating the possibility of async on embedded systems running a
realtime OS.
Since the realtime OS (such as FreeRTOS) supports task/semaphore, etc, it is
possible to have async just like Windows/Linux.
But how?
1\. asyncfutures depends on os. It is (nearly) _impossible_ to
Hi all,
I have submitted issue [#12625](https://github.com/nim-lang/Nim/issues/12625)
on GitHub on generating func-s (closures) with mapIt, where the code crashes
nimvm or behaviors wrongly in runtime.
Further checking indicates that the root cause is that, {.inject.} variables
(it in this
Oh, this remind me of Maybe in Haskell. Excellent.
Multiple dispatch. Maybe you can create a hash signature for each combination
of arguments. Then req becomes a hash set or a dict depending on your design.
Then, I need to import this C var into nim? This does not look like a good idea.
> Workaround: use `system.closureScope` instead.
Unfortunately, this workaround does not work for this case. In the `proc`
generated by `closureScope`, `asgnRef` is used to capture `it`, which is a
failure. While in the example of `closureScope`, local loop variable is just an
integer, and it
They seem to be unstable and untrustworthy.
Hi all,
Env-s are allocated on heap by `newObj`. Is it possible to put them on stack?
There are some cons, such as closure can't live out of a function's scope. But,
in the case of truly embedded systems with only several KiB RAM with
`-gc:regions`, env-s on stack is good enough, ^_^
There are truly readonly data in the physical world, such as ROM. If a value of
type `T` is stored in ROM, what's the type of ``? It's `const T *`. How to
model this in Nim?
If we need to define a callback function (type of a param is `const T *`) in
Nim, using ABI would not help.
P.S. It's
Take `nimCopyMem` as an example, do you mean to change its prototype to this
(below) ?
static N_INLINE(void, nimCopyMem)(void* const dest, void* const source, NI
size)
Run
I do care about `coust T *`, but not `T * const`. To me, below is far more
better than the
* [const is a
contract](https://quuxplusone.github.io/blog/2019/01/03/const-is-a-contract/).
I like to see that Nim could generate something similar to `f(O *a, const O
*b)` for below f:
type
O {.byref.} = object ...
proc f*(a: var O; b: O): int = ...
OK. To heal this (and other possible) bad design(s) of C/C++, let's use `-w`,
and to heal some C++ compilers, let's `define NIM_CONST`.
If `gc:none`, linking will fail with undefined `newObj`.
Is it a good idea to put `env` on stack for `gc:none`?
I am using Nim on embedded system, so RAM is quite precious.
If we do following in C:
const int a[] = {1,2,3};
Run
a will be stored in ROM, and no RAM is consumed.
While in Nim, if we declare it in a let statement:
let a = [1,2,3]
Run
a
]
Run
I tried to
[solve](https://github.com/foldl/Nim/commit/93c814f2efd76c3e1d36e1ed6773423599584d60)
this by making a copy of env in genClosure.
But this modification may not work for other cases, and all checks of my [pull
request](https://github.com/nim-lang/Nim/pull/12689) fails.
All
Performance seems a nice reason, but not JS interop. Most if not all hate this
JS _[feature](https://forum.nim-lang.org/postActivity.xml#feature).
It is possible for the compiler to eliminate redundant copy operations. So,
performance may not be a problem either.
To add it into `system.nim` is not a good idea, `macros.nim` looks like a
better place.
Here is the PR:
[https://github.com/nim-lang/Nim/pull/12712](https://github.com/nim-lang/Nim/pull/12712).
As `system.closureScope` does not work for this case, I would like to propose
another macro,
macro capture(locals: openArray[typed], body: untyped): untyped =
var params = @[newEmptyNode()]
for arg in locals:
params.add(newIdentDefs(ident(arg.strVal),
Hi all,
We are a startup in China, making Bluetooth Low Energy chips. We are happy to
adopt Nim in parallel with C/C++ in our SDK([1]).
There are many benefits to use Nim instead of C.
* _Meta-programming_
> With metaprogramming, we can create advertising and GATT profile at compile
>
Interesting. Why do you hate Python?
I like:
* Erlang for its philosophy
* Mathematica for astonishing me
* C# for its creator
* Nim for its clarity and power
* Pascal for bringing me to this wonderful journey, too
I hate:
* Java for over-designed design patterns
* Rust for
Yes, so many `{.pragma.}` , too many combinations to be handled properly.
I won't write `const` everywhere. If I see a parameter `a_type_t *p` in a
function is decorated with `const`, I am happy because its side effects seem to
be _under control_.
> We can simply make all parameters `const` since that's Nim semantics anyway.
I can't understand this. The first
Hi all,
There are already lots of discussions on this. I find that we need to discuss
it further in a generalized manner: interfacing with C without a `const`
equivalent qualifier.
* **Case 1: Global constant values**
const int value[] = {1,2,3};
Run
This has
> Arrogance definitely leads to ignorance.
> \-- N/A
[How to Print Floating-Point Numbers
Accurately](http://kurtstephens.com/files/p372-steele.pdf) by Guy L. Steele Jr.
and Jon L White.
As a bonus, this paper also gives hints on how to read floating point numbers
accurately.
To make it clear, warnings are valuable. So long.
* * *
* * *
Version: 1.0.2 [Maybe]
* **484 warnings on [unused-but-set-variable]**
Hope that GCC can optimize out these redundant set operations.
* **175 warnings on [discarded-qualifiers]**
Most of these warnings are due to `const`.
Just in case that someone is curious:
* Examples using Nim:
[https://github.com/ingchips/ING918XX_SDK_SOURCE/tree/master/examples-nim](https://github.com/ingchips/ING918XX_SDK_SOURCE/tree/master/examples-nim)
* A little meta-programming for Bluetooth:
One can only help you out after you think that you need to be helped out.
Regarding these warnings, it is more import to have a proper altitude towards
them than to fix them. I am already helping on this.
> "clean" C is meaningless, the C compilers do not agree on a set of warnings
> and warnings are not errors.
Interesting. All those stupid C compilers **should** treat `-w` as default, an
explicit `+w` is needed to enable warnings, but not the opposite.
Hi all,
A summary of my complains.
* Bugs in processing chain of templates
[#12928](https://github.com/nim-lang/Nim/issues/12928),
[#12639](https://github.com/nim-lang/Nim/issues/12639).
* Lack of closure on stack
So, sadly, I can't do much functional programming on embedded system.
Error:
> system module needs: appendString.
Here it is:
[https://github.com/ingchips/ING918XX_SDK_SOURCE/blob/master/examples-nim/smart_home_hub/src/panicoverride.nim](https://github.com/ingchips/ING918XX_SDK_SOURCE/blob/master/examples-nim/smart_home_hub/src/panicoverride.nim)
I can't test it at present. Even through, why 1.0.x is OK?
No, it does not work for me with your `panicoverride.nim`.
nim -v
Nim Compiler Version 1.2.0 [Windows: amd64]
Compiled at 2020-04-03
Copyright (c) 2006-2020 by Andreas Rumpf
git hash: 7e83adff84be5d0c401a213eccb61e321a3fb1ff
active boot switches: -d:release
> Each time there a pain in Nim, always look for a cure in C.
I have to get rid of "==" and call `memcmp` for a cure.
A simple array comparsion will cause error: system module needs: appendString.
Test code:
var
arr1: array[6, uint8] = [0xC2u8, 0x12, 0x35, 0x98, 0x67, 0x00]
arr2: array[6, uint8] = [0xC3u8, 0x12, 0x35, 0x98, 0x67, 0x00]
proc printf(fmt: cstring) {. varargs,
With following options, the generated binary is reduced significantly. I am
**happy** with `--gc:arc -d:useMalloc`. Its footprint is so small.
define = "danger"
checks="off"
assertions="off"
stackTrace="off"
lineTrace="off"
Run
Oh, with `--panics:on`, for a _really_ complex bluetooth app, binary size
reduced from 5.6kB to 5.2kB, about 10% of flash is saved!
I can't find this information in the documents.
I am using the option given in compiler user guide: `--os:any --gc:arc
-d:useMalloc`. Several kB RAM is reserved for heap.
What are the differences between `--os:any` and `--os:standalone`? I can't find
this information in the documents. For a simple project, the generated binary
is about
43 matches
Mail list logo
