Spam detection software, running on the system "mail.Millennium.Berkeley.EDU", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details.
Content preview: Unfortunately in the module TUnitP the provided interfaces setUp, and tearDown have the restriction @atmostonce(), which lead to overwiring warnings during compilation, if one has multiple components like the example TestStateC inhttp://docs.tinyos.net/index.php/State_Interface_Test. It is sometimes desirable to encapsulate multiple components in one testsuite, and have a separate setUp and tearDown implementation for every component. Although the setUp events are called whenever any testcase in any component is about to run, this doesn't really matter. The only alternative would be to let each module run in a separate testsuite on the node, which often is the right choice, but not necessarily always. You could also remove the restriction from setUpOnce and tearDownOnce, although that might lead to confusion, since those are not called once per module, but once for the whole testsuite. [...] Content analysis details: (3.9 points, 3.3 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.2 FH_DATE_PAST_20XX The date is grossly in the future. -0.2 BAYES_40 BODY: Bayesian spam probability is 20 to 40% [score: 0.3725] 1.1 DNS_FROM_OPENWHOIS RBL: Envelope sender listed in bl.open-whois.org. -0.2 AWL AWL: From: address is in the auto white-list
--- Begin Message ---Unfortunately in the module TUnitP the provided interfaces setUp, and tearDown have the restriction @atmostonce(), which lead to overwiring warnings during compilation, if one has multiple components like the example TestStateC inhttp://docs.tinyos.net/index.php/State_Interface_Test. It is sometimes desirable to encapsulate multiple components in one testsuite, and have a separate setUp and tearDown implementation for every component. Although the setUp events are called whenever any testcase in any component is about to run, this doesn't really matter. The only alternative would be to let each module run in a separate testsuite on the node, which often is the right choice, but not necessarily always. You could also remove the restriction from setUpOnce and tearDownOnce, although that might lead to confusion, since those are not called once per module, but once for the whole testsuite.
--- End Message ---
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
