William,

I've read through the patch, sorry I couldn't do it earlier.

Don't worry.

 

I suggest you don't bother with the director examples until this feature is working.


Ok
 

By convention we don't use a : in typemap names. Can you change the 'pasrawtype:import' and similar typemap names accordingly? Perhaps you should have an "import" typemap attribute instead on the appropriate typemap? For example,

 %typemap(pasrawtype, import="Classes, SysUtils") type "code"

Or we use limited use of '_' in the typemap names, and this might be a good case.

I copyed the schema of typemaps name from the Modula 3 's Module. If you look at it, you will find the same kind of naming (at least in the version I used as base for my module)

Anyway I can change the typemaps as you suggested


There are a lot of different typemaps. Are they analogous to the C# typemaps? I don't really recognise the names you have used, I think you have a much larger set, which does surprise me a bit as I thought the C# list was rather extensive. It would be good to draw up a list of the equivalents (like the java/c# list in CSharp.html) and name them accordingly, if they are equivalents. C# has the widest range of typemaps and would be the best to try and match.

As above, I have more or less the same amount of typemaps of Modula3


Please move all author names into the README file, eg remove from dllnames_fixup.pl, delphi.cxx and others. Use the standard header as a replacement. Likewise for generated code, eg in emitBanner().

Ok
 

Check that the warning numbers in swigwarn.h don't clash with the gsoc projects... there was an email about this a week or two back.

Ok, at the time of the beginning of my projects gsoc did not yet existed.
 

delphi.cxx:
- Please remove the Modula3 comments near the top.
Ok

- Remove STL usage and replace with DOH containers/string. Sorry!
:-(

- Replace char * with String use DOH library instead of C string library wherever possible.

Ok, when I started I had a very limited knowledge of DOH
 
- Remove any compiler specific code (_MSC_VER) and use portable code.

I used it only for one stdlib function that is not available on gcc (I think it's strlwr)
 

- Please format the code using the beautify targets in Source/Makefile.am
Ok

- Use DOH's Split instead of the SplitString utility.
Ok
 
- In writeArg() and others, __ prefix is illegal in C++. Looks like you are using char * because of missing string handling in DOH. Please add it into DOH instead. Also we don't name variables with a leading underscore.

I used some char * variables prefixed by __ for debugging purpose (Now I found as use the debugger to look inside a DOH string)
 
- The code has a lot of empty lines which could do with trimming. It might be your conversion to unix LF.

Ok
 
- createCSignature() can be probably be replaced by Swig_name_fulldecl() or Swig_name_decl().

I found it in modula3, I'm not aware of the functions you suggested
 

What is autoname?

I set it to delphi
 


The module now supports FPC and it compiles all the examples on Win32, but I did not tested on linux.

That's great. As it works with Free Pascal, do you think the module would be better named Pascal rather than Delphi?

I also have this doubt. The correct name should be object pascal, since it differs from standard pascal; but objectpascal its too long. I used FPC in delphi compatibility mode in order to compile.
 


The module doc is only a draft ( my mother language is not English :-);
Once committed, I'll read through the docs and fix up any English if you like.

I will be glad!


I edited it using Word so I think I would have to clean it.

Yes most likely. It needs to be easily readable with a text editor and use the same formatting as the rest of the documentation. You might be best off saving copying the contents as plain text and then adding in the formatting manually.

I think the best way forward is for you to create a svn branch - call it smoratto-delphi or smoratto-pascal. I've set you up as a SWIG developer. You are welcome to check your patch in as it is into the branch and then use svn to modify as per the comments. Once that is done and the test-suite is close to 100%, then we can look at merging it to trunk for a release.

I will try to do the branch
 

William

Thanks,
Stefano


--
Dr.Eng. Stefano Moratto