Apps :: MyDSL UCI problem / solution



When I click on the MyDSL icon and then on the UCI button, nothing happens.  But when I click on the Apps button, everything works as it should.  jpeters also reported this problem on Feb. 4, 2007 in a post titled "UCI area" in this forum.  I'm using an older version of DSL (v2.2) so this problem may have been fixed in more recent versions.  Apologies for the length of this post but it seems like the best way to explain what's going on.

The source of the problem:
Clicking on the MyDSL icon and then a button runs the program mydslBrowser.lua but gives no feedback if there's a problem.  To get some, open a terminal window and run the program from the command line.  Its syntax is "mydslBrowser.lua [library-name]" where library-name is, e.g., "apps" or "uci".  Basically what happens is that mydslBrowser.lua accesses the library specified, downloads a file named "index.html" to the user's home, searches this file for lines with the string ".info" in them, writes these lines to a temporary file in /tmp, and then displays this file in a window (which is the window one gets when things are working).

Doing "mydslBrowser.lua uci" (without the quotes) from the command line will give the following error message:

error: attempt to perform arithmetic on local `k' (a nil value)
stack traceback:
  1:  function `parseInfo' at line 15 [file `/usr/bin/mydslBrowser.lua']
  2:  main of file `/usr/bin/mydslBrowser.lua' at line 41

Listing the home directory shows that "index.html" has been downloaded, so that's not where the problem is.  To decipher the error message, open up mydslBrowser.lua with a pager, e.g., "less", or a text editor.  A loop extracts each line from "index.html"; line 41 is inside the loop and sends the line to the function "parseInfo".  Line 15 is in "parseInfo" and is the point at which mydslBrowser.lua blows up.  

So what's going on in this function?  Using "strfind(s,".info")", it looks for the string ".info" in the line it's been sent; if it doesn't find this, it returns to the loop.  If it does find the string, it sets values for various variables, one of which is "k".  Apparently at some point a value for "k" isn't any good because when line 15 tries to compute with the value, it blows up.  So what's causing the "k value problem"?

We need to look in the temporary file in /tmp.  Its name has the form "filexxxxxx" where the x's are random letters and numbers.  If there's more than one like this, look for the one which has lines with ".uci" in it; alternatively, delete them all, run "mydslBrowser.lua uci" again and open the temporary file which has appeared.  Note two things: (1) every line ends with a ".info" and (2) the last line in the file is "imagemagick.uci.info".  

Now open up "index.html".  Various lines in it have ".info" toward their ends; part of these lines are extracted and written to the temporary file. Now look on down through "index.html" for the "imagemagick.uci.info" entry and look at the next entry after it: It is for the inform program and has in it a line containing "inform.uci.info".  This hasn't been written to the temporary file.  

Why are things dying at this entry?  Note that it has the string "info" all through it so "info" doesn't appear only at the end of "inform.uci.info". Apparently the "." in the search string is being ignored (actually it isn't; see below); the search finds something, but not what's expected and so "k" can't get a good value.

Here are two other ways to verify this as the problem: Copy mydslBrowser.lua from /usr/bin/ to your home directory and open the copy with an editor.  In the first line of the "parseInfo" function, change "strfind(s,".info")" to either (1) "strfind(s,".info",1,1)" or (2) "strfind(s,"%.info")" in either case without the outermost quotes.  (I'm using lua version 4.0, but something similar holds for later versions; for the specifics, see the section about string manipulation at www.lua.org/manual under your version of the manual.)  Next, on the command line do "./mydslBrowser.lua uci" without the quotes.  Be sure to use the "./" at the beginning so that the edited version in your home will be used, not the unedited version in the system.  Everything should work as expected.  (Incidentally, when mydslBrowser completes properly, "index.html" is erased.)

Why do these work?  The "." in the search string, ".info", is treated as a special symbol which matches any character, and so one of the "info" strings (presumably the first one) in the inform program's entry is found. Either of the changes (1) or (2) removes the "specialness" and makes the search look for the specifically given string.  (Adding the "%", escapes the "."  so it is no longer special.)  Thus only those lines with precisely the specified string are recognized.  These of course are exactly the lines one wants to extract and display.

FIXES:

OK so how can the problem be fixed?  Here are some ways, none entirely satisfactory for everyone.  (A) Patch the version of mydslBrowser.lua that's distributed.  Problem: this won't help those of us who use versions prior to the patch.  (B) For us, there are two options: When we want to access the uci library, we can edit mydslBrowser.lua as specified earlier. Or we can go to distro.ibiblio.org/pub/linux/distributions/damnsmall/mydsl/uci/, download the desired file, and install it with "mydsl-load [/path/name-of-extension]", e.g., "mydsl-load /tmp/scite.uci".  ( C ) It turns out that if the "i" in "inform" is capitalized, things will work as they should.  So the maintainer of the index file for the uci library could change all the "inform"s to "Inform"s.  In the long term this fix is awkward since it's a constraint that needs to apply to all non-targeted occurrences of the string "info" in the index files of all the libraries. (But in the short term it would be nice for those of us in category (B).)
You are revisiting an old bug that have been corrected in newer versions. Local parsing is no longer performed. Please use an much newer version than v2.2.

Look at the change log since v2.2!

original here.