I think it refers to the possibility that several programming languages compile to an intermediate code, and that this is interpreted or compiled to the target platform. Something similar to what Java’s Bytecode or .NET’s IL does. If that’s the idea, then I like it.
1 Like
Just gonna pop in here with two cents:
- regarding configuration files, I have taken a liking to how the Linux bootconfig works. It’s a good, object-oriented, simple configuration file format that’s flexible enough to take multiple argument styles, but rigid enough to know it’s a key-value store.
- regarding shell UI/UX: I’ve always had this idea of doing a shell as “Scratch, for adults.”
The gist of it is, you can freely enter commands line-by-line typed out, and they’ll be parsed into blocks transparently as you go along; or, you can attach together blocks to specify the operation that you’re performing, with transparent documentation and a menu or “library” of available commands to pull from.
This format would save to plain text, and be parsed into command blocks; or be saved as a compact token/AST form, and “reconstituted” on the fly.
Either way, it’s intended to be accessible to newcomers or less-experienced computer users, while not getting in the way of people who intend to program scripts for the shell like the way they’re used to.
Side-note: I’d prefer to move away from “sh”-suffix names for a Haiku shell, especially if it’s not strictly compatible with Bourne or similar shell scripts.
5 Likes
Regarding all the talk about compiled code - I think a tokenized format that calls to precompiled code fragments, or “gadgets”, is better than a true codegen/JIT proper, especially for security and traceability of the code. I’m thinking like TCG from Qemu, or the “pseudo-JIT” codegen used by iSH. These are very similar to the “ROP” techniques, infamously used by hackers - but, to our benefit, in order to reduce the overall complexity and security boundaries necessary to support this shell language.
You would have very performant high-level code generation without the need to generate code and violate W^X enforcement.
1 Like
@sirocyl
You’ve hit the nail on the head! An AST bytecode is what I have in mind! There are plenty of tools that will compile later, if that’s needed, but something like “Scratch for adults” should be the editor.
If we do UI automation, we should probably consider namespacing and identifying specific UI elements in terms of code, in a way that’s less liable to breakage. I’m thinking along the terms of AppleScript and Automator, on that end.
One UI puzzle that could be solved for automation tasks, is a drag-and-drop “connector” line, which you pull from the shell window to a specific UI element, and then that element is referenced into the code transparently.
No, I’m not talking about a node-based scripting environment (like Quartz Composer, Blender’s node graph UI, or Unreal’s Blueprint system) - I’m focusing more on a “lego”, agglutinative series of code and function blocks, which can themselves contain code and function blocks.
1 Like
Once the bytecode is designed, different representations of it can be experimented with. Object oriented programming lends itself to code reuse already. Only variable names, function/method names, class names and comments are required to be text.
Dear @Null ,
You made me laugh, man – I was really long time ago laughed so mush and long meanwhile and after I was reading your lines about shell scripting (of Unix/ Linux?).
Seems you do not like and take it a mess if you would have some learning curves to acquire well.
Well, I cannot speak about python as I had not learned at all just as perl as well – I’ve just used them if they were available for a specific task – in the past as admin.
So for shell scripting or the simpliest version - the command line – I liked so much as commands were small buider stones that you can combined them you cuold get your results in the layout as you wanted : formatted lines on screen , redirect them into a file, or both thanks to another command, or just a simple value from hundreds or thousends … just what I was looking for …
I’m terribly sorry if it was really a mess for you … for me it was kind of magic. I(t helped me a lot in my work.
I constructed once, saved, even copied to/from remote servers via terminal, meanwhile for binaries I had to establish an another way to move with ftp, scp whatever to use them. Moreover I could use them again later - simply tailored for another server or envcironment as well.
For now - I forgot a lot about syntaxes, and on Haiku commands are differents as those I was familiar with, but yes I use command lines here as well. I still had not written shell scripts, but used them - look at old Wifi firmware installers - for example.
For me, if it would be added something to shell it would be better an administrative tool like SMiT or precisely smitty is in AIX or YaST was in SuSE Linux … a centralized tool to administer all kind of areas : network and its parameters, sorage, mounts, installs, etc
you don’t need to know all the parameters, as you fill up the changable values and all other paremeters were asked by human readable questions where you could select and/or chose among them.
Finally you could execute them, but also the tool showed the constructed command and you could see it and copy it for later use in shell scripts. We used it to generate template command lines, put into an excel file, multiplied and exchanged the parameters where it was needed to give appropriate names, values, switches or filesystem paths. Who was better in awk - they skipped this excel step and they used awk and input file(s) for the same task.
Anyway, I loved the idea of Irix’s 3D shell I 've just seen in a movie ( about the re-created dinos 
) The kids used an SGI machine to control the locks and others with it.
And of course the hipothetical console decks of Gibson, where the console cowboys got into the virtual reality of net via such decks, those rendered a 3D image of the cyberspace into their brain implant (as contact) and their nerves. This way “surfing” was a full body experience and work or infiltrating was story-like … like participating in a 3d game or Second Life.
I do not expect we would shake our hands or do gestures when instruct Haiku in native shell, but dictation and speech recognition would be welcome 8D
Continuing with the concept of bytecode, transpilation and translation, I have a question for @SamuraiCrow
It’s just a vague idea… Could it be applied to the rest of the operating system?
I’ll give you an example:
I’ve always liked COBOL. But COBOL is not a widely used programming language. You can find it on mainframes, but it is rare on desktop machines. I’ve always been frustrated that I couldn’t use it more often. There are things like GNU COBOL, but it’s not a real compiler: it “just transpiles” from COBOL to C, and GCC creates the executable (it only accepts COBOL 85 code, and it’s not fully compatible).
Looking for an alternative, I found LDPL. It is a programming language strongly inspired by COBOL, but more modern (it is more similar to COBOL 2002). In this case, LDPL uses a transpiler, which creates a C++ output. Any C++ compiler installed on the system can be used to generate the executables.
The fun part is that you can use any LDPL or C++ library as if it were native.
That brings me to the next question: Could a transpiler or cross-compiler for the Haiku API be created from other programming languages?
The idea is to use LDPL to create native applications, using the same .h files as any other C++ application.
Now imagine crazier transpilations: from CoffeeScript to C++, using the same .h files to create native applications.
Same API.
Sound crazy?
1 Like
But isn’t that something different than a shell? It’s more a registry-like DB and a single shell-tool to access it, or? (Like for example hey is a single shell-tool for GUI-manipulation.) And for Linux folks: I’m a YaST fan, too.
It’s a bit out there, to me. The better target imo would be something similar to webassembly, NaCl, or a similar VM engine; and having native tooling from that, with a foreign function call interface - where one would compile a very basic shim library of the C header in question, and calls to the library from within the VM would be instanced as if the VM included said library. I think Java/JNI does this, on Android, and there’s probably examples of this on C#.
Also, that’s a bit outside the scope of topic here - relating to a shell, all of the above is quite overkill, and a simple token/gadget-oriented call-generator patterned code language should suffice performantly.
1 Like
Yes. Many ISVs provide services that can help you in that goal…
Yes, I know it’s a bit out of context, but it’s still an interesting concept.
After all, what we are discussing here is basically a new terminal with API access.
If you think about it “out of the box”, that same idea can be applied to the rest of the system.
It could save a lot of work in creating bindings to other programming languages.
It seems I’m not at line with you folks. But wouldn’t Swig solve that, so that any programming language could bind to the Haiku API (and any other API in the software system)?
LOL,
I hope you informed all the guys (and ladies) they use Rexx on OS/2 or today version Arca OS -
that language is dead …
do not develop new versions, maintain it !..
Holy $h1T !
How much 1 specialized people … I would pay attention to white areas those may have upon my knowledge … before I let out such a steep statement …
That was in the context of AmigaOS. The AREXX implementation was designed poorly so new versions couldn’t be designed for Amigas.
1 Like
You could express that a bit more polite!? Apart from that, it’s true. If Rexx is cool, we could try to implement it, or?
I was about to say, I think IBM mainframes still pull REXX from time to time. It’s quite the dead language overall, as it doesn’t get much use outside of legacy or hobby.
Was it AREXX that had static memory addresses that had to be updated with every Workbench, for it to be able to call into AmigaOS and its library?
ARexx had the runtime rexxsystem.library, which was designed to have a fixed size of 22KiB and Commodore didn’t pay the author to update the code (if they paid him in the first place).
1 Like
Well, “shell” the GUI also but that is a graphicall shell.
As the shell what enables user to instruct or interact withe core of OS the kernel.
It just a massive misunderstanding that when people talks about shell and immediately thinks about only command prompt.
It is natural as because another member here pointed it – it was before the young ones started to toddle and licking their thumbs in their baby (rolling) bed.
Another observation - yes it is an admin tool as me myself also wrote. That and the mentioned stuff were missing from actuall Haiku shell – graphical or not – for me.
Without any kind of shell you could not interact with your machine aka use it.
What about the switches on the PDPs? I dont know what they do and how they work but it seems they are hardwired onto memory banks or registers. Switching them are kind of communication with the system, right?
Just like the hw buttons, ACPI events on modern systems.