Quantcast
Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Showcase


Channel Catalog



Channel Description:

ClearScript is a library that makes it easy to add scripting to your .NET applications. It currently supports JavaScript (via V8 and JScript) and VBScript.

older | 1 | .... | 39 | 40 | (Page 41) | 42 | 43 | .... | 115 | newer

    0 0

    Update posted here.

    0 0

    I have been using ClearScript in a Project for a while and have been using a simple cleanup operation of "engine.Dispose(); engine = null;"
    Looking at your included "ClearScriptConsole" I notice you have a "using { }" and that is all.

    So my question is what is the correct method to ensure all resources are Cleaned Up so that if I create the ClearScript engine several times I am not consuming resources.

    My question stems from the assumption that I am doing something wrong as each iteration of the ClearScript engine that I execute results in a different engine.name value
    eg 5 different calls of my "using { }" version of calling engine.Execute resulted in this below and I got the same using Dispose and also when adding GarbageCleanup(true).

    Engine Name : V8ScriptEngine
    Engine Name : V8ScriptEngine [2]
    Engine Name : V8ScriptEngine [3]
    Engine Name : V8ScriptEngine [4]
    Engine Name : V8ScriptEngine [5]

    0 0

    Hi egooner,

    Calling the Dispose() method - either directly or via the using statement - is sufficient. If you don't do that, .NET's garbage collector will eventually take care of it, but it may take a long time.

    As for engine names, "V8ScriptEngine [5]" refers to the fifth engine you've constructed with the name "V8ScriptEngine" during the current process's lifetime. It doesn't mean that there are five script engines currently active.

    Cheers!

    0 0

    Thanks for the feedback. I had hoped this was the case but was concerned that there is clearly tracking of the different instances having been created between NEW Engines telling me something was still around.

    0 0

    I was hoping to use ClearScript for adding JavaScript to a game written with MonoGame. Is there any chance that you could release a portable version which includes the V8 engine?

    What are the challenges involved? It looks like it would be a significant undertaking, and perhaps there's better hope for an IL-only JS engine (maybe Jurassic would be easier).

    ClearScript is fantastic, by the way :)

    0 0

    Hello reubenbond!

    Unfortunately Mono doesn't support mixed-mode assemblies such as ClearScript's V8 interface (ClearScriptV8-*.dll). We'd like to redesign that layer eventually, but that effort is not currently planned. ClearScript also depends heavily on the C# Runtime Binder, an API that Mono doesn't seem to support.

    Have a look at Jurassic, Jint, and V8.NET. And thank you for your kind words!

    0 0

    I noticed some performance issues with the usage of ScriptItem.
    What I did was I had a constructor which received a script item as argument. And because ScriptItem has accessors set to internal, I had to use it as DynamicObject or dynamic.

    What I wanted was to create a flat table of the object, just by getting the object keys as column name and their values as row values. The Properties are retrieved with the "GetDynamicMemberNames()" function, so no problems there. But for each of the properties I needed to create a Binder and get the value (see code below)

    Now anybody can guess that this is not very fast. I tried to create a simple table with 3 rows and 13 columns. And it took a good +/- 1500 milliseconds on one run. I did the same with JSON.net JObject and because accessing properties isn't such a hassle their I got a performance of 0 milliseconds on one run. My temporary fix is that I call JSON.stringify before the constructor and in the constructor I uses JSON.NET his parser.

    Anyway, my question or point of discussion: Isn't ScriptItem flawed by design? Why the use of dynamics? Take a look at how JSON.net encodes JS objects with strict types. In essence are all JS Objects KeyValuePairs where the Value types can vary.

    Or am I doing something terrible wrong?
    publicvoid ParseDynamic(DynamicObject o) {
                
                var props = o.GetDynamicMemberNames();
    
                bool isArray = true;
                // try cast to inttry {
                    foreach (var k in props) { Int32.Parse(k); }
                } catch { isArray = false; }
    
                if (!isArray)
                    AddRow(o);
                else {
                    foreach (var k in props) { AddRow((DynamicObject)GetMember(o, k)); }
                }
    
    
            }
    
    privatevoid AddRow(DynamicObject obj) {
                var cols = obj.GetDynamicMemberNames();
                var row = new MiDataRow(this);
                rows.Add(row);
    
                // Add all columnsforeach (var col in cols) {
                    if (!columns.Contains(col)) {
                        columns.Add(col);
                        ResizeRows();
                    }
    
                    row[col] = GetMember(obj, col).ToString();
                }
    
            }
    
    privatestaticobject GetMember(DynamicObject o, string propName) {
                var binder = Binder.GetMember(CSharpBinderFlags.None,
                      propName, o.GetType(),
                      new List<CSharpArgumentInfo>{
                                   CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null)});
                var callsite = CallSite<Func<CallSite, object, object>>.Create(binder);
    
                return callsite.Target(callsite, o);
            }

    0 0

    Hi blackshade,

    Why the use of dynamics?

    .NET's dynamic infrastructure provides a convenient way to access script objects in a way that's both .NET-friendly and engine-neutral. A dictionary-style interface might also be convenient, but it's not clear what advantage it would have over the combination of GetDynamicMemberNames() and dynamic indexing.

    The problem with your GetMember() method is that it recreates the binder and callsite each time. Try this instead:
    privatestaticobject GetMember(object o, string propName) {
        return ((dynamic)o)[propName];
    }
    This implementation is simpler and takes advantage of inline caching to speed up repeated calls. In our experiments it's about 22x faster on average in Release builds.

    Still, using JSON tunneling as you suggest makes sense in many cases. ClearScript provides live access to script objects, but if all you need is a snapshot, then JSON is a great way to minimize marshaling and improve performance.

    Thanks for your question, and good luck!

    0 0

    Thank you for the reply.
    I will try and benchmark your suggestion and post the results below.

    0 0

    Ok thanks!

    It is still +/- 60 milliseconds (ScriptItem) against +/- 3 milliseconds (String -> Json.net) on the initial run. But after that the JIT has optimized both to nano seconds.
    So thanks! These differences can be explained by the fact that on the first run the JIT will optimize a part of the code path the seconds also takes.

    I will look more into it and do some better benchmarks to see which one is really faster. Still I expect that the String version is faster.
    If that is the cast that really is such a shame.
    But more on this later, thanks anyway!

    0 0

    Ok I did some more benchmarking and I did the following, where rec is a flat json object.
    var arr = [rec, rec, rec];
        var strJson = JSON.stringify(arr);
        new MiTable("form", arr);
        new MiTable("form", strJson);
    
    
        startTime();
        for (var i = 0; i < 1000; i++)
            new MiTable("form", strJson);
        stopTime();
    
        startTime();
        for (var i = 0; i < 1000; i++)
            new MiTable("form", arr);
        stopTime();
    Both the strJson and the JSON function implement the same idea, but the strJson de-serialises the string, and still managed to be faster.
    My point stays, isn't it better to not make ScriptItem dynamic. Because within Javascript all object can be of fixed types and all objects are key value pairs anyway. Or maybe is it possible to make use of JSON.net JObject instead of dynamic ScriptItem? Even translating the ScriptItem to JObject results in a higher benchmark than the above benchmark.

    Anyway, thanks for your time and I hope you can do something with my findings.

    0 0

    Hi blackshade,

    The purpose of a script item in ClearScript is to allow .NET code to access an actual "live" script object, as opposed to a serialized copy of its data.

    Yes, it's definitely faster to read data from a managed collection such as a Json.NET JObject or a standard .NET dictionary - and if reading a script object's properties quickly is what you need to do, then we encourage and recommend JSON tunneling. Hopping the boundary between the managed and script environments is expensive, and JSON lets you transfer an entire object's data in one hop.

    However, this is very different from what script items do. Some examples:
    • Writing to a script item modifies the actual script object to which it's bound.
    • Unlike JSON, script items provide access to JavaScript properties that are not enumerable.
    • Script items invoke property getters and setters as necessary.
    • Script items that are functions can be invoked to execute script code.
    • Script items provide access to script objects that aren't JSON-friendly (e.g., VBScript objects).
    Cheers!

    0 0

    Hi,

    Ahh I see, I thought you would only get a snapshot of the given script item. But if you would run the script async of the c# code, the changes in scriptitem would be live.

    I didn't think about that. The structure of the ScriptItem makes a whole lot of more sense to me now.

    Thank you again sir! I will stick to my JSON tunneling because that is what I need.
    If I haven't said so: Nice work on this project, love it.

    0 0

    Hi, I'm also looking to use this cross platform and have been looking at alternatives for a while, but so far Clearscript is the only one that does things the way I want it to. It was a real bummer when I noticed it only worked on Windows.

    How does V8.NET do it, since their library works on other platforms? What are they doing different?

    I was going to compare to see if I could make the clearscript v8 work with v8.net's implementation, but my lack of c++ knowledge would be like climbing a mountain for me.

    I really hope that you'll make it work cross platform soon!

    0 0

    Thanks for your feedback!

    0 0

    Hi Cadavre,

    How does V8.NET do it, since their library works on other platforms? What are they doing different?

    The difference has to do with the way these projects interface managed code with native code. Our understanding is that V8.NET uses P/Invoke with the managed and native sides residing in separate assemblies, whereas ClearScript uses mixed-mode assemblies that house both managed and native code.

    Mono doesn't support mixed-mode assemblies on non-Windows platforms, and unfortunately this isn't just a matter of binary packaging. It affects how the marshaling code is written, and this is why creating a Mono-friendly version of ClearScript is not a trivial task.

    Another issue for ClearScript is its reliance on the C# Runtime Binder, an API that Mono doesn't seem to support, although it does have other APIs that might provide a suitable alternative.

    Cheers!

    0 0

    Thanks for the quick response! I hope you will eventually make it work cross platform, ClearScript is really good!

    0 0

    By the way, I stumbled upon this thing called swig (http://www.swig.org/) while looking into using RakNet.
    Quote from the RakNet documentation:
    What is Swig?

    Swig is an application that generates wrapper code for a native DLL to interface with other languages allowing you to use a C/C++ library in one of the supported languages. Currently Swig configuration for RakNet is set up to generate a managed interface that can be used in managed C# in Windows, as well as in Linux with Mono.

    Swig generates a CXX and .h file, which exposes interfaces that can be used by the target language. The CXX file is included when building the C++ dll that the target language uses.

    Swig also generates files in the target language for inclusion in the project of the target language to interface with the dll. These are added to the project of the target language.
    Could this be of any use?

    0 0

    Thanks Cadavre! We'll take a look, but the issue isn't interop as much as it is the redesign and re-implementation of the ClearScriptV8 layer.

    0 0

    Yeah, okay, but it might still be useful! :)

older | 1 | .... | 39 | 40 | (Page 41) | 42 | 43 | .... | 115 | newer