Adding JavaScript support for mORMot framework

jonjbar · 2014-11-19 16:33:47

Is it possible and how to register an object method ? I tried the following:

  Engine.RegisterMethod(Engine.GlobalObj,'blog',dummy_method,0);
  Engine.RegisterMethod(Engine.GlobalObj,'blog.article',dummy_method,0);
  Engine.RegisterMethod(Engine.GlobalObj,'blog.article.create',blog_article_create,1);

But then I get the following error:

> blog.article.create('test');  // <-- Error: blog.article is undefined

I believe both "blog" and "blog.article" should be registered as objects but I do not know how this can be done.
Any help would be greatly appreciated.

mpv · 2014-11-20 12:31:48

You want to reproduce this JS code:

var blog = {};
blog.article = {};
blog.article.create = function(){ ...}; // warning - never use keywords as a object property names

or the same but in JS way

var blog = {
  article: {
    create: function(){....}
  }
};

Then Delphi code is:

  
var
  blogObj: TSMObject;
  blogArticleObj: TSMObject;
.....
  Engine.NewObject(blogObj);
  Engine.GlobalObject.DefineProperty('blog', blogObj.AsSMValue);
  Engine.NewObject(blogArticleObj);
  blogObj.DefineProperty('article', blogArticleObj.AsSMValue);
  Engine.RegisterMethod(blogArticleObj.obj,'create',blog_article_create,1);

when you use

  Engine.RegisterMethod(Engine.GlobalObj,'blog.article.create',blog_article_create,1);

you define method with name 'blog.article.create' in global object. For call it you must use

> global['blog.article.create']('test)

jonjbar · 2014-11-20 13:28:41

That's exactly what I wanted. Thank you very much mpv!
Should I take care of freeing the TSMObjects (e.g. blogObj.free) when the engine is freed or are they owned by the engine ?

Orel · 2014-11-20 13:52:37

You shouldn't. TSMObject is not instance of class. It is not allocated in heap but in a stack. You do not allocate memory for it so you shouldn't free it. JS object will be freed by the garbage collector when the reference count on it become equal to 0.

jonjbar · 2014-11-25 11:27:26

Thank you Orel!

sh17 · 2015-10-07 07:50:44

Any news on this project? Win64 Support,...Does it make sense to update to the latest version of SpiderMonkey?

mpv · 2015-10-07 18:32:00

We are working on SpiderMonkey 38 version. But mozilla team decide to migrate from C to C++, so we need to write a huge number of wrappers. Win64 version of SpiderMonkey itself is just for toy, very slow and unoptimized, so no plan to support it. But even with SpiderMonkey 24 you have many ES6 features, arrow function for example. Class suport not implemented in SM release yet.

edwinsn · 2015-10-08 14:56:53

@mpv, PS, looks like http://duktape.org/ is much simple and easy to make a wrapper, and I'm quite sure SpyderMonkey is much full-featured

Hanfusheng · 2015-10-27 03:52:34

@mpv
great job to move spidermonkey 2 omORMot! thank you !!

and
"- Third – implement CommonJS Modules specification and node.js “fs” module (it’s easy) – this give us possibility to use huge number of node.js modules."
is it compelete?

mpv · 2015-10-27 19:02:38

@Hanfusheng
It is compelete, but not ready for publishing. My software use mORMot version 1.18.282, current trunc is 1.18.2017.
Last week (my vacation) I'm trying to migrate to 1.18.2017...... But work still in progress..

edwinsn · 2015-10-28 12:36:36

@mvp, that sounds exciting! How much node.js module we'll be able to use with that addition?

mpv · 2015-10-28 13:41:53

On npmjs there is 199 292 packages. I really do not know how much of them will work. It's depend on dependencies they need. If package depend on native binding provided by node executable (crypto, buffer, tcp e.t.c) we do not able to use it )unless we implement the same binding in Delphi)

Hanfusheng · 2015-10-29 05:42:12

@mpv
that sounds exciting!
Looking forward to meet as soon as possible !

UserIdx64 · 2015-10-30 03:16:35

@mpv Can you please write an example how to use Delphi native function and object in mORMOT Javascript? Currently, the SynSMSelfTest.pas does not completly implement "procedure NativeFunctionsAndObject;" yet.
Thank you very much

Last edited by UserIdx64 (2015-11-11 02:04:22)

Int · 2015-11-18 22:48:52

Hello! I'm searching for JS interpreter for Delphi or FreePascal/Lazarus. So I found that project and this forum but I still don't understand a few points:

- can I use only js-engine without whole framework?
- how strictly is it bound to version of SpiderMonkey?
- are you going to support Ecmascript 2015 (ES6)?
- do you have separate repositories for js-engine project and whole framework on GitHub (or any other alternative)?

I'd be glad for some Hello-World example of js interpretation. I've found [http://synopse.info/files/synsm.7z] this binaries, but I didn't find sources for that.

mpv · 2015-11-19 07:37:14

Int wrote:

- can I use only js-engine without whole framework?

Yes, you can use SynSM* without whole framework - it require only SynCommons & SynLog to work.

Int wrote:

- how strictly is it bound to version of SpiderMonkey?

Very strictly. Only SM24 supported for now

Int wrote:

- are you going to support Ecmascript 2015 (ES6)?

Yes, we work on porting to SM38. Full ES6 support not ready yet in SpiderMonkey. Current status is here: https://developer.mozilla.org/en-US/doc … in_Mozilla

Int wrote:

- do you have separate repositories for js-engine project and whole framework on GitHub (or any other alternative)?

No, there is no separate repository

Int wrote:

I'd be glad for some Hello-World example of js interpretation. I've found [http://synopse.info/files/synsm.7z] this binaries, but I didn't find sources for that.

If you want to buils mozjs.dll - instruction is here: http://synopse.info/fossil/artifact/ddc … eed30d61b5
You can found usage sample in Samples\22 - JavaScript HTTPApi web server and in SynSelfTests.pas

Last edited by mpv (2015-11-19 07:42:42)

ab · 2015-11-19 09:25:06

Also ensure you read http://synopse.info/files/html/Synopse% … ml#TITL_79 chapter in depth.

Int · 2016-02-23 07:30:03

@mvp

Is there an opportunity to pass TSMObject to a function and receive another TSMObject back.

Now I can see how to do something like this:

// pascal:

function js.test(const This: variant; const Args: array of variant): variant;
begin
    Result := Args[0] + Args[1];
end;    

...

Engine.RegisterMethod(Engine.GlobalObj, 'test', test, 2);

...

// js:

test(1, 2) // -> 3

It works fine so far. But I'd like to be able to work with objects. E.g.:

// pascal:

function js.test(const This: variant; const Args: array of variant): variant;
var
    obj, resObj: TSMObject;
    num1, num2, res: Integer;    
begin
    
    // get properties:
    obj := {some magic...} (Args[0]);
    num1 := obj.GetPropVariant('num1'); // not sure about syntax here
    num2 := obj.GetPropVariant('num2'); // not sure about syntax here

    // logic:
    res := num1 + num2;

    // set result:
    Engine.NewObject(resObj); 
    resObj.DefineProperty('result', res);
    Result := resObj;
end;    

...

Engine.RegisterMethod(Engine.GlobalObj, 'test', test, 2);

...

// js:

test({num1: 1, num2: 2}) // -> {result: 3}

And by the way is it possible to pass a callback to function? E.g.:

//js:
test(1, 2, function(res){console.log(res)})

Int · 2016-02-23 07:35:07

I've read a chapter (http://synopse.info/files/html/Synopse% … ml#TITL_79) but an example from there doesn't seem to work in my case:

function TMyClass.MyFunction(const This: variant; const Args: array of variant): variant;
var global: variant;
begin
  TSMVariantData(This).GetGlobal(global);
  global.anotherFunction(Args[0],Args[1],'test');
  // same as:
  global := TSMVariantData(This).SMObject.Engine.Global;
  global.anotherFunction(Args[0],Args[1],'test');
  // but you may also write directly:
  with TSMVariantData(This).SMObject.Engine do
    Global.anotherFunction(Args[0],Args[1],'test');
  result := AnyTextFileToSynUnicode(Args[0]);
end;

Maybe that to run this code I need specific version of Delphi.

ab · 2016-02-23 17:28:02

Did you take a look at the regression tests?
See https://github.com/synopse/mORMot/blob/ … tSynSM.dpr

Int · 2016-03-08 17:16:25

I'm back. Sorry for disappearing. I was wrong about the example - it works fine.

I faced a problem with big numbers:

Math.pow(99, 999);

this simple JS code leads to crash application.

In any other runtime (chrome, ff, node) it works fine and returns Infinity; Is it possible to avoid crashes in such cases?

Important note: this post is really helpful http://synopse.info/forum/viewtopic.php … 072#p10072
Without these changes even this code:

a = 0xFF000000

crashes app.

Also I tried to build mozjs-24.dll (it's really not much easy), and finally I've got binaries but wrong one. Could you please tell which flags did you use to build dll? Or any difference from https://developer.mozilla.org/en-US/doc … umentation It'll be useful for ones who decide to build their own binaries.

Are these http://synopse.info/forum/viewtopic.php … 201#p10201 RTTI features available already. An opportunity to write something like

var inst = new TMyClass();
inst.write('some arg');
inst.myProp;

- seems exiting for me.

Which RTTI features are implemented already?

I feel that I need more documentation First of all I'd like to see a list of provided features and the nearest plans to understand what can I do with mormot and what do I need to implement by myself.

Now I'm trying to migrate my little project from delphi-javascript. But mostly I'm explore features of mormot's spider monkey bindings. So may be I'll be able to contribute somehow.

mpv · 2016-03-08 21:24:10

1) There is no problem with Math.pow(99, 999) in JS itself (in case you set a valid FPU). May be you try to get a value from JS to Delphi as a number ?
2) Do you build mozjs using this instruction BuildInstruction.md ?
3) We implement ability to expose a Delphi classes to JS using "new RTTI" in our project, but don't publish it to mORMot repo. AB wants mORMot to be compatible with Delphi7/FPC, in which no "new RTTI"

mpv · 2016-03-08 21:41:36

On the low level everything is ready for "classes" in current mORMot trunk - see unit SynSMSelfTest.pas: TTestSynSMAPI.ExternalObject for sample. To add a "methods" all you need is to use JS_DefineUCFunction inside a TestClassConstruct.
I think we can try to split our code onto 2 part: without "new RTTI" and with. But we need a time (mostly to write a docs/samples). I'm on vacation now, I will review my codebase after 14 march and note results here

Int · 2016-03-09 01:17:55

1) Could you please give a bit more information about setting a valid FPU? I don't think I try get value from JS.
For example this code res := fEngine.Evaluate('(Math.pow(99,999)==1)'); crashes with "External: SIGFPE" (in Lazarus) - so I suppose in my case the problem is about valid FPU.

I like the idea of compatibility with Delphi7/FPC by the way it was one of the reasons to switch to this project. And as far as I know that means no full RTTI features. But what about using TypInfo unit to access published properties in run-time?
Or may be there are some disadvantages related this way? Is there any kind of API wrapping such features?

How deep SM units integrated with Mormot? What do you think about forking into separated project? It might make development (and using) of SM wrapper easier for people who don't know mormot.

mpv · 2016-03-09 08:36:11

About FPU - In case of your code FPU flags are setting automatically inside TSMObject.Evaluate - the first line is TSynFPUException.ForLibraryCode wich call TSynFPUException.VirtualAddRef and inside this procedure System.Set8087CW called. But we never test this realization under FPC. May be the problem is inside FPC's Set8087CW ? Please compare delphi & FPC realisation - I don't have FPC on hand.

We do not see a reason to fork a SM to separate project . Inside we use many beautiful code from SynCommons & SynLog, AB added Variants support etc. In fact you do not need to know full mORMot, just a low level SynCommons. And yes, some TypeInfo wrappers is also inside SynCommons (my lovely GetEnumNameValue for example)

Int · 2016-03-09 12:14:26

I've found a solution for Lazarus crashes with Math.pow!

SynCommons, line 44185:

{ TSynFPUException }

function TSynFPUException._AddRef: {$ifdef FPC}longint{$else}integer{$endif};
begin
  if fRefCount=0 then begin
    fSaved8087 := Get8087CW;
    Set8087CW(fExpected8087); // set FPU exceptions mask
  end;
  inc(fRefCount);
  result := 1; // should never be 0 (mark release of TSynFPUException instance)
end;

There is this code in mormot. I've found this article http://wiki.freepascal.org/Lazarus/FPC_Libraries I didn't read it completely but there is a line

Set8087CW(Get8087CW or $3f);

So.. I tried to change code to:

SynCommons, line 44185:

{ TSynFPUException }

function TSynFPUException._AddRef: {$ifdef FPC}longint{$else}integer{$endif};
begin
  if fRefCount=0 then begin
    fSaved8087 := Get8087CW or $3f;  
    Set8087CW(fExpected8087); // set FPU exceptions mask
  end;
  inc(fRefCount);
  result := 1; // should never be 0 (mark release of TSynFPUException instance)
end;

And it's worked out. Now in my case Evaluate returns +Inf as I expected!
It would be great if you take a look at the article, because I'm not sure if this solve the problem completely and in a correct way.
The final solution might be something like

fSaved8087 := Get8087CW{$ifdef FPC} or $3f {$endif};

ab · 2016-03-09 13:56:34

I suspect this is the fExpected8087 field which should be modified, not fSaved8087, which is a backup slot!

Int · 2016-03-12 12:05:02

@mpv Are you going to maintain SM24 as JS-engine or to switch to the newer version of SM (or may be v8 or another)? What is the future of this project? Have you already made any progress in wrapping SM 38?

mpv · 2016-03-12 13:13:58

v8 integration is very hard - it written on C++ and we need to wrap almost anything to use it from Delphi. This is a huge work. SM (starting from version 24) is also migrate to C++ (and become slower ) - but at last we know how to deal with it. We create a "test" wrapper for SM38 but stop this work yet. Since nothing interesting in SM38, we decide to wait for SM45 - this release will have a FULL ES6 support (the main feature we need is "import" and "class"). 100% I will migrate my main product to SM45 and contribute SpiderMonkey 45 wrapper to a mORMot.

Int · 2016-03-12 13:55:08

How soon is it going to happen? A didn't found SM45 release date so far But the question is more about your work on the wrapper. How long might it take to wrap whole api of SM for Delphi? What about compatibility between current version and coming (based on SM45)? Are you going to provide the same api of wrapper?

mpv · 2016-03-12 15:23:57

Yes, SM45 is in beta now. We expect a SpiderMonkey45 release in April 2016, and I plane to wrap it till Jun 2016. But every new version of SM is a big braking changes You can read, for example, SM 38 release notes, so I'm sure we also will have a braking changes on the low-level (SynSMAPI). But in the Hi level (SynSM) we will try to break as little as possible. My current project codebase is huge, so I'm not interesting in braking changes at all. But can't give any guaranty.

In any case SM24 is very stable.

Last edited by mpv (2016-03-12 15:27:58)

Int · 2016-05-22 12:45:57

@mpv, SM45 - is released (https://developer.mozilla.org/en-US/doc … eleases/45)! I'd be glad to hear if you have any plans of wrapping it! Or maybe you've done a most of work already! I'm so excited to know!

ab · 2016-05-22 12:56:33

@Int Sounds like SM45 is not released yet - your article is a temporary uncomplete release notes draft for the upcoming SM45.

Int · 2016-05-22 14:22:12

You're right, sorry

mpv · 2016-05-23 11:41:40

It's released 2 month ago. This is usual situation for Mozilla to keep a release notes in a draft stage
We are working on migration - almost all is finished. Since API is incompatible with SM24, we decide to create a separate units SynSM45/SynSMAPI45.

edwinsn · 2016-05-23 13:40:42

mpv, that'll be a very good news！

BeRo1985 · 2016-06-17 11:00:11

Hi guys,

I've started a new BESEN branch https://github.com/BeRo1985/besen/tree/experimental where I'll try to solve the performance problems of BESEN (where BESEN will be then API-incompatible to the current old master branch version), and the I'll try update BESEN to ECMAScript 2015 & 2016.

My planned steps are:

Getting rid of TBESENValue big-record, the performance lack no. 1, and replacing it with LuaJIT-style NaN-tagging.
"Deoptimizing" the another whole code to naive non-optimized code back (but keeping the then new NaN-tagging Value container concept), so that the next step and the over-next step will be easier to manage then.
Adding support for the newer ECMAScript 2015 & 2016 specifications.
Optimizing the code again, but now in a better way, including a better function-call-frame-activation concept, what is the performance lack no. 2 at the current BESEN version, where I was too verbatim to the ECMAScript 5th Edition specification, so that it passes all official test cases overexemplary, but at a cost: very slow execution performance at function-calls.

Because I've started BESEN at that time, because I wanted, that the ObjectPascal ecosystem has a own fast ECMAScript implementation, and that stuff with SynSM doing now hurt in my eyes, so I must act now and lift BESEN to a new level.

Benjamin 'BeRo' Rosseaux

ab · 2016-06-17 11:40:37

@BeRo
We are looking forward at the new implementation!
A pure pascal implementation of JavaScript is always a great project!

BeRo1985 · 2016-06-17 13:31:42

My NaN-Tagging / NaN-boxing throughts so far:

Layout of a IEEE 754 double-precision binary floating-point format:
1 bit sign
11 bit exponent
52 bit mantissa
NaN => all exponent bits set and mantissa != 0, where the last bit of the mantissa sets, if it is a quiet or signalling NaN
Inf => all exponent bits set and mantissa == 0
For NaN tagging/boxing, BESEN will using 51 bits of the 52 bits of the mantissa and the 1 bit sign for to have 52 bits again for the payload
Linux on x86_64, Win64, Solaris and Irix have following policies with the address spaces:
https://msdn.microsoft.com/en-us/librar … s.85).aspx
https://docs.oracle.com/cd/E19127-01/ul … 892-12.pdf
http://menehune.opt.wfu.edu/Kokua/More_ … /ch01.html
https://web.archive.org/web/20090405235 … /ch01.html
In short as summary:
- Microsoft guarantees 44 bits of process address space, 8 terabytes (7 terabytes on Itanium-based systems)
- SGI guarantees 40 bits of process address space
- Sun/Oracle guarantees 43 bits of process address space (in Solaris the stack points into the negative address space at $ffff..., but I don't care as BESEN values will never point there)
- Linux doesn't document this rigorously, but testing shows that it allows 47 bits of address space (and current x86_64 implementations are limited to 48 bits of virtual space anyway)
So I'll choose 48 bits as the conservative compromise for our address space room for the BESEN values, where normal numeric values are just normal doubles, and otherwise all other things NaN-boxed/NaN-tagged pointers inside a Signalling NaN double value.
And Signalling NaN that can't itself be produced by normal numerics code, and NaN-boxed pointers in BESEN values will be guaranteed that all memory that can be pointed to by a memory position lives in the bottom 48 bits of memory.
So I've then 4 bit (52bits - 48bits = 4bits) for the value type of 16 possible value types (string, object, etc.).
Or here a possible alternative approach:
I'll use the whole 51-bit (without the 1-bit sign bit as additional storage) just for the pointers to the NAN-boxed objects (for possible future systems for bigger process address rooms than 48 bit), where the object header behind the NAN-boxed object pointers will have then a 32-bit value type tag itself.

Last edited by BeRo1985 (2016-06-17 13:38:12)

mpv · 2016-06-17 17:05:20

@BeRo
Great news!
But this is a huge work IMHO. As far as I remember in 2013 I was not able to compile the jshint library using BESEN. May be this is a first step to improve a engine.

edwinsn · 2016-06-17 18:37:38

@BeRo, that would be great!

Would the project backed by a complete test suite for the js langauge? I think that's crucial for quality control

BeRo1985 · 2016-06-17 19:16:21

edwinsn wrote:

@BeRo, that would be great!
Would the project backed by a complete test suite for the js langauge? I think that's crucial for quality control

BESEN passed already the offical ECMAScript 5th edition test suite since 2010, see https://youtu.be/w6sRxB4iDpk?t=1805 from the BESEN tech talk from the Revision 2011 demoparty from the year 2011.

And for be clarified: BESEN is primary a ECMAScript engine and less a JavaScript engine. Because ECMAScript isn't JavaScript, but JavaScript is in turn ECMAScript with possible some implementation-dependent extensions. So BESEN focuses on the ECMAScript conformity (where BESEN did passing the offical TC39 es5-test suite already since end 2010, see https://youtu.be/w6sRxB4iDpk?t=1805 ), less on the JavaScript conformity to a another ECMAScript implementation in its JavaScript ECMAScript dialect mode, because JavaScript conformity doesn't exist, because only the ECMAScript language core of JavaScript is specified, but JavaScript with its umpteen Implementation variants not. And for example ActionScript from Adobe Flash is also ECMAScript with Adobe-own extensions, but ActionScript is nevertheless mostly incompatible to the defacto lowest common denominator web JavaScript dialect variant, and the same does apply to JScript and so on. For more, see https://en.wikipedia.org/wiki/ECMAScript .

TLDR: JavaScript != JavaScript and ECMAScript != JavaScript, but JavaScript == ECMAScript + possible implementor-own extensions

So just download the offical ECMAScript 5th edition test suite (for example from https://github.com/tc39/test262/tree/es5-tests ), which BESEN passes already since it's public released (at least in the version state of BESEN, which I've used at the techtalk at the Revision 2011 demoparty) .

ab · 2016-06-18 06:07:49

@BeRo
I like the fact that TypeScript pre-compiler is compatible with ECMAScript 3 and up.
As stated by https://www.typescriptlang.org/
Did you make some tests about TypeScript support?
TypeScript is a very efficient way of writing high-level strongly typed language, more close to Delphi, C# or Java.

For BESEN value, I would follow existing representation.
For instance, how V8 or SpiderMonkey did implement their own value record...
For efficiency, perhaps some tuned asm may be written or tuned function inlining, once true bottlenecks are identified via profiling.
IMHO you should make more effort to support FPC than Delphi, since FPC has much more platforms...

BeRo1985 · 2016-06-18 07:53:15

V8 is using SMI, Shifted-Minimum-Integer as Tagging-Concept (see http://thlorenz.com/talks/demystifying-v8/talk.pdf ), and SpiderMonkey (where it is called NuNBoxing and PuNBoxing, see https://github.com/mozilla/gecko-dev/bl … a/jsval.py and https://github.com/mozilla/gecko-dev/bl … ic/Value.h ) is internally using also NaN-Boxing/NaN-Tagging like LuaJIT (and BESEN in future and my BESEN-sister project POCA already since 2011), even all another state-of-the-art script-VM-designs (not only at ECMAScript) are using often the NaN-Boxed/NaN-Tagging base concept, at least at the internal execution layer.

If TBESENValue is just a 64-bit double, it has following advantages:

The automatic record initialization/finalization stuff will not more needed, but at the explict cases, if the TBESENValue contains a Object or a String over the NaN-boxing mechanism.
The most of BESEN values are just always 64-bit big => more CPU cache friendly
The native code Just-In-Compiler stuff can be also more simple then
Numeric arithmetics just works on these plain raw Non-Signaling-NaN double-precision float values, with fewer code overhead than now.
Something like BESENValueType(AValue) instead AValue.ValueType (like now yet) has also the advantage, that further future underlying TBESENValue data structure changes will be easier than now. It's indeed not so optimal for older ObjectPascal compilers, which don't supporting function inlining yet, but for more current ObjectPascal compilers with function inlining, it is a advantage for to decoupling the TBESENValue data structure internal field access from the BESEN API for the "end-user-programmer" for further future underlying data structure changes, without affecting the then new BESEN 2.0 based application code so much.

And I think, BESEN must be also still compatible with Delphi 7 and Kylix 3, because BESEN is already used by some companies with these old compiler-ecosystems for their products.

And support for TypeScript should be no problem then, when I've finished the first BESEN 2.0 stable release then.

Last edited by BeRo1985 (2016-06-18 09:20:04)

BeRo1985 · 2016-06-18 15:59:03

And for those interested in it: here are some informations, resources and benchmark results of my BESEN-sister research-project called POCA, because BESEN was/is too slow for my Object-Pascal-based Unity-style GameEngine called SupraEngine, which I'm developing also now:

http://vserver.rosseaux.net/stuff/pocastuff/doc.md.html (very incomplete documentation, it documents circa. only 25% of the syntax features of POCA)
http://vserver.rosseaux.net/stuff/pocastuff/ (pocarun.exe binary and some *.poca examples)
https://gist.github.com/BeRo1985/0a87de … e72adb10fa (Prime Search Benchmark against Lua 5.3)

POCA has just nulls, numbers, strings, arrays, objects, ghosts and functions as data types, but no extra boolean or undefined data types, what had simplified the POCA VM design a lot in contrast to the BESEN VM design.

POCA has already all that, what BESEN 2.0 should become then. NaN-Tagging/NaN-Boxing, a better code generator, a better Incremental Generational Mark&Sweep Garbage Collector, and a better virtual-machine design with a better performance, better inline-caching-design-concept and better native code Just-In-Time Compiler, and less memory-usage-bloating-issues than BESEN.

And POCA's syntax is ECMAScript-style but a lot with syntax idea additions from other script languages, for example operator overloading, <=> spaceship operator, C#-style safe navigation operators, TypeScript-style / Squirrel-style classes, Java-style super keyword, and so on.

The POCA Code is more low level Non-OOP Pascal-based (therefore also the overall better execution performance than BESEN), but with some Object-Pascal constructs, for example to have a TBESENNativeObject-style construct in POCA called TPOCANativeObject, so that here is no
OOP-class-object-binding-convenience-disadvantage over to BESEN.

Source code on request (which's smaller than the source code from BESEN, even with the fact than POCA has more features than BESEN), since it's a research project, and not a real-usage project (at least yet). POCA is indeed already nice and even stable usable, but POCA is a own non-standardized and non-tested language, so I would not recommend it to use it, simply because it's a non-standardized language, even if it's ECMAScript-like, unless you convinced me to release it POCA as a stable open source product, which I'll maintaining further then.

And at least as already said I'll try now to get BESEN to the same performance level like my research project POCA, if necessary also with a mostly-from-scratch rewrite of BESEN, then with less design flaws and with POCA-style code structure.

I just wanted to have POCA, SupraEngine and Supraleiter mentioned here, so that you know my motives, why I want to rework BESEN now.

And here some videos to my SupraEngine stuff:

https://www.youtube.com/watch?v=L_2olISxXWw
https://www.youtube.com/watch?v=YB5mNY0DHQc
https://www.youtube.com/watch?v=gRvL2KjMdUU

And here some in-game Supraleiter videos with some older versions of my SupraEngine before the Vulkan-based rewrite now:

https://www.youtube.com/watch?v=_SVL0_Z3WL8
https://www.youtube.com/watch?v=SWanRYNNTUA
https://www.youtube.com/watch?v=dR8OJoHWuGs

Last edited by BeRo1985 (2016-06-18 16:08:58)

hnb · 2016-06-18 17:09:31

My current "lobby goal" is to convince BaRo for using mORMot for presented Unity-style engine just amazing - game structures and fluent usage of DB backends...

BeRo1985 · 2016-06-18 17:48:35

hnb wrote:

My current "lobby goal" is to convince BaRo for using mORMot for presented Unity-style engine just amazing - game structures and fluent usage of DB backends...

Erm ... a Entity-Component-System-implementation in a modern game engine is "just" like a key-value database, but really only just like and not really exactly like, because real-time-game-oriented Entity-Component-Systems do need heavily-cpu-cache-optimized memory-contiguous Array-Of-Structs or Struct-of-Arrays (depends on the usage) implementations including (if possible) fast O(1) entity<->component vice-versa-lookups (without hash tables, hash maps, self-balanced search trees, etc.) for a smooth game experience without unnecessary frame-drops etc., how I've implemented it also in my SupraEngine, see:

http://t-machine.org/index.php/2014/03/ … us-memory/
http://gamedev.stackexchange.com/questi … ame-engine
http://gamedev.stackexchange.com/questi … ty-systems
http://www.randygaul.net/2014/06/10/san … y-systems/
http://www.randygaul.net/2013/05/05/dat … arting-up/
http://entity-systems.wikidot.com/
and of course also https://gist.github.com/paniq/c32ac8447a7cc5c33a45 of my Farbrausch demogroup colleague paniq

Last edited by BeRo1985 (2016-06-18 17:49:27)

hnb · 2016-06-18 18:12:30

I'd like to see mORMot not as core of SupraEngine for critical "gamedev data" but as optional usage to handle: game saving, network, replays, more DB oriented games like tycoon/management games... I think we can somehow adjust mORMot for more game oriented usage. I think there are a lot of possibilities. I can't imagine gamedev without mORMot - well tested on many fields.

BeRo1985 · 2016-06-25 03:09:34

Status upgrade:

The now mostly-written-from-scratch rewrite of BESEN (called BESEN 2.0) have already 13874 code lines now, where the following code parts are already done and working:

The new garbage collector (ported over from my BESEN-sister project POCA)
The new ECMAScript 5.1 compliant lexer and parser, which's also faster than the old one in BESEN 1.x now (parses the whole set of the megabyte-large typescript js files also really fast) including a new and more compact (more memory-usage-friendly) abstract-syntax-tree data representation
The new high level abstract-syntax-tree optimizer
The new abstract-syntax-tree-back-to-ECMAScript-code-dumper (needed for the non-official Function.prototype.toString() stuff, which a lot of another ECMAScript does support also it, even although Function.prototype.toString() is not in the official ECMAScript standard)
UTF-16 anywhere as much as possible (because the ECMAScript standard specification is very very very UTF-16 centric for the internal string encoding stuff), even although I'm preferring UTF-8 personally more (like at POCA), but sadly specification is specification.

I've tested the current state with JQuery 1.12.4, JQuery 2.2.4, JQuery 3.0.0 and TypeScript 1.8.10, without any parsing or high-level-AST-optimizer errors.

The next steps will be:

The new byte code generator and the new again register-based virtual machine
The new native code just-in-time compiler (which'll be then with a more generally (very simplified) LLVM-like concept)
The new standard ECMAScript host object implementations
and then incrementally update the stuff from ECMAScript 5.1 to ECMAScript 2015 and ECMAScript 2016.
and then put BESEN 2.0 onto GitHub.

Last edited by BeRo1985 (2016-06-25 03:13:24)

edwinsn · 2016-06-25 11:17:35

Well done BeRo1985! I wish you'll support FPC as well

mORMot Open Source

#101 2014-11-19 16:33:47

Re: Adding JavaScript support for mORMot framework

#102 2014-11-20 12:31:48

Re: Adding JavaScript support for mORMot framework

#103 2014-11-20 13:28:41

Re: Adding JavaScript support for mORMot framework

#104 2014-11-20 13:52:37

Re: Adding JavaScript support for mORMot framework

#105 2014-11-25 11:27:26

Re: Adding JavaScript support for mORMot framework

#106 2015-10-07 07:50:44

Re: Adding JavaScript support for mORMot framework

#107 2015-10-07 18:32:00

Re: Adding JavaScript support for mORMot framework

#108 2015-10-08 14:56:53

Re: Adding JavaScript support for mORMot framework

#109 2015-10-27 03:52:34

Re: Adding JavaScript support for mORMot framework

#110 2015-10-27 19:02:38

Re: Adding JavaScript support for mORMot framework

#111 2015-10-28 12:36:36

Re: Adding JavaScript support for mORMot framework

#112 2015-10-28 13:41:53

Re: Adding JavaScript support for mORMot framework

#113 2015-10-29 05:42:12

Re: Adding JavaScript support for mORMot framework

#114 2015-10-30 03:16:35

Re: Adding JavaScript support for mORMot framework

#115 2015-11-18 22:48:52

Re: Adding JavaScript support for mORMot framework

#116 2015-11-19 07:37:14

Re: Adding JavaScript support for mORMot framework

#117 2015-11-19 09:25:06

Re: Adding JavaScript support for mORMot framework

#118 2016-02-23 07:30:03

Re: Adding JavaScript support for mORMot framework

#119 2016-02-23 07:35:07

Re: Adding JavaScript support for mORMot framework

#120 2016-02-23 17:28:02

Re: Adding JavaScript support for mORMot framework

#121 2016-03-08 17:16:25

Re: Adding JavaScript support for mORMot framework

#122 2016-03-08 21:24:10

Re: Adding JavaScript support for mORMot framework

#123 2016-03-08 21:41:36

Re: Adding JavaScript support for mORMot framework

#124 2016-03-09 01:17:55

Re: Adding JavaScript support for mORMot framework

#125 2016-03-09 08:36:11

Re: Adding JavaScript support for mORMot framework

#126 2016-03-09 12:14:26

Re: Adding JavaScript support for mORMot framework

#127 2016-03-09 13:56:34

Re: Adding JavaScript support for mORMot framework

#128 2016-03-12 12:05:02

Re: Adding JavaScript support for mORMot framework

#129 2016-03-12 13:13:58

Re: Adding JavaScript support for mORMot framework

#130 2016-03-12 13:55:08

Re: Adding JavaScript support for mORMot framework

#131 2016-03-12 15:23:57

Re: Adding JavaScript support for mORMot framework

#132 2016-05-22 12:45:57

Re: Adding JavaScript support for mORMot framework

#133 2016-05-22 12:56:33

Re: Adding JavaScript support for mORMot framework

#134 2016-05-22 14:22:12

Re: Adding JavaScript support for mORMot framework

#135 2016-05-23 11:41:40

Re: Adding JavaScript support for mORMot framework

#136 2016-05-23 13:40:42

Re: Adding JavaScript support for mORMot framework

#137 2016-06-17 11:00:11

Re: Adding JavaScript support for mORMot framework

#138 2016-06-17 11:40:37

Re: Adding JavaScript support for mORMot framework

#139 2016-06-17 13:31:42

Re: Adding JavaScript support for mORMot framework

#140 2016-06-17 17:05:20