From: Kirk Haines Date: 2004-08-22T07:13:17+09:00 Subject: Re: IOWA error On Sun, 22 Aug 2004 04:15:48 +0900, Mark Probert wrote > "Kirk Haines" wrote: > > > No problem. The error that is reported there is less than totally > > helpful in understanding why the error occured. That is on the todo > > list to fix. > > > IS there an easy way of finding where the Ruby code is incorrect? I > am finding that I am copying the .iwa file to a .rb file, editing it > to remove the odd bits, then running against Ruby. I am sure you > have a more efficient way ... Sure. The ruby code is evaluated by Ruby, and any Exceptions that are thrown are dumped into the logfile with a complete backtrace. So all you should have to do is to check the log file for the iowa app and it should be clear. You'll see something like this: [INFO] iowa_log @ 2004-08-20 06:53:19 :: Loading template /usr/local/htdocs/xxxx.xxxx.com/iowa/AddInventoryByManufacturer.html [INFO] iowa_log @ 2004-08-20 06:53:19 :: Creating namespace Iowa::Application::Content_Classes [INFO] iowa_log @ 2004-08-20 06:53:19 :: There was an error while processing /usr/local/htdocs/xxxx.xxxx.com/iowa/AddInventoryByManufacturer.ht ml: (eval):1:in `module_eval': compile error (eval):20: parse error And following that will be a full backtrace. I am completely open to suggestions on improving what is trapped in the logfile -- either the actual information or the format of the information, but what is there right now should point you right to the offending line. In the above, the .iwa file for the AddInventoryByManufacturer, line 20, had the error in it. Your log file's location is controlled in the .cnf file. For example, in the webrick demo in the source, there is this: logging: basedir: ../log This says that the log(s) will be written in a directory ../log relative to the iowa directory. I am working on three things to help debugging. One is The ability to easily setup unit tests on a component's methods. This is long overdue, and since the layout is seperated from the code like it is, there's nothing _visual_ about any of the code, and it's a pretty gross omission not to have Iowa making it easy to unit test what those methods do. The second is a better webside handling of exceptions. I'm stealing one of DHH's tricks here and setting it up so that one can tell Iowa that for certain requesting addresses, if an exception occurs, show it nicely formatted in the browser so that it's easy to find the information that one needs, and for all other requesting addresses display a configurable "something has broken in a bad way; contact so-and-so" page to the user. I'd love to use the PrettyExceptions class that was mentioned recently, but I need to have code that runs on Win and *nix platforms and that doesn't have an external dependencies, so I'm rolling my own (unless someone knows of something that is already written that I could use). The third is actually just a regular component to help with development. One can stick it into one's standard footer, or just in specific pages, if one wants, and while one is in development mode, it will display a simple debugging toolbar at the bottom of the page that lets one take a peek into the internals of the page and of the app. When one switches a component to production, the component will switch itself off, but you can leave it in the code so that if and when you come back and do more development or need to debug something, you can just turn it on again. All of the above will be in 0.9.2, so if you have any other suggestions on things to make debugging easier, let me know! Thanks, Kirk Haines (nursing a slightly sore knee and hand because I narrowly averted dropping a 1000 lb. trailer and the 350 lb. transmission in the back of it on my leg a little bit ago, and then I tried crushing my hand between the trailer and a 100 lb. rock that I was putting on it as a counterweight; ow.)