Language changes:

• Initial support for overloads (currently limited to standalone functions/procedures).
• New operator “sar” for bitwise shift arithmetic right.
• Delphi-like “dotted unit names” are now supported.
• Support for classic Delphi-style local procedures declaration in units (before the “begin”).
• Support const “blocks” in units.
• Support for “array [TEnumeratedType] of” short declaration for static arrays.
• New hints for unused private symbols and redundant scope specifiers.
• New built-in functions: LastDelimiter, dynamic array’s Insert(), Min()/Max() overloads.

Library and script engine changes:

• TContextMap & TSymbolDictionary were renamed to TdwsSourceContextMap & TdwsSymbolDictionary.
• The context map content has been significantly reorganized, fixed and is now more detailed.
• TdwsSuggestions can now optionally suggest keywords too.
• Random functions now based on XorShift, with independent random per execution.
• New demo/sample: simple web server based on Indy with multi-threaded server-side script execution.
• Faster DWS SynEdit highlighter.
• Improved documentation.
• Various minor fixes and improvements.

JavaScript & CodeGen changes:

• Closures are now supported by the JavaScript CodeGen.
• Added Smart-Linking capabilities to the CodeGen when program is compiled with context map & symbol dictionary. Its capabilities and limitations are currently roughly similar to Delphi’s.
• Improved JavaScript CodeGen for various code generation cases (faster and smaller, as measured through jsperf benchmarking on various browser engines).
• Improved JavaScript obfuscator.
• Improved JavaScript minifier.

function MyFunc(a : Integer) : String; overload;
function MyFunc(s : String) : String; overload;

In many other languages, the overload directive is implicit, you don’t have to type it and you can always overload. On the other hand, it means that as long as your parameters differ, you can end up overloading an existing function without noticing, which can lead to confusion.
Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

myObject.MyEvent := procedure (Sender : TObject);
                    begin
                       ...
                    end;

There are of course some extensions that go beyond what Delphi supports

You are allowed to use a named local procedure as a closure / anonymous method, with optional capture of local variables, allowing for neater layout of code, for instance:

begin
   ...
   procedure MyLocalProc(Sender : TObject);
   begin
      ...
   end;
   ...
   myObject.MyEvent := MyLocalProc;
   ...
end;

The function pointers and closures are unified, you did not have to distinguish between a “procedure” and a “procedure of object“, and you don’t have to distinguish a “reference to procedure” either, ie. if you declare

type TNotifyEvent = procedure (Sender : TObject);

as long as the parameters match (and result type for a function) , the above type will accept standalone functions, object methods, interface methods, and now closures/anonymous methods (and even record methods, which are just syntax sugar for standalone function with an implicit parameter).

PS: DWScript (as a scripting engine), will very likely evolve (in time) from a stack based-engine to a closure-based engine, so the above syntax will be supported for scripting purposes too, and not just when compiling to JavaScript.

Wikipedia's SOPA blackout page

I usually avoid posting non-technical stuff, let SOPA be the exception that confirms the rule! As for a description of the problems of SOPA, see:

1. Name conflicts and obfuscation support
2. Do you really need an “asm” section?
3. Don’t rely on implicit parameters structure
4. Handling callbacks with “Variant” methods
5. Handling callbacks in an “asm” section
6. Current limitations

1. Name conflicts and obfuscation support

This should be a point zero actually, but the first thing to have in mind is that you are allowed in Pascal to use as names identifiers that are reserved in JavaScript. Those can be language keywords (“this”, “delete”, etc.) or common DOM objects and properties (“document”, “window”).

The compiler automatically protects you from such conflicts by transparently renaming your identifiers (currently by adding a “$”+number at the end).

Then there is the obfuscator, which will basically rename everything to short, meaningless names. That’s good for more than obfuscation: it reduces the size of the JavaScript, improves the parsing and lookup-based performance in the browser.

The consequence is that in an “asm” section, you should prefix all Pascal identifiers with an ‘@’, so the compiler can correctly compile your asm. For instance in:

var window : String;
...
asm
   @window = window.name
end;

The ‘@window’ refers to the ‘window’ string variable (which the compiler will rename), while ‘window.name’ will be compiled “as is”, as it reads the ‘name’ property of the global ‘window’ JavaScript object.

2. Do you really need an “asm”‘ section?

Though for some weird cases you might (like this gem), there are many cases in which you don’t need “asm”, as the language supports a “Variant” type which is a raw JavaScript object, and upon which you can call methods, read properties directly or via indexes.

For instance, with v a Variant, the following code:

v := v.getNext();
v['hello'] := v.space + 'world';

will get compiled (almost) straight into

v = v.getNext();
v['hello'] = v.space + 'world';

When using Variant, you don’t have strong compile-time checks (it’s just you vs JavaScript), property and function names are case-sensitive, so use them with care. This is similar in syntax and essence to using OLE Variants and Delphi.

On the other hand, you have compiler support, and you get automatic casts when assigning a variant to a strong type (Integer, String, etc.), and you also get name conflict protection & obfuscation support without having to ‘@’ your Pascal references.

3. Don’t rely on implicit parameters structure

Because they may change in future compiler revisions!

For instance, methods are currently invoked with an implicit “Self” parameters, and the others behind, so currently “arguments[0]” is Self, and everything else if after that. But don’t rely on it.

Future compiler revisions may change that parameter’s name, may obfuscate it, may remove it entirely in favor of an implicit “this”, may inline your function, etc.

So if you need explicit parameters, declare them, if you’re in a method and need to access the object (Self), use “@Self”, if you need to access a field of the current object use “@Self.FieldName”, etc. That will keep working.

4. Avoid declaring variables in “asm” sections

Declare them in the parent function/method instead, and reference them with the ‘@’ prefix.

There are three main reasons for that, the first is that doing so means they’ll be case-insensitive, the second is that it will allow the obfuscator to obfuscate them reason for that, and the third is that you’ll get compiler warnings if you declare a variable but do not use it (or if you forgot to @-prefix it).

So don’t write that:

asm
   var myTemp;
   myTemp = ...whatever...;
   ...
end;

But write this instead:

var myTemp : Variant;
...
asm
   @myTemp = ...whatever...;
   ...
end;

5. Handling callbacks with “Variant” methods

A common occurrence is to register a callback to a JavaScript object, when that object is hosted in a Variant, that’s fairly simple to achieve:

procedure DoImageLoaded;
begin
   ...
end;
...
var myImage : Variant; // will refer to an image object
...
myImage.onload(@DoImageLoaded);

There we use the ‘@’ operator Pascal-side, to make it explicit that we want a function pointer, and not call the function. The ‘@’ isn’t necessary when the function is declared Pascal-side, as the compiler can figure it out, but when invoking a Variant method, it doesn’t know the parameters type.

Note that since function pointers are unified, you can get a function pointer from an object method or an interface method in the same fashion:

myImage.onload(@myObject.DoImageLoaded);
myImage.onload(@myInterface.DoImageLoaded);

6. Handling callbacks in an “asm” section

If you want to register the callback in an “asm” section, the situation is a little more complex, as “@myObject.myMethod” will refer to the function prototype, outside of its context. It means it’s okay for standalone functions or procedures, but may not do what you’re expecting for object or interface methods.

The solution is to acquire the function pointer outside of the “asm” section:

var myCallback : Variant;
...
myCallback := @myObject.DoImageLoaded;
asm
   @myImage.onload(@myCallback);
end;

7. Current limitations

Currently the parser for “asm” sections doesn’t really understand JavaScript:

• it’s still treating JS as a weird invalid form of Pascal, and notably {} define comments for it, so it will pass whatever is inside curlies “as is”, and will annoyingly ignore @ signs inside curlies
• some weird operator combos (but valid JS)  may throw off the parser, if that happens, place that code in between curlies, and post a bug report

Hopefully in time, there will be a proper JS parser, but currently the focus is more on the Pascal side, and “asm” sections are intended for handling corner cases more than as a main workhorse.

• Working with controls, the boxing model
• Using the TW3HttpRequest object
• Add a new form to my application
• Create and use a timer object
• Rotate a control by X degrees
• Plot pixels on a off-screen bitmap

You may also want to read Primoz Gabrijelcic’s article “First Steps with Smart Mobile Studio“.

There were a few glitches with WordPress during the transfer, but they should hopefully have been solved, if not, feel free to post about them here!

To benchmark it yourself, if you don’t have a large text file hanging around, you can make a “meaningful” one easily: just go to Delphi’s source\rtl\win directory and enter the following command-line:

type *.pas > c:\winall.pas

That should give you f.i. with  Delphi XE an 11 MB file, with 280k lines. Using the following file, here are my rough findings, for an executable compiled with Delphi XE, by order of decreasing performance:

*: EmEditor  does its line indexing work in a background task, so the 1 sec delay to reach the last line is only visible if you try to reach it just after having opened the file.

Once you’ve reached the last line at least once, entering text at the top or the bottom of the file, selecting blocks, copy-pasting etc. is instantaneous enough in all above editors. Memory usage is roughly comparable, except for Eclipse, which is the worst by far.

Notepad++ is using Scintilla, but performs much worse than SciTe (Scintilla minimalistic text editor/demo), so there must be a glitch somewhere in Notepad++ (which I personally didn’t expect, must have been a regression of some sort in recent versions).

SynEdit also seems to scale better than  all the others above on even larger files (as tested on 100MB+ files).

For bragging rights, what other fast editors do you know of?

• much improved performance for long & large files, still not quite notepad++-class just yet, but my profiler tells me there are many juicy low-hanging candies left
• improvements to the TSynGeneralSyn highlighter (single & double quote mode, token callback, and a few other niceties)
• DWScript syntax highlighter has been moved to the SynEdit SVN, the copy in the DWScript SVN will no longer be the primary reference

edit 27/12: committed another optimization, AFAICT, when working on large files, SynEdit is now faster than the Delphi IDE code editor and *way* faster than Scintilla/notepad++ 5.9.6.2 (with and without a syntax highlighter like DWS’s)

OP4JS Alpha aka SmartMobileStudio is in the wild

Jørn Einar Angeltveit  -  Dec 21, 2011  -  Public

We’ve now sent “Smart Mobile Studio” Alpha version to 50 testers.

Did you miss the beta invite?

Visit www.SmartMobileStudio.com to participate.

SmartMobileStudio leverages DWScript’s JavaScript CodeGen.

My first test app with the alpha was a clock, check it in your iOS or Android Browser or in the Android market. Source is included in the alpha. Will be beautified it later on

I’ve been playing on another one, head over to YouTube to see a small video, you can also get the apk (47 kB), but beware it’s basic, ugly, and definitely early alpha, but it’s coded in Pascal!

Below is a snippet of the source code (using DWS inline implementations for illustration and compactness purposes, most of OP4JS is written in the more classic interface/implementation style), it’s a snip of the root class of the mini-engine of the game (yes, virtual methods are supported):

type
   TEntity = class
      X, Y : Float;

      function Progress : Boolean; virtual;
      begin
         // does nothing by default
      end;

      constructor Create(aX, aY : Float);
      begin
         X := aX;
         Y := aY;
      end;

      function Dist2(entity : TEntity) : Float;
      begin
         Result := Sqr(X-entity.X)+Sqr(Y-entity.Y);
      end;
   end;

Other recent changes to the DWScript SVN

• Added sample/simple IndyWebServer demo, implements basic “pascal server pages” and demonstrates how to use DWS in a multi-threaded environment. Makes use of RTTI Environment class to expose WebRequest & WebResponse. Expect more details in a future post.
• TTerminatorThread has been replaced by TGuardianThread, which can “guard” multiple executions
• Dotted unit names are now supported
• Random no longer uses the Delphi RTL but XorShift
• unit name symbols are now included in the Symbol Dictionary
• include references are now included in the Symbol Dictionary
• TdwsSuggestions can now optionally suggest reserved words (begin, procedure, etc.)
• fixes for Inc() & Dec() when operating on references with side-effects.
• improved several error messages related to parameter passing.
• other misc. fixes and optimizations, more unit tests.