ngs-lang / ngs Goto Github PK

Since you're starting fresh I must ask : why C ?

Wouldn't this benefit from being written in rust, if only for security considerations.

Reading the current design ideas, it seems you'll want to implement some form of functionnal "code" language in the shell. Might be quite useful to do this in a language that has the required primitives.

Therefore ec2din.ngs --allreg is stuck.

If GC is disabled (using regular malloc and no free) it does not happen.

I've been looking over the project and find it has tremendous potential. I agree with your premise that there is much scope for improvement over current shells like zsh, fishshell etc.

However, it seems to me that there would be a significant gain in adopting an already existing language such as python as the 'programming language' of the shell.
https://docs.python.org/2/extending/embedding.html

I think there would be both advantages and disadvantages to such an approach and i'll just try and list them out here.

Advantages

1. DRY compliant as we can fully leverage the features of python inside the shell instead of reinventing a programming language from scratch.
2. Low barrier of entry for new developers as it is not required to learn the syntax of another programming language at the bash level. - this would theoretically lead to higher adoptions.
3. Python already has very good shell functionality (see ipython)
4. Possible extensible plugin architecture for people to extend functionality of the shell via python snippets hence allowing for customizability.

Disadvantages

1. Syntax and Architecture would be more complicated
2. Not as 'cool' as designing a full featured programming language from scratch
3. Combining python syntax as well as execution results, I/O etc. might be complicated to handle.
4. Is a massive change in direction for NGS.

Example Usage Scenarios

1. file manipulation

# store directory listing in a variable

> ls = files_list      

# loop through every image file
# make a directory by converting '_' into multilevel folder structure
# move the file into that created folder and rename it 

> for file in files_list.filter(extension='jpg'):
    dir_name = '/'.join(file.split('_'))
    mkdir -p dir_name
    mv file dir_name/file.split('_')[-1]

1. log folder maintenance

> ls = files_list 
> date=datetime.strftime('%d-%m-%y')
> tar -xvzf files_list.filter(extension='log') > logs_{date}.tar.gz
> s3cmd put logs_{date}.tar.gz --bucket='backup'
> rm files_list logs_{date}.tar.gz

To match the convention, low level methods should start with ll_. Currently, methods dealing with indexes of global variables do not follow the convention.

The part of the readme:

install macports

brew install Caskroom/cask/macports
macports_dir=$(brew cask info macports | grep '/usr/local/Caskroom/macports' | awk '{print $1}')
macports_pkg=$(brew cask info macports | awk '$2 == "(pkg)" || $2 == "(Pkg)" {print $1}')

sudo installer -pkg "$macports_dir/$macports_pkg" -target /

is not working in high sierra. As a workaround I installed the macports from the
https://guide.macports.org/chunked/installing.macports.html and followed with sudo /opt/local/bin/port install uthash

I am currently implementing a browser based terminal with a DSL narrowly scoped for interacting with JSON APIs. I implemented command output using scoped containers to avoid race conditions and naturally ran into the problem of accepting input from commands that had already lost the prompt. Here are my thoughts:

Traditionally:

• STDIN is a stream that is open by default
• STDIN can be read by one process at a time
• Synchronous portions of a command block the shell
• Asynchronous portions of a command race for write access to STDOUT

Goals:

• Allow asynchronous commands to release the shell early
• Organize latent output
• Support latent input

When should a command release the shell?

• When it is done reading input
• When it is done performing synchronous tasks
• It should never actually block the shell at all

It would be interesting to allow developers to simply close the STDIN stream to guarantee that their program is done asking for input. That would even allow synchronous programs to free the shell early.

It would be nice to get non-blocking async behavior by default though. If you want to free the shell and continue accepting input without disrupting the active shell, it becomes a matter of user interface design. The command needs a way to ask for input without loosing the context of it's output. If you assume that output is organized in containers that are scoped to commands, then you have to assume that it might be hidden in the scroll history.

How should latent input prompts look?

• A global notification with a link that scrolls to the command container
• Shift the command container to the bottom of the stack so it is visible
• A popup with a copy of the command container

I prefer reordering the command containers to avoid making the user scroll back to the main prompt when they are done. I am not a fan of popups. I am not convinced that allowing multiple active input prompts is a good idea. It might be confusing to the user.

In the end I think I would prefer that users have an intuitive experience and put the burden of optimization on the developer.

• Provide an unopened STDIN stream to the command
• Block the shell while the command is executing synchronously
• Require the command to synchronously open the STDIN stream if it wants read from it at any time
• Block the shell until the STDIN stream is closed or the command exits
• Allow the shell to release the STDIN stream before it is opened which releases the shell before the command is done executing synchronously

New multi-method trim() should strip whitespace.

At least method F trim(s:Str) should be implemented. The implementation should be in stdlib.

• Consider optional switches for specifying whether beginning, ending or both should be trimmed
• Think about F trim(a:Arr) and maybe other data types

As Node.js finds libraries which pertain to the running Node.js version, NGS should too.

Currently one has to set up NGS_DIR environment variable to point NGS to it's lib directory. The exception is only when the lib directory is installed in one of the hard-coded directories. This only allows one "main" installation which is easy to operate.

I see you chose GPL, which I'm a big fan of, however it looks like this is meant to run through a web browser?

If that's the case, with GPL someone can use the SaaS loophole to provide an implementation of this shell, while avoiding the copyleft protection GPL provides. AGPL works to fix that loophole.

An option to run external command in a specified directory:

• d="my_dir"; $(cd:d ls)
• $(cd:"my_dir" ls)

Hi,

I can't compile on Ubuntu 14.04.4 LTS.

$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for x86_64-pc-linux-gnu
$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling:

$ make
gcc -c -Wall -Wextra -gdwarf-4 -g3 -g -O1 obj.c -o obj.o
obj.c: In function ‘_encode_json_kern’:
obj.c:833:3: error: ‘for’ loop initial declarations are only allowed in C99 mode
   for(unsigned int i=0; i<OBJ_LEN(obj); i++) {
   ^
obj.c:833:3: note: use option -std=c99 or -std=gnu99 to compile your code
make: *** [obj.o] Erreur 1

I tried to add -std=c99 or -std=gnu99 in Makefile (CFLAGS). But it doesn't work.

Cheers!

HanXHX

Requirements

• Architecture-independent
• (probably) For inter-op with UI clients which run in the browser, one of the formats should be JSON based

Resources

• https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/basic-serialization.md
• https://www.baeldung.com/java-serialization

https://asciinema.org/

Have a look at my project for reference: https://github.com/d33tah/aflize

todo.txt is in the top level directory of the project

• Consider using init(ip:IP) constructor for this functionality.

• Installing different NGS versions - would they use same modules or each version of NGS will have it's own modules directory?
• What should be the modules directory/directories layout?
• Should require() support specifying the desired version? Maybe something as simple as require("my_module/2.5.1/blah.ngs")
• Should multimethods or methods be versioned?
• Should NGS support running different versions of the same module at the same time?
• Consider input in #17

See Module System Design

There seems to be no clear way to turn NGS source code into a tarball, and no PKGBUILD is provided.

While ngs doesn't have a cli, the normal ngs with no parameters should return some sort of help and not the errors and exception. This leads the user to think the ngs is not correctly installed.

Both forms should behave identically

should throw syntax error

Similar to Node.js

Note that currently requre('./my_dir/my_file.ngs') will be relative to current directory, not the directory of the file with the require() call. This is not intentional.

XhbflfdlcxoffoכמעעילנהנכנפנמжзпэвэпнппзръмаъвчспрпррриппзпппвчfggsgfcfdTryff

• As in other languages, an environment variable with sane default should be used.
• Simplify NGS_BOOTSTRAP and NGS_DIR to single search path

The author of this repo has reached out to fish shell contributors. This issue is a place to collect their feedback. (It's not really an issue per se, but I'm not sure if there's any better way to have a discussion.)

Currently executing $(my_option: external_prog) will silently ignore unknown options

https://github.com/ngs-lang/ngs/wiki/Wishlist

The formatting is screwed

Ideally the exception (and hence output) should include

• distinct indication that this is a syntax error
• problematic line
• context lines
• lines numbering
• arrow pointing to the error column

Challenges:

• Source file is not kept in memory after parsing

Guidance:

• Look at implementation in other languages

Current situation:

• The error position (line and column number) is displayed in a non-user-friendly manner

This sounds like there's an overlap with powershell.

Would be happy for a comparison in the README file.

... so that specific section could be linked to

In commands syntax should be straightforward as $(ls *.txt).

In code syntax, we should think whether to use special syntax such as <*.txt> or alike.

In any case, globbing should be implemented using the glob multimethod (which currently throws NotImplemented)

Some kind of roadmap or even a draft will be a very good guide to contributors, don't you think? :)

debug option, when running external programs should act as if NGS is running with "process" debug option was specified in DEBUG environment variable but only regarding the given process.

Also think about about "process2" debug option.

gcc -c -Wall -Wextra -gdwarf-4 -g3 -g -O1 vm.c -o vm.o
vm.c: In function ‘native_attr_pthreadattr’:
vm.c:1021:33: error: expected ‘)’ before ‘restrict’
#define ATTR ((pthread_attr_t * restrict)&GET_PTHREADATTR(argv[0]))
^
vm.c:1025:28: note: in expansion of macro ‘ATTR’
pthread_attr_get ## name(ATTR, &i);
^
vm.c:1041:2: note: in expansion of macro ‘INT_ATTR’
INT_ATTR (detachstate);
^
vm.c:1021:33: error: expected ‘)’ before ‘restrict’
#define ATTR ((pthread_attr_t * restrict)&GET_PTHREADATTR(argv[0]))
^
vm.c:1030:28: note: in expansion of macro ‘ATTR’
pthread_attr_get ## name(ATTR, &size);
^
vm.c:1042:2: note: in expansion of macro ‘SIZE_ATTR’
SIZE_ATTR(guardsize);
^
vm.c:1021:33: error: expected ‘)’ before ‘restrict’
#define ATTR ((pthread_attr_t * restrict)&GET_PTHREADATTR(argv[0]))
^
vm.c:1025:28: note: in expansion of macro ‘ATTR’
pthread_attr_get ## name(ATTR, &i);
^
vm.c:1043:2: note: in expansion of macro ‘INT_ATTR’
INT_ATTR (inheritsched);
^
vm.c:1021:33: error: expected ‘)’ before ‘restrict’
#define ATTR ((pthread_attr_t * restrict)&GET_PTHREADATTR(argv[0]))
^
vm.c:1025:28: note: in expansion of macro ‘ATTR’
pthread_attr_get ## name(ATTR, &i);
^
vm.c:1044:2: note: in expansion of macro ‘INT_ATTR’
INT_ATTR (scope);
^
vm.c:1021:33: error: expected ‘)’ before ‘restrict’
#define ATTR ((pthread_attr_t * restrict)&GET_PTHREADATTR(argv[0]))
^
vm.c:1030:28: note: in expansion of macro ‘ATTR’
pthread_attr_get ## name(ATTR, &size);
^
vm.c:1045:2: note: in expansion of macro ‘SIZE_ATTR’
SIZE_ATTR(stacksize);
^
vm.c: In function ‘vm_init’:
vm.c:1553:11: error: ‘ffi_type_complex_float’ undeclared (first use in this function)
FFI_TYPE(ffi_type_complex_float);
^
vm.c:1536:33: note: in definition of macro ‘FFI_TYPE’
vm->c_ ## name = make_ffi_type(name);
^
vm.c:1553:11: note: each undeclared identifier is reported only once for each function it appears in
FFI_TYPE(ffi_type_complex_float);
^
vm.c:1536:33: note: in definition of macro ‘FFI_TYPE’
vm->c_ ## name = make_ffi_type(name);
^
vm.c:1554:11: error: ‘ffi_type_complex_double’ undeclared (first use in this function)
FFI_TYPE(ffi_type_complex_double);
^
vm.c:1536:33: note: in definition of macro ‘FFI_TYPE’
vm->c_ ## name = make_ffi_type(name);
^
vm.c:1555:11: error: ‘ffi_type_complex_longdouble’ undeclared (first use in this function)
FFI_TYPE(ffi_type_complex_longdouble);
^
vm.c:1536:33: note: in definition of macro ‘FFI_TYPE’
vm->c_ ## name = make_ffi_type(name);
^
make: *** [vm.o] Error 1

Archived here (link)

• The choice of F is very weird! Can't you use lowercase fn instead?
• At the same time, you've got callable:Fun - please, make it consistent, and use fn and callable:Fn!
• Although local is familiar, the language is so vastly different than Bash that the shorter let would be much better!

Modules can theoretically be fetched over network. To make sure it's the intended module, there must be a way to specify how to validate the module.

This issue suggests supporting several hashing algorithms and checking the real vs expected hash value for this purpose.

To check: seen this stuff used on the web, don't remember how it was called at the moment