Following up on my offer to do some housecleaning on DMDScript, here is a variation on the Digital Mars DMDScript 1.10 engine.

The changes done to this variation primarily are source-only changes.  The source code has been reduced from 499kB to 416kB.  I trimmed the comments put there by Walter to accomodate the new limitation in licensing.  My variation is released strictly under the GPLv2.0 and does not have the option to purchase.

All other comments are still in place.

The reduction in code size was mostly accomplished by my prettyprinter cleaning up whitespace but I also removed many redundancies, /+ +/, version(none) and version(all) cases where they were used to comment out deprecated code.

I intend to continue work on the code, and I'll be using diff to keep up with any changes Walter makes that are GPL compatible.

I'm planning to do some more work tonight. Who else is interested so far?



Sincerely,
Dan <http://murpsoft.com/>

On Wed, 12 Apr 2006 07:10:40 +0000 (UTC), Dan wrote:

> Following up on my offer to do some housecleaning on DMDScript, here is a variation on the Digital Mars DMDScript 1.10 engine.

...

> My variation is
> released strictly under the GPLv2.0 and does not have the option to purchase.

...

> Who else is interested so far?

Sorry, but I'm not interested in GPL licenses. Don't they imply that I must make my application code distributable even if I just link in the DMDScript library as is.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
12/04/2006 6:16:01 PM

Yeah, well that's precisely the license that's being offered by Digital Mars unless you're interested in paying the $1084 for a single license.  If you are, I'd be more than happy to write a scripting engine to suite your needs.  ; )

I've actually been thinking I'd write up a BSD licensed ECMAScript engine that could double or possibly quadruple what DMDScript gets.  I just feel so much more comfortable using arrays, modern assembler, caching and fancy bit math than classes.

Well, Derek if you're willing to pay that for a license, then please inform me even if you don't want me to do the work.  It'll sufficiently motivate me to finish the aformentioned project.

Sincerely, Dan <http://murpsoft.com/>

Dan wrote:
> Following up on my offer to do some housecleaning on DMDScript, here is a variation on the Digital Mars DMDScript 1.10 engine.
> 
> The changes done to this variation primarily are source-only changes.  The source code has been reduced from 499kB to 416kB.  I trimmed the comments put there by Walter to accomodate the new limitation in licensing.  My variation is released strictly under the GPLv2.0 and does not have the option to purchase.

IANAL, but I guess you don't have much choice here. This kind of dual licensing is usually the only way for corporations to make some real money out of open source software. You can always release a new version of DMDScript under GPL2, but not under any other license. OTOH you could probably release a custom patchset under some other license.

If you're going to write a brand new scripting engine from scratch, please consider LGPL / BSD.

> I'm planning to do some more work tonight. Who else is interested so far?

I am :) I'm still pondering whether or not should I use DMDScript as a scripting engine for my role playing game.

I'm not sure if DMDScript supports ecmascript revs 3 and 4 yet, but it would be cool to add implementations for these too. Making it a bit faster doesn't hurt either. Great work.

-- 
Jari-Matti

Jari-Matti Mäkelä wrote:
> I'm not sure if DMDScript supports ecmascript revs 3 and 4 yet, but it
> would be cool to add implementations for these too. Making it a bit
> faster doesn't hurt either. Great work.

It does do rev 3.

Edition 4
~~~~~~~~~
Extending to support Edition 4 would be a rather simple task for anyone who's
added functions onto the existing native objects... at least I think that's what
edition 4 was about.

COM
~~~
Some folks around here tried implementing COM, self included... but I don't
think anyone's published a successful replication of JScript's level of support.
Even DMDScript's C++ version was said to have problems though I haven't been
paying attention to know if that's out of date info.

Using COM from within D isn't hard at all though - there are header libraries from dsource.org on the minwin project as well as some old abandoned project called core32.  Someone around there managed to get ActiveX working in D and I wrapped that in a D object.

The problems I faced were the need for getters and setters, because you need to relay ie.Visible = 1; through a function which queries the COM interface.  You also eventually need to learn the ropes with how DMDScript declares functions during runtime so you can attach methods to the new ActiveXObject in the constructor - most of the native objects use static arrays which get processed when the engine starts up.

Getters and Setters
~~~~~~~~~~~~~~~~~~~
I really have no idea what I'm doing to implement this, but I have a feeling
that the functions are already there in value.d.  It's just that they're inline
and haven't been wrapped.  Implementing __defineGetter__ and __defineSetter__
and having a BSD|Mozilla license would have the Mozilla project seriously
consider using your scripting engine.

E4X
~~~
Implementing XML natively in ECMAScript would require a major rewrite of the
lexer and parser, as well as a new native object.  I don't care about it.

DLL Binding
~~~~~~~~~~~
I read somewhere that someone was recently working on loading DLL's into
DMDScript and dynamically binding the DLL to a new object.  That would be hugely
useful and has alot of the same problems as a COM interface.  Definitely worth
getting together on and working out a solution.

xml lib binding
~~~~~~~~~~~~~~
I personally think the String.prototype.anchor and such 'html' functions suck.
Having a binding to a/some professional XML library(s) with a DOM is the 'right
thing'.  That said, if it's going to sub in for JScript, I think it might need
those string functions.  :(

Array/String slices
~~~~~~~~~~~~~~~~~~~
Implementing this would allow dramatic improvements in the performance in the
script.  Definitely cool, and I don't know how many times I've had to use
s.substr(/lala/.search(s),/baba/.search(s))  I can feel the computer's stomach
turning over.

Array-ifying natives
~~~~~~~~~~~~~~~~~~~~
ECMAScript objects are associative arrays; so if we have an array of properties
it's actually quite natural to the language.  More importantly, it makes it very
natural to slice objects, and we keep a single table instead of a
NativeFunctionData and PropertyTable.  If the array elements are 16 byte
align(16), then we can use movaps XMMn, ESI; movntps EDI, XMMn; assembler
instructions to copy a whole property.

Multilingual Support
~~~~~~~~~~~~~~~~~~~~
If we keep ALL of the string data in files separate from the code, we can easily
make the engine multi-lingual by having keywords and such in the local tongue.
It's possible even make it relatively easy to translate code from one human
language to another by one to one mapping.

~~~~~

Well, those are my thoughts on extensions/changes.  Today I'm going to work on writing the main, property, value, program, lexer and parser for my new BSD licensed engine in D.

Dan wrote:
> COM
> ~~~
> Some folks around here tried implementing COM, self included... but I don't
> think anyone's published a successful replication of JScript's level of support.
> Even DMDScript's C++ version was said to have problems though I haven't been
> paying attention to know if that's out of date info. 

I'm one of those folks who's interested in COM. I'd love to have something close to what JScript does with ActiveX in DMDScript.

> Using COM from within D isn't hard at all though - there are header libraries
> from dsource.org on the minwin project as well as some old abandoned project
> called core32.  Someone around there managed to get ActiveX working in D and I
> wrapped that in a D object.

I put the ActiveX stuff in the SVN repository for core32. I think Carlos Santander did the heavy lifting, but I added some of my ideas to it. I never really figured out what was going on enough to move past trivial applications, though.

I'm eagerly anticipating to see the realization of your vision. :)

-- 
jcc7

Hey Justin,

Yeah, I pretty much yanked Carlos' work too.  I was emailing him a few times about it, and he claimed he was pretty much just tinkering his way through it. I don't believe him.  I'm pretty sure he was a COM wizard.  :p

*poke*

I was just mentioning *potential* expansions for an ECMAScript engine at DMDScript's current state.  I wasn't offering to do all those.  :(  Like I said though, I _am_ starting work on my own engine, and it's going fairly well.  I blueprinted the lexer, parser, program and main components yesterday, and wrote the console main.  Today I figured I'd start work on the mundane text and message files.

I am working on a very interesting ECMAScript engine from scratch, which I hope to release under the BSD license.

Dan escribió:
> Hey Justin,
> 
> Yeah, I pretty much yanked Carlos' work too.  I was emailing him a few times
> about it, and he claimed he was pretty much just tinkering his way through it.
> I don't believe him.  I'm pretty sure he was a COM wizard.  :p
> 

Amazing the kind of comments you get when you read some documentation... I'm gonna have to try that more often... :D

> *poke*
> 
> I was just mentioning *potential* expansions for an ECMAScript engine at
> DMDScript's current state.  I wasn't offering to do all those.  :(  Like I said
> though, I _am_ starting work on my own engine, and it's going fairly well.  I
> blueprinted the lexer, parser, program and main components yesterday, and wrote
> the console main.  Today I figured I'd start work on the mundane text and
> message files.
> 
> I am working on a very interesting ECMAScript engine from scratch, which I hope
> to release under the BSD license.
> 
> 


-- 
Carlos Santander Bernal

Well, I'm about 1/10th of the way done.  I've written the static arrays for all the native objects, I have the text and the error messages done, and all the methods have empty husks to fill.  I also have a main program which calls a Global_init and then passes all the source files to a Global_eval.. yes the same one as the eval method.

The lexer and parser blueprints are done.  The next step is to build a nice jumpgate lexer in x86 assembler without any branching.  The thought of 50 if/else if branches for every byte of a source file frightens me.

I'll give another update when I have the lexer throwing tokens at me.  The bad news is that I'm about to move internationally, so things are gonna be slow for a week or so.  :(  Real life sucks.