Pragma for unfinished features

You can make the macro produce a template so that the warning is emitted when the symbol is used. But I agree, using `.deprecated` instead for it might be the better tradeoff.

Pragma for unfinished features

The wip macro would work if you used it inside of a generic proc. It would be called for each separate instantiation of the proc instead of each call. You could make your in progress procs generic and then when you finish them return them to normal.

Pragma for unfinished features

Thanks for your help everyone, I like that macro and was working on a similar one, but the problem is that the `{.warning.}` pragma doesn't do what I want. All it does is unconditionally result in a compiler warning, but I want a warning for and only for each use. Also I would like this to also

Strange behavior of converter with uint

That or change the echo to: echo (10.uint).int Run

Strange behavior of converter with uint

Beware of converters. They have their place, but should be used cautiously because they are very permissive. In your particular case: * You override the overall conversion `SomeInteger` to return a `LongDouble`. * `10` is converted to a `uint` * The `$` function does not not support `uint`

Blocking nmap scans

I'm always game lols

Blocking nmap scans

Also this is an Open Invitation for anyone who would like to make this honeypot more functional and realistic you're free to join the team. :)

Dual 0.1.0

I’ve released [dual](https://github.com/drjdn/nim_dual) which you should now be able to install with [nimble](https://github.com/nim-lang/nimble). It is a dual numbers library which includes a one dimensional root finder (Newton's method). Enjoy, Jason

Gintro not compile package ??

Merci thank you there is no emergency for the moment I use my backup copy

Confusing behaviour with cstringArray

That explains it, I understand now. Thanks to you both for the great explanations and the effort in answering my questions.

Gintro not compile package ??

Got it :-) Just manage to install gstreamer from latest sources with git clone and the ninja/meson stuff. (see ) And I finally get the same error as you get. Wil

80-bit (long double) support?

Thanks for the snippet... we currently have that code in C, and I think it's best to keep it there and access the results. It looks like a simple route with Nim because it compiles to C and should fit with the rest of the code-base.

Confusing behaviour with cstringArray

> Well, all I was getting was a -1 from `execvp`, so didn't really know what > was going on. I also don't know how to handle C errors in Nim. You would do it exactly like how you would in C. `posix.errno`, `os.osLastError()` can be used to retrieve the error (we also have a proc for converting

Confusing behaviour with cstringArray

Thank you very much for the great explanation! > Casting between them is undefined behavior, probably resulting in a segfault. Well, all I was getting was a `-1` from `execvp`, so didn't really know what was going on. I also don't know how to handle C errors in Nim. I certainly did not get an e

Confusing behaviour with cstringArray

Why does this work: var cmd = commandLineParams() cmd.delete(0) let ccmd = cmd.allocCStringArray() echo execvp(ccmd[0], ccmd) Run But this does not: var cmd = commandLineParams() cmd.delete(0) echo execvp(cast[cstring](cmd[0

Confusing behaviour with cstringArray

`seq` and `cstringArray` have different memory layouts and so, they're not binary compatible. Casting between them is undefined behavior, probably resulting in a segfault.

80-bit (long double) support?

It's pretty horrible, hopefully you only need to move them and not do math with them.

Gintro not compile package ??

I have installed latest vte from sources, and it installs fine. So I assume it is another one of the about 30 gintro packages. You should know the package name, as you generally get all processed packages listed when you do the nimble install, but you did not told us. I could try to fix it by a

80-bit (long double) support?

Use type float80 *{.importc: "long double".} = object Run

Hacktoberfest is here!

Not exactly, it also counts if the PR is merged or accepted

80-bit (long double) support?

Since Nim doesn't seem to support 80-Bit IEEE floats, how am I supposed to deal with them? And yes, we have a codebase in C that uses these numbers.

Define and call static proc of an object

This is intriguing, I had to have a play with the dragon. type S[F:static[proc(a,b:int):int{.nimcall.}]] = object proc fadd(a,b:int):int{.nimcall.} = a+b proc fmul(a,b:int):int{.nimcall.} = a*b type Sadd =S[fadd] #Smul =S[(a,b)=>a*b] nope, has to be stat

Define and call static proc of an object

Associated types/statics must use the shorthand from the type declaration like type S2[T;F:proc(a:T, b:T):T {.nimcall.} ] = object # can be defined discard var s2 = S2[int,f]() # can be defined echo s2.T # Returns int echo s2.F(3, 4) # should return your pr

Hacktoberfest is here!

And now they've changed the rules so that repositories must have a specific label before PRs against them re counted: \- which is probably for the best, honestly.

Gintro not compile package ??

Hello : I saved the pkgs "gintro@#head" which was best suited I respected the installation mode as recommended. I just updated my Linux 64 system (Manjaro) i usually never have a problem for 3 years after the problem ... i just copied the pkgs just to see and everything worked, but it's not t

Gintro not compile package ??

I have just installed gintro 0.8.1 on my Gentoo Linux again without problems. I am using gtk+-3.24.22. Gtk+-3.24 should have a stable API, so I would not really expect problems. Maybe it is indeed your new vte 0.62.0-1 Unfortunately for Gentoo it is not yet available from the package management

Gintro not compile package ??

my compilations in c / c ++ works like the example on linux 34 bits gkt3 3.24.23.1 vte3 0.62.1 update 25/09/2020 nimble install gintro@#head or nimble install gintro I'm giving you the worry excuse me ps: it's not by the minute

Define and call static proc of an object

Thanks! Then, I can define object S2 and call it. But I cannot call the static function... type S2[T;F:proc(a:T, b:T):T {.nimcall.} ] = object # can be defined discard var s2 = S2[int,f]() # can be defined echo s2.f(3, 4) # cannot call Run

Strange behavior of converter with uint

I made the following custom long double class from C++'s long double. Then, the behavior of "echo 10" is 10, which is normal. But when I call "echo 10.uint" is "10.000". It seems that the converter will be called only for uint. Why such things occurs? I also noticed that when I import the fo

Gintro not compile package ??

> And before Araq tells us again that we should ship prebuilt packages instead > creating the bindings during install: We have discussed that problem already, > summary is in the framed box in > titled "The > GTK Nim Bindings". I c