Windows Defender detected Trojan.AndroidOS/Multiverze in Nim-1.6.10_64.zip

I downloaded and installed nim-1.9.1-windows_x64.zip and Windows Defender had no problems with that.

Create a ref to a C allocated object to manage its memory

> Memory allocated by C needs to be freed by the C allocator. Memory allocated > by the Nim alligator must be freed by the Nim alligator. Yes I for one eagerly await my new Nim alligator overloards!! ;) (sorry I couldn't resist). Also, I think @ElegantBeef wrote a RemoteRefs (demo) for using cu

Windows Defender detected Trojan.AndroidOS/Multiverze in Nim-1.6.10_64.zip

I'll suggest to compute the checksum, though. The infection chance being very few doesn't means that it's impossible to be infected, just less possible than a false positive. However if every positive result is viewed as false positive, we'll really be infected.

Ttop - System monitoring service tool with tui and historical data

# ttop System monitoring service tool with tui and historical data  * [x] Saving historical snapshots via systemd.timer * [x] Scroll via historical

Mr. Rumpf, why didn't you went along with the Python standard library?

> well: It is not too bad, but in my personal opinion there is much room for improvements. I think I was really satisfied with the Ruby API docs 15 years ago.

Mr. Rumpf, why didn't you went along with the Python standard library?

In my opinion, Nim's standard library is documented well:

Nim version 2.0 RC1

That's a big milestone, congratulation to all the core team members and contributors.

Brogrammer uptick

am from Ethiopia Africa

Use multithreading without channel and threadpool

Yes the code will be threadsafe, though there is a caveat. If you create a variable that points to a reference type you will likely want to do `let myVar {.cursor.} = myRef` this creates a 'weak' reference to the reference that does not cause any GC on this thread. As this thread likely does not

Use multithreading without channel and threadpool

I noticed that I cant't use ref variable in thread even with orc (it said that with orc we have shared memory) For example var workers: array[10, Thread[void]] var name = "Hey" proc printer() {.gcsafe.} = echo name for i in 0..high(workers):

Mr. Rumpf, why didn't you went along with the Python standard library?

What is so good about the Python version is its documentation. IMHO that is lacking in Nim. Unless you can give me some good documentation.

Mr. Rumpf, why didn't you went along with the Python standard library?

https://nim-lang.org/docs/xmltree.html

Mr. Rumpf, why didn't you went along with the Python standard library?

@linwaytin I didn't see anything like xml.etree and I really like the documentation in Python Is there something like that in Nim?

Nim version 2.0 RC1

It seems to be a choosenim issue, It happened for 1.6.x releases too, please open an issue on the issue tracker of choosenim.

Nim version 2.0 RC1

I don't know whether switching to csources_v2 solves the problem, I have submitted a patch to choosenim =>

Tutorial for nim pixie graphics?

@pietroppeter, thanks for the information! this is truely awesome!

ormin example chat - websocket failed

Hello, Im run ormin examples. ./examples/chat/server [Warning] WS negotiation failed: the only supported sec-websocket-version is 13 [Warning] WS negotiation failed: the only supported sec-websocket-version is 13 Run http GET http://localhost:808

Atlas -- the package cloner

Well atlas is a tiny tool, we can add support for an alternative to the existing `.nimble` file that is required to exist when you use e.g. `atlas --pin` (reproducible build). But if we depart from the .nimble file we might as well do it right and come up with some solution that allows for cross

Atlas -- the package cloner

indeed - with the hashes in place, atlas instantly becomes a very attractive tool - minimal versioning, no script execution, lots of things to like. it's critical though that the hashes that the tool chooses get committed to the repo so that when I clone your repo, I don't have to re-run the ve

Atlas -- the package cloner

> blockchain hashes exist as a way to solve this class of problems since well before blockchains, if that's what you're referring to - starting with git itself. > The author doesn't have permission to modify tags. the owners of the org still do, as does anyone that hacked the login of any of t

Atlas -- the package cloner

In the `requires` part of the nimble file you can use full URLs as well as specific git commit hashes.

Atlas -- the package cloner

How would that work with repositories that aren't on GitHub?

Nim version 2.0 RC1

Yey! Nice progress! Thanks to Araq and other contributors!

Atlas -- the package cloner

Maybe the solution is simpler than you think. For example the proposed blockchain solution seems like an overkill. How about every package that's available through nimble is forked under an org? The author doesn't have permission to modify tags. That would solve the issue with deleted repos.

Atlas -- the package cloner

> git tag on the main project the most critical problem is that git tags are mutable - this is a common way to introduce supply chain attacks (which happen regularly) - this is why a lock files contain a hash of the source code (just like git operates on hashes, not "names" of things - a versio

Atlas -- the package cloner

Thanks for the clarification. So instead of git tags git commit hashes should be used. Atlas internally already uses these. I got it right accidentically. :-)

Nim version 2.0 RC1

The link "" is plain text, not a link.

Nim version 2.0 RC1

With a big release you'll always get a bump in new people curious about whats going on. Hopefully its a good point to get more people interested in Nim.

Atlas -- the package cloner

I have been using atlas for a while, it has been the reason I can still compile my older projects although, i have been careless with semver :) in my libraries so thank you for that. My workflow is to create a new repository, either from scratch or treeform's nimtemplate, add your dependencies t

Atlas -- the package cloner

> which is to reliably produce the same build even if the source changes Please elaborate, in my mind that is dealt with by a git tag on the main project. I mean, you only need to pin the commit of the main project in your build server in order to get a reproducible build.

Atlas -- the package cloner

> Thanks to this design, lock files are not required. FWIW, lock files solve a slightly different problem, which is to reliably produce the same build even if the source changes - `minimal version` is really really nice as a strategy (ie ideally nimble would use that too), but it does not preve

Atlas -- the package cloner

Atlas is the 40-80% solution for package management. It is not designed to replace Nimble, but I find it a handy useful tool and hopefully you will too.