I tried looking for a similar question, but couldn't find one.
I have a ASPNET1.1 web application that is business-oriented. And there are many rules which are hardcoded in the application.
I want to start using Boo as an scripting language which developers can use to write some logic there (not final users).
Whenever a change in the BL is done, I would just update the "script file", deploy to server and that's it. No need for compilation. This is important.
So I have two questions:
It seems only CS-Script and Boo support NET1.1 and I don't like CSScript because it requires an exe or a compiled dll for each script. Is Boo the right choice? I wanted to use JINT (NET2.0+) or LUA (couldn't find a way to import to C#).
How fast is to execute Boo? I don't want to compile it (I know this is fast since it will be a static language). I want to only use the Boo interpreter Eval function.
By the way, the business logic I want to execute is simple. It should only be something like:
function(a, b)
{
return a["Type"] == b["Type"];
}
where a and b are simply Hashtables or DataRow. So I actually don't really need the System imports and all that.
Thanks in advance
I'm discarding Boo because even though I wanted to only use the Eval method, Boo automatically compiles the expression and loads that Assembly generated into the AppDomain.
Since I'm running in ASPNET1.1 and a big web application (thousands of users) that will not be efficient nor fast.
Even if I create an internal AppDomain and run the script in there so the memory is restored.
If I run in the same AppDomain, the memory would be eaten and eaten because those new assemblies will be loaded and never unloaded.
So I guess from Ricardo's response on some forums, that was never the intention of Boo language being designed as CLR language, but it beats the whole "scripting" halo put around Boo.
This is a big boo for Boo :(
I just tested LuaInterface 1.3.0 (the last one that supports NET1.1) and it has footprint zero. No assemblies are created and is just plain better in general (more javascript-like, no footprint, etc).
I just hope 1.3.0 version will be stable enough. There is no way I can upgrade my app to NET2.0 in the near future.
IMPORTANT UPDATE:
LuaInterface and luanet had a lot of memory leaks!!!! Instead I linked directly to the lua52.dll by using DllImport and using as a basis the following file: https://simpleot.googlecode.com/svn-history/r32/SimpleOT/trunk/SimpleOT/Scripting/Lua.cs
I used lua52 because it had support for VC++2003.
Related
As we know, there are two methods of library loading.
1) Static libraries (.a): Library of object code which is linked with, and becomes part of the application.
2) Dynamically linked shared object libraries (.so), which will link at execution of application and it can be used in two ways.
a) Dynamically linked at run time but statically aware.
b) Dynamically loaded/unloaded and linked during execution (i.e. browser plug-in) using the dynamic linking loader system functions.
After compilation, we can check the library dependency of type 'a' as below
objdump -x usr/bin/flashcp
.....
Dynamic Section:
NEEDED libgcc_s.so.1
NEEDED libc.so.6
My question is how to check/detect type 'b' library dependency ? Please suggest is there any way to detect before execution ?
Thanks in advance
Thiru
There's no way to generally check for libraries that are loaded dynamically and whose functions are called via function pointers.
In some special cases, as a hack, you can attempt various ways of reverse-engineering the executable, e.g. statically analyzing code around the calls to LoadLibrary and GetProcAddress on Windows. You could derive some heuristics that would work on many executables, but there's no way that's guaranteed to work, other than executing the code in a virtual machine and intercepting all calls to LoadLibrary/dlopen as they happen.
I am writing a Qt application that calls QProcess::startDetached("wscript.exe script.vbs") to show the delete confirmation dialog in Windows.
this is the script:
Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace("-")
Set objFolderItem = objFolder.ParseName("-")
objFolderItem.InvokeVerb("Delete")
the arguments for Namespace and ParseName are from the arguments passed to the script.
This may be inefficient because it opens an external application first before running the script. I was wondering if i can run VBScripts in a Qt application.
If not, what alternatives can i do?
My VBScript is very weak, so I'm not 100% sure I understand what you are trying to do. My assumption is that you are trying to delete a folder, but want to give the user the normal confirmation box and animation while the action is occurring. If that is not correct, please let me know and I will remove this answer.
A few ideas:
You could call the Windows API directory within your C++ code to do this. I believe the correct call would be to use IFileOperation (Vista and later) or SHFileOperation (pre-Vista)
Qt already has message box dialogs. Although you might not get the exact same functionality as the native shell, you could use this (QMessageBox::warning) and then delete the folder using QDir. This would also be cross-platform portable.
If you stick with the VBScript, I doubt you would see any performance issues unless this is being called many, many times in a loop or something. You know, the old "premature optimization is the root of all evil" thing.
You should read up on the IActiveScript COM interface. You can create an instance of an interpreter that implements IActiveScript to provide a runtime for evaluating scripts. VBScript and JScript can both be used for this and a number of other third-party scripting languages also provide IActiveScript support.
The overview for working with this is you create a language runtime (an instance of VBScript for instance) then add some custom objects to it. Typically if you are embedding an interpreter into your application then exposing an Application object is a good place to start. This can be just an IDispatch interface or something more concrete with an IDL generated typelibrary and all the trimmings. Once you have added the necessary named items into the runtime you load one or more scripts. Any public functions or subroutines declared in the scripts now get exposed via the IDispatch interface of the live runtime once you switch its state to active or running. To actually run the script program, I invoke the Main function for my stuff - you could choose some other scheme as applicable to your environment.
The nice thing about ActiveScripting, is to change language you just change the runtime CLSID. So if people prefer Perl they can use PerlScript or PythonScript etc. Your Application object remains the same hence you don't have to write additional code to support the new languages. The only requirement is that everything is COM.
I'd like to be able to write a .swf file that is runnable as a command line app. In other words, I would be able to create actionscript classes which can interact with stdin and stdout, and could then execute that .swf directly in the command line.
I suspect that this isn't really possible. Can anyone confirm that?
EDIT:
A couple of the answers pointed out that using Flash for command line work probably isn't the best choice. I wholeheartedly agree in most situations. The reason I am asking about this is because I want to do some AS3 code generation, and reflecting on AS3 classes within the runtime would be easier than parsing the code or walking the intermediary XML that asdoc produces. I'm doing the XML approach now in Ruby, but would love to have a cleaner solution!
YES! It actually is possible.
You can create a pure AS3 AIR project (without any application window) and run from the command line using ADL (AIR Debug Launcher).
ADL will execute your SWF and will pass whatever arguments you give it directly to your application at runtime—all from the command line! To read the arguments from AS3 just add this code to your main class:
package
{
import flash.desktop.NativeApplication;
import flash.display.Sprite;
import flash.events.InvokeEvent;
public class CmdLine extends Sprite
{
public function CmdLine()
{
NativeApplication.nativeApplication.addEventListener(
InvokeEvent.INVOKE, onInvokeEvent);
function onInvokeEvent(invocation:InvokeEvent):void {
trace(invocation.arguments);
}
}
}
}
Your main class will still extend Sprite, but you won't see any UI unless you create NativeWindow objects. If you're using Flash Builder, just create a new AIR project and rename the extension of the main .mxml file to .as (before you finish the wizard).
Here is more about ADL: Using the AIR Debug Launcher (ADL)
Also, this will be very useful: AIR application invocation and termination
You can do all your output using trace(), write files, or even write directly to stdout, as seen here.
Apparently there is the Tamarin project which aims to create an open source implementation of AS3. This page gives a little detail of compiling an AS3 script and running it from a command line.
I'm not getting a good idea of how stable Tamarin is, but it might be your best bet for now. On the other hand, I have to strongly agree with #zenazn that you would be better off long-term learning a language more designed for general purposes, but if really want to just use Actionscript, don't let anyone stop you :)
There's no way to do this with a bare SWF right now.
However, you can publish your Flash content as an AIR app. The app can then be invoked from the command line, and you can collect the arguments from the arguments property of an InvokeEvent. The basic idea looks like this:
NativeApplication.nativeApplication.addEventListener(
InvokeEvent.INVOKE, onInvoke );
// ...
function onInvoke( e:InvokeEvent ) {
var numArguments:int = e.arguments.length;
// ...
}
Note, however, that this is essentially a one-way street. You can grab the command-line arguments, but Flash still doesn't grok the idea of stdin and stdout.
Actually, there is a project that makes it possible. RedTamarin is a project that extends AS3 (technically, the Tamarin project which is the Adobe/Mozilla ECMAScript project) to have access to low-level libraries (ie. POSIX). In its current state it appears to be good for stuff like shell-scripting-like programs which is what it sounds like what you're looking for.
Give it a try:
http://code.google.com/p/redtamarin/
You can interact with stdin, stdout and stderr with redtamarin
http://code.google.com/p/redtamarin/
see examples/docs here
http://code.google.com/p/redtamarin/wiki/System#stdout
http://code.google.com/p/redtamarin/wiki/System#stderr
http://code.google.com/p/redtamarin/wiki/System#stdin
there is a difference between Flash and ActionScript 3
Flash is a runtime, AS3 is a language
I don't see why AS3 would not be a good programming language
for the command line and/or the server side
Now, redtamarin is just that, a runtime that allow you to
run your AS3 source code on the command line.
Also, depending on your needs, you can use it in different ways
to run script on the command line
$ ./redshell myscript.as
run ABC or SWF files on the command line
$ ./redshell myscript.abc
$ ./redshell myscript.swf
run an exectuable
$ ./myscript
When you will run an AS3 script it will be dynamically interpreted,
using ASC you will be able to compile this same script to an ABC file
that can also be run from the command line.
If for example you need to assemble numerous ABC files together,
you can use swfmake to merge them into SWF file and the runtime
will run that SWF file too from the command line.
Finally, if you need to bundle everything in one executable,
you can use createprojector to take your ABC or SWF file
and merge it with the runtime itself to obtain an independent
executable.
Redtamarin provide native API that cover file system access,
sockets, operating system info, etc.
Now it is possible with AIR 2.0. Check this article to start.
If you are really that inclined, you could open a local socket, and then have a helper program, running from the command-line communicate with the open SWF.
This might be a good time to learn another language. May I suggest Java?
I had a similar question recently. It took me a few days to answer it for myself, but you can create a .swf and execute it entirely from the command line.
AS3 Filesystem Hello World
You could have a look at Haxe with is very similar to AS3 and could compile NekoVM Bytecode, which could be run on the command line.
Also interesting could be HippoHX, it is a kind of framework to create desktop applications out of flash movies. (similar to AIR, but with full access to the system.)
Nope--not possible. The best you can do is a standalone app (which can be made in Flash or with a Projector version of flash player, available from the Adobe website).
And why would you want to--Flash is awesome because of the great GUI capabilities. There are plenty of other programming languages that are much better suited for the command line (Python or Ruby or, god forbid, even Perl)
I'm using selenium to run some functional tests on the UI for our current application.
I want to ensure that strings from the resource files in the Web project are being displayed at the correct time and place.
Simple (I thought) all I have to do is reference the assembly of the web application and assert that the text selenium is reading from the UI matches the test in the approriate resource file.
The problem is the ASP.Net does some precomilation processing on the resource files and compiles them into an assembly called App_GlobalResources, which isn't created by the normal build process so the functional tests fail because that can't find the App_GlobalResources assembly to look the string up from.
So, any suggestions? Do I need to abandon the App_GlobalResources approach and do something manual that I have control over?
Do you understand the problem or do I need to provide more info?
My interim solution is to use SVN:Externals to pull a copy of the resx files into the test project.
I can then access them via
ResourceManager resource = new System.Resources.ResourceManager("My.Web.Namespace.resources.ImageUrls", Assembly.GetExecutingAssembly());
Its ugly because I already have a reference to the webproject (which I can probably remove now...) and I don't like mixing source files between projects. It just feels like asking for trouble but until someone suggests something better this will have to do.
Have you considered moving your GlobalResources into a separate assembly and then referencing that from both your web project and your test project? This is quite easy to do in VS 2008, and achievable but a little more difficult in VS 2005.
I was able to solve a similar problem using that approach.
I'm sure there's a simple explanation for this, but I haven't had much luck at finding the answer yet, so I figured I'd put the word out to my colleagues, as I'm sure some of you've run into this one before.
In my (simple) dev environment, I'm working with a handful of WCF Web Services, imported into my FB3 project and targeting a local instance of the ASP.NET development Web server. All good, no problems -- but what I'd like to know now is, What's the right way to deploy this project to test, staging and production environments? If my imported proxies all point, say, to http://localhost:1234/service.svc (from which their WSDLs were imported), and all I'm deploying is a compiled SWF, does Flex Builder expect me to "Manage Web Services > Delete", "> Add", recompile and release ever time I want to move my compiled Flex project from development to test, and to staging, and ultimately into production? Is there a simpler workflow for this?
Thanks in advance -- hope my question was clear.
Cheers,
Chris
If you have path names which will change depending on the enviroment then you will likely need to recompile for each environment since these will be compiled in the swf.
I typically use ANT scripts to handle my compile/deployment process when moving from development and production environments. This gives me the ability to dynamically change any path names during the compile. These build files can be integrated into Flex Builder making this process very easy once you have everything set up, and can be done with one click or scheduled.
Thanks Brett. I've been meaning to dig into automating my build processes anyway, so now's probably as good a time as any. :)
You do not need to build a SWF for each environment. Here's a technique I use commonly:
Externalize your configuration properties into an XML file; in this case, it could be a URL for each service or a base URL used by all your services
When the application starts up, make an HTTPService call to load the XML file, parse it, and store your properties onto some bindable "configuration object"
Bind the values from that object against your objects that depend on the URLs
Dispatch an event that indicates your configuration is complete. If you have some kind of singleton event dispatcher used by some components in your app, use that, so that the notification is global
Now proceed with the rest of the initialization of your application
It takes a little work to orchestrate your app such that certain parts won't initialize until steps 1-5 take place. However I think it's good practice to handle a lot of this initialization explicitly rather than in constructors or various initialize or creationComplete events for components. You may need to reinitialize things when a user logs out and a different user logs in; if you already have your app set up to that initialization is something you can control then reinitialization will not be a problem.