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