Contents tagged with DLR

  • ASP Classic Compiler: the unit testing framework is released

    2 Comments

    In my previous post, I stressed the importance to have a unit testing framework to move forward with this project. I was facing the decision whether to use NUnit or MSTest. After some thoughts, I came to the conclusion that the choice of unit testing framework is not critical, at least for now. For a language project, unit testing usually falls into two categories: the testing of a parser and the testing of generated code. For parser testing, most of work lies in comparing AST generated by the parser with the expected AST. Paul Vick has an excellent framework in his VBParser work. For testing of the generated code, it is best to have a unit testing framework that is self-contained in the target language so that is can most accurately test the semantics of the language. For example, Javascript has the QUnit framework and ASP Classic has the ASPUnit framework.

    So I went ahead to release my own unit testing framework for VBScript. I created an interface called IAssert that has the following methods:

            void AreEqual(object expected, object actual);

            void AreEqual(object expected, object actual, string message);

            void AreNotEqual(object notExpected, object actual);

            void AreNotEqual(object notExpected, object actual, string message);

            void Fail();

            void Fail(string message);

            void IsFalse(bool condition);

            void IsFalse(bool condition, string message);

            void IsTrue(bool condition);

            void IsTrue(bool condition, string message);

    These are minimum set of method often found in most of unit testing frameworks. We can always add more when needed. Note that I did not have IsEmpty or IsNothing methods. That is because I believe we should use the language built-in method to best reflect the language semantics. For example, instead of having an IsEmpty method in the testing framework, we should use IsTrue(IsEmpty(myVar)) where we are using the VBScript built-in function.

    In environments that we have control over the host, the host will supply an Assert object that can route the testing results to one of the existing unit testing framework, such as NUnit, so that we can reuse the test runners and report functionalities. In the environments that we do not have control of the host, we can supply an Assert class in VBScript itself, much like what ASPUnit does.

    If you look at my VBScriptTest project, you will notice that it uses NUnit framework. It has a single NUnit test case that walks the entire hierarchy under the VBScripts folder. When we need to write a new test case, we just simply add a .vbs file under the VBScripts folder. The following is an example VBScript unit test case:

    dim a
Assert.IsTrue(IsEmpty(a), "Unassigned variable must be empty")

    Because I have use a single NUnit test case to run all the VBScripts, the message parameter is an important parameter to distinguish the test case in the situation of failed test case.

  • ASP Classic Compiler: the next step

    No Comments

    I opened the source code for my ASP Classic Compiler 2 days ago. As this project was started as a research project, proof of concepts has been a major goal. I have cut corners whenever possible to bring out features fast. Going forward, there are many things that need to be tighten up. The following are my top priorities:

    1. Unit testing: You eager downloaders may have noticed the my project is notoriously missing unit tests. I intentionally took out my unit tests when I upload because my previous unit tests were not well organized. I want to give us chance of a fresh start. Since we will have refactoring and re-architecture of the code generator, unit testing is going to carry this project. Like many open source projects, NUnit or MSTest is a decision to make. I have created this thread in my forum to solicit ideas. I don’t quite need StackOverflow style discussions as there are already plenty. But if you look at recent high profile switches in either directions, you would know this is not an easy decision.
    2. Making it easier for people diagnose problems. A debugger is not going to happen easily, as I have already tried twice. But with source code, it is still possible for people to diagnose problems. This will help reducing the frustration level and getting bug reported and fixed.
    3. VBScript 5.0 support. This is my real top goal since many people requested it, but I could not get there without 1 and 2. I want to take over the memory management since I have already pushed DLR to the limit. Controlling the memory management will open up the possibility for debugging. Details is going to be a blog by itself.
    4. Performance improvement when calling CLR static methods. The TypeModel used in VBScript.NET does not take advantage of call-site caching and is hence very slow. Fortunately, this can be corrected fairly easily.
    5. Optimize for multiple string concatenations. This has been a habit in many ASP projects. I can discover this in code analysis and generate the code behind the scene using StringBuilder. This is a pretty fun research project and it is not too hard.
    6. Type checking in many places can still be optimized for callsite-caching.
    7. Rewrite of the parser. Currently, my VBScript parser is modified from Paul Vick’s VBParser which was written in VB.NET. I have some concern on VB.NET’s timely availability in new platforms (remember Windows Phone 7?). However, since my code generator is tightly coupled to the abstract syntax tree (AST) in the parser project, this is going to be a messy work.

  • ASP Classic Compiler is now open source

    5 Comments

    After weeks of preparation, I have opened the source code for my ASP Classic Compiler under the Apache 2.0 license. I conceived the project in 2009 when I joint a company that had a large amount of ASP Classic code. The economy was very slow at the time so I had some energy left to start the work as a hobby. As the economy recovers, I was getting busier with my day-time job. We converted most of our ASP Classic code to .net so that this project would no longer be useful for my own use. However, I truly hope that this project will be useful to those who can still use it.

    The project had gone a long way to implement most features in the VBScript 3.0 standard. It is capable of running the Microsoft FMStock 1.0 end to end sample application. I chose VBScript 3.0 in my initial implementation because VBScript 3.0 is a language with dynamic type and static membership. ASP Classic Compiler is faster than most of the Javascript implementations and is about 3 times faster than the IIS ASP interpreter in limited benchmark test. Many users have requested VBScript 5.0 features such as Class, Execute and Eval. VBScript 5.0 has dynamic membership like Javascript. To avoid the performance hit, I have done some research to optimize the performance for the mostly static scenariou, but have yet to find time to implement it.

    For this project to be successful, I truly need community involvement. In the next few days, I will outline what need to be done. I will stay as the project lead until we find a suitable new leader.

  • Installing FMStocks 1.0 on later platforms

    No Comments

    My latest version ASP Classic Compiler can now run FMStocks 1.0, an end-to-end sample application. I have uploaded a version of FMStocks at http://aspclassiccompiler.codeplex.com/Project/Download/FileDownload.aspx?DownloadId=98236. The version that I uploaded already has the web.config file as well as the bin directory containing the necessary dlls. To run it, you need to map a virtual directory to the website directory. Use IIS manager to map the ISAPI dll for the .asp extension to the same DLL used by the .aspx extension on your virtual directory. You still need to create the database and register the COM objects. Since the setup program was written for Windows 2000/SQL Server 2003, it may not work correctly for later platforms. The following procedure shows how to install them on a later platform manually.

    1. To install the COM objects, just use regsvr32 to register the FMStocks_Bus.dll and FMStocks_DB.dll in the objects\Distribution directory.
    2. To create the database, first useISQL to open the schema.sql file and run it. This will create the database, login and the tables. Note that your sql server must be in mixed security mode.
    3. Next, open Create 10,000 test accounts.sql with ISQL and execute it. This will create the sample accounts.
    4. Lastly, use import feature to import the data in rawdata.mdb into the stocks database.

  • ASP Classic Compiler 0.6.0 released. It can run FMStocks 1.0

    No Comments

    I uploaded ASP Classic Compiler 0.6.0 to http://aspclassiccompiler.codeplex.com. We reached a small milestone: it can run Fitch and Mather Stocks 1.0 now. This is the first end-to-end example that we can run with ASP Classic Compiler. Our goal is to be able to run most of ASP classic applications under ASP.NET without modifications, but we actually need to make two minor modifications. Both cases are due to the difference between interpreter and compiler. With interpreter, you can have syntax error in dead code (unreached code); with compiler, the entire code has to be syntactically correct for the code to compile.

    The first change is at t_head.asp line 71, we added "dim i". That is because we have undeclared variable when the option explicit is on. Since the procedure was never executed, the ASP interpreter never caught the error but we have to fix it for the ASP Classic Compiler.

    The second change is at SellStockAction.asp line 17. We added  "dim m_strMainPrompt". Again, this is an undeclared variable. Since the “on error resume next” is on, the VBScript interpreter would actually skip over the syntactical errors but the code will never work correctly. For the compiler, “on error resume next” cannot trap compilation errors.

    In addition, several pages use @Transaction declaration. They are ignored since we do not have Com+ transaction support at the page level. Transaction for objects in Com+ packages are supported. 

    I have uploaded preconfigured FMStocks with web.config and .net DLLs to http://aspclassiccompiler.codeplex.com/Project/Download/FileDownload.aspx?DownloadId=98236. It is still necessary to register the COM objects and install the SQL database. Since the setup program was written for Windows 2000/SQL Server 2000, it does not work correctly for the later platforms. I will document how to install it in a later platform in a separate blog entry.

    Here is the plan and call for action:

    1. I will come out with some debugging aid in the next version. Trouble shooting both asp problem and the compiler problem without debugging aid is painful.
    2. The parser is 90% done. If you use ASP Classic Compiler to run your application, I do want you to report all syntax errors so that I can fix them.
    3. The code generator quality is at 60-70% level. I want you to hold on the report of runtime errors until I provide better debugging aid.
    4. I will continue test ASP Classic Compiler using some open source samples/applications. Drop me a not if you have any suggestion.
    5. I originally envision to have class support after the 1.0 release, but it looks like now that I will implement the Class feature before the 1.0 release.

  • Uploaded ASP Classic Compiler Version 0.5.6.34834 to http://aspclassiccompiler.codeplex.com

    No Comments

    With feedbacks from several enthusiastic users, I have fixed many little bugs. Give the latest version a try. Post bugs on the forum as usual. Happy computing!

    I am running into a little bit of difficulty with CLR debugger integration. In order to generate the debug symbol, I need to use LambdaExpression.CompileToMethod(). However, this method does not support DynamicExpression that I heavily rely on. So I am back to research and trying to figure out how to use Microsoft.Scripting.Debugging.dll. In the mean time, I am going to enable tracing in near future so that at least we can figure out problems through tracing.

  • Execution Assisted Code Converter

    1 Comment

    As I am working on my VBScript.net and ASP Classic Compiler, I came the realization why the existing asp classic to ASP.NET converters do not work very well. The primary difficulty is those converter do not get many type information during static analysis when converting a scripting language such as VBScript to strongly-typed VB.NET or C#. For the same reason, editor intellisence usually does not go very far when editing VBScript or Javascript.

    Executing the dynamic code will bring in the type information at runtime. I think that I just need to enhance my callsite binder to capture some information and then I will be able to convert the code that flow through my binder much more accurately. Mostly likely the converted code should work correctly right away. So I will just give it a name called Execution Assisted Code Converter. I will try to put together a prototype if I get a little bit of time.

    Note: There are refinements to the thought through discussions of this post below.

  • Uploaded Asp Classic Compiler Build 0.5.5.34834

    No Comments

    I just uploaded ASP Classic Compiler Build 0.5.5.34834 to http://www.codeplex.com/aspclassiccompiler.

    In this release, I have:

    1. Setup the infrastructure to map from generated code back to the source code so that we can report the location accurately in asp files. With that, I will be able to provide debugging experience using either Visual Studio or another CLR debugger fairly soon.
    2. If a file has multiple syntax errors, chances are that we are able to report all the errors at once. In contrast, Asp Classic only reports one error at a time. That is because our parser attempts to recover from the error and continue parsing the file. This is also essential for intellisence support in VS integration that will come in the near future.

    The next build will be in two weeks as I am preparing for my presentations at the LA Code Camp right after PDC. I have blocked two sessions to discuss the C# dynamic feature and the Dynamic Language Runtime. My first talk will be mainly on the C# dynamic feature and the second talk will be mainly on the Dynamic Language Runtime. Here are the abstract of the sessions:

    http://www.socalcodecamp.com/session.aspx?sid=ecbdbbc5-844b-4024-9012-b6ad8827546d and http://www.socalcodecamp.com/session.aspx?sid=7af7eb5a-913d-46fb-a3f8-144fdc77ed3c