Construction Note: I don't have time to fully update this page yet, but I updated this section title to the latest library evolution that I am working on. It merges encryption, encoding, OS objects and operations, user interface, content object types, and streaming. The objective is to fill in all that is missing in Ada for general use and programming custom applications. Support is intended for Linux, Microsoft OSs, Apple OSs, and FreeBSD, but it will start on Linux because it is not such pain to support Ada in Linux. Microsoft OS interfacing is not so bad, but working in their operating systems is bad. Apple is quite awesome, but my access to the latest OS is limited and Ada support is currently limited. FreeBSD isn't a priority. Android is a desirable target, but Ada support is limited there, too. Frankly, I don't control where Ada is the most useful for comprehensive user interface to back-end full applications. I just want to make such applications possible without having to fully create or hack code that was not made to generally support the purpose. GNOGA is getting pretty close to supporting something similar and may bridge the gap in making apps work on all operating systems, so I will probably be attempting to make EGSS work with GNOGA, eventually. Much more will be addressed when I get around to updating this page.
A few projects were merged into my own library, named after me for now. Password_Encode is now just Encoding in the Welf library and is a generic library so that it can be used to support any stream in any Ada program. I plan to make the Welf library available in C++ and maybe other languages after I finish it in Ada. This library is currently a collection of many generic libraries and a few types. It has a few companion packages that work best as separate units, but there is a dependency between them, such as my own Regular_Expression implementation closely modeled after PCRE in order to make using it more familiar and have a shallow learning curve. This page will be rewritten when I have the time to properly explain the packages, but few are: Text_Encoding, a generic, byte-by-byte Stream-supporting encoder/decoder for various text encodings; Scalable_Precision, a generic, fixed point number library that allows a specific Radix, a.k.a. Base, to represent numbers either per package declaration default, or on call with specific base. The features are extensive, in order to fix the gaps other libraries have in simple number processing - fractional exponents, any base up to 64 using Æ and æ instead of symbols to fill in the last two characters by default. A custom string of characters for number representation may be given.
This little encoding/encryption system is a way of hiding your valuable data with your own easy to remember password/key or keys. This was originally inspired by base64 encoding. Your variable length string of printable characters -- as long as you like -- is used as the key to shift a few bits at a time, then swap segments of the stream, then again, and maybe again, depending on how many password strings you give.
If you want more security, just have more passwords and make each of them longer. You could use a poem that you know you will be able to spell correctly in the future, or data you are familiar with, or a list of names or dates in an order significant to you. Whatever it is, it should be something you can remember so that you don't have to write it down where anyone could find it and you can use it without delay when you need to access your data.
The data is secured far better than any traditional shifting/Caesar cipher because a varying number of bits are shifted at a time, and then swapped. The effect is that if just a little bit of the password is off - a different length, a different letter, a different case - the whole data stream may still be garbage. Naturally, this is not as secure as great encryption, but if you want flat, portable, simple, and fast - cross-platform thumb-drive style encryption, this is it and no one will have access to the key but the person who encoded the data.
I am currently toying with the idea of a file with the extension "pnp" that will act as a wrapper around the encoded data, containing an encryption key, encoded by your password(s), the files with their file-names and size, and possibly compression. It could be a tar.xz archive or a Ada native library with whatever compression I have available or create in Ada. PNP stands for Password eNcode Package. The header should be a few bytes stating how large the key is, and what level of encapsulation or features are included. This way the exact size of the rest of the leading package contents can be determined. I am giving it some thought.
This is just a simple set of programs demonstrating how Ada can be used cross-platform a little like a shell script to setup an environment and launch the correctly modified command and arguments. These are better than a shell script because the same code works on any Gnat-supported platform, and as a static executable it runs better in each operating system without fancy dependencies than any shell script could.
This fixed the now old limitation of Windows Subsystem for Linux, where one could not call a Linux command directly while in the Windows environment nor pass environment variables to that command without tedious bash.exe -c "...." commands. All that tedious conversion stuff is taken care of in the bash.exe command wrapping of this launcher. This still has a ways to go to completion, since I haven't implemented and tested a layer of argument quoting the way it needs to be, yet.
This also fixes certain environmental issues with launching GPS. The GPS (Gnat Programming Studio) launcher needs to be customized to each system, but with most of the environment written out already, a few tweaks here and there are no problem. I have found this to be the most reliable way to launch GPS GPL from AdaCore, since mixing with a local environment potentially causes big trouble.
Are you tired of chromium not launching with a default user, or not being able to quickly launch a specific user's profile? or maybe you want to launch specific apps as if they were a native executable, which can be updated to pass arguments when Chromium better supports this? An Ada executable launcher does the trick. Calls to launch the app need never be aware that they are actually launching a web app through the Chromium executable!
Have you ever tried to use the very cool and versatile ffmpeg command line tool and stopped way short of your original intentions because it was just too tedious and time-consuming to write out all the options exactly? That is the difficulty of FFmpeg and what gives the advantage to graphical editors like OpenShot. So my plan is to fix that, and believe me this is an intense and large task to do as I intended. It makes all the ffmpeg option-typing seem like writing my name, comparatively. Still, I don't think we have to have a fully video and graphical powered interface with it's own learning curve to make simple audio/video modifications effectively doable for anyone. What we need is faster access to the pretty well documented options built into ffmpeg.
FFmpeg Composer is supposed to be graphical, but if it works better I can make it a VT100 (text mode) application. It will present a drop-down list in each of the command argument sections with which a user can select what options will be in that spot. when an option has been inserted within a section, then a new drop-down list will appear after it, but still within the section. Sections are (from my memory): inputs, Input handling & codec options, filter/transform options, Output handling & codec options, and format options and filename (five sections and the output filename - really part of the fifth).
I have considered what GUI I would use, but I still can't think of a simple one that is effective enough and cross platform. I am mostly favoring Kivy and GTK. GTK is made widely available with Ada and Kivy is very cross-platform.
Zsh is small, richly featured shell (a bit more powerful than Bash). It is more user friendly than most any other SH-compatible shell, but it is still a Unix shell, and it's brilliant modules don't quite make up for the abilities it lacks (but could have), that Ada has.
My idea is to make a simple, cross-platform, Ada/Gnat standard library based, but as Z Shell compatible as possible, Z Shell interpreter that supports more builtins and more Ada-like syntax. This is the latest idea and at the time of your reading this is likely not finished. It will involve some low-level and task centered programming that will stretch my understanding farther than ever before. Although Ada is cool and more powerful than Zsh, there are some system calls that might not be possible without interfacing with another language, which one should generally avoid in Ada, since the more foreign language calls, the more chance for non-cross-platform functionality and undesirable library dependencies. Update: As it turns out, Ada's terminal interface has both an unmanageable stricture and a runtime-bug in it that precludes even basic input control. It seems that I must do the reverse, making an includable library in Ada and a very slim shell in the locally native language that compiles with the Ada library. It might get complicated, but there is no way around the Ada Standard Library implementation issues except to avoid the corrupting portions.
Ideas from that I plan to make available in this new Zsh-like script include:
True, more accurate, native "delay" builtin
More readable end (...) statements similar to fish (a completely user friendly shell).
Super-fast native Ada functions that recursively perform the expansion of variable/command expansions.
One or two new variable types (for example "typeset -S" and "typeset -M" modeling "functions -M") that tie an associative-array-like variable to a function or math function, so an author can write nested functions as nested variables. This clears up to some extend exactly what is being returned and is much more clear about the handling of ASCII.NULL.
Similar to current Zsh syntax an extension to the "return" reserved word to go with the previous new variable type: consistent with Zsh builtin policy, the "--" will be ignored as an argument to "return" and anything that comes after it will be taken as the return array. Whatever the resulting words/arguments given to return will be the exact expansion of the new variable type.
Support for native JSON variables (-J). Inside braces, just like current recursive array/string slicing, recursive subscript/slicing works, but is special to JSON so that associative array rules apply for selection of object named components, regular array rules apply to JSON arrays, string slicing rules apply to strings, and no subscript/slicing is has meaning for integers and floats (like individual characters). Oh! and like I just hinted, integers are expanded and treated like integers and floats are additionally supported in the same way Zsh handles arithmetic syntax - if it has a dot or an engineering exponent "e" character, it is a float.
For now, run-time support for Ada/Gnat Regpat regular expressions. Possibly later, a custom run-time support for regular expressions will be added with support for full Unicode. *On most systems with Z Shell, PCRE is compiled as a module.
Proper compatibility with certain fish/Ada/Python syntax:
"loop" = "do", "begin" = "{", and naked infinite loops supported, as in Ada, allowing clear deliberate behavior of such.
Option to require ";" terminators (hence statement may be multi-line)
Option to require no terminators and use a Python/XLR style argument/block. This is not difficult for a scanner, and given the right text editors (3 or 4 space tabs, auto-indenting) this could significantly increase authoring efficiency. This would automatically enable certain builtins: "coproc" and "sub" (for sub-shell, not perl's function equiv). Also certain style change: heredoc's would require no terminator word, just a line with one less leading tab than the content's lines. Blocks following if, then, elif, and else may be terminated with one less leading tab, keeping if, then, elif, and else at the same level of tabs
Optional use of "begin", "{", "loop", "do" (essentially ignore them and treat them exactly the same as Zsh's "foreach" syntax, so that any block can be implicitly started by a statement-line terminator following structure or reserved words and ended with the "end" statement.
Optional "null" builtin (for Ada readability; of course ":" is identical)
Integral use of Ada 2012 support for UTF-8 and Wide_String internally.
Something similar to Ada's Gnat.Expect with Regpat functionality implemented as a builtin similar to Don Libes creation -- that is arguments to expect are to include pairs of regular expressions and actions/script-cod (suitable for builtin "eval"), a standard Zsh option terminator "--", and the remainder being the command and arguments to run. An method will have to be thought of for the print command to give the command input, like the "print -p" for coprocesses or a new one just for expect context.
Functionality for "coproc" that gives full management of that processes input/output/error to Zash so that it is no longer ambiguous exactly what and where that useful information goes when the command is started in a script.
A variable type that is actually a file type or a processor buffer. Whenever the variable is read from, all data from the processes output is read and the buffer is cleared
Use of a new environment variable, HASHDIR to convey default directory hashes that can be used similar to xdg directories for desktop sessions.
This is not an attempt to replace Z Shell -- I love Z Shell and re-writing the whole thing is not only more than I can possibly manage right now, but a bit presumptuous. I do hope that some of my ideas will be added to Z Shell, like the JSON variable type, the HASHDIR environment variable, the function-binding variable, and the extension to the "return" reserved word. My objective here is to learn Ada by working on a worth-while project. I don't want to spend time working on the full autocompletion or fancy terminal features of Zsh, even though those are among my favorites, because they don't have cross-platform Ada standard library equivalents.
By making this as cross-platform as possible, improving file-system path handling through variable expansion modifiers (like ":A" -> absolute path) and better path handling builtins, adding an efficient and quiet delay/sleep, and adding builtins for calculation-intensive tasks, I hope to make a monolithic, static, and portable scripting engine/interpreter that can perform many programming and shell-like tasks quickly. I also really want to be able to change syntax styles so that code can be more readable per needs of the situation. Python is a little foreign to SH script, but the the block starting and closing is certainly something that can cross over. Also, most programming languages and many scripting languages don't care about newlines or whitespace. As sophisticated as Zsh script is now, I think it would be even better if we didn't have to limit the statement structure to SH-compatible statements. Zsh uses it's own syntax and builtins anyway, so there seems to be no reason that we can't just do whatever works best for the situation regardless of SH-compatibility.
Zash should be an execute-as-you-go style interpreter. The active scanner procedure is whatever procedure corresponds to the context: regular reserved-word/command-word search, condition argument search, math argument search, heredoc end search, declare argument search, quoted argument end search, and argument search. The scanner updates the global current index of the string buffer that contains the current script/function as it identifies one character/word at a time and decides the appropriate thing to do with it. It will dynamically call internal expand functions for variables and expansion syntax when it comes to them, so theoretically embedding variables in variables should work to any depth in the expansion order expected. Also, I considered using Bounded strings and types for this script - similar to scripting limitations you might consider with Fortran, but that is just not flexible enough for the Zsh syntax target, so I will favor making Bounded variables types for speed with a new option to typeset and use Ada's indefinite containers for the ordinary variable strings.
This approach is more difficult to debug and will glitch an entire script if it hits a snag early in it, but it also make the scanner/interpreter more efficient and allows dynamic composition and use of aliased commands with slightly more flexibility than Zsh actually has. It also allows the author to change syntax style in between command statements in the middle of a block. This raises another consideration: the syntax styles are incompatible, so switching to say Python style, where the number of tabs indicates the depth of embedded statements, the depth will have to be calculated dynamically and within the context where the style is declared. A change in syntax style cannot change the syntax style for the enclosing command/structure statements. These particulars are something to work out, but I think the result is worth it, because I want it to work a little like a virtual machine in its efficiency (hopefully faster than C# or module based scripts, because of the OS caching the script interpreter executable).
Small is great for simple task from startup to the start of the user session, but this is not to replace existing great shells, so an executable that is a few megabytes or more is fine. Unless it became a popular scripting system with dozens of scripts running, the monolithic nature is more of a do-anything-at-anytime advantage than a fault.
This is a direct result of starting Zash. As it turns out, I needed a way to facilitate the line-by-line interpretation that doesn't get insanely complicated. I borrowed some of the language component identification techniques from Bluefish Editor, which I have contributed to and is awesome. My language scanning is dependant on Access types and thus will not work on small embedded systems, but it wouldn't be very usable there anyway. This library allows switching languages or turning on or off language components on the fly. It can be used to create a language structure for colorifying editor text and making editors "understand" the context and special meanings of structures dynamically. This gets very complicated, so I had to make this Zash-independent library to deal with the whole change-how-you-scan-while-scanning problem. Also, it had to be something that can be modified without corrupting whatever language interpretation you start with as changes are made (self-healing).
To that end, I made a library (still working on it) that can rapidly switch between languages without changing their configurations, and thus accommodate embedding entirely different languages within each other (like the heredoc Perl or Awk script). Also, unlike the super-fast Bluefish Editor's language scanner*, this uses true Regex pattern recognition, layered in stacks, like Nano Editor does for it's language scanner, only Nano can't change dynamically and can't understand context.
This doesn't have a proper name yet, it is just a collection of log programs to completely manage my various records in the computer more efficiently, and as a necessity, it required that I develop my own replacement for Readline and Ncurses, both of which are tied down by licensing and the C language. They are both better and more cross-platform supported than I can hope to match, but for basic terminal functionality with color, VT100, xterm, Linux VTs, and Windows Console (with vt turned on) my tools will be able to present lists, accept keyboard input, and in some cases even mouse input, so that I can accomplish about the same thing as what the readline and ncurses most-required features make possible. I haven't named the Terminal library yet but internally it is called Terminal and the attachment to the Console is a private, protected type called Console_Type, so that it is mostly task safe. Widgets are created by simply declaring them and can be arranged by changing the the stacking order (brought forward or pushed backward). The stacking order is also used to identify which widget has focus and which widget is to receive input created by a mouse (clicks don't always happen inside the top-focus widget). So essentially this is a widget windowing environment for Terminals with fixed character-cell blocks, with applications using these features to simulate a GUI for better personal log and record management.
ZUC is both it's own project and a component project for EGSS. It is makes it possible for EGSS based applications to compile and work smoothly on different visual systems (TTY terminal, Linux Framebuffer, Wayland, Xorg, Win32, WebUI, etc). Everything will depend on Unifont, otherwise many simple concepts would become as chaotic as a bad webpage in an obsolete web browser. Better font support is good for publishing applications and word processors, but for real applications that would be written in Ada, the limitations of Unifont are a less complicated benefit.
This is a planned Graphical console to replace Windows Console, Terminal emulators, and too-constricting Linux terminals. With modern frame buffer access in Linux, and wonderful GTK canvas support, it should be possible to create the foundation for raw drawing of the text represented by text programs, only using Unifont in order to guarantee full Unicode support and eliminate font support issues. This means for text interface programs that graphical Unicode characters will actually work reliably and that display of the text buffer should be fast-unimpeded by any font issues. This also means that when graphical images and fonts are meant to be used, they can simply be drawn, with the number of text cells being consumed fully accounted for. This also means that a custom technique for asian/other wide characters can be used so that the appropriate number of cells will be consumed there as well.
Honestly, I don't know why this kind of project hasn't been started much sooner, but since I plan to make it, I may as well make it integrated with my other programs, like Zash and Log Management, as well as providing some support for a macOS-like menu bar and application launcher. Apple operating systems and OS/2-based operating systems are possibly the only ones I consider successful at implementing objects for managing a system instead of just presenting the user with files and operations to perform. presenting objects as well as file information, seamlessly integrated, is the best and most efficient way to work. This is how I can present information using my coding libraries.