Is it possible to detect "not defined in header file" ?

To check if a C macro is defined: let hasNet {.importc: """( #ifdef CONFIG_NET 1 #else 0 #endif )""", header: "config.h".}: cint Run To check if `-d:nimNoNetwork` is passed: when defined(nimNoNetwork): echo 1 els

Is it possible to detect "not defined in header file" ?

I considered this through trial and error. As a result, I thought that allowing configuration without networking would have a significant impact on others, so I will deal with this by enabling only local network(lo).

Expose static nim library to DLL

Ok, it appears it's in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libclang.dylib Run I will play with Futhark. I like what you did with pntr, which is a friend's graphics lib that is still in flux, so it's probly going to c

Nim vs the 6 languages I learned before it

@dlesnoff > I believe this article might convince many procedural persons, but I see no > functional programming languages in there. Well, the Nim version could be turned into something that looks more functional if more variables were defined to be immutable with `let`'s instead of `var`'s an

Http(s) Stream

Just in case someone stumbles over this thread: I had to make some slight changes for this to work again: import std/[ net, strformat, strutils ] const host = "lichess.org" token = "wn89m89uer8999e9" let s = newSocket()

Returning to Nim from Python and Rust

I believe [this script](https://github.com/nim-lang/Nim/blob/devel/tools/nim-gdb.py) along with `--debugger:native` used to give a decent gdb experience. I've tried it before and it seemed to work at least. The script could probably be improved though, and the debugging better integrated with e

Returning to Nim from Python and Rust

I'd have to agree that tooling is the bottleneck to greater adoption for Nim -- more so than any language feature coming in 2.0 IMHO. I want to do my part and not just complain. Maybe some day my Nim-foo will be good enough to contribute directly, but until then I'm opening to sponsoring a conc

Leaving out type names during compilation

Thanks. Would probably be the correct approach. But I tested with Nim 2.0, and it appears to be doing this a bit different, so it seem to solve the most difficult part for me, the type names used in inheritance.

Returning to Nim from Python and Rust

I agree with bitstorm about the debugger... would be important to have it working right of the box.

About NimMain when launching multiple Nim tasks on RTOS (FreeRTOS, Zephr, etc.)

Nice! Yah I’m not too familiar with the inner parts of NimMain. But it sounds about right. Any code in modules that live outside proc’s will get called from NimMain. I’m not sure what you meant by PreMain calling NimMain, but NimMain is called from a C main function. That’s what you disable for

Returning to Nim from Python and Rust

It would be nice if anyone who has knowledge on this could post links to old efforts or at least a breakdown of what is possible and what next steps could be taken. I think if there isn’t available expertise or interest at the moment in Working on this. Maybe for now improvements to the lsp sup

Returning to Nim from Python and Rust

Also maybe we could get a Discord channel for those of us interested in improving tooling? It’d be cool to be able to share improvements and get support. Those of us in the Nim embedded discord talk about various tooling bits a fair bit.

Returning to Nim from Python and Rust

> If I compare my progress in Rust with Nim I have to conclude that the > advantages of Nim are mostly offset by excellent tooling in Rust like the > rust analyzer and the debugging suport in CLion or VSCode. The tooling in Rust for these things are excellent. However for me I find Nim’s expres

Returning to Nim from Python and Rust

Hello, I'm a data scientist and my day to day work is mostly concerned with developing deep learning systems. Despite the popularity of Python in this area I'm looking for alternatives because of its weak typing and the very mixed native speed. After some experiments with FSharp and Rust I stu

Leaving out type names during compilation

Methods and class inheritance need runtime type information in order to function. Maybe don't use these nim features if you don't want types in the compiled code. Or use some sort of automated C obfuscator before calling the C compiler (you could write some sort of shim program that obfuscates t

Expose static nim library to DLL

> That lclang issue talks about how to fix it on ubuntu, and is fairly involved > (not sure why a system-installed library should need all that) so it doesn't > really help me on mac. I have no /usr/lib/llvm-*, for example. Well it's just a matter of figuring out where libclang installed the fil

Leaving out type names during compilation

I don't write malicious stuffs, but me too want to hide these information

Leaving out type names during compilation

There is plenty of reasons for not wanting to expose code structure, there are also non-malicious reasons for writing obfuscated code. Stripping only removes symbols, Nim embeds type names other places.

RosettaBoy - Gameboy emulator rosetta stone

Profiling shows like 35-40% of the CPU time is just in that `nim/src/ram.get` template. This is supported by overall time variations as big as 12% I see by fiddling with the way `of`-branches work in `ram.get` (showing 10% changes in branch mispredicts via `perf stat -ddd` on a Linux Skylake acr

Expose static nim library to DLL

> Poked around a bit (and added a forwarding feature to Futhark) and got > everything working I appreciate it! > The Futhark install issue with -lclang is simply because it isn't able to > find libclang, That lclang issue talks about how to fix it on ubuntu, and is fairly involved (not sure w

Leaving out type names during compilation

* Don't write malware in Nim. * it's called stripping, there's a utility called `strip` for it * don't write malware in Nim

Expose static nim library to DLL

Oh and by the way, when things "seem to work" and C is involved that doesn't really mean much. Before I made Futhark I wrote applications that ran for days before crashing out of nowhere because my bindings where ever so slightly incorrect. You can get a binding to the point where everything see

Expose static nim library to DLL

The Futhark install issue with `-lclang` is simply because it isn't able to find libclang, this issue goes into a bit more detail: . To build `nimrtl` you need to be in the folder where the program lives, which is in Nim sources. But for ARC/ORC you

Khonsu CBD Gummies Reviews 2023: Does It Work?

Khonsu CBD Gummies The ideal locations from where one can arrange the month to month supply of the equation is the authority site. There could be no other source from where one can arrange the month to month other than its true site. OFFICIAL WEBSITE SEE MORE;-

Expose static nim library to DLL

What I tried to explain is that you have to mark the callback itself as `cdecl` if you want to accept a C function pointer as argument. For example: proc retro_set_video_refresh*(cb: proc(data:array[1280, int32], width:cuint, height:cuint, pitch:csize_t):void {.cdecl.}) {.cdecl,exp

Is it possible to detect "not defined in header file" ?

The **importc** pragma can read the value from C headers. Is there any way to use it to determine if it is defined or not? Example: read config.h and set value with/without "CONFIG_NET". (I want to set false if there is no definition in the header). const hasNet = true (or false)

Leaving out type names during compilation

Is there an option or method of compiling that does not include original function names, class names, file names and such in the final executables? For example, when using class inheritance the compiled file will include strings like "someclass|somebaseclass|RootObj|" and I would prefer that the