[gdal-dev] Bindings
Hi, I've been trying to find a way to make the common SWIG interface files less concerned about languages and the whole system more flexible and understandable (which I see a prerequisite for further developments). My conclusion seems to be now that it is probably better to make the main files, what are now gdal.i, ogr.i etc., language specific and only the class files, now ColorTable.i, MajorObject.i, etc., and some other files (typedefs.i etc.) common. That way each language could compose the module as they like. For example in Perl I would like to get rid of Const, and a language could put all classes into one module (gdal) etc. This would at least require extracting remaining common material in gdal.i and ogr.i into new files. I'll test this in my github fork - which I've mentioned a couple of times already. But it will probably take some time due to summer etc. Any comments on this? This is again just internal reorganization and does not affect the APIs. Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings
Hi Ari, Creating language specific main files would be fine for me. We could also add the "language specific extensions" at the bottom section (like gdal_csharp_extend.i) directly into the file. We should however make sure to update all relevant files if a common change is done in a language specific file. Best regards, Tamas 2015-06-04 16:35 GMT+02:00 Ari Jolma : > Hi, > > I've been trying to find a way to make the common SWIG interface files > less concerned about languages and the whole system more flexible and > understandable (which I see a prerequisite for further developments). > > My conclusion seems to be now that it is probably better to make the main > files, what are now gdal.i, ogr.i etc., language specific and only the > class files, now ColorTable.i, MajorObject.i, etc., and some other files > (typedefs.i etc.) common. That way each language could compose the module > as they like. For example in Perl I would like to get rid of Const, and a > language could put all classes into one module (gdal) etc. > > This would at least require extracting remaining common material in gdal.i > and ogr.i into new files. > > I'll test this in my github fork - which I've mentioned a couple of times > already. But it will probably take some time due to summer etc. > > Any comments on this? This is again just internal reorganization and does > not affect the APIs. > > Ari > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Bindings and typemaps
Even,
It took me quite a while again to understand what goes on with Swig when
we %apply a typemap etc.
I think we could simplify the things quite a lot if we simply use
typedefs and then create typemaps for the return values.
For example CPLErr is never returned to the calling language (I think,
but it could in any case be defined by the language typemap), thus we
could simply define typemaps for it in language specific files instead
of repeating
%apply (IF_ERROR_RETURN_NONE) { (CPLErr) };
...
%clear (CPLErr);
in the include/*.i files.
Also sometimes GDAL has simple int instead of CPLErr, which is used as a
success/failure return value, then we could (like we already do) write
typedef int RETURN_NONE;
(actually we have also
typedef int OGRErr;
for SWIGCSHARP, which is invented for the same reason I assume)
and then define typemaps for the new type and skip again
%apply (IF_FALSE_RETURN_NONE) { (RETURN_NONE) };
...
%clear (RETURN_NONE);
which is overkill (and I believe I introduced that).
BTW, RETURN_NONE is not a good name, maybe use TRUE_OR_FALSE or
something more descriptive.
Best,
Ari
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
Le dimanche 08 mars 2015 22:20:50, Ari Jolma a écrit :
> Even,
>
> It took me quite a while again to understand what goes on with Swig when
> we %apply a typemap etc.
>
> I think we could simplify the things quite a lot if we simply use
> typedefs and then create typemaps for the return values.
>
> For example CPLErr is never returned to the calling language (I think,
> but it could in any case be defined by the language typemap), thus we
> could simply define typemaps for it in language specific files instead
> of repeating
>
> %apply (IF_ERROR_RETURN_NONE) { (CPLErr) };
> ...
> %clear (CPLErr);
>
> in the include/*.i files.
>
> Also sometimes GDAL has simple int instead of CPLErr, which is used as a
> success/failure return value, then we could (like we already do) write
>
> typedef int RETURN_NONE;
>
> (actually we have also
>
> typedef int OGRErr;
>
> for SWIGCSHARP, which is invented for the same reason I assume)
>
> and then define typemaps for the new type and skip again
>
> %apply (IF_FALSE_RETURN_NONE) { (RETURN_NONE) };
> ...
> %clear (RETURN_NONE);
>
> which is overkill (and I believe I introduced that).
>
> BTW, RETURN_NONE is not a good name, maybe use TRUE_OR_FALSE or
> something more descriptive.
Ari,
Your proposal looks reasonable (but I don't pretend mastering SWIG and
anticipating all side effects) and you can experiment with that if you wish.
Please make sure to test the 4 supported languages. If there are breakage you
don't know how to fix, it will require coordination with me and Tamas and that
should perhaps be done through a ticket with a patch, or a dedicated branch.
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
08.03.2015, 23:49, Even Rouault kirjoitti: Le dimanche 08 mars 2015 22:20:50, Ari Jolma a écrit : Ari, Your proposal looks reasonable (but I don't pretend mastering SWIG and anticipating all side effects) and you can experiment with that if you wish. Please make sure to test the 4 supported languages. If there are breakage you don't know how to fix, it will require coordination with me and Tamas and that should perhaps be done through a ticket with a patch, or a dedicated branch. Wouldn't the whole thing be best to be a branch from the beginning. If I branch the whole swig tree like this http://emilsblog.lerch.org/2010/03/working-with-feature-branch-in.html then it would assumably be quite simple to test all the changes in all languages. I don't know how to test C# and Java bindings. Especially C# is probably out of what I can do. Ari Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
Le lundi 09 mars 2015 08:08:34, Ari Jolma a écrit : > 08.03.2015, 23:49, Even Rouault kirjoitti: > > Le dimanche 08 mars 2015 22:20:50, Ari Jolma a écrit : > > > > Ari, > > > > Your proposal looks reasonable (but I don't pretend mastering SWIG and > > anticipating all side effects) and you can experiment with that if you > > wish. Please make sure to test the 4 supported languages. If there are > > breakage you don't know how to fix, it will require coordination with me > > and Tamas and that should perhaps be done through a ticket with a patch, > > or a dedicated branch. > > Wouldn't the whole thing be best to be a branch from the beginning. Yes probably. > If I > branch the whole swig tree like this > > http://emilsblog.lerch.org/2010/03/working-with-feature-branch-in.html > > then it would assumably be quite simple to test all the changes in all > languages. Yes, I generally branch a whole repository, but a subtree might do too. Or if you prefer Git, you could fork https://github.com/OSGeo/gdal > I don't know how to test C# and Java bindings. Especially C# > is probably out of what I can do. > > Ari > > > Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
09.03.2015, 11:18, Even Rouault kirjoitti: Le lundi 09 mars 2015 08:08:34, Ari Jolma a écrit : 08.03.2015, 23:49, Even Rouault kirjoitti: Le dimanche 08 mars 2015 22:20:50, Ari Jolma a écrit : Ari, Your proposal looks reasonable (but I don't pretend mastering SWIG and anticipating all side effects) and you can experiment with that if you wish. Please make sure to test the 4 supported languages. If there are breakage you don't know how to fix, it will require coordination with me and Tamas and that should perhaps be done through a ticket with a patch, or a dedicated branch. Wouldn't the whole thing be best to be a branch from the beginning. Yes probably. I'll do that. IMO the goal would be to reduce language specific ifdefs from the general bindings, and remove unnecessary typedefs. For example there are a lot of #ifndef SWIGJAVA %feature( "kwargs" ) CopyLayer; #endif Is there a reason keywords arguments are not enabled with -keyword option for languages that support them? Ari If I branch the whole swig tree like this http://emilsblog.lerch.org/2010/03/working-with-feature-branch-in.html then it would assumably be quite simple to test all the changes in all languages. Yes, I generally branch a whole repository, but a subtree might do too. Or if you prefer Git, you could fork https://github.com/OSGeo/gdal I don't know how to test C# and Java bindings. Especially C# is probably out of what I can do. Ari Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
09.03.2015, 11:18, Even Rouault kirjoitti: Or if you prefer Git, you could fork https://github.com/OSGeo/gdal I did this fork and made the changes in my copy. Then made a pull request and now it says that the Travis CI build passed. But I assume Java etc. are not tested by Travis? Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
Le lundi 09 mars 2015 14:27:05, Ari Jolma a écrit : > 09.03.2015, 11:18, Even Rouault kirjoitti: > > Or if you prefer Git, you could fork https://github.com/OSGeo/gdal > > I did this fork and made the changes in my copy. Then made a pull > request and now it says that the Travis CI build passed. > > But I assume Java etc. are not tested by Travis? The Java, Perl and Python bindings are tested by Travis. See .travis.yml at the root of the repository I've just added in Vagrant the ability to build the Java and CSharp bindings, as well as Perl and Python. It turns out that Swig 2.0.4 that comes with Ubuntu 12.04 isn't compatible with the CSharp bindings. So the .cpp files are generated by a manually compiled swig 1.3.40. But at runtime I get a linking failure. > > Ari -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
I'm curious about the setup. Do you commit to github, which then commits to trac.osgeo.org/gdal or how is the system setup? Ari 09.03.2015, 15:31, Even Rouault kirjoitti: Le lundi 09 mars 2015 14:27:05, Ari Jolma a écrit : 09.03.2015, 11:18, Even Rouault kirjoitti: Or if you prefer Git, you could fork https://github.com/OSGeo/gdal I did this fork and made the changes in my copy. Then made a pull request and now it says that the Travis CI build passed. But I assume Java etc. are not tested by Travis? The Java, Perl and Python bindings are tested by Travis. See .travis.yml at the root of the repository I've just added in Vagrant the ability to build the Java and CSharp bindings, as well as Perl and Python. It turns out that Swig 2.0.4 that comes with Ubuntu 12.04 isn't compatible with the CSharp bindings. So the .cpp files are generated by a manually compiled swig 1.3.40. But at runtime I get a linking failure. Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
Le lundi 09 mars 2015 14:47:48, Ari Jolma a écrit : > I'm curious about the setup. > > Do you commit to github, which then commits to trac.osgeo.org/gdal or > how is the system setup? Regarding Travis, this is vaguely described at http://trac.osgeo.org/gdal/wiki/Buildbot Basically I've a cron job that use git-svn to mirror svn history into git Regarding my usual commits habits, I usually just svn commit. When I do development in git branches, I may use git svn dcommit to commit back into SVN, but you can only do that on your own git-svn mirror, not a fork of https://github.com/OSGeo/gdal. Rougly described at https://trac.osgeo.org/gdal/wiki/UsingGitToMaintainGDALWorkflow Otherwise I create a git patch and apply it in a SVN repository (with caution to manually svn add new files). Regarding Vagrant, this is described here: https://trac.osgeo.org/gdal/wiki/Vagrant > > Ari > > 09.03.2015, 15:31, Even Rouault kirjoitti: > > Le lundi 09 mars 2015 14:27:05, Ari Jolma a écrit : > >> 09.03.2015, 11:18, Even Rouault kirjoitti: > >>> Or if you prefer Git, you could fork https://github.com/OSGeo/gdal > >> > >> I did this fork and made the changes in my copy. Then made a pull > >> request and now it says that the Travis CI build passed. > >> > >> But I assume Java etc. are not tested by Travis? > > > > The Java, Perl and Python bindings are tested by Travis. See .travis.yml > > at the root of the repository > > > > I've just added in Vagrant the ability to build the Java and CSharp > > bindings, as well as Perl and Python. It turns out that Swig 2.0.4 that > > comes with Ubuntu 12.04 isn't compatible with the CSharp bindings. So > > the .cpp files are generated by a manually compiled swig 1.3.40. But at > > runtime I get a linking failure. > > > >> Ari -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Bindings for the histogram method of band
The trac.osgeo.org does not answer so I'll put this here.
Hobu, would it be ok to have (int len, int *output) typemap. They can be
used in GetHistogram method like this (note that the API is same for C#
but it must use different typemaps. From Band.i:
#ifndef SWIGCSHARP
%feature( "kwargs" ) GetHistogram;
%apply (int len, int *output) {(int nBuckets, int *panHistogram)};
%apply (IF_ERROR_RETURN_NONE) { (CPLErr) };
#else
%apply (int inout[ANY]) {int *panHistogram};
#endif /* SWIGCSHARP */
CPLErr GetHistogram( double dfMin=-0.5,
double dfMax=255.5,
int nBuckets=256, /* as in GDAL docs */
int *panHistogram = NULL,
int bIncludeOutOfRange = 0,
int bApproxOk = 1,
GDALProgressFunc callback = NULL,
void* callback_data=NULL ) {
return GDALGetRasterHistogram( self,
dfMin,
dfMax,
nBuckets,
panHistogram,
bIncludeOutOfRange,
bApproxOk,
callback,
callback_data);
}
#ifndef SWIGCSHARP
%clear (int nBuckets, int *panHistogram);
%clear (CPLErr);
#else
%clear int *panHistogram;
#endif /* SWIGCSHARP */
And the typemaps for Perl: Note the slight abuse of check for malloc.
This is tested and works.
%typemap(in,numinputs=1) (int len, int *output)
{
/* %typemap(in,numinputs=1) (int len, int *output) */
$1 = SvIV($input);
}
%typemap(check) (int len, int *output)
{
/* %typemap(check) (int len, int *output) */
if ($1 < 1) $1 = 1; /* stop idiocy */
$2 = (int *)CPLMalloc( $1 * sizeof(int) );
}
%typemap(argout,fragment="CreateArrayFromIntArray") (int len, int *output)
{
/* %typemap(argout) (int len, int *output) */
$result = CreateArrayFromIntArray( $2, $1 );
argvi++;
}
%typemap(freearg) (int len, int *output)
{
/* %typemap(freearg) (int len, int *output) */
CPLFree($2);
}
Ari
--
Prof. Ari Jolma
Geoinformatiikka / Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
tel: +358 9 451 3886 address: POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings for the histogram method of band
On Jul 22, 2008, at 9:48 AM, Ari Jolma wrote:
The trac.osgeo.org does not answer so I'll put this here.
Hobu, would it be ok to have (int len, int *output) typemap. They
can be used in GetHistogram method like this (note that the API is
same for C# but it must use different typemaps. From Band.i:
%typemap(check) (int len, int *output)
{
/* %typemap(check) (int len, int *output) */
if ($1 < 1) $1 = 1; /* stop idiocy */
$2 = (int *)CPLMalloc( $1 * sizeof(int) );
}
Ari,
This isn't too different from what I proposed except for I think that
abusing the check typemap like that (malloc'ing the integer array) is
a recipe for disaster. The check typemap could possibly be run
multiple times, right? Otherwise, it looks pretty close to what I had
for a proposal http://trac.osgeo.org/gdal/changeset/14941 .
I'm open to changing the GetHistogram function signature within Band.i
however you guys wish (ideally to support just using (int len, int
*output) and not having a special typemap for just this function), and
while it would be nice that we wouldn't need the #ifdefs for every
possible language we might ever support ;), it's not the end of the
world either...
Howard
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings for the histogram method of band
Using the same approach for the csharp bindings seems much more
complicated than the current method. Currently the caller (at the
csharp side) allocates a fixed length int array and the default
marshaler takes care of passing the array to the unmanaged (C) part of
the code. There's no need to do extra memory allocations inside the
wrapper code and using the existing 'int argin[ANY]' typemap does the
right thing when mapping this type.
Since I continue to think about a different implementation for c# I
leave the decision about this topic to the other bindings maintainers.
Best regards,
Tamas
2008/7/22 Howard Butler <[EMAIL PROTECTED]>:
>
> On Jul 22, 2008, at 9:48 AM, Ari Jolma wrote:
>
>> The trac.osgeo.org does not answer so I'll put this here.
>>
>> Hobu, would it be ok to have (int len, int *output) typemap. They can be
>> used in GetHistogram method like this (note that the API is same for C# but
>> it must use different typemaps. From Band.i:
>>
>> %typemap(check) (int len, int *output)
>> {
>> /* %typemap(check) (int len, int *output) */
>> if ($1 < 1) $1 = 1; /* stop idiocy */
>> $2 = (int *)CPLMalloc( $1 * sizeof(int) );
>> }
>
>
> Ari,
>
> This isn't too different from what I proposed except for I think that
> abusing the check typemap like that (malloc'ing the integer array) is a
> recipe for disaster. The check typemap could possibly be run multiple
> times, right? Otherwise, it looks pretty close to what I had for a proposal
> http://trac.osgeo.org/gdal/changeset/14941 .
>
> I'm open to changing the GetHistogram function signature within Band.i
> however you guys wish (ideally to support just using (int len, int *output)
> and not having a special typemap for just this function), and while it would
> be nice that we wouldn't need the #ifdefs for every possible language we
> might ever support ;), it's not the end of the world either...
>
> Howard
>
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings for the histogram method of band
Howard Butler kirjoitti:
On Jul 22, 2008, at 9:48 AM, Ari Jolma wrote:
The trac.osgeo.org does not answer so I'll put this here.
Hobu, would it be ok to have (int len, int *output) typemap. They can
be used in GetHistogram method like this (note that the API is same
for C# but it must use different typemaps. From Band.i:
%typemap(check) (int len, int *output)
{
/* %typemap(check) (int len, int *output) */
if ($1 < 1) $1 = 1; /* stop idiocy */
$2 = (int *)CPLMalloc( $1 * sizeof(int) );
}
Ari,
This isn't too different from what I proposed except for I think that
abusing the check typemap like that (malloc'ing the integer array) is
a recipe for disaster. The check typemap could possibly be run
multiple times, right? Otherwise, it looks pretty close to what I had
for a proposal http://trac.osgeo.org/gdal/changeset/14941 .
Yes.. in fact I just merged the two signatures (which are the same),
changed the default nBuckets to 256 (as in GDAL docs) and added the (int
len, int *output) typemap for non-c#. Ok, so you're suggesting I make
that typemap #ifdef Perl. I don't think check is ever run multiple times
for one match. Using check typemap seems to be the only possibility, if
I want to keep the signature unchaged (I was first proposing a change to
it in the trac message).
I'm for generic typemaps and returning an integer array from a C
function with (int len, int *output) pattern is one IMHO.
Ok, I'll commit this change so that it does nothing for other languages
than Perl.
Cheers,
Ari
I'm open to changing the GetHistogram function signature within Band.i
however you guys wish (ideally to support just using (int len, int
*output) and not having a special typemap for just this function), and
while it would be nice that we wouldn't need the #ifdefs for every
possible language we might ever support ;), it's not the end of the
world either...
Howard
--
Prof. Ari Jolma
Geoinformatiikka / Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
tel: +358 9 451 3886 address: POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
