Free wrapped in software for linux

MySQL wrapped is a C++ wrapper for the MySQL database C application programming interface.
Examples:
The following example should be linked with the mysqlclient library from the MySQL distribution / build.
#include
#include
#include
#include
#include "Database.h"
#include "Query.h"
int main()
{
Database db("localhost","dbuser","","testdb");
Query q(db);
q.execute("delete from user");
q.execute("insert into user values(1,First Person)");
q.execute("insert into user values(2,Another Person)");
q.get_result("select num,name from user");
while (q.fetch_row())
{
long num = q.getval();
std::string name = q.getstr();
printf("User#%ld: %sn", num, name.c_str() );
}
q.free_result();
}
Enhancements:
- This release adds methods to access fields by name.

DJWrap is an open format for combining several mp3s into one (wrapping) , without losing information about where the songs begin and where they end, or what file names they had, allowing them to later be turned back into separate files.
The idea of DJWrap is in many ways the same as the AlbumWrap (ALBW) format, and the MP3Wrap format, though DJWrap has some extra features.
libdjwrap is a library that eases the handling of these wrapped files. It can parse DJWrap, AlbumWrap and MP3Wrap files, as well as output DJWrap files. It can be incorporated into software which wants a more intelligent handling of wrapped files. This would mainly be music players and CD writing software.
The library, libdjwrap, comes with a tool, aptly named djwrap. It gives a command line interface to various functions of the library, allowing a user to extract songs from a DJWrap, AlbumWrap or MP3Wrap file, as well as create their own DJWrap files.
There is also a graphical tool, using libdjwrap, for handling wrapped files. Its due for release any time now.
Enhancements:
- There is a bug in DJWrap 0.9.3 that became apparent when its used in MooseWrap.
- A function in the library returns the wrong value at a point, which makes software using DJWrap stop before writing a wrap do disk.

CGI::Wrap is a buffer output when building CGI programs.

SYNOPSIS

use CGI;
use CGI::Croak;
use CGI::Wrap;

$query = new CGI;
savequery $query; # to reconstruct input
$CGI::Out::mailto = fred; # override default of $<

run &myfunc, @myargs # a function
run sub { code } # an inline function
run code # something to eval

sub myfunc {
out $query->header();
out $query->start_html(
-title=>A test,
-author=>muir@idiom.com);
}
$CGI::Out::out # is the buffer

This is a helper routine for building CGI programs. It buffers stdout until youre completed building your output. If you should get an error before you are finished, then it will display a nice error message (in HTML), log the error, and send email about the problem.

To use it, you must condense your program down to a single function call and then use CGI::Wrap::run to call it.

Instead of print, use out.

POE::Component::SubWrapper is an event based wrapper for subs.
SYNOPSIS
use POE::Component::SubWrapper;
POE::Component::SubWrapper->spawn(main);
$kernel->post(main, my_sub, [ $arg1, $arg2, $arg3 ], callback_state);
This is a module which provides an event based wrapper for subroutines.
SubWrapper components are not normal objects, but are instead spawned as separate sessions. This is done with with PoCo::SubWrappers spawn method, which takes one required and one optional argument. The first argument is the package name to wrap. This is required. The second argument is optional and contains an alias to give to the session created. If no alias is supplied, the package name is used as an alias.
Another way to create SubWrapper components is to use the poeize method, which is included in the default export list of the package. You can simply do:
poeize Data::Dumper;
and Data::Dumper will be wrapped into a session with the alias Data::Dumper.
When a SubWrapper component is created, it scans the package named for subroutines, and creates one state in the session created with the same name of the subroutine.
The states each accept 3 arguments:
- An arrayref to a list of arguments to give the subroutine.
- A state to callback with the results.
- A string, either SCALAR, or ARRAY, allowing you to decide which context the function handled by this state will be called in.
The states all call the function with the name matching the state, and give it the supplied arguments. They then postback the results to the named callback state. The results are contained in ARG0 and are either a scalar if the function was called in scalar context, or an arrayref of results if the function was called in list context.

pyCDK is a set of Python bindings (using Pyrex) to the Curses Development Kit. It allows users to access high level curses widgets like the calendar, buttonbox, scrolling list, message box, etc. CDK is great, it really makes building complex curses applications much easier. I have used it before from C and Perl but no Python binding existed in this toolkit that I could find anyway.

pyCDK is strictly a text interface module, if you are looking to write a full fledged GUI in python then I highly recommend wxPython and wxGlade

This is a short guide for install:

1. Make sure you have Pyrex installed (version 0.82+).

2. Download and install CDK from Thomas Dickeys site
untar/gz the source archive
cd into it
./configure
./make
./make install

3. Download the pycdk package from here

4. If necessary, modify setup.py by adding the include and lib directories for CDK. The relevant portion is:

include_dirs = [/usr/local/include/cdk, /usr/include]
library_dirs = [/usr/local/lib, /usr/lib]
(I installed CDK with the default prefix of /usr/local.)

5. Run setup.py install (as root)

6. Every widget has a minimal example under pycdk/examples

7. Consult the man pages for CDK if you have a question that the examples dont make clear. Also, it may be that what you are after just isnt wrapped yet. In that case send me a note or better yet, send me a patch !

tada consists of a python module which is a wrapper module for any DBAPI 2 compatible database module.

It wraps all functions and methods of the origional module and forces the return of deferreds instead.

tada can therefore be considered to be almost DBAPI compatible as it inherits the compatiblity level of the wrapped module, but returns twisted deferreds.

GPS Tracker project allows someone to track a GPS enabled cell phone using Google maps. For this project I used a Motorola i355 cell phone on the Sprint/Nextel network.
You need to have a data plan so that you can make updates to your website from the cellphone. Please read the ReadMe.txt file in the download for installation instructions. I hope you enjoy the project. If you have any questions, feel free ask them in the forum.
There are two projects available. The first project is built with .NET and Microsoft SQL Server. The second project is built with PHP and MySQL. If you have any suggestions, please feel free to let me know. Both projects use java (J2ME) on the phone.
How It Works:
None of the code for this project is very difficult, but it does span a number of tiers and languages which may be unfamiliar to some. Figure 1 shows the data flow from phone to Google map.
Phone
Lets start with the code on the phone. This app is written in java using Java 2 Micro Edition (J2ME). Java is very similar to C#. As you look through the code, the only thing that might confuse a C# coder is the vector. A java vector is pretty much a C# ArrayList, a dynamic array. There are 2 classes in the app, LBSMidlet7 and Qworker. A midlet is an app that runs on cell phones. Take a look at the class definition. It extends the MIDlet class and implements a LocationListener interface. That means that we need to put all the method definitions of that interface into our class. Well get to that in a bit, right now lets look at the constructor.
We do 2 things in the constructor. We create a QWorker object and pass it "this" and the website that we will be uploading to. The getAppProperty method gets attributes out of the JAD file. Open the JAD file in your favorite text editor and there youll see the webpage that youll be sending GPS data to. Notice how were passing "this" to the GWorker object? Thats the LBSMidlet7 object. Take a quick look at the QWorker class, it extends the Thread class. Thats why we call worker.start() in the LBSMidlet7 constructor. We want to start our worker thread.
When you start a thread, what you are doing is creating an object and then running that objects run() method. Take a look at the run method. It has an endless loop and in the loop the first thing it does is call queue.wait(). Look at the definition of the queue. The queue is an abstract data type (ADT), it just like a queue at a bank, enter the queue at the back of the line and leave the queue when you get to the front of the line. Look at the definition of the queue, its our vector (dynamic array). When you call wait() on an object within a class that extends the Thread class, it puts that object to sleep. Think about that a little. When we hit that line, our QWorker object is now waiting... Whats it waiting for? Well get to that in a minute. Before we do that, take a look at the synchronized keyword. Notice that its wrapping the queue. What that does is it puts a lock on the queue and tells all other processes not to touch the queue until that little block of code is done with it.
Ok, so now weve started a worker thread and put it to sleep. Lets now go back to the LBSMidlet7 class and take a look at the startApp() method. In the lifecycle of a midlet, the constructor is called once and then the startApp() method is called next. In fact it can be called several times, like for instance when you close a flip phone and then open it again. What happens is that the app is suspended and when you flip the phone open again, startApp() is called again. In startApp(), we get our display and then we create a LocationProvider if one hasnt already been created and we create another thread... Why are we creating all these threads? Good question. When a midlet (app) is suspended, the backgroud threads that are created keep running. That allows us to get our GPS data and send it to our webserver while we do other important stuff, like make phone calls.
The LocationProvider is what gets our GPS data. First we create a criteria, were using the default, but you can set stuff like accuracy, response time etc. Next we create our Location Listener. Its pretty much just what it sounds like. Here you can set the interval for how often you want to get GPS data. Its currently set to 60 which is in seconds. When data comes in, the locationUpdated() method is called. This is another one of the required methods in the LocationListener interface. Here we create yet another thread and call getLocation(). The getLocation() method gets the GPS coordinates, creates a queryString which we will send to the web server a little later and then calls worker.addToQueue in the QWorker class.
Lets go back over to the QWorker class and see what happens in that method. It add the queryString to the queue and then calls queue.notify(). Guess what queue.notify() does? It wakes up our sleeping QWorker thread and tells it to get to work! Notice that our calls to the queue are once again wrapped in a synchronized block. Please practice safe threading... When notify() is called on a thread, what it does is go back to the run() method and execute the next line of code right after where we told the queue to wait(). So now we are just about ready to send the GPS data to the web server. We have a couple of interesting lines of code there. First we call peekInQueue() which gets the queryString out of the queue but leaves it there for now. Then it sends the queryString to the getUrl method which attempts to send the queryString to our web server. If its successful, we can remove the queryString from the queue. If not, we leave the queryString in the queue and try to send it to the webserver again later.
Why in the world do we have this complicated queue here? Im glad you asked. There may be times when you are receiving GPS data but are not actually in an area that has a cell phone connection. If we dont have a cell phone connection, we cant send our GPS data to our web server. So we stick our queryString in our queue and wait until we get back into an area with cell phone connectability. Can you hear me now?
Well, weve spent a pretty fair bit of time explaining the phone code. Its a little complicated but its important to know whats going on if you want to take the code and make modifications to it to suit your needs. Heres a good article on the Sun website to let you know about more capabilities of the Location Based Services API. Right about now, our queryString should be arriving at our website, lets catch up to it and see what happens.
Enhancements:
- Added comments to code