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
It's not the software that's free; it's you.
- billyskank on Groklaw