georeference.org
Subscribe to this thread
Home - Scripting / All posts - What a the full requirements for adding a new active scripting language?
herbertwest19 post(s)
#05-Jun-09 15:20

Greetings.

I easily got ActiveState Python and ActiveState Perl working with Manifold 8. When I installed

ActiveScriptRuby (from http://arton.hp.infoseek.co.jp/index.html) I was able to run scripts from

the windows command shell using cscript but the new language did not show up in the

manifold scripting language menu. Should new ActiveScript languages show up automatically or is some configuration needed?

I notice that IronPython shows up even though it is not installed on my system -- so is the list

effectively hardcoded? What do I have to do to get ActiveScriptRuby (or something else, like

TclScript) recognized?

Thanks!

liofr
342 post(s)
#05-Jun-09 15:59

have already test to discover ruby is not supported . see my thread here

perhaps in june 2009 , ruby is supported but i don't think so . Think manifold don't support by default all microsoft virtual machine ( CLR DLR) without specific code !!


many talentuous developper leave microsoft boat ... hope the "delphi" guy ll succeed with C# to challenge java RMI sun language and MS focus on new functionnalities rather than publicity.

herbertwest19 post(s)
#05-Jun-09 16:17

Thanks, I did see that post. I saw another one from manifold-l in 2004 that mentions

manifold looking for a specific python dll (see http://lists.directionsmag.com/discussion/read.php?f=29&i=36318&t=36309), which led me to suspect the developers have hardcoded support for

specific languages or even versions -- i recall some complaints about the latest IronPython not working even though older ones do.

On the other hand, the documentation says:

Scripting within Manifold is implemented using either .NET languages or ActiveX scripting. This means that you can use any language for scripting within Manifold for which an ActiveX scripting engine is installed on your computer.

And also:

Other scripting languages, such as REXX and Tcl/Tk, are said to be available as ActiveX scripting engines and presumably could be used within Manifold. These have not been used at manifold.net but we would be interested in hearing from users who have experimented with them or with any other scripting languages within Manifold.

Well, I would LOVE to experiment with other scripting languages. What do I need to do to get Manifold to see them? Since ActiveRubyScript works with cscript, it seems to satisfy windows' requirements for being an active scripting language. TclScript I am less sure about, but am just as interested in testing out.

HAS ANYONE SUCCEEDED IN GETTING ANY LANGUAGE other than Python, Perl, and the microsoft stuff working?

Dimitri


3,145 post(s)
#06-Jun-09 08:41

i recall some complaints about the latest IronPython not working even though older ones do.

IronPython is a .NET language, not an ActiveX scripting language. The two are not related.

Well, I would LOVE to experiment with other scripting languages. What do I need to do to get Manifold to see them?

1. Install a language which is *fully* implemented as an ActiveX scripting engine.

2. Done. Manifold will recognize it and it will be available to you.

Since ActiveRubyScript works with cscript, it seems to satisfy windows' requirements for being an active scripting language.

That's not a valid inference. An easy way to see that is to try running it using Microsoft Script Debugger (see http://www.manifold.net/doc/debugger.htm ...comments at the beginning of that topic as well as at the end in the section captioned "Installation Requirements"). I'd bet it hasn't implemented all the debugging calls, which would be proof it is an incomplete implementation.

ActiveX is very cool in that it is easy to get up a new language with a partial implementation of a scripting engine. That encourages experimentation in a wide variety of casual settings, which is a great thing. A downside of that relaxed attitude is that much of what people expect in a development environment, such as support of debugging calls, need not be implemented. That's why one runs into very many ActiveX languages that are usable enough for experimentation or within their own worlds or within whatever their authors have tested but which do not follow through as do fully implemented ActiveX scripting engines like vbscript. That limits their usability in all possible environments. I don't worry about that with free languages as I'm grateful for whatever I get for free. :-)

If you have a language and you can get it running on its own you can still experiment with it and Manifold so long as it can call the API (as can any Microsoft development environment).

herbertwest19 post(s)
#06-Jun-09 13:38

Dimitri,

Thanks for some very useful information. But what constitutes "*fully* implemented?" Can you comment on what is minimally required for Manifold to see a language? For example, the debugging API is not required since it doesn't work with ActiveState Python -- but I can script in ActiveState Python. Are Activestate Python and Perl each "*fully* implemented as an ActiveX scripting engine" since they work

with Manifold? It seems not.

So I guess I'm looking for sufficient conditions, not necessary conditions.

Can you or anyone else provide any guidance as to what needs to be added before we get some useful capability within the Manifold environment? I mean being able to run simple scripts in the target language.

Since you pointed out that IronPython is .NET, and not ActiveX -- now I would like to know what it

would take to get other .NET scripting languages integrated. For example, IronRuby as an alterative to Ruby. Or even a (soon-to-be) microsoft-supported language, F#. Will any .NET language that conforms to some set of microsoft-published rules be recognized automatically? If so, where are those rules?

Any guidance is appreciated.

Dimitri


3,145 post(s)
#07-Jun-09 22:33

But what constitutes "*fully* implemented?"

According to Microsoft, something that fully implements Microsoft's ActiveX scripting specification.

So I guess I'm looking for sufficient conditions, not necessary conditions.

I can sympathize, but that somewhat defeats the purpose of a common spec, which is to avoid the hassles of having to ask such questions.

Will any .NET language that conforms to some set of microsoft-published rules be recognized automatically?

No. .NET languages (for now) must be explicitly supported. To lobby for a favorite language, see tips in http://www.manifold.net/info/suggestions.shtml

herbertwest19 post(s)
#09-Jun-09 02:55

But what constitutes "*fully* implemented?"

According to Microsoft, something that fully implements Microsoft's ActiveX scripting specification.

That's a very clear, and perfectly reasonable answer. It would be nice if the documentation were a little more explicit about this. Manifold.net invites users to experiment with various alternative languages, but none seem to exist! Granted, a usable PythonScript and RubyScript are available, but they don't meet the criteria of fully implementing Microsoft's ActiveX scripting specification (namely the debug APIs, possibly others).

This is very frustrating. Are there any counterexamples (open source, non-Microsoft, but fully-conforming)? The existence of almost-counterexamples (like ActiveState Python and Perl) is terrific, but somewhat infuriating as well.

Dimitri


3,145 post(s)
#09-Jun-09 09:22

I think you're not feeling sufficient oneness with the whole alternative language thing. :-) Some comments...

It would be nice if the documentation were a little more explicit about this.

The documentation says...

you can use any language for scripting within Manifold for which an ActiveX scripting engine is installed on your computer.

Well, I suppose if that language was written for programmers interested in tinkering with open source software or alternative languages they took it for granted that "ActiveX scripting engine" would be understood that a fully functional such engine was meant. It's like if someone publishes snippets of code for C++ it's understood that those will be used within a development environment that fully supports C++ syntax and not just part of it.

Manifold.net invites users to experiment with various alternative languages, but none seem to exist!

I think it would be more accurate to write that Manifold makes note of various efforts that are "said to" be available and leaves it up to you what you choose to pursue. That's in keeping with the whole open source, alternative language vibe. The main focus of the documentation is VBSCript and JScript and the reasons why the focus is on those is set forth. After much talk on those two languages, the documentation comments...

At the present writing downloadable, free-of-charge ActiveX scripting engines for PERL and Python are available from sources such as www.activestate.com. End users may download these engines, install them and then merrily write Manifold scripts in either PERL or Python. manifold.net personnel have experimented enthusiastically with both languages on a casual basis.

Other scripting languages, such as REXX and Tcl/Tk, are said to be available as ActiveX scripting engines and presumably could be used within Manifold. These have not been used at manifold.net but we would be interested in hearing from users who have experimented with them or with any other scripting languages within Manifold.

As far as "none seem to exist" goes, I suppose that depends upon one's search engine skills and might better be rewritten to "none seem to exist except oddball little languages in which I have no interest and which appear to have been forgotten even by their own authors." :-)

I hesitate to write the above because I don't want to commit the sin of not zealously believing every word I read in that ultimate Open Source font of indisputable Internet wisdom, Wikipedia (http://en.wikipedia.org/wiki/Active_Scripting):

VBScriptand JScriptengines are included with the default installation of Windows versions after Windows 95, and are an optional install with CE. But, there are additional free and commercial Active Scripting engines available. For example, one can add support for Perland Pythonscripting to Windows by installing the ActiveStateActive Scripting engines which are included in the ActivePerland ActivePythondistributions. Haskell, PHP, Rexx, Delphi, XSLT, Tcl, Rubyand many other are also available.

Of course, if Wikipedia says so it must be true! :-)

Seriously, though, it's not likely you'll see too many new ActiveX scripting engines. ActiveX is a very old technology that does not seem to muster very much contemporary enthusiasm in the open source or alternative languages communities. It's no accident Microsoft and their ecosystem are moving to .NET languages. If anyone doesn't like that, the right open source vibe is not to complain other people aren't publishing sufficiently many ActiveX languages, it is to roll up one's sleeves and write those languages.

Although it is a bit dated, Microsoft still provides lots of useful archived info to those who would write new ActiveX scripting engines, complete with debugging support. There are even examples such as SamScrpt and 4thScrpt, Mark Hammond's implementation of Forth (well, as he puts it a "Forthish" language).

http://support.microsoft.com/kb/216271

http://support.microsoft.com/kb/216073

http://support.microsoft.com/kb/223389

herbertwest19 post(s)
#10-Jun-09 02:43

Re: "none seem to exist" and dependence on "search engine skills"

What I meant was that "none" meeting the criteria that I inquired about exist -- i.e. those that implement the full ActiveX protocol. The search engine comment is off base given the previous dialogue; the purpose was not to collect a list of oddball languages that might or might not work with Manifold, it was to obtain documentation about the requirements of adding yet another oddball language to Manifold. Any given oddball language is only interesting insofar as it can provide clues about what is missing from (e.g.) RubyScript. The whole bloody point is to get real work done by hooking these scripting engines up to Manifold, not to screw around with writing programming languages. Its easy to find languages that MIGHT work just by looking at the Manifold docs. But none of those meet the criteria. And the first four that I tried didn't work.

And I am perfectly willing to roll up my sleeves and augment existing open source efforts -- that was the point of the inquiry, to find out what additional features are needed to get an existing partial implementation (RubyScript) working with Manifold. The unofficial answer seems to be "figure it out yourself by experimentation" because the official answer of "you must implement the full ActiveX spec" is obviously not correct (given the existence of ActiveState Python and Perl). And that unofficial answer is perfectly reasonable (moreso than the phony requirement), but why was it so hard to obtain?

If the documentation wasn't so optimistic I never would have bothered looking into this at all. Your comment: 'I think it would be more accurate to write that Manifold makes note of various efforts that are "said to" points out a problem with Manifold documentation style -- some of it is open to interpretation. Separating out the rumor, speculation, and self-congratulation into a separate document and leaving a core of objective reference documentation might help.

Anyway, thanks again for the information.

Dimitri


3,145 post(s)
#10-Jun-09 10:08

I think we're talking past each other in that we have different concepts of what Manifold's role is in this. I don't have any expectation that Manifold would provide guidance on how to re-write other people's packages so they conform to Microsoft's specifications and advice regarding ActiveX scripting engines.

That's up to the authors of such packages, and Microsoft has provided a lot of information to assist them. For example, if you follow the first link from my earlier posting and review the technical information provided in the SanScrpt package you'll find highly useful information like the attached .doc.

The unofficial answer seems to be "figure it out yourself by experimentation" because the official answer of "you must implement the full ActiveX spec" is obviously not correct (given the existence of ActiveState Python and Perl).

I think you may be confusing comments posted here in the forum by Manifold users like you and me with what the company writes in the documentation, which is the only info that's official. There's no "unofficial" info that comes out of Manifold. The documentation tells people to use only VBScript and Jscript, and that only VBScript is supported by tech support.

If you want to work with something else that's entirely up to you, which I think the documentation makes quite clear (see the quotations in my earlier posting). I personally think it's good that the company provides helpful comments here and there such as mentioning the possibility of other languages, but I don't see how any of that could be interpreted to be an offer or a duty to assist folks in writing such languages or debugging the limitations of other packages.

By the way, if you are writing about my earlier posting...

"you must implement the full ActiveX spec" is obviously not correct (given the existence of ActiveState Python and Perl).

...I'd respectfully point out that the comment is indeed correct or you'd be able to use the debugger with those languages. Microsoft in its published information (see the attached .doc and the info in the other links) takes special pains in teaching how to support debugging in an ActiveX engine, so it is not something that is difficult to learn how to do.

to find out what additional features are needed to get an existing partial implementation (RubyScript) working with Manifold.

Given the infinity of ways in which partial implementations may or may not have chosen to follow Microsoft's specs and advice to suite the taste of the original developer, there is no "one size fits all" answer to the above other than to point newer developers at the copious information resources Microsoft makes available and to wish them good luck in deciphering someone else's code.

For me, I don't find it worthwhile to tinker if I know a project has left off something big like debugging, based on the reckoning that there are probably too many other things neglected as well to make it either fun or worth my time. But other people quite rightly may feel differently and that's part of the fun of tinkering with open source.

Attachments:
SampleScriptDocs.doc

2 msec Copyright (C) 2007-2008 Manifold.net. All rights reserved.