Hi Tobias, thanks for you support!
I am still working on it, but when I have something ready for pushing I
will let you know.
I have two specific questions now:
1) I think that there would be a few issues with the lack of julia's
exported symbols (non-DLLEXPORTed symbols in julia.h)
The ones related to arrays and basic types are exported now, but others
are not, and therefore runtime linking errors occur.
Shall I create a diff file with a proposal of the additional ones to
DLLEXPORT, to check if you agree and we can add that to the main repo?
Having those symbols exported would also be great for anyone calling
Julia from C (aka Embedding Julia).
2) I am still not sure how to get a pointer to a module, given its name. Is
this possible with the current julia api?
I mean to be able to do something like jl_module_t *moduleptr =
jl_get_module_by_name("MyModule") or similar.
Thanks.
------------------------------------------
Carlos
On Mon, Feb 10, 2014 at 6:01 PM, Tobias Knopp
<tobias.kn...@googlemail.com>wrote:
> Fair enough, if you wrap the C-API in C++ this can get quite neat. And
> having myself pushed the documentation of the Julia C-API I definately
> think that Julia's CAPI is quite good. My intention at that time was,
> however, embedding Julia in C, in which case the C-API is definately
> required.
>
> So, it seems that you know what you are doing and for a C++ library the
> answer might not be as simple as "do it using ccall in Julia".
>
> I would welcome it if you could push your c++ wrapper into the main Julia
> source code!
>
> Cheers,
>
> Tobi
>
> Am Montag, 10. Februar 2014 17:35:38 UTC+1 schrieb Carlos Becker:
>>
>> Hi Tobias,
>>
>> model = SQBMatrixTrain( featureMatrix, labelVector, maxIters, options )
>>
>> That is how the matlab call looks like, so it is very transparent.
>> That is how I want the Julia call look like, and I think that it is
>> better to pass Julia objects directly to ccall() in those cases.
>>
>> It also offers more freedom for C/C++ programmers. I have some code
>> already working, and to me it looks neater than
>> creating new function calls to pass/return array sizes/etc, and added to
>> that my fear to mis-matched structs between C and Julia.
>>
>> For example, with what I have now working in C++, to create a struct of
>> type MyStruct from a module,
>> with members *str2, str1 *and *num*, one does:
>>
>> extern "C" {
>> void * createStructTest( void *module )
>> {
>> JL::Struct::Type s = JL::Struct::create( module, "MyStruct" );
>> JL::Struct::setField( s, "str2", "This is str2" );
>> JL::Struct::setField( s, "num", (int64_t)1234 );
>> JL::Struct::setField( s, "str2", "another string" );
>>
>> return s;
>> }
>> }
>>
>> and it automatically checks that MyStruct is a valid type, that str2 is a
>> member and it is a string,
>> that num is a member and is a int64, etc. If not, it throws a Julia
>> exception and ends cleanly.
>>
>> As I said before, I think this could help Julia newcomers when wrapping
>> their C/C++ libraries.
>>
>> Thanks.
>>
>>
>> ------------------------------------------
>> Carlos
>>
>>
>> On Mon, Feb 10, 2014 at 5:20 PM, Tobias Knopp
>> <tobias...@googlemail.com>wrote:
>>
>>>
>>> Am Montag, 10. Februar 2014 14:17:02 UTC+1 schrieb Carlos Becker:
>>>
>>>>
>>>> model = SQBMatrixTrain( featureMatrix, labelVector, maxIters, options )
>>>>
>>>
>>> Is this the function declaration of the C function or is this how you
>>> want your Julia API to look like?
>>> If its the C signature and model is a pointer to an array of structs,
>>> this function cannot be used at all as the user cannot know the length of
>>> model.
>>> Note, by the way that the length/size of an array is not a compile time
>>> parameter. It can be changed during runtime.
>>>
>>>
>>>
>>
