@lscrd, @mratsim, @cblack:
> @mratsim's code may not trigger it, but at least in /devel there seems to be
> a check in semexprs.semOverloadedCallAnalyseEffects that errors out with
> errRecursiveDependencyIteratorX ("recursion is not supported in iterators:
> '$1'"). The error message was even
If you include C code directly in a Nim repo, you may eventually want to use
your new Nim library from other Nim code. In that case, you have to to pass
compiler flags in a special way, since the Nim compiler (unfortunately) does
not do this for you automatically.
[https://forum.nim-lang.org/t/
What bothers me is that my manual evaluation is really subjective and I only
skim over the code, the documentation and the issues. I'm unable to test if the
package compiles with the latest version of Nim. I can't evaluate if it's easy
to use, with a high-level Nim API or only a low-level bindin
c file left as exercise for reader.
{.compile: "only_adds_ints.c".}
proc add_int(a, b: cint): cint
{.importc: "add_int".}
echo add_int(1, 2)
#[
alternatively using emit
{.emit: """
/*INCLUDESECTION*/ // if you want this placed near the top
Hi everyone,
I know that in Nim is possible to call C functions compiled to a shared
library, but I was wondering if it could be possible to compile a C file with a
set of functions directly with the Nim source, without having to compile the C
file to a shared library first. If this is possible
@dom96:
> For the time being, Nim v1 will have a GC. We should improve what we have now
> instead of jumping ship to this brand new runtime which is a massive risk..
I respect your caution about "newruntime", and of course version 1.0 will still
have the current GC options as a fall back.
If t
Thanks for the link. I have quite some code from ClojureScript with data stored
in EDN(like JSON) files. And I 'm thinking about reading/writing EDN(probably
subset of EDN) from Nim. It might be slow compared to other Nim programs but
I'm expecting it to be faster than reading/writing from Cloju
Setting two nodes equal to each other causes changes in one node to be visible
in the other. Idents are also only bound once and visible across all the nodes.
However the equality operator acts like a value type equality operator. This is
good default behaviour but an operator or function that t
@mratsim: Thanks for the reply and your correction of my misunderstandings.
> Also the current threadpool/spawn/^ does not work on the "Hello World!" of
> multithreading which for better or worse is fibonacci...
Ah, I understand. So the order of business is still likely correct: get
threading w
Rewriting React components in Karax is less than optimal given how small the
Nim community is and how quick the Web changes. We need to figure out how to
leverage the large frontend codebases already out there.
what might work is if you have a
seq[tuple[elemType: EnumOfElem, ref: refToData]]
Run
then cast it based on the elemType. But not tested and might have other issues
i'm not aware of right now.
I always say "use json.nim until you're ready for static typing and its design
implications".
The answer to this is to use object variants
[https://nim-lang.org/docs/tut2.html#object-oriented-programming-object-variants](https://nim-lang.org/docs/tut2.html#object-oriented-programming-object-variants)
which is exactly what the JSON module does:
[https://nim-lang.org/docs/json.html#7](http
> we believe that for typical use they will be almost as easy to use as GC'ed
> references but without GC's downfalls in taking a huge development effort to
> reduce memory access wait time latency while supporting multi-threading/Some/
> believe that. Others like myself need to see this in prac
Yes, I forgot to mention JSON, but it was mentioned in the thread I pointed you
to,
[https://forum.nim-lang.org/t/4233](https://forum.nim-lang.org/t/4233)
I have no experience with JSON, my feeling is that you will loose most of the
advantages of a compiled statically typed language, which is m
Previous work was done in dynamic languages and I want to try Nim with it.
[http://repo.cirru.org/cirru-parser](http://repo.cirru.org/cirru-parser)/
But I don't think it's impossible. Maybe I asked in a wrong way, I think it's
solvable since there's already an example. How to you parse JSON, whi
Nimble could run better checks when releasing a package
[https://github.com/nim-lang/nimble/issues/632](https://github.com/nim-lang/nimble/issues/632)
Great! Thanks for this info)
The Nimble package directory can help with this, see:
[https://nimble.directory/about.html](https://nimble.directory/about.html) If
someone wants to contribute you can contact me on IRC
Replying mostly to your first reply @GordonBGood
> threadpool/spawn/FlowVar is a beautiful modern concept for multi-threading
Agreed
> So in a few hours I took my wrapper implementations and re-wrote my required
> parts of threadpool to not consider GC'ed data structures in about 150 lines
> (
Hidden Brains is an enterprise web & mobile app development company in USA &
India. We are providing end to end IT services with focus on software product
development, customized enterprise business solutions and offshore development
center. Contact Us Now!
[https://www.hiddenbrains.com](https:
@nickjonson:
> I’ve found (Nim's) supposed to be faster than Julia...
Referring to your opening post, Nim is at least as fast as Julia but not that
much faster for well written Julia code other than Julia's wait to pre-compile
it's code when it's called the first time. The problem with writing
22 matches
Mail list logo
