good chemistry is complicated,
and a little bit messy -LW
Re^8: How to use wxHtmlEasyPrintingby Anonymous Monk
|on Mar 20, 2013 at 15:45 UTC||Need Help??|
OK. Your suggestion on the font sizes worked correctly. Many thanks. If it moves you, I would like to know your thought process to make that suggestion.
Glad it helped
Well, I read what you tried, I read the documentation, and compared what you tried to my understanding of the docs (including html), and I examined what the values of the constants were
Basically , you verify everything starting with the problem-causing-line until you encounter a difference between what you think should happen and what you observe to happen -- usually these revelations are loud AHA!-types with a solution, or so confusing that you're forced to put-aside what you're working on and start a new file to create the smallest possible example that replicates the problem
Its a lot like debugging CGI scripts or any kind of program, you need a mental model of how its supposed to work (Cwd, STDIN/STDERR/STDOUT/@ARGV/%ENV), what is special about perl ( PERLLIB/PERL5LIB/PERL5OPTS, perlvar, @INC ), what is special about CGI (Server error, see CGI Help Guide , Troubleshooting Perl CGI scripts)
You know input comes on STDIN, output goes on STDOUT, and if things stop making sense and you haven't been able to force an error message, you start making your own error message (turn on debugging/logging, add print statement), you start verifying that STDIN contains the input that is supposed to be there, that pwd/cwd is what you think it should be, and %ENV, and @ARGV ... and @_ are what the function takes
You always start with the big picture, an overview(like wxWidgets overviews), a bird's eye view of how something is supposed to work ( like HTTP ), then look at some simple examples, then bigger examples, until the big idea is firmly planted in your headn. Then write lots of little programs to explore/test/verify how each part is supposed to and does work.
Then when debugging a real program, you have a built-in debugging checklist to verify against. If you're well designed libraries (Dancer/Catalyst...) they'll do a lot of the checking for you, make errors obvious, but you'll be lost without a mental model (aka "domain" or metaphor) , error messages won't make sense, and programmers need a few just to get started (stdin, args, return values, exit codes, files and folders/directories ...)
Its a lot like being a car mechanic or an animal tracker, you start with a model/behaviour of a car/animal, you look to see what tracks/diagnostics you're getting, you ask yourself, if I were fuel/camel and I were leaking/thirsty, which way would I turn? And then turn left/replace leaky carburetor :) How Non-scientists use the Scientific Method
a lot more links on this type of thing and related things and examples if you've got time and need some perspectives and perspectives
Also known as teddy bear debugging , mirror debugging, empty room debugging, talking to yourself, Rubber Duck method of debugging, say it out loud George, sing into that hairbrush ... Re^3: Move along, nothing to see here . . ., Re: On Answering Questions
Re^2: Perl Module Not Working In Crontab, Re^4: Cron revisited, brian's Guide to Solving Any Perl Problem, on learning CGI learn about the internet,Web Programming: For Beginners, to get an overall picture of how the internet works, how tcp/ip, sockets, html, ajax, all fit together.
Also worth reading are The Architecture of Open Source Applications (Volume 2): Scalable Web Architecture and Distributed Systems and mod_perl: Building a Large-Scale E-commerce site with Apache and mod_perl