Nim 2.0 -- thoughts

@arnetheduck: > > enabled by a flag such as our --threads:on > > Global flags like these create dialects and don't work for composing > libraries in general which stifles development - this is by and large a > broken model that even C is trying to move away from (who remembers the mess > of li

How to best return immutable variable without copying it?

You can use the `lent` keyword for getting a immutable reference, and you can override the `=copy` hook to see whether you're copying. Nim is intelligent enough with the lent annotation to copy if you call it to a `var` and then mutate it. So an example of this is as follows: impo

How to best return immutable variable without copying it?

I was wondering, if there is an easy way to return something immutable from a function without copying it. To demonstrate my issue, I wrote this code snippet: import random type Big = object c: array[1, int] # needs mutable seq[Big] func get0(s: va

Memory leak with ARC and malloc when using references and casts

the expandarc looks the same when compiler with or without `-d:useMalloc`, and as the version without the malloc doesn't leak, I assumed that there can't be a missing destroyer. To be honest, I don't quite understand the output: --expandArc: test var r :tmpD

Can I jump to the definition of a proc or macros of a package when using IDE?

Yep, though you're likely to find that nimsuggest chokes on large projects, so a lot of people end up turning it off in their editors eventually, once the pain outweighs the gain. :( Hopefully this will be fixed this year (if I understand correctly, nimsuggest improvements are on the roadmap, b

Memory leak with ARC and malloc when using references and casts

My point is to inspect the output of expandarc and try to find if a destructor call is missing.

Memory leak with ARC and malloc when using references and casts

> as the issue happens only with --gc:arc -d:useMalloc The point is that valgrind can see the leak only with --gc:arc -d:useMalloc. See my book:

Memory leak with ARC and malloc when using references and casts

`--expandarc:test`doesn't help here, I believe, as the issue happens only with `--gc:arc -d:useMalloc` but not with only `--gc:arc`.

Nim enters top 50 programming languages list on TIOBE Index!

Tangenitally. I can speak to yes. We are using it inour red teaming (which is emulating adversary's to secure networks). So I'm sure malware writers are too. Since InfoSec is big on python and nobody wants to learn C ( I'd not blame em. I'm trying to get a handle on it myself with Win32 programm

Memory leak with ARC and malloc when using references and casts

Best way to identify the leak is --expandarc:test. Then open a new issue on GitHub.

Can I jump to the definition of a proc or macros of a package when using IDE?

Yeah, playing with nim. Looks like the `nimsuggest` totally knows what a proc or a macros means, and their source code is normally in the .nimble folder. So can I jump to the definition in the IDE(I think you guys use neovim), like what jedi does for python, like what ctags does for c++?

Can I jump to the definition of a proc or macros of a package when using IDE?

Solved, by with `gd` and `gD`

Memory leak with ARC and malloc when using references and casts

I fixed the issues with the first example. This still has the same leak issue: type ComponentC = ref object c: int func newComponentC(): ComponentC = result = new ComponentC result[].c = 150 proc test() = var r: ref seq[int8]

Nim 2.0 -- thoughts

> enabled by a flag such as our --threads:on Global flags like these create dialects and don't work for composing libraries in general which stifles development - this is by and large a broken model that even C is trying to move away from (who remembers the mess of linking single-vs-multithread

Memory leak with ARC and malloc when using references and casts

I tried again with the latest nightly, and it still behaves the same.

Memory leak with ARC and malloc when using references and casts

I don't know about the leak, but shouldn't this code not work? `ref ComponentC` becomes `ref ref int`, no? I assume this is what you meant to write: type ComponentC = ref object c: int func newComponentC(): ComponentC = result = new ComponentC result[

Nim is just so great, works first try

Hello, I just wanted to thank all those involved in the Nim language itself. I just finished coding a replication feature on a small web service that manages accounts, and it worked first try. I got a load of compile errors, but after solving them all, I just tested it, and no exception, no bug

Memory leak with ARC and malloc when using references and casts

Fixed in devel right?

Nim enters top 50 programming languages list on TIOBE Index!

That is amazing! You may argue that TIOBE index does not actually reflect the real popularity of a language, but TIOBE index is among the famous one. Undeniably, this is a successful marketing campaign (by accident maybe). If Nim can keep it on the list, the real popularity will grow organically