tnfox-announce Mailing List for FOX for Tn (Page 2)
Brought to you by:
ned14
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
(1) |
Mar
(5) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
2005 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Niall D. <s_s...@ne...> - 2003-11-10 21:48:13
|
Wow, can't believe it's really been three and a half months (15 weeks) since the last release! The reason has been python support which has proved extremely difficult & frustrating to complete. However, almost all of the horse work is done and once pyste in Boost.Python is fixed, the solution is complete (if a little untested currently). I estimate that around 750 hours has gone into this release which is not an insignificant portion of one's overall lifespan! However what TnFOX now has is a world-class set of python bindings which self- generate (so I can keep up with development drops of FOX easily) plus are extremely easy to extend and encompass any other code. The framework for this is totally generic - you just write some return policies once-off plus a few patches to work around unsupported areas, and the rest is taken care of for you. In combination with BPL, classes such as FXPython and FXPythonInterp allow you to easily embed python into your applications or indeed be embedded into a python application (or any mixture of the two, including running multiple interpreters and next release, threads). Another major area of update for TnFOX is security - TnFOX now boasts a generic strong encryption i/o device called FXSSLDevice capable of transparently encrypting any other i/o device, whether file or communication. For communication type devices, the full v2 & v3 auto- negotiated SSL protocol is used plus TLS. Public keys (RSA) and symmetric keys (Blowfish or AES) can be loaded and stored to disc or transmitted over a secure link. X509 PEM translation support is provided for interoperability. When combined with a secure C++ namespace plus a portable high-quality entropy gatherer (FX::Secure::Randomness), TnFOX makes adding strong encryption both easy and secure. The last major area of update is a generic meta-programming library (in FX::Generic) providing basic compile-time logic and introspection facilities, including typelists, type traits and custom user- definable traits. Addition of this unfortunately means support for MSVC6 and GCC v3.2 can no longer be provided. TnFOX has finally done away with makefiles and anything like them - it now uses scons which is a much superior replacement, not least because there is now a unified environment across all platforms which autodetects what's available and disables what's not needed. Lastly, several major bugs were fixed which actually caused the last release to terminate if an exception was thrown (whoops!). Since no one has downloaded TnFOX yet, I figured I didn't need to issue an update :) I expect that due to there being so much new code, there will be a long list of new bugs I haven't discovered yet. Indeed, some code remains untested and where this is so I have marked so in the documentation. Furthermore, things like threads in python are currently unsupported as they await generic functor & binding support (next release). Lastly, unfortunately just before release testing on RH9 turned up a namespace scoping bug in GCC v3.2 so there won't be any prebuilt binaries for RH9 till v0.5 (it couldn't handle the generic tools anyway). You can find TnFOX at http://www.nedprod.com/TnFOX/ plus its documentation at http://tnfox.sourceforge.net/TnFOX/html/ Cheers, Niall P.S.: Prebuilt binaries for win32 are on their way, they're still building ATM (the python bindings DLL takes four hours on release settings :( ) |
From: Niall D. <s_s...@ne...> - 2003-11-04 21:46:37
|
Got a GUI application running from Python now, which is where I wanted it. Found that automatic QValueList/STL to/from python list conversions weren't working, the solution to that is proving troublesome as I need a typeof() operator in MSVC - or some other mechanism of determining what the return type is of a certain method in an arbitrary class ie; struct X { int foo(); }; typedef ReturnExtract<X::foo>::value rettype; ... and rettype becomes "int". Obviously the code above doesn't work and the problem is in metaprogramming terms how to deduce a type and pass the result /up/ the inheritence chain. I have some ideas on this I'm about to research (any tips most welcome!). Then comes adding one more test of the generic tools, running both test suites on RH9 and Win2k as usual, and release! Cheers, Niall |
From: Niall D. <s_s...@ne...> - 2003-10-25 05:03:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body I went into "make a release" mode about a week ago (ie; beginning of testing), but new problems have arisen which have thus far prevented the test cycle. The previous one was virtual functions returning anything not by value throwing the infamous BPL "dangling reference" exception (fixed by me circumventing the check). The current one is binding argument translation during C++ invocation so I can release and restore the python GIL when executing C++ code. There are also, as always, a number of new bugs in pyste discovered by the arduous lengths TnFOX puts it through. Chances are v0.4 will be out early November. I had said by the end of October before, but this time I'll say that assuming no other problems that it'll be early November. OTOH, some feature creep has happened, the FXPython and FXPythonInterp classes weren't originally going to be in v0.4 but I wrote them while waiting the hour required for rebuilding the wrappings library. If it keeps on, I may add versioned .so support to scons, something scons users would be happy about. So ultimately, while the release is late, it's further along the overall roadmap. Which is a good thing (TM). Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP5n3CsEcvDLFGKbPEQLlygCfWR4y6mckXWJXOdjEsHQX50+wDTIAoPvq konY7jqJqqK9jbkyjBoeAq4U =HYkw -----END PGP SIGNATURE----- |
From: Niall D. <s_s...@ne...> - 2003-09-06 22:41:13
|
Just a little note on what's been happening. Basically, I've been adding two things: (i) strong encryption and (ii) python bindings using boost.python. The former has been VERY slow moving because there's virtually no docs and the OpenSSL library often works in an undocumented fashion :( The latter has pushed boost.python into some new areas it hasn't travelled before. Pyste, the wrappings generator, has been substantially upgraded from my efforts by Nicodemus, its author. The most recent CVS hopefully this time will actually work! But again, it's been very slow moving especially where I don't know if it's my code or boost.python (which also lacks documentation). However, the good news is that strong encryption support was finished last night, so that's plank 1 of v0.4 done. Now follows the python bindings which more than anything take ages to compile :( And then, we'll be back onto the Todo file contents! Estimated time for release? Ooo, I don't want to even try. Too many variables. As soon as I can make it! Cheers, Niall |
From: Niall D. <s_s...@ne...> - 2003-07-28 00:58:22
|
http://www.nedprod.com/TnFOX/ http://sourceforge.net/projects/tnfox/ Out of interest, the TnFOX extensions now occupy 15,668 lines which in two months isn't bad! I've concentrated on the i/o classes mostly this time, especially IPC-capable i/o classes. We now have a named pipe class (FXPipe) which offers the best available IPC speed on either Windows or POSIX - however there's also a local process pipe class (FXLocalPipe) if you wish to connect two threads together. For connecting processes running on different machines across the internet there is an IPv4 and IPv6 capable socket class (FXBlkSocket) with an IP address container class (FXHostAddress, which is Qt compatible). File i/o performance has also been substantially improved (indeed testing here shows a 3x performance increase) if you substitute a FXMemMap for a FXFile which transparently lets you map sections of a file into memory where naturally they can be accessed much faster and indeed managed by the host OS for you. The traditional problems with memory mapped sections have been abstracted away for you so you can treat a FXMemMap exactly like a FXFile. Furthermore as the name implies, FXMemMap can also provide shared memory between processes. Small QTL enhancements have been made with a QSortedList (something Qt doesn't have but it seems a logical extension) and the last major new feature is thread-safe reference counting classes. They are intended for use with a filing system type structure with individual node locking yet with correct lock transference semantics to avoid deadlocks. Lastly a large number of bugs have been fixed as the new tests I've added to the test suite are much more demanding. v0.4 is already in the works, for this I intend to add python bindings for all TnFOX extensions so you can use TnFOX directly from python! Cheers, Niall |
From: Niall D. <s_s...@ne...> - 2003-07-12 21:05:43
|
There are too many new features to write about, so here's the change log: v0.2 12th July 2003: -=-=-=-=-=-=-=-=-=-= B Fixed bug where copy to clipboard in error reporting box wasn't working on X11 B Fixed bug where FXProcess' destructor was not destructing static inits B Fixed bug where FXThread was not calling primary thread registered cleanup calls + Added string literal extraction to CppMunge.py & generation of translation file * Merged fox v1.1.29 + QDict, QDictIterator, QIntDict, QIntDictIterator added + Altered xincs.h to use 64 bit file addressing on both Unix & Windows + as many API's as I could find now use FXfval to indicate file size and position + Added FXIODevice + Added FXFile * Revamped FXStream: + Now uses an FXIODevice for i/o + Added much more error detection + Carefully changed to maintain backwards API compatibility * Altered FXFileStream to thunk to FXStream + FXFile combination + Added QMemArray<> and QByteArray + Added FXBuffer * Altered FXMemoryStream to thunk to FXStream + FXBuffer combination * Altered fxgifio.cpp, fxjpegio.cpp, fxpngio.cpp, fxrgbio.cpp, fxtifio.cpp & fxxpmio.cpp to be compatible with new 64-bit i/o structure + Added utext() and wtext() to FXString for eventual unicode transition. + Added FXGZipDevice, removed FXGzStream + Added FXStream overloads for all the QTL thunks, FXException, FXBuffer. * Merged fox v1.1.30 + Added FXMemDbg, plus added it to all my source files. + Added generic FXStream overload for all FXIODevice's + Added stdio() method to FXFile (really needs FXPipe) + Added transaction rollback support (FXRollback*) + Implemented FXTrans plus added FXTransString + Moved to new TnFOX MSVC project, changed file extensions to .cxx, installed custom build configuration to have CppMunge.py process all C++ source before compilation. + Added dynamically loaded library support to FXProcess and FXTrans + Generated MSVC7.1 project files for all parts + Added -sysinfo on the command-line + Added FXProcess::mappedFiles() which now means FXTrans knows where to find its translation files + Added automatic GZip decompression and compression support to FXTrans + Added delayed DLL loading on Win32 for mostly unused DLL's + Added StripSymbols to generate .dbg files for MSVC release builds + Merged fox v1.1.31 Indeed there is so much it's hard to test it all adequately. My apologies if you find things don't work as they should - I did put in a week finding and fixing bugs, but the spider-sense tells me it isn't adequate - however, you can be consoled that the IPC stuff will seriously hammer all this code so once that's tested and working, so is everything added this release. What's up for next release? It's basically more merging in of Tornado code - things like FXPipe, FXBlkSocket, FXMemMap along with some originally QTL extensions like an always sorted list, thread-safe reference counting template classes, primary button support (this is an idea direct from Tornado actually and has no parallel in existing mainstream GUI's) plus tidying up odds and ends. After that comes extending Python/FOX bindings for the extra TnFOX functionality, extra mouse cursor support (colour!), typelist facilities and lastly the IPC classes out of Tornado. I'd imagine the final version before I port Tornado over to TnFOX will be v0.5 (estimated completion is for end of August) so you have three more releases pending before then! Enjoy! Cheers, Niall |