November 2006 - Boost-users - lists.preview.boost.org

Re: [Boost-users] Serialization problem on 64-bit Windows release
by Sergey Filippov 14 Nov '06

14 Nov '06

Robert Ramey <ramey <at> rrsd.com> writes: > This doesn't seem to be the case in your situation. Anyway, thank you for the information. I'll keep trying to reproduce an issue in test lab. Sergey

2 2

Minor ublas issue
by Daniel Krügler 14 Nov '06

14 Nov '06

Hello, I stumbled about the current cvs HEAD version of exception.hpp, where I found one remaining throw under *_NO_EXCEPTIONS conditions in "singular". Here the proposed fix: Index: exception.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/ublas/exception.hpp,v retrieving revision 1.19 diff -u -r1.19 exception.hpp --- exception.hpp 2 Feb 2006 19:27:23 -0000 1.19 +++ exception.hpp 13 Nov 2006 18:54:27 -0000 @@ -175,7 +175,6 @@ explicit singular (const char *) {} void raise () { - throw *this; std::abort (); } #endif I also would like to recommend, that the current exception text of struct non_real should be changed as follows (The prefix "exception:" seems redundant): Index: exception.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/ublas/exception.hpp,v retrieving revision 1.19 diff -u -r1.19 exception.hpp --- exception.hpp 2 Feb 2006 19:27:23 -0000 1.19 +++ exception.hpp 13 Nov 2006 19:01:45 -0000 @@ -185,7 +185,7 @@ #if ! defined (BOOST_NO_EXCEPTIONS) && ! defined (BOOST_UBLAS_NO_EXCEPTIONS) // Inherit from standard exceptions as requested during review. : public std::domain_error { - explicit non_real (const char *s = "exception: non real") : + explicit non_real (const char *s = "non real") : std::domain_error (s) {} void raise () { throw *this; Greetings from Bremen, Daniel Krügler

1 0

BJam can't find arguments to gcc-spawn
by Charles Broderick 14 Nov '06

14 Nov '06

I am having problems running even a basic Jamfile consisting only of: Main : main.c ; When running bjam with debugging on, I receive this output (truncated). I looked at allyourbase.jam and gcc-tools.jam, and it looks like OK jam code to me... why won't main.c get passed in as the target? /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:1136:>>>>|>>>>|>> switch .c /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:1139:>>>>|>>>>|>> Cc : main.c /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:624:>>>>|>>>>|>>>> DEPENDS : main.c /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:626:>>>>|>>>>|>>>> Cc-platform-specifics : main.c /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:593:>>>>|>>>>|>>>>|> local _h = /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:634:>>>>|>>>>|>>>> Cc-action : main.c /local/apps/boost/1.33.1/tools/build/v1/gcc-tools.jam:489:>>>>|>>>>|>>>>|> gcc-spawn /local/apps/boost/1.33.1/tools/build/v1/gcc-tools.jam:489: in Cc-action *** argument error * rule gcc-spawn ( targets + ) * called with: ( ) * missing argument targets /local/apps/boost/1.33.1/tools/build/v1/gcc-tools.jam:402:see definition of rule 'gcc-spawn' being called /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:634: in Cc /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:1139: in Object /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:1207: in Objects /local/apps/boost/1.33.1/tools/build/v1/allyourbase.jam:969: in Main Jamfile:2: in load-jamfiles /local/apps/boost/1.33.1/tools/build/v1/bootstrap.jam:21: in boost-build /local/apps/boost/1.33.1//boost-build.jam:16: in module scope

2 1

Re: [Boost-users] [Serialization] a couplacrashesfromhiearchycomplexity
by Reusser, Edward 13 Nov '06

13 Nov '06

Robert, After more analysis, I am getting evidence that this error might be on my end (something seems to corrupt the XML text itself). More to follow... Ed ________________________________ From: Robert Ramey [mailto:ramey@rrsd.com] Sent: Monday, November 13, 2006 2:22 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Serialization] a couplacrashesfromhiearchycomplexity it would seem to me that a stack trace would be interesting to see. I'm wondering if its just a stack that is too short (I would have expected to see this sooner if it was) or some error somewhere which creates an unterminated recurssion. With VC its easy to see the stack trace. With the Gnu Debuger, one has to back trace from the right point. Robert Ramey "Reusser, Edward" <Edward.Reusser(a)actel.com> wrote in message news:5E916BAE1732F344BAFD713DF2373479016EA233@SV-MSG-01.amer.actel.com.. . Robert, I would need permission to send you the exact library code. I am reluctant to do this primarily because recreating my exact build environment would be a hassle (we are using gnumake on the PC). I also would need to do this directly to you, as I could not post this code into a public forum. Having said that, any recursive descent parser has complexity limits based on stack size. It would be pretty easy to create test cases that probe these complexity limits for the various archive types. I would like to see how much (approximately) stack space is allocated in the runtime for each level of xml hierarchy, and also for the text archives. The main complexity seems to be because I am using shared_ptr's extensively at all levels of the hierarchy. Thus, I have 2 levels nested for each class, the <px> data </px> and the actual data, which is in turn being represented by a collection of shared_ptr's, etc. I am also using std::map of shared pointers, and std::set of shared_ptr's. I also use enable_shared_from_this<T> for my base classes, then statically cast the resultant shared pointers internally for the derived classes. This is to get around a Linux problem which I can describe more fully if you like (would take a few pages of explanation). So for example: class Base : public boost:enable_shared_from_this<Base> { virtual boost::shared_ptr<Base> GetSharedFromThis() { return shared_from_this(); } }; class Derived1 : public Base { public: virtual boost::shared_ptr<Derived1> GetSharedFromThis() { return static_pointer_cast<Derived1>( shared_from_this() ); } }; class Derived2 : public Base { public: virtual boost::shared_ptr<Derived2> GetSharedFromThis() { return static_pointer_cast<Derived2>( shared_from_this() ); } }; I am assuming that I do not need to call boost::serialization::base_object<boost::enable_shared_from_this<Base> >( *this ); When I serialize the base class. Could that be the problem? I think what I am going to do is go back into the program and simply eliminate all of the shared_ptr serializations. I can serialize to raw pointers, and then just create the shared_ptr's from those pointers explicitly in my case. I simply do not ever have any shared_ptr's with multiple reference counts to worry about. I will let you know what happens. ________________________________ From: Robert Ramey [mailto:ramey@rrsd.com] Sent: Monday, November 13, 2006 8:30 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Serialization] a coupla crashes fromhiearchycomplexity I would be curious to see your particular case. The fact that different archives give problems that seem related to nesting depth suggest along with the fact that this hasn't been reported suggests that there is some sort of use case or error which hasn't been considered. Robert Ramey "Reusser, Edward" <Edward.Reusser(a)actel.com> wrote in message news:5E916BAE1732F344BAFD713DF2373479016EA059@SV-MSG-01.amer.actel.com.. . I am using the serialization library in boost 1.33.1. I am compiling on windows using the VC 7.1 compiler. The problem I am having is that when I use xml_iarchive and xml_oarchive, everything works just fine for simple cases, but if the xml gets very deep ( same exact class hierarchy, just more data organized a little more complexly) I am getting runtime stack overflow crashes in the spirit parser. I figured I could solve that by simply substituting text_iarchive and text_oarchive. Please note that I am simply substituting in these archive types instead of using the xml archive headers, which work. There are no other code changes anywhere. Now I am getting the following compiler error: \boost\mpl\eval_if.hpp(40) : fatal error C1204: compiler limit : internal structure overflow Any suggestions? I can try increasing the stack size of my current application to eliminate the xml runtime stack overflow problem, but I am uneasy doing this until I understand how to calculate the stack sizes required, and why it is happening. Furthermore, I would prefer using the text archives, since the data is more compact than the xml ones. Ed Reusser Principal Software Engineer Actel Corporation (408) 318-4972 ________________________________ The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information. ________________________________ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ________________________________ The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information. ________________________________ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information.

1 0

Re: [Boost-users] [Serialization] a coupla crashes fromhiearchycomplexity
by Reusser, Edward 13 Nov '06

13 Nov '06

Robert, I would need permission to send you the exact library code. I am reluctant to do this primarily because recreating my exact build environment would be a hassle (we are using gnumake on the PC). I also would need to do this directly to you, as I could not post this code into a public forum. Having said that, any recursive descent parser has complexity limits based on stack size. It would be pretty easy to create test cases that probe these complexity limits for the various archive types. I would like to see how much (approximately) stack space is allocated in the runtime for each level of xml hierarchy, and also for the text archives. The main complexity seems to be because I am using shared_ptr's extensively at all levels of the hierarchy. Thus, I have 2 levels nested for each class, the <px> data </px> and the actual data, which is in turn being represented by a collection of shared_ptr's, etc. I am also using std::map of shared pointers, and std::set of shared_ptr's. I also use enable_shared_from_this<T> for my base classes, then statically cast the resultant shared pointers internally for the derived classes. This is to get around a Linux problem which I can describe more fully if you like (would take a few pages of explanation). So for example: class Base : public boost:enable_shared_from_this<Base> { virtual boost::shared_ptr<Base> GetSharedFromThis() { return shared_from_this(); } }; class Derived1 : public Base { public: virtual boost::shared_ptr<Derived1> GetSharedFromThis() { return static_pointer_cast<Derived1>( shared_from_this() ); } }; class Derived2 : public Base { public: virtual boost::shared_ptr<Derived2> GetSharedFromThis() { return static_pointer_cast<Derived2>( shared_from_this() ); } }; I am assuming that I do not need to call boost::serialization::base_object<boost::enable_shared_from_this<Base> >( *this ); When I serialize the base class. Could that be the problem? I think what I am going to do is go back into the program and simply eliminate all of the shared_ptr serializations. I can serialize to raw pointers, and then just create the shared_ptr's from those pointers explicitly in my case. I simply do not ever have any shared_ptr's with multiple reference counts to worry about. I will let you know what happens. ________________________________ From: Robert Ramey [mailto:ramey@rrsd.com] Sent: Monday, November 13, 2006 8:30 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Serialization] a coupla crashes fromhiearchycomplexity I would be curious to see your particular case. The fact that different archives give problems that seem related to nesting depth suggest along with the fact that this hasn't been reported suggests that there is some sort of use case or error which hasn't been considered. Robert Ramey "Reusser, Edward" <Edward.Reusser(a)actel.com> wrote in message news:5E916BAE1732F344BAFD713DF2373479016EA059@SV-MSG-01.amer.actel.com.. . I am using the serialization library in boost 1.33.1. I am compiling on windows using the VC 7.1 compiler. The problem I am having is that when I use xml_iarchive and xml_oarchive, everything works just fine for simple cases, but if the xml gets very deep ( same exact class hierarchy, just more data organized a little more complexly) I am getting runtime stack overflow crashes in the spirit parser. I figured I could solve that by simply substituting text_iarchive and text_oarchive. Please note that I am simply substituting in these archive types instead of using the xml archive headers, which work. There are no other code changes anywhere. Now I am getting the following compiler error: \boost\mpl\eval_if.hpp(40) : fatal error C1204: compiler limit : internal structure overflow Any suggestions? I can try increasing the stack size of my current application to eliminate the xml runtime stack overflow problem, but I am uneasy doing this until I understand how to calculate the stack sizes required, and why it is happening. Furthermore, I would prefer using the text archives, since the data is more compact than the xml ones. Ed Reusser Principal Software Engineer Actel Corporation (408) 318-4972 ________________________________ The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information. ________________________________ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information.

2 1

[Boost.Test} exit codes
by Christoph 13 Nov '06

13 Nov '06

Hi, I am experimenting with the Boost.Test framework. I have stumbled upon the exit code of the test program. I have not found the documentation on the exit code (maybe I have overlooked it) and am somewhat baffled how to interpret it: i) what is the semantic of the exit code? It seems to be 0 when all tests are passed (as expected), but I get 201 if some tests fail. What does 201 mean? Are there further possibilities? ii) is it possible have the exit code return the number of failed test cases? Thank you Christoph

2 1

[enable_if][type_traits] Overload resolution question
by Michael Marcin 13 Nov '06

13 Nov '06

Hello, I have a fixed point math class and I want to enable some optimized operator overloads. for instance: fixed& fixed::operator /= ( const fixed &rhs ); fixed& fixed::operator /= ( int n ); it seems however to me that what I really want is an overload like: template< typename T > fixed& operator /= ( typename boost::enable_if<boost::is_integral<T>,T>::type n ); However I can't seem to get that function considered for overload resolution instead it goes through the following constructor and calls the /= that takes a const fixed &. template< typename T > fixed::fixed( T n, typename boost::enable_if< boost::is_integral<T> >::type* = 0 ); Speaking of which I don't understand why the following doesn't work in place of the previous constructor. template< typename T > fixed::fixed( typename boost::enable_if< boost::is_integral<T>,T>::type n ); Finally I'm using this class to replace a lot of hardcoded / macro logic and often as an optimization the code uses binary shifts to represent power of 2 multiply/divides. Going forward these divides need to work with both fixed and floating point types so f >> 1 needs to change to f / 2. Is it possible to create an overload for the / and * operators that determine if the operand is an integral constant and is a power of 2 and use a binary shift internally? Thanks, Michael Marcin

3 5

Re: [Boost-users] [Serialization] unexpected assert registeringclasses
by Reusser, Edward 13 Nov '06

13 Nov '06

Robert, Thanks for the quick response. I have ensured that the serialization for each type is located in exactly one place. The header files where the serialization code resides for the derived classes are not global, that is, our build system is set up to ensure that no other library or DLL can reference them. I believe that I can make the serialization completely independent and contained inside the DLL without much difficulty. However, unless I statically link the serialization library, I don't think I can prevent the macro: BOOST_CLASS_EXPORT_GUID( class, "ClassNameText" ) from initializing the global table inside the serialization DLL (which is dynamically linked). I noticed that when I tried to use the other registration technique you describe, register_type<T>(), this also calls the registration code in the serialization DLL on load, so that doesn't solve the problem. It doesn't seem very practical to serializing in/out a prototype of each derived class into the archive initially because it would increase the archive size by a lot. Too bad there isn't a mechanism for creating a registration table specific to the DLL where the classes are serialized. If the global table was of the following structure: using namespace std; map< HMODULE, map<string, ETI*> >; Then the above macro would simply use AfxGetInstanceHandle (in the case of windows, I am unsure what the corresponding calls in other OS's would be), to pass the HMODULE handle. Ed -----Original Message----- From: Robert Ramey [mailto:ramey@rrsd.com] Sent: Monday, November 13, 2006 8:24 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Serialization] unexpected assert registeringclasses Having serialization code in DLLS has raised some stick issues. The basic problem is the existence of a global table of information about types being serialized. Among other thngs, this global type table contains the export string name (GUID) that is shared among programs to identify the type. This table also points to functions via a virtual function mechnamism to implementations required by serialization. Entries are added to this table when code is loaded and deleted when code is unloaded. in version 1.33 I included the indicated assert - as it seemed to me that this must be unique. I was concerned that multiple entries in the table might point to different function implementations - as indeed they will. So I included this assertion. This started to create problems as you have found. Also I've now come to thnk that the having multiple entries for the same type is harmless - and difficult to avoid in the presence of dynamically loaded/unloaded DLLS. So in 1.34 - I commmented out the assertion. In addition, I've augmented the code to make sure that the correct entry in the table is deleted when the corresponding DLL is unloaded. So I believe that starting in 1.34 this problem will be resolved. I really don't know for sure because its very hard to come up with a good test for this. So, I think this problem is addressed. But in the face of dynamically loaded DLLs - which are not all guarenteed to be in sync ( some could have older versions of code), I think that the best policy would be to be sure that serialzation code for a particular type should be found in one and only one place. Also, doing this will result in smaller DLLS and applications. Doing this requires that one explicitly orgranize his code so to achieve this. This means avoiding instantiation of serialization code in applications and by explicitly instantiation such code in the DLLS. The closest guide I have for doing this is demo_pimpl which shows how to do this. Robert Ramey "Reusser, Edward" <Edward.Reusser(a)actel.com> wrote in message news:5E916BAE1732F344BAFD713DF2373479016EA054@SV-MSG-01.amer.actel.com.. . I am using the boost 1.33.1 distribution, and the xml_iarchive and xml_oachive to serialize a rather deep and complex data structure to xml. I am using make_nvp directly in all cases (not the macro). I am sometimes getting the following assert (line 71 in extended_type_info.cpp) when I load previously serialized data: assert( lookup(eti) == m_self->m_map.end() ); It seems obvious that what is happening is that somehow I am calling self_register more than once for a specific class. Tracing through the code however I am puzzled exactly how this could happen, since the registration should only happen once when the libraries are loaded. This never happens on save by the way, only on load. It also never happens if I do the save, followed by a load immediately. It only happens if I do the save, shut down the application, then load the data. I have verified that the loaded data is a bit by bit equivalent in both cases. The best that I can come up with is that I am loading the serialization library as a side effect of calling LoadLibrary at runtime. So I am linking in the serialization library after everything else has been loaded and is running. But again, none of the libraries are ever unloaded, and the load sequence should always be the same. The actual situation is that I have a library . call it Library A, which is linked to libraries B, and C. The library A is being linked using the LoadLibrary call, each of libraries B are C are linked to the boost serialization library. In each of libraries B, and C, I have used the macro: BOOST_CLASS_EXPORT_GUID( class, "ClassNameText" ) To define all of my classes I am serializing, including all classes that I am serializing using shared_ptr's. I was thinking originally that the problems were all shared_ptr's of classes that are derived from enable_shared_from_this<T>, but I am no longer confident that has anything to do with it. In fact, truth be told, I have no idea if any of the above has anything to do with the problem. When I commented out the assertion, everything seems to work just fine, except now I am getting a stack overflow on very complex hierarchies in the spirit parser (again, load only), but the simpler ones seem to work repeatedly without any problems. I have no doubt that the assertion was added there for a reason, so I hate to comment it out without finding out what else I might have broken. Edward Reusser Principal Engineer Actel Corporation (650) 318-4972 The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

[Serialization] a coupla crashes from hiearchy complexity
by Reusser, Edward 13 Nov '06

13 Nov '06

I am using the serialization library in boost 1.33.1. I am compiling on windows using the VC 7.1 compiler. The problem I am having is that when I use xml_iarchive and xml_oarchive, everything works just fine for simple cases, but if the xml gets very deep ( same exact class hierarchy, just more data organized a little more complexly) I am getting runtime stack overflow crashes in the spirit parser. I figured I could solve that by simply substituting text_iarchive and text_oarchive. Please note that I am simply substituting in these archive types instead of using the xml archive headers, which work. There are no other code changes anywhere. Now I am getting the following compiler error: \boost\mpl\eval_if.hpp(40) : fatal error C1204: compiler limit : internal structure overflow Any suggestions? I can try increasing the stack size of my current application to eliminate the xml runtime stack overflow problem, but I am uneasy doing this until I understand how to calculate the stack sizes required, and why it is happening. Furthermore, I would prefer using the text archives, since the data is more compact than the xml ones. Ed Reusser Principal Software Engineer Actel Corporation (408) 318-4972 The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information.

2 1

[Serialization] unexpected assert registering classes
by Reusser, Edward 13 Nov '06

13 Nov '06

I am using the boost 1.33.1 distribution, and the xml_iarchive and xml_oachive to serialize a rather deep and complex data structure to xml. I am using make_nvp directly in all cases (not the macro). I am sometimes getting the following assert (line 71 in extended_type_info.cpp) when I load previously serialized data: assert( lookup(eti) == m_self->m_map.end() ); It seems obvious that what is happening is that somehow I am calling self_register more than once for a specific class. Tracing through the code however I am puzzled exactly how this could happen, since the registration should only happen once when the libraries are loaded. This never happens on save by the way, only on load. It also never happens if I do the save, followed by a load immediately. It only happens if I do the save, shut down the application, then load the data. I have verified that the loaded data is a bit by bit equivalent in both cases. The best that I can come up with is that I am loading the serialization library as a side effect of calling LoadLibrary at runtime. So I am linking in the serialization library after everything else has been loaded and is running. But again, none of the libraries are ever unloaded, and the load sequence should always be the same. The actual situation is that I have a library ... call it Library A, which is linked to libraries B, and C. The library A is being linked using the LoadLibrary call, each of libraries B are C are linked to the boost serialization library. In each of libraries B, and C, I have used the macro: BOOST_CLASS_EXPORT_GUID( class, "ClassNameText" ) To define all of my classes I am serializing, including all classes that I am serializing using shared_ptr's. I was thinking originally that the problems were all shared_ptr's of classes that are derived from enable_shared_from_this<T>, but I am no longer confident that has anything to do with it. In fact, truth be told, I have no idea if any of the above has anything to do with the problem. When I commented out the assertion, everything seems to work just fine, except now I am getting a stack overflow on very complex hierarchies in the spirit parser (again, load only), but the simpler ones seem to work repeatedly without any problems. I have no doubt that the assertion was added there for a reason, so I hate to comment it out without finding out what else I might have broken... Edward Reusser Principal Engineer Actel Corporation (650) 318-4972 The information contained in or attached to this email may be subject to the Export Administration Regulations (EAR), administered by the U.S. Department of Commerce, or the International Traffic in Arms Regulations (ITAR), administered by the U.S. Department of State, and may require an export license from the Commerce or State Department prior to its export. An export can include a release or disclosure to a foreign national inside or outside the United States. Include this notice with any reproduced portion of this information.

2 1