Nabble - TnFox

Re: IPC message sending problems

2008-10-13T04:04:26Z

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 requests from thread_2 some actions and wants to get the
> result of this actions.
>
> void thread_1::req()
> {
> Msg msg(bla-bla);
> sendMsg(msg);
>
> // here i want to use result from thread_2.
> }
>
> ..
> thread_2::msgReceived(FXIPCMsg *rawmsg)
> {
> Msg *i = (Msg*)rawmsg;
>
> FXString result = someAction(i->data);
> }
>
> How to return result to thread_1?

You need to define an Ack message for the message which will
transport your result back to the sender. Your sender can either wait
for the reply or move on with other processing, polling for the reply
or indeed having a separate handler for the reply whenever it
arrives.

If you have an Ack message defined, TnFOX will automatically collect
any C++ exceptions thrown by the remote side and return them to the
message sender. I vaguely remember a system in place for timeouts as
well, so if a message does not return in time you get notified and
the operation is cancelled.

If you check the TestIPC program for the "file access over IPC"
mechanism then this gives a good demonstration of how to efficiently
use Ack messages to maximise throughput and deal correctly with error
situations.

HTH,
Niall

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: IPC message sending problems

2008-10-06T03:37:21Z

One more question.

Can't understand how to get ask from thread via IPC..

For example:
thread_1 requests from thread_2 some actions and wants to get the
result of this actions.

void thread_1::req()
{
Msg msg(bla-bla);
sendMsg(msg);

// here i want to use result from thread_2.
}

..
thread_2::msgReceived(FXIPCMsg *rawmsg)
{
Msg *i = (Msg*)rawmsg;

FXString result = someAction(i->data);
}

How to return result to thread_1?

Thanks.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: IPC message sending problems

2008-10-05T05:28:46Z

> If you are in the same process, just reuse the same QPipe instance
> between threads.

Ok! Thanks.

> Hope that helps,

Yes.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: IPC message sending problems

2008-10-04T08:53:39Z

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(wc = new ClientConnector(this, *pipe1));
> > wc->channel()->start(true);
>
> Client2:
> > FXERRHM(pipe2 = new QPipe("pipe"));
> > pipe2->open(IO_ReadWrite);
> > FXERRHM(wc2 = new ClientConnector(this, *pipe2));
>
> but Client2 wait something on pipe2->open(IO_ReadWrite);
>
> How to connect 2 or 3 clients to server via QPipe?
> Can you write simple example?

Oh I see what you mean. You want two clients connecting to one server
pipe.

No that isn't supported because its behaviour doesn't match between
Windows and POSIX. You can have one server QPipe and one client QPipe
and multiple threads can simultaneously use both pipe objects at the
same time.

More than two QPipe objects per pipe is not supported. This is
because Windows uses a IP socket style system of detaching pipe
instances from a listening pipe whereas Unix does not.

If you want one server interface and multiple clients, QBlkSocket is
the only thing which does this.

If you want to cheat, you could fetch the internal HANDLE, duplicate
it with cross-process inheritability and pass it to the other
process. I am not sure if just doing an ReadFile() on the same pipe
instance string works - I am afraid I do not have the internet
available to me right now so I cannot check.

If you are in the same process, just reuse the same QPipe instance
between threads.

Hope that helps,
Niall

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: IPC message sending problems

2008-09-30T22:17:30Z

Niall Douglas <s_sourceforge@...> writes:

>
>
> TnFOX scares away most programmers - a lot of CS
> courses use it as a teaching aid for advanced C++ techniques but no
> one that I know of uses it for actual application programming.
>

This scares me more than TnFox).
Do you use TnFox?

> No you need to create() the server end of the pipe and open() the
> client end of the pipe.

I do not understand..

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(wc = new ClientConnector(this, *pipe1));
> wc->channel()->start(true);

Client2:
> FXERRHM(pipe2 = new QPipe("pipe"));
> pipe2->open(IO_ReadWrite);
> FXERRHM(wc2 = new ClientConnector(this, *pipe2));

but Client2 wait something on pipe2->open(IO_ReadWrite);

How to connect 2 or 3 clients to server via QPipe?
Can you write simple example?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: IPC message sending problems

2008-09-29T09:59:05Z

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, but you should avoid more than
> two threads working with
> the same pipe (the same as more than two processes) because ...

Yes so long as you can guarantee that no two threads will be writing
simultaneously. You can either employ a mutex, a wait object or
simply structure your code appropriately. If the messages are small
then you shouldn't even need any extra synchronisation so long as the
receiver processes messages quickly.

> > By the way, what kind of application are you developing?
>
> I'm developing application for Stock market.
> I need to rewrite dll for application named Anvil.
> Old dll is singlethreaded and it can't work with big dataflow.
> I trying to implement multithreaded architecture.
>
> Already has passed a lot of time, and I still try to understand
> some components. I found your fox-toolkit fork near 2 years ago.
> Now I decided to use it in this project.
> Jeroen's fox-toolkit and your TnFox are very intresting thigs).
> But i never used TnFox before. Just a little fox-toolkit - hello-world
> application)).
> So sorry for stupid questions.

That's no problem. TnFOX scares away most programmers - a lot of CS
courses use it as a teaching aid for advanced C++ techniques but no
one that I know of uses it for actual application programming.

> Yet another couple of questions:
> How to use QPipe with more than one sender thread?
> On client side I tried to make the test:
>
> > FXERRHM(pipe1 = new QPipe("pipe"));
> > pipe1->open(IO_ReadWrite);
> > FXERRHM(wc = new ClientConnector(this, *pipe1));
> > wc->channel()->start(true);
> > ...
> > FXERRHM(pipe2 = new QPipe("pipe"));
> > pipe2->open(IO_ReadWrite);
> > FXERRHM(wc2 = new ClientConnector(this, *pipe2));
>
> but
> > pipe2->open(IO_ReadWrite);
>
> waiting something..
> I checked with debugger. It happen on this line in qpipe.cxx:
> > FXERRHWINFN(WaitNamedPipe(temp.buffer(), NMPWAIT_USE_DEFAULT_WAIT), readname);
>
> If I do like this:
>
> > FXERRHM(wc2 = new ClientConnector(this, *pipe1));
>
> everything goes fine and I can send messages via wc()->channel() and
> wc2->cannel(). But maybe this is not correct?

No you need to create() the server end of the pipe and open() the
client end of the pipe.

> How do you think maybe it is better to use event loops (FXEventLoop) for
> communicating threads.
> For async calls use postAsyncMessage (for example for sending data to GUI),
> and for sync calls use:
>
> RetType SomeObject::syncCall()
> {
> someThread->getEventLoop()->postAsyncMessage(bla-bla);
> waitReturnValue();
> return retVal;
> }
>
> void SomeObject::tryHandle(FXObject *sender, FXSelector sel, void *ptr)
> {
> if(sender == someThread && maybe_additional_condition){
> retVal = ptr;
> endWait();
> }
> ..
> }
>
> or something like this..
> But i prefer to use IPC - it is easier.

There's no synchronous call ability for async messages - it's a fire
& forget system. You can of course fire an async message back again
when done.

The IPC mechanism is much better designed for this sort of stuff -
but then the threaded windowing system was originally designed as a
standalone patch for FOX and so I kept it separate. Jeroen refused
the patch unfortunately and is proceeding his own direction. I'll try
merging his changes with mine when FOX v1.8 comes out.

> Is method with EventLoops faster? or IPC faster?
> In fact I planned to use EventLoops for async calls and IPC for sync calls...

IPC is definitely faster as it skips the windowing systems which is
slow.

> I found some (maybe) bugs...
> 1) Simple test:
> QFileInfo info;
>
> info.setFile("filename.suffix");
> fxmessage("1. Basename:%s suffix:%s\n", info.baseName().text(),
> info.extension().text());
>
> info.setFile("c:\\path\\filename.suffix");
> fxmessage("2. Basename:%s suffix:%s\n", info.baseName().text(),
> info.extension().text());
>
> info.setFile("/usr/local/filename.suffix");
> fxmessage("3. Basename:%s suffix:%s\n", info.baseName().text(),
> info.extension().text());
>
> info.setFile("f.s");
> fxmessage("4. Basename:%s suffix:%s\n", info.baseName().text(),
> info.extension().text());
>
> Output:
> 1. Basename:filenam suffix:suffix
> 2. Basename:filenam suffix:suffix
> 3. Basename:filenam suffix:suffix
> 4. Basename: suffix:s
>
> Something wrong here)

Oh yes. I'll tag that for doing something about it. Thanks.

> 2) In FXTable:
> The "down"-arrow is displayed if we call
> getColumnHeader()->setArrowDir(FXHeaderItem::ARROW_NONE).
> But it must be displayed if we call
> getColumnHeader()->setArrowDir(FXHeaderItem::ARROW_DOWN).

That's probably a bug in Jeroen's code, but I'll tag that too.

Thanks,
Niall

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: IPC message sending problems

2008-09-27T21:52:05Z

My mail server have problems.. I posted this answer from gmane.org.

> 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, but you should avoid more than
two threads working with
the same pipe (the same as more than two processes) because ...

> I'll be honest: there has been a long standing bug in QLocalPipe as mentioned
in Todo.txt which somehow causes it to fail when working under QSSLDevice. I
have never discovered why it fails ...

It is sad.. I'll try to use QPipe.

> Still, try a QBlkSocket just to make sure, you never know.
>

Hm. I have some technical problems with testing QBlkSocket.
Maybe I'll try it later.

> By the way, what kind of application are you developing?

I'm developing application for Stock market.
I need to rewrite dll for application named Anvil.
Old dll is singlethreaded and it can't work with big dataflow.
I trying to implement multithreaded architecture.

Already has passed a lot of time, and I still try to understand
some components. I found your fox-toolkit fork near 2 years ago.
Now I decided to use it in this project.
Jeroen's fox-toolkit and your TnFox are very intresting thigs).
But i never used TnFox before. Just a little fox-toolkit - hello-world
application)).
So sorry for stupid questions.

Yet another couple of questions:
How to use QPipe with more than one sender thread?
On client side I tried to make the test:

> FXERRHM(pipe1 = new QPipe("pipe"));
> pipe1->open(IO_ReadWrite);
> FXERRHM(wc = new ClientConnector(this, *pipe1));
> wc->channel()->start(true);
> ...
> FXERRHM(pipe2 = new QPipe("pipe"));
> pipe2->open(IO_ReadWrite);
> FXERRHM(wc2 = new ClientConnector(this, *pipe2));

but
> pipe2->open(IO_ReadWrite);

waiting something..
I checked with debugger. It happen on this line in qpipe.cxx:
> FXERRHWINFN(WaitNamedPipe(temp.buffer(), NMPWAIT_USE_DEFAULT_WAIT), readname);

If I do like this:

> FXERRHM(wc2 = new ClientConnector(this, *pipe1));

everything goes fine and I can send messages via wc()->channel() and
wc2->cannel(). But maybe this is not correct?

How do you think maybe it is better to use event loops (FXEventLoop) for
communicating threads.
For async calls use postAsyncMessage (for example for sending data to GUI),
and for sync calls use:

RetType SomeObject::syncCall()
{
someThread->getEventLoop()->postAsyncMessage(bla-bla);
waitReturnValue();
return retVal;
}

void SomeObject::tryHandle(FXObject *sender, FXSelector sel, void *ptr)
{
if(sender == someThread && maybe_additional_condition){
retVal = ptr;
endWait();
}
..
}

or something like this..
But i prefer to use IPC - it is easier.

Is method with EventLoops faster? or IPC faster?
In fact I planned to use EventLoops for async calls and IPC for sync calls...

I found some (maybe) bugs...
1) Simple test:
QFileInfo info;

info.setFile("filename.suffix");
fxmessage("1. Basename:%s suffix:%s\n", info.baseName().text(),
info.extension().text());

info.setFile("c:\\path\\filename.suffix");
fxmessage("2. Basename:%s suffix:%s\n", info.baseName().text(),
info.extension().text());

info.setFile("/usr/local/filename.suffix");
fxmessage("3. Basename:%s suffix:%s\n", info.baseName().text(),
info.extension().text());

info.setFile("f.s");
fxmessage("4. Basename:%s suffix:%s\n", info.baseName().text(),
info.extension().text());

Output:
1. Basename:filenam suffix:suffix
2. Basename:filenam suffix:suffix
3. Basename:filenam suffix:suffix
4. Basename: suffix:s

Something wrong here)

2) In FXTable:
The "down"-arrow is displayed if we call
getColumnHeader()->setArrowDir(FXHeaderItem::ARROW_NONE).
But it must be displayed if we call
getColumnHeader()->setArrowDir(FXHeaderItem::ARROW_DOWN).

Thank you.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: IPC message sending problems

2008-09-27T02:29:08Z

> 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, but you should avoid more than two
threads working with
the same pipe (the same as more than two processes) because ...

> I'll be honest: there has been a long standing bug in QLocalPipe as
> mentioned in Todo.txt which somehow causes it to fail when working
> under QSSLDevice. I have never discovered why it fails ...
It is sad.. I'll try to use QPipe.

> Still, try a QBlkSocket just to make sure, you never know.
>
Hm. I have some technical problems with testing QBlkSocket. Maybe I'll
try it later.

> By the way, what kind of application are you developing?
I'm developing application for Stock market.
I need to rewrite dll for application named Anvil.
Old dll is singlethreaded and it can't work with big dataflow.
I trying to implement multithreaded architecture.

Already has passed a lot of time, and I still try to understand some
components.
I found your fox-toolkit fork near 2 years ago. I now I decided to use
it in this project.
Jeroen's fox-toolkit and your TnFox are very intresting thigs)
But i never used TnFox before. Just a little fox-toolkit - hello-world
application)).
So sorry for stupid questions.

Yet another couple of questions:
How to use QPipe with more than one sender thread?
On client side I tried to make the test:

> FXERRHM(pipe1 = new QPipe("pipe"));
> pipe1->open(IO_ReadWrite);
> FXERRHM(wc = new ClientConnector(this, *pipe1));
> wc->channel()->start(true);
> ...
> FXERRHM(pipe2 = new QPipe("pipe"));
> pipe2->open(IO_ReadWrite);
> FXERRHM(wc2 = new ClientConnector(this, *pipe2));

but
> pipe2->open(IO_ReadWrite);
waiting something..
I checked with debugger. It happen on this line in qpipe.cxx:
> FXERRHWINFN(WaitNamedPipe(temp.buffer(), NMPWAIT_USE_DEFAULT_WAIT),
readname);

If I do like this:

> FXERRHM(wc2 = new ClientConnector(this, *pipe1));

everything goes fine and I can send messages via wc()->channel() and
wc2->cannel(). But maybe this is not correct?

How do you think maybe it is better to use event loops (FXEventLoop) for
communicating threads.
For async calls use postAsyncMessage (for example for sending data to
GUI), and for sync calls use:

RetType SomeObject::syncCall()
{
someThread->getEventLoop()->postAsyncMessage(bla-bla);
waitReturnValue();
return retVal;
}

void SomeObject::tryHandle(FXObject
<../../d5/d5a/class_f_x_1_1_f_x_object.html> *sender, FXSelector sel,
void *ptr)
{
if(sender == someThread && maybe_additional_condition){
retVal = ptr;
endWait();
}
..
}

or something like this..
But i prefer to use IPC - it is easier.

Is method with EventLoops faster? or IPC faster?
In fact I planned to use EventLoops for async calls and IPC for sync
calls...

I found some (maybe) bugs...
1) Simple test:
QFileInfo info;

info.setFile("filename.suffix");
fxmessage("1. Basename:%s suffix:%s\n", info.baseName().text(),
info.extension().text());

info.setFile("c:\\path\\filename.suffix");
fxmessage("2. Basename:%s suffix:%s\n", info.baseName().text(),
info.extension().text());

info.setFile("/usr/local/filename.suffix");
fxmessage("3. Basename:%s suffix:%s\n", info.baseName().text(),
info.extension().text());

info.setFile("f.s");
fxmessage("4. Basename:%s suffix:%s\n", info.baseName().text(),
info.extension().text());

Output:
1. Basename:filenam suffix:suffix
2. Basename:filenam suffix:suffix
3. Basename:filenam suffix:suffix
4. Basename: suffix:s

Something wrong here)

2) In FXTable:
The "down"-arrow is displayed if we call
getColumnHeader()->setArrowDir(FXHeaderItem::ARROW_NONE).
But it must be displayed if we call
getColumnHeader()->setArrowDir(FXHeaderItem::ARROW_DOWN).

Thank you.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: IPC message sending problems

2008-09-26T00:43:59Z

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 miscompiled python such that it sometimes
makes mistakes.

> I used QPipe for FXIPCChannel.
>
> As I understand, QPipe is not good choice for connecting more than 2
> threads...
> (I checked maxAtomicLength() - 4096).

There can only ever be one receiving thread but many sender threads.
This applies to QPipe, QLocalPipe or anything else.

Actually, you /could/ have multiple threads receiving too so long as
only one is doing it at any one time. I have a special case in Tn
where one thread receives one message and then hands off message
receiving to a child thread.

> QLocalPipe is better for me (for intra-process communications).
> I checked QLocalPipe code: CHUNKSIZE (64*1024). Maybe this will be
> enough for messages..
> I can use QLocalPipe with many threads, rigth?

The 4Kb limit for QPipe is a system imposed limit. In fact it varies
on different operating systems ... Apple & FreeBSD will automagically
extend the pipe buffer dynamically up to 16Kb, Windows will allocate
64Kb if you pass isDeepPipe=true to the QPipe constructor. Linux is
fixed at 4Kb no matter what.

> But I can't connect via QLocalPipe.
>
> Here how I do this:
>
> On server side:
> > FXERRHM(pipe = new QLocalPipe);
> > pipe->create(IO_ReadWrite);
> > FXERRHM(p = new ServerConnector(this, *pipe));
>
> On client side:
> > FXERRHM(pipe = new QLocalPipe(Global::pipe->clientEnd()));
> > pipe->open(IO_ReadWrite);
> > FXERRHM(wc = new ClientConnector(this, *pipe));
>
> This is not worked..
> If use QPipe in this way - It works.
>
> Can you tell me where my mistake?

I'll be honest: there has been a long standing bug in QLocalPipe as
mentioned in Todo.txt which somehow causes it to fail when working
under QSSLDevice. I have never discovered why it fails ... it has
always seemed to work under FXIPCChannel, indeed Tn uses it, so
obviously QSSLDevice sends some pattern of messages which makes it
trip over.

It is possible that by sheer chance your code happens to duplicate
this pattern and thus it fails. I can tell you that your code looks
absolutely fine and I can't see why it wouldn't work. As you said, if
it works via QPipe, it should work via QLocalPipe. Still, try a
QBlkSocket just to make sure, you never know.

> PS. BTW, Niall, in QLocalPipe documentation:
> > See QPipe for more information about how such objects work. One
> difference that there is no create(), instead there is an otherEnd()
> method which returns ...
> otherEnd() ?? The typing error seems to me here... And Should be
> clientEnd() instead otherEnd().

Yes this is definitely a typing error. I'll flag this for fixing next
time I am on the desktop computer.

Thanks for the typo report, and sorry that I am not more useful for
QLocalPipe. By the way, what kind of application are you developing?

Thanks,
Niall

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: IPC message sending problems

2008-09-25T21:20:39Z

Hello.
Thanks for you answers, Niall.

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.

I used QPipe for FXIPCChannel.

As I understand, QPipe is not good choice for connecting more than 2
threads...
(I checked maxAtomicLength() - 4096).

QLocalPipe is better for me (for intra-process communications).
I checked QLocalPipe code: CHUNKSIZE (64*1024). Maybe this will be
enough for messages..
I can use QLocalPipe with many threads, rigth?

But I can't connect via QLocalPipe.

Here how I do this:

On server side:
> FXERRHM(pipe = new QLocalPipe);
> pipe->create(IO_ReadWrite);
> FXERRHM(p = new ServerConnector(this, *pipe));

On client side:
> FXERRHM(pipe = new QLocalPipe(Global::pipe->clientEnd()));
> pipe->open(IO_ReadWrite);
> FXERRHM(wc = new ClientConnector(this, *pipe));

This is not worked..
If use QPipe in this way - It works.

Can you tell me where my mistake?

PS. BTW, Niall, in QLocalPipe documentation:
> See QPipe for more information about how such objects work. One
difference that there is no create(), instead there is an otherEnd()
method which returns ...
otherEnd() ?? The typing error seems to me here... And Should be
clientEnd() instead otherEnd().

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: IPC message sending problems

2008-09-25T12:24:03Z

Re: IPC message sending problems

2008-09-23T00:37:32Z

>> 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 administrator(s).
>>
>
> Looks like you had a problem reaching the list.
>
>
Sorry, i wrote wrong email - tnfox-discussion-bounces@...
> Are you sure you are defining & registering the message chunk
> correctly as per the documentation and source code examples?
>
>
I looked at the docs & TestIPC example and I do the only the following
steps for defining & registering IPC messages:

> typedef FX::FXIPCMsgChunkCodeAlloc<0x80, true> MsgChunkBegin;

> struct TestMarketMsg_Error : public FX::FXIPCMsg
> {
> typedef FX::FXIPCMsgChunkCodeAlloc<MsgChunkBegin::code, false> id;
> typedef FX::FXIPCMsgRegister<id, TestMarketMsg_Error> regtype;
> int code;
> TestMarketMsg_Error() : FX::FXIPCMsg(id::code), code(0) { }
> TestMarketMsg_Error(int c): FX::FXIPCMsg(id::code), code(c){}
> void endianise(FX::FXStream &ds) const { ds << code; }
> void deendianise(FX::FXStream &ds) { ds >> code; }
> };
>
//--------------------------------------------------------------------------------

> struct TestMarketMsg_Action : public FX::FXIPCMsg
> {
> typedef
FX::FXIPCMsgChunkCodeAlloc<TestMarketMsg_Error::id::nextcode, false> id;
> typedef FX::FXIPCMsgRegister<id, TestMarketMsg_Action> regtype;
> int code;
> TestMarketMsg_Action(int c=0)
> : FX::FXIPCMsg(id::code), code(c){ }
> void endianise(FX::FXStream &ds) const { ds << code; }
> void deendianise(FX::FXStream &ds) { ds >> code; }
> };
>
//--------------------------------------------------------------------------------
>
> typedef FX::FXIPCMsgChunk<FX::Generic::TL::create<
> TestMarketMsg_Error::regtype,
> TestMarketMsg_Action::regtype
> >::value> MsgChunk;

and in class:
> void IPCController::channelInstall()
> {
> FXERRHM(m_chunk = new MsgChunk(&m_channel->registry()));
> ...

after
> TestMarketMsg_Action act(1);
> wc->channel()->sendMsg(act);
I have the exception.

> Your error above suggests a serialisation/deserialisation mismatch in
> the message sent before that message - the exception you got is a
> trap for that problem. There is some #ifdef DEBUG code in the
> FXIPCChannel source which may help and there are even more debug
> outputs which can be commented into working too. One of them even
> dumps a byte output of bytes received & sent so you should definitely
> find where the problem is.
>
>
Ok, I'll try to use this.

Thanks for your answers, Niall.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: Uncaught bounce notification

2008-09-22T13:43:33Z

On 22 Sep 2008 at 11:10, sitelist-bounces@...
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 administrator(s).

Looks like you had a problem reaching the list.

> I decided to use IPC framework for threads communication.
>
> After sending message from thread to main thread:
>
> > FXERRHM(wc = new WindowConnector(this, *pipe));
> > wc->channel()->start(true);
> > ...
> > TestMarketMsg_Action act(1);
> > wc->channel()->sendMsg(act);
>
>
> the exception is generated:
>
> > Thread 5808 sending msg 0x83 (struct TestMarketMsg_Action), len=34
> bytes > FXException id 1 created, 'Maximum message size exceeded
> (570425344
> with limit of 65536)'
> > at line 387 in src\FXIPC.cxx thread 2656
> > Exception occurred in thread 2656 (IPC channel monitor): Maximum
> message size exceeded
> > (570425344 with limit of 65536) (code 0x7C8B4603 file
> > src\FXIPC.cxx line 387 in FX::FXIPCChannel::doReception() thread 2656)
>
> > Stack backtrace:
> > 0x620021B1:<unknown> FX::FXException::FXException +0x41 >
> (file fxexception.h line
> no 389)
> > 0x62250EF4:<unknown> FX::FXIPCChannel::doReception +0x6b4 >
> (file fxipc.cxx line
> no 387)
> > 0x6224E127:<unknown> FX::FXIPCChannel::run +0x27
> > (file fxipc.h line no
> 817)
> > 0x6231F834:<unknown> FX::QThreadPrivate::run +0x1e4
> > (file qthread.cxx line no
> 1030)
> > 0x623211B9:<unknown> FX::start_thread +0xb9
> > (file qthread.cxx line no
> 788)
> > 0x623210EC:<unknown> FX::start_threadwin +0xc
> > (file qthread.cxx line no
> 841)
> > 0x7C80B6A3:<unknown> GetModuleFileNameA +0x1b4
> > (file <unknown> line no
> 0)
> > <backtrace ends>
> > Thread 2656 (IPC channel monitor) cleanup
> > Attempting to send Disconnect message to other end of IPC connection >
> Thread 2656 sending msg 0x1 (struct FX::FXIPCMsg_Disconnect), len=18
> bytes
> > Succeeded in sending Disconnect message to other end of IPC connection! >
> Thread 560 received msg 0x1 (struct FX::FXIPCMsg_Disconnect), len=18
> bytes
> > class WindowConnector *@02DAB320: msgReceived()
>
> I think the exception is generated at reception in main thread.
> I do not know, what else i must post for detecting the problem..
> Strange what message size is 570425344..
>
> Where I could wrong?

Are you sure you are defining & registering the message chunk
correctly as per the documentation and source code examples?

Your error above suggests a serialisation/deserialisation mismatch in
the message sent before that message - the exception you got is a
trap for that problem. There is some #ifdef DEBUG code in the
FXIPCChannel source which may help and there are even more debug
outputs which can be commented into working too. One of them even
dumps a byte output of bytes received & sent so you should definitely
find where the problem is.

Cheers,
Niall

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: TnFox application in DLL and threads

2008-09-16T08:22:22Z

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(). Basically it
runs via getNextEvent() and dispatchEvent().

> I think I need to use FXObject...
>
> struct Data;
> class Receiver: public FXObject
> {
> public:
> ...
> /** For sync calls. */
> void syncCall(Data *data);
>
> /** For async calls. */
> long tryHandle (FXObject *sender, FXSelector sel, void *ptr);
> }
>
> For sync call from worker thread I can do:
> m_receiver->syncCall(m_data);
>
> For async:
> m_receiver->getEventLoop()->postAsyncMessage(bla bla);
>
> How to pump Receiver message system from MFC message lopp?

See above.

If you wish to invoke some synchronous call which isn't threadsafe,
you should set up a message handler which receives async messages
from other threads and executes the required call. I personally would
have it pass a BoundFunctor such that any thread can invoke any
function in any other thread arbitrarily. I have an implementation of
this actually in Tn but not TnFOX - it wouldn't be hard to port over
though. I might add that to the todo list actually.

> PS Is this ok, what I write to you personally instead of to maillist?

I'd prefer the mailing list so others can search it in the future.

HTH,
Niall

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: TnFox application in DLL and threads

2008-09-13T06:26:59Z

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 thread so API can be
> safely called.
>
> How I can attached to dll thread?
> Can i receive in main (dll) thread event form worker thread?
>
> I use MFC, TnFOX-0.88-FOXv1.6.33, MCVC++ 2005.
>
> PS Sorry for english)

TnFOX copies the Windows model, so each thread has its own window
stack which only it can access. Multiple threads can have multiple
window stacks.

As you correctly point out, if a worker thread wishes to access a
window stack belonging to a different thread, it must post a message
to that thread using TnFXApp::postAsyncMessage() or more conveniently
wndh->getEventLoop()->postAsyncMessage().

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.

Does this help? Your email was a bit unclear.

Cheers,
Niall

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

TnFox application in DLL and threads

2008-09-11T10:15:54Z

Hi.

I'm writing dll for some program.
And i want to use TnFox in this dll.

I found topics:
Using tnfox in a COM component
Question about launching application itself in a separate thread

and tried to create Window in dll.
Ok. TnFox application works fine in dll.

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 thread so API can be
safely called.

How I can attached to dll thread?
Can i receive in main (dll) thread event form worker thread?

I use MFC, TnFOX-0.88-FOXv1.6.33, MCVC++ 2005.

PS Sorry for english)

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: Question about launching application itself in a separate thread

2006-05-09T07:03:51Z

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 server basically looks like:
>
> int launch(int argc, char** argv) {
> FX::FXProcess myprocess(argc, argv);
> FX::TnFXApp application("foo", "bar");
> application.init(argc, argv);
> MyThread primaryLoop(&application);
> return application.run(primaryLoop);
> }
>
> but of course this does not return until the application ends. What I
> want is that the primaryLoop starts (and thus starts the GUI), the GUI
> is kept running and that this launch function still returns.
> In the past I did this with putting the application.run method in an
> FXThread, but I can not do this in TnFOX anymore.
>
> I think it is trivial what i want to do, but i cannot see how to do it :-)

What you could do, and I stress this will only work on Windows, is
run the message pump for MyThread and just not bother for the main
thread.

Therefore, you'd do everything you're doing except that instead of
return application.run(primaryLoop), you'd invoke
primaryLoop.start(true). This will cause launch() to return
immediately, which means FXProcess will get destroyed along with
TnFXApp.

Therefore you need to move those into static FXAutoPtr's so they
persist as long as TnFOX code is running. You should then at some
point before program termination but after the TnFOX code has
finished destroy the TnFXApp and the FXProcess.

If you want some hints on how to do this, look at the code in
Python/converters.cxx which has to temporarily instantiate a
FXProcess when TnFOX is loaded into python as a module and then
correctly deinitialise stuff when it gets kicked out of python. It
uses FXPtrHold rather than FXAutoPtr, but the process is very
similar.

Hope this helps.

Cheers,
Niall

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: Re: followup on

2006-05-06T12:42:22Z

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 have committed fixes to SVN at
http://svn.berlios.de/viewcvs/tnfox/.

Cheers,
Niall

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: Re: followup on

2006-05-05T05:36:40Z

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
> > example, resolved the problem.

How wonderful of Microsoft! :(

I'll commit a fix to SVN, but in the meantime your problems appear to
be caused by defining FXINLINE_MUTEX_IMPLEMENTATION. If you can wait
to tomorrow I'll have a full fix in SVN as I don't think it's ever
been tested on msvc8. Until then, best undefine it!

Cheers,
Niall

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: followup on

2006-05-05T04:36:34Z

>
> 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
> example, resolved the problem.
>
> David De Weerdt

Compilation went fine now, but now I am unable to link:

FXColorWheel.obj : error LNK2005: "private: int __thiscall
FX::FXAtomicInt::get(void)const " (?get@FXAtomicInt@FX@@ABEHXZ) already defined
in FXApp.obj
FXColorWheel.obj : error LNK2005: "public: __thiscall FX::FXAtomicInt::operator
int(void)const " (??BFXAtomicInt@FX@@QBEHXZ) already defined in FXApp.obj
FXColorWheel.obj : error LNK2005: "private: int __thiscall
FX::FXAtomicInt::set(int)" (?set@FXAtomicInt@FX@@AAEHH@Z) already defined in
FXApp.obj
FXColorWheel.obj : error LNK2005: "public: int __thiscall
FX::FXAtomicInt::operator=(int)" (??4FXAtomicInt@FX@@QAEHH@Z) already defined in
FXApp.obj
FXColorWheel.obj : error LNK2005: "private: int __thiscall
FX::FXAtomicInt::incp(void)" (?incp@FXAtomicInt@FX@@AAEHXZ) already defined in
FXApp.obj
FXColorWheel.obj : error LNK2005: "public: int __thiscall
FX::FXAtomicInt::operator++(int)" (??EFXAtomicInt@FX@@QAEHH@Z) already defined
in FXApp.obj
FXColorWheel.obj : error LNK2005: "private: int __thiscall
FX::FXAtomicInt::pinc(void)" (?pinc@FXAtomicInt@FX@@AAEHXZ) already defined in
FXApp.obj
FXColorWheel.obj : error LNK2005: "public: int __thiscall
FX::FXAtomicInt::operator++(void)" (??EFXAtomicInt@FX@@QAEHXZ) already defined
in FXApp.obj
FXColorWheel.obj : error LNK2005: "private: int __thiscall
FX::FXAtomicInt::finc(void)" (?finc@FXAtomicInt@FX@@AAEHXZ) already defined in
FXApp.obj
...

I get this for a lot of files, always the symbol already seems to be defined in
FXApp.obj, even for TnFXApp.obj I get this problem.

Am I alone with this problem? :-)

David De Weerdt

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: build error on FXApp.cpp

2006-02-27T06:10:14Z

On 26 Feb 2006 at 21:11, jayn@... 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 memmap.cpp.
>
> Without FX_FOXCOMPAT defined, these four fail
> 1. gltest.cpp gltest.cpp:163: error: call of overloaded 'strdup(const
> char*&)' is ambiguous
>
> 2. memmap.cpp memmap.cpp:52: error: 'FXMemMap' was not declared in this scope
>
> 3. imageviewer.cpp imageviewer.cpp:522: error: 'FXFileStream' was not
> declared in this scope
>
> 4. image.cpp image.cpp:363: error: 'FXFileStream' was not declared in this
> scope

Yeah, FXFileStream and FXMemMap are among the classes only supported
with the FX_FOXCOMPAT option. I put a note about this in
foxtests/!ReadmeFirst.txt

> With FX_FOXCOMPAT defined, adding the line below to your SConscript
> env['CPPDEFINES']+=[ "FX_FOXCOMPAT" ]
> only these two fail, but I'm guessing the problem may be that the entire
> library needs to be rebuilt with that FX_FOXCOMPAT defined. Is that
> right?

Yes, the entire library needs to be rebuilt. It's easier just to set
the option inside config.py rather than hack the SConstruct files.

> 1. gltest.cpp ... the strdup problem
>
> 2. memmap.cpp ... memmap.cpp:52: undefined reference to
> `FX::FXMemMap::FXMemMap()'
>
>
> I'm not sure the compatibility option is necessary for these examples.
> I'll look at what changes are required to fix the 4 examples so that they
> work with FX_FOXCOMPAT undefined.

Well, I'm hesitant to change the code too much. FXMemMap should be
replaced with QMemMap which probably means rewriting the test. I
think that can't be ported.

FXFileStream is much easier - if you use FXFile plus a FXStream, then
both of these are present without FX_FOXCOMPAT and you're still not
using any TnFOX-specific code.

As far as the strdup problem in gltest.cpp, I'm definitely not
getting that on either SuSE 10 or Windows anymore. Of course, if
you're still having a problem, a simple FX::strdup may be the only
answer.

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: TnFOX Size?

2006-02-26T16:04:03Z

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::FXDirSelector
> \li FX::FXDLL
> \li FX::FXDriveBox
> \li FX::FXFileDialog
> \li FX::FXFileList
> \li FX::FXFileSelector
> \li FX::FXPrintDialog
> \li FX::FXReplaceDialog
> \li FX::FXSearchDialog
>
> is that old info, or could that be the reson I get FXFile issues?

No that's when you define BUILDING_TCOMMON. You'll never do that in
all likelihood.

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: Trying to move from FOX 1.6.0 (dev) to TnFOX, some errors encountered:

2006-02-26T16:03:06Z

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/usr/lib -L/usr/X11R6/lib -lGL -L./system -lpng -
> lfmod-3.74.1 -lFOX-1.6 -lXext -ldl -lpthread -lX11 -lz -fpic -DHAVE_GL_H=1
> -DHAVE_PNG_H=1 -I ./include/FOX -I ./include/FMOD
>
> I need to somehow make scons do that exact thing, is there some kind of auto
> scon file generator?

It can be as simple as:

env=Environment()
env.Program("main.cpp", LIBPATH=['/usr/lib', '/usr/X11R6/lib'],
LIBS=['GL', 'png', 'fmod-3.74.1', 'FOX-1.6', 'Xext', 'dl', 'pthread',
'X11', 'z'], CPPFLAGS=['-fpic'], CPPDEFINES=[('HAVE_GL_H', 1),
('HAVE_PNG_H', 1)], INCLUDES=['./include/FOX', './include/FMOD'])

However, both FOX and TnFOX require a little more than that and more
importantly, a lot of the above is autogenerated for you. Look at
that foxtests folder.

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: build error on FXApp.cpp

2006-02-26T15:57:50Z

On 26 Feb 2006 at 11:39, jayn@... 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 definitions in the includes, but I
> haven't looked into this further.

I've added the fox test suite. I fixed these strdup problems by
adding WIN32_LEAN_AND_MEAN to fx3d.h so it doesn't include WinSock.h

> /home/jay/tnfox/TnFOX/include/fx.h:294: error: 'timeval' is already
> declared in this scope
> /home/jay/tnfox/TnFOX/include/fx.h:299: error: 'strdup' is already
> declared in this scope
> ../Tn/TFileBySyncDev.cxx: In member function 'void
> Tn::TFileBySyncDevPrivate::dynchkBuffers()':
> ../Tn/TFileBySyncDev.cxx:133: warning: format '%d' expects type 'int',
> but argument 2 has type 'size_t'
> ../Tn/TFileBySyncDev.cxx: In member function
> 'FX::FXIPCChannel::HandledCode
> Tn::TFileBySyncDevPrivate::msgReceived(FX::FXIPCMsg*)':
> ../Tn/TFileBySyncDev.cxx:260: warning: converting negative value
> '-0x00000000000000001' to 'unsigned int'
> scons: *** [Debug_g++_x64_0/main.o] Error 1
> scons: building terminated because of errors.

Fixed.

> > If ControlPanel.cpp defines its own DEFAULT_SPACING, it will need
> > changing. I fixed the QSSLDevice.h problem by renaming None to
> > NoEncryption. It's in SVN.

Fixed this.

> >> 3. groupbox.cpp doesn't compile because of conflicting definitions of
> >> timeval shown below.
> > Hopefully fixed in SVN but not tested.
>
> This not fixed either. See 3. above

Fixed this.

> >> 4. iconlist.cpp builds, but on running produces a bunch of assert
> >> messages.
> >>
> >> TYPE:SEL_UPDATE ID:1 SENDER: FXIconList PTR:
> >> 0x00000000 #1 src/FXDebugTarget.cpp:155:
> >> FXASSERT(ARRAYNUMBER(messageTypeName)==SEL_LAST) failed.
> >> 2 Deleted secure heap
> >>
> >> Unhandled Signal 0x2 (User interrupt)
> >> at address (nil) - immediate exit!
> >
> > Dunno about this one.

Fixed the assertion error.

> >> 5. imageviewer.cpp builds, but on running and selecting a gif file, it
> >> aborts with an error below (the first two exceptions are at startup).
> >>
> >> [jay@localhost tests]$ ./imageviewer
> >> FXApp: Using font 'luxi sans,80,normal,normal' for normal font
> >> FXException id 1 created, 'File '/home/jay/.foxrc/FoxTest/FoxTest' not
> >> found' at line 275 in src/QFile.cxx thread -1425916512
> >> FXException id 2 created, 'File '/home/jay/.foxrc/FoxTest/ImageViewer'
> >> not
> >> found' at line 275 in src/QFile.cxx thread -1425916512
> >> Deleted secure heap
> >>
> >> Unhandled Signal 0xb (Segmentation fault [Address not mapped to object])
> >> at address (nil) - immediate exit!
> >
> > Oh dear. I will investigate when I next get time.

Fixed.

> >> 6.memmap.cpp fails to build. I haven't looked into this.
> >>
> >> memmap.o(.text+0xcc): In function `main':
> >> /home/jay/tnfox/TnFOX/fox_tests/tests/memmap.cpp:52: undefined reference
> >> to `FX::FXMemMap::FXMemMap()'
> >
> > It should work if you enable the FOX compat layer in config.py.

Tested this and indeed it does work. Did you compile your TnFOX
library with the compat layer on?

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: TnFOX Size?

2006-02-26T14:57:32Z

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::FXDirSelector
    \li FX::FXDLL
    \li FX::FXDriveBox
    \li FX::FXFileDialog
    \li FX::FXFileList
    \li FX::FXFileSelector
    \li FX::FXPrintDialog
    \li FX::FXReplaceDialog
    \li FX::FXSearchDialog

is that old info, or could that be the reson I get FXFile issues?

--------------------------------------------------------------------------
Talent is not something you learn, its something you refine.

If you make something that any idiot can use, only idiots will use it.

Re: Trying to move from FOX 1.6.0 (dev) to TnFOX, some errors encountered:

2006-02-26T14:37:43Z

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:

(a shell script that does the following)

g++ main.cpp -o myapp -L/usr/lib -L/usr/X11R6/lib -lGL -L./system -lpng -lfmod-3.74.1 -lFOX-1.6 -lXext -ldl -lpthread -lX11 -lz -fpic -DHAVE_GL_H=1 -DHAVE_PNG_H=1 -I ./include/FOX -I ./include/FMOD

I need to somehow make scons do that exact thing, is there some kind of auto scon file generator?

On 2/26/06, Niall Douglas <s_sourceforge@...> wrote:

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 of FOX tests in SVN. Actually, I haven't
uploaded it yet but I will within the hour.

> Do you have any quick and easy ways to make a scons setup so I can use that
> to compile my app and maybe get a better understanding of whats going on?

Scons is very easy to use. I'd recommend copying the
foxtests/SConstruct file and altering as appropriate. I derived that
SConstruct from the TestSuite/CommonSConstruct.py in about five
minutes.

Obviously, you may find the scons man page useful. There are FAQ's
and tutorials on the web too. BTW, I'll apologise now for the
structure of my SConstruct files - I began them well before scons
matured and I had to work around misfeatures.

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

--
Talent is not something you learn, its something you refine.

If you make something that any idiot can use, only idiots will use it.

<a href="http://www.spreadfirefox.com/?q=affiliates&id=0&t=1">Get Firefox!</a>

Re: Trying to move from FOX 1.6.0 (dev) to TnFOX, some errors encountered:

2006-02-26T13:52:20Z

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 of FOX tests in SVN. Actually, I haven't
uploaded it yet but I will within the hour.

> Do you have any quick and easy ways to make a scons setup so I can use that
> to compile my app and maybe get a better understanding of whats going on?

Scons is very easy to use. I'd recommend copying the
foxtests/SConstruct file and altering as appropriate. I derived that
SConstruct from the TestSuite/CommonSConstruct.py in about five
minutes.

Obviously, you may find the scons man page useful. There are FAQ's
and tutorials on the web too. BTW, I'll apologise now for the
structure of my SConstruct files - I began them well before scons
matured and I had to work around misfeatures.

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: TnFOX Size?

2006-02-26T13:09:07Z

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 into TnFOX that makes it so much larger? All I
> need is basic GUI code with the IPC features.

Well there's an additional 35,000 lines of code in there which is
about a third more than FOX v1.4. Here are some figures (for
msvc7.1):

FOX 1.6 (with /O2): 2.14Mb
TnFOX no GUI: 0.95Mb
TnFOX minimal: 2.97Mb (+39%)
TnFOX full: 4.4Mb (+106%)

If you want something approaching minimal, see the FAQ section in
include/TnFOXDocs.h from SVN. But in short, disable the FOX compat
layer, disable openssl and the graphics libs (in sconslib.py) and
delete the embedded copy of sqlite3 in the src directory.

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: Trying to move from FOX 1.6.0 (dev) to TnFOX, some errors encountered:

2006-02-26T11:16:03Z

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.

Do you have any quick and easy ways to make a scons setup so I can use that to compile my app and maybe get a better understanding of whats going on?

On 2/26/06, Niall Douglas <s_sourceforge@...> wrote:

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 portable as a makefile or scons, but it is much
> cleaner, smaller and easier.

Ok, but you'll understand you may run into problems I can't see
because of this.

> I dont mind a portable workarround for the timeval issue, as you stated I
> would rather do this than make an unportable solution.  What is your
> solution here?

Well, try the latest from SVN. In fx.h it tells the compiler to
always use FX::timeval rather than ::timeval. This is fine unless you
do direct calls into Unix, then you'll need to put a '::' before your
timeval.

> I include fx.h and fx3d.h as the very first thing in my code so its not
> related to that in anyway.  I get hundreds of errors from these FXFile and
> friends because I have so many used in my app.  I can attempt to include the
> FXSystem, FXDir, FXFile, etc... directly and see if that changes anything.

fx.h includes everything. I don't see that as the problem.

> I dont use any fox thread or memory functions, or any similar low level
> functions, just the gui, string manipulation and file info.  The only errors
> that I get are the file and directory missing function ones.  Everything
> else looks like it will compile without a hitch.

It should all compile definitely - for example, nearly the entire FOX
examples suite compiles and runs perfectly even without the FOX
compat layer. Some of the FOX emulations aren't well tested and may
cause problems, but they should all compile.

Can you give me an example of some source which causes errors?

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

--
Talent is not something you learn, its something you refine.

If you make something that any idiot can use, only idiots will use it.

<a href=" http://www.spreadfirefox.com/?q=affiliates&id=0&t=1">Get Firefox!</a>

Re: TnFOX Size?

2006-02-26T11:12:06Z

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 into TnFOX that makes it so much larger? All I need is basic GUI code with the IPC features.

On 2/26/06, Niall Douglas <s_sourceforge@...> wrote:

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 parser is not very good and generates a lot
of unnecessary code. This adds around 2Mb of unnecessary code. As
TnFOX uses a lot of templates, it's not like it can be compiled out.

Best thing is to move to a better compiler. They totally replaced the
template parser in 3.4 and the output shrinks massively, as well as
running a lot faster.

If that's simply not possible, don't worry you'll get the binary
shrink when Knoppix upgrades to 3.4. The current situation will be
temporary.

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

--
Talent is not something you learn, its something you refine.

If you make something that any idiot can use, only idiots will use it.

<a href=" http://www.spreadfirefox.com/?q=affiliates&id=0&t=1">Get Firefox!</a>

Re: Trying to move from FOX 1.6.0 (dev) to TnFOX, some errors encountered:

2006-02-26T09:40:11Z

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 portable as a makefile or scons, but it is much
> cleaner, smaller and easier.

Ok, but you'll understand you may run into problems I can't see
because of this.

> I dont mind a portable workarround for the timeval issue, as you stated I
> would rather do this than make an unportable solution. What is your
> solution here?

Well, try the latest from SVN. In fx.h it tells the compiler to
always use FX::timeval rather than ::timeval. This is fine unless you
do direct calls into Unix, then you'll need to put a '::' before your
timeval.

> I include fx.h and fx3d.h as the very first thing in my code so its not
> related to that in anyway. I get hundreds of errors from these FXFile and
> friends because I have so many used in my app. I can attempt to include the
> FXSystem, FXDir, FXFile, etc... directly and see if that changes anything.

fx.h includes everything. I don't see that as the problem.

> I dont use any fox thread or memory functions, or any similar low level
> functions, just the gui, string manipulation and file info. The only errors
> that I get are the file and directory missing function ones. Everything
> else looks like it will compile without a hitch.

It should all compile definitely - for example, nearly the entire FOX
examples suite compiles and runs perfectly even without the FOX
compat layer. Some of the FOX emulations aren't well tested and may
cause problems, but they should all compile.

Can you give me an example of some source which causes errors?

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion

Re: TnFOX Size?

2006-02-26T09:40:11Z

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 parser is not very good and generates a lot
of unnecessary code. This adds around 2Mb of unnecessary code. As
TnFOX uses a lot of templates, it's not like it can be compiled out.

Best thing is to move to a better compiler. They totally replaced the
template parser in 3.4 and the output shrinks massively, as well as
running a lot faster.

If that's simply not possible, don't worry you'll get the binary
shrink when Knoppix upgrades to 3.4. The current situation will be
temporary.

Cheers,
Niall

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Tnfox-discussion mailing list
Tnfox-discussion@...
https://lists.sourceforge.net/lists/listinfo/tnfox-discussion