Re: How to debug init.m?
- To: mathgroup at smc.vnet.net
- Subject: [mg92328] Re: How to debug init.m?
- From: magma <maderri2 at gmail.com>
- Date: Sat, 27 Sep 2008 22:21:32 -0400 (EDT)
- References: <gbl30f$m0g$1@smc.vnet.net>
If the problem is finding the offending line among 218 lines of code then the solution is simple: perform a binary search on the code! Here is how: Split the code roughly in 2 equal parts. Comment out the second part Run the code Does it crash? No? then the problem lays in the second part. So now take the second part of the code (take away the comment brackets) Split this second part roughly in 2 equal parts comment out the last fourth of the code Ect.... Do you see it? At each step comment out half of the (yet untested) code and see what happens. You will find the offending line in about Log[218,2] tries, that is about 8 tries. Good hunting On Sep 27, 12:47 pm, Bob F <deepyog... at gmail.com> wrote: > Does anyone have any suggestions on how to debug a problem with an > init.m file (located in ~/Library/Mathematica/FrontEnd)? I am using > Mathematica 6.0.3 on Mac OS X (both 10.4 and 10.5 show the problem) > and if I simply start up the program and have a completely empty > notebook, then open the "Options Inspector" and then start up the > "Documentation Center" the program always crashes. If I empty the > init.m file there is no crash, so the problem is related to what it > has. But, the things that are there are there because of how I want > things set up, e.g. positions of palettes, kernel configuration > definitions, recently opened files, etc, and only because Mathematica > puts them in there according to how I have things defined and what > files I have opened, etc. I have not edited this file by hand, so the > error is there as a result of Mathematica. I have looked at the file > and don't find any strange control-characters or anything glaringly > obvious, but it's all regular looking text in the typical verbose > Mathematica low-level encoding. > > The file has 218 lines in it right now, so trying to debug by > eliminating things line by line is a bit daunting. Wolfram says they > can reproduce the crashing with my init.m file, and want me to debug > the file and find the offending line to narrow down the problem for > them. Surely this would be trivial for them to debug given source and > a simple breakpoint, but they don't seem to think the same, so I am > stuck trying to debug their problem for the moment. Perhaps someone > might have a suggestion for narrowing this down? > > Is this typical for Wolfram to push this level of debugging onto > customers for problems with the program? For software as expensive as > this, I don't think this should be the normal behavior on their part, > but that is only my opinion. Anyone wish to comment about this in > general? > > There is an error that is flashed up on the screen in the Messages > window, and I believe the error says something about an "internal self- > test error", and gives a reference to a specific routine, felexAPI.c| > 33, which I am guessing is something about "FrontEndAPI, line 33", but > Wolfram says that's not any help in this case since the problem has to > do with parsing the init.m file. > > But something just occured to me -- why would this file get parsed > when the "Documentation Center" window is opened? Maybe it gets parsed > when any file is opened? > > Any ideas or suggestions?? > > Thanks.... > > -Bob