On Tuesday, 19 May 2015 at 08:09:33 UTC, Suliman wrote:
> modmap (C++) "<gdalwarper>";
>
> import std.stdio;
>
> void main()
> {
> 	GDALDatasetH  hSrcDS, hDstDS;
> 	GDALAllRegister();
> 	writeln("hello");
> }
>
>
> error:
> app.d(7): Error: undefined identifier GDALDatasetH
> app.d(7): Error: undefined identifier GDALDatasetH
> app.d(8): Error: undefined identifier GDALAllRegister

Perhaps you also need to include the GDAL headers, as I suspect gdalwarper doesn't define GDALDatasetH.

On Tuesday, 19 May 2015 at 08:09:33 UTC, Suliman wrote:
> modmap (C++) "<gdalwarper>";
>
> import std.stdio;
>
> void main()
> {
> 	GDALDatasetH  hSrcDS, hDstDS;
> 	GDALAllRegister();
> 	writeln("hello");
> }
>
>
> error:
> app.d(7): Error: undefined identifier GDALDatasetH
> app.d(7): Error: undefined identifier GDALDatasetH
> app.d(8): Error: undefined identifier GDALAllRegister


Hello Suliman,

I have translated the GDAL example ( http://www.gdal.org/warptut.html ) and got it to run...woohoo!! I needed to apply the fix from Elie last night (and the pull request from me that hasn't been accepted yet), so this won't work for you yet, unfortunately...soon hopefully.

For comparison I have posted the translation here ( http://pastebin.com/VwrVeBJ3 ), but it may be a day or two yet before Calypso can compile it out-of-the-box, even if my pull requrest is accepted today. There is still one outstanding error that I couldn't fix. I had to cheat and modify a system file (not a good thing to ask others to do, obviously)!!

As you can see the differences between the two examples are pretty minimal. Things like using '.' instead of '->'. Having to 'new' the GDALWarpOperation, and another slightly subtle change -- we need to use an ampersand for the function pointer assignment of GDALTermProgress/GDALAGenImgProjTransform.

Also notice that we needed to explicitly modmap cpl_conv.h to get access to CPLMalloc. In addition, we have to be explicit about which structs/classes to 'import'.

I have not tested this on Windows! I haven't even built Calypso on Windows yet...so I may not be able to help much with Windows errors. Just so you know.

Thanks,
Kelly

On Tuesday, 19 May 2015 at 16:33:00 UTC, CraigDillabaugh wrote:
> On Tuesday, 19 May 2015 at 08:09:33 UTC, Suliman wrote:
>> modmap (C++) "<gdalwarper>";
>>
>> import std.stdio;
>>
>> void main()
>> {
>> 	GDALDatasetH  hSrcDS, hDstDS;
>> 	GDALAllRegister();
>> 	writeln("hello");
>> }
>>
>>
>> error:
>> app.d(7): Error: undefined identifier GDALDatasetH
>> app.d(7): Error: undefined identifier GDALDatasetH
>> app.d(8): Error: undefined identifier GDALAllRegister
>
> Perhaps you also need to include the GDAL headers, as I suspect gdalwarper doesn't define GDALDatasetH.


Hi Craig,

The method here is to actually 'import (C++) _;' since that '_' will make Calypso import all the global functions/variables/typedefs in gdalwarper.

This works for namespaces also, so if you have a namespace in a different example called MySpace, then calling 'import (C++) MySpace._;' will import all the functions/variables/typedefs in the namespace and make them accessible in your D file.

If you just have a single class in the MySpace namespace called 'myclass', and you would like to use it in your D program, then use 'import (C++) MySpace.myclass;' to import it. Then instantiate the class in D and use it from there.

Thanks,
Kelly

On Tuesday, 19 May 2015 at 17:31:07 UTC, Kelly wrote:
> On Tuesday, 19 May 2015 at 16:33:00 UTC, CraigDillabaugh wrote:
>> On Tuesday, 19 May 2015 at 08:09:33 UTC, Suliman wrote:
>>> modmap (C++) "<gdalwarper>";
>>>
>>> import std.stdio;
>>>
>>> void main()
>>> {
>>> 	GDALDatasetH  hSrcDS, hDstDS;
>>> 	GDALAllRegister();
>>> 	writeln("hello");
>>> }
>>>
>>>
>>> error:
>>> app.d(7): Error: undefined identifier GDALDatasetH
>>> app.d(7): Error: undefined identifier GDALDatasetH
>>> app.d(8): Error: undefined identifier GDALAllRegister
>>
>> Perhaps you also need to include the GDAL headers, as I suspect gdalwarper doesn't define GDALDatasetH.
>
>
> Hi Craig,
>
> The method here is to actually 'import (C++) _;' since that '_' will make Calypso import all the global functions/variables/typedefs in gdalwarper.
>
> This works for namespaces also, so if you have a namespace in a different example called MySpace, then calling 'import (C++) MySpace._;' will import all the functions/variables/typedefs in the namespace and make them accessible in your D file.
>
> If you just have a single class in the MySpace namespace called 'myclass', and you would like to use it in your D program, then use 'import (C++) MySpace.myclass;' to import it. Then instantiate the class in D and use it from there.
>
> Thanks,
> Kelly

Kelly,

Just to clarify then.  If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too?

Craig

>import (C++) GDALWarpOperation;
>import (C++) GDALAccess;
>import (C++) GDALWarpOptions;

How do you understand which files should be imported?

> GDALWarpOptions* psWarpOptions = GDALCreateWarpOptions();
GDALWarpOptions* is type?
would:
auto psWarpOptions = GDALCreateWarpOptions();
work?

>Windows
I hope to be able to test it in nearest time. As I wrote before I have not enough knowlages to build it's by myself, so I will wait bin builds.

>  If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too?

+1 for question!

On Tuesday, 19 May 2015 at 17:44:38 UTC, CraigDillabaugh wrote:
> Just to clarify then.  If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too?
>
> Craig

On Tuesday, 19 May 2015 at 19:57:45 UTC, Suliman wrote:
> How do you understand which files should be imported?
>
> +1 for question!

modmap is only telling Clang which headers to parse. Then all those headers form a big monolithic AST that Calypso split into modules following a few rules:

  import (C++) namespace1.testStruct; // imports namespace1::testStruct
  import (C++) namespace2.testClass; // imports namespace2::testClass
  import (C++) test.anotherClass; // etc. each struct/class/enum template or not is placed in a module named after it
  import (C++) test.tempWithPartialSpecs; // imports the primary class template + all its partial and explicit specializations
  import (C++) test._; // « _ » is a special module that contains all the global variables, global functions and typedefs of a namespace (the ones which aren't nested inside a struct or a class, or another namespace).

Why the header paths can't be used in imports is explained here:

http://syniurge.blogspot.fr/2013/08/calypso-to-mars-first-contact.html#namingquestion

Documentation is scarce at the moment, the examples (starting with showcase.d) try to give a quick overview of how to use Calypso but yep we really should write a tutorial of some sort, either I or Kelly will do it before DConf.

On Tuesday, 19 May 2015 at 17:44:38 UTC, CraigDillabaugh wrote:
> Just to clarify then.  If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too?
>
> Craig

So to give a more straight answer, modmap "is" an #include directive so every header gdalwarper.h includes will be parsed too. But it doesn't import anything.

On Sunday, 17 May 2015 at 13:37:45 UTC, Suliman wrote:
> Where set where Calypso should look header files?

It works the same as in C++, there are the standard header paths: /usr/include, /usr/include/c++/4.9, /usr/local/include

And to add another header search path you can pass options to Clang with -cpp-args, i.e « ldc2 (...) -cpp-args -I/another/include/folder ».

With the MingW version all those Unix paths refer to the MingW root directory.

On Tuesday, 19 May 2015 at 19:57:45 UTC, Suliman wrote:
>
>>import (C++) GDALWarpOperation;
>>import (C++) GDALAccess;
>>import (C++) GDALWarpOptions;
>
> How do you understand which files should be imported?
>

These aren't files being imported, they are classes/structs/templates being imported for use. Files are 'modmap'ed not imported in Calypso.

It can be tricky to know which classes/structs/templates need to be imported if you aren't writing a program from scratch AND know the library fairly well. What you can do is run Calypso and if it complains that there is an 'undefined identifier', then check to see if that identifier is a class/struct/template and try to import it to see if the problem is fixed. Not an ideal programming philosophy, of course, but it can help at the beginning to let Calypso do some work for you.

There are also clues in the source code...if you have to 'new' anything then it will need probably to be imported.

>> GDALWarpOptions* psWarpOptions = GDALCreateWarpOptions();
> GDALWarpOptions* is type?
> would:
> auto psWarpOptions = GDALCreateWarpOptions();
> work?
>

This actually ties in with the question above...and yes, 'auto' will work. 'Auto' is definitely your friend with Calypso, as sometimes it isn't clear what the C++ type would translate into. Now the big thing with 'auto', in this case, is that if you use 'auto' then you don't even need the 'import (C++) GDALWarpOptions'!!!! Calypso will figure it out and do it for you.

This is a bit of a double edge sword though, because sometimes you will really want/need to know the type you are dealing with and what it translates into. Hopefully this doesn't happen too often.

>>Windows
> I hope to be able to test it in nearest time. As I wrote before I have not enough knowlages to build it's by myself, so I will wait bin builds.
>
>> If gdalwarper.h includes gdal.h and GDALDatasetH is declared in gdal.h, then gdal.h gets imported too?
>
> +1 for question!


Since everything in the headers on the C++ side is sort of mashed together into the PCH (pre-compiled header) file, and you import every global variable/typedef/function/namespace using the special "_", then you can get access to all of these globals via the one modmap of gdalwarper.h.

Some more well-behaved libraries that have multiple namespaces can be easier to deal with because you can be quite specific with what you want to import, instead of just importing 'EVERYTHING' and then only using a small portion of it.


This is an "As far as I understand it!!!" type of answer designed to be a little less technical. Please see Elie's answers to these questions for a more technical and in depth explanation (and the CORRECT explanation, as I may be somewhat off in my interpretation here :) !! )

Thanks,
Kelly

On Monday, 18 May 2015 at 12:27:35 UTC, Kagamin wrote:
> BTW how does it rely on having everything on the D side? Maybe it's enough to have just instance size and method symbols?

I'm not sure what you mean.

> But then there's problem with this inference: what if the type is intended to be used as a reference type and you infer it to be POD, and it can also flicker between POD and non-POD depending on defines.

This is true and it may not even be rare: turning C++11 on or off is doing it for some Qt classes.

But there is another issue that will make me revisit their semantics anyway, it's that C++ structs and classes shouldn't be garbage collected because they weren't made with GC in mind and might have weak refs. So unless someone has a better solution C++ classes will go back to manual memory management, and the plan is while changing class and "new"'s semantics to also make all C++ classes values.