Infinite Lifetimes

Building Fedora

2011-08-26T13:41:00.001+10:00

http://magazine.redhat.com/2007/08/07/fedora-7-community-remix/

Fedora 7: Community remix

by Mike McGrath

One of the popular features of Fedora 7 is the ability to remix Fedora and build your own custom version. Now don't get me wrong–building a new distribution is nice. But what about those who wish to create their own Fedora-based project? How do you grow a complete community in an enterprise environment or in the general public? Thanks to some of the lesser-known features, anyone can use the exact same tools that make Fedora, well… Fedora.

Fedora development is generally US-based and, as a result, must follow all applicable US law regarding intellectual property, copyrights, and patents. Additionally, Fedora prides itself on being free in every sense of the word. Not only are our developers free but we encourage our users to be free as well. And one part of being free is allowing our code to be used by others–even if they want to build something less free. Revisor and Pungi are perfect examples of Fedora allowing it's user base to customize Fedora simply and freely.

With Revisor, users can easily create any spin of Fedora imaginable. Add codecs for a media center, strip out games, or add additional training applications to build a specific corporate version of Fedora. This new custom version, however, isn't useful for very long without maintainence and distribution.

It's not only possible to create a custom operating system based off of Fedora's code base, but it's also possible to copy the Fedora Project's community methods and best practices. From source to build system to distribution and communication, everything the Fedora Project needs is 100% open source. Users and developers can tweak the operating system and leave everything else alone. Enterprises can create RPMs or rolll their own custom operating system–with everyone using the exact same methods as the Fedora Project.

The first thing someone needs to create their own community is a home. Typically, this home is a simple web page. In Fedora we have a MoinMoin wiki. The wiki provides a central place to collect all Fedora information. It houses packaging guidelines, download locations, and sometimes provides work-flow. It also documents Fedora's governance, provides information about various teams or groups, and gives developers a place to share a bit about themselves. More than anything, though, it is Fedora's home and gives the community a opportunity to speak up and say "we're here."

The next essential item is communication. Initially, straight email is a good way to get things going. When the community grows (even to just a few people), something more will be needed; most (like the Fedora group) will turn to a mailing list or even a forum. When people think about lists and open source software, they think mailman. Most communities try to separate email discussion into different relevant subjects. Two lists are typically sufficient, one for development and one for users. The number of lists may scale quickly, depending on the size and scope of your project. At present, Fedora has around 70 lists.

The Fedora Project also uses IRC for more immediate communications. It is not necessary to host IRC directly–in fact the Fedora community relies on Freenode. Other communities convene there and it's valuable (and convenient) to have all of these open source people in the same place. Since telephone communication is not always possible or desirable, IRC provides a great inexpensive alternative for real-time communication. Again, it's appropriate to create separate channels based on topic or need. Fedora has many different channels, with #fedora, #fedora-devel, and #fedora-meeting being among the most popular.

Once everyone has a place to go for information on the community and can communicate openly with one another, then it's time to get down to business. Most communities will wish to customize Fedora in some way. To do that, they'll need to compile RPMs. Fortunately, with Fedora 7 every part of the build process is 100% open and available for others to duplicate.

Fedora is built from RPMs. The idea behind an RPM is that a packager takes pristine source from upstream, adds patches, creates a spec file, and builds a binary RPM to be distributed. RPMs are aware of dependencies for both the build process and at install time. Building RPMs is a tricky and time-consuming process. Fedora has many package maintainers to help do the job right. Fortunately all of Fedora's official RPMs are maintained by Fedora so others don't have to worry about keeping them up-to-date.

The easiest way to determine if a developer's custom RPM is compatible with Fedora is to actually get it accepted by Fedora. Becoming a Fedora contributor is a well-documented process, but most people needing to create their own community based on Fedora probably can't get their packages into the official Fedora operating system. This is typically because of legal reasons. However, just because something is illegal in the United States doesn't mean its illegal in other areas of the world. This situation is a perfect use-case for customizing and creating a localized version of Fedora.

Even if a package cannot make it into the official Fedora, it's still a good idea to follow the Fedora Packaging Guidelines. These guidelines are open and all Fedora packages are subject to it. An interesting side effect of this is that many Red Hat® Enterprise Linux® packages are also packaged using these guidelines. They are an excellent guide for anyone packaging something for an operating system in the Red Hat family. They also generally translate well for other community projects as well as for applications in the enterprise.

Once a custom set of RPMs has been developed, it's time to set up a system so they can be created the exact same way over and over again by different people. Reproducability is an extremely important aspect of software development and is especially true where an entire distribution is concerned. RPM was designed so that pristine source plus added patches and a spec file creates an RPM. The catch is that some packages will compile differently depending on what's already on the host. To overcome this limitation Fedora uses mock.

In its simplest form, Mock takes an SRPM as an argument, builds a chroot with a set of minimal packages, then spits out an RPM. Using RPMs 'BuildRequires' function ensures that any SRPM passed to it will get built the same way every time. There are some caveats to that, but it's best that beginners think of mock in this way until they becomes more familiar with it.

Building RPM's can be a time-consuming process and many will find it annoying to use their workstation for this task. This is especially true in larger communities or in an enterprise environment. To overcome this hurdle, the Fedora Project started using a build system called Koji. At it's core, Koji is a build queue manager for mock. At its most complex, it is a complete build solution for all of Fedora's building needs. Using x86_64 and ppc builders, Koji keeps track of what's building on what builders and sends tasks to each builder based on available load.

Even with only two build machine architectures, Fedora can build i386, x86_64, and ppc RPMs. This is great for the developers since they may not have access to these architectures and their machines never get tied up in the build process. It is also a very secure method, since they're pulling everything out of cvs and lookaside cache^[1], which prevents people from submitting malicious code by anonymous means. It also allows Fedora administrators to recreate any build at any time.

Because mock uses yum to build its chroot for every build, it is a good idea to keep a local mirror of Fedora. Using Koji can alleviate this need, but most people test new RPMs using a local mock install. Creating a Fedora mirror is fairly easy and it's also a well-documented process.

For those with high bandwidth, Fedora is always on the lookout for more mirrors. Fedora's new Mirror Manager makes it possible to set up new mirrors. Administrators can even use Mirror Manager to direct those in your organization to a local mirror using the netblock feature. This is very handy in the enterprise, as it's possible to use a stock Fedora install without any changes to the yum configuration and yet still direct users to a local mirror.

On the ticketing and bug side of Fedora's development lies bugzilla. Bug systems provide a mechanism to get metrics about the project and, of course, track issues with software. It also provides a means for users to comment and prevents developers from getting a thousand emails about the same bug. There is no perfect bug tracking system, but those serious about their community need to have one.

Now that all of those RPM's are being built and updated, it's a good idea to use some sort of updates system to pull and manage what updates go out and when. The Fedora Project created an updates system called Bodhi. The updates system is used for test cases–making sure RPMs don't break a good repository. It also allows some control over when a package gets pushed, as well as providing notes related to each update. The system itself is targeted at more mature communities and the enterprise.

Once the systems have been set up, it is just a matter of keeping everything together and making sure users and developers are informed about new events and continue to participate. By basing a custom operating system on Fedora's already-active code base, much of the difficult work of keeping the operating system up-to-date is complete, leaving community leaders to focus on development and allowing the community to grow on its own.

Everything about Fedora's process is now in the open and can be customized to any organization or community's needs. Those already running Fedora or any operating system in the Red Hat family can now build packages and communities in the exact same way that Fedora does.

^[1] lookaside cache is basically the upstream tarballs that The fedora Project store's in a separate location from the CVS.

This entry was posted by The editorial team on Tuesday, August 7th, 2007 at 5:46 pm and is filed under Fedora. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

Go Lang JSON & Topsy Twitter request

2011-07-01T16:42:00.001+10:00

I built my first Go Lang program to request some data from the Topsy Otter API that queries Twitter.
It returns JSON and requests via HTTP
It doesn't unmarshall the JSON just yet...

package main

import (
    //"io"
    "io/ioutil"
    //"strings"
    //"log"
    "http"
    "json"
    "fmt"
    )

/*
{
   "request" : {
      "parameters" : {
         "url" : "http://twitter.com/barackobama"
      },
      "response_type" : "json",
      "resource" : "authorinfo",
      "url" : "http://otter.topsy.com/authorinfo.json?url=http%3A%2F%2Ftwitter.com%2Fbarackobama"
   },
   "response" : {
      "name" : "Barack Obama",
      "url" : "http://twitter.com/barackobama",
      "type" : "twitter",
      "nick" : "barackobama",
      "description" : "44th President of the United States",
      "topsy_author_url" : "http://topsy.com/twitter/barackobama",
      "influence_level" : "5"
   }
}
*/

type OtterResponse struct {
      name string
      Url string
      Type string
      Nick string
      Description string
      Topsy_author_url string
      Influence_level string
}

func main() {
    r, err := http.Get("http://otter.topsy.com/authorinfo.json?url=http://twitter.com/barackobama")
    var b []byte;
    if err == nil {
        b, err = ioutil.ReadAll(r.Body);
        r.Body.Close();
    }

    if err != nil {
        fmt.Println(err)
           fmt.Println("Whoa we really didn't make it!")
    } else {
        fmt.Println(string(b));
        var m OtterResponse
        err := json.Unmarshal(b, &m)
        if err != nil {
           fmt.Println("Whoa we didn't make it!")
           fmt.Println(err)
        } else {
           fmt.Println("Whoa we made it!")
           fmt.Println(m.name)
        }
    }
}

The links I used:
http://blog.golang.org/2011/01/json-and-go.html
http://code.google.com/p/otterapi/wiki/Resources
http://golang.org/pkg/http/#Response
http://raycompstuff.blogspot.com/2009/11/golang-networking.html

A Guide to Undefined Behavior in C and C++, Part 1

2011-05-13T13:09:00.000+10:00

http://blog.regehr.org/archives/213

What are important languages to learn to understand different approaches and concepts?

2011-05-12T12:53:00.000+10:00

http://stackoverflow.com/questions/3958630/what-are-important-languages-to-learn-to-understand-different-approaches-and-conc

Matters of practicality are highly subjective, so I will simply say that learning different language paradigms will only serve to make you a better programmer. What is more practical than that?

Functional, Haskell - I know you said that you didn't want to, but you should really really reconsider. You've gotten some functional exposure with Clojure and even Python, but you've not experienced it to its fullest without Haskell. If you're really against Haskell then good compromises are either ML or OCaml.

Declarative, Datalog - Many people would recommend Prolog in this slot, but I think Datalog is a cleaner example of a declarative language.

Array, J - I've only just discovered J, but I find it to be a stunning language. It will twist your mind into a pretzel. You will thank J for that.

Stack, Factor/Forth - Factor is very powerful and I plan to dig into it ASAP. Forth is the grand-daddy of the Stack languages, and as an added bonus it's simple to implement yourself. There is something to be said about learning through implementation.

Dataflow, Oz - I think the influence of Oz is on the upswing and will only continue to grow in the future.

Prototype-based, Javascript/Io/Self - Self is the grand-daddy and highly influential on every prototype-based language. This is not the same as class-based OOP and shouldn't be treated as such. Many people come to a prototype language and create an ad-hoc class system, but if your goal is to expand your mind, then I think that is a mistake. Use the language to its full capacity. Read Organizing Programs without Classes for ideas.

Expert System, CLIPS - I always recommend this. If you know Prolog then you will likely have the upper-hand in getting up to speed, but it's a very different language.

Frink - Frink is a general purpose language, but it's famous for its system of unit conversions. I find this language to be very inspiring in its unrelenting drive to be the best at what it does. Plus... it's really fun!

Functional+Optional Types, Qi - You say you've experience with some type systems, but do you have experience with "skinnable* type systems? No one has... but they should. Qi is like Lisp in many ways, but its type system will blow your mind.

Actors+Fault-tolerance, Erlang - Erlang's process model gets a lot of the buzz, but its fault-tolerance and hot-code-swapping mechanisms are game-changing. You will not learn much about FP that you wouldn't learn with Clojure, but its FT features will make you wonder why more languages can't seem to get this right.

Enjoy!

Secrets of Power Negotiating

2011-05-03T08:42:00.001+10:00

http://www.korokithakis.net/posts/secrets-power-negotiating/

Nibbling. This is the principle of getting something extra, after everything else has been agreed upon. For example, you agree to buy a couch for a price, and then say "can you throw in that pillow as well?". The other person has made up their mind, so they're more receptive to adding something extra.

Higher authority. Always have a "higher authority" that you have to "check with" before you can make a decision. This ensures both that you will have more time to think about the deal, and that you will be able to put more pressure on the other party without leading to confrontation (as you do not appear to be the one responsible for the pressure).

Good guy, bad guy. This is the well-known technique of saying "I think this is a great offer, but X doesn't think so", and can be used effectively with the higher authority technique.

Impasse. If the negotiations reach an impasse, you can try to set the specific matter aside and talk about the other points of the negotiation, even if they are the minor ones. This establishes momentum and makes it easier for both parties to settle the point they were at an impasse on earlier.

Agree with people. No matter what peolpe say, agree with them and then gently nudge them to another direction. Arguing makes them go on the defensive and impedes the negotiation.

Flinch. This one is self-explanatory. Always flinch and act indignant at the first offer, no matter how good it may be. This leads the other party to believe that the offer is not good enough.

Play dumb. Don't show your hand, it's better to play dumb than to flaunt your intelligence to the other party. This makes them underestimate and sympathize with you

Be prepared to walk away. Once you decide to close the deal at any cost, you have lost the negotiation. Always be prepared to walk away.

The power of writing. Seeing something in writing is much more powerful than just hearing about it. Always use writing (the more official-looking the better) when possible.

Don't make the first offer. If you make the first offer, you're revealing the range you want to go for. Always let the other person make the first offer, if possible.

Congratulate at the end. Never gloat after a negotiation, congratulate the other person and make them feel good about the negotiation.

Be the one who writes the contract. Try to be the person who writes the contract. This allows you to add a few details that the other party has to negotiate out of the contract afterwards.

Fait accompli. This is the principle of sending the other party a proposal with the assumption that they are going to accept it exactly the way it's written. For example, you can send a contract and a cheque to the other party, thus putting them in the position that they have to either decide whether to take the slightly modified offer, or come back to the negotiation and draw it out, risking failure.

Think in real money. Convert quotes to scales that make sense. If, for example, someone quotes you a price in cents per day for a contract that will last for years, it can add up to a significant cost increase. Always think in terms of real money.

Red herring. Add terms to the negotiation that you don't really care about, just so you can give them away later to gain something else from the other party.

Puppy dog. This is the practice of letting people try products before buying them, at which point they will be hooked to the product and have a much higher chance at purchasing it. Try to make people think about the benefits of the deal in the long term, this way they will be more likely to forgo the short-term costs.

Reluctant buyer. Act like you aren't very interested in the offer. This gives you leverage.

Want it all. Ask for as many things as you can, even things you don't want. This way, you set the other person up to "win" by making you relinquishing terms you didn't even care for. It also helps you get more things than you initially planned for.

Don't split the difference. Never split the difference yourself, but always try to get the other person to split their offer. This way you can split the difference over and over again on their end without relinquishing anything of yours.

These are the points in the book that come to mind. I haven't explained them in nearly as much detail as the book does, and I haven't provided ways to counter each technique when other people use it on you. So, if you felt that this list is interesting, I would urge you to buy the book. I heavily recommend it.

c-ares

2011-04-29T20:28:00.001+10:00

c-ares is a C library that performs DNS requests and name resolves asynchronously.

Google APIs preiodic table

2011-01-28T09:04:00.000+11:00

http://code.google.com/more/table/

Javascript graph library

2011-01-13T13:33:00.000+11:00

http://mbostock.github.com/d3/docs/

Mirror of GeoHot's PS3 Jailbreak

2011-01-13T13:32:00.001+11:00

erk: C0 CE FE 84 C2 27 F7 5B D0 7A 7E B8 46 50 9F 93 B2 38 E7 70 DA CB 9F F4 A3 88 F8 12 48 2B E2 1B
riv: 47 EE 74 54 E4 77 4C C9 B8 96 0C 7B 59 F4 C1 4D
pub: C2 D4 AA F3 19 35 50 19 AF 99 D4 4E 2B 58 CA 29 25 2C 89 12 3D 11 D6 21 8F 40 B1 38 CA B2 9B 71 01 F3 AE B7 2A 97 50 19
  R: 80 6E 07 8F A1 52 97 90 CE 1A AE 02 BA DD 6F AA A6 AF 74 17
  n: E1 3A 7E BC 3A CC EB 1C B5 6C C8 60 FC AB DB 6A 04 8C 55 E1
  K: BA 90 55 91 68 61 B9 77 ED CB ED 92 00 50 92 F6 6C 7A 3D 8D
Da: C5 B2 BF A1 A4 13 DD 16 F2 6D 31 C0 F2 ED 47 20 DC FB 06 70

~geohot

props to fail0verflow for the asymmetric half
no donate link, just use this info wisely
i do not condone piracy

I made a video

it's jailbreak time
open the zip, you know how to install
3.55 only
would be pirates, don't waste your time
do not mirror file, link to geohot.com
no donations accepted right now, don't get scammed

homebrew signing source (edited by jwise: Git source tree mirrored here)
make_self_npdrm makes valid NPDRM selfs from elfs
it does not contain any info on decrypting or removing NPDRM
NPDRM is required for interoperability of our homebrew applications
package_finalize turns your debug packages into psuedoretail packages
psuedoretail packages install on a geohot jailbroken PS3

i'm excited to see what you will create
open source SDK @ PSL1GHT (edited by jwise: Git source tree mirrored here)

what should a developer know before building a public web site

2010-11-23T12:49:00.000+11:00

http://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site

Python, the colour blue, flash mobs

2010-11-11T13:10:00.001+11:00

http://nfggames.com/games/ntsc/visual.shtm
http://ashitvora.info/flash-mob-gone-wrong
http://stackoverflow.com/questions/2573135/python-progression-path-from-apprentice-to-guru

launching-a-new-website-18-steps

2010-11-10T14:56:00.001+11:00

http://www.seomoz.org/blog/launching-a-new-website-18-steps

Programming Android

2010-10-21T13:55:00.001+11:00

http://programming-android.labs.oreilly.com/index.html

Javascript and JQuery fundementals

2010-10-07T22:34:00.001+11:00

http://jqfundamentals.com/book/book.html

EICAR Standard Anti-Virus Test File

2010-10-07T22:33:00.001+11:00

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

learning clojure, stacked deck

2010-09-15T21:21:00.001+10:00

http://www.benjoffe.com/holdem
http://learnclojure.blogspot.com/2010/09/clojure-macro-tutorial-part-i-getting.html

lens flare

2010-08-20T13:52:00.001+10:00

http://www.blackpawn.com/texts/lensflare/default.html

processing.js

2010-08-14T12:11:00.001+10:00

http://www.monocubed.com/?p=549
http://processingjs.org/

Using sqlite3 - C programming example

2010-08-13T15:15:00.001+10:00

void select_stack_shuffle(const char * database, const char * blk_lbl, int blk_lbl_len)
{
    sqlite3 *db;
    char *zErrMsg = 0;
    int rc;

    rc = sqlite3_open(database, &db);
    if ( rc ) {
        fprintf(stderr, "sqlite4: Can't open database: %s\n", sqlite3_errmsg(db));
        sqlite3_close(db);
        return;
    }
    const unsigned int sql_str_len = 1024;
    char sql_str[sql_str_len];
    strcpy(sql_str, "SELECT ctr_key, deadline FROM stack_shuffle WHERE block = ?1 AND still_there = 1;");
    sqlite3_busy_timeout(db, 500);
    sqlite3_stmt * pStmt;
    const char * pzTail;
    rc = sqlite3_prepare(db, sql_str, -1, &pStmt, &pzTail);
    // rc = sqlite3_prepare_v2(db, sql_str, -1, &pStmt, &pzTail);
    if ( rc != SQLITE_OK ) {
        fprintf(stderr, "sqlite4: Can't prepare statement: %s\n", sqlite3_errmsg(db));
        sqlite3_close(db);
        return;
    }
    rc = sqlite3_bind_text(pStmt, 1, blk_lbl, blk_lbl_len, SQLITE_STATIC);
    if (rc != SQLITE_OK) {
        fprintf(stderr, "sqlite4: bind failed: %s\n", sqlite3_errmsg(db));
        sqlite3_close(db);
        return;
    }
    do {
        rc = sqlite3_step(pStmt);
        if (rc == SQLITE_ROW) {
            int cols = sqlite3_column_count(pStmt);
            int col_1_type = sqlite3_column_type(pStmt, 0);
            int col_2_type = sqlite3_column_type(pStmt, 1);
            printf("sqlite4: %s: %d columns, type col 1 %d, type col 2 %d\n", __FUNCTION__, cols, col_1_type, col_2_type);
            int ctr_key = sqlite3_column_int(pStmt, 0);
            const unsigned char * deadline = sqlite3_column_text(pStmt, 1);
            printf("sqlite4: %s: ctr_key %d, deadline %s\n", __FUNCTION__, ctr_key, deadline);

        } else {
            if (rc != SQLITE_DONE) {
                printf("sqlite4: %s: received a %d, %s\n", __FUNCTION__, rc, sqlite3_errmsg(db));
            }
        }
    } while (rc == SQLITE_ROW);

}

HTML5 boilerplate & Learn python the hard way

2010-08-11T13:18:00.001+10:00

http://html5boilerplate.com/
http://learnpythonthehardway.org/index

Approximate profiling with gprof.

2010-07-19T14:47:00.001+10:00

A work colleague (AB) discovered a little trick with pg profiling that everyone should know about if they don't already,

Profiling is often avoided in live apps because it is expensive and slows down apps that are already running slow (why else profile?)

But there are two things going on when profiling. If you COMPILE with a -pg, every function that gets called stores information about itself. This info is used to determine how many times particular functions are called, and which function gets called by which function. Unfortunately this is expensive for your application, especially for properly written c++ apps as functions are called lots and lots.

When you LINK with a -pg, the program will sample your application 100 times a second and record which function is active at that point in time. This information is used to estimate what proportion of time your app spends in each function. This is often the most sought after information when profiling and is actually very cheap, computationally.

To come to these conclusions I wrote a test application that had a handful of functions that get called a lot, one of them was a recursive function. My results with different profiling methods were as follows:

(1) No profiling:                                         application took 13 seconds to execute.
(2) Linked with -pg:                                  application took 13 seconds to execute.
(3) Compiled and Linked with -pg:     application took 59 seconds to execute.

When linking with -pg the call graph was absent from the profiling results, but the percentage of time spent in each function was retained with accurate results.

Android CyanogenMod soon for HTC Desire

2010-07-19T13:54:00.001+10:00

http://www.cyanogenmod.com/

IPv6 internode openwrt

2010-07-19T12:35:00.001+10:00

http://ipv6.internode.on.net/access/adsl/
http://superuser.com/questions/104859/native-ipv6-on-openwrt
http://www.andy.id.au/Home/openwrt/custom-builds
http://kamikaze.openwrt.org/docs/openwrt.html

Using zlib in C programming

2010-07-12T10:37:00.001+10:00

g++ -Wall -Wextra comp.cpp -lz -o comp

#include <iostream>

#include <cstring>

#include <zlib.h>

using namespace std;

ZEXTERN int ZEXPORT compress OF((Bytef *dest, uLongf *destLen,

const Bytef *source, uLong sourceLen));

Compresses the source buffer into the destination buffer. sourceLen is

the byte length of the source buffer. Upon entry, destLen is the total

size of the destination buffer, which must be at least the value returned

by compressBound(sourceLen). Upon exit, destLen is the actual size of the

compressed buffer.

This function can be used to compress a whole file at once if the

input file is mmap'ed.

compress returns Z_OK if success, Z_MEM_ERROR if there was not

enough memory, Z_BUF_ERROR if there was not enough room in the output

buffer.

ZEXTERN int ZEXPORT uncompress OF((Bytef *dest, uLongf *destLen,

const Bytef *source, uLong sourceLen));

Decompresses the source buffer into the destination buffer. sourceLen is

the byte length of the source buffer. Upon entry, destLen is the total

size of the destination buffer, which must be large enough to hold the

entire uncompressed data. (The size of the uncompressed data must have

been saved previously by the compressor and transmitted to the decompressor

by some mechanism outside the scope of this compression library.)

Upon exit, destLen is the actual size of the compressed buffer.

This function can be used to decompress a whole file at once if the

input file is mmap'ed.

uncompress returns Z_OK if success, Z_MEM_ERROR if there was not

enough memory, Z_BUF_ERROR if there was not enough room in the output

buffer, or Z_DATA_ERROR if the input data was corrupted or incomplete.

int main()

{

char d[] =

"QWERTYUIOPASDFGHJKLZXCVBNMqwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNMqwertyuiopasdfghjklzxcvbnm";

cout << "sizeof(d): " << sizeof(d) << endl;

const unsigned int DESTLEN = 256;

char dest[DESTLEN];

if (sizeof(d) > DESTLEN) {

cerr << "Dest size " << DESTLEN << " too small : " << sizeof(d) << endl;

return 0;

}

uLongf destlen = DESTLEN;

unsigned int compress_bound = compressBound(sizeof(d));

cout << "Source len: " << sizeof(d) << ", size of compress bound: " << compress_bound << ", size of destlen: " <<

DESTLEN << endl;

if (compress_bound > DESTLEN) {

cerr << "Dest size " << DESTLEN << " too small for compress_bound: " << compress_bound << endl;

return 0;

}

int rtn = compress((Bytef*)dest, &destlen, (Bytef*)d, sizeof(d));

if (rtn != Z_OK) {

cerr << "Compress failed" << rtn << endl;

} else {

cout << "Compress suceeded: destlen: " << destlen << endl;

//cout << "Compressed: " << dest << endl;

}

char dest2[DESTLEN] = {0};

uLongf destlen2 = DESTLEN;

rtn = uncompress((Bytef*)dest2, &destlen2, (Bytef*)dest, destlen);

if (rtn != Z_OK) {

cerr << "Decompress failed" << rtn << endl;

} else {

cout << "Decompress suceeded: destlen: " << destlen2 << endl;

cout << "Decompressed: " << dest2 << endl;

}

rtn = memcmp(d, dest2, sizeof(d));

cout << "Comparison: " << rtn << endl;

return 0;

}

zero mq - fast messaging

2010-07-07T15:11:00.001+10:00

http://sheddingbikes.com/posts/1278464593.html
http://www.complang.org/ragel/
http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
http://www.zeromq.org/