Why can't SWIG infer directorin:descriptor?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Why can't SWIG infer directorin:descriptor?

Lindley French
There's some friction caused by the requirement to specify directorin:descriptor. Unlike almost everything else, it takes a Java class name specified with slashes rather than dots, and since there's no way to do string substitution in a macro, you get these macros with an extra argument *just* for the variation.

Instead, couldn't SWIG look up the jstype and do a replace('.', '/') on it to get the descriptor? At least as a fallback if one isn't specified?

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|

Re: Why can't SWIG infer directorin:descriptor?

William S Fulton
On 20 May 2016 at 01:32, Lindley French <[hidden email]> wrote:
> There's some friction caused by the requirement to specify
> directorin:descriptor. Unlike almost everything else, it takes a Java class
> name specified with slashes rather than dots, and since there's no way to do
> string substitution in a macro, you get these macros with an extra argument
> *just* for the variation.
>
This is not quite right as the primitive types use descriptors such as
"I" for int and "[I" for arrays and "V" for void.

> Instead, couldn't SWIG look up the jstype and do a replace('.', '/') on it
> to get the descriptor? At least as a fallback if one isn't specified?
>
This is pretty much what happens when you use the generic descriptor, eg:

%typemap(directorin,descriptor="L$packagepath/$&javaclassname;") SWIGTYPE
%typemap(directorin,descriptor="L$packagepath/$javaclassname;") SWIGTYPE *

Can you not use the same approach (maybe with the aid of a macro)?
Currently there is a warning when the descriptor is omitted, which I
think is better than defaulting to something else that is going to be
wrong a lot of the time and will not be noticed until runtime as these
mistakes do not lead to a compilation error.

William

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|

Re: Why can't SWIG infer directorin:descriptor?

Lindley French
That default only works when you are mapping to a swig generated type. If you need to set the jstype to something else, there is no good way to convert it to the slash format automatically.

This isn't a big deal when it's for one type, but when it's for a class of types and you want to use a macro it's a problem.

On Sunday, May 22, 2016, William S Fulton <[hidden email]> wrote:
On 20 May 2016 at 01:32, Lindley French <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;lindleyf@gmail.com&#39;)">lindleyf@...> wrote:
> There's some friction caused by the requirement to specify
> directorin:descriptor. Unlike almost everything else, it takes a Java class
> name specified with slashes rather than dots, and since there's no way to do
> string substitution in a macro, you get these macros with an extra argument
> *just* for the variation.
>
This is not quite right as the primitive types use descriptors such as
"I" for int and "[I" for arrays and "V" for void.

> Instead, couldn't SWIG look up the jstype and do a replace('.', '/') on it
> to get the descriptor? At least as a fallback if one isn't specified?
>
This is pretty much what happens when you use the generic descriptor, eg:

%typemap(directorin,descriptor="L$packagepath/$&javaclassname;") SWIGTYPE
%typemap(directorin,descriptor="L$packagepath/$javaclassname;") SWIGTYPE *

Can you not use the same approach (maybe with the aid of a macro)?
Currently there is a warning when the descriptor is omitted, which I
think is better than defaulting to something else that is going to be
wrong a lot of the time and will not be noticed until runtime as these
mistakes do not lead to a compilation error.

William

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|

Re: Why can't SWIG infer directorin:descriptor?

William S Fulton
Do you have some sort of macro that equates loads of non-SWIG Java
proxy classes to C++ types? I'm just trying to understand why you
would have so many cases that providing the descriptor in by hand is
troublesome given the classes being wrapped are C++ SWIG'd classes.
Seems rather unusual.

It sounds like you want some new syntax like:

  %typemap(directorin, descriptor="L$packagepath/$jstypeclassname;")
W::X::Y * { ... }

where $jstypeclassname would look up the jstype typemap for the given
C++ type (W::X::Y *) and obtain 'X.Y' from:

  %typemap(jstype) W::X::Y * "X.Y"

and convert the descriptor into 'Lcom/me/X/Y;'.

where 'com/me' comes from the usual expansion of $packagepath.


Have you considered using this more manual approach of providing the
slashes in a made up typemap table like javadecriptor and then using
$typemap to use it as a look up table:

  %typemap(jstype) W::X::Y * "X.Y"
  %typemap(javadescriptor) W::X::Y * "X/Y"
  %typemap(directorin,descriptor="L$typemap(javadescriptor, W::X::Y
*);") W::X::Y * { ... }

Noting that if there is no 'javadescriptor' typemap you will get an
error (useful for finding missing typemaps).

Or maybe it boils down to the same problem that you don't want to
supply both "X.Y" and "X/Y" anywhere at all?

William


On 22 May 2016 at 21:34, Lindley French <[hidden email]> wrote:

> That default only works when you are mapping to a swig generated type. If
> you need to set the jstype to something else, there is no good way to
> convert it to the slash format automatically.
>
> This isn't a big deal when it's for one type, but when it's for a class of
> types and you want to use a macro it's a problem.
>
>
> On Sunday, May 22, 2016, William S Fulton <[hidden email]> wrote:
>>
>> On 20 May 2016 at 01:32, Lindley French <[hidden email]> wrote:
>> > There's some friction caused by the requirement to specify
>> > directorin:descriptor. Unlike almost everything else, it takes a Java
>> > class
>> > name specified with slashes rather than dots, and since there's no way
>> > to do
>> > string substitution in a macro, you get these macros with an extra
>> > argument
>> > *just* for the variation.
>> >
>> This is not quite right as the primitive types use descriptors such as
>> "I" for int and "[I" for arrays and "V" for void.
>>
>> > Instead, couldn't SWIG look up the jstype and do a replace('.', '/') on
>> > it
>> > to get the descriptor? At least as a fallback if one isn't specified?
>> >
>> This is pretty much what happens when you use the generic descriptor, eg:
>>
>> %typemap(directorin,descriptor="L$packagepath/$&javaclassname;") SWIGTYPE
>> %typemap(directorin,descriptor="L$packagepath/$javaclassname;") SWIGTYPE *
>>
>> Can you not use the same approach (maybe with the aid of a macro)?
>> Currently there is a warning when the descriptor is omitted, which I
>> think is better than defaulting to something else that is going to be
>> wrong a lot of the time and will not be noticed until runtime as these
>> mistakes do not lead to a compilation error.
>>
>> William

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|

Re: Why can't SWIG infer directorin:descriptor?

Lindley French
In this case it's protocol buffer classes, which are generated by protoc for both languages. Swig macros exist to pass them via serialization. However, the same problem would apply in any case where you are mapping to a category of pre existing Java types without knowing exactly which one inside the macro.

The java descriptor typemap is interesting, but doesn't entirely solve the problem.

Also, I'm not sure packagepath is useful because the Java classes in the target category are not necessarily all in the same package.

On Thursday, June 2, 2016, William S Fulton <[hidden email]> wrote:
Do you have some sort of macro that equates loads of non-SWIG Java
proxy classes to C++ types? I'm just trying to understand why you
would have so many cases that providing the descriptor in by hand is
troublesome given the classes being wrapped are C++ SWIG'd classes.
Seems rather unusual.

It sounds like you want some new syntax like:

  %typemap(directorin, descriptor="L$packagepath/$jstypeclassname;")
W::X::Y * { ... }

where $jstypeclassname would look up the jstype typemap for the given
C++ type (W::X::Y *) and obtain 'X.Y' from:

  %typemap(jstype) W::X::Y * "X.Y"

and convert the descriptor into 'Lcom/me/X/Y;'.

where 'com/me' comes from the usual expansion of $packagepath.


Have you considered using this more manual approach of providing the
slashes in a made up typemap table like javadecriptor and then using
$typemap to use it as a look up table:

  %typemap(jstype) W::X::Y * "X.Y"
  %typemap(javadescriptor) W::X::Y * "X/Y"
  %typemap(directorin,descriptor="L$typemap(javadescriptor, W::X::Y
*);") W::X::Y * { ... }

Noting that if there is no 'javadescriptor' typemap you will get an
error (useful for finding missing typemaps).

Or maybe it boils down to the same problem that you don't want to
supply both "X.Y" and "X/Y" anywhere at all?

William


On 22 May 2016 at 21:34, Lindley French <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;lindleyf@gmail.com&#39;)">lindleyf@...> wrote:
> That default only works when you are mapping to a swig generated type. If
> you need to set the jstype to something else, there is no good way to
> convert it to the slash format automatically.
>
> This isn't a big deal when it's for one type, but when it's for a class of
> types and you want to use a macro it's a problem.
>
>
> On Sunday, May 22, 2016, William S Fulton <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;wsf@fultondesigns.co.uk&#39;)">wsf@...> wrote:
>>
>> On 20 May 2016 at 01:32, Lindley French <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;lindleyf@gmail.com&#39;)">lindleyf@...> wrote:
>> > There's some friction caused by the requirement to specify
>> > directorin:descriptor. Unlike almost everything else, it takes a Java
>> > class
>> > name specified with slashes rather than dots, and since there's no way
>> > to do
>> > string substitution in a macro, you get these macros with an extra
>> > argument
>> > *just* for the variation.
>> >
>> This is not quite right as the primitive types use descriptors such as
>> "I" for int and "[I" for arrays and "V" for void.
>>
>> > Instead, couldn't SWIG look up the jstype and do a replace('.', '/') on
>> > it
>> > to get the descriptor? At least as a fallback if one isn't specified?
>> >
>> This is pretty much what happens when you use the generic descriptor, eg:
>>
>> %typemap(directorin,descriptor="L$packagepath/$&javaclassname;") SWIGTYPE
>> %typemap(directorin,descriptor="L$packagepath/$javaclassname;") SWIGTYPE *
>>
>> Can you not use the same approach (maybe with the aid of a macro)?
>> Currently there is a warning when the descriptor is omitted, which I
>> think is better than defaulting to something else that is going to be
>> wrong a lot of the time and will not be noticed until runtime as these
>> mistakes do not lead to a compilation error.
>>
>> William

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user
Reply | Threaded
Open this post in threaded view
|

Re: Why can't SWIG infer directorin:descriptor?

William S Fulton
The jstype does not usually contain the package name though for SWIG
wrapped classes though. As you've got some hybrid, leaving out
packagepath would be okay like for a pure Java class.

I still don't think an empty descriptor is a good idea, so do you have
any other suggestions apart from the $jstypeclassname that I
mentioned? How about providing a patch for this new special variable
and I'll review it for inclusion in a future release?.

William

On 4 June 2016 at 04:36, Lindley French <[hidden email]> wrote:

> In this case it's protocol buffer classes, which are generated by protoc for
> both languages. Swig macros exist to pass them via serialization. However,
> the same problem would apply in any case where you are mapping to a category
> of pre existing Java types without knowing exactly which one inside the
> macro.
>
> The java descriptor typemap is interesting, but doesn't entirely solve the
> problem.
>
> Also, I'm not sure packagepath is useful because the Java classes in the
> target category are not necessarily all in the same package.
>
>
> On Thursday, June 2, 2016, William S Fulton <[hidden email]> wrote:
>>
>> Do you have some sort of macro that equates loads of non-SWIG Java
>> proxy classes to C++ types? I'm just trying to understand why you
>> would have so many cases that providing the descriptor in by hand is
>> troublesome given the classes being wrapped are C++ SWIG'd classes.
>> Seems rather unusual.
>>
>> It sounds like you want some new syntax like:
>>
>>   %typemap(directorin, descriptor="L$packagepath/$jstypeclassname;")
>> W::X::Y * { ... }
>>
>> where $jstypeclassname would look up the jstype typemap for the given
>> C++ type (W::X::Y *) and obtain 'X.Y' from:
>>
>>   %typemap(jstype) W::X::Y * "X.Y"
>>
>> and convert the descriptor into 'Lcom/me/X/Y;'.
>>
>> where 'com/me' comes from the usual expansion of $packagepath.
>>
>>
>> Have you considered using this more manual approach of providing the
>> slashes in a made up typemap table like javadecriptor and then using
>> $typemap to use it as a look up table:
>>
>>   %typemap(jstype) W::X::Y * "X.Y"
>>   %typemap(javadescriptor) W::X::Y * "X/Y"
>>   %typemap(directorin,descriptor="L$typemap(javadescriptor, W::X::Y
>> *);") W::X::Y * { ... }
>>
>> Noting that if there is no 'javadescriptor' typemap you will get an
>> error (useful for finding missing typemaps).
>>
>> Or maybe it boils down to the same problem that you don't want to
>> supply both "X.Y" and "X/Y" anywhere at all?
>>
>> William
>>
>>
>> On 22 May 2016 at 21:34, Lindley French <[hidden email]> wrote:
>> > That default only works when you are mapping to a swig generated type.
>> > If
>> > you need to set the jstype to something else, there is no good way to
>> > convert it to the slash format automatically.
>> >
>> > This isn't a big deal when it's for one type, but when it's for a class
>> > of
>> > types and you want to use a macro it's a problem.
>> >
>> >
>> > On Sunday, May 22, 2016, William S Fulton <[hidden email]>
>> > wrote:
>> >>
>> >> On 20 May 2016 at 01:32, Lindley French <[hidden email]> wrote:
>> >> > There's some friction caused by the requirement to specify
>> >> > directorin:descriptor. Unlike almost everything else, it takes a Java
>> >> > class
>> >> > name specified with slashes rather than dots, and since there's no
>> >> > way
>> >> > to do
>> >> > string substitution in a macro, you get these macros with an extra
>> >> > argument
>> >> > *just* for the variation.
>> >> >
>> >> This is not quite right as the primitive types use descriptors such as
>> >> "I" for int and "[I" for arrays and "V" for void.
>> >>
>> >> > Instead, couldn't SWIG look up the jstype and do a replace('.', '/')
>> >> > on
>> >> > it
>> >> > to get the descriptor? At least as a fallback if one isn't specified?
>> >> >
>> >> This is pretty much what happens when you use the generic descriptor,
>> >> eg:
>> >>
>> >> %typemap(directorin,descriptor="L$packagepath/$&javaclassname;")
>> >> SWIGTYPE
>> >> %typemap(directorin,descriptor="L$packagepath/$javaclassname;")
>> >> SWIGTYPE *
>> >>
>> >> Can you not use the same approach (maybe with the aid of a macro)?
>> >> Currently there is a warning when the descriptor is omitted, which I
>> >> think is better than defaulting to something else that is going to be
>> >> wrong a lot of the time and will not be noticed until runtime as these
>> >> mistakes do not lead to a compilation error.
>> >>
>> >> William

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Swig-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/swig-user