Using Concepts for abstracting display graphics

I have wondered about this myself.

Using Concepts for abstracting display graphics

What's the deal with that? Are both concept styles meant to co-exist or will the new one deprecate the old one eventually? Or will they be combined somehow at some point?

Using Concepts for abstracting display graphics

Personally I always have better luck with old style concepts import bitops # Concept describing a display, analogous to "Indexable" in tests/concepts/tspec.nim type AnyDisplay*[T] = concept display display.getPixel(int, int) is T display.setPixel(in

How to echo from a proc correctly?

Thanks all; I liked the .join method for now, but string formatting will also be useful in the future.

Using Concepts for abstracting display graphics

Ah thanks! Missed that one entiely, I removed the color argument and now the `disp: AnyDisplay[T]` argument of `drawQuad` is matched correctly. Unfortunately, it still does not compile, and fails to match the first argument of `setPixel`: /home/sei/projects/nimoled/test.nim(50, 5)

Using Concepts for abstracting display graphics

I think the problem is that the `getPixel` proc has an extra color argument and as such your type doesn't match the concept. The error message should really describe why a concept doesn't match though..

And the fastest language to print hello world is ...

The benchmarks might be quite imperfect, sure, but we've got at least some guiding elements. Plus, in the case of someone who's never heard of Nim before, stumbling upon it while looking at the top of those rankings is good marketing.

Using Concepts for abstracting display graphics

Thank you for your suggestion, but I'm afraid that won't quite work for me: This library will only be useful embedded programming, and the difficulty with these kinds of displays is that you can have a variety of color types, such as monochromatic with on byte describing 8 pixels, or 16 bit colo

ugly code or concepts?

You might want to have a look at various ways to implement reverse-mode autodifferentiation: 1\. Via callbacks, which is what you use: * *

Using Concepts for abstracting display graphics

Are you sure the concept should be at the "Display" level and not at the "Color" level? For color conversions I've implemented a RGB concept here type RGB_Concept* =

Using Concepts for abstracting display graphics

Hi y'all! I've followed nim for some time now, and when I discovered [picostdlib](https://github.com/EmbeddedNim/picostdlib) that gave me a good reason to use it trying out stuff with the pico. I would like to drive different displays with the pico and for that I want to write a small library,

ugly code or concepts?

Although the code works (not the extract below) but I don't realy like it. Then, reading the docs again I noticed `concepts`. Would that be a better choise than the current type? In the complete code the pattern is added to a `tile` that sets the duration of the pattern and the start time on a

And the fastest language to print hello world is ...

I've outlined 8 steps to be unbeatable speedwise on secp256k1 benchmark, a conservative expected speedup would be 2x over Rust implementation (current top) but I wouldn't be surprised by a 3x. Outline:

Which tools do you use to code in Nim?

`nimlsp` definitely doesn't rely on Nimble. Atlas just doesn't build binaries as part of installation (meaning tools like Futhark also can't be installed via Atlas). You can simply clone `nimlsp` yourself and build the binary like any other Nim project.

Which tools do you use to code in Nim?

I've wanted to try nimlsp, but it appears to rely on Nimble and doesn't work with Atlas. :/ Maybe time for a PR. The nimsaem’s plugin doesn't appear to use nimsuggest for error checking but relies on `nim check` which takes a long time for big projects.

And the fastest language to print hello world is ...

If someone wants to be coached into learning low-level cryptography to smoke the secp256k1 benchmark with Constantine (), there's quite a few things that can be done, and you start with a good baseline and comprehensive tests: For 2000 inputs, the fastest