Enhancing Nim vtable implementation vs subtype checking

in devel already.

Enhancing Nim vtable implementation vs subtype checking

What are your thoughts on improving Nim by favoring vtable implementation over subtype checking?

Hello `nph`, an opinionated source code formatter for Nim

Agreed on that, I'd strongly prefer to have spaces around all infix operators, including `..` and `..<`.

ccal: Calendar with local holidays via ip location

`ccal` Calendar with local holidays via ip location * Caches holidays and location in local cache folder Github: Usage: ccal [year(s)] [country] year (or several) and country code [country] [year(s)] --cleanup

Nim 2.0.2 and 1.6.18 released

We have released two patch releases for Nim: * Nim 2.0.2 * Nim 1.6.18 For more information, [see the website article](https://nim-lang.org/blog/2023/12/19/versions-1618-202-released.html).

ref types and the align pragma

@mratsim Thanks for the context. I created an RFC here:

https://www.facebook.com/SmartHempGummiesCA/

Smart Hemp Gummies Australia:- is all about keeping the body healthy and mind active, as well as stress-free. The product was launched for the first time, so people can avoid chemical products and lead a life that is free from all those kinds of substances. Facebook @

ref types and the align pragma

> If that's not possible, then maybe the align pragma should also apply to > types (currently it doesn't)? e.g. You can open a RFC for this, this should be possible as `alignas` can also work at the type level: > BTW, I found another thread f

ref types and the align pragma

I don't see a bug? The code is doing exactly what you asked. type MyArr = ref array[4, int] MyObj = ref object MyArrObj = ref object arr {.align(256).}: array[4, int] Run There is no constraint on `MyArr` and `MyObj` type at all.

ref types and the align pragma

Sure. But what's the use of aligning a pointer? I'd expect the object being pointed to to be aligned instead.

ref types and the align pragma

@demotomohiro That's what I realized as well, that the references (i.e. pointers) themselves are aligned, but not what they point to. IMHO, this is counter-intuitive. > The alignment is not passed over to the heap allocator. @Araq is this a bug, or by design?

Hello `nph`, an opinionated source code formatter for Nim

No sorting or other reorganisation of imports planned for `nph` due to the order being semantically significant in nim (top-level statement execution order, generics bugs and so on). Sounds like a job for a separate tool (like python).

Hello `nph`, an opinionated source code formatter for Nim

`isort` distinguishes between stdlib, third-party, project and local imports heuristically and gives you options to sort within a section or across all imports and also has options how to sort symbols within one import line.

Direct C/C++ interop without generating wrappers?

> should work in V as V-lang I wouldn't put too much faith into any claim coming from V-lang. There is a history of over-promising and under-delivering. Everytime I've seen people try to check their claims, they ended up finding compiler bugs or edge cases not handled.

Hello `nph`, an opinionated source code formatter for Nim

Formatting (and optionally re-grouping and re-sorting) imports could be an extra step / tool, like Python's `isort`.

Hello `nph`, an opinionated source code formatter for Nim

Does it work like `cargo fmt` for imports? If they are in adjacent lines, they are sorted alphabetically. If there is a blank line in-between, it creates a separate group for sorting? I use this in Rust projects to differentiate between `crate` imports, std/core imports and dependencies import.

Direct C/C++ interop without generating wrappers?

> Is it possible to pass paths (and use the "/" operator) to the compile > pragma? Is it possible to use strformat on those pragmas and on the .passC > pragma? I do pass paths in that example, and even const strings and globs. const rel_path = "./arcade_learning_environment/src/"

Figuro updates: Scrollpane and more

If you want you can take a look at ThreadButler () for the multithreading bits, where I do **exactly** that. Not even just "kinda" that, I mean **exactly** that. I'm still refining bits and bobs here and there, mostly docs, before I make any alp

Direct C/C++ interop without generating wrappers?

Thanks for the hints. @PMunch > However these automatic wrappers will be very C-like, so if you want an > easier Nim experience then you would probably want to write a more Nim-like > interface to the C library which maps it to the automatic memory management, > converts types, and prettifies