There are various kinds of techniques that can be used to create thread-safe algorithms and data structures. The are two main classes called blocking algorithms and non-blocking algorithms. On a blocking algorithm, locks are used to encapsulate fragments of code where you must not do concurrent writes to avoid racing conditions, where that fragment is called critical section. On non-blocking algorithms, you do not use locks, instead you use atomic operations to switch between the used resources, for example using a technique called compare and swap or CAS.

A racing condition, is an event that occurs when two or more threads are accessing the same resource at the same time, leading to data corruption or system faults. The most classic lock techniques in Java and C, are the synchronized keyword on Java and pthread_mutex_lock() call in C. On Java we protect our critical section using synchronized as follows.

class SingletonSampleImpl extends Object {  

    private static Object singletonMutex = new Object();
    private static SingletonSampleImpl instance = null;  

    public static SingletonSampleImpl getInstance() {
        synchronized (singletonMutex) {
            /* when we instantiate the singleton
               we have a critical section to protect
               from racing conditions */
            if (instance == null) {
                instance = new SingletonSampleImpl();
            }
        }
        return instance;
    }
}

The singletonMutex object acts as mutex, where a mutex — term that comes from mutual exclusion — has a flag that indicates to the other threads if it is blocked or not to jump into the critical section and execute the code. So, a mutex or semaphore is a mere flag that indicates to the program if the resource is busy or not. Using locks or blocking-algorithms is expensive on most systems, depending on how are they used. For example is very expensive to use a blocking algorithm to protect a socket, where it must wait its chance to be written by other threads, with inherent network time wait.

On the non-blocking side, we have three types of algorithms: wait-free, lock-free and obstruction-free. Where wait free is the strongest technique, but the hardest to handle, because once you implement it you have an algorithm that do not waits for writing or reading. Lock-free usually uses CAS, so it using a compare and swap operation to ensure that the critical section is protected, without locking. Obstruction-free uses locking, but a different one called live-locking.

The atomic operations used on the non-blocking techniques usually are operating on a very low level of the processor, because they must executed without the interference of any other threads. For example to work with atomic operations using the GCC compiler we have some special extensions to work with them.

© dmw for coder . cl, 2011. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

The sophistication of the analysis performed by tools varies from those that only consider the behaviour of individual statements and declarations, to those that include the complete source code of a program in their analysis. Uses of the information obtained from the analysis vary from highlighting possible coding errors (e.g., the lint tool) to formal methods that mathematically prove properties about a given program (e.g., its behaviour matches that of its specification) [Static program analysis, Wikipedia].

I’ve created a very simple Python script that wraps the execution of various of those tools to analyze C source code, grouping the execution of splint static analyzer, TenDRA static checker and cppcheck static checker. Those tools will allow you to verify your C source code using static analysis, and will allow you to find bugs in your C source code finding patterns of well known programming errors. Along the time, with practice, you will not write the same errors twice, and if you use those tools, you will enhance your programming habits by doing better code, with the assistance of those tools, for example using uninitiated variables or unchecked variables will not be a problem for you.

The tool cppcheck do not requires configuration, you just need to run it using a small set of flags, usually cppcheck --enable style --enable information --enable unusedFunction, so you do not require to create a configuration file and those tests made by cppcheck are very lightweight. The TenDRA compile just checks for standard conformance, and common flags in TenDRA are like tchk -Xs -Yxpg4 -Yposix. Among those three tools, the most complex one is splint, since it is a guided static analyzer, which uses comments to guide the static analyzer on program analysis. It requires a configuration file, that is called .splintrc and should be placed in your $HOME directory. My .splintrc configuration file is as follows:

##
## .splintrc example file
##

+strict
+matchanyintegral
+trytorecover
+unixlib
-sysdirerrors
-syntax

-bugslimit 50
-sysdirs /usr:/usr/include:/usr/local/include:/usr/include/bits
-DHAVE_CONFIG=1
-DHAVE_CONFIG_H=1
-DNDEBUG=1
-I/usr/include
-I/usr/local/include
-I/opt/include
-I./include
-I../include
-I.
-I..

That is a very basic configuration, but is almost complete to allow you to check your C source code. You will find splint reporting errors that your compiler will not display, for example if you are using GCC and your compiler flags are strict, like -Wall -Wextra -Wshadow -pedantic -std=c99 or -Wall -Wextra -Wshadow -pedantic -std=c90, will not report the same errors than splint does. You will find splint as a very strict tool to check your source code, displaying well known bugs, but not all reports should be handled as real, you must think on those errors that really have a real significance.

You can find the bugbuster.py script that I’ve wrote to use all those tools in one command from Emacs, by running the Emacs compile command on its web page here, and the source code repository to contribute or download the script is located on github.com here. Enjoy enhancing your source code.

© dmw for coder . cl, 2011. | Permalink | One comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

Some notes on performance. Windows has a very poor performance compared to Linux and FreeBSD platforms. Please check the following plot that compares the performance on Windows, Linux and FreeBSD:

Compare pyxser-1.5.2 on Windows, Linux and FreeBSD

The performance on Windows is very poor. The effort required to migrate the source from POSIX platforms to Windows platforms is minimum. The difference the major effort was made on porting the setup script. My code is almost standard and it requires a C99 compiler, and usually I use the flags -Wall -Wextra -Wshadow -pedantic -std=c99 to compile my sources, so I’m using very strict dialect. Seems that the Windows C compiler is C90 by default. No way to deal with the Windows compiler for some C keywords. I’m expecting to bring constant support for Win32 platform on future releases. I will be waiting your feedback :)

Some notes on the FreeBSD install, is the fact that it is a standard distribution, without kernel optimization and it is using distribution binaries — that means that everything is made for 80×386 machines — and also it does not have any compiler optimization. Also, is well known that FreeBSD default binaries are slow, mainly because it lacks kernel optimization and standard C library optimizations. The libxml2 port on FreeBSD seems to be the problem, since it is not using the jemalloc library, and it is using the internal libxml2 memory allocator.

© dmw for coder . cl, 2011. | Permalink | One comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

The ChangeLog for this release is as follows:

1.5.1r (2010.10.11):

        Daniel Molina Wegener <dmw@coder.cl>

        * On all files: algorithms were optimized, the code
        was flattened applying "The Zen of Python" and the
        performance was enhanced in 10%.

        * Was added the cinit argument to deserialization
        functions, which control whether or not, the default
        constructor is called, instead of creating a raw
        instance of deserialized objects.

        Thanks to pyxser users for their feedback.

The cinit = False argument makes pyxser to skip the default constructor, calling PyInstance_NewRaw() instead of the default constructor. This skips the initialization code on the __init__() method. The impact on the performance — if your objects do not require of the default constructor — is as follows:

This enhancement is minimal, but saves time when you work with very simple objects. To take a look on the documentation, the pyxser extension is self documented, so you just need to call pydoc -p8181, connect your browser to http://localhost:8181/ and search for the pyxser extension documentation.

I hope that you will enjoy this release :D

© dmw for coder . cl, 2010. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

This release is quite special, I’ve added lazy initialization of some resources, so it runs 15% faster, and I’ve removed all memory leaks, so it just keeps using about 65MB of RAM when is doing the 1,500,000.00 serialization and deserialization test. I’ve spent more time coding pyxser for this release. Just comparing the performance between the older release 1.4.6r — a buggy release — with the current release 1.5r we can see the performance enhancement as follows:

The memory usage was reduced, on what object creation refers, but not on certain tasks — remember that now I’m using lazy initialization for some resources — and we can see a very similar to previous releases plot on how the memory is handled:

The memoization has suffered some important changes. Now it uses PyObject_Hash() as object identification method. It’s qute slower than past revisions, but still it works faster using lazy initializations. Another important change made to the serialization algorithm, is the fact that now it is skipping callable objects, so function will not be serialized on any manner.

On the distribution now you will find on the test folder directory, some interesting tests, such as utf-16 encoding test and ascii encoding test. All serializations now are using the Python embeded Unicode codecs for deserialization, that is not the case for serialization, it is using the LibXML2 codec, so it can handle more encodings.

I must strongly thank to pyxser users for their feedback.

© dmw for coder . cl, 2010. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

memory profiling

On the profiling script, the only remaining reference to constructed objects. Some interesting notes about the memory profiling task, is that the most allocated object type is str with 278 allocations, and is using the 47% with 10384 bytes, but the heaviest object is dictionary with 79 allocations, the 13% and 457720 bytes. I’ve tested pyxser using valgrind without any kind of true report of memory leaks.

Also, in the pyxser distribution, you can find the test-utf8-leak.py script, which executes serialization and deserialization functions up to 1000000 times, leaving python executable just using a small portion of the operating system memory, and certainly you will notice that pyxser maintains its memory usage along that test.

speed tests

Speed tests are going fine, I’ve reduced a small amount of the used by the serialized and created a new test that executes each pyxser function 1000 times. The result can be seen as follows:

Deserialization functions are the slowest ones, requiring almost the double time that serialization takes, but thinking a little, you will notice that the XML parsing process is slower than Python object tree traversal. Some functions, like getdtd() and getdtdc14n() practically do not require time to being executed, since both DTDs are pre-allocated on module loading, the same applies to pyxser XML schemas. I think that I will reduce the execution and load time along the time, since pyxser has reached a good maturity level, without memory leaks and well structured tests, for different kinds of objects — as any lazy resource initialization.

© dmw for coder . cl, 2010. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

metrics

pyxser is complex. It requires some compiler construction techniques. The main one is memoization, which uses an internal and thread safe cache to allow the serializer to create unique XML instances of the pyxs:obj element. Also, it uses mutually recursive functions while is harvesting objects from the object tree using an preorder traversal tree algorithm. The result of implementing it, is the following table:

But there is a fact, pyxser is fast as hell!. It can do 10010 serializations in 1.992 seconds and 11011 deserializations in 6.910 seconds. So, I was introducing some enhancements and securing the code doing code harndening test and shorting code flow paths. Now the code looks flat and more elegant.

profiling

After securing the code I got a slower pyxser implementation. So, I was impressed since I got to double the time on certain internal functions. Here is the metric on how code was executed:

But after some code cleanup, refactoring and code path shortening, I got much better results, and I’ve maintained the original perfomance with hardened, ordered and flat code. The reduction of nested statements was quite hard, but I’ve done it. It has just three levels as an average of nested statements:

enhancements

pyxser now can serialize, for example SqlAlchemy objects, sent them through the network and restore the instance so far away. For those kind of objects you must follow a simple rule, use the selector argument and the depth argument. The pyxser distribution comes with some test files, test-utf8-sqlalchemy.py is one of those files, where we define a class User:

class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    name = Column(String)
    fullname = Column(String)
    password = Column(String)

    def __init__(self):
        self.name = None
        self.fullname = None
        self.password = None

    def get_set(self):
        return (self.name, self.fullname, self.password)

    def __repr__(self):
        return "User('%s','%s', '%s')" % self.get_set()

The first rule is quite simple: the constructor must be a simple constructor, without arguments, but it can hold initialization code, just remain it without arguments. And the second rule is to use the selector argument:

def sqlalch_filter(v):
    r = ((not callable(v[1]))
         and (not (v[0].startswith("_")))
         and ((v[0] != "metadata")))
    return r

def sqlalch_selector(o):
    r = dict(filter(sqlalch_filter, inspect.getmembers(o)))
    return r

serialized = pyxser.serialize(obj = ed_user, enc = 'utf-8', selector = sqlalch_selector, depth = 2)

This will create a very simple object:

<?xml version="1.0" encoding="utf-8"?>
<pyxs:obj xmlns:pyxs="http://projects.coder.cl/pyxser/model/" version="1.0" type="User" module="testpkg.sample" objid="id170543564">
  <pyxs:prop type="str" name="fullname">Ed Jones</pyxs:prop>
  <pyxs:prop type="str" name="password">password</pyxs:prop>
  <pyxs:prop type="str" name="name">ed</pyxs:prop>
</pyxs:obj>

But when it is restored on the end, it will remain intact.

Some people was saying that pyxser do not comes with documentation. Those people have not seen the documentation. pyxser as any Python extension, is self documented, this means that you must launch pydoc to read it. If you never have used pydoc, just try it: pydoc -p8080, this will create a small web server running on localhost to let you read the documentation. It has some other interesting parameters, others than depth and selector, such as typemap, which allows you to create custom serializations of certain objects — such as files.

where is located

The project is hosted at SourceForge: pyxser@sourceforge and the home page of the project is located pyxser@coder.cl.

© dmw for coder . cl, 2010. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

interface definition

JavaScript requires class definitions to work. So, you need to create IDL definitions of your scriptable classes. The syntax for the XPIDL is quite standard, so isn’t difficult to create interfaces with this IDL variant. To allow you to use IDL defined interfaces on JavaScript, interfaces must be defined as scriptable and must be derived from nsISupports interface, with an unique uuid. Let me show you an example:

#include "nsISupports.idl"
#include "nsIMyProtocolRequest.idl"
#include "nsIMyProtocolResponse.idl"
#include "nsIMyProtocolError.idl"
#include "nsIMyProtocolStatus.idl"
#include "nsIMyProtocolService.idl"

[scriptable, uuid(3455c51a-3323-4343-844f-2342526113c2)]
interface nsIMyProtocolService : nsISupports
{
    readonly attribute nsIMyProtocolError error;
    nsIMyProtocolResponse get(in nsIMyProtocolRequest req);
    nsIMyProtocolStatus getStatus(in nsIMyProtocolRequest req);
};

This will create a XPCOM object wrapped in JavaScript similar to the following example:

var nsIMyProtocolService = {
    error: new nsIMyProtocolError(),
    get: function (req) {
    },
    getStatus: function (req) {
    },
};

class definition

Here, error is a read only attribute, and get() and getStatus() are methods. But this isn’t enough, that is just the interface definition. The implementation must be done in C++ so the interface defintion is transformed to C++ code — a C++ header specifically — which must be included in the class implementation C++ code file. Where need to consider a special note on class attributes and methods: Every method implementation has the form: nsresult MethodName(…input parameters if any…, …output parameters if any…), where nsresult is the type of the returned status to the XPCOM API to let it know how was executed the method, so you can return NS_OK on execution correctness, NS_ERROR_NULL_POINTER for invalid input as null pointers, NS_ERROR_INVALID_POINTER for invalid variable input and so on. Well, the class definition inside the implementation file, should look as follow:

class nsMyProtocolService : public nsIMyProtocolService
{
public:
    nsMyProtocolService();
    ~nsMyProtocolService();

    nsresult GetError(nsIMyProtocolError **out);
    nsresult Get(nsIMyProtocolRequest *req,
                 nsIMyProtocolResponse **out);
    nsresult GetStatus(nsIMyProtocolRequest *req,
                 nsIMyProtocolStatus **out);
private:
    int statusCode;
    int errorCode;
    char *errorString;
    nsIMyProtocolError *currentError;
}

class implementation

You must be a two star programmer to know how to implement the argument passing and method output, but I know that you are a good C and C++ programmer, so this is not an obstacle and you can act as a three star programmer without problems. So, the implementation, for example for the GetError() method, which has been mapped to the error attribute on the nsIMyProtocolService interface, should look as follows:

nsresult
nsMyProtocolService::GetError(nsIMyProtocolError **out)
{
    nsMyProtocolError *rout;
    result = NS_ERROR_NULL_POINTER;
    if (out == NULL || out == nsnull) {
        return result;
    }
    rout = new nsMyProtocolError();
    if (rout == NULL) {
        result = NS_ERROR_NOT_INITIALIZED;
        return result;
    }
    if (currentError != NULL && currentError != nsnull) {
        NS_RELEASE(currentError);
        delete currentError;
    }
    rout->SetErrorCode(errorCode);
    rout->SetErrorString(errorString);
    NS_ADDREF(rout);
    *out = rout;
    result = NS_OK;
    return result;
}

On the example above, we have created a new pointer to the nsIMyProtocolError interface implementation. That pointer, before is being returned to the JavaScript and wrapped by the XPCOM API, must have an increased reference count, so Firefox do not remove that object. But as any language which uses reference counting in its garbage collection tasks, requires a reference counting decrement before the object is released. So you need to release those references using the NS_RELEASE macro. As any software development — with or without a garbage collector behind — you must be careful with the memory usage. Any object with a reference count different from zero, will hang Firefox, so you need to release reference counting on destructors too.

nsMyProtocolService::~nsMyProtocolService()
{
    if (currentError != NULL && currentError != nsnull) {
        NS_RELEASE(currentError);
        delete currentError;
    }
}

The example above shows how the destructor releases the reference counting for the currentError object. But think a little. Every time you call GetError(), in other words, you request the error attribute on the nsIMyProtocolService instance, you are increasing references which are left without being decreased. You need an storage for those pointers, so you can use any collection class that you want and is supported by your platform, but is recommended that you use the kind of storage classes which are present on the XPCOM API. How to create a collection?

nsCOMPtr<nsIMutableArray> container;
container = do_CreateInstance(NS_ARRAY_CONTRACTID);

The nsIMutableArray provides an array class which can be used inside your Firefox extension and also it can be exposed as a JavaScript array, it is an scriptable class, and also provides methods for pushing and extracting elements as the JavaScript array does, so you can use methods such as GetLength(), which is mapped to the length attribute, AppendElement(), which is mapped to the append() method, QueryElementAt() which is mapped to the array[index] operator. The do_CreateInstance template will allow you create instances of you interfaces, when you are requesting them from other extensions. For example if you want to use the WebDAV extension from your C++ extension, you need to use do_CreateInstance template.

component declaration

Finally, you need to register and expose your components to the JavaScript interface and the XPCOM API, so you need to define a contract identifier and add some static code to you extension.

#define NS_MYSVC_CONTRACTID         "@mozilla.org/myprotocol/service;1"
#define NS_MYSVC_CID
    { /* 3455c51a-3323-4343-844f-2342526113c2 */
        0x3455c51a,
            0x3323,
            0x4343,
            { 0x84, 0x4f, 0x23, 0x42, 0x52, 0x61, 0x13, 0xc2 }
    }

NS_GENERIC_FACTORY_CONSTRUCTOR(nsMyProtocolService)
NS_DECL_CLASSINFO(nsMyProtocolService)
static const nsModuleComponentInfo components[] =
{
    { "My Protocol Service", NS_MYSVC_CONTRACTID, NS_MYSVC_CID,
      nsMyProtocolServiceConstructor,
      NULL, NULL, NULL,
      NS_CI_INTERFACE_GETTER_NAME(nsMyProtocolService),
      NULL,
      &NS_CLASSINFO_NAME(nsMyProtocolService)
    }
};

NS_IMPL_NSGETMODULE(nsJxSNMPService, components)

This can be used as template, where the components array contains the interface definitions and interface implementation references that allow you to use those classes from JavaScript. This code will:

NS_GENERIC_FACTORY_CONSTRUCTOR

Will declare nsMyProtocolServiceConstructor to be used as default constructor by the do_CreateInstance() template.

NS_DECL_CLASSINFO

Will declare class information referencing the nsMyProtocolService class to allow you to use that class information from JavaScript to be exposed to the XPCOM API.

NS_MYSVC_CONTRACTID

Contract (interface) identifier, it will be required by your JavaScript to instantiate you class, using the interface as was defined in nsIMyProtocolService.

NS_MYSVC_CID

This is the unique uuid identifier for your component. Remember that those components are quite analogous to the COM+ components on the Window$ platform.

NS_IMPL_NSGETMODULE(nsJxSNMPService, components)

This line finally will expose — through static code — your component to the XPCOM API, and will allow your class to being used from JavaScript or your Firefox extension. Remember that components is an array which can hold multiple interface and class definitions.

component exposition

If you followed the article with a conscious reading, the following lines of JavaScript will bring you the proper guide to instantiate your own component. I’m assuming that you are an experienced system programmer and web developer to handle this article:

const C = Components;
const CI = C.interfaces;
const CL = C.classes;

function getContract(contract) {
  try {
    return C.classes[contract];
  } catch (e) {
    alert(e.message);
  }
}

function getService(contract, iface) {
  try {
    return getContract(contract).getService(CI[iface]);
  } catch (e) {
    alert(e.message);
  }
}

function getInterface(contract, iface) {
  try {
    return getContract(contract).createInstance(CI[iface]);
  } catch (e) {
    alert(e.message);
  }
}

try {
    var myService = getService("@mozilla.org/myprotocol/service;1",
                               "nsIMyProtocolService");

    var myRequest = getService("@mozilla.org/myprotocol/request;1",
                               "nsIMyProtocolRequest");

    myRequest.first_argument = 200;
    myRequest.second_argument = "hello world!";
    var myResponse = myService.get(myRequest);
    if (typeof(myService.error) == "object"
        && myService.error.status != 0) {
        alert(myService.error.toString());
    }
} catch (e) {
    alert(e.message);
}

interesting code to look

You can start downloading the Firefox source code and take a look on the following interfaces:

• extensions/webdav, this defines the "@mozilla.org/webdav/service;1" interface, allowing you to create WebDAV clients from JavaScript.
• extensions/webservices, this defines the "@mozilla.org/xmlextras/proxy/webserviceproxy;1," and similar interfaces, allowing you to create WebService client proxies from JavaScript.
• extensions/sql, this folder stores "@mozilla.org/sql/connection;1" and similar interfaces, so Firefox can be used directly as client to query some RDBMS engines — such as PostgreSQL and SQLite.

You can go on deeper reading code and references to enhance your XPCOM component development ;)

references

• "XPCOM", Wikipedia Article, as introductory reading.
• "XPCOM Part 1: An introduction to XPCOM", IBM DeveloperWorks article, by Rick Parrish.
• "XPCOM Part 2: XPCOM component basics", IBM DeveloperWorks article, by Rick Parrish.
• "XPCOM Part 3: Setting up XPCOM", IBM DeveloperWorks article, by Rick Parrish.
• "XPCOM", Mozilla Reference Documentation.

© dmw for coder . cl, 2010. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

Hello Python Community.

I’m pleased to announce pyxser-1.4.4r, a python extension which contains functions to serialize and deserialize Python Objects into XML. It is a model based serializer. Here is the ChangeLog entry for this release:

1.4.4r (2010.02.10):

        Daniel Molina Wegener 

        * src/include/pyxser_collections.h - added set handling
        function prototypes. Added support for unicode
        key names, which are converted to the user settings
        encoding (ie utf-8) inside the XML output.
        * src/pyxser_serializer.c - removed memory leak. Addded
        support for unicode object names in dictionary/list types.
        * src/pyxser_collections.c - added set handling function
        prototypes. added name property handling algorithm, so
        non string name properties are not serialized. I shall
        extend it to other modules.
        * src/pyxser_tools.c - added set handling prototypes and
        set type checking function.
        * test-utf8-leak.py - added serialization of SQL Alchemy
        objects, so we can test more complex Python objects
        serialization.
        * test-utf8-sqlalchemy.py - added sql alchemy object
        serialization test.
        * src/pyxser_serializer.c - reduced serialization algorithms,
        replacing deep nested if statements by flatten ones.
        * src/pyxser_collections.c - reduced serialization algorithms
        replacing deep nested if statements by flatten ones.
        * src/pyxser_typem.c - reduced serialization algorithms,
        replacing deep nested if statements by flatten ones.

        Thanks to pyxser users for their feedback.

This release contains some bug fixes, mainly related to type checking and type handling. I hope this small extension will help you on your programming tasks.

• The project is hosted at:
  http://sourceforge.net/projects/pyxser/
• The web page for the project is located at:
  http://coder.cl/products/pyxser/
• PyPi entry is:
  http://pypi.python.org/pypi/pyxser/1.4.4r
• For a sample article on how to integrate pyxser with ZSI WebServices:
  http://coder.cl/2009/10/18/pyxser-and-zsi-webservices/

Thanks and best regards…

I hope that this module can help you in your development tasks and thanks for your feedback.

© dmw for coder . cl, 2010. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)

pyxser

pyxser have about one year of development, some months doing research, and other months doing development or coding the Python Module.

And the SVN log show an average hour for commits between 22:00 and 23:00

r125 | damowe | 2010-02-10 16:15:49 -0300 (Wed, 10 Feb 2010) | 2 lines
r124 | damowe | 2010-02-10 15:52:31 -0300 (Wed, 10 Feb 2010) | 2 lines
r123 | damowe | 2010-02-10 13:30:15 -0300 (Wed, 10 Feb 2010) | 10 lines
r122 | damowe | 2010-02-02 08:47:07 -0300 (Tue, 02 Feb 2010) | 3 lines
r121 | damowe | 2009-12-26 21:52:49 -0300 (Sat, 26 Dec 2009) | 2 lines
r118 | damowe | 2009-12-26 21:40:33 -0300 (Sat, 26 Dec 2009) | 2 lines
r117 | damowe | 2009-12-25 15:20:30 -0300 (Fri, 25 Dec 2009) | 4 lines
r116 | damowe | 2009-12-22 20:09:25 -0300 (Tue, 22 Dec 2009) | 5 lines
r115 | damowe | 2009-12-21 19:47:50 -0300 (Mon, 21 Dec 2009) | 2 lines
r114 | damowe | 2009-12-20 01:38:45 -0300 (Sun, 20 Dec 2009) | 7 lines
r112 | damowe | 2009-12-03 09:48:41 -0300 (Thu, 03 Dec 2009) | 6 lines
r110 | damowe | 2009-11-30 14:52:10 -0300 (Mon, 30 Nov 2009) | 2 lines
r109 | damowe | 2009-11-30 14:46:43 -0300 (Mon, 30 Nov 2009) | 9 lines
r107 | damowe | 2009-08-23 11:43:52 -0400 (Sun, 23 Aug 2009) | 2 lines
r102 | damowe | 2009-08-23 11:29:07 -0400 (Sun, 23 Aug 2009) | 2 lines
r99 | damowe | 2009-08-23 11:12:20 -0400 (Sun, 23 Aug 2009) | 6 lines
r98 | damowe | 2009-08-08 15:15:07 -0400 (Sat, 08 Aug 2009) | 3 lines
r93 | damowe | 2009-07-28 21:59:10 -0400 (Tue, 28 Jul 2009) | 2 lines
r90 | damowe | 2009-07-27 22:22:55 -0400 (Mon, 27 Jul 2009) | 2 lines
r89 | damowe | 2009-07-27 22:21:50 -0400 (Mon, 27 Jul 2009) | 5 lines
r88 | damowe | 2009-07-26 22:27:23 -0400 (Sun, 26 Jul 2009) | 4 lines
r87 | damowe | 2009-07-20 16:02:27 -0400 (Mon, 20 Jul 2009) | 5 lines
r86 | damowe | 2009-07-17 22:24:53 -0400 (Fri, 17 Jul 2009) | 4 lines
r84 | damowe | 2009-05-09 23:19:49 -0400 (Sat, 09 May 2009) | 2 lines
r83 | damowe | 2009-05-09 22:31:00 -0400 (Sat, 09 May 2009) | 7 lines
r82 | damowe | 2009-05-09 11:00:44 -0400 (Sat, 09 May 2009) | 3 lines
r81 | damowe | 2009-05-08 21:31:56 -0400 (Fri, 08 May 2009) | 2 lines
r80 | damowe | 2009-04-28 00:32:53 -0400 (Tue, 28 Apr 2009) | 3 lines
r78 | damowe | 2009-04-26 19:21:16 -0400 (Sun, 26 Apr 2009) | 2 lines
r77 | damowe | 2009-04-26 19:13:26 -0400 (Sun, 26 Apr 2009) | 2 lines
r76 | damowe | 2009-04-26 17:34:09 -0400 (Sun, 26 Apr 2009) | 4 lines
r75 | damowe | 2009-04-25 19:31:45 -0400 (Sat, 25 Apr 2009) | 3 lines
r74 | damowe | 2009-04-24 20:49:40 -0400 (Fri, 24 Apr 2009) | 3 lines
r73 | damowe | 2009-04-23 23:06:46 -0400 (Thu, 23 Apr 2009) | 4 lines
r72 | damowe | 2009-04-22 08:28:31 -0400 (Wed, 22 Apr 2009) | 3 lines
r71 | damowe | 2009-04-22 00:52:12 -0400 (Wed, 22 Apr 2009) | 2 lines
r70 | damowe | 2009-04-22 00:28:48 -0400 (Wed, 22 Apr 2009) | 3 lines
r69 | damowe | 2009-04-21 23:09:09 -0400 (Tue, 21 Apr 2009) | 2 lines
r68 | damowe | 2009-04-21 16:41:11 -0400 (Tue, 21 Apr 2009) | 3 lines
r65 | damowe | 2009-04-19 01:24:34 -0400 (Sun, 19 Apr 2009) | 2 lines
r64 | damowe | 2009-04-19 01:22:15 -0400 (Sun, 19 Apr 2009) | 2 lines
r63 | damowe | 2009-04-19 01:17:29 -0400 (Sun, 19 Apr 2009) | 2 lines
r62 | damowe | 2009-04-19 01:10:33 -0400 (Sun, 19 Apr 2009) | 2 lines
r61 | damowe | 2009-04-19 00:01:47 -0400 (Sun, 19 Apr 2009) | 3 lines
r59 | damowe | 2009-04-18 22:57:01 -0400 (Sat, 18 Apr 2009) | 2 lines
r58 | damowe | 2009-04-18 22:30:30 -0400 (Sat, 18 Apr 2009) | 3 lines
r57 | damowe | 2009-04-18 04:26:58 -0400 (Sat, 18 Apr 2009) | 2 lines
r56 | damowe | 2009-04-18 03:28:56 -0400 (Sat, 18 Apr 2009) | 3 lines
r55 | damowe | 2009-04-15 23:38:34 -0400 (Wed, 15 Apr 2009) | 2 lines
r54 | damowe | 2009-04-15 23:10:32 -0400 (Wed, 15 Apr 2009) | 2 lines
r53 | damowe | 2009-04-15 22:46:15 -0400 (Wed, 15 Apr 2009) | 3 lines
r52 | damowe | 2009-04-10 18:30:22 -0400 (Fri, 10 Apr 2009) | 2 lines
r49 | damowe | 2009-04-10 00:17:25 -0400 (Fri, 10 Apr 2009) | 2 lines
r47 | damowe | 2009-04-08 23:43:50 -0400 (Wed, 08 Apr 2009) | 4 lines
r46 | damowe | 2009-04-08 14:29:42 -0400 (Wed, 08 Apr 2009) | 4 lines
r45 | damowe | 2009-04-08 01:31:22 -0400 (Wed, 08 Apr 2009) | 2 lines
r44 | damowe | 2009-04-08 01:30:18 -0400 (Wed, 08 Apr 2009) | 2 lines
r43 | damowe | 2009-04-08 01:28:36 -0400 (Wed, 08 Apr 2009) | 3 lines
r42 | damowe | 2009-04-06 21:58:57 -0400 (Mon, 06 Apr 2009) | 2 lines
r41 | damowe | 2009-04-06 21:46:19 -0400 (Mon, 06 Apr 2009) | 2 lines
r40 | damowe | 2009-04-06 21:36:55 -0400 (Mon, 06 Apr 2009) | 3 lines
r39 | damowe | 2009-04-05 22:25:50 -0400 (Sun, 05 Apr 2009) | 2 lines
r38 | damowe | 2009-04-05 22:19:10 -0400 (Sun, 05 Apr 2009) | 4 lines
r37 | damowe | 2009-04-04 20:18:15 -0400 (Sat, 04 Apr 2009) | 3 lines
r36 | damowe | 2009-03-31 23:49:23 -0400 (Tue, 31 Mar 2009) | 5 lines
r33 | damowe | 2009-03-28 12:13:41 -0400 (Sat, 28 Mar 2009) | 2 lines
r30 | damowe | 2009-03-26 22:17:10 -0400 (Thu, 26 Mar 2009) | 3 lines
r29 | damowe | 2009-03-26 21:59:57 -0400 (Thu, 26 Mar 2009) | 5 lines
r28 | damowe | 2009-03-26 21:17:10 -0400 (Thu, 26 Mar 2009) | 2 lines
r27 | damowe | 2009-03-25 23:26:30 -0400 (Wed, 25 Mar 2009) | 3 lines
r26 | damowe | 2009-03-25 22:58:16 -0400 (Wed, 25 Mar 2009) | 5 lines
r25 | damowe | 2009-03-25 22:03:16 -0400 (Wed, 25 Mar 2009) | 2 lines
r24 | damowe | 2009-03-25 21:00:44 -0400 (Wed, 25 Mar 2009) | 4 lines
r23 | damowe | 2009-03-25 20:48:26 -0400 (Wed, 25 Mar 2009) | 3 lines
r22 | damowe | 2009-03-25 20:34:30 -0400 (Wed, 25 Mar 2009) | 2 lines
r21 | damowe | 2009-03-25 20:15:58 -0400 (Wed, 25 Mar 2009) | 2 lines
r20 | damowe | 2009-03-24 20:47:42 -0400 (Tue, 24 Mar 2009) | 2 lines
r19 | damowe | 2009-03-23 23:41:47 -0400 (Mon, 23 Mar 2009) | 5 lines
r18 | damowe | 2009-03-23 21:03:13 -0400 (Mon, 23 Mar 2009) | 3 lines
r17 | damowe | 2009-03-23 20:16:58 -0400 (Mon, 23 Mar 2009) | 2 lines
r16 | damowe | 2009-03-19 22:57:46 -0400 (Thu, 19 Mar 2009) | 2 lines
r15 | damowe | 2009-03-19 22:30:56 -0400 (Thu, 19 Mar 2009) | 5 lines
r14 | damowe | 2009-03-19 20:37:13 -0400 (Thu, 19 Mar 2009) | 2 lines
r13 | damowe | 2009-03-19 00:37:39 -0400 (Thu, 19 Mar 2009) | 3 lines
r12 | damowe | 2009-03-19 00:11:23 -0400 (Thu, 19 Mar 2009) | 3 lines
r11 | damowe | 2009-03-18 23:47:08 -0400 (Wed, 18 Mar 2009) | 3 lines
r10 | damowe | 2009-03-17 22:25:47 -0400 (Tue, 17 Mar 2009) | 2 lines
r9 | damowe | 2009-03-17 22:23:21 -0400 (Tue, 17 Mar 2009) | 2 lines
r8 | damowe | 2009-03-17 22:16:37 -0400 (Tue, 17 Mar 2009) | 2 lines
r7 | damowe | 2009-03-17 00:55:43 -0400 (Tue, 17 Mar 2009) | 2 lines
r6 | damowe | 2009-03-16 23:33:31 -0400 (Mon, 16 Mar 2009) | 2 lines
r5 | damowe | 2009-03-15 17:21:57 -0400 (Sun, 15 Mar 2009) | 2 lines
r4 | damowe | 2009-03-15 17:07:39 -0400 (Sun, 15 Mar 2009) | 2 lines
r1 | damowe | 2009-03-15 15:35:31 -0400 (Sun, 15 Mar 2009) | 2 lines

The project has 6,198 lines of code… a good effort and a good product. During the day I must work on those projects which bring me money, at night and as hobbits I work on my FOSS projects. I have a little time to work on them.

caffeine

caffeine or C Application Framework has 14,177 lines of code, and it is evaluated as one project with three humans working on it, but it is really one, me.

And the SVN log show an average hour for commits between 22:00 and 23:00

r125 | damowe | 2009-09-30 14:45:06 -0400 (Wed, 30 Sep 2009) | 6 lines
r124 | damowe | 2009-09-26 18:49:31 -0400 (Sat, 26 Sep 2009) | 2 lines
r123 | damowe | 2009-09-26 17:46:26 -0400 (Sat, 26 Sep 2009) | 5 lines
r122 | damowe | 2009-09-26 13:14:50 -0400 (Sat, 26 Sep 2009) | 2 lines
r121 | damowe | 2009-09-26 12:25:19 -0400 (Sat, 26 Sep 2009) | 4 lines
r120 | damowe | 2009-09-22 05:18:11 -0400 (Tue, 22 Sep 2009) | 8 lines
r119 | damowe | 2009-09-19 23:27:06 -0400 (Sat, 19 Sep 2009) | 5 lines
r118 | damowe | 2009-09-19 19:06:50 -0400 (Sat, 19 Sep 2009) | 8 lines
r117 | damowe | 2009-09-01 22:18:54 -0400 (Tue, 01 Sep 2009) | 5 lines
r116 | damowe | 2008-10-27 07:40:14 -0300 (Mon, 27 Oct 2008) | 2 lines
r115 | damowe | 2008-10-27 07:38:30 -0300 (Mon, 27 Oct 2008) | 2 lines
r114 | damowe | 2008-10-27 07:35:09 -0300 (Mon, 27 Oct 2008) | 3 lines
r113 | damowe | 2008-10-25 13:01:20 -0300 (Sat, 25 Oct 2008) | 2 lines
r112 | damowe | 2008-06-10 21:10:30 -0400 (Tue, 10 Jun 2008) | 3 lines
r111 | damowe | 2008-06-06 20:05:39 -0400 (Fri, 06 Jun 2008) | 5 lines
r110 | damowe | 2008-05-08 21:12:50 -0400 (Thu, 08 May 2008) | 2 lines
r109 | damowe | 2008-05-06 23:53:10 -0400 (Tue, 06 May 2008) | 2 lines
r108 | damowe | 2008-05-05 23:37:42 -0400 (Mon, 05 May 2008) | 2 lines
r107 | damowe | 2008-04-27 02:08:49 -0400 (Sun, 27 Apr 2008) | 2 lines
r106 | damowe | 2008-04-26 11:59:49 -0400 (Sat, 26 Apr 2008) | 4 lines
r105 | damowe | 2008-04-22 23:06:33 -0400 (Tue, 22 Apr 2008) | 3 lines
r104 | damowe | 2008-04-21 21:13:06 -0400 (Mon, 21 Apr 2008) | 4 lines
r103 | damowe | 2008-02-10 13:16:32 -0300 (Sun, 10 Feb 2008) | 3 lines
r102 | damowe | 2008-02-10 10:22:34 -0300 (Sun, 10 Feb 2008) | 2 lines
r101 | damowe | 2008-02-10 10:08:35 -0300 (Sun, 10 Feb 2008) | 2 lines
r100 | damowe | 2008-01-06 12:07:57 -0300 (Sun, 06 Jan 2008) | 4 lines
r99 | damowe | 2008-01-05 20:03:27 -0300 (Sat, 05 Jan 2008) | 4 lines
r98 | damowe | 2008-01-01 17:29:14 -0300 (Tue, 01 Jan 2008) | 3 lines
r97 | damowe | 2007-12-31 15:47:20 -0300 (Mon, 31 Dec 2007) | 2 lines
r96 | damowe | 2007-12-30 12:15:46 -0300 (Sun, 30 Dec 2007) | 2 lines
r95 | damowe | 2007-12-30 12:06:41 -0300 (Sun, 30 Dec 2007) | 3 lines
r94 | damowe | 2007-12-30 07:59:58 -0300 (Sun, 30 Dec 2007) | 2 lines
r93 | damowe | 2007-12-25 10:37:15 -0300 (Tue, 25 Dec 2007) | 3 lines
r92 | damowe | 2007-12-22 09:57:27 -0300 (Sat, 22 Dec 2007) | 2 lines
r91 | damowe | 2007-12-22 09:56:15 -0300 (Sat, 22 Dec 2007) | 4 lines
r90 | damowe | 2007-12-22 07:26:39 -0300 (Sat, 22 Dec 2007) | 3 lines
r89 | damowe | 2007-12-16 22:21:51 -0300 (Sun, 16 Dec 2007) | 4 lines
r88 | damowe | 2007-12-03 21:35:27 -0300 (Mon, 03 Dec 2007) | 2 lines
r87 | damowe | 2007-12-01 23:56:53 -0300 (Sat, 01 Dec 2007) | 3 lines
r86 | damowe | 2007-12-01 23:44:02 -0300 (Sat, 01 Dec 2007) | 2 lines
r85 | damowe | 2007-11-11 09:06:24 -0300 (Sun, 11 Nov 2007) | 4 lines
r84 | damowe | 2007-11-10 21:43:36 -0300 (Sat, 10 Nov 2007) | 2 lines
r83 | damowe | 2007-11-10 21:25:58 -0300 (Sat, 10 Nov 2007) | 2 lines
r82 | damowe | 2007-10-07 11:39:55 -0400 (Sun, 07 Oct 2007) | 3 lines
r81 | damowe | 2007-10-07 08:32:09 -0400 (Sun, 07 Oct 2007) | 3 lines
r80 | damowe | 2007-09-30 21:53:52 -0400 (Sun, 30 Sep 2007) | 3 lines
r79 | damowe | 2007-09-19 18:27:20 -0400 (Wed, 19 Sep 2007) | 2 lines
r78 | damowe | 2007-09-18 00:34:21 -0400 (Tue, 18 Sep 2007) | 2 lines
r77 | damowe | 2007-09-17 17:10:57 -0400 (Mon, 17 Sep 2007) | 3 lines
r76 | damowe | 2007-09-15 17:27:45 -0400 (Sat, 15 Sep 2007) | 2 lines
r75 | damowe | 2007-09-08 11:19:19 -0400 (Sat, 08 Sep 2007) | 2 lines
r74 | damowe | 2007-09-02 12:11:38 -0400 (Sun, 02 Sep 2007) | 2 lines
r73 | damowe | 2007-09-02 10:57:54 -0400 (Sun, 02 Sep 2007) | 2 lines
r72 | damowe | 2007-09-02 10:55:09 -0400 (Sun, 02 Sep 2007) | 2 lines
r71 | damowe | 2007-09-02 09:38:43 -0400 (Sun, 02 Sep 2007) | 5 lines
r70 | damowe | 2007-09-02 02:13:20 -0400 (Sun, 02 Sep 2007) | 4 lines
r69 | damowe | 2007-08-31 20:05:06 -0400 (Fri, 31 Aug 2007) | 3 lines
r68 | damowe | 2007-08-26 13:34:53 -0400 (Sun, 26 Aug 2007) | 2 lines
r67 | damowe | 2007-08-26 13:15:04 -0400 (Sun, 26 Aug 2007) | 3 lines
r66 | damowe | 2007-08-26 10:10:19 -0400 (Sun, 26 Aug 2007) | 3 lines
r65 | damowe | 2007-08-25 19:00:10 -0400 (Sat, 25 Aug 2007) | 3 lines
r64 | damowe | 2007-08-19 00:26:00 -0400 (Sun, 19 Aug 2007) | 3 lines
r63 | damowe | 2007-08-18 10:36:16 -0400 (Sat, 18 Aug 2007) | 3 lines
r62 | damowe | 2007-08-15 17:23:28 -0400 (Wed, 15 Aug 2007) | 2 lines
r61 | damowe | 2007-08-13 07:48:31 -0400 (Mon, 13 Aug 2007) | 3 lines
r60 | damowe | 2007-08-12 17:06:08 -0400 (Sun, 12 Aug 2007) | 2 lines
r59 | damowe | 2007-08-12 16:33:09 -0400 (Sun, 12 Aug 2007) | 3 lines
r58 | damowe | 2007-08-12 13:39:59 -0400 (Sun, 12 Aug 2007) | 2 lines
r57 | damowe | 2007-08-12 01:26:32 -0400 (Sun, 12 Aug 2007) | 2 lines
r56 | damowe | 2007-08-11 13:26:10 -0400 (Sat, 11 Aug 2007) | 2 lines
r55 | damowe | 2007-08-11 13:21:17 -0400 (Sat, 11 Aug 2007) | 3 lines
r54 | damowe | 2007-08-06 21:58:22 -0400 (Mon, 06 Aug 2007) | 2 lines
r53 | damowe | 2007-08-04 23:03:06 -0400 (Sat, 04 Aug 2007) | 3 lines
r52 | damowe | 2007-08-04 22:39:10 -0400 (Sat, 04 Aug 2007) | 3 lines
r51 | damowe | 2007-08-04 17:28:45 -0400 (Sat, 04 Aug 2007) | 2 lines
r50 | damowe | 2007-08-04 16:54:48 -0400 (Sat, 04 Aug 2007) | 2 lines
r49 | damowe | 2007-07-29 09:15:12 -0400 (Sun, 29 Jul 2007) | 2 lines
r48 | damowe | 2007-07-28 17:38:23 -0400 (Sat, 28 Jul 2007) | 2 lines
r47 | damowe | 2007-07-16 23:45:16 -0400 (Mon, 16 Jul 2007) | 3 lines
r46 | damowe | 2007-07-16 16:47:06 -0400 (Mon, 16 Jul 2007) | 3 lines
r45 | damowe | 2007-07-15 20:03:51 -0400 (Sun, 15 Jul 2007) | 3 lines
r44 | damowe | 2007-07-15 12:10:35 -0400 (Sun, 15 Jul 2007) | 3 lines
r43 | damowe | 2007-07-02 17:30:56 -0400 (Mon, 02 Jul 2007) | 2 lines
r42 | damowe | 2007-07-02 10:46:27 -0400 (Mon, 02 Jul 2007) | 3 lines
r41 | damowe | 2007-06-30 16:23:19 -0400 (Sat, 30 Jun 2007) | 2 lines
r40 | damowe | 2007-06-23 21:08:20 -0400 (Sat, 23 Jun 2007) | 3 lines
r39 | damowe | 2007-06-23 10:37:22 -0400 (Sat, 23 Jun 2007) | 2 lines
r38 | damowe | 2007-06-23 10:33:24 -0400 (Sat, 23 Jun 2007) | 2 lines
r37 | damowe | 2007-06-22 23:10:58 -0400 (Fri, 22 Jun 2007) | 3 lines
r36 | damowe | 2007-06-20 21:57:34 -0400 (Wed, 20 Jun 2007) | 3 lines
r35 | damowe | 2007-06-18 21:22:26 -0400 (Mon, 18 Jun 2007) | 3 lines
r34 | damowe | 2007-06-17 21:33:13 -0400 (Sun, 17 Jun 2007) | 2 lines
r33 | damowe | 2007-06-17 21:31:58 -0400 (Sun, 17 Jun 2007) | 2 lines
r32 | damowe | 2007-06-17 18:48:40 -0400 (Sun, 17 Jun 2007) | 3 lines
r31 | damowe | 2007-06-17 12:03:32 -0400 (Sun, 17 Jun 2007) | 3 lines
r30 | damowe | 2007-06-17 11:50:15 -0400 (Sun, 17 Jun 2007) | 2 lines
r29 | damowe | 2007-06-16 21:48:05 -0400 (Sat, 16 Jun 2007) | 2 lines
r28 | damowe | 2007-06-16 21:43:38 -0400 (Sat, 16 Jun 2007) | 3 lines
r27 | damowe | 2007-06-09 18:25:07 -0400 (Sat, 09 Jun 2007) | 2 lines
r26 | damowe | 2007-06-09 18:05:07 -0400 (Sat, 09 Jun 2007) | 2 lines
r25 | damowe | 2007-06-09 18:03:56 -0400 (Sat, 09 Jun 2007) | 3 lines
r24 | damowe | 2007-06-03 20:45:25 -0400 (Sun, 03 Jun 2007) | 3 lines
r23 | damowe | 2007-06-03 19:08:34 -0400 (Sun, 03 Jun 2007) | 2 lines
r22 | damowe | 2007-06-03 19:07:35 -0400 (Sun, 03 Jun 2007) | 2 lines
r21 | damowe | 2007-05-21 10:48:01 -0400 (Mon, 21 May 2007) | 2 lines
r20 | damowe | 2007-05-20 22:00:12 -0400 (Sun, 20 May 2007) | 2 lines
r19 | damowe | 2007-05-20 21:45:38 -0400 (Sun, 20 May 2007) | 6 lines
r18 | damowe | 2007-05-20 10:57:12 -0400 (Sun, 20 May 2007) | 2 lines
r17 | damowe | 2007-05-19 22:22:24 -0400 (Sat, 19 May 2007) | 5 lines
r16 | damowe | 2007-05-18 21:41:36 -0400 (Fri, 18 May 2007) | 2 lines
r15 | damowe | 2007-05-14 23:02:09 -0400 (Mon, 14 May 2007) | 3 lines
r14 | damowe | 2007-05-13 12:03:47 -0400 (Sun, 13 May 2007) | 2 lines
r13 | damowe | 2007-05-13 01:01:13 -0400 (Sun, 13 May 2007) | 2 lines
r12 | damowe | 2007-05-12 22:48:18 -0400 (Sat, 12 May 2007) | 2 lines
r11 | damowe | 2007-05-12 22:41:14 -0400 (Sat, 12 May 2007) | 3 lines
r10 | damowe | 2007-05-07 08:57:33 -0400 (Mon, 07 May 2007) | 2 lines
r9 | damowe | 2007-05-03 08:37:04 -0400 (Thu, 03 May 2007) | 3 lines
r8 | damowe | 2007-05-02 20:50:25 -0400 (Wed, 02 May 2007) | 3 lines
r7 | damowe | 2007-05-01 17:43:00 -0400 (Tue, 01 May 2007) | 2 lines
r6 | damowe | 2007-05-01 09:31:08 -0400 (Tue, 01 May 2007) | 2 lines
r5 | damowe | 2007-05-01 09:24:07 -0400 (Tue, 01 May 2007) | 1 line
r4 | damowe | 2007-05-01 09:08:02 -0400 (Tue, 01 May 2007) | 2 lines
r3 | damowe | 2007-05-01 09:05:41 -0400 (Tue, 01 May 2007) | 2 lines
r2 | damowe | 2007-05-01 09:04:51 -0400 (Tue, 01 May 2007) | 2 lines
r1 | damowe | 2007-05-01 09:04:22 -0400 (Tue, 01 May 2007) | 2 lines

Both projects requires effort and research, and both project are not simple ones to handle, since they are written in C, a language difficult to learn and handle… I hope that I can continue the foss development that I’ve started, but seems that I have some health problems now :(

© dmw for coder . cl, 2010. | Permalink | No comment | Add to del.icio.us
Post tags:

Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)