From: Aline Normoyle (aline++at++mak.com)
Date: 07/30/2000 14:40:26
Hi,
First of all, please let me say thanks to Tom for all his suggestions last
week. I am still looking at that problem, but in the meantime, I have a
quick question:
As you've probably guessed, we've based our application on the perfly app
that comes with performer. When someone runs both perfly and our
application on an SGI machine with the -W argument, they can then re-size
the window afterwards. On the linux platform, however, the window size is
fixed. Why is this the case? If possible, I'd like to be able to change
perfly so that windows created with the -W option are re-sizable by the
user afterwards.
thanks again.
sincerely,
Aline
***********************************************
* Aline Normoyle
* MaK Technologies Product Group
* (617) 876 - 8085 X 137
* aline++at++mak.com
***********************************************
On Fri, 21 Jul 2000, Tom Flynn wrote:
>
> Sorry about this, I had a rather significant typo:
>
> On Thu, 20 Jul 2000, Tom Flynn wrote:
>
> > The problem with pfuInitInput() you're seeing is probably related to where
> > it is placed within main(). Try putting it after pfdInitConverter() and
> > before pfConfig(). If the problem persists, please send us an email at
> > mongoose-feedback++at++corp.sgi.com.
>
> I was refering to placement of pfuInit(). You won't see the problem until
> pfuInitInput().
>
> tom
>
> > hope that helps,
> > tom
> >
> > On Thu, 20 Jul 2000, Aline Normoyle wrote:
> >
> > >
> > > Hi,
> > >
> > > We're in the process of trying to port a performer application to linux
> > > (Red Hat 6.2, gcc version egcs-1.1.2) using Performer 2.3.1. Throughout
> > > the documentation, I keep seeing that Shared Arenas and pfDataPools are
> > > not functional. I'm not sure what this means exactly, however, since the
> > > calls still exist in the libraries and work most of the time (calls such
> > > as pfGetSharedArena() are even being called in the perfly application).
> > >
> > > For example, in our application we are occasionally getting crashes in
> > > pfDataPool::find. Here's the call stack:
> > >
> > > #0 0x40883e43 in pfDataPool::find () from /usr/lib/libpr.so
> > > #1 0x408717b7 in pfDPoolFind () from /usr/lib/libpr.so
> > > #2 0x4030d240 in pfuNewEventQ () from /usr/lib/libpfutil_ogl.so
> > > #3 0x8143ac8 in initDataPool () at libpfu_input.c:130
> > > #4 0x8143d6d in pfuInitInput (pw=0x86048a0, mode=2) at libpfu_input.c:252
> > > #5 0x810b3ba in main (argc=4, argv=0xbffff7d4) at main.cxx:502
> > >
> > > libpfu_input.c is based on the file input.c from libpfutil and the two
> > > functions, pfuInitInput and initDataPool, are identical to the ones which
> > > came with 2.3.1.
> > >
> > > What types of things should we be doing to get around "not supported"
> > > functions? Are there any obvious errors which would result in
> > > pfDataPool::find to crashing?
> > >
> > > Any information regarding the current state of these memory functions
> > > would be extremely helpful!
> > >
> > > thanks, Aline
> > >
> > > ***********************************************
> > > * Aline Normoyle
> > > * MaK Technologies Product Group
> > > * (617) 876 - 8085 X 137
> > > * aline++at++mak.com
> > > ***********************************************
> > >
> > > -----------------------------------------------------------------------
> > > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > > Submissions: info-performer++at++sgi.com
> > > Admin. requests: info-performer-request++at++sgi.com
> > >
> >
> > --
> > "Mongooses are famous for their snake-fighting ability, and are
> > almost always victorious because of their speed, agility, and timing
> > and also because of their thick coat."
> >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> >
>
> --
> "Mongooses are famous for their snake-fighting ability, and are
> almost always victorious because of their speed, agility, and timing
> and also because of their thick coat."
>
This archive was generated by hypermail 2b29 : Sun Jul 30 2000 - 14:40:34 PDT