Legal & Policies
Kill
SpyWare/AdWare
(FREE Scan!)
Differences between Yanoff+ and Yanoff-
Extra Features for Registered Users
Good Net-Keeping Seal of Approval
Extra Features for Registered Users
Good Net-Keeping Seal of Approval
Good Net-Keeping Seal of Approval
Compatibility with Java Conduit
Can I use Yanoff if I don't have a Palm Modem or a PalmPhone?
Java Conduit problems with my Treo 650, T5, E2 or LifeDrive
Why won't any articles download?
Why won't the Conduit download any articles?
Why does the Conduit disable my threading preferences?
Manipulating server polling order
How can I visit a URL referenced in an article?
Delete Command skips some articles
Missing or Impossibly Read/Marked/Locked Articles
Automatic Quoted-Printable Decoding Failures
Manipulating server polling order
Missing/Garbage message bodies when posting
Tungsten 3 (T3) display problems
Java Conduit problems with my Treo 650, T5, E2 or LifeDrive
Frequent crashes during polling
Why won't any articles download?
Why won't the Conduit download any articles?
Why does the Conduit disable my threading preferences?
Missing/Garbage message bodies when posting
Losing Memory (NewsHisotry.pdb is huge)
Delete Command skips some articles
Missing or Impossibly Read/Marked/Locked Articles
Problems with Memos at HotSync
Throughout New Yanoff and its documentation we use the following conventions: "Yanoff" refers to all versions of Yanoff, "GPL Yanoff" refers to the original open-source Yanoff, "Yanoff-" refers to the totally demoware (free) version of the private-branch (our) Yanoff, "Yanoff+" refers to the trialware (pay-to-keep) version of the private-branch (our) Yanoff, and "New Yanoff" refers to both "Yanoff-" and "Yanoff+", "article" refers to a Usenet/NNTP message, "email" refers to an email/SMTP message, "message" is generic including both/either NNTP and/or SMTP messages, the word is "Newsgroup" is usually abbreviated as "NG" and "Message-ID" as "MID".
A: Yanoff+ will only allow the advanced features to work for 15 days. After this trial period, it disables them and reverts to the same feature set as exists in Yanoff-. You may either continue to use Yanoff+ as-is (although it is better to downgrade to Yanoff- if that's your decision because it has the same features but smaller size) or register Yanoff+ to unlock the lost features (and also enable a few super-advanced features that are only available to registered users).
A: The Purchase Page explains everything. Basically, you send the registration fee to us via PayPal or US$ Money Order along with the delivery email address and the user's HotSync ID. Within 24 hours of the payment clearing, we will email to you a file which, when installed on the designated PDA, registers the payment and unlocks the advanced features.
A: Probably your HotSync
ID is different and you need to change it back to what it was when you
bought your license. The programs, databases and settings for a handheld are
stored in a "HotSync profile" on the host PC. When a user switches
to a new handheld (or has serious problems with his current handheld), it's a
very good idea to create a new profile so that HotSync Manager won't install
old, incompatible programs and settings onto the new (or reset) device. But
since the New Yanoff registration code is based on the HotSync ID that you provided when you purchased
the software, changing your HotSync ID means
that your code will no longer work. Fortunately, your HotSync ID is simply a label associated with a
HotSync profile, so it's simple and safe to reassign your old/original HotSync ID to your new profile. You can do this
either before or after setting up your new handheld.
If you haven't yet set up your new handheld, rename your old device's HotSync
profile and give it a new HotSync ID. Then when
you set up your new handheld, assign it the old HotSync
ID. A new profile will be created. If you have already set up your new
device and given it a new HotSync ID, you can
easily reassign your old HotSync ID to the new
HotSync profile. In either case, here is how to do it:
A: Yes, we do offer a secure 3rd-party, encrypted, real-time fulfillment option for Credit Card purchases called "Pocket Purchase" and it is completely safe so long as you trust the end-service provider (we do). However we would much rather you order directly from the web pages because there are hefty surcharges to us (both in the form of CC fees and in the form of 3rd party service fees) that take a substantial bite out of our margin (the price to you is the same for any order method). We provide this facility as a courtesy to our users who REALLY want to buy RIGHT NOW! If you can wait a day or so, please do order directly from the web pages as it really helps our bottom line when you do so.
A: The problem is not with New Yanoff
but rather with your T3. In order for 3rd party programs to take advantage of
the extended screen of the T3, two files need to be installed onto your PDA:
AppSlipRotate.prc and StatusBarLib.prc. These files were given to us by Palm
because development on this piece of the Operating System was not finished
before the T3 was shipped. Once these two files are installed, all
applications that support the T3's wide/full screen mode will be able to take
advantage of the Tungsten's 320x480 screen display.
WARNING:These files are for the T3
only
WARNING: You must
install both PRCs at the
same time;
installing them separately may force a hard reset!
The link below is a zip file that includes the two missing files:
http://www.PalmYanoff.com/download/T3_DIA_Compatibility_prcs.zip
A: All versions of Yanoff do nothing secretly; they only send email/articles when YOU tell it to and only add (with the exception of some mundane headers generated at transfer time) the text you give it. Everything the use and do is available for you to see. While Yanoff has NO SpyWare, Yanoff+ does have limited "push" ability provided by Pocket Purchase through its conduit by which we can update the "nag" popups that are displayed when unregistered users launch Yanoff+. This option is selectable during installation so if you don't want to allow these updates, you can prevent them from being transmitted to your PDA. Be aware that the primary purpose of such updates is to notify users of temporary discounts (e.g. "Buy a license by the end of tomorrow and receive a 20% discount" or some such). Our Privacy Statement is available on our Legal Notices & Policies Page.
A: Before you take the dramatic step of removing Pocket Purchase, be aware that:
Pocket Purchase only adds about 1 second to your HotSync duration.
PocketPurchase.prc only uses about 80K of memory on your PDA.
PocketPurchase.prc and the conduit are required to receive product discount "nag" updates from the PocketPurchase server.
The initial 2.0 release of Yanoff+ required PocketPurchase.prc to decrypt the license keys but this is no longer the case. The folks at Pocket Purchase worked quickly with us to create an update that allows any user to remove Pocket Purchase at any time and still use Yanoff+ including validating the license key. The only things that are lost if Pocket Purchase is disabled are the convenience features Pocket Purchase provides ("nag" screen updates, real-time credit card validation, etc.) There are several ways to disable or remove Pocket Purchase. The simplest is to use the launcher or your favorite PDA file utility to delete 'PocketPurchase.prc' from your PDA. If 'PocketPurchase.prc' is not present, the conduit sits idle and does nothing. If you further wish to uninstall the conduit, the simplest way is to run the Yanoff+ uninstaller. This does 2 things: it removes the Pocket Purchase conduit and it removes the Yanoff+ documentation (all of which is duplicated on the web at http://www.PalmYanoff.com anyway). If you'd like to keep the documentation on your PC and wish to manually uninstall the conduit, then locate these files in your palm directory on your PC and delete them:
PocketPurchaseConduit.dll
PalmOSUplinkClientStub.dll
PalmOSUplinkClientDLL-xxxxxxxx.dll
Power users may also want to remove the few registry entries that Pocket Purchase installs but really there is no need (and this can be quite dangerous if one does not know what one is doing).
A: There are 39 as follows:
A: There are 3 as follows:
A: Because of a necessary change to the NewsArts.pdb data structure, for now, no. However at some point in the near future, we will submit a code change to GPL Yanoff so that it can understand both versions of the articles and then backwards compatibility will be restored. Of course, there are many new things that New Yanoff does that GPL Yanoff doesn't know about and therefore can't understand (e.g. killfiles). Besides this change, though, most everything is saved in the same spot and in the same format for both versions so none of the new things should break anything in GPL Yanoff. The only exception is some of the trivial preference data (mostly booleans) moved around a little bit so all the preference settings should be verified when moving back and forth. Most likely we will submit those changes to GPL Yanoff soon, too. We wish to be as compatible with GPL Yanoff as possible and to live in cross-compatible harmony!
A: There is 100% backwards compatibility with the Java Conduit but there is 1 "gotcha" which you need to beware! Other than this, the Java Conduit works exactly as it does with GPL Yanoff. Obviously, though, it is ignorant of the new preferences and the features they control so it cannot respond to the added functionality the way the online polling code does. If interest and demand are high, we plan to update the Java Conduit so that it comprehends and obeys the new preferences.
A: If your PDA has Wi-Fi and you have a Wireless router you should be able to directly access your home internet connection to download. If you PDA has bluetooth and you are running at least Windows 98 SE, you should be able to setup Internet Connection Sharing to access your host PCs internet connection to download. But even if you have neither of those options, the Java Conduit allows any user to download articles on a host Windows PC and then transfer them to the Palm during HotSync. This allows people with "un-wired" PDAs to still use Yanoff! The Java Conduit has not been updated so it doesn't understand the new features we have added but it still works just fine so long as you keep "Conduit" checkmarked in "Poll Preferences". We will be updating the conduit in the very near future as well but for now, just use the original version which can be found here and be sure to subscribe to our email list so that you will be notified when we release the updated conduit.
A: Believe it or not, PalmSource did not initially support Java conduits
in the earliest (6.0.1 and 6.0.2) versions of the HotSync Manager!
It took half a year since I first reported it to them but
they finally released a patch. You need this patch if you are using a
version 6.* HotSync Manager released before September 2005:
http://www.PalmYanoff.com/download/Sync20dll.zip
Read the release announcement of the patch here:
http://news.palmos.com/read/messages?id=193748
You can read the entire original thread here:
http://news.palmos.com/read/messages?id=184939
This oversight effected ALL Java-based conduits, not just ours.
The patch re-adds support for JSync (Java) conduits and contains
a single file (Sync20.DLL) that replaces the defective original
that was shipped with HotSync Manager 6.0.1 and 6.0.2.
WARNING: INSTALING THIS FILE FOR ANY OTHER HOTSYNC MANAGER VERSION (i.e. 4.*)
WILL CAUSE ALL CONDUITS (not just JSync) TO FAIL!
A: You are probably using the gmane default news server ("news.gmane.org") for non-gmane NGs. If so you should be getting "Group unknown: <name>" errors when you try to poll them. This server does not carry any "regular" Usenet NGs (but the groups it does carry are a very interesting and highly unique bunch). This is because gmane's primary purpose is to convert email lists to Usenet NGs. For example, the default "gmane.comp.handhelds.palm.yanoff" NG is populated by an email feed from the "Yanoff" Yahoo Group! All NGs carried by gmane begin with "gmane.". Subscribe to "regular" NGs using the other ("news.readfreenews.com") default news server or one that you add which you know carries the NG you desire. If you have already verified this and are still having problems, then also check to make sure each of these is true:
A: You must be using 2.*; upgrade to the latest version. Because we have not yet updated the conduit, it did not understand the "Unpolled" selection for "Poll" the way we encoded this option in 2.* releases (this was fixed for 3.0, though). If for some reason you can't or won't upgrade, use "Next 999" instead and it will work essentially the same way. Using anything other than "Unpolled" will work with the conduit as one would expect. Other options which the conduit will not understand (even with the latest release) until it is updated include: MIME handling, the killfile, the new trimming options, "Multi-Index" value of "false" and the "Abort" Poll Prefs, the "Max" NG Pref settings, and the "Lost" and "Sent" boxes. Sometimes the conduit may be confused by values of '0' for the NG Prefs settings "lines/article", and "NGs/article". So if all else fails, make sure these both are non-0 for each NG.
A: This answer is similar to the previous; the conduit does not understand the new threading (cache) options but it goes deeper than that. The PC-side software employs a perfect-as-is-possible threading algorithm because the PC has essentially limitless RAM and CPU that makes this computationally and memory intensive perfection a sensible (not too time-consuming) proposition. Also, the conduit was not written to use the NG Prefs threading options and uses its own separate configuration. This can be accessed as follows: from Palm Desktop, select "Custom" from the "HotSync" menu. In the dialog that opens, select "Yanoff" from the list and tap on the "Change" button. Set threading with the "Allow threading by conduit" checkbox. Other options include "Skip Yanoff Synchronization", "Sync Only once a day", and "Purge MsgIDs". Because the articles will all arrive "pre-threaded", the conduit turns off the threading option for each NG. When New Yanoff notices that the article DB has been externally modified (by use of the Conduit or any other action) it deletes all the thread caches because they are, by definition, corrupt. A thread cache is only useful if it is 100% perfect; it must know certain specific things about each article threaded in the NG. If even 1 article is added or deleted without updating the cache accordingly, the cache is irrecoverably corrupted and will be destroyed (both to save memory and to provide the option to recreate if the need should arise). Starting with version 3.0, New Yanoff will prompt you how to set the thread caching option when you change the "Conduit" Poll Pref from on to off.
A: In the upcoming 4.0 release, users will be able to tap on a URL (or highlight the URL text and use a ButtonAction™) to launch a Palm Browser. The essential mechanics for this feature are present in the 3.2 release that provides a good preview of how the feature will work. However, the actual launch functionality is not present so for now you must settle for something less direct. First, properly configure your mail server so that you can send emails. Then set one of your ButtonActions™ to be the "Forward w/ quote" action. When you find an article of interest (such as something with a URL), forward it to yourself (the default "To:" is your own email address). The entire operation takes just 2 button presses to complete! Then, after your next poll, you will receive this email on your PC and you should be able to click on the link and access the site. Obviously, this basic method is useful for other things than just URL browsing!
A: No. Maybe it will in a future release; let us know what missing features are important to you. If this missing function is essential, we would be happy to move your feature request to the top of our to-do list and implement it immediately if you would care to pay our standard consulting rate. Otherwise, please register and contribute to the success of the current release as this will ensure future updates will continue to be produced. In any case, please do send us your ideas for improvements and we'll do our best to eventually implement the ones that make good sense.
A: The "Network Svc" preference does nothing at all; at some point in a future release, we intend to support the association of a particular server to a particular network "Service" (as defined on the "Network" OS preferences). The "Type" preference is functional but the server defined at position 0 (i.e. the first server defined) must always be a mail server. In the latest versions, this preference has been removed.
A: You must be using the Java Conduit. If so, you need to checkmark the "Conduit" box in the "Poll Prefs". If interest and demand are high, we plan to update the Java Conduit so this won't be necessary.
A: Here are what most (not a complete list) of the actions do:
A: Now it is required that you highlight the text you wish to include. Just select the portion you want before you hit the button and the selected text will be used to seed your response.
A: Screen space is a scarce resource for PDAs. By contracting each header label to a single character (or 2) each, we are able to fit the vast majority of dates, email addresses, NG names and Message-IDs on a single line. Many times, this allows the header to fit on 1 screen.
The abbreviations and the order in which they will appear are:
All other incoming headers are discarded by Yanoff (although there will be options to save them in a future release). If the "D:" appears as "d:" this indicates that it is the creation date of a user-created message that has not yet been transmitted. Once it is sent, the "d:" becomes a "D:" and the date displayed is the transfer date of the message (this, of course, is only noticeable if the "Sent box" Poll Preference is used; otherwise messages are deleted immediately following transmission).
A: The first number is the position of the message's reference in the NG database. The second number is the NG database entry's unique ID. The third number is the position of the message in the article database. The fourth number is the article database entry's unique ID. The fifth number is the message's multi-index count. The sixth/last number is the message's server number (to where it will be posted or from where it was polled). The symbol before the 5th number (multi-index count) is either a vertical bar (|) which indicates the message is stored in the "new" format or a colon (:) which indicates it is stored in the "old" format. The old database format used a single position for the "Reply-To:" and "Followup-To:" headers. If the message was user-created, it was to be interpreted as "Reply-To:"; if the message was a polled article, it was to be interpreted as "Followup-To:". This is a very poor compromise because it is valid for any message to have both headers so one is always lost. The new format adds an extra field so each header has it's own space and both can exist at the same time.
A: There are 3 flags. The left flag is a centered dot indicating the message is marked. The middle flag has a top and bottom indicator. The top indicator is an apostrophe (') indicating the message is locked. The bottom indicator is a period (.) indicating either that the message has been read (if it is a polled article) or that the message has been sent (if it is user-created). These appear as an exclamation point (!) if both are true. The right flag is either a vertical bar (|) indicating a "genuine" message body exists or a centered dot indicating it does not. Non-body messages may show some text (indicating article polling errors or other article-specific information) in the body-view but such messages (without "genuine" bodies) will not show the '|' flag.
A: No; the bottom edge would show if we removed one of the divider lines but we feel the divider lines are more important than the bottom edge of the menu.
A: There were a couple of incidents during beta testing when the "Log Prefs" data became corrupted and caused New Yanoff to crash whenever it hit a "Log" command in the code (i.e. constantly) or the user tried to edit the "Logging Prefs". We never did figure out what caused the corruption so we added this menu item as a fallback plan in case anyone else runs into this problem. We do not intend for any users to ever use this command so we like it that it is hard to see and access.
A: The Palm OS needs special programming to properly handle extended (anything other than standard US Latin) ASCII characters and this was not done at the initial creation of the app. Unfortunately, it is a very laborious process to redesign the app to work properly (but eventually this will be done). In the mean time, any trim function executed on an article with these extended (multi-byte) ASCII characters will result in a crash (including manual post-poll trimming). The solution is to turn off all trimming options on "Poll Prefs".
A: You are polling online (not using the conduit) and you have not been regularly purging your MIDs with the "Purge Old MIDs" function. This should be done regularly (at least once a week) to reclaim memory by deleting entries that are no longer useful. See the Crossposting Section of the User Manual for more details.
A: This is a temporary, truncated, shorthand "Xref" header (the actual "Xref" header is not stored). Whenever a head is downloaded (articles are downloaded in 2 parts; first the head, then the body), a context is saved in the article's body. The first number (the "1" in this case) indicates which NG in the article's "Newsgroup:" header is the NG where this header was downloaded. The second number is the article's position/number within that NG (local to a specific NG on a specific server; different servers and even different NGs will have different numbers for the same Message-ID). This information is important because it allows us an additional option to specify the article's body. It can be specified either by Message-ID (global context) or by group+number (server-local context). Sometimes one will work but not the other; we need to be able to try both ways. Note that articles of this type do not have the "body present" flag indicator described above because this text is not a "genuine" body.
A: Yanoff will only attempt to obtain articles within the range the server has specified is valid. However it is very common for servers to be missing some articles within this range (they were canceled, corrupted, whatever). Those 2 errors are returned when an article (header or body) is requested but no longer exists. Most of the time, the header does exist but the body does not. The problem with MOST newsreaders is that they don't report the "missing" articles and so the user has no idea the situation exists. New Yanoff allows the user to see the header even if the body cannot be retrieved. This follows our "power to the user" paradigm in that the user is notified of articles which he has missed which empowers him to attempt retrieval via other means (i.e. Google, etc.). With the header, one has both a reasonable idea as to the content of the missing body and also the unique Message-ID to assist in alternative retrieval.
A: Because they were locked. The lock flag has a higher precedence than any operation or other flag. Locked messages can only be deleted if they are first unlocked. The "Mark All", "Unmark All", "Flip Marking", "Unlock Marked" and "Lock Marked" functions work well together to easily manipulate locked articles.
A: As with GPL Yanoff, each single article may exist in more than one NG. The "Multi Index" Poll Preference controls whether an article that was crossposted to multiple subscribed NGs shows up in just the first NG in your list or in all of them. If you are subscribed to 2 NGs in an article's header, and the article is indexed into both NGs, then when it is read (or marked or locked) in the first NG, all changes will be reflected when you run across it in the other NG because both NGs point to the same (shared) article in the article database. Most users find this an annoying waste of time so they will want to uncheck the "Multi Index" Poll Preference. When unchecked, crossposted articles will only be indexed into one subscribed NG: whichever one is highest on the main screen. This option is also more efficient for RAM because articles which are "deleted" in one NG yet which are also indexed in another NG are not deleted; they merely have the NG reference deleted, and reduce the mutli-index count of the article itself. An article will not be deleted from the article database until its multi-index count is 0 (i.e. until all NG references to it are deleted). Unchecking "Multi Index" ensures that every article's multi-index count is never more than '1' and when any reference to an article is deleted in a NG, the article is always deleted at that same time.
A: If you poll online (sorry conduit users), go into the truncated article and do a "Re/Poll body" from under the "Mgmt" menu. When bodies are manually repolled, no automatic trimming or truncating is done and the maximum article size (32K) is used (overriding the "Max" setting in "NG Prefs").
A: There are plenty of natural occurrences of strings that appear to be encodings but are not (e.g. cgi parameters such as in eBay URLs). So while it is true that "Trim MIME" will both trim non-text MIME stanzas and decode the quoted-printables, the latter is only done if it can be conclusively determined an encoding is present. This is done by checking for the "Content-Transfer-Encoding: quoted-printable" header. If this header is not found, no automatic decoding is done. The manual operation assumes you know what you are doing and will happily mangle eBay URLs or anything else that fits the format of "=##".
A: Remember the explanation about the 2 ways to specify an article earlier? The failure to repoll the article is almost certainly because your news server requires the group+number specification and does not respond properly to the MID specification. The problem is that when the article was first polled, the incoming body permanently destroyed the (temporary) encoded group+number that was stored there. You are out of luck.
A: If you have a value greater than 4KB for "Memo max" on "Logging Prefs" then you will have problems with MemoPad HotSyncing once any of New Yanoff's logfiles grows to greater than 4KB. In general, this setting should be left as 4KB for this reason.
A: YES! Just send an email from the Contacts Page with your name and HotSync ID and we will verify your registration in our records and resend the key to you. This may take a couple of days. If you are using PocketPurchase, though, this can never happen because once you reinstall the yanoff.prc and PocketPurchase.prc, the conduit restores the key automatically.
A: At this time, it is our policy that when you pay for a license key, that is exactly what you are doing. If you need a different license key (because you changed your HotSync ID or for any other reason), then you must pay for another (different) one. We are sure everyone can appreciate the reason for this policy as it protects us from people "sharing" their license keys when the sharee should be paying for his own. Because license keys are based on the HotSync ID of your device and because users may change their HotSync ID, we will soon provide instructions on our web page for how to change your HotSync ID back to what it used to be which will re-validate your original, existing license key.
A: Although there is no direct facility to rearrange the servers like there is to rearrange the NGs, a manual process can be used as follows: go into Server Prefs and copy each Server in the order you want them to be polled. So if they are A-B-C-D and you want them to be D-B-C-A then select D and tap the "Copy" button, select B and tap the "Copy" button, then C, then A the same way. Next go into NG prefs for each NG and select the SECOND (duplicated) instance of the server for the "From:" preference and save the modified settings. Lastly, go back to Server Prefs and delete the FIRST (original) instance of each server (make sure this step is last, after the changes to NG prefs, or NG articles will be deleted). A slight variation of this idea allows for splitting up the polling of NGs within a server. For example, if you have NGs A and B on server 1 and C and D on server 2 but you want to poll them in the order A-C-D-B then you would do these steps: rearrange the NGs so they appear in the NG list screen in the desired order. Next, go into Server Prefs and copy server 1. Lastly, go into NG prefs for X and set the "From:" preference to the new (duplicated) server.
A: Most of us use these (top-to-bottom as listed in the ButtonAction™ screen):
| NG list (main) | Article list (NG) screen | Article screen |
|---|---|---|
| Re/Index articles | Exit+DelOnUp!Lck | Exit |
| Enter NG | Enter article | Next article |
| PageUp+Wrap | PgUp+Jump | Kill (read) subject (Occasionally: Decode "=##" tags) |
| PageDown+Wrap | PgDn+Jump | Un/Lock |
| LineUp+Wrap | LnUp+DelRead+Jmp | PgUp+Next art |
| LineDown+Wrap | LnDown+DelRead+Jmp | PgDn+Next art |
| Purge old MIDs | Goto 1st unread | Followup |
| Poll | Goto first<->last | Reply |
| Goto first<->last | Delete all unlocked | [N/A] |
| --- | ||
Most are obvious but a few are subtle. On the NG screen, I do not have any delete on the PgUp/Dn buttons because I like to be able to "Jump" to another NG either with or without deleting. Since PgUp/Dn is the same as LnUp/Dn when near the end of a list (i.e. first/last page), I use the "Pg" buttons to Jump without deleting or the "Ln" buttons to jump with deleting. I like to be able to initiate a manual DelUnLocked at the press of a button (or 2); that's why I have Exit+DelOnUp!Lck. When reading an article I'll decide I'm done for now so I push Calendar twice (Exit, Exit+DelOnUp!Lck) which is a quick way to initiate a DelOnUp!Lck for the NG. Then, if I want to go back to reading, I push Phone twice (Enter, Enter) and I'm back to reading where I left off and I never had to look at the PDA or tap the screen. I always read from top-to-bottom and hardly ever skip any articles so I have "Bip After" set for "Art del". This is to exploit the fact that most Del (and all DelOnUp) functions begin low and work their way back/up: when it stops beeping, I cancel the operation (no need to let it search for unlocked or read articles which I know aren't there). If I didn't read the way I do, though, this wouldn't be a useful shortcut.
A: Officially, no, because we have not yet been independently validated. However unofficially, YES! We hope shortly to be verified and will update our web pages with the seal when this occurs!
A: Those do the same thing and should only be accessible in test versions of the software. They set an internal flag that dumps out extra programmer-interpretable-only data used by us while we are programming. It allows us to dump out internal values of various things to track down bugs.
Copyright 1999-2005 by SonLight Software and Gregg E. Woodcock
