From: Stefano M. <ste...@gm...> - 2008-07-02 06:40:53
|
Dear SWIG's community, I've developed a functional delphi module that implements all the swig functions except for director. The module compiles all the examples that can be found in the CSharp example's folder and I tested some testsuits (cpp_basic, bloody_hell, enums ). I would like this effort will be included in the standard SWIG because * I think the DELPHI community needs this tools; * I'm a developer in the GDAL project and I done a GDAL's version for delphi using SWIG but I can not include it in the standard GDAL distros while the Delphi module is not included in SWIG. How can I produce a patch to be sent to you? I developed starting from swigwin-1.35 sources. Best Regards, Stefano Moratto |
From: William S F. <ws...@fu...> - 2008-07-02 22:10:35
|
Stefano Moratto wrote: > Dear SWIG's community, > > I've developed a functional delphi module that > implements all the swig functions except for director. > The module compiles all the examples that can be found in the CSharp > example's folder and I tested some testsuits (cpp_basic, bloody_hell, > enums ). > > I would like this effort will be included in the standard SWIG because > * I think the DELPHI community needs this tools; > * I'm a developer in the GDAL project and I done a GDAL's > version for delphi using SWIG but I can not include it in the standard > GDAL distros > while the Delphi module is not included in SWIG. > > How can I produce a patch to be sent to you? I developed starting from > swigwin-1.35 sources. > Stefano I think the best way to submit a patch is to send it to SF. Some people send patches inline in an email, but usually the lines get broken up, then the patch program can't patch properly. The patch will probably apply cleanly to svn head even if you send the patch diff'd to 1.3.35. A unix/cygwin line ending diff will be preferable. Please send any initial documentation you have to the list too. We're always interested in new modules and Pascal would be a good one to add to the list of supported languages. However, we are concerned about the number of language modules that have been submitted and then not brought up to scratch. It sounds like you have some basics working which is great. If you havn't yet read the prerequisites for acceptance, please take a look at http://www.swig.org/Doc1.3/Extending.html#Extending_prerequisites. We're an open source project and like to support other open source languages, eg the C# module is designed to work with Mono as well as MS's C#. Similary for Delphi, I'd hope that it works with free pascal. Free Pascal 2.2.0 looks a doddle to install (under Debian/Ubuntu anyway). I'd be quite happy to test it out if you havn't yet tried it out. It'll probably be a lot easier to configure for the test-suite than using Windows unless you are using cygwin or mingw's gcc. Ultimately, easily running the entire test-suite error free is what is needed to maintain a language module. William |
From: Stefano M. <ste...@gm...> - 2008-07-03 08:11:56
|
William, I developed the module using both Visual Studio (2005) C++ and mingw so I have working windows and unix like compile environments. I followed all the requirements in http://www.swig.org/Doc1.3/Extending.html#Extending_prerequisites. I checked the diff command and it is available in my mingw environment so I will proceed with the building of the diff package. I will assure to have unix style LF in the code. Today I'm going to modify the makefiles in order to compile with FPC. Maybe it will be sufficient to ./configure --with-delphi-compiler=fpc or something similar. I ran the test suites only on few cases (two c++ and two c) but I would like to put the module online in order to find some help to finish the test suites. Yesterday I tried to send the docs to the list but it is to large > 40k and the list doesn't accept .zip files. BTW my SF account is smoratto Stefano On Thu, Jul 3, 2008 at 12:09 AM, William S Fulton <ws...@fu...> wrote: > Stefano Moratto wrote: >> >> Dear SWIG's community, >> >> I've developed a functional delphi module that >> implements all the swig functions except for director. >> The module compiles all the examples that can be found in the CSharp >> example's folder and I tested some testsuits (cpp_basic, bloody_hell, >> enums ). >> >> I would like this effort will be included in the standard SWIG because >> * I think the DELPHI community needs this tools; >> * I'm a developer in the GDAL project and I done a GDAL's >> version for delphi using SWIG but I can not include it in the standard >> GDAL distros >> while the Delphi module is not included in SWIG. >> >> How can I produce a patch to be sent to you? I developed starting from >> swigwin-1.35 sources. >> > > Stefano > > I think the best way to submit a patch is to send it to SF. Some people send > patches inline in an email, but usually the lines get broken up, then the > patch program can't patch properly. The patch will probably apply cleanly to > svn head even if you send the patch diff'd to 1.3.35. A unix/cygwin line > ending diff will be preferable. Please send any initial documentation you > have to the list too. > > We're always interested in new modules and Pascal would be a good one to add > to the list of supported languages. However, we are concerned about the > number of language modules that have been submitted and then not brought up > to scratch. It sounds like you have some basics working which is great. If > you havn't yet read the prerequisites for acceptance, please take a look at > http://www.swig.org/Doc1.3/Extending.html#Extending_prerequisites. > > We're an open source project and like to support other open source > languages, eg the C# module is designed to work with Mono as well as MS's > C#. Similary for Delphi, I'd hope that it works with free pascal. Free > Pascal 2.2.0 looks a doddle to install (under Debian/Ubuntu anyway). I'd be > quite happy to test it out if you havn't yet tried it out. It'll probably be > a lot easier to configure for the test-suite than using Windows unless you > are using cygwin or mingw's gcc. Ultimately, easily running the entire > test-suite error free is what is needed to maintain a language module. > > William > > -- Dr.Eng. Stefano Moratto |
From: William S F. <ws...@fu...> - 2008-07-03 20:56:09
|
Stefano Moratto wrote: > William, > I developed the module using both Visual Studio (2005) > C++ and mingw so I have working windows and unix like compile > environments. I followed all the requirements in > http://www.swig.org/Doc1.3/Extending.html#Extending_prerequisites. > > I checked the diff command and it is available in my mingw environment > so I will proceed with the building of the diff package. I will assure > to have unix style LF in the code. > > Today I'm going to modify the makefiles in order to compile with FPC. > Maybe it will be sufficient to > ./configure --with-delphi-compiler=fpc or something similar. > That or even better is to detect fpc on linux hosts. Certainly it should be detected if it is in the users path. See all the other languages in configure.in, they all work pretty similarly. > I ran the test suites only on few cases (two c++ and two c) but I > would like to put the module online in order to find some help to > finish the test suites. > Great, let's see your patch and take it from there. > Yesterday I tried to send the docs to the list but it is to large > > 40k and the list doesn't accept .zip files. > That's a shame. Perhaps you could put it temporarily on a web site somewhere or otherwise submit it as a separate file attachment to your SF patch. > BTW my SF account is smoratto > > Stefano > Please take a look at the top posting/ bottom posting advice at http://www.swig.org/mail.html#top_bottom_posting for future email postings. Thanks William |
From: Stefano M. <ste...@gm...> - 2008-07-04 20:46:30
|
William, I have uploaded to SF a patch : its a zip file containing both the patch and the module's documentation. I produced the patch using: diff -rupN swigwin-1.3.35 swigwin-1.3.35.delphi > delphi.patch The module now supports FPC and it compiles all the examples on Win32, but I did not tested on linux. The module doc is only a draft ( my mother language is not English :-); I edited it using Word so I think I would have to clean it. Stefano |
From: Stefano M. <ste...@gm...> - 2008-07-09 08:41:43
|
William, had you any chances to examine the patch I uploaded to SF? Best regards, Stefano Moratto |
From: William S F. <ws...@fu...> - 2008-07-13 21:34:06
|
Stefano Moratto wrote: > William, > > had you any chances to examine the patch I uploaded to SF? > > Not yet. Could you try add it to Richard's reviewboard that he posted details of a few days ago. That might be the best way to do a review. William |
From: William S F. <ws...@fu...> - 2008-07-26 00:29:54
|
Stefano Moratto wrote: > William, > > I have uploaded to SF a patch : its a zip file containing > both the patch and the module's documentation. > I produced the patch using: > diff -rupN swigwin-1.3.35 swigwin-1.3.35.delphi > delphi.patch > I've read through the patch, sorry I couldn't do it earlier. I suggest you don't bother with the director examples until this feature is working. 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. 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. 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(). 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. delphi.cxx: - Please remove the Modula3 comments near the top. - Remove STL usage and replace with DOH containers/string. Sorry! - Replace char * with String use DOH library instead of C string library wherever possible. - Remove any compiler specific code (_MSC_VER) and use portable code. - Please format the code using the beautify targets in Source/Makefile.am - Use DOH's Split instead of the SplitString utility. - 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. - The code has a lot of empty lines which could do with trimming. It might be your conversion to unix LF. - createCSignature() can be probably be replaced by Swig_name_fulldecl() or Swig_name_decl(). What is autoname? > 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? > 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 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. William |
From: Stefano M. <ste...@gm...> - 2008-07-29 09:24:59
|
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 |
From: Olly B. <ol...@su...> - 2008-07-29 11:35:15
|
On 2008-07-26, William S Fulton <ws...@fu...> wrote: > - Remove STL usage and replace with DOH containers/string. Sorry! Don't forget that you offered to convert patches from STL to DOH: http://thread.gmane.org/gmane.comp.programming.swig.devel/18074/focus=18109 "With regard to patches, I'd be happy to take patches that use the standard library and I'd convert them to DOH in the mean time." Personally, I think we'll be stuck will DOH forever if we insist on an all-in-one conversion because it's just too big a change to make in one go without breaking things. I bet we'd be shaking new bugs out for ages. But sadly I don't have the time to work on even a piecemeal conversion at present though, and I suspect that's true for all of us. It's certainly true that having to mess around with DOH puts me off working with SWIG more than I do. DOH is a very cute hack, but it's trying to create the feel of a scripting language, yet requires explicit memory management, and using it wrongly can lead to undefined behaviour. If we want the feel of a scripting language, we should use a scripting language (and we could even mix scripting language and C/C++ code - we have a tool for that!) Random patchwork use of DOH and STL within the same area certainly isn't a good place to be, but STL use within particular modules seems less problematic to me. It certainly seems unhelpful to be forcing would be contributors to jump through the extra hoop of learning DOH. Cheers, Olly |
From: William S F. <ws...@fu...> - 2008-07-31 21:02:48
|
Olly Betts wrote: > On 2008-07-26, William S Fulton <ws...@fu...> wrote: >> - Remove STL usage and replace with DOH containers/string. Sorry! > > Don't forget that you offered to convert patches from STL to DOH: > > http://thread.gmane.org/gmane.comp.programming.swig.devel/18074/focus=18109 > > "With regard to patches, I'd be happy to take patches that use the > standard library and I'd convert them to DOH in the mean time." > Yes, I'll convert any patches that anyone feels unable to accomplish themselves. > Personally, I think we'll be stuck will DOH forever if we insist on > an all-in-one conversion because it's just too big a change to make > in one go without breaking things. I bet we'd be shaking new bugs > out for ages. But sadly I don't have the time to work on even a > piecemeal conversion at present though, and I suspect that's true for > all of us. > I don't think it will be such a big job to replace DOH with something better. It is my number two target on big things to accomplish. The first target is to replace the UTL with something comprehensible and I'm working on that. > It's certainly true that having to mess around with DOH puts me off > working with SWIG more than I do. > Understood, agreed and I feel your pain. The UTL and DOH are two barriers to SWIG development and both need sorting out. > DOH is a very cute hack, but it's trying to create the feel of a > scripting language, yet requires explicit memory management, and using > it wrongly can lead to undefined behaviour. If we want the feel of a > scripting language, we should use a scripting language (and we could > even mix scripting language and C/C++ code - we have a tool for that!) > > Random patchwork use of DOH and STL within the same area certainly isn't > a good place to be, Agreed, the conversion from DOH to the next great thing will be a lot easier keeping the current code using DOH. > but STL use within particular modules seems less > problematic to me. It certainly seems unhelpful to be forcing would be > contributors to jump through the extra hoop of learning DOH. Maybe in theory. There can't be many modules that can avoid using DOH. Mixing DOH and STL is no go, so in reality, using the STL is practically impossible. On the contrary, I've seen STL in the doxygen module and this is an unusual case of being quite standalone. I'll defer judgement as to whether it should remain like that until I've reviewed it properly. William |
From: Lucena, I. <iva...@pm...> - 2008-07-03 13:27:39
|
Stefano, I can help with Free Pascal on Linux if you want. Best regards, Ivan Stefano Moratto wrote: > William, > I developed the module using both Visual Studio (2005) > C++ and mingw so I have working windows and unix like compile > environments. I followed all the requirements in > http://www.swig.org/Doc1.3/Extending.html#Extending_prerequisites. > > I checked the diff command and it is available in my mingw environment > so I will proceed with the building of the diff package. I will assure > to have unix style LF in the code. > > Today I'm going to modify the makefiles in order to compile with FPC. > Maybe it will be sufficient to > ./configure --with-delphi-compiler=fpc or something similar. > > I ran the test suites only on few cases (two c++ and two c) but I > would like to put the module online in order to find some help to > finish the test suites. > > Yesterday I tried to send the docs to the list but it is to large > > 40k and the list doesn't accept .zip files. > > BTW my SF account is smoratto > > Stefano > > On Thu, Jul 3, 2008 at 12:09 AM, William S Fulton > <ws...@fu...> wrote: >> Stefano Moratto wrote: >>> Dear SWIG's community, >>> >>> I've developed a functional delphi module that >>> implements all the swig functions except for director. >>> The module compiles all the examples that can be found in the CSharp >>> example's folder and I tested some testsuits (cpp_basic, bloody_hell, >>> enums ). >>> >>> I would like this effort will be included in the standard SWIG because >>> * I think the DELPHI community needs this tools; >>> * I'm a developer in the GDAL project and I done a GDAL's >>> version for delphi using SWIG but I can not include it in the standard >>> GDAL distros >>> while the Delphi module is not included in SWIG. >>> >>> How can I produce a patch to be sent to you? I developed starting from >>> swigwin-1.35 sources. >>> >> Stefano >> >> I think the best way to submit a patch is to send it to SF. Some people send >> patches inline in an email, but usually the lines get broken up, then the >> patch program can't patch properly. The patch will probably apply cleanly to >> svn head even if you send the patch diff'd to 1.3.35. A unix/cygwin line >> ending diff will be preferable. Please send any initial documentation you >> have to the list too. >> >> We're always interested in new modules and Pascal would be a good one to add >> to the list of supported languages. However, we are concerned about the >> number of language modules that have been submitted and then not brought up >> to scratch. It sounds like you have some basics working which is great. If >> you havn't yet read the prerequisites for acceptance, please take a look at >> http://www.swig.org/Doc1.3/Extending.html#Extending_prerequisites. >> >> We're an open source project and like to support other open source >> languages, eg the C# module is designed to work with Mono as well as MS's >> C#. Similary for Delphi, I'd hope that it works with free pascal. Free >> Pascal 2.2.0 looks a doddle to install (under Debian/Ubuntu anyway). I'd be >> quite happy to test it out if you havn't yet tried it out. It'll probably be >> a lot easier to configure for the test-suite than using Windows unless you >> are using cygwin or mingw's gcc. Ultimately, easily running the entire >> test-suite error free is what is needed to maintain a language module. >> >> William >> >> > > > |
From: Stefano M. <ste...@gm...> - 2008-07-03 15:03:00
|
Ivan, thank your for your help. I'm just modifying the makefiles for fpc. Using fpc and -Sd (delphi mode) allows me to compile the examples fine. Unfortunately fpc accepts only one source file at a time on the command line so I have to play with Makefile.in order to compile all the files. All the example programs are composed by 2 files: example.pas (generated from example.i) and runme.dpr (the test program). >From Examples/Makefile.in - : this has been added for delphi support ################################################################## ##### DELPHI ###### ################################################################## # Extra DELPHI specific dynamic linking options DELPHI_DLNK = -mno-cygwin -mthreads -Wl,--add-stdcall-alias DELPHI_LIBPREFIX = DELPHICOMPILER = @DELPHICOMPILER@ DELPHICFLAGS = -mno-cygwin -mthreads DELPHISO = .dll DELPHIFLAGS = @DELPHIFLAGS@ # ---------------------------------------------------------------- # Build a DELPHI dynamically loadable module (C) # ---------------------------------------------------------------- delphi: $(SRCS) $(SWIG) -delphi $(SWIGOPT) $(INTERFACE) $(CC) -c $(CCSHARED) $(CFLAGS) $(DELPHICFLAGS) $(SRCS) $(ISRCS) $(INCLUDES) $(LDSHARED) $(CFLAGS) $(OBJS) $(IOBJS) $(DELPHI_DLNK) $(LIBS) -o $(DELPHI_LIBPREFIX)$(TARGET)$(DELPHISO) # ---------------------------------------------------------------- # Build a DELPHI dynamically loadable module (C++) # ---------------------------------------------------------------- delphi_cpp: $(SRCS) $(SWIG) -delphi -c++ $(SWIGOPT) $(INTERFACE) $(CXX) -c $(CCSHARED) $(CFLAGS) $(DELPHICFLAGS) $(SRCS) $(CXXSRCS) $(ICXXSRCS) $(INCLUDES) $(CXXSHARED) $(CFLAGS) $(OBJS) $(IOBJS) $(DELPHI_DLNK) $(LIBS) $(CPP_DLLIBS) -o $(DELPHI_LIBPREFIX)$(TARGET)$(DELPHISO) # ---------------------------------------------------------------- # Compile DELPHI files # ---------------------------------------------------------------- delphi_compile: $(SRCS) $(DELPHICOMPILER) $(DELPHIFLAGS) $(DELPHISRCS) Regards, Stefano Moratto On Thu, Jul 3, 2008 at 3:27 PM, Lucena, Ivan <iva...@pm...> wrote: > Stefano, > > I can help with Free Pascal on Linux if you want. > > Best regards, > > Ivan > > Stefano Moratto wrote: >> >> William, >> I developed the module using both Visual Studio (2005) >> C++ and mingw so I have working windows and unix like compile >> environments. I followed all the requirements in >> http://www.swig.org/Doc1.3/Extending.html#Extending_prerequisites. >> >> I checked the diff command and it is available in my mingw environment >> so I will proceed with the building of the diff package. I will assure >> to have unix style LF in the code. >> >> Today I'm going to modify the makefiles in order to compile with FPC. >> Maybe it will be sufficient to >> ./configure --with-delphi-compiler=fpc or something similar. >> >> I ran the test suites only on few cases (two c++ and two c) but I >> would like to put the module online in order to find some help to >> finish the test suites. >> >> Yesterday I tried to send the docs to the list but it is to large > >> 40k and the list doesn't accept .zip files. >> >> BTW my SF account is smoratto >> >> Stefano >> >> On Thu, Jul 3, 2008 at 12:09 AM, William S Fulton >> <ws...@fu...> wrote: >>> >>> Stefano Moratto wrote: >>>> >>>> Dear SWIG's community, >>>> >>>> I've developed a functional delphi module that >>>> implements all the swig functions except for director. >>>> The module compiles all the examples that can be found in the CSharp >>>> example's folder and I tested some testsuits (cpp_basic, bloody_hell, >>>> enums ). >>>> >>>> I would like this effort will be included in the standard SWIG because >>>> * I think the DELPHI community needs this tools; >>>> * I'm a developer in the GDAL project and I done a GDAL's >>>> version for delphi using SWIG but I can not include it in the standard >>>> GDAL distros >>>> while the Delphi module is not included in SWIG. >>>> >>>> How can I produce a patch to be sent to you? I developed starting from >>>> swigwin-1.35 sources. >>>> >>> Stefano >>> >>> I think the best way to submit a patch is to send it to SF. Some people >>> send >>> patches inline in an email, but usually the lines get broken up, then the >>> patch program can't patch properly. The patch will probably apply cleanly >>> to >>> svn head even if you send the patch diff'd to 1.3.35. A unix/cygwin line >>> ending diff will be preferable. Please send any initial documentation you >>> have to the list too. >>> >>> We're always interested in new modules and Pascal would be a good one to >>> add >>> to the list of supported languages. However, we are concerned about the >>> number of language modules that have been submitted and then not brought >>> up >>> to scratch. It sounds like you have some basics working which is great. >>> If >>> you havn't yet read the prerequisites for acceptance, please take a look >>> at >>> http://www.swig.org/Doc1.3/Extending.html#Extending_prerequisites. >>> >>> We're an open source project and like to support other open source >>> languages, eg the C# module is designed to work with Mono as well as MS's >>> C#. Similary for Delphi, I'd hope that it works with free pascal. Free >>> Pascal 2.2.0 looks a doddle to install (under Debian/Ubuntu anyway). I'd >>> be >>> quite happy to test it out if you havn't yet tried it out. It'll probably >>> be >>> a lot easier to configure for the test-suite than using Windows unless >>> you >>> are using cygwin or mingw's gcc. Ultimately, easily running the entire >>> test-suite error free is what is needed to maintain a language module. >>> >>> William >>> >>> >> >> >> > -- Dr.Eng. Stefano Moratto |
From: Jan J. <je...@po...> - 2008-07-03 19:10:06
|
Stefano Moratto wrote: > Dear SWIG's community, > > I've developed a functional delphi module that > implements all the swig functions except for director. > The module compiles all the examples that can be found in the CSharp > example's folder and I tested some testsuits (cpp_basic, bloody_hell, > enums ). > > I would like this effort will be included in the standard SWIG because > * I think the DELPHI community needs this tools; > * I'm a developer in the GDAL project and I done a GDAL's > version for delphi using SWIG but I can not include it in the standard > GDAL distros > while the Delphi module is not included in SWIG. > > How can I produce a patch to be sent to you? I developed starting from > swigwin-1.35 sources. > > > Best Regards, > Stefano Moratto > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 Hi Stefano, For your information - I am developing a COM target for SWIG as my Summer of Code project. It is already usable, e.g. at this stage you can generate wrappers (and typelibs) that can be imported and used in Delphi (and other COM-aware languages - VB, JScript, etc.). It is available at branches/gsoc2008-jezabek. Of course COM has its limitations, like no direct support for constructors, and a dedicated Delphi module - the one you are developing - is preferable for Delphi users. And FreePascal support is another thing which is out of the scope of my project. So I'm looking forward to seeing the Delphi module included in SWIG. Thanks, Jan Jezabek -- My GSoC 2008 development blog: http://jezabekgsoc.wordpress.com/ |
From: Stefano M. <ste...@gm...> - 2008-07-04 07:04:56
|
Jan, It's a very interesting project! How do you have implemented the director feature? I have not jet implemented director in my module but my planned implementation would use interfaces. Since delphi interfaces are COM interfaces (at least in Win32) we could discuss the topic. Stefano On Thu, Jul 3, 2008 at 9:03 PM, Jan Jezabek <je...@po...> wrote: > Stefano Moratto wrote: >> Dear SWIG's community, >> >> I've developed a functional delphi module that >> implements all the swig functions except for director. >> The module compiles all the examples that can be found in the CSharp >> example's folder and I tested some testsuits (cpp_basic, bloody_hell, >> enums ). >> >> I would like this effort will be included in the standard SWIG because >> * I think the DELPHI community needs this tools; >> * I'm a developer in the GDAL project and I done a GDAL's >> version for delphi using SWIG but I can not include it in the standard >> GDAL distros >> while the Delphi module is not included in SWIG. >> >> How can I produce a patch to be sent to you? I developed starting from >> swigwin-1.35 sources. >> >> >> Best Regards, >> Stefano Moratto >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > > Hi Stefano, > > For your information - I am developing a COM target for SWIG as my > Summer of Code project. It is already usable, e.g. at this stage you can > generate wrappers (and typelibs) that can be imported and used in Delphi > (and other COM-aware languages - VB, JScript, etc.). It is available at > branches/gsoc2008-jezabek. > > Of course COM has its limitations, like no direct support for > constructors, and a dedicated Delphi module - the one you are developing > - is preferable for Delphi users. And FreePascal support is another > thing which is out of the scope of my project. So I'm looking forward to > seeing the Delphi module included in SWIG. > > Thanks, > Jan Jezabek > > -- > My GSoC 2008 development blog: http://jezabekgsoc.wordpress.com/ > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > -- Dr.Eng. Stefano Moratto |
From: Jan J. <je...@po...> - 2008-07-04 21:14:02
|
Stefano Moratto wrote: > Jan, > It's a very interesting project! > > How do you have implemented the director feature? > > I have not jet implemented director in my module but my planned > implementation would use interfaces. Since delphi interfaces are COM > interfaces (at least in Win32) we could discuss the topic. > > Stefano > Stefano, I have not started implementing directors yet, but I've had some thoughts about it. I also think that interfaces are the way to go. The objects created using the COM wrapper implement 2 interfaces (in addition to IUnknown and IDispatch) - one is the interface corresponding to the C++ object (containing all its member functions and variables) and the other one, currently called SWIGWrappedObject, allows to get the pointer to the underlying C++ object. So for director support I plan to check whether an object passed as argument implements SWIGWrappedObject - if yes then I can just call the underlying object; otherwise some form of directors will be needed. I don't know if a similar approach will work for Delphi - I have very limited knowledge about it. I will be away from home for a few days, so please cc my e-mail address (je...@po...) - it is easier for me to check my mail than the newsgroup. Thanks, Jan Jezabek -- My GSoC 2008 development blog: http://jezabekgsoc.wordpress.com/ |
From: Stefano M. <ste...@gm...> - 2008-07-29 12:17:56
|
Jan, my approach is more or less the same of yours. Every Pascal class implements (will implement) all the methods of the wrapped class plus one interface containing all the virtual function. A pointer to this interface is passed to the C++ class that will used it to forward the virtual functions to the methods of the interface. Eg. C++ class A { public: void Method1() ...; virtual void Method2(); }; Pascal IA_VirtualMethods = interface procedure Method2(); end; TA = class(TSwigObject, IA_VirtualMethods) protected procedure DoMethod2(); implements IA_VirtualMethods.DoMethod2(); public constructor Create(); procedure DoMethod1(); procedure DoMethod2(); end; constructor TA.Create(); begin FSwigObj := new_A(); FSwigObj.SetVirtualMethodos( Self As IA_VirtualMethods ); end; SWIG: class IA_VirtualMethods { public: virtual void Method2() = 0; }; class SWIGWrappedA : public A { private: IA_VirtualMethods * v; public void SetVirtualMethods (IA_VirtualMethods *); void Method2() { v->void Method2(); } } More or less this is the Idea. This should be the same in you case. The Pascal As operator performs a QueryInterface on the target Object. Delphi Pascal interfaces are fully COM compliant infterfaces Stefano Stefano, > > I have not started implementing directors yet, but I've had some thoughts > about it. I also think that interfaces are the way to go. The objects > created using the COM wrapper implement 2 interfaces (in addition to > IUnknown and IDispatch) - one is the interface corresponding to the C++ > object (containing all its member functions and variables) and the other > one, currently called SWIGWrappedObject, allows to get the pointer to the > underlying C++ object. So for director support I plan to check whether an > object passed as argument implements SWIGWrappedObject - if yes then I can > just call the underlying object; otherwise some form of directors will be > needed. I don't know if a similar approach will work for Delphi - I have > very limited knowledge about it. > > I will be away from home for a few days, so please cc my e-mail address ( > je...@po...) - it is easier for me to check my mail than the > newsgroup. > > > Thanks, > Jan Jezabek > > |
From: William S F. <ws...@fu...> - 2008-07-31 21:03:07
|
Stefano Moratto wrote: > 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 > I see. Modula 3 isn't really mainstream so I didn't recognise them. To be honest, I don't think the modula 3 module gets used much, if at all. If you can, try and model code/typemaps/features etc on one of the popular modules. The probability of maintenance by others will be much higher. > - 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) > I need to check, but if gcc doesn't support it, I doubt it is in the standard and so shouldn't be used. By all means write a replacement and as it is string based, prefer a DOH version and add it into DOH/string.c. > > - 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 > Ah okay. These functions were added fairly recently. > 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. > Okay I suppose there are two options. 1) You generate wrappers that FPC can only compile using Delphi compatibility mode... Call the module delphi. 2) You generate wrappers that both FPC and Delphi compile using default options... Call the module objectpascal. Sounds like 1) applies atm. If you think 2) is possible and a worthwhile goal, then it might be worth the effort. We prefer open source over proprietary with SWIG. Are there any Object Pascal standards? If so you should be aiming at generating standards compliant code. William |
From: Stefano M. <ste...@gm...> - 2008-07-31 21:18:56
|
William, On Thu, Jul 31, 2008 at 11:02 PM, William S Fulton <ws...@fu...>wrote: > Stefano Moratto wrote: > >> 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 >> >> I see. Modula 3 isn't really mainstream so I didn't recognise them. To be > honest, I don't think the modula 3 module gets used much, if at all. If you > can, try and model code/typemaps/features etc on one of the popular modules. > The probability of maintenance by others will be much higher. > I used modula as a starting point because of theri commont roots. Anyway I supposed it is not very used and I looked inside c# module when I had problem on some feature the modula does not implement correctly. > > - 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) >> >> > I need to check, but if gcc doesn't support it, I doubt it is in the > standard and so shouldn't be used. By all means write a replacement and as > it is string based, prefer a DOH version and add it into DOH/string.c. > It is only a single function; I wrote a replacement for gcc so I could write a new one common for both plaftform. > > > >> - 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 >> >> > Ah okay. These functions were added fairly recently. > I will look at them. > > 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. >> >> > Okay I suppose there are two options. > 1) You generate wrappers that FPC can only compile using Delphi > compatibility mode... Call the module delphi. > 2) You generate wrappers that both FPC and Delphi compile using default > options... Call the module objectpascal. > > Sounds like 1) applies atm. If you think 2) is possible and a worthwhile > goal, then it might be worth the effort. We prefer open source over > proprietary with SWIG. Are there any Object Pascal standards? If so you > should be aiming at generating standards compliant code. > There is not a ISO standard for Object Pascal (only for the old one ISO pascal). The standard is DELPHI because it is a defacto standard. I'm for 1) I looked briefly at FPC docs; there are some slighty difference but I think the Delphi mode is the only one that could support director. > William > Stefano -- Dr.Eng. Stefano Moratto |
From: Stefano M. <ste...@gm...> - 2009-04-17 13:21:26
|
William, it has been passed a lot of time since the last mail. I was very busy with my child, but now that he is 1 year old I have some time for my hobbyes. I would like to finish my pascal module for swig. I have just managed to be able to recompile all (I changed my pc in the meanwhile) and to review the documentation. The module targets 1.3.35 and I have seen then swig is 1.3.39. What have to do now? Lastyear swig used "reviewboard" to sumbit patch. Now how can I submit a patch?. I think I have to adjust documentation chapter's number and warning number because some new languages have been added. . Stefano Moratto |
From: Olly B. <ol...@su...> - 2008-07-31 22:47:04
|
On 2008-07-31, William S Fulton <ws...@fu...> wrote: > I need to check, but if gcc doesn't support it, I doubt it is in the > standard and so shouldn't be used. No, strlwr() isn't ISO C. > By all means write a replacement and > as it is string based, prefer a DOH version and add it into DOH/string.c. There's already one: Swig_string_lower() in misc.c (prototyped in swig.h). Cheers, Olly |
From: Stefano M. <ste...@gm...> - 2008-08-01 06:46:07
|
Thanks Olly! Stefano On Fri, Aug 1, 2008 at 12:46 AM, Olly Betts <ol...@su...> wrote: > On 2008-07-31, William S Fulton <ws...@fu...> wrote: > > > I need to check, but if gcc doesn't support it, I doubt it is in the > > standard and so shouldn't be used. > > No, strlwr() isn't ISO C. > > > By all means write a replacement and > > as it is string based, prefer a DOH version and add it into DOH/string.c. > > There's already one: Swig_string_lower() in misc.c (prototyped in swig.h). > > Cheers, > Olly > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > -- Dr.Eng. Stefano Moratto |
From: William S F. <ws...@fu...> - 2009-04-20 14:08:16
|
Stefano Moratto <stefano.moratto <at> gmail.com> writes: > > William, > it has been passed a lot of time since the last mail. I was very busy > with my child, but now that he is 1 year old I have some time for my > hobbyes.I would like to finish my pascal module for swig. > I have just managed to be able to recompile all (I changed my pc in > the meanwhile) and to review the documentation.The module targets 1.3.35 > and I have seen then swig is 1.3.39.What have to do now?Lastyear swig > used "reviewboard" to sumbit patch. Now how can I submit a patch?.I > think I have to adjust documentation chapter's number and warning > number because some new languages have been added. Hi Stefano, I was wondering what happened to that. To be honest, I don't recall much about reviewing your patch, so I'll do it again. Can you update your patch on SF: http://sourceforge.net/tracker/index.php?func=detail&aid=2010931&group_id=1645&atid=301645 with the latest against svn head (I suggest using svn diff to create the patch). Once that is okay, I'll get you svn write access and you can develop it on a branch until it is ready to be incorporated into trunk. With regard to reviewing your patch, I recently enabled SourceForge's new hosted tool called codestriker, which is a code review system. Can you log on here (using your SF username) http://apps.sourceforge.net/codestriker/swig/codestriker.pl and upload your patch. I've no idea how good it is, so if you don't mind, we can try out codestriker with your patch. Don't worry about the documentation numbering, it should automatically be fixed when you run make in the Doc/Manual directory. William |