ericgrange / dwscript Goto Github PK

Can i bind the DoExecute to the OnExecute property?

e.g.

TDelphiObject = class(TObject)
published
property OnExecute: TNotifyEvent;
end;

TDWSObject = class(TDelphiObject)
public
procedure DoExecute(Sender: TObject);
end;

uses
System.Classes, System.SysUtils, System.Types, System.Masks,
System.SyncObjs, System.Variants, System.StrUtils,
{$ifdef DELPHI_XE3_PLUS}
DateUtils,
{$endif}
{$IFDEF FPC}
{$IFDEF WINDOWS}
Windows
{$ELSE}
LCLIntf
{$ENDIF}
{$ELSE}
{$IFDEF WINDOWS}
Winapi.Windows, System.Win.Registry
{$ENDIF}
{$IFNDEF VER200}, IOUtils{$ENDIF} // <-- here is problem. For compiler is it looks: "DateUtils, , IOUtils" and got an error
{$IFDEF UNIX}
{$IFDEF POSIXSYSLOG}, Posix.Syslog{$ENDIF}
Posix.Unistd, Posix.Time, Posix.Pthread, System.Internal.ICU,
dwsXPlatformTimer,
{$ENDIF}
{$ENDIF}
;

I can help with debug and report issues for support Linux compilation under Delphi 11.3 (with your help)
Currently I'm use Json part only and need it for Linux

I think you can hide this warnings for current state and modify it only when modifying strings in place will be dropped

[dcc32 Warning] dwsUtils.pas(4071): W1068 Modifying strings in place may not be supported in the future
[dcc32 Warning] dwsUtils.pas(5222): W1068 Modifying strings in place may not be supported in the future
[dcc32 Warning] dwsUtils.pas(5570): W1068 Modifying strings in place may not be supported in the future

Now I have this line to hide such warnings:
{$WARN IMMUTABLE_STRINGS OFF}

I want to understand as to how DWScript is coded and modify the code to get it to work in a different environment.

Eric, can you please explain the same here?

Thanks

I am trying to evaluate an expression Delphi-side, using TdwsEvaluateExpr.Evaluate. The expression must be compiled and executed in the context of a specific script side object/method.

For example, let’s say I have the following script class TScriptClass declared in a TdwsUnit and the corresponding class implemented in Delphi as TDelphiClass:

type
  TScriptClass = class
    ...
  public
    // Simple getter/setters. Just forwards to the Delphi side property getter/setters
    property Count: Float read GetCount write SetCount;
    property Price: Float read GetPrice write SetPrice;
    property Expression: string read GetExpression write SetExpression;

    property Value: Float read GetValue;
  end;

The idea is that the Expression specifies how the Value is calculated. An example expression could be: Count * Price

The Delphi-side implementation of the GetValue script method looks like this:

procedure TDataModuleScript.dwsUnitTestClassesTScriptClassMethodsGetValueEval(Info: TProgramInfo;
  ExtObject: TObject);
begin
  var DelphiObject := TDelphiClass(ExtObject);
  if (DelphiObject.Expression = '') then
    exit;

  var Expr := TdwsEvaluateExpr.Evaluate(Info.Execution, DelphiObject.Expression);

  if (Expr.Expression.Typ = nil) then
    exit;

  Info.ResultAsFloat := Expr.Expression.Eval(Info.Execution);
end;

While this works fine for evaluating expressions in the global context, it fails to resolve references to symbols in the local context. That means that in the Count * Price expression example the class symbols Count and Price are unknown.

Is this a bug, am I using the wrong execution context, or is what I’m trying to do simply not possible?

Using the latest sources and compiling the DWSWebServer.dpr has a lot of problems.

Apart from the various small issues that I could solve, it seems to require units in Libraries\JSCodeGen from DWS v2.2 which are no more available in DWS v2.3.

But, even if I supply the units from JSCodeGen, the compilation does not succeed --classes have been renamed, methods and parameters are different etc.

IOW, too numerous to list here..

Could you please update the sources so that all units that are needed for DWSWebServer.dpr are in this repository and that they compile.

Thank you.

Commit f0e53d5 contains a breaking change to the IdwsFileSystem interface:

https://bitbucket.org/egrange/dwscript/commits/f0e53d5baf98d8d34cb4418d529ac26003733cc3#LSource/dwsFileSystem.pasF51T54

This is pretty annoying when one already have custom file systems implemented as the change breaks existing code without any benefit.
While the added interface methods might be convenient in new code, for existing code they are just overhead as one will have already implemented the same functionality in some other way if it was needed. I already have empty methods implementation stubs after the last breaking change to this interface.

Since it’s an interface would it not be possible to extend it with separate feature interfaces instead?

type
  IdwsFileSystemDirectoryExists = interface
  [{blahblah}]
    function DirectoryExists(const directoryName : TFilename) : Boolean;
  end;
  [...]
begin
  var FileSystemDirectoryExists: IdwsFileSystemDirectoryExists;
  if (Supports(MyFileSystem, IdwsFileSystemDirectoryExists, FileSystemDirectoryExists)) then
  begin
    if (FileSystemDirectoryExists.DirectoryExists(directoryName)) then
      [...]
  end;
end;

That’s what I already do with my different file system implementations when I need a feature that isn’t provided by the base file system API. It saves me from having to implement empty stubs in the file systems where a given feature isn’t relevant.