Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

Issue 11    October 4, 2000 October 7 & 8, 2000 BeGeistert 005 event will take place Oct. 7-8 in Düsseldorf Sept., 22, 2000 BIAS Initiates Development of Deck for BeOS return to top Plus çà change... by Jean-Louis Gassée, CEO and Chairman The rest of the English expression amounts to a shrug, a Gallic one perhaps -- things never really change, same old stories keep going around. When it comes to this emerging class of connected devices, Internet Appliances, it is natural to start from the known in exploring the unfamiliar. And, once ensconced in the comfort of familiar frames of reference, why not recycle the old stories? There are enough to go around -- just pick the ones that suit your line. It's yet another avatar of Larry's old NC tales, what Microsoft and Intel have been advocating, the Simple PC, the NetPC, the Zero Administration PC. Yes, we've been promised simple PCs that would just work for a while, and it's tempting to see Net Appliances as the deliverable -- or the deliverance. Or there's Sun's karmic effort to sell the network as the computer, open systems, X-Windows terminals, Java Stations. So, yes, looking at these and a few others better forgotten, no wonder skeptics and older males contend that things never change. We keep hearing these stories, but the only connected device of any substance is the PC. Everything else is a bunch of recycled old tales with one thing in common: PC envy. Perhaps. One look at the facts might point at one important difference, the glare, the magnifying glass, the size, ego or otherwise, of people and entities involved, the magnitude of financial bets of several kinds. When PCs got started, they were made by geeks for geeks. No investment bankers involved, Microsoft was the Bill Gates on a New Mexico DMV picture and the players were Ohio Scientific, Cromemco, MITS, Altos, and Commodore. Apple, IBM, and Compaq hadn't entered the scene yet. No industry conferences. One pulp rag, Creative Computing, one magazine with software on a flexible 45 rpm record insert, Byte. How much geekier can you get? I could go on, but I'm probably belaboring the point already. Chances are slim that history will repeat itself. Because with appliances, the more things change, the more they keep changing. For one thing, we don't know yet where the leaders will come from: the PC industry, the consumer electronics industry, makers of PDAs, classical phone companies, huge ISPs, smaller ISPs, or wireless operators. We don't know who the next Jobs and Wozniak will be or what will be the next Microsoft with WebTV and Windows CE. Do I have a bet? Yes. Many thought the technophobes would be the early adopters of these appliances. At last, the technophobes would say, something I can use instead of being used by it. My bet -- in this, I agree with a respected PC-industry analyst, Michael Slater-- is early adopters will be the technophiles. People who, by character, are not afraid of the new, people who know PCs are too complicated for much of what it takes to enjoy the Web. Of course, in writing this, I realize I contradict myself. In this technophile, early adopter respect, history repeats itself. Still, if the character of early adopters is a constant, the identity of the next generation of leaders in the world of connected devices is far from a guaranteed clone of today's establishment. return to top The Be Line Look for a Be Line article in the next issue. return to top Using the Support Kit Debug API by Dave Brown, Partner Technical Support Manager The Debug API in the Support kit is under used. Such an elegant tool needs more consideration. So, grab the sample code and let's dive in: In dealing with other peoples' code, both individually and in groups, I see different theories and applications in debugging. These are the groups I break them into and the musicians I liken their styles to. Cannonball Adderly. This is where in test code and in production code, the command line, system log, serial port, or whatnot gets barraged with information, wanted or not (mainly not). But dangit, there's no mistaking, that's debugging information. However, for code, this is openly wasteful. It confuses a user who launches the program looking for errors. Outputting all your successes and warnings only makes it harder for a user to find errors and problems. Plus, there's CPU time spent formatting and writing the message that gets sent. It should just go away in the release code. Harpo Marx. This is where someone started out as Cannonball Adderly, and then just turned off the sound. They comment out their printf's or cout's one by one as the code gets more reliable. This is fast, but has other drawbacks; for example, to turn on your debugging code again, you have to un-comment each line you want to appear again. Philip Glass. No debugging code is left at all, making you wonder if the results you're getting are intentional or not. No errors, no warnings, nothing. These are usually the guys that never comment anything either. In coding, this is just laziness. The time spent commenting and checking errors pays off in reusability. John Coltrane. Smooth and elegant, perhaps even ingenious. This code may have proper compile-away debugging code, but is using some proprietary method that nobody else in the world could possibly understand without the Rosetta Stone. Have you ever read Rico.h? Sonny Rollins. Very natural feeling code. Proper organization, easy to read, uses published APIs ( such as the Debug API) so not only does he know what he's doing -- get this -- other people do too! This is the guy everyone loves. Non-lethal errors exported to the command line, lethal errors reported in clear, proper alerts, all statuses checked, all data verified as early as possible to prevent lethal failures. As much shape and forethought as can be expected is implemented. You can judge who you are. Moving on, here are some general notes about the Debug API. They are C-style macros. Most of the useful code is in <Debug.h> to be read. In order to use the Debug macros, you need to do two things: Set the DEBUG flag in each implementation (.c, .cpp) file you will be using the Debug API in, and Switch on the flag programmatically in your code (usually in main()). Note that with most of these commands, you don't need the finishing semicolon after the final closing paren, but I use it for consistency's sake, and it has no significant impact. That's the worst of it, really. So, how do you play with the Debug macros? First, let me bring up something that is just plain incorrect in the Be Book right now. You have to type "#define DEBUG 1" in all your .cpp documents to get the debug macros to work. When it's time to compile away your debugging code, you can do one of two things. Replace all the lines #define DEBUG 1 with #define DEBUG 0, or comment out the lines. Either will do nicely. Note that if you do makefiles for your projects, this is even easier -- you just remove the DEBUG definition from your makefile and it affects all the files at once! A topic beyond the scope of this article, makefiles are left to those who know how to use them. More details are available in the Be Book. The next line in your .cpp file should read #include <Debug.h>. It is vital that you define DEBUG to true (1) _before_ you include the <Debug.h> file the first time chronologically because Debug.h tests the value of DEBUG and defines the debugging macros according to that value. So: in my main.cpp file, I usually have these 2 lines first. This does 2 things. First, it sets up the global debugging mode so all files included afterward use the debugging macros. Second, if any other files #include <Debug.h> where DEBUG isn't true, I win, because I got there first. Now let's look at what most people want to do with debugging code. Dump information to where they can see it in testing. Use this macro: PRINT(("I want to see this")); If you look in <Debug.h>, you'll read that this requires both sets of parentheses. Reason being that the outer parentheses get stripped, and the inner ones get handed to printf. All valid printf formatting flags apply, so you can print the values of your variables in typical formatting. In the sample code, I use: PRINT(("Condition 3 met: clicks=%d | \n", clicks)); Another situation you may find yourself in is wanting to call a command or block of commands under debug conditions only. One situation I ran into was part of an if-else statement. I only wanted to execute the else clause under debug conditions. So, I used: //condition: within 4 pixels if ((abs(int32(point.x - firstclick.x)) < 4) && (abs(int32(point.y-firstclick.y)) < 4)) { closeenough = true; } DEBUG_ONLY( else { PRINT(("Not close enough")); } ); In my sample code, the impact is negligible, but in a Translator Kit add-on or Media Kit decoder, every time you perform a test, every time you format another string, you're wasting CPU time. By using the Debug API, your finished code will outperform your debug code by literally not having those instructions. The Debug API has other functions that are more powerful: ASSERT(bool) to stop running the program if bool is false; ASSERT_WITH_MESSAGE() to not only break the program, but provide the user with a message as to why. TRESPASS() which is similar, and DEBUGGER() to break out of runtime into bdb so you can poke around. About 80% of application-side debugging can be done with the samples I have here, so I leave these and the other more powerful commands for your reading in the Be Book. This is not the only way to achieve compile-away debugging code. I have seen many functional ways to get similar effects with the preprocessor, with macros, etc., but for consistency, we suggest using the APIs provided. This project is a superset of some fancy double-click handling code I wrote for a developer. The original exercise was to split double- clicking across two views correctly, which the current BeOS model intentionally does not do. My solution was to filter the B_MOUSE_DOWN messages and redirect them to a background view, which handles, records, and reports the clicks through its children. I hope that both the discussion on the Debug API and the doubleclick code will be useful. return to top Statements contained in this Newsletter that are not historical facts are "forward-looking statements" including without limitation statements regarding the demand for, future market penetration and market acceptance of BeIA and BeOS, the shipment dates of Be's products, and the future operating results of Be Incorporated. Actual events or results may differ materially as a result of risks facing Be Incorporated or actual results differing from the assumptions underlying such statements. Such risks and assumptions include, but are not limited to, risks related to competition, market acceptance and market penetration of Be's products, ability to establish and maintain strategic relationships, the benefit of Be's products to OEM and Internet appliance manufacturers. the continued availability of third party BeOS applications and drivers, and the ability to establish and maintain strategic publishing relationships. All forward-looking statements are expressly qualified in their entirety by the "Risk Factors" and other cautionary statements included in Be Incorporated's Annual Report on Form 10-K for the year ended December 31, 1999, and other public filings with the Securities and Exchange Commission. The BMessage Copyright (c) 2001 by Be, Inc. All rights reserved. Be, Inc. 800 El Camino Real, Suite 400 Menlo Park, CA 94025 Tel: (650) 462-4100 Fax: (650) 462-4129 Web: http://www.be.com/ Be, BeOS and BeIA are trademarks or registered trademarks of Be Incorporated in the United States and other countries. Other brand product names are registered trademarks or trademarks of their respective holders. All rights reserved. The BMessage is sent to subscribers of one or more of the Be mailing lists. For more information about subscribing/unsubscribing, see the Be web site: http://www.be.com/world/mailinglists.html. The Be web site also offers a complete set of current and back issues of Be Newsletters: If you have any comments about The BMessage, please e-mail them to:newsletter@be.com.

About Be, Inc. | Be Products | World of Be | BeOS Support | Jobs | Developers | Press | Partners | Investors

Copyright © 2001 by Be, Inc. All rights reserved. (Legal Info)
Comments, questions, or confessions about our site? Please write the Webmaster!