Nish, a command line shell

Just a small bump. The new version (0.8.0, still beta) of the shell arrived today. It contains the option to quit from the shell with Ctrl-D too. Better late than never. :)

String to AST

It is under the `compiler` "package". So you have to use it as `import compiler/parser`, etc.

Nim on the go: Smartphone, termux and ... "no" docs.

If you can't find anything, you can create a PDF from an existing page in any modern browser, Chromium or Firefox based. In the printing dialog, select destination as "Save as PDF". Should work on smartphones and on desktops too. That's how I often read documentation on a smartphone. :)

Cross compilation to Windows, linker error (unrecognized option '-z'

This working for me, but with GCC and mingw 10 on the old stable Debian. I use it to build Linux and Windows versions of my projects. Here is a full command which works for me: <https://github.com/thindil/nimalyzer/blob/trunk/nimalyzer.nimble#L42> Another possible source of the problem

Cross compilation to Windows, linker error (unrecognized option '-z'

I see, it seems like the old problem is still here. ;) Here are my all arguments for cross-compile: `nim c -d:mingw --os:windows --cpu:amd64 --amd64.windows.gcc.exe:x86_64-w64-mingw32-gcc --amd64.windows.gcc.linkerexe=x86_64-w64-mingw32-gcc`

Cross compilation to Windows, linker error (unrecognized option '-z'

Out of curiosity, what happens when you add two more flags: `--cpu:amd64` and `--os:windows`? >From my experience, cross-compilation from Linux to Windows works with Nim. >Just I set it some time ago, and with a different version of mingw.

Having trouble with the Testament tool

Testament requires the tests to be stored in a proper directories' hierarchy. For example, Nim tests: Example of working structure. The tests are in `tests/directory/test.nim` and `tests/directory2/anothertest.nim`. If you have that structure, t

Is there a way to create a musl binary (static binary) in a project using libcurl.nim?

It is possible, but in that case, you will need to rebuild all libraries on which the project depends. In your case, you will have to rebuild `libcurl.so` with `musl`. And all its dependencies, if any. I think the easiest way for this, would be to use any musl-based distro.

Nish, a command line shell

Currently, not, but it landed on my to-do list for the next version. :)

Nish, a command line shell

[Nish](https://github.com/thindil/nish) is a non-POSIX, multiplatform (tested on Linux and FreeBSD but should work on Windows too. With a lot of unixisms inside) command-line shell (similar to zsh, bash or fish), currently in the beta stage. It offers some features common for commands' s

thread process can not change text buffer

The problem is not within Owlkettle, but in the graphical stack. Almost every GUI library isn't thread-safe and can be updated only from its main thread. The only multithread libraries are Vulkan, DirectX 12 and Metal. Anything else will crash when you will try to update GUI from another thread.

no simple way to import files from dir recusively?

Perhaps, because it will make many things unnecessary complicated. ;) Importing the whole directories of code is usually a rare case, and the amount of work needed for creating separated types of imports can be large. Additionally, it will cause the importing syntax more complicated, so the lang

Testament - Test Failure reFilesDiffer comparing wrong files with one another

If you want to import a module from your project, you have to use a full path to it, like `import ../../src/mapster`. The reason of it is, that the test is a separated program. Thus, `import` statement knows only the version from your packages' repository.

Command line options

For that kind of checks, you will probably need another tool, like `nimalyzer`: <https://github.com/thindil/nimalyzer> Just "small" warning, it is in pre-alpha stage that's why I don't advertise it around. At least not too often. :)

Trouble Porting to FreeBSD

Just a small update after some tests, more like note for myself. ;) The whole process of installing Nim on FreeBSD looks that (without downloading, decompressing, etc.): 1. Run `./build_all.sh` 2. Copy proper binaries to _/usr/local/bin_ 3. Copy _lib_ directory to _/usr/local/lib/nim/_ , s

Trouble Porting to FreeBSD

My observation related to the FreeBSD port of Nim. Several months ago, I need to play with the development version of Nim. First I tried to install it in FreeBSD way, by upgrading the existing port. It didn't build. So I built Nim manually, with the standard `./build_all.sh` command. It worked

Some of Nim's convention needs to change in order for it to succeed

1. Having the **optional** keyword `end` for closing code blocks would be a helpful feature, but it wouldn't change the speed of adoption of the language. It could prevent some mistakes in the code, related to the wrong indentations levels, a special feature of Python-like languages, but that'

Wrapping Tkinter GUI in Nim?

> Quite the contrary, actually: there's a lot I could learn from your code! Glad to read that, I hope good things too. :D About asking, feel free to ask me, I will try to help you as much as I can. It is always a good opportunity to test my own knowledge and to expand it. Especially that I have

Wrapping Tkinter GUI in Nim?

Interesting feeling. :) Personally, I see Nim as Ada 2.0. It solves some issues which I had with Ada, mostly related to dynamic containers and portability. From the second side, I miss the ability to set arbitrary start index for sequences in Nim. :) But generally I'm happy. After some initial p

Wrapping Tkinter GUI in Nim?

The game is my pet project, which I started a couple of years ago to learn a different language, Ada. :) When I meet Nim I decided to rewrite the whole project to Nim. For fun, and to see how much work will be needed for it. That work is currently under way. And that is the reason why the code i

Wrapping Tkinter GUI in Nim?

for Tk, but it is very low level binding, basically it calls the Tcl commands to create GUI: <https://github.com/thindil/steamsky/blob/master/nim/src/tk.nim> It can be used more as an example how to create the binding. ;) Answer to questions: 1. That's quite simple and needed for Tk

Wishlist: Ideal UI library for Nim

> it's rather easy to accomplish One of the famous last words. My favorite battle-cry. :) > "Works well for boring apps and for games" Then we don't need both approaches. Having both would be very nice, just not a top priority. I saw games which were using QT as GUI framework and professional

Wishlist: Ideal UI library for Nim

> I don't agree. It's mostly the existing distinction between peekEvent vs > waitForEvent. >From my experience, a bit more. ;) The immediate mode places a GUI's code >inside a program's main loop, while the event/callback mode before the loop. >Immediate takes care also about drawing, while the

Wishlist: Ideal UI library for Nim

* It is usually done via `canvas` widget. So that widget is needed. And this mean just abilities to drawing in the library. * Multithreading in GUI usually depends on a backend code. At the moment, only Vulcan and DX12 supports multithreading, OpenGL not. If you try to update GUI from another th

GUI app with nim

Another option is to use Nuklear UI library. It has some plotting capabilities. Just the Nim binding for it is not commercial ready: <https://github.com/thindil/nuklearnim>. It is low level binding, the only good thing is that original documentation fits. ;) As I just started dogfood

The Nim development team cooperates with OpenAI in order to fight climate change

Oh, I see. In that case, do you accept medical or legal documents?

The Nim development team cooperates with OpenAI in order to fight climate change

Can we extend the check to atomic tanks too? I recently bought a customized, upgraded version of M1A2 SEPv3 as a daily driver and would be nice to take it into account.

File logging in a thread using spawn (GC safe call expression)

The call `logger.log(lvlInfo, "Logged")` isn't thread safe, because the logger, especially to a file, isn't thread safe. You have to use handlers to log to a file from different threads. You can't use logger directly in that way. Don't forget about notes:

How to further speed up the build of your Nim's projects (using ccache)

It depends on the file system. ZFS caches, others usually not. ccache speed up recompilation of a project even if you do clean recompilation or recompile it after restart/reboot the machine. Generally, ccache is a nice thing for large projects. Sometimes it can boost recompilation even by 90%.

Selecting/installing older nim package on FreeBSD

FreeBSD doesn't store older versions of packages. If you want to use an older one, you have to build it from ports, install as package and then lock the package, so the system will not upgrade it. In your situation, that could be a huge overkill. Thus, probably the best option is to build from s

Nimble decentralisation?

Nimble can pull packages from Git or Mercurial repositories, even if they are not in any index. But in that case you have to specify the repo. So, instead of: `requires "mypackage = 1.0.0"` You have to write (for example, if you want the newest commit): `requires "https://github.com/user/packag

How to use Github's actions/cache with Nim?

It depends on what you use. If you install Nim with _choosenim_ you will need to cache `~/.choosenim` directory. If you use any dependencies installed with _nimble_ , you will need to cache `~/.nimble` directory. BTW, GitHub Nim action: has support

Setting compiler-style defines in normal code?

I see. :) Any flag/variable set to compiler will affect all files. Another option, maybe setting an environment variable in one module and read it in another? In that way, it would be possible to also change the variable's value without editing the code.

Setting compiler-style defines in normal code?

This works for me: when defined(myVar): echo "defined" else: echo "not defined" Run Compiling it with `nim c -d:myvar test.nim` and executing, prints **defined** , when compiling with `nim c test.nim` and executing, prints **not defined**.

Testament Demo: "Running a single test" is not working

Tests for Testament have to be in separated subdirectories. My guess, the documentation needs some updates, unless it is a bug. ;) For example, if your main tests directory is `tests`, and you want to have test file `test0.nim` you have to put it in a path like `tests/subdir/test0.nim` Then run

Building Nim + Nimble on Ubuntu 22, "could not import: SSL_get_peer_certificate"

You could try: 1. annoying way: use `LD_LIBRARY_PATH` environment variable or `rpath` setting of the compiler to set the path to the OpenSSL 1.1 library. A lot of fun. ;) 2. Use `choosenim`, download and install OpenSSL 1.1 as suggested here:

Nim devroom at FOSDEM this weekend

Usually, FOSDEM talks are available after some time. This year talks will be available to download here: And thank you everyone for the talks. It was a pleasure to watch them. :)