2.0 RC new and old

sigh... The real problem is there are not enough versions... Nim add features all the time but release very slow, everyone has to change code all at once for all the new features. Then too many features, old code is "broken" but would be fixed easily if it was gradual release. Look at Rust, they

2.0 RC new and old

> Projects simply do not support new versions of Nim, thereby having to rewrite > the code almost from scratch or to develop a project without updates on a > static basis. I didn't have much trouble updating for Nim 2.0 with Norm or other packages I maintain. Is there a specific issue you're ha

Object Arrays

Thank you so much, I will try this.

2.0 RC new and old

Good people, please answer me, clarify! Will Nim solve the problems of different Nim implementations? With each new version of Nim - all the time something is removed or added. Projects simply do not support new versions of Nim, thereby having to rewrite the code almost from scratch or to develo

Future of typing ?

The point is just cause two generic parameters are related does not mean the data type should support this conversion. `seq[Child] -> seq[Parent]` is just a single instance of where it can be fine. I can provide a multitude of examples where this implicit conversion causes runtime issues cause i

Scan syntax tree for procedure calls

I see but I've done some database work back in the days. If you keep business logic on application side you often need reading from database too in your write transactions for enforcing rules etc. I think something like this is a possible use case: db.startTransaction(t): rea

Scan syntax tree for procedure calls

Thanks for the ideas! I intend to have the commit and rollback as part of the transaction template so you don't forget it, that's why two different templates are needed. I originally intended one template with automatic choice but was convinced otherwise by the kind responders.

How could I set up an i386 CI for Nim?

This is my i386 setup:

Scan syntax tree for procedure calls

thinking some more, actually `readTransaction` / `writeTransaction` describe the most common use case really well, so a note in the docs will do fine to explain the finer points. Looks like we have a winner.

Scan syntax tree for procedure calls

I dont know that database but how about this : type Transaction = object active : boolean handle... etc db.startTransaction(t): write or read db commit (/ rollback) #which beginTransaction(t) translates as below and commit/r

Need guidance for a first experience with Nim and ESP32

Rolling back to esp-idf 4.0 fixed the issue. Should i retry with esp-idf 5.0 and the branch devel-5.0-fixes with the patch I described earlier?

Need guidance for a first experience with Nim and ESP32

I was reinstalling everything cleanly (esp-idf 5.0, USB on WSL2...) to have a more reliable setup. However, now whatever branch of Nesper I use (devel, devel-5.0-fixes, faldor20/devel), I was getting an error while compiling the Nim Code: /home/vincent/Documents/Nim/MCU/esp32_nim_e

Scan syntax tree for procedure calls

> I have considered writing a more in-depth thing about macros and the logic > surrounding them. I am really interested in such a blog post!

Future of typing ?

> More type inference is not necessarily good: "I have to type less" has to be > weighted against "error messages are more mysterious than ever". Minimal type inference is one of the better features of Nim, it makes it easier to work with random code.

Future of typing ?

It works if you convert the first element explicitly. type Parent = ref object of RootObj i: int Child = ref object of Parent f: float let list: seq[Parent] = @[Parent(Child()), Child(), Child()] echo list[0][] Run It's just

Need guidance for a first experience with Nim and ESP32

Oh wow, I'm really lucky on my timing then! It's amazing that you managed to implement the calibration because that is one really nice feature of micropython on the esp32. With that, Nesper will be far more advanced than tinygo. Are you also implementing the DAC at the same time? May I ask you

Need guidance for a first experience with Nim and ESP32

Hey, I'm the guy working on the branch with the buttons, I've got some more changes I'll try to sync into the PR, but if you want the latest work off my devel branch. I have just started to do stuff with ADCs and added FFI wrappers for the calibration code, I cannot speak to their accuracy, but

Shrinkx ACV keto Gummies Hearing Support Supplement Worth Buying

Shrinkx ACV Keto Gummies - If you're looking for a weight loss supplement, you may have come across ShrinkX ACV Keto Gummies. These gummies claim to help you lose weight by suppressing your appetite, boosting your metabolism, and increasi

Scan syntax tree for procedure calls

`readTransaction` / `writeTransaction` These are really good for exposing what's going on to whoever is reading the code. Adapting the freedom to drop the python-with, `read` and `write` might do it as well. But hang on- you can read from a writable transaction. The accurate terms would be ro

Future of typing ?

I meant impossible to do statically, of course it's possible to check instance type at runtime. proc some(parent: Parent): void = # impossible to determine if parent has specific child type at compile time Run compared to proc some(child: Child): v

How could I set up an i386 CI for Nim?

Hey @elcritch I'm running `i386/ubuntu:latest` container on ubuntu-latest. But the problem is the CPU is not 32 bits so that csource building fails.

NiGui: adding images to a layout container

This is simply because Nim closures capture by reference. By the time your loop is over `dieImage` will point to the last image for all of the callbacks. Have a look at this for a way to solve it:

Object Arrays

ah ok that makes sense, then you should use a tuple and the [fields](https://nim-lang.org/docs/iterators.html#fields.i%2CT) iterator as mentioned by @tsojtsoj. type Layer*[NumIn, NumOut: static int] = object weights: Matrix[NumOut, NumIn, float] biases: Vector[

Future of typing ?

"Pretty much the same thing", that's just wrong. When you do `mySeq.add Child()` the compiler sees that it can implicitly upcast to the `Parent` type since it's a mismatched parameter. When you do `let mySeq: seq[Parent] = @[Child()]` there is no converter for `seq[Child]` to `seq[Parent]`. Whic

NiGui: adding images to a layout container

This is my code: import nigui app.init() var diceContainer = newLayoutContainer(Layout_Horizontal) for i in 1..6: var dieImage = newImage() dieImage.loadFromFile("Dice" & $i & ".png") var dieControl = newControl()

NiGui: adding images to a layout container

Thank you, Trustable.

Future of typing ?

Nim allows `var list: seq[Parent]; list.add Child()` which is pretty much the same as `let list: seq[Parent] = @[Child()]`. Inconsistent, same thing working one way but not another.