A rant about Nim bugs

We have been using Nim since 0.18.0 and the bugs we have ran into is minimal compared to the development speed. Some fixes were needed when upgrading Nim versions but all were manageable. We are very happy for the scope of the standard library - and without it we wouldn't have chosen Nim. We do

enum in macro

I'm still not sure what you are trying to do and why you need a macro? Are you trying to get the string value of the enum value?

enum in macro

I can slurp content of defaults files.

diff lib?

I think my port of that same Py difflib algo is a bit tidier and also quite a bit faster: In the near future (whenever duplicate keys in `std/tables.Table` move from deprecated to gone - a move I still consider better resolved through documentation improvemen

Mazda Skyactive-X

Mazda Skyactive-X business case is similar to Nim unfortunately. Nim needs to learn from Mazda.

A rant about Nim bugs

No one is really obligated to do anything except what they get paid for, so you need some kind of motivation. This motivation is not easy to come by if you don't have a specific goal. I don't think Nim has a specific goal (so it's "general purpose"), and I'm perfectly fine with this. There are

Nim : Style insensitivity , snake_case , camelCase

I don't agree but I also don't care enough to continue the discussion. Believe what you want, I know what I know. ;-)

Bug with peekableOutputStream?

Thanks, I'll give that a try

Unicode Operators: How Do we Choose Which To Include?

With regards to ease of entry, I've updated the table to show the operators for which vim digraphs exist. Inclusion in that particular list is in practice critical for at least me; I suggest it's one of the considerations if/when any more unicode is added (e.g. more brackets)

A rant about Nim bugs

TL;DR Distributing Nim with a rich standard library or with a bundle of "core" libraries is important for many use cases. In some organizations the same team writes software, selects 3rd party dependencies, builds, deploys and runs it. Despite the popularity of continuous deployment, the majori

Nim : Style insensitivity , snake_case , camelCase

> plenty of people also claim they are productive with Vim (and they are not). Ah yes the good old "I'm not productive with it so no one is". Very compelling. > Nope, see here: I mean, have you read the paper you linked ? While the re

Bug with peekableOutputStream?

Procedures implemented with `peekData` (`peekChar`, `peekStr`, etc) should work.

Nim : Style insensitivity , snake_case , camelCase

I find camelCase easier to type

Nim : Style insensitivity , snake_case , camelCase

please, boss, no more trolling...

Nim : Style insensitivity , snake_case , camelCase

> I found the claim this is objective unfounded and I strongly suspect this is > a cultural thing. Nope, see here:

Nim : Style insensitivity , snake_case , camelCase

> Interestingly, most people I know find snake_case more readable and they are > not German speakers. How do you know they don't merely _claim_ to find it "more readable"? ;-) I mean, plenty of people also claim they are productive with Vim (and they are not).

progress while binding libxl

BTW, there is another version which is translated from VB6's declaration. No `handle.h` is need as the above version does. However, maybe it works only on windows (or windows 64 bits?) import encodings import strformat type Integer = int16 Long = int64

progress while binding libxl

Aha, I almost modified nothing, then my code can be compiled with nim 1.7.1, and the xls file is created as expected! What a weird fantacy! import encodings type tagBookHandle* {.final, header: "", importc: "struct tagBookHandle".} = object BookHandle* = ptr

Nim : Style insensitivity , snake_case , camelCase

[spam]: I put together a linter that can switch naming style automatically: Interestingly, most people I know find snake_case more readable and they are not German speakers.

Unicode Operators: How Do we Choose Which To Include?

There are no "first principles" we adhere to here, some operators are missing, others are questionable to include, others are hard to distinguish from others but that depends on the font and others are currently hard to type. I'm skeptical that we could come up with "principles" here that will s

Unicode Operators: How Do we Choose Which To Include?

> the important part is that operators can help express ourselves better. a ♥ b > could make perfect sense This is a perfectly reasonable principle by which to select operators for inclusion, and I could see that as the answer to my question. * Operators should be filled in * Operators must

Nim : Style insensitivity , snake_case , camelCase

Oh, I did a dumb. Sorry.

Unicode Operators: How Do we Choose Which To Include?

> Well I don't see what's wrong with how the RFC went I think it went very well; maybe I should have put my thoughts into another RFC. It began for me as a question, but of course, as I dug deeper my opinions started to crystallize. Reading back, i realize my snarky 'cargo cult' comment could b

Unicode Operators: How Do we Choose Which To Include?

Well I don't see what's wrong with how the RFC went and why the particular set of operators is problematic. Supporting all of Unicode seems crazy, esp since Unicode keeps changing. Unicode operators are like salt in a soup, it tastes well when used with care.

Nim : Style insensitivity , snake_case , camelCase

thats kebab-case