#210 orxscrpt.dll loses state between ParseScriptText calls

pending
nobody
WSH (6)
5
2012-08-14
2006-11-28
No

Using ooRexx version 3.1.1 MT (Nov 17 2006) through the IActiveScript interface on Windows XP Tablet PC Edition EN-US (NT 5.1.2600 SP2) platform.

When the host adds several script blocks, it seems the engine doesn't keep its state between blocks.
I believe this goes down to multiple successive calls to IActiveScriptParse::ParseScriptText. It seems each block is executed as a separate script instead of continuation of the existing script.

It can be tested in Windows Internet Explorer using several script blocks.
The attached ooRexx.hta sample can be run run with MSHTA.exe, and the script can be viewed by opening it in Notepad. Both "Object Rexx" and JScript code is included in the same file to show the expected behavior.

When the 2nd Object Rexx block is executed, the i variable is lost. Active Script engines should be able to keep their state between script blocks, and so the second document~write(i) call should have the same effect as the first one.

With the current version of ooRexx, it resets the variable.

This makes it impossible to parse scripts in multiple blocks.

Discussion

  • Philippe Majerus

    Sample HTML Application showing the behavior difference between JScript and ooRexx for multiple script blocks

     
  • Mark Miesfeld

    Mark Miesfeld - 2006-11-28

    Logged In: YES
    user_id=191588
    Originator: NO

    Hi Philippe,

    I am going to take a look at this bug and bug # 1567599, which looks like a similar problem.

    Would you go ahead and assign this to me, miesfeld.

    Plus, you seem knowledgable in this area, maybe you can help fix this. You state: "Active Script engines should be able to keep their state between script blocks"

    Is this documented as a requirement? I can't seem to find a lot of documentation on the details of how a script engine is required to behave, do you know of any good documentation?

     
  • Mark Miesfeld

    Mark Miesfeld - 2006-11-28

    Logged In: YES
    user_id=191588
    Originator: NO

    Hi Philippe,

    I am going to take a look at this bug and bug # 1567599, which looks like a similar problem.

    Would you go ahead and assign this to me, miesfeld.

    Plus, you seem knowledgable in this area, maybe you can help fix this. You state: "Active Script engines should be able to keep their state between script blocks"

    Is this documented as a requirement? I can't seem to find a lot of documentation on the details of how a script engine is required to behave, do you know of any good documentation?

     
  • Philippe Majerus

    Logged In: YES
    user_id=1655860
    Originator: YES

    I didn't notice bug#1567599 when I checked if this error was already tracked. It definitely seems like a symptom of the same bug.
    ActiveScript engines are state machines, the host can change the engine state. Typically the host will init the engine using IActiveScriptParse::InitNew (or through IPersist*), make it parse text with one or several calls to ParseScriptText and other methods of the ActiveScriptParse interface for some more complex hosts (like inline script in Internet Explorer HTML's ).
    There is a very good explanation of the state machine at
    http://blogs.msdn.com/ericlippert/archive/2004/04/10/111028.aspx

    The official ActiveScript interface and behavior documentation is included along with the documentation for ScrRun (Script Runtime objects), WSH (Windows Script Host), WSC (Windows Script Components) and Microsoft's script engines (JScript and VBScript).
    You can download it in CHM at http://www.microsoft.com/downloads/details.aspx?FamilyID=01592c48-207d-4be1-8a76-1c4099d7bbb9
    You can also browse it online at http://msdn.microsoft.com/library/en-us/script56/html/4c750627-6797-4857-9f5e-e5f54371f83c.asp

    The engine should not lose its state until the host calls IActiveScript::Close(), which moves the engine into the SCRIPTSTATE_CLOSED state.

    I spent time on the other side of the IActiveScript* interfaces, creating host applications that can be scripted.
    I noticed this problem with both ooRexx and PHPScript (which exposes the same bug) while trying to get one of my personal projects work with as many script engines as possible, it could be usefull for testing purpose while testing this bug:
    http://www.phm.lu/products/MAS/
    Each line gets executed using a separate call to IActiveScriptParse::ParseScriptText.

    Don't hesistate to contact me for any help you think I could provide for orxscrpt.dll.

     
  • Mark Miesfeld

    Mark Miesfeld - 2006-12-02

    Logged In: YES
    user_id=191588
    Originator: NO

    Philippe, thanks that is useful information for me and helpful.

    If you are monitoring bug #1567599 then you are probably already aware that it is likely that this bug will not get fixed until the release of ooRexx 4.0. Release date sometime in the future, but certainly not soon.

    I took a look at your MAS product and it looks pretty cool. <grin> It also looks like it would be a useful tool to help us improve the Object Rexx script engine. I am interested in getting the orxscrpt engine to work correctly with it and won't hesitate to contact you when I get a few things off my plate.

     
  • Philippe Majerus

    Logged In: YES
    user_id=1655860
    Originator: YES

    Thanks for looking into this.
    I'll be more than happy to test the engine once you get something working. I usually test that all MAS features works with every engine I run accross, that usually also provides a good idea of the interface robustness on the engine side.

    Things I cannot test with MAS and that would be usefull for other hosts are:
    - IActiveScript::Clone (I think ASP uses it to fork script engines for different HTTP requests arriving for the same script, but it can also use IPersist* if Clone is E_NOTIMPL).
    - IActiveScript::AddTypeLib (used by WSH and other hosts when the script project contains references, it usually imports consts from the typelib enums into the script engine.
    - IActiveScriptParse::AddScriptlet.

    It should be easy to support AddTypeLib and AddScriptlet at later time, but Clone and IPersist* might require some design considerations early in the process if you plan to support them.

    Please let me know when you got the time to get back to this, thanks.

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-08-17

    Windows Scripting Host (WSH) has been temporarily disabled in ooRexx 4.0.0. The WSH implementation code is not compatible with the refactored interpreter and needs to be completely rewritten. The old code used undocemented, unsafe, APIs. Those APIs no longer exist.

    The WSH bugs are bugs in the old code. The old code is not going to be used, so technically, the bugs are not going to be fixed.

    This bug will put into the postponed state and used to ensure that this type of bug does not exist in the re-written WSH support. At that time it will be closed.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks