How to switch implementations with compiler flags.

[takekikuchi]

I am currently trying to add functions and data types to Neon support for 
nimsimd(). I want to distinguish in the 
source "when" block whether the compile target is arm32 or arm64 (--cpu in the 
compile flag). It would be better if it could also switch by ARM CPU core type 
(e.g. ARM generation). How can I do this?

How to switch implementations with compiler flags.

[uzo2005]

Something like --d:x in compiler flag and when defined(x) in source code

How to switch implementations with compiler flags.

[uzo2005]

Does using --d as a compiler flag to define something and then using a when 
statement in source code work?

How to switch implementations with compiler flags.

[Isofruit]

Note, if you want easy guarantees that both implementations implement the same 
functions, you can write yourself a bunch of forward declarations of the procs 
that should be defined and include those in the various files that provide the 
different implementations.


#moduleInterface.nim
proc x1(y: string)
proc x2(y: int)

#implementation1.nim
include moduleInterface

proc x1(y: string) = echo "Implementation1 x1"
proc x2(y: int) = echo "Implementation1 x2"

#implementation2.nim
include moduleInterface

proc x1(y: string) = echo "Implementation2 x1"
proc x2(y: int) = echo "Implementation2 x2"


#main.nim
when defined(myFlag):
  import implementation1
else:
  import implementation2


Run

Note that this only works for procs, not for templates, iterators etc. so that 
could be an unwelcome limitation for that mechanism.

How to switch implementations with compiler flags.

[takekikuchi]

Thank you, I have confirmed that the --cpu:arm option can be determined with 
"when defined(arm)". The difference in CPU generation cannot be detected at 
compile time because a cross-compiler is used, so it seems the only way to 
determine the difference is at runtime (to support multiple CPUs in a single 
binary).

Exceptions not being handled with libuv: bug or what?

[dadadanix]

I was interested in bringing Libuv to Nim as an experiment to see how it would 
work against native implementations. After getting it to compile correctly with 
Nim's build system, I was able to create a simple TCP echo server. Then, I 
encountered into a problem which I am still stuck with: exceptions are not 
getting handled at all.

To explain it a bit better, these are two snippets of code of a very simple 
implementation of a TCP client:


proc onConnect(req: ptr uv_connect_t; status: cint) {.cdecl.} =
let fut = cast[Future[TCPConnection]](req.data)
let ctx = cast[TCPConnection](req.handle.data)
if status != 0:
fut.fail(returnException(status))
return
let err = uv_read_start(req.handle, allocBuffer, readCb)
if err != 0:
fut.fail(returnException(err))
return
fut.complete(ctx)


Run


asyncCheck dial("127.0.0.1", 8000.Port)
runForever()


Run

To get this working, I've imported the module `asyncfutures` which does not 
depend on the `asyncdispatch` backend, and then wrote my own version of 
`runForever` which just calls `uv_run` with the default loop and the mode set 
as `UV_RUN_DEFAULT`. `dial` just resolves the IP address into an object that is 
accepted by libuv and then calls `uv_tcp_connect` which has the callback set to 
`onConnect`

So, what is the problem? After `uv_read_start` is called, libuv will "block" 
the program until data is read, and for some reason this causes any exception 
to not get handled until the event loop exits, either if there are no more 
active tasks, or by manually stopping it with `uv_stop`.

I initially thought about fixing it by adding a "global" exception handler, 
that before actually throwing the error would stop the event loop: however this 
doesn't seem to be possible at all Nim. Then, I've discovered if the exception 
backend is set to `setjmp`, they would get actually thrown while the loop is 
started.

I am wondering: Is related to a possible bug, or it's just a side effect on how 
the `goto` exception backend behaves? I never worked internally on the Nim 
compiler, so I have no idea on how this actually works

Nim Community Survey 2023

[freeflow]

Curious as to why you are running a survey when the frequent feedback in this 
forum is routinely ignored.

Nim Community Survey 2023

[Araq]

Because it's a tradition by now. Also, feedback is not "ignored", it's just 
that we know how to prioritize and who is paying our bills.

Guardian Blood Balance Australia Price

[Guardzbalancy]

Official Website@:- 

Guardian Blood Balance Australia:-

Only the official Guardian Botanicals website is authorized to sell Blood 
Balance. To avoid scams, customers should be careful when considering the 
offers they receive in stores. The Guardian Blood Balance Australia Supplement 
maintains healthy blood levels.

Official Website@:- 

Facebook@:- 











































Jimdo@:- 







Official Blogs@: 

Nim Community Survey 2023

[SolitudeSF]

for example?

Nim Community Survey 2023

[Isofruit]

Given that the forum feedback just recently informed the decision to focus on 
IC I don't think I agree.

Exceptions not being handled with libuv: bug or what?

[PMunch]

Since C code doesn't have a concept of exceptions you'll need to invoke the Nim 
exception detection. I touch on it in my article on wrapping MAPM: 

How many developers are working on Nim?

[alexeypetrushin]

> better use TypeScript. No, Swift! No, Rust!

I think the era of imperative programming languages is ending.

And we going to see the rise of declarative languages, in the next couple of 
years. You describe the problem, maybe even in english, or mix of formal lang 
and english. And let the AI define the implementation.

And instead of static code, you get live and evolving code base. With every 
improvement in AI, your implementation going to be automatically improved.

And way, way faster progress. And all those zero-overhead performance 
optimisations.

Imperative languages - there not going to be anything new or interesting, it's 
a thing of a past. Like assembler.

please who can explain this code

[Isofruit]

I'd like to ask you to at least format this instead of forcing it into a single 
line. It's intensely difficult to read in this format.

Ideally just use three backticks aka:

```nim



```

please who can explain this code

[isaiah]

`type Animal = ref object name: string age: int proc speak(self: Animal, msg: 
string) = echo self.name & " says:" & msg proc setName(self: Animal, 
name:string) = self.name = name proc incAge(self: Animal) = self.age += 1 proc 
`$`(x, y:Animal ): string= $x.name & " is " & $y.age.int & " old" var sparky = 
Animal(name: "Sparky", age: 10) sparky.setName("John") sparky.incAge() echo 
sparky.$()`

Run

please who can explain this code

[isaiah]

thanks for the quick reply, i really do not know how to format the code using 
rst. after going through the nim manual i was able to fix it.

please who can explain this code

[isaiah]

`type Animal = ref object name: string age: int proc speak(self: Animal, msg: 
string) = echo self.name & " says:" & msg proc setName(self: Animal, 
name:string) = self.name = name proc incAge(self: Animal) = self.age += 1 proc 
`$`(x:Animal ): string= $x.name & " is " & $x.age & " years old" var sparky = 
Animal(name: "Sparky", age: 10) sparky.speak("I am eating") echo sparky 
sparky.setName("John") sparky.incAge() echo sparky[] echo sparky `

Run

Which tools do you use to code in Nim?

[IgnisTempestas]

At the moment, I'm experimenting with JetBrains' CLion and the [Nim language 
plugin](https://plugins.jetbrains.com/plugin/15128-nim), as the plugin doesn't 
support the latest version of PyCharm.

Python programmer by day looking for a language that can help speed up some of 
the code I write without having to learn a language that is difficult to read 
and interpret.

please who can explain this code

[Isofruit]

Turns out the formatters appear to not like code-blocks without _any_ other 
.text

please who can explain this code

[treeform]

I fixed your program (with beef's help) so that it fits on one line:


type Animal = tuple[name:string;age:int];let speak=(proc(self:var 
Animal,msg:string)=echo self.name&" says:"&msg);let setName=(proc(self:var 
Animal,name:string)=self.name=name);let incAge=(proc(self:var 
Animal)=self.age+=1);let `$`=(proc(x:Animal): string = $x.name & " is " & 
$x.age & " years old");var sparky=(name:"Sparky",age:10);sparky.speak"I am 
eating";echo sparky;sparky.setName "John";sparky.incAge;echo sparky;echo sparky


Run

please who can explain this code

[jrfondren]

  1. `echo sparky` doesn't work as you haven't defined the appropriate `$` for 
it.
  2. `sparky.$()` looks like the use of a dot-like operator named `.$`
  3. `$sparky` doesn't work as you've only defined a `$` that takes two 
parameters



Apart from that, it's easy to understand, right? If you want the output "John 
is 11 old" from this program, you can change `$` to only accept a single 
Animal, or you can have use this strange line:


echo sparky.`$`(sparky)


Run

The expected `$`:


proc `$`(x: Animal): string =
  $x.name & " is " & $x.age.int & " old"


Run

or:


import std/strformat
proc `$`(x: Animal): string =
  &"{x.name} is {x.age} old"


Run

please who can explain this code

[jrfondren]

echo type(sparky)   # Animal
echo type(sparky[]) # Animal:ObjectType


Run

Since `Animal` is defined as a `ref object`, you can deference it get the 
underlying `object`, and `object` types have have default printers in Nim.

What's stopping Nim from going mainstream? (And how to fix it?)

[IgnisTempestas]

@dwhall256

> Most people use the editor/IDE of their choice. I'm not going to switch 
> editor/IDE just for a new-to-me language. Any killer feature one editor/IDE 
> has is usually replicated to other editor/IDEs in a matter of months.

I'll argue that a lack of a decent IDE _support_ is one of the reasons why Nim 
isn't taking off, yet. What I find most attractive about Nim for compiled 
applications is that it's easy to read like Python. _However_ Nim's development 
tooling isn't as mature and robust as other languages like Python, C/C++ or 
JavaScript. To be fair to Nim, Python, C/C++ and JavaScript have several 
decades of development and notoriety on Nim so this isn't a criticism. It's 
certainly an opportunity Nim needs to focus on and exploit to become 
_mainstream_.

The [Which tools do you use to code in Nim](https://forum.nim-lang.org/t/10507) 
thread shows there is still some manual setup and tinkering in the tooling to 
use Nim. Visual Studio Code and JetBrains IDEs appear to be an exception, 
though where these two make up for ease of getting started they seem to lack 
maintenance and an active community of developers to help drive them forward:

  * Visual Studio Code's (official?) [Nim extension by 
nimsaem](https://marketplace.visualstudio.com/items?itemName=nimsaem.nimvscode) 
seems to have stalled (last commit 4 months ago at time of writing; two other 
Nim extensions haven't recieved commits for 3 years at time of writing)
  * JetBrain's [Nim extension for JetBrains 
IDEs](https://plugins.jetbrains.com/plugin/15128-nim) hasn't been updated to 
support the latest versions of their respective IDEs, making it hard to adopt 
Nim. Piotr is the sole developer, who also works for JetBrains, who 
unfortunately can't seem to dedicate a lot of time to the extension (and it is 
not yet open-source).



The reason why I'm focusing on these IDEs particularly is because of their 
significant 
['marketshare'](https://survey.stackoverflow.co/2023/#section-most-popular-technologies-integrated-development-environment),
 of 86,544 people surveyed. Converting percentages into rough numbers, noting 
that developers are likely to use more than one IDE:

  * **JetBrains IDEs** : 75,544 approx. users (IntelliJ IDEA, Android Studio, 
PyCharm, WebStorm, PhpStorm, Rider, DataGrip, CLion)
  * **Visual Studio Code** : 63,792 approx. users
  * **Vim** -like: 29,572 approx. users (Vim, Neovim)
  * **Emacs** : 4,059 approx users



@haxscramper

> You need to know who you are selling the language to and what their needs 
> are. Why should I care about the language for example.
> 
> What problem does it solve for me, specifically? Most people are not out in 
> the wild for some quest for enlightenment and better languages, they are 
> looking to solve their problems.

I stumbled across Nim, I think from a random post on Hacker News. For what it's 
worth, I'm a spatial analyst that, among other things, works on algorithms that 
drive wildfire risk and impact modelling for a government emergency management 
organisation. Most of this work is coded in Python (which is used extensively 
in the GIS world), though I'd like to be able to compile some of our slower 
more intensive algorithms for efficiency gains, [like others are doing in 
Rust](https://web.archive.org/web/20220506040523/https://www.nature.com/articles/d41586-020-03382-2).
 Our algorithms exist on desktops, server-side applications, and in web 
applications, so Nim's cross-compilation ability into C, C++, and JavaScript is 
a pretty big perk.

The only thing holding me back is tooling, because of the corporate/government 
environment I work in. I depend on robust tooling. As @giaco points out, the 
tooling side of things is perhaps too brittle for corporate/scientific use.

So, to answer this to help drive the discussion:

> The order of questions must be: What's in it for me? Why should I bother so 
> much (where how 'much' newcomer is bothered defined by availability of 
> documentation, tooling, libraries)?

I don't have the time or the brain wiring to learn, let alone _understand_ , 
C-like languages. I have a really difficult time making sense of languages that 
use special characters extensively in their syntax so C/C++, JavaScript, and 
Rust aren't reachable for me, at least not without significant effort. I am 
magnitudes faster working with _pythonic_ languages over C-like languages, so I 
preference them. It helps that most of my tooling exists in Python (GIS, data 
science, etc.).

Nim allows me to write fast algorithms and standalone executables without 
struggling with C-like languages. Nim is much more ergonomic, which reduces my 
development time writing **clean** code and debugging, which is why I like 
Python. This is despite Nim's immaturity compared to Python. I can read a block 
of Nim, or Python, and understand it without too much cognitive effort. I can't 
say the same for C/C++, JavaScript, and Rust. They disorient me.

After all, wheth