Windows?

[IngwiePhoenix]

Hello!

This shell looks very interesting and I like the approach of this project to what a shell should do and offer. After reading through the examples and taking a look at the source a little, I noticed that it, currently, is Linux and BSD only (execinfo.h, poll.h, ...). So, I wanted to ask if there are plans to support Windows in the future?

One thing I am personally missing quite a lot is a "native" shell for Windows. PowerShell is nice, but I ended up bridging my entire win32 PATH into WSL - simply because the fish shell (my current default) was nicer to use than PowerShell. It'd be great if there was a shell that I could use on Windows natively, without having to resort to hacks like symlinking my home directory to my Windows user profile - whilst also being able to facilitate features from a proper shell that is really ment for scripting and operations.

Do you thik there will be a Windows port eventually?

That said - and this might blow straight out of the concept of this project, but I might just mention it anyway - would there be a way to embed this shell's scripting component to use in another project? i.e.: by providing other built-in commands and the like? This would be very interesting for those that basically want to make a REPL, but also want to facilitate the abilities of a scripting language. Another way would be to allow ngs to load modules (.so, .dll) to allow other programs to "inject" their REPLs into ngs to make them native to the shell itself, where no switching between REPLs just to run a few commands would be required. Again - this might just go straight over what this project is ment to be, so I just decided to mention it at the bottom of an actual feature request.

Kind regards, Ingwie!

[ilyash]

Hi.

Sorry for the delay.

This shell looks very interesting

Thanks! Please note that the CLI / REPL part is not ready yet. It's only the programming language that is usable at this moment. I'm just starting working on the REPL. The idea is that REPL implementation would be in NGS and people wouldn't need to learn another programming language to make a contribution or fix something in REPL.

Linux and BSD

Linux and Mac, not tested on other BSDs.

So, I wanted to ask if there are plans to support Windows in the future?

In a general sense, yes. I'm not against Windows support. In practice it would need a contributor.

Do you thik there will be a Windows port eventually?

I hope.

would there be a way to embed this shell's scripting component to use in another project? i.e.: by providing other built-in commands and the like?

If I understand you correctly, you are talking about using NGS as a C library. Despite having some thoughts about this from time to time, I don't have any specific plans.

Another way would be to allow ngs to load modules (.so, .dll)

Regarding .so - it's a work in progress with some code already in the project. Not a particularly good attempt I think. The idea is to have much better FFI support and decrease the amount of C code in the project. That's of course in addition to enabling the use of arbitrary libraries in .so.

.dll - I don't know enough about this

You are welcome! Please feel free to post here feature requests and/or other ideas. Thanks!

[IngwiePhoenix]

Thanks! Please note that the CLI / REPL part is not ready yet. It's only the programming language that is usable at this moment. I'm just starting working on the REPL. The idea is that REPL implementation would be in NGS and people wouldn't need to learn another programming language to make a contribution or fix something in REPL.

Some thoughts here: Termbox and other single-header TUI libraries might provide you with some useful utility functions. Luckily, there are almost - albeit named differently - identical functions for Windows and UNIX-ish systems. The only difference is that the Windows console does not handle ANSI escapes. Fortunately, you can just use the colouring functions provided by a single header - con.h i think? Shot into the blue, but it's something like that.

Using a small abstraction like Termbox or alike might help get things started to the point where you might want to nab some of the code that you need. After all, you probably only need support for the arrow keys, colouring and maybe smaller fancy stuff such as cursor positioning or suggesting for completions. Fish handles this by moving the cursor in each input and inserting a differently coloured - grey by default - text with the hint and keeps track of the input through the user's keypresses, where an arrow up/down key resets the buffer whilst left, right pos1 and posN just move the cursor in the buffer. Not difficult, but also not all that trivial. That said - getting a basic REPL running first might be the better idea.

Linux and Mac, not tested on other BSDs.

Using a service like Travis CI or Github Workflows could give you some insight on this as you can set them to build against various configurations. Quite useful if you have a testsuite. Alternatively, I believe you can run docker containers of BSD on Linux - don't quote me on that, but it should be a possibility. After all, all you need is the base dependencies and a C compiler.

In a general sense, yes. I'm not against Windows support. In practice it would need a contributor.

What exactly would be needed? I suppose - from what I have seen - the most important part is to "generalize" the libc being used - i.e. _fopen on windows vs. fopen on UNIX. Anything else? I could take a look into that.

If I understand you correctly, you are talking about using NGS as a C library. Despite having some thoughts about this from time to time, I don't have any specific plans.

Yes - that. Basically I am working on a build tool that needs a simple, yet obvious scripting language. A shell language that is as close to BASH but more advanced in it's feature set would be ideal as the syntax clutter would be minimized. For instance, I have several concepts for using JavaScript or Wren for that purpose - but they are both rather convoluted, especially since JavaScript is a full-blown OOP language, Wren is even OOP-first and other languages are just too big in terms of implementation. So to say, they are kind of overkill. That is why I was wondering if NGS had any means of being embedded. Might be useful.

Regarding .so - it's a work in progress with some code already in the project. Not a particularly good attempt I think. The idea is to have much better FFI support and decrease the amount of C code in the project. That's of course in addition to enabling the use of arbitrary libraries in .so.

.dll - I don't know enough about this

libffi and dyncall are both very good and small C libraries that can help a lot with dynamic FFI calling. I like dyncall a little more because it has a little nicer API, but not by much. You could look at those to get started there. The basic idea is to load a dynamic library and fetch the required symbol. Both of these libraries use a little bit of ASM in order to convert arguments into their proper datatypes and handle calling conventions (Windows STDCALL and UNIX syscall/stdcall). Both of them work cross-platform, too.

I will take a closer look at ngs later today - but it looks very interesting to me so far! Having a shell that runs universally on Windows and UNIX makes switching between OSes - especially when SSHing into different hosts - much more fluent, and is one of the things that I miss a lot. On my Windows host, I use WSL2 to get me covered for the most essential UNIX tooling and some cross compilers that refuse to work as expected under Windows via MSYS or MinGW. But, if NGS was to become a native Windows shell, it would make a strong candidate for system administration as it would eliminate the need to keep multiple shell syntaxes in mind (cmd.exe, PowerShel, Bash, ...).

I'll post more after having taken a good look at the source. Have a nice day and thank you for your fast answer!

Kind regards, Ingwie

[ilyash]

getting a basic REPL running first might be the better idea.

I did not consider this but given the amount of work to implement the vision for the UI, it sounds reasonable as the first milestone.

Github Workflows

In use. I guess it's just a matter of configuration then.

Anything else?

I don't know yet and not sure where to start checking that. The brute force approach would be to just try to compile and see what's missing or fails?

From the top of my head:

• Confirm that the garbage collector library actually works on windows.
• POSIX threads library. From the name I would assume it's for ... POSIX. If another library is added, it should only expose the primitives to the language, all abstraction over the different libraries belongs to stdlib.ngs.
• The "meat" of what language needs from libc in terms of functions used is in vm.c. All functions which are exposed to the language are registered with register_global_func(). Values and constants are exposed using set_global().

Info: higher level functionality is pushed as much as possible from vm.c into stdlib.ngs, trying to minimize the amount of C code.

I could take a look into that.

I would really appreciate that. I want to help you with that. Not sure how specifically yet, we should discuss that.

other languages are just too big in terms of implementation.

Lua comes to mind. Personally not a fan of but it's an OK language I think.

[IngwiePhoenix]

From the top of my head:

• Confirm that the garbage collector library actually works on windows.
• POSIX threads library. From the name I would assume it's for ... POSIX. If another library is added, it should only expose the primitives to the language, all abstraction over the different libraries belongs to stdlib.ngs.
• The "meat" of what language needs from libc in terms of functions used is in vm.c. All functions which are exposed to the language are registered with register_global_func(). Values and constants are exposed using set_global().

Info: higher level functionality is pushed as much as possible from vm.c into stdlib.ngs, trying to minimize the amount of C code.

• GC compiles on Windows using CMake. (VS2019, x64, CMake, Ninja)
• Well, in theory there is pthread-win32 or a few in this list. But it depends on what you need to do - maybe it might just be easier to write your own miniature abstraction though. But, those should at least give you an idea on the differences of UNIX threads and Win32 threads.
• Good to know, I'll take a look at that :)

I would really appreciate that. I want to help you with that. Not sure how specifically yet, we should discuss that.

I am going to read the CMake files and take a look at the build process and see if I can replicate it in a tiny Makefile - from there, I can work out what is missing for windows specifically. Might not even need to go that far, but it'll help somewhat. Since I have my stuff ready, I'll likely do that now. :)

Lua comes to mind. Personally not a fan of but it's an OK language I think.

Gravity, Wren, AngelScript, Lua, Pike, Pawn, ... I have seen a lot of them by this point. The smallest so far is Wren, with Gravity not far behind. I decided to use V as the backend language simply because it's not really OOP, compiles into C and thus is very close to the metal, so to say. It also has some neat features that makes writing wrappers easier - although it's not at the level I'd wish it to be... yet. Lua has a nice syntax, but take a look at a premake example and you might see why I chose to not stick to it. That said though, I also saw Lua in use in a whole many other places - sometimes for the better, sometimes for the worse.

[ilyash-b]

Side note: If it's hard to contribute because for example documentation is lacking or for other reasons, you are welcome to open issues on that. It should be fixed.

[organom]

As a side note, maybe important to the issue: If using WSL2 with ubuntu, ngs can be installed and runs out of the box ( curl https://ngs-lang.org/install.sh | bash ). WSL1 had some issues, not sure what they were anymore :'( . Will add this information asap as part of the issue https://github.com/ngs-lang/ngs/issues/423