Re: hyperg_0F1 doesn't work

[David Bateman]

Ok, I think I understand what is happening here. Consider the autoload
lines used in the gsl package (and in fact in all of the packages) are
of the form

autoload ("hyperg_0F1", which ("gsl_sf"));

now which("gsl_sf") will return something like

which: `gsl_sf' is the script file
/usr/share/octave/packages//gsl-1.0.0/gsl_sf

where as which("fftn") returns

fftn is the dynamically-linked function from the file
/usr/lib/octave/2.9.9/oct/i586-mandriva-linux-gnu/fftn.oct

The issue is that help.cc(do_which) calls

symbol_record *sym_rec = lookup_by_name (name, 0);

The file is found, however as there is no gsl_sf function in gsl_sf.oct,
the function is not defined and in help.cc(do_which) we fall through to

      std::string path = fcn_file_in_path (name);

which incorrectly finds the file without the extension, again because it
finds gsl_sf.oct, but then

const file_info& fi = *i;
int t = fi.types;
(t & load_path::M_FILE)

is not true and the ".oct" is not added in load_path::do_find_fcn,
though the retval maintains the string for the find when it shouldn't.
It doesn't make sense to have lookup_by_name not find the file and then
have fcn_file_in_path find the oct-file, and so I believe the correct
behavior should be to have fcn_file_in_path also fail, and then we need
to adapt gsl_sf to have a dummy gsl_sf function, that should probably
just give a help string..

So, the attached patch to octave, and a second patch for gsl as attached
will completely address this issue.

Regards
David


Peter Soendergaard wrote:
> Try something like
>
> autoload('hyperg_0F1','/usr/lib/octave/site/oct/api-v22/i686-suse-linux/octave-forge/gsl_sf.oct');
>
> I reported this on the bug list, but noone has found out why the loading 
> fails for gsl_sf.oct.
>
> The problem seems to be that
>
> which gsl_sf
>
> incorrectly indentifies gsl_sf as a script file, and not as a .oct file. 
> Explicitly loading the function corrects the problem.
> This affects all the functions is the gsl library.
>
> Cheers,
>
> Peter.
>
> On Mon, 4 Dec 2006, Torben Mikael Hansen wrote:
>
>   
>> Hi
>>
>> I alread posted this on the octave-dev list but it doesn't seem vary active 
>> so
>> I'll repost it here. Sorry, if you receive it twice.
>>
>> I have built   and installed octave 2.9.9 and octave-forge 2006.07.09 (also
>> called 2006-07-10) and tried to use the "hyperg_0F1" function. However it
>> seems not to be installed.
>>
>> the "gsl_sf.oct" seems to be build correctly
>>
>> nm /usr/lib/octave/site/oct/api-v22/i686-suse-linux/octave-forge/gsl_sf.oct\
>>
>> | grep hyperg
>>
>> 00011860 T FShyperg_0F1_gnu_v3
>>         U gsl_sf_hyperg_0F1
>>         U gsl_sf_hyperg_0F1_e
>> 00058950 T _Z11Fhyperg_0F1RK17octave_value_listi
>>
>> Looking at the build.log seems to me a bit strage, but honestly I don't
>> really understand it. It seems that the octlink's for gsl are processed
>> before the "gsl_sf.oct" is built. Is that the correct order?
>>
>> "coupling_3j", "coupling_6j",  "coupling_9j" are there, but they also have
>> their own cc-file.
>>
>> Regards
>> Torben
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Octave-dev mailing list
>> address@hidden
>> https://lists.sourceforge.net/lists/listinfo/octave-dev
>>
>> -------------------------------------------------------
>> _______________________________________________
>> Help-octave mailing list
>> address@hidden
>> https://www.cae.wisc.edu/mailman/listinfo/help-octave
>>
>>     
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www.cae.wisc.edu/mailman/listinfo/help-octave
>
>   


-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

*** src/load-path.cc.~1.12.~    2006-11-15 20:52:46.000000000 +0100
--- src/load-path.cc    2006-12-04 11:58:23.745104816 +0100
***************
*** 727,732 ****
--- 727,735 ----
          else
            error ("load_path::do_find_fcn: %s: invalid type code = %d",
                   fcn.c_str (), type);
+ 
+         // Reset the return string, in case the above fails
+         retval = std::string();
        }
      }
  

*** main/gsl/src/precode.cc.template.orig       2006-12-04 12:07:08.828971701 
+0100
--- main/gsl/src/precode.cc.template    2006-12-04 12:04:43.467123936 +0100
***************
*** 27,32 ****
--- 27,43 ----
      error("GSL error %d at %s, line %d: %s\n", gsl_errno, file, line, reason);
  }
  
+ DEFUN_DLD (gsl_sf, args, nargout,
+   "-*- texinfo -*-\n\
+ @deftypefn {Loadable Function} {} gsl_sf ()\n\
+ \n\
+ Octave bindings to the GNU Scientific Library. All GSL functions can be\n\
+ called with by the GSL names within octave.\n\
+ @end deftypefn")
+ {
+   usage("gsl_sf");
+ }
+ 
  /*
  ;;; Local Variables: ***
  ;;; mode: C++ ***