-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is just a test message activating the new gmane and mail-archive
searchable archives of tnfox-discussion.
-BEGIN PGP SIGNATURE-
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2
iQA/AwUBQP7hV8EcvDLFGKbPEQL/pwCdF2G5gPGsvaV8WCF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1 Dec 2004 at 17:08, Dimitris Servis wrote:
> I vote for the CVS and I totally agree for anyone to use whatever I
> have ever submitted. I must say here that Niall did not do just some
> small extensions, but opened the TnFox CVS some time ago (13/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2 Dec 2004 at 1:26, Lothar Scholz wrote:
> ND> BTW, go SVN rather than CVS for any new project. SVN is now very
> ND> stable indeed.
>
> Does sourceforge already offer a public SVN server ?
It will next year. I'm using berlios.de right now.
> ND
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2 Dec 2004 at 16:22, Lothar Scholz wrote:
> Okay i will see how the exception fits into my Eiffel binding and if i
> like your programming style there (using exceptions as exceptions not
> as an alternate control flow).
Exceptions are only ever th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7 Dec 2004 at 11:13, Aris Basic wrote:
> when do you expect to have that version out ?
It's unfortunately looking unlikely before the new year. It's simply
a question of time to patch in the latest FOX development and run
everything through the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7 Dec 2004 at 22:49, Aris Basic wrote:
> here is the error im getting when trying to compile tnFox trunk on my
> linux amd64 note also that i uncommented #define for LOCK and UNLOCK
> on begining of FXThread.cxx
That's old dead code. I've just rem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8 Dec 2004 at 7:02, Aris Basic wrote:
> btw is there a support for amd64 ? (im getting some unsuported
> architecture msg from FXThread.cxx.
It's probable that GCC for AMD64 doesn't define __i386__ so
FXThread.cxx doesn't know what to do.
Please
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8 Dec 2004 at 9:36, Aris Basic wrote:
> Ok here it is
Thanks for that. SVN has a modified FXThread.cxx which should in
theory compile and run happily on 64 bit x86.
> BTW if you need access to this amchine i can probably give you access.
Probab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9 Dec 2004 at 12:04, Aris Basic wrote:
> when trying to build tests im getting eror unknown key PYTHON_INCLUDES
> is that scons, tnfox build scripts or pythons problem ?
If you read the docs it will tell you what environment variables need
to be
On 5 Jan 2005 at 18:00, [EMAIL PROTECTED] wrote:
> I found the scrollbar ranges to be a rather awkward limitation for an
> application I was working on because the fox tools throw away half the
> number range... and so are limited to 31 bit range in the default
> FXScrollbar FXint range of fox-1.
On 7 Jan 2005 at 18:28, [EMAIL PROTECTED] wrote:
> > The OpenSSL library provides a good bignum implementation. However,
> > I think the key here is to use templates - then you can easily and
> > transparently extend the paradigm with no source alteration.
>
> It doesn't have to be too fancy to d
On 9 Jan 2005 at 11:30, [EMAIL PROTECTED] wrote:
> >> I could send the mods I made to 1.0.30 that were necessary to
> >> create the 64 bit int version of FXScrollArea, FXScrollbar and
> >> FXTable. The mods were very small ... just to the parameters pos,
> >> range and dragpoint.
> >
> > That wo
On 9 Jan 2005 at 15:24, [EMAIL PROTECTED] wrote:
> Most of my struggle was due to the difficulty of getting tools to
> ignore
> my gcc original in /usr/bin and use the gcc 4.0 from a local directory
> that with the -fvisibility capability. I'd guess others will
> struggle with this, wanting
On 9 Jan 2005 at 20:56, [EMAIL PROTECTED] wrote:
> > If you hacked PYTHON_INCLUDE in for the main library build, did it
> > compile and work?
> >
> I don't recall having to make any changes to get the tnfox library to
> build, only for the TestSuite PYTHON_INCLUDE.
>
> The tnfox libraries built o
On 10 Jan 2005 at 21:27, [EMAIL PROTECTED] wrote:
> > BTW, have you tried the v0.80 stock release rather than the SVN
> > version? You'll still need to fix PYTHON_INCLUDE but everything else
> > should work much better.
>
> I tried to build the 0.80 version several months ago on a work
> computer
I'm aiming to release v0.85 of TnFOX by next Sunday but I shall be
away for the next few days. TnFOX in SVN is currently passing all its
tests on Windows, Linux and FreeBSD apart from the python related
ones. I am testing against the following:
1. Microsoft Windows 2000 SP3 with MSVC7.1 (Visual
I've just realised that I inadvertently broke shared memory on Linux
late in the release cycle when fixing it being broken on FreeBSD.
There's a fix right now in SVN, if people want new Linux binaries
enough I'll generate them otherwise I'll leave things as they are.
Sorry about that.
Cheers,
Homepage: http://www.nedprod.com/TnFOX/
Docs: http://tnfox.sourceforge.net/TnFOX/html/
SVN: http://developer.berlios.de/svn/?group_id=2262
I've just got the first build of Win64 TnFOX (and indeed Tn) running
smoothly. You can get it from SVN above and any feedback most
appreciated.
I intend to
On 1 Jun 2005 at 9:58, Andrew McDonald wrote:
> The first file, tnfox_python_test.PNG, is the result of simply
> starting and stopping the script. Stopping the script using Alt-C,
> since the windows position is such that the top of the window is not
> visible.
Yeah that happens here too. I keep
On 2 Jun 2005 at 9:10, Andrew McDonald wrote:
> > You also didn't say what version of TnFOX you were using. I haven't
> > tested the python bindings since version 0.85.
>
> version 0.85
Cool. It's likely I broke something in the v0.86 snapshots.
> > If the AllFromHeader() issue were fixed, ther
On 6 Jun 2005 at 7:57, Andrew McDonald wrote:
> This weekend I noticed that gcc support was for 3.3! I'm using 3.4.2
> and am now deliberating what to do next. Is there something broken
> with 3.4.x? Somewhere I remember hearing about 3.4 not being so
> popular
It's more that they completely
On 7 Jun 2005 at 8:14, Andrew McDonald wrote:
>> Are
>> you going to attempt to use TnFOX with mingw? ))
>
> My alternatives are mingw, and bcc 5.5 and I've just downloaded the
> Visual C++ Toolkit.
There's only build support included for ICC and MSVC on Windows, and
GCC and ICC on POSIX. A lot
I have the python bindings now complete and it's running all the old
tests
correctly. Tomorrow I'll test some examples from FXPy and fix any
remaining problems such as the old dangling FXWindow children
problem.
If anyone would like to try the new complete bindings, go to SVN. You
can
get updat
As above is now in SVN. There is also a new example ported from FXPy,
the imageviewer example which mostly runs (though it doesn't shut
down properly). Thus, as you might be guessing, while the bindings
are now full & complete there still remains a number of bugs and
issues.
I have run out of
As of revision 457 in SVN, TnFOX has renamed all Qt-compatible
classes from a FX prefix to a Q prefix. This has been done to avoid
name clashes with FOX v1.6 when it is merged.
Needless to say, this will break all existing code. You may wish to
bear this in mind when using SVN - update only to
On 15 Aug 2005 at 8:53, Brian Olsen wrote:
> I was interested in using some of TnFox's services to build a server.
> The services I wanted were:
>
> QBlkSocket
> FXProcess
> FXSettings
> QThread
> FXRex
> etc.
>
> Unfortunately because of the monolithic library I was forced to pull
> in all sort
On 16 Aug 2005 at 11:21, Brian Olsen wrote:
> I'll grab the subversion archive and give it a look see.
>
> Inside FXProcess & QBlkSocket I found direct calls to FXApp in case of
> failure conditions. It would make sense to rip out these static calls
> and replace them with some sort of functor to
As of revision 550 in SVN, you can now build just the TnFOX
extensions with almost no FOX code ie; no GUI code. This is intended
for statically linking the Tn kernel which must run as a daemon and
would have security issues if it used TnFOX as a DLL, but should be
useful to others who simply wa
On 1 Nov 2005 at 21:11, [EMAIL PROTECTED] wrote:
> Hello Niall,
> I recently got a quad opteron system and was interested in testing some of
> your code. I'm compiling with the gcc 4.0.1 and in fedora 4 installation.
> I pulled down the tnfox trunk from svn a couple of days ago, modified
> the
On 2 Nov 2005 at 8:03, [EMAIL PROTECTED] wrote:
> The compiler is just complaining about the lack of a declaration of
> 'type'. Where are you assuming it is declared?
>
> template struct BindImpl<-1, isUnsignedInt, const char *>
> { // A string literal. Convert to FXString and pass
>
On 2 Nov 2005 at 20:43, [EMAIL PROTECTED] wrote:
> The FXString part was ok, although it suggested FX::FXString, and it also
> seems to want &l instead of &v there.
Yeah, correct.
Does this mean that everything is working perfectly now? I remember
you were looking for larger scrollbar ranges an
On 3 Nov 2005 at 19:55, [EMAIL PROTECTED] wrote:
> TestCursor probably works ok, but I'd need to look at the source code to
> see what was the intent with the hour glasses and if one was not supposed
> to have a percent time associated with it.
That's correct behaviour.
> ---
> T
On 25 Feb 2006 at 10:10, The Devils Jester wrote:
> My child app has a list of thousands of tasks it must perform, after each
> task it needs to send a message to the parent to ask permission to do the
> next task (or possibly skip ahead, or repeat a task).
A simple synchronous IPC msg would be i
On 25 Feb 2006 at 9:34, The Devils Jester wrote:
> TnFOX SVN fails with:
>
>
> #
> In file included from include/FXProcess.h:27,
> from include/QThread.h:25,
> from src/QThread.cxx:23:
> include/FXGenericTools.h:431: warning:
On 25 Feb 2006 at 15:24, [EMAIL PROTECTED] wrote:
> >> 3. The error line below had to be commented out.
> >> src/FXApp.cpp: In function 'int FX::xerrorhandler(Display*,
> >> XErrorEvent*)':
> >> src/FXApp.cpp:1147: error: 'FXThread' has not been declared
> >> src/FXApp.cpp:1147: error: 'current' w
On 25 Feb 2006 at 21:06, The Devils Jester wrote:
> I have a question about the size of TnFOX vs the size of 'regular' FOX. I
> have a regular fox lib thats 3.75 MB compiled (unstripped, release) with all
> the goodies I wanted. A regular compile of TnFOX is 7.11 MB (unstripped,
> release).
>
>
On 25 Feb 2006 at 19:55, The Devils Jester wrote:
> Using 4.0.x would be a last resort, not because I dislike it, but because
> many of my testers do not have linux, they use Knoppix and friends which do
> not come with the newer dependancies that an app compiled with 4.0.x would
> require. Same
On 25 Feb 2006 at 22:33, The Devils Jester wrote:
> The first set of errors was about FOX_BIGENDIAN not being declared. I put a
> -DFOX_BIGENDIAN in my compile script and now that doesnt yell at me. (I
> dont know if I _should_ be declaring that though...)
If you're using scons, the SConstruct
On 26 Feb 2006 at 9:43, The Devils Jester wrote:
> I only care about turning off the features that I dont use that would have
> large impact on the lib size. 7.5ish MB compared to 3.5ish MB is a huge
> difference. Know of any specific features that add alot of space?
Yes, GCC 3.3's template par
On 26 Feb 2006 at 9:53, The Devils Jester wrote:
> I dont use scons or make or anything of the sort, its always been too
> complicated and too many files just to compile an app. I use a simple .sh
> script which calls g++ with my options (and a .bat which calls borland on
> win), it may not be as
On 26 Feb 2006 at 12:12, The Devils Jester wrote:
> I actually did use 3.4 for the compile of TnFOX (3.3 wouldnt work), and its
> still a pretty large lib compared to FOX. Stripping can probably take a
> small chunk away but not enough to make a large difference.
>
> What is all being compiled i
On 26 Feb 2006 at 12:16, The Devils Jester wrote:
> I will attempt to make a small test app using the same functions that I am
> using, see if it compiles (if not, I will mail the source). I can also
> attempt to compile the test suite to see if its the compiler or not.
You can try the new set o
On 26 Feb 2006 at 17:37, The Devils Jester wrote:
> I dont see a foxtests folder, I will look at the one in TestSUite and see I
> can make heads or tails of it, this is how I normally compile my app:
Sorry, got bogged down with fixing a separate issue. It's in SVN now.
> g++ main.cpp -o myapp -L
On 26 Feb 2006 at 11:39, [EMAIL PROTECTED] wrote:
> >> 1. had to specify FX::strdup(tmp) to keep the compiler from aborting
> >> with
> >> a conflict error from one included by string.h in gltest.cpp
> >
> > Should be fixed in SVN. Haven't tested it though.
>
> This one not fixed. Several strdup
On 26 Feb 2006 at 17:57, The Devils Jester wrote:
> When looking on the TnFOXDocs.h I noticed that with the compatiblity layer
> turned off, that it says these are not compiled:
>
> Not compiled:
> \li FX::FXDirBox
> \li FX::FXDirDialog
> \li FX::FXDirList
> \li FX::FXDirSelec
On 26 Feb 2006 at 21:11, [EMAIL PROTECTED] wrote:
> I see now that I did have the Fox compatibility definition in the
> SConstruct file for the fox_tests that I sent you, and so that was the
> problem with image.cpp that I sent. But I see that gltest.cpp still fails
> in both cases, as well as me
On 5 May 2006 at 10:36, David De Weerdt wrote:
> > Ok, found the problem,
> >
> > apparantly CopyCursor is a macro that is defined by winuser.h, so
> > including winuser.h will result in this compilation problem. Renaming
> > all references to CopyCursor from CopyCursor to TnCopyCursor for
> > ex
On 5 May 2006 at 10:36, David De Weerdt wrote:
> > apparantly CopyCursor is a macro that is defined by winuser.h, so
> > including winuser.h will result in this compilation problem. Renaming
> > all references to CopyCursor from CopyCursor to TnCopyCursor for
> > example, resolved the problem.
I
On 8 May 2006 at 11:15, David De Weerdt wrote:
> I'm wondering how I can accomplish the following:
> I want to use COM to start the GUI from a client process. So I have a
> COM-server process running that has a launch command which is called
> by the COM-client.
>
> this launch command on the ser
On 12 Sep 2008 at 0:15, Ck wrote:
> But program's API is not threadsafe. And I must call API functions from
> the dll thread.
>
> In dll many threads with calculations and some GUI windows.
>
> Worker thread must call API functions (but it can't).
> I decided to send events/messages to main dll
On 15 Sep 2008 at 15:44, Ck wrote:
> > If your main thread is a MFC thread, then you'll need to pump the FOX
> > message dispatch system manually from within the MFC message loop.
> >
> How to do this?
> Can you give an example?
Look at the source for TnFXApp::run() and FXApp::run(). Basicall
On 22 Sep 2008 at 11:10, [EMAIL PROTECTED]
wrote:
> The attached message was received as a bounce, but either the bounce
> format was not recognized, or no member addresses could be extracted
> from it. This mailing list has been configured to send all
> unrecognized bounce messages to the list
On 26 Sep 2008 at 2:24, Ck wrote:
> I found problem: Previously I compiled dll project with FOX_BIGENDIAN
> and now (after I looked at scons build log) I compile with FOX_BIGENDIAN
> = 0.
> It works.
Well scons does the right thing here except on Mac OS X where for
some odd reason Apple have m
On 28 Sep 2008 at 4:52, CK wrote:
> > Actually, you /could/ have multiple threads receiving too so long as only
> > one
> is doing it at any one time.
>
> So I can use many threads with QPipe to send messages without any extra
> synchronisation?
> In doc:
>Reads and writes are threadsafe, bu
On 1 Oct 2008 at 5:17, Ck wrote:
> I do the following:
>
> Server side:
>
> > FXERRHM(pipe = new QPipe("pipe"));
> > pipe->create(IO_ReadWrite);
> > FXERRHM(p = new ServerConnector(this, *pipe));
>
> Client1:
> > FXERRHM(pipe1 = new QPipe("pipe"));
> > pipe1->open(IO_ReadWrite);
> > FXERRHM(
On 6 Oct 2008 at 17:37, Ck wrote:
My apologies for the very late reply - my entire email processing
system died for most of last week and it took the past weekend to
extract my email.
> One more question.
>
> Can't understand how to get ask from thread via IPC..
>
> For example:
> thread_1 re
On 23 Nov 2010 at 18:39, Paul Thomas wrote:
> Not sure if this list is alive or defunct, but anyway trying to resolve
> build issue for txFox 0.89.
Oh TnFOX is alive and well in the sense that it is maintained, but
there have been no new features in a long while. Sad fact is that
other work pay
Added a note in Readme.txt about this GIT weirdness at
https://github.com/ned14/tnfox/commit/62ac35c6eda8f3272c70b55e7c38d696
f4989b7a.
Niall
On 24 Nov 2010 at 11:06, Paul Thomas , General discuss wrote:
> On 23 Nov 2010 at 18:39, Paul Thomas wrote:
>
> > Not sure if this list is alive or defu
On 28 Nov 2010 at 17:52, Paul Thomas wrote:
> In file included from src/TnFXApp.cxx:26:
> include/qptrlist.h:60: error: redefinition of default argument for
> 'class allocator'
> include/fxdefs.h:982: note: original definition appeared here
> include/qptrlist.h:61: error: redefinition of default a
Hi,
Sorry it's taken so long to get back to you. It turns out that LOTS
of stuff had become broken and last night I pushed a fairly hefty
update of source changes to the GIT repos.
It now compiles cleanly on VS2010 and GCC v4.3. However right now it
segfaults on process init on both Linux and
I am glad to report that after a week of pulling my hair out over one
of the hardest debugging sessions I think I have ever had in my life
(I think I must be getting old), TnFOX is now passing all but one of
its testsuite on Linux and everything on Windows even under VS2010
with full rvalue ref
On 11 Dec 2010 at 21:33, Paul Thomas wrote:
> Having said that, a challenge is set upon me; For a number of advanced
> features of C++ and now C++0x have been made available in TnFox, but my
> understanding of these features is very limited. Help is available, I
> recognize that I should probably
62 matches
Mail list logo
