You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 9, 2019. It is now read-only.
Copy file name to clipboardExpand all lines: README.md
-125Lines changed: 0 additions & 125 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -93,131 +93,6 @@ There are three possibilities to load the library
93
93
94
94
95
95
96
-
**Summary:** A fairly non-abstracted wrapper for Google's V8 JavaScript engine.
97
-
98
-
What does that mean? Well, most other existing wrappers abstract most of the Google V8 engine's abilities away from you. That's fine for simple tasks, but wouldn't you rather have full control over the power of the V8 engine from managed code?
99
-
100
-
I've carefully crafted a C++ proxy wrapper to help marshal fast communication between the V8 engine and the managed side. One of the biggest challenges (which actually turned out to be simple in the end) was storing a field pointer in V8 objects to reference managed objects on call-backs (using reverse P/Invoke). A special custom C# class was created to manage objects in an indexed array in an O(1) design that is extremely fast in locating managed objects representing V8 ones.
101
-
102
-
Interesting note: I was carefully considering future portability to the Mono framework as well for this project, so great care was made to make the transition as seamless/painless as possible. ;)
103
-
104
-
**License Clarification**
105
-
106
-
The license is LGPL. In a nutshell, this means that you can link to the libraries from your own proprietary code, but if you modify the source files for anything in this project, the modified source and executables from it must also be made freely available as well (and you must clearly state you modified the code).
107
-
108
-
**Coming in Next Release (updated on August 7, 2013):**
109
-
110
-
* Attempting to make it easier to deal with accessing nested properties/objects.
111
-
* Looking into creating a system to allow easy binding (exposing) of C#/.NET objects to the JavaScript environment.
112
-
* Created a new function '{V8Engine}.LoadScript(string scriptFile)' to make it easier to load JS files. :)
113
-
* Integrating V8.NET into the client/server solution "DreamSpaceJS/Studio" (my answer to Microsoft abandoning Silverlight). This will also help refine the V8.NET system in the process. Scirra (Construct 2) has donated a license to help the project.
114
-
* Added methods to make it easier to bind existing .NET object instances and types to the V8 JS environment.
115
-
***Possible Breaking changes: Handles now have full access to the native objects without having to create a V8NativeObject instance. In fact, V8NativeObject now wraps a Handle and redirects dynamic requests to it, and both Handle and InternalHandle implement the same methods for working on the native JavaScript objects. This was done to allow dynamic property access on the handles without having to create another object to do it. This change slightly affects the members and functionality of the V8NativeObject - but mostly behind the scenes. This is still a WIP, so more things may break, but the end goal is to allow accessing objects easily using a chain of property names, such as 'a.b.c.d...'.**
116
-
* V8NativeObject will now have a generic object (V8NativeObject<T>) version to allow injecting your own objects into it instead. I want to get rid of the internal "_ObjectInfo' objects that hold member data that really should be in the object itself. This will mainly affect only those who need to implement the interface (IV8NativeObject) instead of inheriting from V8NativeObject. Under the new system, when initialized, you just cache a pointer to the 'V8NativeObject' instance wrapping your object.
117
-
118
-
**Completed Updates**
119
-
120
-
Added support for .NET 3.5. I used some fancy build configurations to compile both in the same solution. ;) The only difference, as it pertains to this project, is that .NET 3.5 and under does not support "DynamicObject" (nor the dynamic type), and default parameters are not supported.
121
-
122
-
Looks like some people have issues with the DLLs loading. I've made this better and have a more descriptive error to help correct the issues. :)
123
-
124
-
I spent a lot of time on the performance of the system and have been able to increased it quiet a bit. I have some simple garbage collection and performance testing scripts now that can be run from the console.
125
-
126
-
I'll also be looking into the WebRTC SDK in the near future as well to help support networkable servers that are compatible to the supported browsers (currently Chrome and Firefox).v8dotnet
127
-
========
128
-
#[This is a V8.Net port to Mono](https://v8dotnet.codeplex.com/).
129
-
130
-
The Repository contains the following branches:
131
-
- Master (stable releases for windows)
132
-
- development (bleeding edge development changes)
133
-
- development-mono (bleeding edge development changes for mono)
134
-
135
-
#Building V8.Net
136
-
137
-
Prerequisites
138
-
Make sure git and git-svn are installed. To install using apt-get:
139
-
`apt-get install git git-svn`
140
-
141
-
This project contains Csharp and cpp projects. We using MonoDevelop to build the Csharp projects and g++ via commandline to build the cpp project.
142
-
To speed up this process you can also use the `build_V8_Net.sh`.
143
-
To build the projects execute the script **within** the `v8dotnet` directory.
5. Build V8.NET-Proxy library, on windows the library is called `V8_Net_Proxy_x64.dll` on Linux it is called `libV8_Net_Proxy.so`. We start by compiling the cpp from `/Source/V8.NET-Proxy/` to object files into an output directory called `/Source/V8.NET-Proxy/out`.
7. After we have the object files we need to build a shared library called `libV8_Net_Proxy.so`. Copy the following files from `/Source/V8.NET-Proxy/V8/out/native/lib.target/*.so` into your output directory `/Source/V8.NET-Proxy/out`.
164
-
- libicui18n.so
165
-
- libicuuc.so
166
-
- libv8.so
167
-
168
-
8. Compile the shared library with the following command. Execute it within your output directory.
11. The last step is to copy all files into one directory
184
-
185
-
12. Release Directory
186
-
- libicui18n.so
187
-
- libicuuc.so
188
-
- libv8.so
189
-
- libV8_Net_Proxy.so
190
-
- V8.Net.dll
191
-
- V8.Net.Proxy.Interface.dll
192
-
- V8.Net.SharedTypes.dll
193
-
- V8.Net-Console.exe
194
-
- V8.Net-Console.exe.config
195
-
13. Start it with `mono 8.Net-Console.exe`.
196
-
14. For debugging errors these commands can be helpful.
197
-
-`LD_LIBRARY_PATH="pwd" MONO_LOG_LEVEL=debug MONO_LOG_MASK=all mono V8.Net-Console.exe` for checking if the library gets loaded.
198
-
199
-
-`nm -u -C libV8_Net_Proxy.so` checking for undefined symboles.
200
-
201
-
### Loading the `libV8_Net_Proxy.so` library
202
-
There are three possibilities to load the library
203
-
- adding it in the same place where the executable is. For instance:
204
-
- V8.Net-Console.exe
205
-
- libicui18n.so
206
-
- libicuuc.so
207
-
- libv8.so
208
-
- libV8_Net_Proxy.so
209
-
- adding it in the /usr/lib directory
210
-
- libicui18n.so
211
-
- libicuuc.so
212
-
- libv8.so
213
-
- libV8_Net_Proxy.so
214
-
- or setting the `LD_LIBRARY_PATH="pwd" path.
215
-
216
-
217
-
218
-
219
-
220
-
221
96
**Summary:** A fairly non-abstracted wrapper for Google's V8 JavaScript engine.
222
97
223
98
What does that mean? Well, most other existing wrappers abstract most of the Google V8 engine's abilities away from you. That's fine for simple tasks, but wouldn't you rather have full control over the power of the V8 engine from managed code?
0 commit comments