swfmill 0.0.2 → 0.0.3

data/.swfmill

@@ -104,3 +104,24 @@ ext/swfmill/test/Makefile.in
 ext/swfmill/test/xml/Makefile.am
 ext/swfmill/test/xml/Makefile.in
 ext/swfmill/test/xml/test-xml
+ext/libb64/Makefile
+ext/libb64/BENCHMARKS
+ext/libb64/base64/Makefile
+ext/libb64/base64/base64.cc
+ext/libb64/base64/VisualStudioProject/Makefile
+ext/libb64/base64/VisualStudioProject/base64.vcxproj.filters
+ext/libb64/base64/VisualStudioProject/base64.sln
+ext/libb64/base64/VisualStudioProject/base64.vcxproj
+ext/libb64/README
+ext/libb64/INSTALL
+ext/libb64/CHANGELOG
+ext/libb64/include/b64/decode.h
+ext/libb64/include/b64/cencode.h
+ext/libb64/include/b64/encode.h
+ext/libb64/include/b64/cdecode.h
+ext/libb64/src/Makefile
+ext/libb64/src/cdecode.c
+ext/libb64/src/cencode.c
+ext/libb64/LICENSE
+ext/libb64/AUTHORS
+ext/libb64/TODO

data/VERSION

@@ -1 +1 @@
-0.0.2
+0.0.3

data/ext/.gitignore

@@ -4,3 +4,4 @@ mkmf.log
 *.o
 *.so
 !test/Makefile
+!libb64/**/Makefile

data/ext/base64.c

@@ -0,0 +1,21 @@
+#include "b64/cdecode.h"
+#include "b64/cencode.h"
+
+long
+base64_decode(char *to, char *from, unsigned int len)
+{
+    base64_decodestate state;
+    base64_init_decodestate(&state);
+    return base64_decode_block(from, len, to, &state);
+}
+
+long
+base64_encode(char *to, char *from, unsigned int len)
+{
+    base64_encodestate state;
+    int size;
+    base64_init_encodestate(&state);
+    size = base64_encode_block(from, len, to, &state);
+    size+= base64_encode_blockend(to + size, &state);
+    return size;
+}

data/ext/extconf.rb

@@ -98,7 +98,7 @@ have_func("iconv", "iconv.h") or have_library("iconv", "iconv", "iconv.h")
 
 have_library("stdc++")
 
-$CFLAGS  += " -I./swfmill/src -I./swfmill/src/swft -I./swfmill/src/xslt"
+$INCFLAGS += " -I./swfmill/src -I./swfmill/src/swft -I./swfmill/src/xslt -I./libb64/include"
 
 Dir.chdir("swfmill") do
   cmd = <<CMD
@@ -107,14 +107,28 @@ FREETYPE_CFLAGS="#{$FREETYPE_CFLAGS}" FREETYPE_LIBS="#{$FREETYPE_LIBS}" \
 XML_CFLAGS="#{$XML_CFLAGS}" XML_LIBS="#{$XML_LIBS}" \
 XSLT_CFLAGS="#{$XSLT_CFLAGS}" XSLT_LIBS="#{$XSLT_LIBS}" \
 PNG_CFLAGS="#{$PNG_CFLAGS}" PNG_LIBS="#{$PNG_LIBS}" \
-CXXFLAGS="-O3"
+--with-pic \
+--enable-shared \
+CFLAGS="-fPIC -O3" \
+CXXFLAGS="-fPIC -O3 -finline -finline-functions"
 CMD
   raise "error: #{cmd}" unless system(cmd)
   cmd = "make"
   raise "error: #{cmd}" unless system(cmd)
 end
 
+Dir.chdir("libb64") do
+  cmd = "make"
+  raise "error: #{cmd}" unless system(cmd)
+end
+
 create_makefile("swfmill_ext")
 File.open(File.dirname("__FILE__") + "/Makefile", "ab") do |f|
-  f.puts "OBJS += #{Dir["swfmill/src/**/*.o"].join(" ")}"
+  exclude = ['swfmill/src/swfmill-base64.o']
+  objects = Dir["swfmill/src/**/*.o"] - exclude
+  f.puts "OBJS += #{objects.join(" ")}"
+end
+
+File.open(File.dirname("__FILE__") + "/Makefile", "ab") do |f|
+  f.puts "OBJS += libb64/src/cdecode.o libb64/src/cencode.o"
 end

data/ext/libb64/AUTHORS

@@ -0,0 +1,7 @@
+libb64: Base64 Encoding/Decoding Routines
+======================================
+
+Authors:
+-------
+
+Chris Venter	chris.venter@gmail.com	http://rocketpod.blogspot.com

data/ext/libb64/BENCHMARKS

@@ -0,0 +1,85 @@
+-- Intro
+
+Some people have expressed opinions about how
+fast libb64's encoding and decoding routines
+are, as compared to some other BASE64 packages
+out there.
+
+This document shows the result of a short and sweet 
+benchmark, which takes a large-ish file and 
+encodes/decodes it a number of times.
+The winner is the executable that does this task the quickest.
+
+-- Platform
+
+The tests were all run on a Fujitsu-Siemens laptop,
+with a Pentium M processor running at 2GHz, with
+1GB of RAM, running Ubuntu 10.4.
+
+-- Packages
+
+The following BASE64 packages were used in this benchmark:
+
+- libb64-1.2 (libb64-base64)
+  From libb64.sourceforge.net
+  Size of executable: 18808 bytes
+  Compiled with:
+    CFLAGS += -O3
+    BUFFERSIZE = 16777216
+
+- base64-1.5 (fourmilab-base64)
+  From http://www.fourmilab.ch/webtools/base64/
+  Size of executable: 20261 bytes
+  Compiled with Default package settings
+
+- coreutils 7.4-2ubuntu2 (coreutils-base64)
+  From http://www.gnu.org/software/coreutils/
+  Size of executable: 38488 bytes
+  Default binary distributed with Ubuntu 10.4
+
+-- Input File
+
+Using blender-2.49b-linux-glibc236-py25-i386.tar.bz2
+from http://www.blender.org/download/get-blender/
+Size: 18285329 bytes
+(approx. 18MB)
+
+-- Method
+
+Encode and Decode the Input file 50 times in a loop,
+using a simple shell script, and get the running time.
+
+-- Results
+
+$ time ./benchmark-libb64.sh 
+real	0m28.389s
+user	0m14.077s
+sys	0m12.309s
+
+$ time ./benchmark-fourmilab.sh 
+real	1m43.160s
+user	1m23.769s
+sys	0m8.737s
+
+$ time ./benchmark-coreutils.sh 
+real	0m36.288s
+user	0m24.746s
+sys	0m8.181s
+
+28.389 for 18MB * 50
+= 28.389 for 900
+
+-- Conclusion
+
+libb64 is the fastest encoder/decoder, and 
+has the smallest executable size.
+
+On average it will encode and decode at roughly 31.7MB/second.
+
+The closest "competitor" is base64 from GNU coreutils, which
+reaches only 24.8MB/second.
+
+--
+14/06/2010
+chris.venter@gmail.com
+

data/ext/libb64/CHANGELOG

@@ -0,0 +1,25 @@
+libb64: Base64 Encoding/Decoding Routines
+======================================
+
+## Changelog ##
+
+Version 1.2 Release
+-------------------
+Removed the b64dec, b64enc, encoder and decoder programs in favour of
+a better example, called base64, which encodes and decodes 
+depending on its arguments.
+
+Created a solution for Microsoft Visual Studio C++ Express 2010
+edition, which simply builds the base64 example as a console application.
+
+Version 1.1 Release
+-------------------
+Modified encode.h to (correctly) read from the iostream argument,
+instead of std::cin.
+Thanks to Peter K. Lee for the heads-up.
+
+No API changes.
+
+Version 1.0 Release
+-------------------
+The current content is the changeset.

data/ext/libb64/INSTALL

@@ -0,0 +1,44 @@
+libb64: Base64 Encoding/Decoding Routines
+======================================
+
+Requirements:
+------------
+This piece of software has minimal requirements.
+
+I have tested it on the following systems:
+
+- a Linux machine, with the following specs:
+(this was the original development machine)
+	* FedoraCore 4
+	* kernel v. 2.6.11 (stock FC4 kernel)
+	* gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
+	* glibc-2.3.5-10
+	* make v. 3.80
+	* some arb version of makedepend
+
+- Windows XP machine
+	* MSYS 1.0
+	* MinGW 5.1.4
+	* gcc version 3.4.5 (mingw-vista special r3)
+
+- Windows XP machine (same as above)
+	* Microsoft Visual Studio 2010, Version 10.0.30319.1 RTMRel
+	
+Barring any serious screwups on my part, this code should compile and run sweetly
+under Cygwin and other systems too. If you DO get it running under some weird arch/os setup,
+send me a mail, please.
+
+Compiling:
+---------
+There is no configure. It would be overkill for something so simple...
+Run make in the root directory.
+
+Installing:
+----------
+Since the current targets are a standalone executable and a static library
+(fancy name for archive) with some headers, an install script has not been implemented yet.
+Simply copy the executable into your path, and use it.
+
+--
+peace out
+Chris

data/ext/libb64/LICENSE

@@ -0,0 +1,29 @@
+Copyright-Only Dedication (based on United States law) 
+or Public Domain Certification
+
+The person or persons who have associated work with this document (the
+"Dedicator" or "Certifier") hereby either (a) certifies that, to the best of
+his knowledge, the work of authorship identified is in the public domain of the
+country from which the work is published, or (b) hereby dedicates whatever
+copyright the dedicators holds in the work of authorship identified below (the
+"Work") to the public domain. A certifier, moreover, dedicates any copyright
+interest he may have in the associated work, and for these purposes, is
+described as a "dedicator" below.
+
+A certifier has taken reasonable steps to verify the copyright status of this
+work. Certifier recognizes that his good faith efforts may not shield him from
+liability if in fact the work certified is not in the public domain.
+
+Dedicator makes this dedication for the benefit of the public at large and to
+the detriment of the Dedicator's heirs and successors. Dedicator intends this
+dedication to be an overt act of relinquishment in perpetuity of all present
+and future rights under copyright law, whether vested or contingent, in the
+Work. Dedicator understands that such relinquishment of all rights includes
+the relinquishment of all rights to enforce (by lawsuit or otherwise) those
+copyrights in the Work.
+
+Dedicator recognizes that, once placed in the public domain, the Work may be
+freely reproduced, distributed, transmitted, used, modified, built upon, or
+otherwise exploited by anyone for any purpose, commercial or non-commercial,
+and in any way, including by methods that have not yet been invented or
+conceived.

data/ext/libb64/Makefile

@@ -0,0 +1,25 @@
+all: all_src all_base64
+
+all_src:
+	$(MAKE) -C src
+all_base64: all_src
+	$(MAKE) -C base64
+
+clean: clean_src clean_base64 clean_include
+	rm -f *~ *.bak
+
+clean_include:
+	rm -f include/b64/*~
+
+clean_src:
+	$(MAKE) -C src clean;
+clean_base64:
+	$(MAKE) -C base64 clean;
+	
+distclean: clean distclean_src distclean_base64
+
+distclean_src:
+	$(MAKE) -C src distclean;
+distclean_base64:
+	$(MAKE) -C base64 distclean;
+

data/ext/libb64/README

@@ -0,0 +1,138 @@
+b64: Base64 Encoding/Decoding Routines
+======================================
+
+Overview:
+--------
+libb64 is a library of ANSI C routines for fast encoding/decoding data into and
+from a base64-encoded format. C++ wrappers are included, as well as the source
+code for standalone encoding and decoding executables.
+
+base64 consists of ASCII text, and is therefore a useful encoding for storing 
+binary data in a text file, such as xml, or sending binary data over text-only
+email.
+
+References:
+----------
+* Wikipedia article:
+	http://en.wikipedia.org/wiki/Base64
+* base64, another implementation of a commandline en/decoder:
+	http://www.fourmilab.ch/webtools/base64/
+
+Why?
+---
+I did this because I need an implementation of base64 encoding and decoding,
+without any licensing problems. Most OS implementations are released under
+either the GNU/GPL, or a BSD-variant, which is not what I require.
+
+Also, the chance to actually use the co-routine implementation in code is rare,
+and its use here is fitting. I couldn't pass up the chance.
+For more information on this technique, see "Coroutines in C", by Simon Tatham,
+which can be found online here: 
+http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
+
+So then, under which license do I release this code? On to the next section...
+
+License:
+-------
+This work is released under into the Public Domain.
+It basically boils down to this: I put this work in the public domain, and you
+can take it and do whatever you want with it.
+
+An example of this "license" is the Creative Commons Public Domain License, a
+copy of which can be found in the LICENSE file, and also online at
+http://creativecommons.org/licenses/publicdomain/
+
+Commandline Use:
+---------------
+There is a new executable available, it is simply called base64.
+It can encode and decode files, as instructed by the user.
+
+To encode a file:
+$ ./base64 -e filea fileb
+fileb will now be the base64-encoded version of filea.
+
+To decode a file:
+$ ./base64 -d fileb filec
+filec will now be identical to filea.
+
+Programming:
+-----------
+Some C++ wrappers are provided as well, so you don't have to get your hands
+dirty. Encoding from standard input to standard output is as simple as
+
+	#include <b64/encode.h>
+	#include <iostream>
+	int main()
+	{
+		base64::encoder E;
+		E.encode(std::cin, std::cout);
+		return 0;
+	}
+
+Both standalone executables and a static library is provided in the package,
+
+Implementation:
+--------------
+It is DAMN fast, if I may say so myself. The C code uses a little trick which
+has been used to implement coroutines, of which one can say that this
+implementation is an example.
+
+(To see how the libb64 codebase compares with some other BASE64 implementations
+available, see the BENCHMARKS file)
+
+The trick involves the fact that a switch-statement may legally cross into
+sub-blocks. A very thorough and enlightening essay on co-routines in C, using
+this method, can be found in the above mentioned "Coroutines in C", by Simon
+Tatham: http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
+
+For example, an RLE decompressing routine, adapted from the article:
+1	static int STATE = 0;
+2	static int len, c;
+3	switch (STATE)
+4	{
+5		while (1)
+6		{
+7			c = getchar();
+8			if (c == EOF) return EOF;
+9			if (c == 0xFF) {
+10				len = getchar();
+11				c = getchar();
+12				while (len--)
+13				{
+14					STATE = 0;
+15					return c;
+16	case 0:
+17				}
+18			} else
+19				STATE = 1;
+20				return c;
+21	case 1:
+22			}
+23		}
+24	}
+
+As can be seen from this example, a coroutine depends on a state variable,
+which it sets directly before exiting (lines 14 and 119). The next time the
+routine is entered, the switch moves control to the specific point directly
+after the previous exit (lines 16 and 21).hands
+
+(As an aside, in the mentioned article the combination of the top-level switch,
+the various setting of the state, the return of a value, and the labelling of
+the exit point is wrapped in #define macros, making the structure of the
+routine even clearer.)
+
+The obvious problem with any such routine is the static keyword.
+Any static variables in a function spell doom for multithreaded applications.
+Also, in situations where this coroutine is used by more than one other
+coroutines, the consistency is disturbed.
+
+What is needed is a structure for storing these variabled, which is passed to
+the routine seperately. This obviously breaks the modularity of the function,
+since now the caller has to worry about and care for the internal state of the
+routine (the callee). This allows for a fast, multithreading-enabled
+implementation, which may (obviously) be wrapped in a C++ object for ease of
+use.
+
+The base64 encoding and decoding functionality in this package is implemented
+in exactly this way, providing both a high-speed high-maintanence C interface,
+and a wrapped C++ which is low-maintanence and only slightly less performant.