Questions:

1. Vect will not start on my system or it gives me an error saying some library files not found.

2. When working on Mac OS X 10.2 Jaguar, Vect will not open when I double-clicked on it.

3. I visited the website above but the version of X11 I can find there only works on the newer Mac OS 10.3 Panther. How do I find an X11 that works for my 10.2 Jaguar?

4. When working with Vect, the output panel sample does not match the output generated by my Perl script during runtime.

5. The following message appears while running Vect under Mac OS X 10.2 Jaguar; Gdk-WARNING **: locale not supported by C library.

Q: Vect will not start on my system or it gives me an error saying some library files not found.

A: You many not have Perl installed on your machine, or your Perl installation is not found by the Vect binary. The latter problem happens often when you are running a different Linux distribution than Redhat 9, where Vect was built. Please follow the directions below to install Perl onto your system; http://www.complexcomputation.org/download/Vect/perl.html. If you know where your local Perl shared library is installed you can set the LD_LIBRARY_PATH environment variable to point to that directory, and Vect will execute.

After Vect is published in a scientific journal, we will make its source code available so you can try to build Vect specifically for your machine. However, building Vect is nontrivial and if you have the capability to build it, you probably don't need it! :-)

Q: When working on Mac OS X 10.2 Jaguar, Vect will not open when I double-clicked on it.

A: Under OS 10.2, Vect must be started within the Xterm window by typing a command, such as 'vect' or './vect'. The latter is necessary if you do not have your command search path setup to include the current or Vect directory. Note that the Xterm window is not the Terminal Application, but the window opened when you start Apple X11. Please visit the following site for more information about Apple X11 application; http://www.apple.com/macosx/x11/.

See the detailed information Apple provided to configure and execute X11 applications on your Mac:
http://developer.apple.com/darwin/runningX11.htm

Q: I visited the website above but the version of X11 I can find there only works on the newer Mac OS 10.3 Panther. How do I find an X11 that works for my 10.2 Jaguar?

A: Well, Apple has chosen to remove their X11 beta 3 for Jaguar from their website as a way to persuade customers to upgrade to Panther. If you cannot upgrade to Panther at the moment and you have not downloaded the X11 for Jaguar before or have no friend who has it, you may consider using third party X11 implementations such as XDarwin, OroborOSX, or you can use the popular Fink utility to automatically install a copy of X11 onto your machine. Fink is a must-have tool if you do any sort of Unix style data processing on your Mac. Highly recommended.

Q: When working with Vect, the output panel sample does not match the output generated by my Perl script during runtime.

A: There are several possibilities that this might happen. First, if your Vect rules are incorrect, like missing substring coordinates, missing source strings, or the coordinates do not read like a number, then Vect has no way of telling you what you will get (other than giving you Vect's own version of warning messages). Perl will has its own set of error messages, thus the mismatch. In another word, every effort has been put in to making sure the output from Vect and Perl are the same, but only WHEN THE RULES/PROGRAM IS CORRECT. Simulating Perl's error messages verbatim within Vect is not a priority for us at the moment.

Another possibility is that Perl may not be able to interpret your data files correctly while Vect can in some situations. If you are using a file nonnative to your platform, like a PC user is loading up a file sent to him by his Mac friend, or on the same platform like Mac but that has two different flavors of line breaks (Mac uses its own CR line breaks while Mac Perl treats NL as line breaks!), then you will have this problem! You can actually use Perl to fix this type of problems easily. See the following website for more information; http://www.macosxhints.com/article.php?story=20001206164827794.

When data are coming from the same input line, their order of processing by Perl is unknown to Vect and therefore if the data somehow influence each other, the outcome from Perl might be different than what Vect predicted. For example, if a string and its substring coordinates are coming from the same line, then either the string is received by the Substring Rule first, or its coordinates are received first. If only a single substring is to be extracted from each input string, then it doesn't matter which comes first since it's a one-to-one match. However, if multiple substrings are to be extracted from the same source string, it is possible that either the string or the coordinates are outdated when the substrings are taken out, thus the discrepancy. The reason is that the Vect generated code will keep the source string and extract substrings from it indefinitely until it's updated. Therefore, if the source string update is not synchronized with the coordinates, the discrepancy can happen even if data are coming from different lines. One can solve this problem easily by using a marker-based concatenation rule instead of a level-based one for both the source string and the coordinates.

Finally, another possibility is that Vect simply has some bugs! Please feel free to report bugs to us ()to help us improve Vect.

Q: The following message appears while running Vect under Mac OS X 10.2 Jaguar; Gdk-WARNING **: locale not supported by C library.

A: You can safely ignore it. You can find more information from the following website: http://fink.sourceforge.net/doc/x11/trouble.php#locale.