Hi Tobias, it may be better to look at an example. For instance, to train my SQB classifier:
model = SQBMatrixTrain( featureMatrix, labelVector, maxIters, options ) where featureMatrix and labelVector are matrices (2-dimensional) and vectors (1-dimensional), maxIters is a uint32 and options a structure of the form: options.<something> = value, where value may be a uint32, string, array, etc. Lastly, "model" is an array of structs, where each struct also contains arrays in some of its members. In this case most types/structs are known at compile-time, except for the length of featureMatrix, labelVector and model. (and in the future may be the size of some arrays inside the structures of the array model may as well vary). Wrapping such call in Julia with ccall seems overly complicated to me. About structs, I can declare an immutable struct in Julia and do the exact equivalent in C, but I fear that at some time I can mess up the order or types, and I have no way (AFAIK) of knowing if I made a mistake from the Julia or C side. I would get garbage, or hopefully a segfault. On the other hand, if I write some general wrappers for Julia, I could check whether the passed Julia type is an array or type of struct I am looking for, check if a struct has field 'name' of type 'type', etc. I think this is a great advantage. Once something like this is written, modifying structs is straightforward, and if an error happens, I can know what is happening. Does this make sense? Or am I missing something fundamental from ccall's design? Thanks. ------------------------------------------ Carlos On Mon, Feb 10, 2014 at 1:56 PM, Tobias Knopp <tobias.kn...@googlemail.com>wrote: > Carlos, > > So if I understand you correctly you have some C functions. Ontop of that > you put a C wrapper that dispatches different Julia objects based on some > internal state. > If this is the case it would be much cleaner if you would make this state > accessible via ccalls and do the dispatching on the Julia side. I also > don't see the maintainance argument. It is IMHO much nicer to maintain > Julia code instead of C code. But if you add new types to the C (core) code > you will have to touch the wrapper anyway. > > There is a bunch of code out there in base/ and many different packages > and I have never seen that extra C wrappers have been written just to > expose functionality of the core libraries. > Wrapping is always done in Julia. Often in a way that there is a thin > wrapper that directly exposes the C API and ontop of that a nicer Julia API > is written. > > By the way: If you are dealing with arrays of structs, making the > according type immutable will guarantee that the memory layout is > compatible with C. > > Cheers > > Tobi > > > Am Montag, 10. Februar 2014 12:24:27 UTC+1 schrieb Carlos Becker: >> >> Hi Tobias, >> >> I want to be able to return different types from ccall(), according to >> what happens inside my C/C++ code, >> without the need for telling julia what I want to return, its size, etc. >> Argument passing gets complicated in such cases, >> and I believe returning julia objects directly is neater. >> >> I know this means that I have to write more C code to interface with >> julia, but at the same time I don't have to simultaneously maintain C and >> Julia code >> if something changes in the C code (eg, I add a member in a struct, or I >> change the output type) >> >> Another example is with a boosting library I wrote, for which I wrote >> matlab wrappers >> (here<https://sites.google.com/site/carlosbecker/resources/gradient-boosting-boosted-trees> >> ). >> In this case its train function accepts a structure with options, plus >> some arrays. It returns an array of structs >> as a 'model' that can be later used. It is nice to have a interface that >> needs almost no tuning from the matlab or julia end. >> >> I think many would consider this 'direct julia type return' as an >> advantage, particularly people coming from python/matlab. >> I also like very much how ccall can handle void pointers, which is >> necessary in some situations, but in some other cases >> it may be cleaner to work with julia object directly. >> >> I hope I was clear. If I have nice code running I will make it available >> for other developers. >> >> Cheers. >> >> >> >> ------------------------------------------ >> Carlos >> >> >> On Sun, Feb 9, 2014 at 7:23 PM, Tobias Knopp <tobias...@googlemail.com>wrote: >> >>> Carlos, the code that you showed can be completely written in Julia. It >>> would be helpful if you could give us more insight what you want to >>> achieve. Is there a specific API that you want to wrap? You said that the >>> API returns a double pointer but the length of the memory is not know (if I >>> get that right) How can one use this pointer if the length is unknown? >>> >>> Am Sonntag, 9. Februar 2014 12:46:24 UTC+1 schrieb Carlos Becker: >>>> >>>> I think I finally made it work, close to what I wanted. >>>> >>>> This could be good for future reference for anyone trying to do >>>> something similar. >>>> The code is at https://gist.github.com/anonymous/8897943. >>>> >>>> I have two questions about it: >>>> 1) calling jl_gc_disable() and jl_gc_enable() is ok in that context? >>>> (see link above) >>>> 2) I still don't know how to avoid passing a pointer to the module I >>>> want to get the type from to the C call. >>>> >>>> Thanks. >>>> >>>> >>>> El domingo, 9 de febrero de 2014 00:40:33 UTC+1, Carlos Becker escribió: >>>>> >>>>> Hi Steven, >>>>> >>>>> I tried that before, I know it is possible, but if the size is unknown >>>>> to julia, it must be returned as another variable, which makes >>>>> coding more difficult if many of such return arrays are needed. >>>>> >>>>> That is why I think it would be interesting to see the julia-api side >>>>> of it, to see if this can be avoided. >>>>> (I prefer to write a bit more of C code but make the ccall clearer in >>>>> julia) >>>>> >>>>> About my previous question, I am still struggling to create a custom >>>>> type with julia's C API and fill it in, to pass it back then. >>>>> Has anyone done this in such scenario before? I wonder if the >>>>> necessary symbols are already exported for 3rd party use. >>>>> >>>>> Cheers. >>>>> >>>> >>
