Christian Soeller wrote:
> I'd echo Karl's point, f2c only makes sense if a dependence on libf2c.a 
> is avoided. I greped the slatec code and it certainly contains WRITE 
> statements. This might be in bits we don't use but somebody needs to 
> carefully check.

Out of 19282 lines in the *.f files, 13 are write statements.
There appear to be no read statements and only 5 format statements.
The affected files are:

   dp1vlu.f
   i1mach.f
   pvalue.f
   xerbla.f
   xermsg.f
   xerprn.f
   xersve.f

or 7 files out of a total of 112.

> Also, if we do go for the modular approach then we need to go for a 
> graphics free core, otherwise the whole thing is pretty pointless IMHO. 
> Most issues with building PDL relate to graphics issues of some sort.

This can be handled by the discussion of soft fails for module
dependencies in the base PDL.  They won't cause PDL to fail but
if you have the required module, then they will work.  We could
even make them skip those tests for the "soft fail" features
like 2D and 3D baseline graphics.

> Finally, while it might be a great idea to get rid of the MakeMaker 
> approach, how big a task is it to make that transition? It would not be 
> nice to see the 'modular PDL' approach go down the line of a 'perl6' 
> type effort that takes N+1 years to get anywhere.

That is definitely one of the biggest tasks in terms of its
possible impact on PDL overall.  The good news is that the
dependency stuff is the hardest part and the proposed
strategy and use of the existing code should reduce the
risk in this area.  I *definitely* don't want to have PDL-3.0
out in 2020...

> I'd much rather see a quick and less than perfect stab at it (not that I 
> would have time to contribute much).

I think the slatec f2c conversion would not take much work
since with less than 20 lines of IO to worry about, I think
hand replacing with C printf et. al. should not be too
onerous to implement.

--Chris

> Christian
> 
> On 12/11/2009, at 11:13 AM, Karl Glazebrook wrote:
> 
>> Just remember f2c depends on a whole slew of support routines in
>> libf2c.a - though most of these are IO related.
>>
>> But there is some work between running f2c on some fortran and have a
>> pure C code that works.
>>
>> Karl
>>
> 
> -- 
> Christian Soeller PhD   Dept. of Physiology  +64 9 3737599 x82770
> University of Auckland  Auckland, New Zealand  fax +64 9 3737499

_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to