Posts by hsvandrew

hsvandrew · mORMot 1

Is it possible to consider the time/cost of making Synode (SpiderMonkey) and the common parts of framework at least Delphi 10.3 Linux compatible. A trial version of 10.3 is available which should be sufficient or access can be provided.

I'd be prepared to run & contribute to a crowd funding effort with a set goal that could be donated to the project if we could make this happen.

hsvandrew · SyNode

mpv wrote:

SyNode for Linux (x64) merged into trunk. We add a compiled SpiderMonkey to mORMot git repository (using LSF extension) - see fpc-linux64 folder
Build instruction is also available
Also added a Hello World sample
Thanks to @ssoftpro for contribution!

Hi mpv

Do you plan on providing support for both FPC and the Delphi Linux compiler or just FPC?

I am trying to work out whether to buy the latest Delphi and some comments here suggest FPC is better than the Delphi Linux compiler but I'm having trouble finding any sources that tell me why.

Compiling Synode in Linux is very important to us and there is no point spending $4600AUD on Delphi if SyNode will only ever be for FPC

hsvandrew · SyNode

mpv wrote:

In practice I'm not recommend to use a RTTI-based binding. Preferred way is to expose a minimal set of functions to a JS Engine via native bindings and implement all logic inside a JS, like we did in fs.js + SyNodeBinding_fs.pas.
As a workaround to deal with TDateTime there is jsval.getAsDate / jsval.setAsDate. I'm not understand how we can recognize a TDateTme, since where is no DateTime in TTypeKind?
We use Int64 (actually Int52) to interact with a database primary key values. String / GUID is overhead in our case, Int32 is small for us (we have ~10Tb DB). The only place where we limit a Int64 size is a database primary key generator (sequences, etc)

I think you misunderstand my point about int64. We like and use int64 for database primary keys as well. The problem is that javascript doesn't support int64 properly as a basic type and therefore making it look like there is support for it will confuse developers who aren't aware of this fact and place bugs in their code that will be very hard to detect until their database grows and all of a sudden really crazy things start to happen, which could even include security holes exposing themselves.

This is why its safer to not support int64

See https://developer.mozilla.org/en-US/doc … ence/Int64

-----

To detect TDateTime types

function TVal2JSVal(cx: PJSContext; const Value: TValue; aParentProto: TSMCustomProtoObject; propType: TRttiType ): jsval;
...
begin
  Result.setNull;
  if Value.IsEmpty then
    exit;

  if assigned( propType ) then
  begin
    if propType.ToString = 'TDateTime' then
    begin
      result.asDate[cx] := value.AsVariant;
      exit;
    end;
  end;

hsvandrew · SyNode

Can I suggest a few improvements to SyNodeNewProto

Firstly I think TVal2JSVal should be function TVal2JSVal(cx: PJSContext; const Value: TValue; aParentProto: TSMCustomProtoObject; propType: TRttiType ): jsval;
This allows us to correctly pickup a TDateTime property/method arg etc and process correctly as currently dates only work one way (write/inwards), not read on a property)
Secondly, I suggest any 'int64' support be removed as Javascript can't cope with 64bit integers and it will cause more problems than it solves allowing it. Its better to force users to create string based int64 properties/method args etc

mORMot Open Source

#1 Re: mORMot 1 » Delphi 10.3 - Linux platform support » 2019-01-15 05:47:30

#2 Re: SyNode » Beta release of SyNode - ES6 JavaScript + NPM modules » 2017-12-22 23:53:58

#3 Re: SyNode » Beta release of SyNode - ES6 JavaScript + NPM modules » 2017-10-21 03:11:40

#4 Re: SyNode » Beta release of SyNode - ES6 JavaScript + NPM modules » 2017-10-18 02:51:17

Board footer