Impure libraries ???

The dependency to PCRE is IME not much of a problem (but then see the thread about "doesn't work at compile-time nor in NimScript"), the problem is that we have both `nre` and `re` and both are flawed. But maybe it is the better idea to patch nre and "deprecate" re. Whatever "deprecate" even mea

Impure libraries ???

I see that in the comments section you propose to remove both regex modules from the std lib? That really worries me and is exactly what I meant when I asked for some restraint when removing libraries from the std lib. I know that there are better alternatives to regexes like pegs but for quick

my TUI designer.

hello Upcoming treatment. Additional function: ioFmt(PANEL,GRID) in order to process a form more easily. REFLECTION: see if we can integrate the selection of a line of the GRID I'm still in testing the project is evolving... but already usable

Regular expressions in Nimscript?

If you don't want to read or understand the resulting code why write it? The docker command will fail anyway if your version is illformed or doesn't exist.

Regular expressions in Nimscript?

Thanks for the answer. Do you mean checking manually for compliance with Semver, without using a Regex? I copied the Regex from some website. I didn't care how it looks, I just wanted it to work correctly. Could you please tell me why `reSemver = re"..."` is not good code? How could I improve

Impure libraries ???

is a living document and since the `db_*` modules are not listed they are safe for the time being.

Regular expressions in Nimscript?

`reSemver = re"..."` is not good code anyway and you're better off with a helper proc. Look at your regex, it's full of repetition because regexes offer no abstraction mechanisms.

System.sink & System.lent

If you use a template as an inline function you need to be extra careful to avoid double evaluation of parameters. Also there are some situations like with var return parameters where in Nim it's impossible to replicate the exact behaviour of a (inlined) proc with a template until views are stab

System.sink & System.lent

Sure, I agree that if you can get things working with a procedure it is best to use that instead of a template. However, if you _[really](https://forum.nim-lang.org/postActivity.xml#really) want to inline a procedure, it seems better to use a template, which will _[ensure](https://forum.nim-lan

Regular expressions in Nimscript?

I expiremented a bit, and my conclusion is, that using the `regex` library in Nimscript will always work, except you are invoking `nimscript`'s `exec` proc. (Or any other proc using `nimscript`'s `log` template.) If that `exec` proc wouldn't use `nimscript`'s `log` template, then it would all wo

runnableExample considered harmful / good feature to deprecate before 1.0?

`runnableExamples` turned out to be terrible to implement and are a major source of complexity. I would never do it again. For our users, however, I still think they are nice. And they did improve the quality of our code base, all things considered. And the initial reasons for making them part o

System.sink & System.lent

For me it comes down to the "use the least powerful tool for the job" mantra (especially when writing code that might be used by other people) - procs are simpler and more constrained in what they can do. When they contain errors or are used wrongly they will often fail earlier in the compilatio

runnableExample considered harmful / good feature to deprecate before 1.0?

> Which "vast improvements" happened? Bugfixes and tooling improvements.

Regular expressions in Nimscript?

I've come to the same conclusion, trying this `regex` library, but I get a `~/.choosenim/toolchains/nim-1.6.4/lib/system/nimscript.nim(205, 6) Error: cannot evaluate at compile time: mode` constantly, when trying to use the library. I tried several methods. Using `std/os`, removing it again, et

System.sink & System.lent

Because you may not want to force it to be inlined

System.sink & System.lent

Given that the {.inline.} pragma basically just passes the inline "hint" to the C/C++ compiler, which might or might not decide to actually inline the function, doesn't it make more sense to instead use a template, which will actually "embed" the template code into the call location? If that is

my TUI designer.

Hello, TUI a complete example a complete project with database, multi-window, paging combo treatment grid form call program address book

runnableExample considered harmful / good feature to deprecate before 1.0?

> But those echo docs are hard to maintain; at some point you will end up with > mismatching code and echo examples. no. how would it get mismatched?

runnableExample considered harmful / good feature to deprecate before 1.0?

> runnableExamples got vastly improved after that original thread time ~2018! With respect to the original points: Writing a good doc often means interleaving description and code to weave a readable story - did this improve? Is there any new visual indication where docs / examples end and actu

runnableExample considered harmful / good feature to deprecate before 1.0?

`runnableExamples` got vastly improved after that original thread time ~2018! I am a strong proponent of using `runnableExamples`. If you see any issues with it, may be it deserves a new thread. * * * Few examples of runnableExamples loaded docs written by me: * [elnim](https://kaushalmodi.g

`=destroy` ref object of RootObj?

Thanks, that worked. I did not expect that behavior

Impure libraries ???

I personally hope that the team shows some restraint when “cleaning up” the standard library. I understand the cost of maintaining too many things but having a good set of batteries included is really nice. I know that this is not as important in a compiled language with a good package manager b

Impure libraries ???

Currently the only way is getting hold of a working crystal ball I believe

Impure libraries ???

The easiest way to not worry about v2 is to use a stand-alone library for sqlite, like this one that compiles sqlite itself with the rest of your code mess-free:

C++ interop via Dynamic Library

I've discovered an undocumented pragma, `{.exportcpp.}`, that exports a proc without `extern "C"`. But I don't think it's a good idea to use it because every C++ compiler has its own idea of [name mangling](https://en.m.wikipedia.org/wiki/Name_mangling) , which makes your library not compatible