The following video shows a technique I used to remove some distracting elements from the original shots of this album.
Sunday, November 29, 2009
Sunday, November 22, 2009
How to enable Ruby debug in RubyMine 2.0 on Windows
I recently had the chance to evaluate JetBrains' RubyMine. I was well impressed by this IDE except for the impossibility to debug Ruby code.
However I didn't gave up and, googling a bit, I found a thread inside JetBrains Developer Community that helped me to fix my installation and finally to debug Ruby code inside RubyMine.
Although the entire procedure is fully described in that thread, I think is worth summarizing the fundamental steps to fix the environment.
Let's start from a scenario where Ruby 1.9 has been installed with the one-click installer and RubyMine 2.0 has been installed too. (If you installed Ruby with the zip binary, reinstall it using the one-click installer as found here. That's because currently the ruby debugger ide only works on Windows using a RubyInstaller installation). Also verify that Ruby's root path doesn't include spaces.
- Download Ruby DevKit. (The links brings you to a .7z file, that you can open with 7Zip).
- Open the .7z file and follow the instructions in INSTALL file: basically they said to extract top-level folders (i.e. bin and devkit) to the Ruby's root folder and to modify the contents of fstab file according to your installation. In my case, my Ruby folder was: C:\programmi\ruby19, so my fstab file contents became:
C:\Programmi\Ruby19\devkit\gcc\3.4.5\mingw32 /mingw
C:\Programmi\Ruby19\devkit\msys\1.0.11\usr\local /usr/local - Execute the command gem install ruby-debug-ide19
(Note that's fundamental to install ruby debug ide as ruby-debug-ide19 because RubyMine looks for a gem with name ruby-debug-ide19 and not ruby-debug-ide, as you would expect). Also be patient because the command takes a while to complete. - Open with a text editor the file command.rb that's part of the installed ruby-debug-ide19 gem. In my case, that file was under folder C:\Programmi\Ruby19\lib\ruby\gems\1.9.1\gems\ruby-debug-ide19-0.4.12\lib\ruby-debug
- Modify the beginning of procedure debug_eval (at line 120) so to enter a new statement between statements str = str.to_s and max_time = 10. The new statement to enter is:
return "" if str == "$FILENAME"
At the end, the procedure debug_eval should begin like this:
def debug_eval(str, b = get_binding)
begin str = str.to_s
return "" if str == "$FILENAME"
max_time = 10
to_inspect = str.gsub(/\\n/, "\n") - Save the file
That's it. Enjoy Ruby debugging with RubyMine!
Friday, November 13, 2009
How to install the current Flash player into Chrome Portable/Firefox Portable on Windows
- Download the current Flash Player as xpi package from http://fpdownload.macromedia.com/get/flashplayer/xpi/current/flashplayer-win.xpi
- Rename the package's extension from .xpi to .zip
- Open the zip package and extract files flashplayer.xpt and NPSWF32.dll.
- For Chrome Portable: put extracted files into folder Chrome\plugins
- For Firefox Portable: put extracted files into folder App\Firefox\plugins
- (Re)start your browser
- Type about:plugins in the address bar
- A list of installed plugins appears. Verify that Shockwave Flash is present and that there is an entry with MIME type application/x-shockwave-flash and suffix swf.
Saturday, January 31, 2009
Flash Player SecurityError: Error #2060
This post starts with a security error echoed by Flash Player: I'm talking about Error #2060, an error that is associated with the use of ExternalInterface.call.
For those of you that just don't remember what ExternalInterface is responsible of, I have to say that this class allows ActionScript to "talk" with the Flash Player container: in my current example, I was calling a JavaScript function from inside ActionScript. My idea was to allow ActionScript to run a user-specified Windows program through the intermediation of the ActiveX WScript.Shell, instantiated in a IE-managed HTML page.
So, the code for the ActionScript part looked like this:
... and inside HTML page I had this JavaScript fragment:
The idea here is not obvious, but pretty simple: the user enters a program name in a Flex TextInput, then presses the Enter key and voilĂ ... ActionScript calls the JavaScript function jsRunProgram providing it with the text just entered by the user. JavaScript, in turn, instantiates the ActiveX WScript.Shell and instructs it to run the program entered by the user. This way, ActionScript can run every Windows program the user typed: notepad, iexplore, cmd... just to name a few.
I developed this solution inside Adobe Flex Builder. Now, when I opened inside the Flex Builder browser the HTML page containing the Flash control corresponding to the ActionScript code, all ran as expected. Cool!
The surprise came out when I closed the Flex Builder browser and tried to open the same page in IE. I couldn't believe my eyes: everytime ActionScript tried to call JavaScript a Flash error popped out complaining about error 2060: Security sandbox violation.
This behavior sounded so unbelievable to me for several reasons:
Firstly, I browsed the Internet and I discovered that the same problem is not so uncommon. Some people suggest to deploy all the files in a web sever and, instead of accessing the HTML page via file system, access it via a HTTP connection to the web server. They say it works, but I was not interested in that solution primarily because I didn't want to introduce a web server. So I didn't try that solution.
I found two different solutions.
The first:
For those of you that just don't remember what ExternalInterface is responsible of, I have to say that this class allows ActionScript to "talk" with the Flash Player container: in my current example, I was calling a JavaScript function from inside ActionScript. My idea was to allow ActionScript to run a user-specified Windows program through the intermediation of the ActiveX WScript.Shell, instantiated in a IE-managed HTML page.
So, the code for the ActionScript part looked like this:
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="absolute" width="402" height="22"
backgroundColor="white">
<mx:Script>
<![CDATA[
private static const JS_FUNCTION_NAME: String = "jsRunProgram";
private function callExternalProgram(programName:String):void {
if (ExternalInterface.available) {
ExternalInterface.call(JS_FUNCTION_NAME, programName);
}
}
]]>
</mx:Script>
<mx:Label text="External program to call:"
y="0"
fontWeight="bold"/>
<mx:TextInput id="txtProgramName"
text="notepad"
x="151" y="-2" width="198"
enter="callExternalProgram(txtProgramName.text)"/>
<mx:Button label="Run" x="352" y="-2"
click="callExternalProgram(txtProgramName.text)"/>
</mx:Application>
... and inside HTML page I had this JavaScript fragment:
<script language="javascript" >
function jsRunProgram(programName) {
shellObj = new ActiveXObject("WScript.Shell");
shellObj.run(programName);
}
</script>
The idea here is not obvious, but pretty simple: the user enters a program name in a Flex TextInput, then presses the Enter key and voilĂ ... ActionScript calls the JavaScript function jsRunProgram providing it with the text just entered by the user. JavaScript, in turn, instantiates the ActiveX WScript.Shell and instructs it to run the program entered by the user. This way, ActionScript can run every Windows program the user typed: notepad, iexplore, cmd... just to name a few.
I developed this solution inside Adobe Flex Builder. Now, when I opened inside the Flex Builder browser the HTML page containing the Flash control corresponding to the ActionScript code, all ran as expected. Cool!
The surprise came out when I closed the Flex Builder browser and tried to open the same page in IE. I couldn't believe my eyes: everytime ActionScript tried to call JavaScript a Flash error popped out complaining about error 2060: Security sandbox violation.
This behavior sounded so unbelievable to me for several reasons:
- Inside Flex Builder browser it ran without problems
- I couldn't imagine why Flash player had security concerns for accessing its containing HTML page.
Firstly, I browsed the Internet and I discovered that the same problem is not so uncommon. Some people suggest to deploy all the files in a web sever and, instead of accessing the HTML page via file system, access it via a HTTP connection to the web server. They say it works, but I was not interested in that solution primarily because I didn't want to introduce a web server. So I didn't try that solution.
I found two different solutions.
The first:
- Change Flash Player security settings to allow it to access the local directory containing the HTML page. (To change Flash Player settings it's required to call this URL)
- Change IE security settings to allow the use of ActiveX WScript.Shell
- Rename the HTML page to HTA.
How to call a program as Windows service
It's really easy to call a program as a Windows service.
In order to proceed, you firstly need two programs: instsrv.exe and srvany.exe. These programs are produced by Microsoft and are parts of Windows Resource Kit Tools.
To call a program as a new Windows service, follow this procedure:
In order to run the specified program, you may provide additional authentication information. This can be accomplished specifying log on parameters in the service properties.
To remove the new service, just follow this procedure:
In order to proceed, you firstly need two programs: instsrv.exe and srvany.exe. These programs are produced by Microsoft and are parts of Windows Resource Kit Tools.
To call a program as a new Windows service, follow this procedure:
- Create a new directory, let's say winsrv, on drive c
- Store both instsrv.exe and srvany.exe on that directory
- Open a DOS window
- Type: cd /d c:\winsrv
- Type: instsrv "service name" c:\winsrv\srvany.exe
- Exit from DOS window
- Open regedit
- Navigate to this key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\service name
- Add a new key: Parameters
- Under the key Parameters, add these three string values: Application AppDirectory AppParameters
- Set the AppDirectory value to the directory where the program is stored into
- Set the Application value to the program name
- Set the AppParameters value to the command line parameters passed in program invocation
In order to run the specified program, you may provide additional authentication information. This can be accomplished specifying log on parameters in the service properties.
To remove the new service, just follow this procedure:
- Open a DOS window
- Type cd /d c:\winsrv
- Type instsrv "service name" remove
Subscribe to:
Posts (Atom)