mgalloy / idldoc

Documenting IDL code
Other
20 stars 13 forks source link

Cannot construct class definition - just inheritence - intermittent #48

Closed mgalloy closed 9 years ago

mgalloy commented 11 years ago

I think that there is a problem when IDLDoc tries to construct a class definition for a class that just inherits. For example:

pro star_course_vs_time_receiver_request`__`define 
  struct = { star_course_vs_time_receiver_request, $ 
             inherits star_single_receiver_request } 
end

Produces the following error:

IDLDOC: cannot construct definition for class star_course_vs_time_receiver_request

This doesn't seem to happen all of the time, but I can't find a consistent thread to indicate when this problem occurs and when it doesn't.

mgalloy commented 11 years ago

Is the definition of star_single_receiver_request available? i.e., is star_single_receiver_request__define.pro in the !path? I got exactly the same error you mention when I hadn't created star_single_receiver_request__define.pro yet, but it works fine with star_single_receiver_request__define.pro in the same directory as star_course_vs_time_receiver_request__define.pro or somewhere else in my !path.
mgalloy commented 11 years ago

Author: jhood Yes all of the superclasses are in the path for the example. The code itself executes properly. Until a short while ago, all errors of this form (5 over the entire code base) were in depricated code, so I didn't pay much attention. In the last month, I got four new errors of this form, so I decided to try and solve it. It may be something silly that I am doing on my end, but I can't see what the problem would be.

Some of the code doesn't nicely auto-compile and we put includes (@filename) at the top of some applications to make sure that the right code is compiled in order. This is mainly because we will put several functions in the same file. It looks like you might require function calls, etc. to properly compile automatically in order for IDLDoc to understand them. This might be the root of the problem, though in this case the classes are in their own file and properly named to compile automatically. I will look to see if some other function call (i.e. one with a keyword that isn't already defined) could be causing a compile to fail. Would this cause the error?

kimyx commented 9 years ago

For what it's worth, we see this error consistently when mgunit tests are parsed via idldoc. The doc output seems ok, but we get this message:

00:00:30.585 % Compiled module: CONFIG_UT__DEFINE.
00:00:30.585 % IDLDOC: cannot construct definition for class config_ut

These test cases inherit MGutTestCase, which is available on the path.

mgalloy commented 9 years ago

They inherit only from MGutTestCase?

kimyx commented 9 years ago

Yes. Here's the complete class definition for the message referenced above.

pro config_ut__define
  compile_opt strictarr

  define = { config_ut, inherits MGutTestCase }
end

I can strip down the complete file and send it if that would help.

mgalloy commented 9 years ago

If you could make a small example that shows the problem and send it to me, that would be great!

mgalloy commented 9 years ago

I got the same issue you are reporting until I made sure MGutTestCase was resolved before running IDLdoc. Remember: if you are using the mgunit .sav file distribution, then you need to RESTORE mgunit.sav before running IDLdoc to make MGutTestCase available (since it will not automatically be found in mgunit.sav since it has a different name).

Please let me know if this resolves your issue.

kimyx commented 9 years ago

Yes, I'm glad it was that easy! I assumed this wasn't necessary since the tests find and resolve mgunit when they are run, but of course they aren't being run when the doc is built. For the record, I added this code to the start of our documentation batch job:

; must restore mgunit.sav or there will be warnings in the log
  print, 'Restoring mgunit'
  mgunit_path = strsplit(!path,path_sep(/SEARCH_PATH),/extract)
  mgunit_path = mgunit_path + path_sep() + 'mgunit.sav'
  mgunit_file = file_search(mgunit_path)
  if n_elements(mgunit_file) ge 1 then restore, mgunit_file[0] & print, 'Restored mgunit'
mgalloy commented 9 years ago

Great, I will close this ticket.

By the way, I would do:

mgunit_file = file_which('mgunit.sav')
if (n_elements(mgunit_file) gt 0) then restore, mgunit_file[0] & print, 'Restored mgunit'
kimyx commented 9 years ago

Thanks Mike. More library routines to become familiar with...