A quick update on this old thread...
Remember that I'm having troubles with a self-installed command that
calls other self-installed commands. When the first one is called, the
user is prompted with a modal ppg, where he has to enter some
parameters. On of these infos is the shot number (along with episode
and sequence).
To help myself trouble shooting these scripts when a problem occurs,
these commands print lots of messages. Among these message, the
information relating to the shot number is printed. So technically,
you would expect these command to print the same shot number infos
than those entered by the user, right?
Well I have noticed that sometimes, for some obscure reasons, the shot
number processed by the secondary commands is not the same than the
one entered by the user. Specifically, the shot number processed by
the command is an old shot number, that the user previously worked on.
I could notice that because the problem happened to me a few times.
Since I do very little shots compared to the other artists, when I
noticed that, I saw a shot number that I had worked few days ago. It's
not the first time it happens to me.
I have yet to find an explanation for this, as the commands do not
store any information on disk, do not do pickling, or anything that *I
thing* should cause some persistance of such data. Unless there is
some bug or caching mechanism that we poor motal users don't know
about? Perhaps there is a brute force way flush any reference to data
that could be used after the commands complete their task?
Then the second or sometimes the third time I run the commands, it
works without a problem. As I said in the beginning of this thread,
sometimes one needs to restart XSI, sometimes it just works the next
time the user runs the command.
One last comment: since I originally posted about these problems, it
seems things improved without any intervention from my part. I don't
know why, but users stopped reporting these problems not long after. I
doubt it still happens but they don't tell me, because these shots
would bounce back to them sooner or later, wich is not the case.
Perhaps it is my karma then :-)
(I hope so)
Cheers
Bernard
On 8/15/05, kim aldis <kim(at)cg-soup.com> wrote:
> My thoughts were more along the lines of code left inadvertantly in other
> workgroups, or my classic, making a backup suddirectory of my plugins
> folder, not realising that xsi uses the directory recursively and spending
> an hour or so trying to find out why my plugins were failing to load, still
> working but working incorrectly.
>
> The idea of using logged versioning to prevent this from happening isn't a
> bad one, though.
>
>
>
> > -----Original Message-----
> > From: owner-xsi(at)Softimage.COM
> > [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Andrew Skowronski
> > Sent: 15 August 2005 19:49
> > To: XSI(at)Softimage.COM
> > Subject: RE: [script] Same python code, different results
> >
> > Having some out-of-date script files in memory is a good
> > theory - XSI caches a self-installed plug-in script in memory
> > once it is first instantiated.
> >
> > So in Kim's scenario the Logmessage won't actually show up until
> >
> > -XSI restarted
> > -Update button on Plug-in Manager pressed -Some OM code
> > called to unload/reload the specific plugins
> >
> > -Andrew
> >
> > -----Original Message-----
> > From: owner-xsi(at)Softimage.COM
> > [mailto:owner-xsi(at)Softimage.COM]On Behalf Of kim aldis Posted
> > At: Monday, August 15, 2005 12:17 PM Posted To: xsi
> > Conversation: [script] Same python code, different results
> > Subject: RE: [script] Same python code, different results
> >
> >
> > try taking the plugins you think everyone is using, add a
> > coded logmessage in the init or command, wait for a baddy and
> > see if the log is there, or check see if everyone gets the log.
> >
> > > -----Original Message-----
> > > From: owner-xsi(at)Softimage.COM
> > > [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Bernard Lebel
> > > Sent: 15 August 2005 17:08
> > > To: XSI(at)Softimage.COM
> > > Subject: Re: [script] Same python code, different results
> > >
> > > Here the issues affects self-installed commands, not imported
> > > libraries. Isn't the command names garbaged collected immediately
> > > after it returns?
> > >
> > > Bernard
> > >
> > >
> > > On 8/15/05, xsibrad(at)fie.us <xsibrad(at)fie.us> wrote:
> > > > I have been noticing some oddities on our python setup as well...
> > > > though nothing as large as what you seem to be running into.
> > > >
> > > > Since I never removed the LogMessage commands from some
> > of our self
> > > > installed python commands (ir lazy), I do get to see when
> > they init
> > > > and all that jazz (hey, we're still in developoment... not
> > > release).
> > > > and often a python self installed command will fail to init
> > > once and then init fine the next time...
> > > > with no changes to its code. So far it has not caused any
> > > major problems.
> > > > Except of course the problem of confusing and belittling
> > > the programmer (me).
> > > >
> > > > I guess the next obvious question is: has this been
> > > happening during a
> > > > period that you've been coding into your python tools? Is
> > > it possible
> > > > that a module has been loaded into the python runtime for
> > > like... two
> > > > days... since some artists may leave XSI running that long?
> > > In that
> > > > time, you could have updated the code twice... but they
> > > might still have the old version loaded into memory.
> > > > Or is that a wild goose chase too? I thought I'd point out the
> > > > obvious easy solutions first. Cause the next suggestion becomes
> > > > testing out different python installs (activestate vs.
> > > python.org etc). ouch.
> > > >
> > > > -brad
> > > >
> > > > Quoting Bernard Lebel <3dbernard(at)gmail.com>:
> > > >
> > > > > Andrew:
> > > > >
> > > > > >> Maybe there is a command conflict (same command name
> > > > >
> > > > > I'm pretty sure that is not the case! I mean,
> > otherwise, wouldn't
> > > > > all of the 25 users of the workgroup run into these
> > > problems? I seem
> > > > > to never run into these problems (or almost), while some
> > > others run
> > > > > into this several times a day.
> > > > >
> > > > > >> or command scripting name being used more than once)?
> > > > >
> > > > > Hum I will 100ple-check that, thanks for the tip.
> > > > >
> > > > >
> > > > >
> > > > > Kim:
> > > > >
> > > > > > Sounds to me like some of the machines are looking at older
> > > > > > versions of code?
> > > > >
> > > > > That is extremely unlikely. The reason is the only plugin the
> > > > > Plugins directory in the workgroup contains is a plugin
> > > loader, it
> > > > > explicitely load plugin files that are located in a
> > directory not
> > > > > part of the workgroup. Unless the plugin loader has duplicate
> > > > > entries, loading plugins of the same name twice is
> > > technically impossible.
> > > > >
> > > > > But again I will 101ple-check all this stuff. Thanks
> > for the tip.
> > > > >
> > > > >
> > > > >
> > > > > Bernard
> > > > >
> > > > > ---
> > > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the
> > > following text in body:
> > > > > unsubscribe xsi
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > This message was sent using IMP, the Internet Messaging Program.
> > > >
> > > > ---
> > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the
> > > following text in body:
> > > > unsubscribe xsi
> > > >
> > >
> > > ---
> > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the
> > following text in
> > > body:
> > > unsubscribe xsi
> > >
> >
> > ---
> > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following
> > text in body:
> > unsubscribe xsi
> >
> > ---
> > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following
> > text in body:
> > unsubscribe xsi
> >
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
