Is there an as3 solution for extracting file content from uncompressed tar files around?
/ Jonas
Try hxformat, a Haxe-library supporting a multitude of formats, including tar ... you will need Haxe for that, either using swc output or ActionScript 3 generation ...
A little side note: personally, I'd recommend switching from AS3 to Haxe anyway ... Haxe can also be translated to PHP, which you are using as well, so you could conveniently use it on both client and server ...
Edit: yes, actually Haxe can be compiled to swfs directly, resulting in faster bytecode than as3, but you can always use as3gen, if you want to ... Haxe/PHP is also very cool, because it produces php code, but you can use Haxe, which implies, that it's strictly typed and that the whole API is exposed in a consistent and nice OO way ... Haxe does not even allow top level functions ... but if your really need it to do some dirty stuff, you can use inline php of course ...
the API also contains many helpful things, as the SPOD layer (package php.db) for clean and simple database access ... the tutorial is for neko, but that does not matter, because actually the Haxe/PHP and Haxe/Neko standard APIs are fully compatible ... this also implies, that porting from php to neko (which significantly faster and more effictient in some cases) usually is a matter of remaping package php to package neko using a compiler directive ... Haxe is THE solution for using the deploy-anywhere advantages of PHP, whilst using a really great language ...
Also Haxe is much more expressive than both AS3 and PHP ... it has enums with parameters, generics, structural subtyping, etc. ... there are some drawbacks, due to the fact that it is platform independant, but these will only occur if your code is not strictly typed ... sounds like a lot of typing, but the compiler infers many types, so by initializing a variable, it is already strictly typed ... :)
Oh, and if you really want to use Haxe, have a look at haxelib, which has many cool libraries ...
I haven't seen an as3 tar library. There are zip libraries out there though, like nochump's zip and fzip.
A workaround would be to tell the server to make the requested tar into a zip, load into flash, and once you have the content, tell the server to whipe that zip. It's a big long and has unnecesary steps if you had a tar library for as3.
The other option would be obviously to make your own tar library.
I have used nochump's zip and had no problems, but since you need no compression this would make the whole thing complex for no reason. How about not using any compression at all, and not package the whole thing into a tar. Try Bulk Loader:. Seems to fit your needs. If you don't feel like manually adding all the files manually you could probably generate an xml on the server, something generic like:
<files>
<file url="/images/icon.png" id="icon" />
...
</files>
Load that with an URLLoader, loop through the nodes, add the items to bulk loader and start the whole loading process.
Related
I'm having trouble finding good advice and common practices for the use of namespaces in Clojure. I realize that namespaces are not the same as Java packages so I'm trying to tease out the conventions in Clojure, which seem surprisingly hard to determine.
I think I have a pretty good idea how to split functions into clj files and even roughly how I'd want to organize those files into directories. But beyond that I'm having trouble finding the mechanics for my dev environment. Some inter-related questions:
Do I use the same uniqueness conventions for Clojure namespaces as I would normally use for Java packages? [ie backwards-company-domain.project.subsystem]
Should I save my files in a directory structure that matches my namespaces? [ala Java]
If I have multiple namespaces, do I need to compile all of my code into a jar and add it to my classpath to make it accessible?
Should each namespace compile to one jar? Or should I create a single jar that contains clj code from many namespaces?
Thanks...
I guess it's ok if you think it helps, but many Clojure projects don't do so -- cf. Compojure (using a top-level compojure ns and various compojure.* ns's for specific functionality), Ring, Leiningen... Clojure itself uses clojure.* (and clojure.contrib.* for contrib libraries), but that's a special case, I suppose.
Yes! You absolutely must do so, or else Clojure won't be able to find your namespaces. Also note that you musn't use the underscore in namespace names or the hyphen in filenames and wherever you use a hyphen in a namespace name, you must use an underscore in the filename (so that the ns my.cool-project is defined in a file called cool_project.clj in a directory called my).
You need to make sure all your stuff is on the classpath, but it doesn't matter if it's in a jar, multiple jars, a mixture of jars and directories on the filesystem... As long as it obeys the correct naming conventions (your point no. 2) you should be fine.
However, do not compile things ahead-of-time if there's no particular reason to do so -- this may prevent your code from being portable across various versions of Clojure without providing any benefits besides a slightly improved loading time.
You'll still need to use AOT compilation sometimes, notably in some Java interop scenarios -- the documentation of the relevant functions / macros always mentions that. There are examples of things requiring AOT in clojure.contrib; I've never needed it, so I can't provide much in the way of details.
I'd say you should use jars for functional units of code. E.g. Compojure and Ring get packaged as single jars containing many namespaces which together compose the whole package. Also, clojure.contrib is notably packaged as a single jar with multiple unrelated libraries; but that again may be a special case.
On the other hand, a single jar containing all of your project's code together with its dependencies might occasionally be useful for deployment. Check out the Leiningen build tool and its 'uberjar' facility if you think that sort of thing may be useful to you.
Strictly speaking, not necessary, though many Java projects have dropped that convention as well, especially for internal projects or private APIs. Do avoid single-segment namespaces though, which would result in classfiles being generated in the default package.
Yes.
Regarding 3 & 4, packaging and AOT compilation are entirely orthogonal to the question of namespace conventions.
I'm creating a game in XNA and was thinking of creating my own scripting language (extremely simple mind you). I know there's better ways to go about this (and that I'm reinventing the wheel), but I want the learning experience more than to be productive and fast.
When confronted with code at run time, from what I understand, the usual approach is to parse into a machine code or byte code or something else that is actually executable and then execute that, right? But, for instance, when Chrome first came out they said their JavaScript engine was fast because it compiles the JavaScript into machine code. This implies other engines weren't compiling into machine code.
I'd prefer not compiling to a lower language, so are there any known modern techniques for parsing and executing code without compiling to low level? Perhaps something like parsing the code into some sort of tree, branching through the tree, and comparing each symbol and calling some function that handles that symbol? (Wild guessing and stabbing in the dark)
I personally wouldn't roll your own parser ( turning the input into tokens ) or lexer ( checking the input tokens for your language grammar ). Take a look at ANTLR for parsing/lexing - it's a great framework and has full source code if you want to dig into the guts of it.
For executing code that you've parsed, I'd look at running a simple virtual machine or even better look at llvm which is an open-source(ish) attempt to standardise the virtual machine byte code format and provide nice features like JITing ( turning your script compiled byte code into assembly ).
I wouldn't discourage you from the more advanced options that you machine such as native machine code execution but bear in mind that this is a very specialist area and gets real complex, real fast!
Earlz pointed out that my reply might seem to imply 'don't bother doing this yourself. Re-reading my post it does sound a bit that way. The reason I mentioned ANTLR and LLVM is they both have heaps of source code and tutorials so I feel this is a good reference source. Take it as a base and play
You can try this framework for building languages (it works well with XNA):
http://www.meta-alternative.net/mbase.html
There are some tutorials:
http://www.meta-alternative.net/calc.pdf
http://www.meta-alternative.net/pfront.pdf
Python is great as a scripting language. I would recommend you make a C# binding for its C API and use that. Embedding Python is easy. Your application can define functions, types/classes and variables inside modules which the Python interpreter can access. The application can also call functions in Python scripts and get a result back. These two features combined gives you a two-way communication scheme.
Basically, you get the Python syntax and semantics for free. What you would need to implement is the API your application exposes to Python. An example could be access to game logic functions and render functions. Python scripts would then define functions which calls these, and the host application would invoke the Python functions (with parameters) to get work done.
EDIT: Seems like IronPython can save you even more work. It's a C# implementation of CPython, and has its own embedding API: http://www.ironpython.net/
Inside a Java project I use Google Protocol Buffers (GPB) for serializing my objects. I can use the same .proto files in auxiliary Python code, which is great. Now I'm adding a Flex client to the whole thing and I'd like to use the same .proto files once more.
It seems there's a couple of projects out there which compile .proto files to Actionscript. From a few glances at the projects' homepages, it seems to me that protobuf-actionscript3 is actually the most advanced and most "alive" of these projects.
Has anybody had practical experience with GPB to AS3 compilers and which one(s) can you recommend (or recommend against)?
If you're sure you want to use GPB, then protobuf-actionscript3 is your best option. It builds on the semi-successful protocol-buffers-actionscript project: http://code.google.com/p/protocol-buffers-actionscript/
If you're open to looking at other formats, there's always Adobe's own AMF3. It seems to have a good amount of community support behind it.
The only choice now is https://code.google.com/p/protoc-gen-as3/. All the other Protobuf/AS3 projects are out-of-date, and lack of features.
I'm interested in making a language to run on the AVM2 and I'm looking for advice on where to start. I do realize that this is by no means a trivial task, but I would like to give it a try and at the very least learn more about implementing a language along the way.
I have messed around with ANTLR and have been reading up on syntax issues for language development. What I'm looking for is advice on a path to take or useful references/books.
For instance I would like to generate (script/manually) some very simple AVM2 bytecode and get that to run on the VM as a start.
Thanks
If you are not interested in Haxe, you will basically need to write your own compiler that compiles objects down to ABC (Actionscript Byte Code). The AVM2 Overview document available from Adobe on ABC and the AVM2 which should help you get started. It's a fairly thorough document but stay alert for a few typo's in the bytecode instructions.
You will also need to wrap the bytecode in a doABC tag as part of a SWF container. You can get more information from the SWF File Format documentation.
If you'd like a headstart on writing the data structures (optimised int formats, etc), feel free to checkout the code at asmock, a dynamic mocking project I've been working on. The SWF/ByteCode generation stuff is a bit messy but there are IDataOutput wrappers (SWF, ByteCode) that might come in handy.
Project Alchemy by Adobe can be a good reference
http://labs.adobe.com/technologies/alchemy/
How did it go?
I'm also interested in doing a Java to AVM2 compiler...
Do you have any published code?
Take a look at Haxe: it is an open source language that can target different platforms, including the AVM. You can dig into the SWF compiler source code to get some inspiration.
I've started a project(developer text editor) in a interpreted language(Tcl/Tk) and another with Perl(both are open-source), but with some time, when it gets in a Beta version, I will need to distribute it for the users(developers of course), but I want to know some things about this:
It's possible to compile it to a executable?
How?
Can I compile for other platforms?
Or in this case it's better to use a compiled language or a interpreted?
Is usual things like this?
In the users machine, he will need to have Tcl/Tk or Perl?
Both Tcl and Perl can be compiled into executables. For windows, there's perl2exe and perlcc for systems running UNIX style operating systems. As for Tcl, there is freewrap and starpacks.
If you're just doing this for the benefit of a single executable, and eliminating the need for installing Perl and other dependencies, then there's no real reason you can't do this. It's quite a nice method for testing your application without having to constantly compile, though defeats the point of using an interpreted language in the first place.
Also take a look at The Simplest Steps to Converting TCL TK to a Stand Alone Application, this page is also useful, How can I compile Tcl type scripts into binary code
The usual and common way for such scripts is to distribute the source. A binary would only work on some very specific systems but Tcl/Tk/Perl runs on so many systems, so that would be a really big restriction for no real reason. It also helps other developers more to reuse your scripts in some good way. In most cases, even when somebody could execute your binary, it wouldn't be of much help without the source.