MIDRANGE dot COM Mailing List Archive



Home » LINUX5250 » February 2005

RE: win32 update



fixed

On Fri, 25 Feb 2005, Ruel, Marc-Antoine wrote:

It seems that Jay 'Eraserhead' Felice <jfelice@xxxxxxxxxxxx> was the guy doing the python port. But seeing that is last check-in was in 2001, I would simply ignore the changes. The python code could be branched since it seems it will never be updated, we could:
- branch the current HEAD to b0-17-python and not use it anymore.
- update the b0-16 branch with the latest code of the current HEAD without the python code.
- promote the b0-16 branch to HEAD.
- go the 1.0 :) I hate 0.x version numbers :)

I vote for the first choice. I don't know any python, and if someone who does takes sufficient interest they can use the python branch as a base. In the mean time let's just move on without it.


Otherwise, we could simply add
#define g_malloc malloc
#define g_free free
in tn5250-private.h in the b0-16 branch just to have much less discrepancy between the branches. For instance, the only differences in macro.c between the branches are allocation functions. This doesn't need to be. I'm willing to do the g_ adding to the b0-16 branch. As you can see, I have some time to put on the project. But I'd prefer my first solution, i.e. create a new "stable" release soon and stop keeping unfinished (?) code indefinitely.

I think we should get rid of glib. Is the use of g_malloc and g_free really gaining us anything? Let's just get rid of the glib dependancy. Then I can build tn5250 current cvs on my old laptop.


Let's move on with a single branch (or in this case trunk) of just cvs HEAD. If the 16 branch has something we want to keep let's put it in cvs HEAD.

James Rich

It's not the software that's free; it's you.
        - billyskank on Groklaw





Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact