below:
> -----Original Message-----
> From: owner-xsi(at)Softimage.COM
> [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Bernard Lebel
> Sent: Thursday, February 28, 2008 8:09 PM
> To: XSI(at)Softimage.COM
> Subject: Re: XSI crashes on startup when updating a workgroup
>
> Look Matt, I'm not saying anything here.
>
> *All* my test showed that A loads before underscore....
> consistently (in 6.02).
> In XSI 5.11, underscore loaded before a, in 6.02, it's A
> before underscore. Consistently.
Ugh - I've been on Windows too long. I forgot as of Windows XP the
windows explorer sorts things differently from the ASCII character
table. ASCII order is:
- numbers
- uppercase letters
- underscore
- lowercase letters
The windows explorer sorts as:
- underscore
- numbers
- letters (upper and lower case)
>
> In order to reduce file I/O overhead (which is a lot more
> significant with Python), I decided to have only one plugin
> per scripting language. The project is called "podcats", so
> the plugins are named:
> podcats_py.py
> podcats_js.js (which also contains the events)
> podcats_vb.vbs.
> The workgroup syncing plugin is named async.js. It always
> loads first, I assure you. I'm not pretending it is the
> expected behavior or it is reliable, it just do that
> consistently from what I can tell.
>
> As for your problem, remember: if you call UpdatePlugins()
> from a plugin that has to be updated in the process, you'll
> compromise XSI's stability. That's what my experiments led me
> to conclude. So do whatever you want to deal with this.
I've been calling XSIApplication.UnloadPlugin() to unload each plugin
before replacing it, but XSI still crashes. Hence why I'm scratching my
head.
>
> The IDEAL scenario would be to launch XSI from a script file
> rather than the factory bactch file. The script file, most
> likely javascript/jscript, would really download updates from
> an apache server, and then launch XSI and exit. I
> experimented with that at Big Bang, just before leaving, and
> it worked really well. It also allowed us to change the log
> commands preference without having reset to true by XSI, by
> modifying the user preference file. That was sweet, users
> gained performance.
Could you elaborate here? What do you mean by, "also allowed us to
change the log commands preference without having reset to true by XSI,
by modifying the user preference file."
Unfortunately, I don't have any experience with Apache servers or the
like. I'd like to get more involved in that area but don't know where
to begin.
> PS: Why do you require for an update upon termination? I'm
> not sure it's relevant to have an update when exiting, since
> the next launch is garanteed to get the update done.
Using your filenames as an example, if I needed to update async.js, I
can't do it when XSI is loading because async.js will be executing. The
only other time I can pull the latest version of async.js and not get in
the way of the user would be when XSI terminates. I can then unload the
plugin manually from XSI and replace it. Next time XSI starts, it will
use the new version of async.js. This is useful for occasions where the
production pipeline changes affecting tool delivery.
Matt
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
