Nim 1.2.8 and 1.0.10 are released

> (...) Ideally, a tag should be a let not a var. That's how we do it usually. This time, we found problems with the release in the middle of the release procedure. We've decided to not publicly announce the release and fix those problems, and then re-release (and re-tag).

Nim 1.2.8 and 1.0.10 are released

> Would it be more logical to call it v1.2.8rc or v1.2.7 instead of moving a > tag? Ideally, a tag should be a let not a var. Sure. And previously we were close to this ideal. Now that the move to our new "nightly build" infrastructure is complete we'll back on track.

template expanding to multiple sequence members

How about ? template myTemplate(x: untyped) : untyped = @[int(x), int(x shr 2)] var a: seq[int] = myTemplate(13) assert(a == @[13, 3]) Run

Listening for variable changes in Nim?

You need a reactive or stream library. I have tried a quick keywords search on nimbler directory, but cannot hit any. I have an unpublished and unpolished library for reactive programming. Here is the base file. import deques, tables type Callback[X] = proc(x:X): bo

Nim 1.2.8 and 1.0.10 are released

> Uh, sorry, a release is complete when we announce it here, not earlier. Thanks for sharing the tribal knowledge. For those of us who monitor GitHub this comes as a surprise. For the last 11 days in the github repo there was a tag `v1.2.8` with the text `Version 1.2.8` and no any indication tha

Listening for variable changes in Nim?

Is it possible to have an event or something else in Nim that fires when the value of a certain variable changes?

template expanding to multiple sequence members

I tried to create a template that expands to multiple values during sequence initialization, eg: template myTemplate(x: untyped) = int(x), int(x shr 2) var a: seq[int] = @[myTemplate(13)] assert(a == @[13, 3]) Run The compiler complains, that it expe

Should we use British or American English in the documentation?

I forgot to vote above ;-). I'd go for 3) as I'm all for documentation. Anything that might cause anyone not to write it is something I'm against. I'd be very surprised if anyone fluent enough in English to read the docs would have any problem parsing the differences between the two.

handmade hero in nim ( warning: noob)

casting is unsafe and discouraged, but type conversions are kosher. none of your casts are necessary. var red = x.uint8 pixel[] = ( (red+offsetX.uint8).int32 shl 16 ) and ( (green + offsetY.uint8).int32 shl 8 ) and ( (blue + offsetZ.uint8).int32 ) Run depending on

Should we use British or American English in the documentation?

> But sounds like it it doesnt

Enu - 3d live programming and game dev in Nim

Note that from what I heard, HN ignores multiple upvotes originating from the same link, as part of "voting rings detection". What I heard recommended is to not post links to a specific HN post, just mention posting there and maybe have some people find it manually ;)

handmade hero in nim ( warning: noob)

Okay, here is some progress. I'm really digging this hybrid manual + arc approach for memory. Is this a good idea? using Jehan's ptr templates. import winim/lean import jptrops #GLOBAL VARIABLE !!! var Running {.global.} :bool = false type win3

Compile-time members

I couldn't figure out how to access members of static variables within a type definition, but found the workaround of writing getters for the fields. type Dim = object x,y:int #can't seem to access fields of a static object? so declare getters proc x(d:Dim)

Should we use British or American English in the documentation?

American English (as used in the USA). Not Canada... :(

Should we use British or American English in the documentation?

@PMunch > But I'd imagine that native speakers might find it a bit more noticeable that > there are different styles. I'm _not_ a native English speaker, but nevertheless when I come across British spelling it sticks out. @drkameleon > I think software and programming are - for better or for

Nim 1.2.8 and 1.0.10 are released

Uh, sorry, a release is complete when we announce it here, not earlier. But the next time this happens, we can also release 1.0.12 and skip 1.0.10, for example.

Should we use British or American English in the documentation?

But sounds like it. Most of the users or developers of Nim are neither american or british

Should we use British or American English in the documentation?

no ;)

Should we use British or American English in the documentation?

Is this a different version of "remove offensive words from your project"?

Should we use British or American English in the documentation?

We're talking about more than just -ize, we're talking about things like "backwards" -> "backward", "afterwards" -> "afterward", etc

Compile-time members

So I'm still trying to wrap my head around compile-time computing and templates in Nim, but am struggling mightily. Anyway, I wanted to construct types based on other types (generic types?), but with members of the parameter type as parameters in the type definition. An example that doesn't com

Should we use British or American English in the documentation?

FYI, Americans mostly use [Oxford spelling](https://en.wikipedia.org/wiki/Oxford_spelling), so pitching it as a USA vs UK thing is a bit off...

Should we use British or American English in the documentation?

This isn't true. Countries like Jamaica and Canada are still members of the Commonwealth which means that the Head of State is Queen Elisabeth II (very symbolic but true). So in Canada colour would be the correct spelling of color. However, due to the close ties etc. color/colour are interchange

Enu - 3d live programming and game dev in Nim

Just wanted to say thank you for your amazing work with Enu. Demo looks very impressive, it's a shame my son is too young to learn programming otherwise I'd be using Enu :-)

Nim 1.2.8 and 1.0.10 are released

I guess I should rebuild images for 1.2.8 and 1.0.10 as well.

Enu - 3d live programming and game dev in Nim

I just released a [new demo video](https://youtu.be/upg77dMBGDE) for Enu and [posted it to Hacker News](https://news.ycombinator.com/item?id=24908514). I'd very much appreciate some love. Enu 0.1 will release on Nov 6th with Mac/Windows binaries, and will be validated to build and run on the la

What Nim projects are you working on?

This is the best extension for Nim Thanks > I would like it to take into account the include, maybe too much requested Really great your version;););) This allowed me to reset all the extensions since there is no longer any dependency Very clean work

Equivalent stdlib data structure to std::map

Perfect this is exactly what I was looking for.

Should we use British or American English in the documentation?

American English is in America.

Nim 1.2.8 and 1.0.10 are released

> Did the v1.2.8 tag move? Yes. > Should I reinstall v1.2.8 ? Yes.

Should we use British or American English in the documentation?

United States is in America.

Should we use British or American English in the documentation?

Yes, but "American English" **specifically** refers to English used in United States

Compile-time if and/or syntax conflicts

`if` is strictly runtime, you need to use `when` in this case: proc createMyArray*(N: static[int]): array[N, int] = when N == 2: result = [1, 2] elif N == 3: result = [1, 2, 3] Run

Should we use British or American English in the documentation?

I know that you're nitpicking, but "American English" is really the accepted term for English used in the United States - see

Compile-time if and/or syntax conflicts

So I'm relatively new to nim, and have been using generics to great effects. Really enjoying the experience so far. Now I wanted to do something different depending on the type parameter, like this: proc createMyArray*(N: static[int]): array[N, int] = if N == 2: resul

Compile-time if and/or syntax conflicts

Hi! Welcome to the Nim community :) The error in your case is pretty simple - you need to use `when` instead of `if` to make different branches based on a compile-time value, like so: proc createMyArray*(N: static[int]): array[N, int] = when N == 2: result = [1, 2]

how to handle non ordinal enums (enum with holes)

is there a good method to work with non ordinal enums eg.: AuthenticationMethod* = enum NO_AUTHENTICATION_REQUIRED = 0x00.byte GSSAPI = 0x01.byte USERNAME_PASSWORD = 0x02.byte # to X'7F' IANA ASSIGNED = 0x03 # to X'FE' RESERVED FOR PRIVATE METHO

Should we use British or American English in the documentation?

America is a continent, by definition. So using American English covers from Canada to Argentina, from north pole to south pole, from Guam to Caribbean islands, someone from Ottawa or Buenos Aires is as American as it gets. :)

Mysterious crashed with SIGSEGV

Sure, I created a repo at:

Nim 1.2.8 and 1.0.10 are released

Did the `v1.2.8` tag move? I distinctly remember that 1.2.8 was released on the same day as 1.4.0 about two weeks ago. Should I reinstall v1.2.8 ?

Should we use British or American English in the documentation?

nim linter can do spell checking. If one limits British/American English differences to just spelling (w/o touching idiomatic expressions in comments) it will not be too difficult.

Nim 1.2.8 and 1.0.10 are released

Yes, you should

Mysterious crashed with SIGSEGV

Can you provide the whole program source code?

Should we use British or American English in the documentation?

I don't think that it's much of a joke since Nim had syntax skins in the past so you could write your Nim code with braces instead of indentation :)

Should we use British or American English in the documentation?

> with braces instead of indentation :) Oh not again :-) There was a high pitch emotional thread on the forum few weeks ago on the subject of braces. Don't restart an extinguished fire.

Equivalent stdlib data structure to std::map

Another possibility is to directly use `std::map`. It's possible to wrap it; see : . But I would only go this way, if you desperatly need some specific `std::map` functionality that you can't find anywhere else.

Should we use British or American English in the documentation?

Same position as @Hlaaftana. American by default. Accept British PR and British -> American PR to avoid overtaxing contributions.

Should we use British or American English in the documentation?

`` Hackathon challenge feature request: Extend Nim's syntax rules such that in addition to being non-first-letter case insensitive and underscore `_` insensitive it is also American/British English insensitive for nim-1.6. Planned for nim-2.0 are Hochdeutsch/Schwiizerdütsch, Russian/Ukranian a

Equivalent stdlib data structure to std::map

Maybe I'm searching the wrong thing. But is there something in the stdlib lib like std::map? So a binary tree backed sorted key value data store.

Equivalent stdlib data structure to std::map

maybe ?

Should we use British or American English in the documentation?

Problem is that most of the code already uses American English: $ grep --include \*.nim -ri "initialize" | wc -l 323 $ grep --include \*.nim -ri "initialise" | wc -l 21 $ grep --include \*.nim -ri "color" | wc -l 2177 $ grep --include \*.nim -ri "colour" | wc -

Square brackets for generics

> The most common point brought up is that expressions like > foo[x](https://forum.nim-lang.org/postActivity.xml) would be ambiguous The angle bracket version of this isn't great either, in Rust you have to do `foo::()`, and Java requires you to do `Class.foo()`. Nim could easily enforce `foo[:

Should we use British or American English in the documentation?

3) Doesn't matter

Should we use British or American English in the documentation?

American is easier to read for a lot of cases ("color" with no "u" is less letters, "initialization" pops out more and is more honest) but I don't think we should fuss too much over it. I'd say have the guideline be for American but accept anything with British spelling, and accept PRs that make

Nim 1.2.8 and 1.0.10 are released

In addition to that, I don't expect the 1.2.x line to reach 1.2.12 (and maybe not 1.2.10 either), 1.2 is not a long-term support release. Is 1.4 a long-term support release? Good question, haven't decided, depends on what 1.6 will offer.

Should we use British or American English in the documentation?

One of the arguments for American English that I can think of: it's much more popular (especially in programming communities). But I'm for British English ;)

Should we use British or American English in the documentation?

As I am the original source for this whole debate, as I've already said... I think software and programming are - for better or for worse - intimately-connected with American English. I started programming when I was 7 and I learned that the text's color in Pascal has to be said with `TextColor

Nim 1.2.8 and 1.0.10 are released

These are bugfix releases for 1.2.x and 1.0.x version, respectively. Our recommendation is to **use Nim 1.4**! These bugfix releases are aimed at people/companies who cannot switch to 1.4 just yet.

Should we use British or American English in the documentation?

So in the author changed a lot of British spellings into American ones, and I'm wondering if we generally should follow British or American word spellings in the documentation? Please vote (and maybe write your opinion down), you can do that by liking

Should we use British or American English in the documentation?

British English

Should we use British or American English in the documentation?

American English

Mysterious crashed with SIGSEGV

So you think those crashed relate to errors in nigui?

Mysterious crashed with SIGSEGV

Please report nigui crashes on nigui's issue tracker. Including the test programs that trigger the crashes.

What Nim projects are you working on?

I'm working on [Enu](https://github.com/dsrw/enu), a 3D live-programming/block-building type environment that hopes to make programming (particularly 3D game programming) more accessible. It's my first Nim project, and I'm really happy with how it's turning out. I just created a new demo video

Mysterious crashed with SIGSEGV

Hey, I just started out with Nim, and I'm currently working on my 2nd practice project. It renders a few points and lines between them based on a text that is parsed. After a short while of playing around with the Program it will crash. The crashes are not deterministically reproducible. A text

Square brackets for generics

> Solitude is right, but there is another problem with square brackets together > with UFCS in Nim - a.b[T](https://forum.nim-lang.org/postActivity.xml) > doesn't work, for that a new syntax extension was introduced - > a.b[:T](https://forum.nim-lang.org/postActivity.xml) so it's not ambiguou T

Testament & module

Thanks !

Square brackets for generics

Well you can call `printSqured(b)` and have its `T` inferred and that makes all the difference.

Square brackets for generics

IMHO, in a meta-programming-heavy language like Nim, there shouldn't even be a special type of bracket used for generic type parameters, `()` is good enough. A "generic" just returns a concrete `type` or `proc` when called with type parameters at compile time. The syntax element for call paramet