Compiling an .SWF using Action Script Files - actionscript

This may be somewhat trivial, but I am attempting to work on an Action Script / Flash project and need to make some changes to it and attempt to rebuild the .SWF file associated with it.
The project itself is fairly straightforward and is available on github here It is jwagener's recorder.js, which consists of several Action Script files and a single compiled .SWF file.
I am not terribly familiar with the build process for Action Scripts and I am sure that I have all of the necessary tools (Flash Builder, Adobe Flash Professional etc.) but I am not sure about how to go about it.
I've attempted to simply create a new ActionScript project and add all of the necessary ActionScript files from his repository, but upon building the .SWF it didn't function at all and lacked all of the External Interface elements that I need to use.
Any ideas, walk-throughs, or tutorials that would point me in the right direction would be extraordinarily helpful.

The project you want to compile actually includes a Make file.
MXMLC = "/Applications/Adobe Flash Builder 4.5/sdks/4.5.0/bin/mxmlc"
build:
$(MXMLC) -debug=false -static-link-runtime-shared-libraries=true -optimize=true -o recorder.swf -file-specs flash/FlashRecorder.as
clean:
rm recorder.swf
It looks setup for osx, but you get the idea.
If you only need to do minor changes and could do without an IDE that shows error/warnings/etc. you can do this:
Download the FlexSDK
Setup an environment variable so you can access the mxmlc compiler from anywhere on your system
Navigate to your project and compile from the command line
Step 1 is trivial.
Step 2 depends on your os a bit. On Windows should be something like My Computer > Properties > Advanced > Environment variables (I remember this is on XP, should still be somewhere on the Computer Properties properties on Windows 7) and add to the PATH variable the location of the FlexSDK's bin folder. On unix you should add something like this to either ~/.profile or ~/.bash_profile : export PATH=/your/path/to/FlexSDK/bin:$PATH
At this you should be able to run mxmlc -version from the command line
Step 3 means navigating to the project and running:
mxmlc -warnings=false -debug=false -static-link-runtime-shared-libraries=true -optimize=true -o recorder.swf -file-specs flash/FlashRecorder.as
So that's the command line option in a nutshell.
If you have a bit more editing to do you can use an IDE.
If you're on Windows I warmly recommend FlashDevelop: it's fast/lightweight/free/opensource. It downloads the sdk and setups everything for you.
If you're on OSX you can use FDT 5 Free or a trial version of Flash Builder(60 days by default) or setup TextMate with the actionscript 3 bundle.

Related

dxgettext and Windows 10

Has anyone got dxgettext running under Windows 10?
I installed dxgettext from the offical homepage under Windows 10, which worked fine.
But whenever I try to run some of the installed tools (e.g. msgfmt.exe), they don't really run, but call themselves again, generating thousands of processes and making the system crawl.
This is what happens:
I call msgfmt --help
the executable msgfmt hangs, blocking the command window
in the TaskManager I see houndreds of msgfmt.exe processes popping up
I think, I have to replace the gettext tools of the dxgettext package with some newer version but before trying to figure it out I first wanted to ask if someone else experienced similar problems and found a working solution.
My questions:
Has anyone got the tools coming with dxgettext running under Windows 10?
What steps have been necessary to get it to run?
I resolved the problem in the following way:
I downloaded https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.19.8.1-v1.14/gettext0.19.8.1-iconv1.14-static-32.zip from https://mlocati.github.io/articles/gettext-iconv-windows.html
I replaced the following files from the installation directory of dxgettext with files from the zip archive:
msgattrib.exe
msgcat.exe
msgcmp.exe
msgcomm.exe
msgconv.exe
msgen.exe
msgexec.exe
msgfilter.exe
msgfmt.exe
msggrep.exe
msginit.exe
msgmerge.exe
msgunfmt.exe
msguniq.exe
xgettext.exe
Result:
Dxgettext and the tools, I use, seem to work fine. I found no problems with my workflow so far, with one exception:
If I use assemble to embed mo-files into an exe compiled with JvGnugettext.pas, I get the following error:
Pach code “6637DB2E-62E1-4A60-AC19-C23867046A89” was not found in .exe file. Are you sure the .exe file has been compiled with the correct libraries?
This may not be related to the original problem. However, it is resolved by replacing the original assemble.exe with the version from https://sourceforge.net/p/dzlib/code/HEAD/tree/buildtools/trunk/ (see answer by #dummzeuch).
The installer on the official home page is pretty old. Last time I looked it contained several outdated dlls and executables from the original gnugettext project that did not work correctly under recent Windows versions. You could take those from my buildtools repository on OSDN. These work for me. No guarantee that they work for you though.
https://osdn.net/projects/dzlib-tools/scm/svn/tree/head/buildtools/trunk/
I've been having these issues too with dxgettext 1.22, in Windows 10 1607. I changed some DLLs at first but kept having the bash.exe looping and hogging my PC to death.
So what I did was basically install latest Cygwin 32bit and replaced the appropiate DLLs. I kept the ones for gettext. Instructions:
Download and fresh install dxgettext-1.2.2.exe from http://dxgettext.po.dk/download as admin. Restart.
Download Cygwin 32bit from https://cygwin.com/install.html in a different folder from dxgettext (I took the default, c:\cygwin)
Run setup-x86.exe and select "Base" Package (Install). Next, Select Required packages just in case.
Move the following files from dxgettext folder to a backup folder (we'll use some DLL later):
cyg*.dll
bash.exe
Copy from c:\cygwin to the dxgettext folder the following files:
bash.exe (set to run as admin)
cygwin1.dll
cygiconv-2.dll
cygintl-8.dll
cygreadline7.dll
cyggcc_s-1.dll
cygncursesw-10.dll
Recover the file(s) below from the backup folder (See #4) and copy to the dxgettext folder.
cyggettextsrc-0-14-1.dll
cyggettextlib-0-14-1.dll
cygintl-3.dll
Running like this, you might get error 740 (requires elevation). So: Set ggmerge.exe,ggfmt.exe to run as admin
** EDIT** Found online this very interesting link, from a programmer who offers a free backup written in Delphi. The good thing is he adapted the dxgettext tools to run in Windows 10. This helped me a lot.
http://personal-backup.rathlev-home.de/translate.html

Using LibGit2Sharp in the Mono ASP.NET MVC project on Ubuntu

I've created ASP.NET MVC project in MonoDevelop on Ubuntu.
Using Nuget, I added LibGit2Sharp package, but it doesn't have libgit2 library compiled for linux environment.
Then I downloaded libgit2 sources and compiled them.
Now I have libgit2-06d772d.so, but when I put it into the bin folder of my asp.net mvc project, I get System.DllNotFoundException git2-06d772d
NOTE
When I create Console project and put libgit2-06d772d.so into the bin folder of this project, application works fine.
Shared objects are not loaded when they are next to a particular file, but when their directory is in the library load path. The operating system sets a few paths that are valid for all programs, but if you have your library elsewhere, you need to specify the directory yourself.
Exporting LD_LIBRARY_PATH with the dir of the library will let the library loader know what other paths you expect to load a library from. E.g. if you built libgit2 with the libgit2sharp script you might run
export LD_LIBRARY_PATH=$HOME/libgit2sharp/libgit2/build
in the console to let the OS know that any program you start from that shell where to find libgit2.
It's common for mono-based apps to provide a script for the user to run which sets up the environment before calling mono to start the actual .exe with the program.

Trigger.io continuous development

I'd like to know if there is any way to develop continuously with Trigger.io and avoid the forge build step with every file change I want to test in my browser or simulator.
I was faced with the same problem and I've got a working solution that uses watchr and watch to automatically rebuild each time I make a change to a source file. If you are running a "web" version of your app you can make a change to a source file and go directly to your browser and see the effect of your changes fairly quickly depending on how long the build takes.
Prerequisites: Ruby, watchr, Unix 'watch', and a terminal.
gem install watchr.
create a new ruby file for watchr to know what files to monitor and what to do when it sees a change. I named my file 'my_watch.rb': https://gist.github.com/3153167
open two terminals. Terminal 1 will run watchr and Terminal two will run 'forge build ...'.
In terminal 1 run 'watchr my_watch.rb' making sure the path to my_watch.rb is correct and make sure you've edited my_watch.rb according to your setup so that the path inside watch(...) reflects the files to be watched. My example watches all files in the same directory (and beneath) as the my_watch.rb script. You can place my_watch.rb in the 'src' folder of your Trigger.io app if you want to match my example and run watchr my_watch.rb directly from the src folder. Also not the shell command and path in the block need to be updated to reflect your environment. Again, in my example 'my_watch.rb' is inside 'src/' so when a change is detected we go up one directory and call 'forge build'.
I tend to develop actively with the 'web' version of my app so I can just open terminal 2 to my forge project directory and 'forge run web'. When I am testing in simulators and on devices, yes I have to run forge build every time I want to see a change. However, I typically don't have to wait for forge build to finish because watchr kicked off the build as soon as I made a change and it happens pretty quickly.
I know this is not an ideal solution but so far developing new features in the 'web' version first and then implementing in mobile versions has been very smooth for me. I've never needed to kill the 'web' version after a build but I maybe just lucky. As for running build each time you want to test the mobile versions if you are good with your keyboard shortcuts it really isn't bad at all. XCode makes you build and run after changes are made to source code when creating native iOS apps so I don't think Trigger is unique in requiring this build step.
I hope this helps and that my answer isn't too specific to me and my setup.
The build phase makes some changes to your source to enable the forge.* APIs - therefore, trying to just use the raw files in your src directory won't work.
You may be tempted to change files directly in the development directory, but this is a pretty bad idea: we delete those files with impunity when we need to!
We have plans on our medium-term roadmap to add a file-system watcher to start builds automatically when changes have occurred.
In the meantime, I just use forge build && forge run PLATFORM which tends to only take a few seconds...
while not perfect... this works for me.
go into development/web
rm src
link to your root src, ie ln -s ../../src src
copy the all.js from the web/forge and add to your index.html
ie
start nodemon web.js
open in browser.
note you will need to comment out the all.js script tag for non web builds.

Lablgtk2 Installation on Windows

I am currently relearning Ocaml and am in the need of a good editor. There is a new editor from OcamlForge: OCamlEditor http://ocamleditor.forge.ocamlcore.org/. Prerequisite for installation is Lablgtk2.
Installing Lablgtk2 on windows is not straight forward and there is good instruction here: http://wwwfun.kurims.kyoto-u.ac.jp/soft/lsl/install-win32.txt
I have completed the first two steps and in the third step, as warned, it is failing on the native code version. This is where I am left stranded. How do I check to see if the assembler is on my path? What am I missing here?
Please help me move forward from this point.
You have an MSVC installation, right? By default MSVC doesn't add command-line tools (cl - compiler, ml - assembler, link - linker) to the PATH (and needed directories to INCLUDE and LIB). But it provides a shell script to do this - MSVS9\Commnot7\Tools\vsvars32.bat. Copy it somewhere to the PATH so that you can easily call it any time needed. Then, before running ocaml compiler call vsvars32.bat to setup the environment. You can make this environment permanent by looking at changes to %INCLUDE%, %LIB% and %PATH% variables made by this script and adding them manually to environment variables of current user (usual windows gui insanity - My Computer -> Additional -> Environment variables).

"Bundling" external libraries in Erlang?

I have an erlang application I have been writing which uses the erldis library for communicating with redis.
Being a bit of a newbie with actually deploying erlang applications to production, I wanted to know if there was anyway to 'bundle' these external libraries with the application rather than installing into my system wide /usr/lib/erlang/lib/ folder.
Currently my directory structure looks like...
\
--\conf
--\ebin
--\src
I have a basic Makefile that I stole from a friend's project, but I am unsure how to write them properly.
I suspect this answer could involve telling me how to write my Makefile properly rather than just which directory to plonk some external library code into.
You should really try to avoid project nesting whenever possible. It can lead to all sorts of problems because of how module/application version is structured within Erlang.
In my development environment, I do a few things to simplify dependancies and multiple developed projects. Specifically, I keep most of my projects sourced in a dev directory and create symlinks into an elibs dir that is set in the ERL_LIBS environmental variables.
~/dev/ngerakines-etap
~/dev/jacobvorreuter-log_roller
~/dev/elib/etap -> ~/dev/ngerakines-etap
~/dev/elib/log_roller -> ~/dev/jacobvorreuter-log_roller
For projects that are deployed, I've either had package-rpm or package-apt make targets that create individual packages per project. Applications get boot scripts and init.d scripts for easy start/stop controls but libraries and dependancy projects just get listed as package dependencies.
I use mochiweb-inspired style. To see example of this get your copy of mochiweb:
svn checkout http://mochiweb.googlecode.com/svn/trunk/ mochiweb
and use
path/to/mochiweb/scripts/new_mochiweb.erl new_project_name
to create sample project of the structure (feel free to delete everything inside src afterwards and use it for your project).
It looks like this:
/
/ebin/
/deps/
/src/
/include/
/support/
/support/include.mk
Makefile
start.sh
ebin contains *.beam files
src contains ***.erl files and local *.hrl files
include contains global *.hrl files
deps contains symlinks to root directories of dependencies
Makefile and include.mk takes care of including appropriate paths when project is built.
start.sh takes care of including appropriate paths when project is run.
So using symlinks in deps directory you are able to fine tune the versions of libraries you use for every project. It is advised to use relative paths, so afterwards it is enough to rsync this structure to the production server and run it.
On more global scale I use the following structure:
~/code/erlang/libs/*/
~/code/category/project/*/
~/code/category/project/*/deps/*/
Where every symlink in deps points to the library in ~/code/erlang/libs/ or to another project in the same category.
The simplest way to do this would be to just create a folder named erldir and put the beams you need into it and then in your start script just use the -pa flag to the erlang runtime to point out where it should fetch the beams.
The correct way (at least if you buy into the OTP distribution model) would be to create a release using reltool (http://www.erlang.org/doc/man/reltool.html) or systools (http://www.erlang.org/doc/man/systools.html) which includes both your application and erldis.
Add the external libraries that you need, anywhere you want them, and add them to your ERL_LIBS environment variable. Separate the paths with colon in unix or semicolon in dos.
Erlang will add the "ebin"-named subdirs to its code loading path.
Have your *.app file point out the other applications it depends on.
This is a good halfway-there approach for setting up larger applications.
Another way is put your lib path in ~/.erlang.
code:add_pathz("/Users/brucexin/sources/mochiweb/ebin").
code:add_pathz("/Users/brucexin/sources/webnesia/ebin").
code:add_pathz("./ebin").
code:add_pathz("/Users/brucexin/sources/erlang-history/ebin/2.15.2").

Resources