Is it possible to use swc libraries with redtamarin?


#1

It seems possible now to make use of .as files on the server and I wondered if it was possible to make use of existing swc libraries some how. i.e. a physics library.

Cheers


#2

You seem to not be very familiar with Redtamarin

so I would say, first try it
you don’t even have to install the whole redtamarin-sdk
you can quickly install as3shebang to have a “taste”

by testing it you will see very fast if it’s for you or not

why?

because all these are mainly command-line tools
meant to run where there are no GUI
and sometimes it’s just not the cup of tea of some dev

Now, about reusing SWC “as is”

no, it will not gonna work like that just yet

see for example this issue
Loading external swf and executing a function with redtamarin

you probably gonna have to work on

  • producing an ABC file instead of SWC
  • removing dependencies and doing some refactor
  • replacing events by functions callback
  • emulating, mocking or reimplementing some part of the code
  • etc.

but I would ask why do you want to run a physic library server-side ?


#3

A swc is just a library though, not really an ‘executable’ bit of AS3 code. For that, you’d need either the .abc file as mentioned above, or presumably a .swf file which would be more in line with the normal Flash/AIR workflow.

I’ve just been playing a bit with Redtamarin and it works when I build a SWF using an .as file with MXMLC, although at the moment it only seems to be executing the final script that’s found in each ABC tag (which means some glue logic is needed, or alternatively I’m thinking of adding the behaviour like in a SWF where it will instantiate on object of the main class i.e. the one which symbol ID 0…)


#4

OK so reviving an “old post” but to bring new infos :slight_smile:

when I mentioned

At that time the only libraries that could be dynamically loaded by Redtamarin were .abc files
but things has evolved

now (ahem in a future release but it does work now), you will be able to dynamically load
.abc, .swf and .as files but still not yet .swc files

but it will come, in a later update (not implemented yet) you will be able to dynamically load .swc files, because the runtime will recognise it , and a SWC is just a ZIP file, so it will unzip it on-the-fly, grab the .swf part and load that dynamically.

That’s for dynamic loading, but maybe you just want to compile your program against a .swc
and that is working now (was not working at the time).

Simply put, the traditional way to compile for Redtamarin was to compile .as sources to .abc or .swf.

Few months (year?) ago, another way been added: compiling a .swf from an IDE like Flash Builder and so compiling against 1 or many .swc files to generate a .swf.

With a little “trick”, the sequence loading of .abc files is a bit different,
so if you use an IDE to compile against .swc files you will have to tell the runtime which class to start.

eg. from redtamarin 0.4.2

Program.start( "MyMainClass" );

if you can not wait, from redtamarin 0.4.1

import shell.Program;
Program.atExit( function():void {
   new MyMainClass();
} );

see Compile with the Flex SDK on Redtamarin wiki

also

Yes, it will work wether the compiler that generated the SWF is ASC, MXMLC, etc. but with the little trick I mentioned above.

Now the other issues are

Again, at the time (3 years ago) we did not have a fully functioning “event system”
that has evolved too :slight_smile:

dev will not need to “replace events by functions callback”, they will just be able to use events as they do in Flash/AIR, but they will have to pay attention to the synchronicity of the events.

If some events are async you will probably have to use Runtime.goAsync() and manage a “main loop”, or if dev want to delegate heavy tasks to a child worker they will have to use events in an asynchronous manner to let the child worker the time to do it task and then send the event back to the main worker.

There are a lot of different cases, but tools are provided in the API to deal with those different cases.

And finally for the parts “removing dependencies and doing some refactor” and “emulating, mocking or reimplementing some part of the code” due to the Flash/AIR API not being completely implemented, this should be less needed.

Case in point, using synchronous or asynchronous sockets, so few years ago on this particular discussion implement flash.net.Socket
I can now come back with more details about the different direction

At the C level, sure you can make a socket async or non-blocking with something like fcntl()
but then it put on the dev an heavy work of managing this kind of async code without an event system, it is quite painful.

Now at the AS3 level with a bit of API “magic”, you can perfectly use a blocking socket but that is instantiated in a child worker, and when you sync the event loop of both the main worker and the child worker you can basically accomplish everything that a “real” non-blocking socket would do.

The API “magic” ? reusing the Runtime compiler (RTC) that is already there in the avmplus source code, the same one that allow to implement an eval() function, but that you sue to dynamically creates child workers (without having to pre-compile the .abc code).

So let’s say we need the socket to be non-blocking because we want a timeout on the connect(), eg, try to connect for 20 seconds, if by that time the socket is not connected throw an error or something.

At the C level, a socket is just a file descriptor with a number, so from the main worker you create your Socket object, and when you call connect() but instead of wiating in the main worker, you delegate the task to connect to a child worker

some pseudo code

package flash.net
{
    public class Socket
    {
    
        private var _timeout:uint = 20 * 1000; // milliseconds

        public function connect( host:String, port:int ):void
        {
            var source:String = "";
                source += " ... "; // source code for the child worker
            var bytes:ByteArray = Runtime.compile( bytes ); // dynamic compilation with RTC
            var worker:Worker = WorkerDomain.createWorkerFromByteArray( bytes );
            //...
            // connecting stuff between child and main worker
        }
    }
}

With that, the socket in the child worker can stay blocking, and you wait for an event coming back from the child to the main worker, at best it connect at worst it time out or other errors.

And so all that works mainly when you have an event system in place, in short the main even loop will check for a child worker message and then redispatch it as an event emitted from the original object (the Socket object).

It is very stupid but it works :smile:.

it also gives options, in that case the timeout can be a timer event that check on the connection state of the socket, if still not connected after N seconds it can terminate the worker for ex, so there the timeout is managed outside of the child worker; but you could calculate the timeout from within the event loop of the child worker and there the timeout would be managed internally from the child worker.

And that is only one example, but now there are many more things from the Flash/AIR API that can be implemented in Redtamarin with that system, ideally if in a Flash/AIR project a dev was using flash.net::Socket, he/she will be able to use the same class in Redtamarin, with the events, with the async.