file and editor?
Tell that to some store owners..gunshops print (customized) contracts on the spot for customers as needed (multiple copies). Then there are all of EOM and EOY reports needed for the Feds...
A second hand HP laserprinter + new toner / drum cartridge is cheaper.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
3k lines? Thats next to nothing for an embedded project :-)
I used to print listings but nowadays I load the source (C or C++) into Eclipse. Eclipse makes it very easy to browse through code because it also checks the source and makes lists of variables, functions, defines, call-hierarchies, etc.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
On a sunny day (Sat, 20 Feb 2010 16:35:46 -0800) it happened Jon Kirwan wrote in :
I doubt that, a lot! Because these days you can probably read in better code from the web in a few seconds then hours of puzzling through old listings.
There is such a thing as google code. It is a specialsevice of google.
Try entering your precious algo from the DEC dinosaur age, that is so unique it needed to be kept around on procesed poor killed trees.
100:1 you find better code. Sorry, make that 10^100000000^10000^10000 to 10^-10^-10.hehe
On a sunny day (Sun, 21 Feb 2010 02:57:31 -0500) it happened "Michael A. Terrell" wrote in :
Not as temprary as you, they will grow all over your grave.
That's around average or a bit low, especially if I nlist the big sinewave lookup tables and such. Some projects hit 6 or 8 kloc. But we're increasingly moving the heavy lifting into FPGAs, and the uP just does setup/supervisory/calibration/self-test stuff. The VME products are all register-based, so we don't have stuff like TCP/IP stacks or command parsers or user interfaces. My weekend project is code for a 16-channel digitizer with FPGA-based calibrations, floating-point lowpass filters, FIFOs, all that stuff. The uP just manages things. Most of the work is defining and commenting data structures; the code is easy after all that setup grunt work.
We're also doing a Linux based spectroscopy controller that will run to tens of thousands of lines of code and, probably, thousands of files. Luckily, I don't have to write the code for that one; I'm a simple circuit designer.
I print fanfold listings so that I can review them in bed, in a leisurely manner, and add color-coded highlights, edge post-its, notes, tweaks, and look for hazards or cleaner ways to do things. I'll rewrite the code several times before I ever run it, and it will usually work with minimal problems and zero shipped bugs. It's easier for me to visualize the whole project as, literally, a physical entity with components in *places*, sort of like a schematic. That's just the way my brain works. The results are pretty good.
I don't believe that the usual hack-compile-test loop is very good at finding bugs. Reading the code carefully is better. I suspect that most programmers type code once and, if it appears to work, don't look at it again.
John
I think/hope that only the inkjets do that.
John
No wonder you can ship products working... Most of the stuff I work on nowadays has an IP stack and talks through IP.
Unfortunately that will need to some debugging as well. The nastiest bugs come from third party code. I've been hunting several of those the past couple of weeks. Interfacing to other equipment is always a real joy. The protocol is usually very well un(der)specified.
I guess so. See above. I like to write small units which I thouroughly test and use those as building blocks for bigger applications. Ofcourse the input and buffer sizes are thouroughly checked so an error doesn't spread like an oil stain.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
And huggable :-)
-- "Electricity is of two kinds, positive and negative. The difference is, I presume, that one comes a little more expensive, but is more durable; the other is a cheaper thing, but the moths get into it." (Stephen Leacock)
I'd argue that you spend plenty of time debugging, it's just that you do it
*before* you actually build the hardware or run the code for the first time. :-)But I take you point and am absolutely convinced that your approach is much more efficient overall, requiring far fewer ends to obtian bug-free code than the now-common approach of "write something that's really only half-thought-out, run it and see what happens, tweak as needed to get something that's hopefully correct."
Trees are LESS temporary than you...
So far, all of the complaints re: Epson printers were related to inkjets. So, you may be safe. But, if your print volume is rather large (cases per month or more) i would suggest giving a "bash and trash" test via max volume you can generate well within the so-called warrantee period and if it dies, return it for full refund: fails uniform code of merchantability AND not fit for purpose for which it was designed AND defective merchandise. Then get a different brand (Citizens? Brother? Panasonic?).
In a sense, yes. But I find the low-probability bugs, whereas live testing usually doesn't. I just treat software the way most people treat hardware: check the design before you etch the boards.
That seems to be the usual procedure. Read "Showstopper!", the story of the development of Windows NT. All the coders could do was to get a clean compile of their module. They passed that on to "builders" who passed it on to "testers."
Windows is now so fragile that Microsoft dare not mess with the DLL structure. Nobody understands how it works.
John
That depends on the species of tree.
-- Greed is the root of all eBay.
Don't they have groundskeepers for graveyards in Europe, or do they just dump you in a hole & walk away?
-- Greed is the root of all eBay.
Well, if nobody understands it then nobody should "fix" it; meaning issue NO "patches". Solution: 1) fire all but the top 10 percent programmers, 2) run exhaustive competency testing of them, 3) pick the top 3-5 of that group and have them start FROM SCRATCH with ZERO access to any code done before, 4) leave them alone - do not micromanage, do not "bug" them for results, 5) make ONE version - none of this "home" "pro" "upgrade" "oem" etc etc ad nauseum BS - the one version does it all. Oh yes, have them do it all: code, debug, and TEST as if they were a real user (!!). $aves hundreds of thousands of dollars on "programmers" that do nothing but shuffle paper, will not need dozens of buildings to house the absent "programmers" (more savings).
..that is a TREEmendous statement.
Sigh. There are dead trees all around here. The hurricanes a few years ago killed a lot of them. They had a huge burn pit for the better part of a year with truck after truck full of wood to burn. The smoke was so thick I couldn't go outside for more than a few minutes at a time.
-- Greed is the root of all eBay.
That's what you get for living in a swamp!
Best regards, Spehro Pefhany
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
The swamps are lot further South. There is a couple marshy areas about 35 miles from here, though. I live in North Central Florida where there is real dirt and huge horse farms.
The worst thing about this area is the huge number of 70+ cougars. they are worse than the bugs. :(
-- Greed is the root of all eBay.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.