They are released in the SVN source repository on google code, at
http://code.google.com/p/dwscript/
The core compiler and some internal libraries are there, along with a few unit tests, but no demos just yet. It’s compatible with Delphi 2009 (and 2010?) only at this point.
Hopefully some demos will be added, ad interim, you’ll have to look at the unit test source to see how to compile your own scripts. More modules should also come in the next weeks/months as their dependencies get cleaned up, and the dust of many years shaken away.
Here is a quick summary of the most significant changes since DWS2:
What changed in the script language?
- DateTime type was deprecated, in favor of plain old Float for timestamps.
- Integer is now an Int64. For language simplicity, there is only one integer type, 64bit it is.
- Strong typing is more strictly enforced throughout, this can cause issues in previous scripts that abused compiler bugs.
- Support for “deprecated” warnings was added.
- for loop variables can no longer be altered within the loop.
What changed internally?
- Move to strong typing away from Variants, this is still a work in progress (and source of much speedups).
- Handling of break/continue/exit no longer relies on exceptions (it’s now orders of magnitude faster).
- Expression tree memory usage reduced significantly, this is also still a work in progress.
- Tokenizer was re-architectured for higher parsing speed.
- Naming prefix was simplified from “dws2” to just “dws”, though the code is based on DWS2.
Nice work!
I like the new strong typing instead of Variants, and the fact than exceptions are not needed to break loops.
The code is much more readable than RemObject’s pascal script, because of the class-oriented design.
What about integration into DoR, aka Delphi on Rails, instead of Lua?
Well, we’re using DWS mostly for non-web-related stuff (plain old application scripting, end-user customization, ETL, graphics…), so I didn’t use or maintain the web-related aspects of DWS…
So I guess that makes any web framework possible if there is someone interested in developing it, as DWS is pretty much restarting from a clean slate from the web-development point of view 😉
I have yet to look at the code but this sounds like good work and I certainly intend to take a look soon.
Just one question:
What’s the rationale behind the exclusive use of Int64 for integer types?
Int64 arithmetic has (or certainly *had*) some edge-case bugs in the compiler and has a performance penalty as compared to 32-bit integer ops (both the result of Int64 type support not exploited/relied upon by the current compiler, presumably in order to be sure of creating code that will run on strictly 32-bit processors).
The capacity of an Int64 is (ime, ymmv) rarely needed in the majority of applications.
64bit values these days are a regular encounter in two areas IME: databases and file sizes, both are areas that see scripting use, so 64bit became a requirement. To avoid complexity, there is only one Integer type, it also avoids the kind of bugs that is alas so prevalent in Delphi when dealing with file sizes f.i. (using the wrong integer type, worsened in Delphi by the lack of compiler warnings for lossy integer casts).
Performance-wise, the hit is measurable but isn’t so high actually, as heavy integer computations aren’t common in scripts IME, and the 64 bits Delphi compiler should further minimize the overhead (yeah, I know…).
However, in which cases do the Int64 compiler bugs manifest themselves? The use in DWS is rather specific, so it might skirt them.
Great work Eric.
I’ll use your version of DWS for a Delphi MVC Web Development System.
DWS will be used in the “view” and can be used like PHP or Perl with a Delphi BackEnd.
ASAP I’ll post some info on my blog.
@Daniele Teti
Nice. I’ll post a roadmap of sorts soon, so everyone will know what’s on the radar, what’s stable (interface-wise) and what is in flux. Basically I plan for all the external aspects to be forward compatible (the language & the components), while the internals (compiler, expression classes, inner workings…) will be subject to evolutions.
There are also several RTL classes to be re-released, so one on doesn’t have to reinvent the wheel for things like TStringList, TStringBuilder, etc.
@Eric
A roadmap should be very nice. Do you plan a “PHP Mode” for the DWS?
A “PHP Mode” should work in the following mode:
SOURCE CODE:
This is normal HTML or whatever text you like
Now I’m back to the VERBATIM TEXT mode
What do you think about? Could this behaviour managed directly in the parser?
@Eric
A roadmap should be very nice. Do you plan a “PHP Mode” for the DWS?
A “PHP Mode” should work in the following mode:
SOURCE CODE:
<html><body>This is normal HTML or whatever text you like <?pas
WriteLn(‘Now the engine is in DELPHI SCRIPT MODE’);
var s: string = ‘Hello World’;
Writeln(s); ?>
Now I’m back to the VERBATIM TEXT mode
</body></html>
What do you think about? Could this behaviour managed directly in the parser?
This is one aspect of the original DWS I never used (and thus didn’t maintain), but IIRC this was supported via the dws2HtmlFilter unit, so it could only be a matter of bringing the code into Delphi Unicode compatibility. There may be a few things to upgrade along, but I guess it should be relatively light. You can find the units in the DWS packages & CVS at sourceforge.
Ok, I’ll see to do some work on it.
Done! I’ve a working version of dws2HTMLFilter.pas right now.
I’m doing some naming change (strip the ‘2’ in the class and in the units).
Eric, do you wanna to add this filter in the SVN?
Sure! If you have a file to test it on (a .dws source testing some cases and the expected result in .htm or .txt), I’ll even add it to the unit tests 🙂
Ok, ASAP I’ll send to you the whole files (in some way…).
Please add dfm for demos in SVN.
oops, added.