click to rate:

## Channel Catalog

(showing articles 901 to 920 of 2297)
(showing articles 901 to 920 of 2297)

 Browse the Latest Snapshot Browsing All Articles (2297 Articles) Live Browser

## 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 | .... | 44 | 45 | (Page 46) | 47 | 48 | .... | 115 | newer

 0 0

I'm not sure about the web workers (but I don't think they're already available).

Have you already considered using a pool of active ClearScript engines, so to avoid recreating engines at every new iteration?

 0 0

Greetings!

V8 doesn't support (and actually blocks) concurrent access to a given runtime, but the application can spin up multiple runtimes and access them concurrently. Windows script engines are similar but more limited in that each instance must always be accessed from the same thread that created it.

In any case, it isn't ClearScript's goal to provide application infrastructure beyond script engine access. When it comes to concurrency, ClearScript doesn't dictate any specific model. Instead, it aims to make it easy to expose whatever model suits the application (or is already in use by the application) to script code, as long as it complies with the script engine's requirements.

Cheers!

 0 0

ClearScript wrote:
Hello querdenker,

It doesn't look like you're doing anything wrong. Can you say any more about the sort of work your scripts are doing?

Some general suggestions:​
• Make sure you're using the latest version of ClearScript. A number of memory leaks have been fixed since the last point release.
• Is it possible that your scripts are generating increasing amounts of data that is reachable from the global/root object?
I check this on the scripts I have here to test, but i can't check every script, that is executed by the users.
• Try to avoid script compilation as much as possible. Consider using compiled scripts or direct invocation of script functions to re-execute script code.
• We've found that when it comes to garbage collection, V8 is lazy to an extent that can get it in trouble. Consider invoking the garbage collector explicitly via ScriptEngine.CollectGarbage(true). Use a schedule that makes sense for your application - periodically or based on idle state, maximum invocation count, etc.
I had this idea before, but didn't implemted it yet. I give it a try.
• If all else fails, consider disposing the script engine and spinning up a fresh instance once in a while - again, using a schedule that makes sense for you.
Good luck!

 0 0

Hi again,

i can't check every script, that is executed by the users

If you're executing unknown or untrusted scripts, please note that a buggy or malicious script can easily corrupt the environment for subsequent scripts; e.g., by leaving data hanging off the root object, by altering built-in behavior with unexpected extensions, etc. If possible, consider creating a clean context for each script by re-instantiating V8ScriptEngine. If that's too expensive, you might be able to reuse one or more V8 runtimes (see V8Runtime.CreateScriptEngine()).

Cheers!

 0 0

ClearScript wrote:
Hi again,

i can't check every script, that is executed by the users

If you're executing unknown or untrusted scripts, please note that a buggy or malicious script can easily corrupt the environment for subsequent scripts; e.g., by leaving data hanging off the root object, by altering built-in behavior with unexpected extensions, etc. If possible, consider creating a clean context for each script by re-instantiating V8ScriptEngine. If that's too expensive, you might be able to reuse one or more V8 runtimes (see V8Runtime.CreateScriptEngine()).

Cheers!
I'm already use such a solution. I have a "Runtime-Pool" (inspired by another thread here ;) ) with a specific number of runtimes and from there I create new V8ScriptEngines for every new script executer, so that I have a defined resource usage, but also a clean environment for every executor.

Now back to my problem. I tried the solution with the schedule of the Garbage Collection and it seems to work. The memory usage looks good now. I will still have a look at it, but I think the problem is resolved ;)

 0 0

Hey guys!

First off I'd like to say awesome work on ClearScript!

Second is that I've got an example of live-in-browser script debugging via ClearScript V8 and SignalR.

It simply lets you write some JS code in a browser, eval it, and using the V8 hooks for debugging set breakpoints and when stopped at a breakpoint see the stack trace, eval immediate scripts, continue, step in, step out and so forth.

Give it a whirl!
https://github.com/Oceanswave/V8SignalRDebugging

 0 0

Hi,

this looks great. I will definitely give it a spin later today, thank you very much for the effort!

Kudos for taking the effort to implement the debugger protocol :)

 0 0

Nice work, Oceanswave! Thanks for sharing.

 0 0
• 08/13/14--14:24: New Post: Promises with V8
• Is there support for Promises/A like promises with Clearscript V8? (Chrome 32 has native support for promises, so I am assuming V8 does as well since chrome uses V8)

Or if not, how does one use When.js or Task.js with Clearscript V8.

Thanks!
Shrainik

 0 0
• 08/14/14--06:53: New Post: Promises with V8
• Hi Shrainik,

ClearScript's current release has been tested with V8 3.24, which doesn't have built-in promises enabled by default. Unfortunately neither does V8 3.26, which is the target for ClearScript's next release.

Until built-in promises are enabled in ClearScript, you should be able to use one of the available external implementations, perhaps with some modifications. Another possibility might be to leverage ClearScript's environment and implement the promise API pattern on top of .NET Tasks.

Good luck!

 0 0
• 08/14/14--11:46: New Post: Promises with V8
• The external implementation which I could find being closest to Promises/A proposal was task.js. But that relies on generators, which is again something which V8 3.24 doesn't support.

Any other suggestions would be really helpful.

Thanks,
Shrainik

 0 0

From my testing so far I've noticed that default properties are not being recognized as such when added to the script engine context via some object - take a look at Item property of Dictionary for example. Although it's not a major problem, it could lead to some unexpected errors during testing. Is there any way you could add a support for a default property recognition to the script engine?

 0 0
• 08/14/14--19:44: New Post: Promises with V8
• Hi again,

Lie is one possibility. Using it with ClearScript requires no modifications and only minor setup:
// setup
engine.Execute(@"
self = this;
setTimeout = function (func, delay) {
};
");

// run lie.js

// create a promise
engine.Execute(@"
x = new Promise(function (resolve, reject) {
});
");
You just need to provide a setTimeout() function that works with your application's async model.

As for modules, ClearScript doesn't define or depend on any particular solution, as it provides only low-level script engine integration. With .NET facilities at its disposal, the host should be able to implement or reuse whatever packaging scheme it requires.

However, because existing implementations often assume a browser or Node.js environment, the host may have to provide a bit of plumbing. You can find an a RequireJS example here, and one that sets up a CommonJS environment here.

Cheers!

 0 0

Hi maxshakirov,

Is there any way you could add a support for a default property recognition to the script engine?

Could you please clarify your expectations for this feature? That is, how would you expect it to change the way default properties are exposed and/or consumed? What new capabilities would it enable, if any?

Thanks!

 0 0

The expectation is the same as it is in the .Net framework. Consider following example:
Using engine As New V8ScriptEngine(V8ScriptEngineFlags.DisableGlobalMembers, V8ScriptEngineFlags.EnableDebugging, 9222)
engine.AddHostObject("testDict", New Dictionary(Of String, String) From {{"a", "1"}})
engine.Evaluate("console.WriteLine('testElement = {0};', testDict.Item('a')); console.WriteLine('');")
End Using
In the code above I'm simply outputting a value of the dictionary item found by key, testDict.Item('a'). Note that .Item is a default property in case of dictionary, so I was expecting I can do the following (the only difference is how I'm trying to access the dictionary item):
...
engine.Evaluate("console.WriteLine('testElement = {0};', testDict('a')); console.WriteLine('');")
...
For me this is not a big deal in particular, it's just the observation of behavior vs. the expectation on my end.

 0 0
• 08/15/14--09:30: New Post: Promises with V8
• Thanks! Let me try this out.

 0 0
• 08/15/14--14:46: New Post: Scaling V8
• Hi Again,

I am working on a project which would require a lot separate javascript execution contexts.
Right now I am using V8 Runtime and am creating multiple engines inside it for each JS Execution context. But this scales very poorly.

25000 Engines divided across 25 runtimes take up 11GB of memory. (Jurassic execution engine takes 9GB for 50000 engines, however I switched to Clearscript V8 because of richer .Net support and better performance, but now I want to scale with this performance as well)

Is there a way I can have multiple js contexts within a single engine (something like V8 isolates?)?
Or what are other ways to reduce the memory usage?

Thanks,
Shrainik

 0 0

ClearScript doesn't provide any syntactic shortcuts for accessing default members.

This is particularly noticeable with indexers, which currently must be accessed by name. For example, host dictionary indexers are actually named "Item" and support the following syntax (JavaScript):

 JavaScript
value = dict.Item(key);
value = dict.Item.get(key);
dict.Item.set(key, value);


Because Item is a default property, it might also make sense to support one or more of the following:

 JavaScript
value = dict(key)
value = dict.get(key)
dict.set(key, value)


Default methods, though rarely used, might also benefit from special handling.

 0 0

Hi maxshakirov,

Thanks for clarifying. Your feature request seems reasonable; we're tracking it here.

Cheers!

 0 0

ClearScript doesn't provide any syntactic shortcuts for accessing default members.

This is particularly noticeable with indexers, which currently must be accessed by name. For example, host dictionary indexers are actually named "Item" and support the following syntax (JavaScript):

 JavaScript
value = dict.Item(key);
value = dict.Item.get(key);
dict.Item.set(key, value);


Because Item is a default property, it might also make sense to support one or more of the following:

 JavaScript
value = dict(key)
value = dict.get(key)
dict.set(key, value)


Default methods, though rarely used, might also benefit from special handling.

older | 1 | .... | 44 | 45 | (Page 46) | 47 | 48 | .... | 115 | newer