Releases: hypersoft/jse
The Hypersoft Javascript Engine
Vital bug fixes to previous release.
Buffers + Shared Libraries + Shared Functions + Ellipsis/VarArg + Callbacks
This should be enough to get you a decent test environment.
Please note: to accelerate development of this project, PLEASE CONTRIBUTE or FILE ISSUES! The capabilities of this project are so extensive, that the maintainer cannot possibly ensure bug-free-operation for every use case.
No API in this release should be considered stable or compatible with future versions. Code will be moved around and refactored as needed to ensure the best development of the coding environment where new bugs or logical errors in implementation are found.
The Hypersoft JavaScript Engine
Various bug fixes to previous release. This release has not been extensively tested, but is known to be extensively working.
Buffers + Shared Libraries + Shared Functions + Ellipsis/VarArg + Callbacks
This should be enough to get you a decent test environment.
Please note: to accelerate development of this project, PLEASE CONTRIBUTE or FILE ISSUES! The capabilities of this project are so extensive, that the maintainer cannot possibly ensure bug-free-operation for every use case.
No API in this release should be considered stable or compatible with future versions. Code will be moved around and refactored as needed to ensure the best development of the coding environment where new bugs or logical errors in implementation are found.
Locked 'N Loaded
You MUST install this version for it to work correctly.
See share/core.js for the (Platform) Native interface.
GHTML requires the -f FILENAME switch to load HTML docs. If you did not perform installation, JSE will not be available in GHTML. Otherwise, you have a JavaScript/C programming environment with GUI!
There are bugs and some missing features, which are yet to be determined, or already documented somewhere in the code-base.
If you need help, don't hesitate to shout at the issues page.
Happy Coding!
Hypersoft JSE Redstone v0.2.702
2,702 builds, 3 repositories and one day ago, this project set out to be best there is in GNU/Linux application scripting. Today Hypersoft is pleased to announce that JSE has broken the ellipsis "barrier".
Now you can call native Procedures that take a varying number of arguments. Number, and String types are automatically converted to 'int' and 'utf8 *', for your convenience.
Types can be "marked" for conversion (See: example/native.type.value.js) by using a type reference to cast the JavaScript values into a "Typed Object". This system is under revision, but the external interface is reliable, and can be managed without disrupting user applications that are built on top of the new technology.
Address will be modified in future versions, using the new type system to determine if array mode access and length are required for ** and * variables.
This FREE and OPEN software system serves as a primary means of income for its sole developer. Please consider donating via paypal at the time of writing, this project has raised $0.00
See also:
Hypersoft JSE Redstone v0.2.670
This build has been outdated by v0.2.702
Various changes have been made to the global environment.
echo() has been made a global command function, as its use has proved to be highly ubiquitous in various examples.
js.native has been relocated to native
native.setPrivate() has been added; Get/Set private functions only work with native container objects.
Various unused software components have been removed. Among those are:
- Tokenizer Example
- iStackMachine
A new type system has been developed. It appears we have developed a weak (but sufficient) attempt at native type prototyping. The new type system provides more script friendly means to accomplish native type tasks.
The examples have been re-organized and a README.md has been added. The examples in the wiki have also been updated to reflect changes.
See also: How to build JSE
Hypersoft JSE Redstone v0.2.528
This release is outdated by v0.2.670
The GNU C manual has been removed, and a few fixes have been introduced. I am confident in this APIs ability to maintain enough backwards compatibility to both be suitable and manageable.
I'm going to be diverting to a new branch that coincides with some general applications I will be testing. One should expect various bug fixes and perhaps some scripting API relocations in the new branch 'Redstone'. Please try to stick to the examples given in this release, and all should be well, or else you could be facing a serious case of find and replace to maintain compatibility with future versions.
When the general application programming rationale has been established, the "Operator's Manual"
will be on the table for production. Until then, sit down, strap in, and burn rubber.
See also: How to Build JSE
Philosopher's stone
This release is outdated with some corrections: https://github.com/hypersoft/jse/releases/tag/v0.2.528
I am pleased with this release. No ellipsis, struct, enum, or union, but these are all layers on top of technology we already fully support. This entire system is about providing an adequate means for user augmentation.
Highly untested. Look to the examples for instruction, look to the source code for wisdom, and look to your programming manuals for guidance. Look to your dreams for inspiration. Being "untested" is a merit of its own, you, the user are able to become the "top engineering associate" in your field by merit alone.
Understanding this system in its entirety is a great deal of work. But you don't have to do that. You only have to understand that it works, and figure out when and why it doesn't. Engines require tuning to run at optimal specification; you will be a Scientific Engineer.
Philosopher's stone
Fired the old procedure/callback APIs. They have been re-implemented, using more straightforward styling. Primarily the change is to promote sound coding logic, and allow for the possibility of parsers & transcoders to do minimalist work.
For the time being ellipsis calls have been "disabled". Elliptical arguments present quite the problem for a weakly typed system. We cannot simply "scan" the format string because not every variadic procedure uses a format string!
The solution in regards to ellipsis is any combination of the following:
* Mark each value with "conversion hints"
* Mark variadic types explicit "per-call" with an layered call invoke as such:
`function(type, type, type)(value, value, value)`
* Only support automatic conversions to bool, char, long, utf8 *, and double
Either way, ellipsis is looking really shitty to me from this vantage point. I want the code to look the way it looks in a C program whilst executing, so either we go automatic, or "type hinting", automatic is the only form fitting function. I think I will settle for automatic, supporting coercions through hinting where confusions are likely to crop up.
Also need to "crack the code" on dyncall's struct & union interface. With these additions, we will have a fully native interface provided we also implement enumerated values and (preferably) C header parsing.
Ironside
Ironside
This is the first release of JSE. While most of this software has been tested as it was built, this release serves as a base by which we can test real world applications, to develop real world solutions.
Everything in the standard JavaScript implementation (using webkit-gtk-3.0) is supported, as well as the GNU Seed being supported. GNU Seed will likely be dropped in future versions, favoring the loading/linking to this application through our native CallVM interface.
It is unknown whether development of this application should continue using Apple's WebKit. While I am impressed by their offering of a C interface to their software, it doesn't seem that they actually test if the software does what it says (callbackFinalize). From my analysis I would say the project is being maintained in a highly disorganized manner. In the very least, this release version will always be using the GNU/Apple WebKit-GTK 3.0 Interface.
There is a wealth of capability packed into this release and none of it is documented. The reason being that most implementations in this software correspond to a straightforward mapping to the underlying native interface. If you have questions, or would like some kind of example/tutorial written up on a topic of interest, let me know.
Structures, unions, and function callbacks (generic handlers) are really the only missing components to a complete native interface. Even though we don't implement them, any developer can still leverage technology by providing the application with a custom interface (via shared library) to any functionality required. Seed can also be used to implement such layers where needed.
I would like to know what you think of this release, and where you are struggling with it. I did build this software to help you out after all.... The problem is I am not a mind reader, and I cannot predict every application profile the software is suitable for. So if you feel like driving, I'll let you run the software development to a proper course if it is indeed beneficial to the project and does not inhibit the possibilities of future expansions, or waste time/resources on pointless methodologies that are better left as an exercise for the end user, who knows what their project needs better than anyone else.
Cheers. Hit me up.