× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




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.

So, your suggestion is to throw away Python support altogether? That's actually just fine with me, I've never used it, so not having it won't bother me at all!


However, there have been several requests for it, so I think there are probably people who are interested in seeing it happen. Unfortunately, none of them have picked up the reins and done the job.

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 :)

There are some other minor changes (aside from the Python and GLIB support) in the 0.17 branch. I don't really want to throw them away. If nobody is going to develop the Python code, I could see removing just that code from HEAD and making that into our branch for development.



Three is a limit of keeping 2 branches over 3 years if you want active developpement...

Don't blame the messenger... Mike Madore and Jay Felice have done the majority of development on this project. They're the ones who decided what goes in which branch.


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.

I think we should either use GLIB or not use GLIB. I don't think using #define hacks to work around it is a good solution. If we're going to use GLIB as Mike wanted to way back when, then let's actually use it instead of using #define trickery.



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.

Like I said, I'd be quite happy to throw away the Python code -- it doesn't do me any good, I don't know any Python programming at all. I'd be completely happy to get rid of it.


S/Lang is another thing that I think is just bit-rot waiting to happen. Does anyone use S/Lang support? Does anyone even care about it? When you guys are making all of these changes to the terminal objects, are you also changing slangterm?

What about the GTK terminal?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.