for now we have

public native function recv( socket:int, bytes:ByteArray, len:int = 8192, flags:int = 0 ):int;

len need to be renamed to buffer
and the type should be uint as a buffer can not be negative

and the return value should be Number instead of int
because as we receive data into a ByteArray we could receive 4 GB of data
and that would be overflow the max 2 GB of max int.

new signature

public native function recv( socket:int, bytes:ByteArray, buffer:uint = 8192, flags:int = 0 ):Number;

https://code.google.com/p/redtamarin/issues/detail?id=53

currently the situation is like that

in a general manner "it is hard to use redtamarin"

• it's hard to find the correct executable
• it's hard to find what can be done with redtamarin
• it's hard to setup an IDE to work on a redtamarin project
• it's hard to test/debug/compile/etc.
• it's even harder when people want to work with external abc libraries
• and much more

A redtamarin SDK should help by providing a default organisation
of files, utilities, environment variables, etc.

scenario:

• download an SDK
• install the SDK (different versions can be installed in parallel)
• follow an easy setup for the Flash Builder IDE
• now you can write code, test/compile, produce projector easily

after many tests, relying on Ant to test/compile/etc. is not enough
so we will create our own build tool to cover the special cases

• abc dependencies
• include files generation
• projector generation (for the current system, for other systems)

see #54 redbean

first support mainly Windows and OSX
(even though it should work with Linux too later)

2 parts of the SDK

• environment variables setup
• files distribution

env var
REDTAMARIN_HOME = /opensource/redtamarin/sdks/0.3.5
PATH = '$REDTAMARIN_HOME/bin:$PATH'

files

• asc.jar
• redshell, redshell.exe, redshell_d, redshell_d.exe
• redbean, redbean.exe
• builtin.abc, toplevel.abc, avmglue.abc

later we should provide more files like
abcdump, swfmake, etc.

the first redtamarin SDK will target version 0.3.2
and support only Windows and OSX

so we should be able to distribute an SDK before
the sync with tamarin-redux

then the next SDK will target v0.4.0
(which is more server oriented)
and so also support Linux (Debian, Ubuntu CentOS, maybe others)

we should organize the files in such a way that
we could support the same name for Linux and OSX

eg. no to different names, for ex: redbean and redbean.nix

but instead:
/linux/redbean
/osx/redbean

not only support the same names for different OS
but also for different bits

eg. 32bits vs 64bits

/linux/32/redbean
/linux/64/redbean

/osx/32/redbean
/osx/64/redbean

as we don't want complicated path for users

eg.
${env_var:REDTAMARIN_HOME}/bin/linux/32/redbean

we want simple path like
${env_var:REDTAMARIN_HOME}/bin/redbean

/bin/redbean should be a system shell scripts
that look into REDTAMARIN_OPTS

REDTAMARIN_HOME = /opensource/redtamarin/sdks/0.3.5
REDTAMARIN_OPTS = -d64

eg. like JAVA_OPTS use -d64 to run in 64bit

also we should have REDSHELL_OPTS for the avmshell running options

REDSHELL_OPTS = "-swfversion 9 -api FP_9_0"

and be very clear in the doc that
REDTAMARIN_OPTS is not the same as REDSHELL_OPTS
and explain the why/what/etc.

we also need a REDTAMARIN_PATH (like PYTHONPATH)
to allow to augment the default search path for library files (*.abc)

by default we could have this logic to search for libraries
CURRENT_PATH/name.abc
REDTAMARIN_PATH/name.abc
REDTAMARIN_HOME/abcs/name.abc

illustrated example:
you have myprogram.abc
which call loadLibrary( "avmglue.abc" )
running from the path /test/123/

with the env vars
REDTAMARIN_HOME = /opensource/redtamarin/sdks/0.3.5
REDTAMARIN_PATH = "/usr/share/redtamarin/lib:/users/zwetan/redlib"

loadLibrary() should then search in order

1. /test/123/avmglue.abc
2. /usr/share/redtamarin/lib/avmglue.abc
3. /users/zwetan/redlib/avmglue.abc
4. /opensource/redtamarin/sdks/0.3.5/abcs/avmglue.abc

if notfound in any of those paths then should
report an error "could not load library" or something alike

so far SDK structure would look like this

.
├── bin
│   ├── redbean
│   └── redbean.exe
├── lib
│   └── asc.jar
├── lib-abc
│   ├── avmglue.abc
│   ├── builtin.abc
│   └── toplevel.abc
├── lib-swc
│   └── redtamarin.swc
├── runtimes
│   └── redshell
│       └── 32
│           ├── nix
│           │   ├── redshell
│           │   └── redshell_d
│           ├── osx
│           │   ├── redshell
│           │   └── redshell_d
│           ├── osx105
│           │   ├── redshell
│           │   └── redshell_d
│           └── win
│               ├── redshell.exe
│               └── redshell_d.exe
└── tools
    └── redbean
        └── 32
            ├── nix
            │   └── redbean
            ├── osx
            │   └── redbean
            └── win
                └── redbean.exe

we will not start with v0.3.2 but with v0.4

eg. we make a clean cut between v0.4 and any older version

no backward compatibility, period

the SDK should have the functionality to

• chose the path of an already installed Flex SDK
• chose the path of an already installed AIR SDK

and/or

• install a Flex SDK
• install a AIR SDK
• merge a AIR SDK with a Flex SDK

but

Flex and AIR SDK are OPTIONAL

our SDK and tools need to rely mainly and solely on asc.jar (and/or asc2.jar)
with maybe in a far away futur porting everything to AS3 (to avoid any dependencies on Java)

see #96 as3distro

see #97 redshell

let's clarify the role of everyone

RedTamarin SDK

• distributed as a zip file
• contains files and folders
• have ONE installer script (that can rely on redshell)
• define ENVIRONMENT VARS
• generate default executable tools: redbean, as3distro

redshell

• is our AS3 command line runtime
• have NO DEPENDENCIES
• the SDK contains all the versions: release, debug, debug-debugger
• the SDK contains all the OS exe: Windows , Mac OS X, Linux
• the SDK contains all the cpu architecture: 32-bit and 64-bit

redbean

• is our AS3 make and compiler
• have dependencies: redshell, ASC.jar, ASC2.jar
• use by default: build.as3
• can build ABC, SWF and EXE
• can build complex SWF, SWC, AIR only if FLEX/AIR SDK is installed

as3distro

• is our AS3 package manager
• have dependencies: redshell, redbean
• use by default: distro.as3
• can distribute and install AS, ABC, SWF, SWC, AIR and EXE
• can build complex AS sources, complex SWF, SWC, AIR only if FLEX/AIR SDK is installed

note: redtamarin EXE are not exactly the same as your Operating System EXE

• we can distribute a very "little" *.abc or *.swf file
• we merge one of the redshell exe wit this ABC or SWF to produce the EXE
• if new redshell runtimes become available it should allow to produce new EXE directly

note: we make a difference between AS sources and complex AS sources

• AS sources: AS3 source code that depends only on redtamarin libraries CLIB, RNL and AVMGLUE
• complex AS sources: AS3 source code that depends on AIR/FLEX SDK

note: we make a difference between SWF and complex SWF

• SWF: SWF file containing only doABC2 tags (will work only with redshell runtime)
• complex SWF: SWF containing ANY tags (will work with Flash Player and/or AIR runtime)

to build Redtamarin under Windows 7

see: http://pubs.opengroup.org/onlinepubs/9699919799/functions/setvbuf.html

C signature:
setvbuf - assign buffering to a stream
int setvbuf(FILE *restrict stream, char *restrict buf, int type, size_t size);

setbuf - assign buffering to a stream
void setbuf(FILE *restrict stream, char *restrict buf);

AS3 signature:
function setvbuf( stream:FILE, type:int, size:uint = 0 ):int;
function setbuf( stream:FILE, type:int = -1 ):void;

If buf is not a null pointer, the array it points to may be used instead of
a buffer allocated by setvbuf() and the argument size specifies the size of the array;

we don't want to give access to a buffer char *restrict buf
as we prefer to let setvbuf() allocate its own buffer.

We still want to be able to change the size of the buffer,

if size is not defined, we will use BUFSIZ by default.
For ex under Mac OS X BUFSIZ = 1024
and under Linux Ubuntu BUFSIZ = 8192

If we know in advance well need to write more than BUFSIZ,
then we can use a bigger buffer eg. setvbuf( fp, _IOLBF, 4096 ).

setbuf will be implemented in AS3

the function call: setbuf(stream, buf)
shall be equivalent to: setvbuf(stream, buf, _IOFBF, BUFSIZ)
if buf is not a null pointer,
or to: setvbuf(stream, buf, _IONBF, BUFSIZ)
if buf is a null pointer.

(by default a stream is non-buffered)

eg.

public function setbuf( stream:FILE, type:int = -1 ):void
{
    if( type < 0 )
    {
        type = _IONBF; //this is by default
    }
    setvbuf( stream, type, BUFSIZ );
}

reason:
we need to be able to change the buffering behaviour

use case:
concurrency when writing logs

var bytes:ByteArray = new ByteArray();
    bytes.writeUTFBytes( "2015-09-02 some log line\n" );
    bytes.position = 0;

// we append to the file, eg. write at the end
var fp:FILE = fopen( "somefile", "a" );

/* Here we force line buffering with a buffer of 4KB (4096 bytes)
   it will "reserve" 4KB of space to write to the file.

   Because fwrite() lock the file during a write,
   because appending to the file stream (O_APPEND) move the offset to the end of the file,
   and because we use a buffer (for each lines)
   we can achieve concurrency.

   so even if another process write at the same
   time to the log file the 2x concurrent writes will note mangle with each other

   with buffering:
   1: "Here's process #1"
   2: "Here's process #2"

   without buffering:
   0: "Hehere's process #2re's process #1"
*/
var buffered:int = setvbuf( fp, _IOLBF, 4096 );

var wrote:int = fwrite( bytes, bytes.length, fp );

before

public function sendto( socket:int, bytes:ByteArray, address:*, flags:int = 0, buffer:uint = 0 ):int

after

public function sendto( socket:int, bytes:ByteArray, address:*, flags:int = 0, buffer:uint = 8192 ):Number

the utility function recvall() in C.sys.socket has a bug.

It will be updated in next binary release.

for the time being see the fix in betalib recvall()

https://code.google.com/p/redtamarin/issues/detail?id=103

see: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/crypto/package.html#generateRandomBytes()

signature:

public function generateRandomBytes(numberRandomBytes:uint):ByteArray

under Macintosh / Linux we can use /dev/urandom
$ cat /dev/urandom | LC_CTYPE=C tr -dc 'A-F0-9' | fold -w 2 | sed 1q

in AS3 that would gives

var str:String = Program.open( "cat /dev/urandom | LC_CTYPE=C tr -dc 'A-F0-9' | fold -w 2 | sed 1q" );
var byte:uint = uint( "0x" + str );

Under Windows we need to use CryptGenRandom()
see PHP implementation of php_win32_get_random_bytes
https://github.com/php/php-src/blob/master/win32/winutil.c#L80

because Program.open() call the CLI as sh -c ""

it is better to do like that

var str:String = Program.open( "LC_CTYPE=C tr -dc 'A-F0-9' < /dev/urandom | head -c 2" );

shorter command line, less dependencies and no risk to block the CLI and end up in an infinite loop while running the function, also avoid a carriage return at end of line

Is it possible to load swf from file and then call a function that's inside the swf with redtamarin?

I see that there is shell.FileSystem for loading the file into bytearray, but there is no flash.display.Loader to load from bytearray

There is also the shell.Domain.load() and shell.Domain.loadBytes(), but as I understand it only supports .abc files?

see betalib mkdirp()

same kind of issue with have with binfmt_misc under Linux

it would be nice to register the .abc extension under windows
to run automatically with redshell

under cmd.exe
C:\>program.abc would run directly

under bash
$ program.abc would run directly

would be nice if we could run an ABC files directly under IIS or Apache as CGI

https://code.google.com/p/redtamarin/issues/detail?id=96

in short, a package manager for redtamarin

see https://code.google.com/p/as3distro

and
https://code.google.com/p/as3distro/wiki/Design

https://code.google.com/p/redtamarin/issues/detail?id=50

What steps will reproduce the problem?

1. compile a script to a projector
   for ex:
   $ java -jar asc.jar -AS3 -strict -import biltin.abc -import toplevel.abc -exe redshell sysinfo.as
2. move the projector to something accessible from $PATH
   eg.
   export PATH=/Users/zwetan/scripts:$PATH
3. go to the root directory and call the exe
   $ cd /
$ sysinfo

What is the expected output?
run the sysinfo exe

What do you see instead?
the redshell usage/help output

so far we kept redbean under /src/tools/redbean
as it is something we distribute with the redtamarin SDK

but we should be able to update/upgrade/replace the default redbean
installed with the SDK with a new redbean

also we need to produce 2 kind of redbean

• the ABC library that can be loaded by a shell script or reused as a lib
• the executable command-line tool

before

public function sendall( socket:int, bytes:ByteArray, flags:int = 0, buffer:uint = 0 ):int

after

public function sendall( socket:int, bytes:ByteArray, flags:int = 0, buffer:uint = 8192 ):Number

set the default buffer to 8192 bytes and return value to Number to support ByteArray max value of 4 GB

see betalib which()

https://code.google.com/p/redtamarin/issues/detail?id=15

a mix between popen
and how JSDB use Stream

in short we want to add avmplus.Process in a cross-platform way

we can take high inspiration from the Chrome browser code, in /base they have implemented cross-platform processes in a nice way

System.popen() exists in release 0.3

a Process class shoudl be the next step

we will have a Process class

this SubProcess is even more important when you think it's what we need to wrap external external command line tools control

eg. you can include ffmpeg headers in the runtime
it will make it harder and more comoplex to complie
the runtime will grow etc.

it's possible but not wanted

but if you could just wrap the stdin/stdout/stderr around ffmpeg
and call it from AS3 code, then things get simpler and powerful

also, for redbean, as we plan to use it as compiler tool
and so reuse asc.jar but also maybe MXMLC COMPC etc.
we end up with the same use case

we need a very good subprocess control class

https://code.google.com/p/redtamarin/issues/detail?id=104

in

the utility function recvall() has a bug

here the fix

var recvall2:Function = function( socket:int, bytes:ByteArray, len:int = 8192, flags:int = 0 ):int
{
    var total:uint = 0; // how many bytes we received
    var n:int;
    var b:ByteArray = new ByteArray();

    var run:Boolean = true;
    while( run )
    {
        b.clear();
        n = recv( socket, b, len, flags );
        if( n == -1 ) { run = false; break; }
        bytes.writeBytes( b );
        total += n;
        if( n == 0 ) { run = false; break; }
    }

    b.clear();

    if( n < 0 )
    {
        return -1; //failure
    }

    return total; // number of bytes actually received
}

the loop need to check on "bytes recv zero"
and not "bytes recv smaller than buffer"

eg.
//if( n < len ) { run = false; break; } // bad
if( n == 0 ) { run = false; break; } // good

if you trace( "n = " + n );
on getting an HTTML page you get something like

n = 1448
n = 1448
n = 2896
n = 1448
n = 1448
n = 1448
n = 2896
n = 1448
n = 1448
n = 1448
n = 1448
n = 1448
n = 1448
n = 2896
n = 1534
n = 0

even if the buffer is max=8192 bytes
depending on network settings and other MTU window
we can recevie s,aller chunk than the buffer
which is what create the bug

the real indicator of "all is received" is when we receive zero bytes

before

public function recvfrom( socket:int, bytes:ByteArray, address:*, len:int = 8192, flags:int = 0 ):int

after

public function recvfrom( socket:int, bytes:ByteArray, address:*, buffer:uint = 8192, flags:int = 0 ):Number

to build Redtamarin Under Ubuntu 14.04

https://code.google.com/p/redtamarin/issues/detail?id=97

redshell is the runtime produced and maintained by RedTamarin

it is important to isolate redshell as a tool on his own

the project is named redtamarin
the redtamarin source code generate redshell for now

but later we will also generate: mod_redtamarin , etc.

that means with time we will have much more than just redshell being generated

for now redshell keep all the functionalities and options used by avmshell

we may need in the futur to change that

see https://msdn.microsoft.com/en-us/library/tw4k6df8.aspx

C signature:
int _setmode( int fd, int mode );

AS3 signature:
function setmode( fd:int, mode:int ):int;

reason:
Under Windows allow to change the translation mode of a stream, mainly used with stdout and stdin to change the mode to _O_BINARY.

Under POSIX no need to do that, so the AS3 function will be a noop
eg.

/**
 * 
 * @playerversion AVM 0.4
 * @playerversion WIN +
 */
public function setmode( fd:int, mode:int ):int
{
    if( Runtime.platform == "windows" )
    {
        //call
    }

    return 1; //for POSIX, always true
}

https://code.google.com/p/redtamarin/issues/detail?id=54

redbean will be the tool to use to

• test redtamarin oriented project from an IDE
• compile ABC files
• compile group of ABC files into a SWF
• compile projectors (EXE)

we will test only IDE so far: Flash Builder 4.5 and 4.7

the goal is to produce a redbean executable
that replace the default builder

more details:
when you create an ActionScript project in Flash Builder

• go into project properties
• select "builders"
• you see by default a "Flex" builder

scenario would be

• desactivate the "Flex" builder
• create a new builder (program)
• open file system
• follow the path where the redtamarin SDK is installed
• in the redtamarin SDK select "/bin/redbean"

there the SDK could define an env var
REDTAMARIN_SDK = /opensource/redtamarin/sdks/0.3.5
which would allow instead of browsing the file system
to simply use

for OSX
${env_var:REDTAMARIN_SDK}/bin/redbean

for Windows
${env_var:REDTAMARIN_SDK}/bin/redbean.exe

other scenario

• desactivate the "Flex" builder
• create a new builder (ant builder)
• use "${project_loc}/build.xml"
• build.xml would define the path of the redtamarin SDK
• and which redbean executable to call

there we could provide a default Ant build.xml
which could

• define the path of the redtamarin SDK (need to he edited by the user)
• detect the operating system
• use the correct redbean executable
• etc.

the env var for the redtamarin SDK should be REDTAMARIN_HOME

to follow the standard: JAVA_HOME, ANT_HOME, AIR_HOME, PLAYERGLOBAL_HOME, etc.

how redbean should work

the builder by default should use
${env_var:REDTAMARIN_HOME}/bin/redbean

and there redbean would by default look for a build.as3 file

or you could force the executable to load a particular build file
${env_var:REDTAMARIN_HOME}/bin/redbean -f mybuild.as3

basic minimum redbean API

public function compile( filepath:String, ...libraries ):void
public function shell( filepath:String, debug:Boolean = false, ...libraries ):void
public function projector( name:String, debug:Boolean = false, target:OS = null, ...filepath ):void

a basic build script

build.as3

import redbean.*

var test:Boolean = true;
var debug:Boolean = true;

compile( "src/sysinfo.as", "avmglue.abc" );

if( test )
{
    shell( "sysinfo.abc", debug, "avmglue.abc" );
}
else
{
    projector( "sysinfo", false, "sysinfo.abc", "avmglue.abc" );
}

API related to the command line

API:

compile( "src/sysinfo.as", "avmglue.abc" );

CLI:
$ java -jar asc.jar -AS3 -import builtin.abc -import toplevel.abc -import avmglue.abc src/sysinfo.as

API:

shell( "sysinfo.abc", true, "avmglue.abc" );

CLI:
$ ./redshell_d avmglue.abc sysinfo.abc

API:

projector( "sysinfo", false, "sysinfo.abc", "avmglue.abc" );

CLI:
$ ./swfmake -o program.swf avmglue.abc sysinfo.abc; ./createprojector -exe redshell -o sysinfo program.swf

correction, exemple with projector should be
projector( "sysinfo", false, null, "sysinfo.abc", "avmglue.abc" );

null for use the default OS

or
projector( "sysinfo", false, OS.windows, "sysinfo.abc", "avmglue.abc" );

OS would contains either
OS.unknown/OS.default - to compile for the current OS
(eg. if you run the build under OSX, then you compile by default for OSX)
OS.linux - to compile for Linux Debian/Ubuntu/CentOS
OS.windows - to compile for Windows
OS.macintosh - to compile for Mac OSX
OS.all - to compile for all OS: linux/windows/macintosh

OS.linux , OS.windows, OS.macintosh mens by default 32bit

then when 64bit is supported we can add
OS.linux64, OS.windows64, OS.macintosh64

and then OS.all would mean all 32bits OS
and OS.all64 would mean all 64bits OS

and if needed we can add
OS.all96 (32+64=96) to compile all 32bits and 64bits OS
and/or
OS.windoww96 to compile both OS.windows and OS.windows64
etc.

see redtamarin google code issues

here the list

• create a redtamarin SDK (google code Issue 53)
• redbean (google code Issue 54)
• as3distro (google code Issue 96)
• redshell (google code Issue 97)
• linux 64-bit compilation requires -Wno-error (google code Issue 101)
• unicode path issue with isHidden under Windows (google code Issue 102)
• impl flash.crypto.generateRandomBytes (google code Issue 103)
• bug in recvall (google code Issue 104)
• new projector and abc versioning support (google code Issue 52)
• Is there any possiable to add bitmapdata support (google code Issue 51)
• exe projector odes not execute from $PATH (google code Issue 50)
• Running Windows .EXE is incorrectly requiring .EXE to be specified on commandline (google code Issue 43)
• implement exe control with native class shell.SubProcess (google code Issue 15)
• implement events (google code Issue 4)
• implement LocalConnection (google code Issue 8)
• implement flash.net.SharedObject (google code Issue 9)
• implement flash.net.Socket (google code Issue 10)
• implement SocketServer (google code Issue 11)

to build Redtamarin under Mac OS X 10.10

test
123.txt

We need to be able to detect if we run under cmd.exe or under Cygwin with bash

This is very important for the server-side

• run CGI under IIS
• run CGI under Apache for Windows
• run CGI under other HTTP servers

now that we have tested all our setup
we need to push back some build config change

concerns any redshell, either 32-bit or 64-bit, and also as3shebang

$ redshell
obtain this error
Illegal instruction: 4

$ sudo installer -pkg as3shebang_0.9-1.pkg -target /
obtain this error
Installation failed. The installer reported: installer: Cannot install on volume / because it is disabled.

Projectors are our "static binaries", they allow us to merge a redshell runtime with an ABC or SWF program into a single executable.

But they have one little problem: the arguments

because the projectors is basically the redshell runtime
we then inherit the argument logic of this one

for example in the case of the tool redbean

we can not directly use $ redbean -f mybuild.as3
we have to use $ redbean -- -f mybuild.as3

the logic is redshell [avmplus arguments] -- [program arguments]

ideally we want to detect from the runtime that we are inside a "projector
and then alter the logic for those arguments (already done in redtamarin 0.2.5 but removed since then).

it would be "nice to have" to be able to still configure the runtime from a projector
see:

• Bug 570919 - Improved runtime option configuration mechanism.
• Bug 765905 - Improve the avmshell projector

Here we track the different components

• document a minimum Cygwin install for Windows
• create a Redtamarin installer for Windows
• shell detection under Windows

we already have REDTAMARIN_SDK (which could change)

it would be nice to have

• REDTAMARIN_BOOT to configure the boot process
  for example: set by default cygwin_compat = true
• REDTAMARIN_LIB to configure the different paths to look for ABC libraries
  eg. we want an utility function load( "hello.abc" )
  • first, look for it in the current working path
  • second, look for it in the /usr/lib/redtamarin
  • third, look in all the paths defined in REDTAMARIN_LIB
    for ex: REDTAMARIN_LIB = "/opt/local/lib:/my/custom/path"
• REDTAMARIN_OPTIONS to automatically apply redshell options
  for ex REDTAMARIN_OPTIONS="-api AIR_3_0"
  and now when you run $ redshell program.abc
  it's like running $ redshell -api AIR_3_0 program.abc

interesting use case

• customise CGI behaviour
  for ex with Apache you could change the REDTAMARIN_LIB per web site
• run the same exe with different API compatibility
  $ export REDTAMARIN_OPTIONS="-api AIR_3_0"; program
$ export REDTAMARIN_OPTIONS="-api AIR_3_1"; program
  could be useful to run unit tests and other tests

https://code.google.com/p/redtamarin/issues/detail?id=43

If an .EXE for Windows 7 is compiled with redtamarin, it can not be run by specifying the executable name without the .exe extension. If .EXE is ommitted, then an avmplus splash screen is displayed, instead of running the actionscript.

Most programs can be run under windows dos prompt without specifying the .EXE extension.

Example:

C:\Projects\tamarin\redtamarin>java -jar l/asc.jar -AS3 -import
l/builtin.abc -import l/toplevel.abc -exe l/redshell.exe sysinfo.as

sysinfo.abc, 914 bytes written
sysinfo.exe, 957338 bytes written

C:\Projects\tamarin\redtamarin>sysinfo
You must provide input files, -repl, or -Dselftest, or the executable must
be a projector file.
avmplus shell 1.4 release build cyclone
usage: avmplus
(etc.)

Running with .exe runs the actionscript:

C:\Projects\tamarin\redtamarin>sysinfo.exe
OperatingSystem.name = Win32
OperatingSystem.username = Garnet
OperatingSystem.nodename = ENVY17SPIDER
OperatingSystem.hostname = Envy17Spider
OperatingSystem.release = 6.1 build 7601
OperatingSystem.version = Windows 7 Home Premium Edition Service Pack 1
OperatingSystem.machine = i686
OperatingSystem.vendor = Microsoft
OperatingSystem.vendorName = Windows 7
OperatingSystem.vendorVersion = 6.1.1
OperatingSystem.vendorDescription = Microsoft Windows 7 Home Premium Edition Service Pack 1 (Vienna 6.1 build 7601)

so here what happen

when you bundle an *.abc file with a shell.exe you are basically creating a projector
when the shell execute it tries to discover if it is in "projector mode" or "shell mode"
and here without the ".exe" extension the shell fail to see it is in "projector mode"
so it runs the regular shell command (and end up showing the usage informations)

the problem is situated here
https://code.google.com/p/redtamarin/source/browse/trunk/shell/avmshell.cpp#695

apparently running an executable without the ".exe" extension does not fill the argv[0] value,
and because argv[0] is NULLL, then the redshell fail to reckonize it is a projector

I ll make some tests with something like

char *Path;
GetModuleFileName(NULL, Path,MAX_PATH); 
printf("%s\n", Path);

see if it gives better result under Windows

also as an alternative if you run under cygwin there is no issues (eg. argv[0] is found)
see the attached screenshot.

just gave redtamarin a spin - very nice work.

i've noticed this issue, but i'm not exactly sure why it happens, as the windows default shell should always populate argv[0] with the call (being "a.exe" or simply "a"); also to my knowledge the value of argc should be >=1 on DOS/CMD/NTVDM. on the other hand cygwi/msys with bash/sh should populate it with a full path.

apparently running an executable without the ".exe" extension does not fill the
argv[0] value, and because argv[0] is NULLL, then the redshell fail to reckonize
it is a projector

as mentioned above i cannot confirm this, but mind that the c entry point arguments are shell specific and if you decide to port your code to a not so common OS, its shell might not even allow arguments (argc = 0, *argv = NULL). if you are mainly targeting popular OS, arguments should work on such (thus a puzzle for this specific issue).

i haven't compiled your code since there are a bit too much dependencies for me: ant, python, jre etc., but here is a simple test with argv[0] / GetModuleFileName() for windows:

#include <windows.h>
#include <stdio.h>
#include <string.h>
#include <ctype.h>

#define STRIP_PATH(buffer, filename) \
    (filename) = strrchr((buffer), '\\'); \
  if ((filename)) \
    (filename)++; \
  else \
    (filename) = (buffer)

int main(int argc, char *argv[])
{
  const char ext_exe[] = ".exe\0";
  char buffer[MAX_PATH] = {0};
  char *filename;
  short i;

  if (!(*argv))
  {
    GetModuleFileName(NULL, buffer, MAX_PATH);
    STRIP_PATH(buffer, filename);

    printf("no arguments, %d, %s\n", argc, filename);
  }
  else
  {
    strcpy((char *)buffer, argv[0]);

    i = -1;
    while (buffer[++i])
      buffer[i] = tolower(buffer[i]);

    if (!strstr((char *)buffer, ext_exe))
      strcat(buffer, ext_exe);

    STRIP_PATH(buffer, filename);

    printf("has argumens, %d, %s\n", argc, filename);
  }

  return 0;
}

lubomir

I will investigate that further with the basic command prompt and cygwin under Windows

i have test the redtamarin sometime,and it not easy use.it is use include ,not use the import.
why not use the java like public static void main?and full support the import

https://code.google.com/p/redtamarin/issues/detail?id=102

when we pass a relative path to isHidden()
the result will always be wrong

as we preprend "\?" to support unicode path

a path like "..\test" will transform to "\?..\test" and most likely will not be found

see
https://code.google.com/p/redtamarin/source/browse/trunk/src/as3/shell/FileSystem.as#2687

the fileSystem.isHidden function need to be patched

from

case "windows":
return _isAttributeHidden( "\\\\?\\" + filename );

to

case "windows":
return _isAttributeHidden( "\\\\?\\" + realpath( filename ) );

see: http://en.wikipedia.org/wiki/Large_file_support

for Linux / Macintosh
fseeko() / ftello()

for Windows
_fseeki64() / _ftelli64()

it is not essential but would be nice to have
as the ByteArray is in the 4 GB zone
it would allow most files manipulation to also be in the 4 GB zone
(instead of the actual 2 GB zone).

We need to provide a bash script (Linux/Mac OS X) and bat script (Windows) for the redshell executables and other tools like redbean.

One of our main issue is to not be able to call simply
$ redshell myfile.as
$ redshell myfile.abc
$ redshell myfile.swf

for example a runtime can be located here
$REDTAMARIN_SDK/runtimes/redshell/macintosh/64/redshell_dd

at the condition the environment variable REDTAMARIN_SDK is set
then a user would only have to add this path
export PATH=$REDTAMARIN_SDK/bin:$PATH

and in $REDTAMARIN_SDK/bin
we would provide a bash script redshell

for example

#!/bin/bash

FILE_NAME=$1
shift

exec "$REDTAMARIN_SDK/runtimes/redshell/macintosh/64/redshell" ${FILE_NAME} -- $@

pros

• global access to redtamarin sdk binaries
• ease of use for the users
• remove the need to use -- to pass program arguments
  eg. $ redbean -h instead of $ redbean -- -h
• allow to configure the redshell executables per program
  if you run $ redshell test.as and you need to pass the avmplus config -swfversion 9
  then you create a config file test.as.config containing the string -swfversion 9
  or you define the environment variable REDSHELL_CONFIG and use it like that
  $ export REDSHELL_CONFIG="-swfversion 9"; redshell test.as
• works under Windows / Mac OS X / Linux
  and support Cygwin under Windows
• follow symlinks

cons

• prevent to use avmplus configuration directly on the command-line
  eg. $ redshell -swfversion 9 myfile.abc -- -a -b -c
• redshell is not a "real" executable but a bash/bat script
  with a logic that redirect the call to the real executable
  so it could slightly slow down the launch of the executables
• does not solve the problem with "projectors" (static binaries)
  current problem we have with redbean

long time ago those implementations existed and later were removed

see:

• rev 3b1b1c96a04c
• file 3b1b1c96a04c
• Bug 757375 - Changes for Concurrency

this is important to have as it allows 2 workers to communicate with each other
and would even allow to emulate MessageChannel with events.

like we did with the Windows Setup
we need to document a minimum install of Cygwin, steps by steps

there is a difference with the Windows Setup
as this minimum install is targeted at final users of redtamarin
and not developers who wish to compile the C/C++ source code

https://code.google.com/p/redtamarin/issues/detail?id=52

as of v0.3.5 even if we declare versioning
this is quietly ignored

for ex
https://code.google.com/p/maashaack/source/browse/platform/avmglue/trunk/src/flash/system/Capabilities.as#266

        [API(CONFIG::FP_10_1,CONFIG::AIR_2_0)]
        public static function get touchscreenType():String
        {
            CFG::dbg{ trace( "Capabilities.get touchscreenType()" ); }
            return avmplus.System.profile.touchscreenType;
        }

if you run
$ ./redshell -API FP_9_0 avmglue.abc myprogram.abc

you will still be able to access
Capabilities.touchscreenType

there is 3 problems here

1. abc versioning is not active in the current redtamarin

we need to upgrade to the latest tamarin-redux
and also upgrade to a new asc.jar to be able to support it

2. about passing command line options to the avmshell/redshell

in scripting or CGI mode you could do that workaround

        #Apache AS3
        AddType application/x-httpd-as3 .as3
        AddHandler cgi-script .as3

or simply running *.as file as shell script
see https://code.google.com/p/redtamarin/wiki/RunningShellScripts

you could use a wrapper

    #! /bin/sh
    ABCNAME=$1
    shift
    /usr/share/redtamarin/redshell -api FP_9_0 "${ABCNAME}" -- $@

what is considered is as part of the SDK to be able to define an environment variable
REDTAMARIN_OPTIONS = -api PF_9_0

so each time the redshell run, it will look for this first

3. about passing options for a projector

see https://code.google.com/p/redtamarin/wiki/Projector

when you embed an ABC or SWF with the redshell exe
there is simply no way or support to add options to the redshell itself

$ ./redshell -API FP_9_0 avmglue.abc myprogram.abc
to
$ ./myprogram

"myprogram" as an executable has no way to configure the redshell/avmshell

luckily there is this patch

Bug 765905 - Improve the avmshell projector
https://bugzilla.mozilla.org/show_bug.cgi?id=765905

see also
https://bug765905.bugzilla.mozilla.org/attachment.cgi?id=634165
https://bug765905.bugzilla.mozilla.org/attachment.cgi?id=634164

once upgrade to the latest tamarin-redux and this patch applied
it should solve the problem for projectors

all is working

we have versioning in the ABC files and in the runtime :)

now we need to implement the last bit from Bug 765905

https://code.google.com/p/redtamarin/issues/detail?id=8

allow to connect to a SWF or AIR or anyother
with LocalConnection from a redtamarin exe

https://code.google.com/p/redtamarin/issues/detail?id=9

allow to read/write to SharedObject files (*.sol)
in the same logic as the flash player / AIR

but without the security limitation

ex:
test.swf hosted on www.domain.com
write into test.sol

allow a redtamarin exe to read and write to the
same *.sol file

documentation

http://en.wikipedia.org/wiki/Local_shared_object

http://www.adobe.com/security/flashplayer/articles/lso/

example of file location

under Mac OS X with PPAPI
~/Library/Application Support/Google/Chrome/Default/Pepper Data/Shockwave Flash/WritableRoot/#SharedObjects/A1B2C3D4

"A1B2C3D4" is a random directory

for ex:
../A1B2C3D4/cdn.pixlr.com/express/express.swf/pixlr.sol

the random directory contains subdirectories named as the domain saving the LSO
then another 1 or more subdirectories representing the URL "path",
then another subdirectory is the name of the SWF saving the LSO
and finaly the LSO file itself with the extension .sol

when the RuntimeProfile emulate either the Flash Player or AIR
we need to try to follow their rules for creating/reading LSO

for ex:
we need to find out if the random directory already exists
and if not create a random directory

if running from a CLI executable then the domain directory could use the name of the executable

etc.

https://code.google.com/p/redtamarin/issues/detail?id=51

redtamarin is wonderful. Is there any possible to add bitmapdata functionalit?

native support for Bitmap and BitmapData are definitively considered

https://code.google.com/p/redtamarin/issues/detail?id=101

seems similar to
Bug 654996: use target-specific variable to disable -Werror in these cases

https://bugzilla.mozilla.org/show_bug.cgi?id=654996

so in core/manifest.mk we do

ifeq (x86_64,$(TARGET_CPU))
ifeq ($(TARGET_OS),linux)
$(curdir)/AvmCore.$(OBJ_SUFFIX): avmplus_CXXFLAGS += -Wno-error
$(curdir)/CodegenLIR.$(OBJ_SUFFIX): avmplus_CXXFLAGS += -Wno-error -fpermissive
$(curdir)/exec-jit.$(OBJ_SUFFIX): avmplus_CXXFLAGS += -Wno-error
$(curdir)/exec-osr.$(OBJ_SUFFIX): avmplus_CXXFLAGS += -Wno-error
$(curdir)/InvokerCompiler.$(OBJ_SUFFIX): avmplus_CXXFLAGS += -Wno-error
$(curdir)/LirHelper.$(OBJ_SUFFIX): avmplus_CXXFLAGS += -Wno-error
$(curdir)/PoolObject.$(OBJ_SUFFIX): avmplus_CXXFLAGS += -Wno-error
endif
endif

and here the real problem

• fixing bug in our source code, it's OK
• going into the AVM2 source code to fix such bugs is possible but not wanted

use something like "Inno Setup" or other to

• install Cygwin
• install apt-cyg
• install wpkg

3 main documents

• Tamarin
• Tamarin_Build_Documentation
  started see Tamarin_Build_Documentation
• MMgc

ref: MDN Articles tagged Tamarin

also Tamarin on the Mozilla wiki

Not essential, but some of those documents can provide important knowledge
on "why things have been done this way", would be nice to have a copy
in case mozilla decide to delete them

https://code.google.com/p/redtamarin/issues/detail?id=4

implement the full event stacks based on W3C

goal:
have the same event system than Flash/AIR

but also allow to add a little more

so we gonna do that but cheat a little ;)

more details a bit later

improve the SDK

the file/directory structure need to change
it will be similar to other lang distribution
and follow the Filesystem Hierarchy Standard (FHS)

under Windows: hard dependency on Cygwin ?
yes

https://code.google.com/p/redtamarin/issues/detail?id=10

mimic the APi of flash.net.Socket
without the security limitation

eg> being able to connect anywhere, any ports, etc.

https://code.google.com/p/redtamarin/issues/detail?id=11

on the same model as flash.net.Socket
provide a SocketServer and be able to listen
for connections

before

public native function send( socket:int, bytes:ByteArray, flags:int = 0, buffer:uint = 8192 ):int;

we should set a default buffer of 8192 bytes