<div dir="ltr">Hi Liam,<div><br></div><div>thanks for the feedback. I will get an account on gitlab.</div><div><br></div><div>Mirko</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 1, 2016 at 1:12 PM, Liam Healy <span dir="ltr"><<a href="mailto:lhealy@common-lisp.net" target="_blank">lhealy@common-lisp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for these patches. I think that GSLL should use the GSL<br>
functions for permutations and combinations rather than relying on the<br>
foreign representation as vectors (and the wrong type, too, as you<br>
discovered). There is some loss of use of grid functions for<br>
manipulation, but I never used that anyway (and I doubt anyone else<br>
did).<br>
<br>
However, I would make some changes. Please use defmobject to define<br>
the permutation and combination classes. It defines the interface to<br>
GSL following GSL's standard way of naming functions. Second, GSLL<br>
does not define interfaces to any _calloc functions, relying instead<br>
on separate functions for clearing/resetting the data (and GSL always<br>
defines a function for doing that). I'm not sure of the value of the<br>
_calloc functions, but if they are thought useful, they should be<br>
defined for every mobject and thus need a change in defmobject. So, I<br>
would eliminate the :initialize keyword for now.<br>
<br>
The best way to learn how to use defmobject is to look at the other<br>
uses of it in GSLL. When you write something, you can macroexpand it<br>
to see that what comes out looks correct. Try macroexpanding the<br>
defmobject histogram form and see how the interface to the foreign<br>
object and functions is defined.<br>
<br>
I have created an issue at<br>
<a href="https://gitlab.common-lisp.net/antik/gsll/issues/2" rel="noreferrer" target="_blank">https://gitlab.common-lisp.net/antik/gsll/issues/2</a>. If you want to<br>
register as a user on <a href="http://gitlab.common-lisp.net" rel="noreferrer" target="_blank">gitlab.common-lisp.net</a>, I can assign it to you<br>
and we can continue discussion and patches there. Thanks again.<br>
<span class="HOEnZb"><font color="#888888"><br>
Liam<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Sun, Nov 29, 2015 at 10:02 AM, Mirko Vukovic <<a href="mailto:mirko.vukovic@gmail.com">mirko.vukovic@gmail.com</a>> wrote:<br>
> This is a follow-up on the previous patch.<br>
><br>
> I applied the same principles on data/combination.lisp and recoded using<br>
> GSL's combination functions only. Again this cleared up some errors or<br>
> failures on my end.<br>
><br>
> I hope that I did not mangle major pieces of your design intent.<br>
><br>
> Mirko<br>
><br>
><br>
> On Fri, Nov 27, 2015 at 10:43 PM, Mirko Vukovic <<a href="mailto:mirko.vukovic@gmail.com">mirko.vukovic@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Liam,<br>
>><br>
>> I am not trying to bludgeon this issue to death nor convince the you that<br>
>> I am right and you are wrong.<br>
>><br>
>> In a nutshell, I started on this path because of exception errors when<br>
>> trying to<br>
>> load GSLL on Windows (SBCL or CCL) using GSL compiled MinGW64. I<br>
>> traced this to the initialization of the permutation structures and the<br>
>> size of<br>
>> the requested memory (see recent post on CFFI mailing list).<br>
>><br>
>> I decided to rewrite a small part of permutation.lisp to use GSL's code to<br>
>> directly<br>
>> initialize and query permutation structure. The attached patch contains<br>
>> the<br>
>> rewrite and some minor edits. All the permutation and qrpt tests pass.<br>
>><br>
>> The patch should be considered a proof-of-concept (or failure of concept).<br>
>><br>
>> For me, this patch has cleared the exception errors that have started me<br>
>> on this<br>
>> trek. Even if it is not accepted, I learned something, and it was fun.<br>
>> And I can<br>
>> keep it on my GSLL so that it runs for me.<br>
>><br>
>> Best,<br>
>><br>
>> Mirko<br>
>><br>
>><br>
>><br>
>><br>
>> On Thu, Nov 26, 2015 at 10:24 AM, Liam Healy <<a href="mailto:lhealy@common-lisp.net">lhealy@common-lisp.net</a>><br>
>> wrote:<br>
>>><br>
>>> Added thought: you can lookup any GSL (C) function to find the CL<br>
>>> equivalent by using gsl-lookup. So for example<br>
>>><br>
>>> (gsl:gsl-lookup "gsl_permute_vector")<br>
>>> PERMUTE<br>
>>> T<br>
>>><br>
>>> tells you #'permute is the function you want. If there is no<br>
>>> equivalent (there are some C functions with no interface in CL), you<br>
>>> will get NIL as the return value of this function.<br>
>>><br>
>>> Liam<br>
>>><br>
>>><br>
>>> On Wed, Nov 25, 2015 at 11:20 PM, Mirko Vukovic <<a href="mailto:mirko.vukovic@gmail.com">mirko.vukovic@gmail.com</a>><br>
>>> wrote:<br>
>>> > Thanks for the explanations - I missed the :generic and :method<br>
>>> > specifiers.<br>
>>> > I'll study the macro-expansions.<br>
>>> ><br>
>>> > Sorry for the noise.<br>
>>> ><br>
>>> > Mirko<br>
>>> ><br>
>>> > On Tue, Nov 24, 2015 at 10:16 PM, Liam Healy <<a href="mailto:lhealy@common-lisp.net">lhealy@common-lisp.net</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> The original code looks right to me.<br>
>>> >><br>
>>> >> You have taken the generic function and the associated foreign vector<br>
>>> >> methods #'permute and gratuitously renamed them #'permute-vector,<br>
>>> >> leaving the method for raw C pointer with the original name and no<br>
>>> >> generic function. Then you completely delete the generic function and<br>
>>> >> vector methods for #'permute-inverse for no apparent reason, leaving a<br>
>>> >> method for the raw C pointer only.<br>
>>> >><br>
>>> >> There is no duplicated code here. There is certainly the equivalent of<br>
>>> >> gsl_permute_vector, it is the GRID:VECTOR-DOUBLE-FLOAT (second arg)<br>
>>> >> method of #'permute (which you renamed).<br>
>>> >><br>
>>> >> I recommend macroexpansion as a way of seeing what's being defined. If<br>
>>> >> you use emacs, place the cursor on the defmfun line and do C-c C-m.<br>
>>> >> Then you will see all the generic functions and methods, and you will<br>
>>> >> see there is no error in the original code.<br>
>>> >><br>
>>> >> On Tue, Nov 24, 2015 at 5:43 PM, Mirko Vukovic<br>
>>> >> <<a href="mailto:mirko.vukovic@gmail.com">mirko.vukovic@gmail.com</a>><br>
>>> >> wrote:<br>
>>> >> > Because of a typo, GSLL did not have the equivalent of<br>
>>> >> > GSL_PERMUTE_VECTOR.<br>
>>> >> ><br>
>>> >> > There was also a section of duplicated code.<br>
>>> >> ><br>
>>> >> > This patch should fix these errors.<br>
>>> >> ><br>
>>> >> > NOTE: I did not test this patch - My GSLL system is not behaving<br>
>>> >> > super-cleanly on MSYS2 and GSL2.1. Proceed with care.<br>
>>> >> ><br>
>>> >> > Mirko<br>
>>> ><br>
>>> ><br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>