<div class="gmail_quote">Thanks for you suggestions Glynn.<br><br><div class="gmail_quote">2009/1/12 Glynn Clements <span dir="ltr">&lt;<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>&gt;</span><div class="Ih2E3d">
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
Soeren Gebbert wrote:<br>
<br>
&gt; In case we will use the meschach library within grass to replace the<br>
&gt; existing LAPACK wrapper, my BLAS and solver implementation<br>
&gt; and several numerical recipes algorithm (lu, eigenvalues solvers ...), i<br>
&gt; will take the patched debian sources and integrate them into<br>
&gt; grass.<br>
&gt;<br>
&gt; IMHO the following changes have to be made in the meschach library:<br>
&gt;<br>
&gt; * replacing malloc, calloc and realloc with the GRASS implementation<br>
<br>
</div>Not necessarily. The G_* versions are merely a convenience to avoid<br>
having to explicitly check for failure. If meschach is already<br>
performing the checking, there probably isn&#39;t much reason to change<br>
it.<br>
<div></div></blockquote></div><div><br>Agreed, AFAICT memory checks are performed in meschach.<br>But i was hoping to get rid of the machine dependent defines within the include files of meschach, <br>grass already checks for malloc, calloc and realloc.<br>

&nbsp;</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
&gt; * replacing printf and fprintf with the GRASS implementation<br>
<br>
</div>GRASS doesn&#39;t have implementations of those functions. It has<br>
G_message() etc, which should be used for communicating with the user.</blockquote></div><div><br>Sorry for confusion, i ment G_message() etc. <br>Usage of G_message() will probably integrate meschach better in the grass message handling (quite, verbose ...).<br>

But i have to think more about this. You are making a good point.<br>In case a distribution version of meschach will be used, instead of the copy in grass, <br>the message handling will process in the original way ..&nbsp; so the benefit of changing the<br>

message handling in the grass copy is lost ... and because of that not meaningful at all.<br>&nbsp;</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
<div><br>
&gt; * changing the error handling to use G_fatal_error and similar GRASS<br>
&gt; functions<br>
<br>
</div>Probably, although this should be done in a minimal manner, e.g.<br>
making errors call a user-defined callback, and installing a callback<br>
which calls G_fatal_error().</blockquote></div><div><br>Agreed. <br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div><br>
&gt; * adding the prefix G_math_ to all extern library functions (with<br>
&gt; preprocessor directives)<br>
<br>
</div>Why?</blockquote></div><div><br>To mark the meschach code as part of the gmath library. Many functions in meschach are quite short<br>and in this manner not self explaining. I think the grass code using meschach will <br>

be more readable if a prefix is used. A developer who is not familiar with meschach will identify the<br>functions as part of the gmath library and will not search for local function definitions.<br>But i wont touch any function name in the code of meschach. Instead i would like to include the meschach<br>

includes into gmath.h and redefine the meschach names with macros:<br><br>gmath.h:<br><br>/*meschach includes*/<br>#ifndef SYSTEM_MESCHACH<br>#include &quot;grass/matrix.h&quot;<br>...<br>#else<br>#include &lt;matrix.h&gt;<br>

...<br>#endif<br><br>#define G_math_iv_get iv_get<br>#define G_math_SPMAT SPMAT<br>#define G_math_sp_free sp_free<br>...<br>&nbsp;</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
<br>
Is there some reason why GRASS must &quot;assimilate&quot; meschach rather than<br>
simply using it (with any modifications which are strictly necessary).</blockquote></div><div><br>No.<br>&nbsp;</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
<br>
In particular, if any distributions provide a meschach package, it&#39;s<br>
generally preferable to use that rather than a private copy.</blockquote></div><div><br>Agreed. <br>But IMHO a copy of meschach should be provided in grass with minimal changes so it can be <br>replaced with a distribution version. I guess this can be handled at configuration time.&nbsp; <br>

<br>Soeren<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div><div></div><div><br>
--<div class="Ih2E3d"><br>
Glynn Clements &lt;<a href="mailto:glynn@gclements.plus.com" target="_blank">glynn@gclements.plus.com</a>&gt;<br>
</div></div></div></blockquote></div><br>
</div><br>