From: William S F. <ws...@fu...> - 2013-06-06 19:22:22
|
On Jun 6, 2013 4:58 PM, "Sylvestre Ledru" < syl...@sc...> wrote: > > Hello William, > > We are in the process of finishing the SWIG / Scilab support. > > Simon, as C/C, is currently working on fixing the tests. > However, the STL tests are failing. They require quite some works and we > don't think they will be used by the SWIG/Scilab users (too complex in > term of usage). > > Would you agree on the merge even if the STL support is not there ? > I'm not sure I entirely agree. The main strengths of Swig compared to other wrapping tools are the c++ support including STL and multiple target language support that is fairly consistent. By omitting the STL in new target languages, it will degrade the overall Swig experience disappointing users. Most c++ users will also use string and vector, probably more than half of projects. If there is any compromise, then these two must be supported at a minimum. If this is difficult then there is something wrong because it should be a simple adaptation of C strings and arrays. It should take in the order of a few days at most if the rest of the module is up to scratch. There are also lots of runtime tests in other languages which greatly eases the implementation as translating these from another language is quick compared to the usual considerable time it takes to write the tests. If you want to avoid the whole UTL approach for providing STL support take a look at the earlier STL wrappers for the scripting languages or even the simple Java approach. Before merging I would like to review the module and would encourage others to also do so. It is good to hear that this module is maturing and I have cc'd swig-devel for further discussion. William |
From: Simon M. <sim...@sc...> - 2013-07-30 08:38:52
|
> On Jun 6, 2013 4:58 PM, "Sylvestre Ledru" > <syl...@sc... > <mailto:syl...@sc...>> wrote: > > > > Hello William, > > > > We are in the process of finishing the SWIG / Scilab support. > > > > Simon, as C/C, is currently working on fixing the tests. > > However, the STL tests are failing. They require quite some works and we > > don't think they will be used by the SWIG/Scilab users (too complex in > > term of usage). > > > > Would you agree on the merge even if the STL support is not there ? > > > I'm not sure I entirely agree. The main strengths of Swig compared to > other wrapping tools are the c++ support including STL and multiple > target language support that is fairly consistent. By omitting the STL > in new target languages, it will degrade the overall Swig experience > disappointing users. > > Most c++ users will also use string and vector, probably more than > half of projects. If there is any compromise, then these two must be > supported at a minimum. If this is difficult then there is something > wrong because it should be a simple adaptation of C strings and > arrays. It should take in the order of a few days at most if the rest > of the module is up to scratch. There are also lots of runtime tests > in other languages which greatly eases the implementation as > translating these from another language is quick compared to the usual > considerable time it takes to write the tests. > > If you want to avoid the whole UTL approach for providing STL support > take a look at the earlier STL wrappers for the scripting languages or > even the simple Java approach. > > Before merging I would like to review the module and would encourage > others to also do so. > > It is good to hear that this module is maturing and I have cc'd > swig-devel for further discussion. > > William > Hello William, STL support in SWIG seems to be like a never ending task, but I think I've finished the work that you required for Scilab. Now we can -in a generic way- manipulate and pass to C++ functions, STL "simple containers" (like vectors, sets, lists). For this, I mostly based my work on what has been done in Python on that topic, and adapted it to the case of Scilab. You probably know that we mostly use matrices in Scilab. Matrices of the four primitive types in Scilab (int, double, string, bool) are mapped in input/output to an equivalent STL container. As Scilab knows also pointers (which can be stored not in a matrix but in a list), you can also manipulate (through pointers) STL containers of more complex types, and pass them to C++ functions. I could give some other details (for example on STL map, for which there is no equivalent type in Scilab, so it is used through pointers only), but all elements about STL support will be documented soon. I would have liked to add remaining containers (like deque, ...), to complete unit tests, to fix things about iterators, to reorganize some sources.... There is still some work to do, but I think it can be done in a further step. To illustrate this, I've successfully used SWIG Scilab to integrate a big and and real C++ library, containing about a thousand of functions using STL. Could you review our work ? And if you accept this, could you explain me what has to be done to integrate this in the master branch ? I've already fixed the Scilab test suite, it should be run without crash or compilation issue. Best regards. Simon Marchetto Scilab Enterprises |
From: William S F. <ws...@fu...> - 2013-07-30 18:43:01
|
On Jul 30, 2013 9:23 AM, "Simon Marchetto" < sim...@sc...> wrote: >> >> On Jun 6, 2013 4:58 PM, "Sylvestre Ledru" < syl...@sc...> wrote: >> > >> > Hello William, >> > >> > We are in the process of finishing the SWIG / Scilab support. >> > >> > Simon, as C/C, is currently working on fixing the tests. >> > However, the STL tests are failing. They require quite some works and we >> > don't think they will be used by the SWIG/Scilab users (too complex in >> > term of usage). >> > >> > Would you agree on the merge even if the STL support is not there ? >> > >> I'm not sure I entirely agree. The main strengths of Swig compared to other wrapping tools are the c++ support including STL and multiple target language support that is fairly consistent. By omitting the STL in new target languages, it will degrade the overall Swig experience disappointing users. >> >> Most c++ users will also use string and vector, probably more than half of projects. If there is any compromise, then these two must be supported at a minimum. If this is difficult then there is something wrong because it should be a simple adaptation of C strings and arrays. It should take in the order of a few days at most if the rest of the module is up to scratch. There are also lots of runtime tests in other languages which greatly eases the implementation as translating these from another language is quick compared to the usual considerable time it takes to write the tests. >> >> If you want to avoid the whole UTL approach for providing STL support take a look at the earlier STL wrappers for the scripting languages or even the simple Java approach. >> >> Before merging I would like to review the module and would encourage others to also do so. >> >> It is good to hear that this module is maturing and I have cc'd swig-devel for further discussion. >> >> William > > > Hello William, > > STL support in SWIG seems to be like a never ending task, but I think I've finished the work that you required for Scilab. > > Now we can -in a generic way- manipulate and pass to C++ functions, STL "simple containers" (like vectors, sets, lists). For this, I mostly based my work on what has been done in Python on that topic, and adapted it to the case of Scilab. > > You probably know that we mostly use matrices in Scilab. Matrices of the four primitive types in Scilab (int, double, string, bool) are mapped in input/output to an equivalent STL container. > As Scilab knows also pointers (which can be stored not in a matrix but in a list), you can also manipulate (through pointers) STL containers of more complex types, and pass them to C++ functions. > > I could give some other details (for example on STL map, for which there is no equivalent type in Scilab, so it is used through pointers only), but all elements about STL support will be documented soon. > > I would have liked to add remaining containers (like deque, ...), to complete unit tests, to fix things about iterators, to reorganize some sources.... There is still some work to do, but I think it can be done in a further step. > > To illustrate this, I've successfully used SWIG Scilab to integrate a big and and real C++ library, containing about a thousand of functions using STL. > > Could you review our work ? And if you accept this, could you explain me what has to be done to integrate this in the master branch ? I've already fixed the Scilab test suite, it should be run without crash or compilation issue. > This all sounds great. I'll gladly review the code with the aim to get it ready for master. Just one thing before I do, can you please configure the Travis build for Scilab ? Just merge .travis.yml from master then there should be just a couple of simple changes to add in Scilab. Travis builds will be needed for master and I can also see the current state online before tackling the review. William On Jul 30, 2013 9:23 AM, "Simon Marchetto" < sim...@sc...> wrote: > On Jun 6, 2013 4:58 PM, "Sylvestre Ledru" < > syl...@sc...> wrote: > > > > Hello William, > > > > We are in the process of finishing the SWIG / Scilab support. > > > > Simon, as C/C, is currently working on fixing the tests. > > However, the STL tests are failing. They require quite some works and we > > don't think they will be used by the SWIG/Scilab users (too complex in > > term of usage). > > > > Would you agree on the merge even if the STL support is not there ? > > > I'm not sure I entirely agree. The main strengths of Swig compared to > other wrapping tools are the c++ support including STL and multiple target > language support that is fairly consistent. By omitting the STL in new > target languages, it will degrade the overall Swig experience disappointing > users. > > Most c++ users will also use string and vector, probably more than half of > projects. If there is any compromise, then these two must be supported at a > minimum. If this is difficult then there is something wrong because it > should be a simple adaptation of C strings and arrays. It should take in > the order of a few days at most if the rest of the module is up to scratch. > There are also lots of runtime tests in other languages which greatly eases > the implementation as translating these from another language is quick > compared to the usual considerable time it takes to write the tests. > > If you want to avoid the whole UTL approach for providing STL support take > a look at the earlier STL wrappers for the scripting languages or even the > simple Java approach. > > Before merging I would like to review the module and would encourage > others to also do so. > > It is good to hear that this module is maturing and I have cc'd swig-devel > for further discussion. > > William > > > Hello William, > > STL support in SWIG seems to be like a never ending task, but I think I've > finished the work that you required for Scilab. > > Now we can -in a generic way- manipulate and pass to C++ functions, STL > "simple containers" (like vectors, sets, lists). For this, I mostly based > my work on what has been done in Python on that topic, and adapted it to > the case of Scilab. > > You probably know that we mostly use matrices in Scilab. Matrices of the > four primitive types in Scilab (int, double, string, bool) are mapped in > input/output to an equivalent STL container. > As Scilab knows also pointers (which can be stored not in a matrix but in > a list), you can also manipulate (through pointers) STL containers of more > complex types, and pass them to C++ functions. > > I could give some other details (for example on STL map, for which there > is no equivalent type in Scilab, so it is used through pointers only), but > all elements about STL support will be documented soon. > > I would have liked to add remaining containers (like deque, ...), to > complete unit tests, to fix things about iterators, to reorganize some > sources.... There is still some work to do, but I think it can be done in a > further step. > > To illustrate this, I've successfully used SWIG Scilab to integrate a big > and and real C++ library, containing about a thousand of functions using > STL. > > Could you review our work ? And if you accept this, could you explain me > what has to be done to integrate this in the master branch ? I've already > fixed the Scilab test suite, it should be run without crash or compilation > issue. > > Best regards. > > Simon Marchetto > Scilab Enterprises > |
From: Sylvestre L. <syl...@sc...> - 2013-08-06 12:24:18
|
Hello, On 30/07/2013 20:17, William S Fulton wrote: > > On Jul 30, 2013 9:23 AM, "Simon Marchetto" > <sim...@sc... > <mailto:sim...@sc...>> wrote: [...] > This all sounds great. I'll gladly review the code with the aim to get > it ready for master. Just one thing before I do, can you please > configure the Travis build for Scilab ? Just merge .travis.yml from > master then there should be just a couple of simple changes to add in > Scilab. Travis builds will be needed for master and I can also see the > current state online before tackling the review. I configured the travis build in the gsoc2012-scilab branch. Is it possible to have it running on a branch ? Thanks Sylvestre |
From: William S F. <ws...@fu...> - 2013-08-06 17:10:32
|
On 06/08/13 13:24, Sylvestre Ledru wrote: > Hello, > > > On 30/07/2013 20:17, William S Fulton wrote: >> >> On Jul 30, 2013 9:23 AM, "Simon Marchetto" >> <sim...@sc... >> <mailto:sim...@sc...>> wrote: > [...] >> This all sounds great. I'll gladly review the code with the aim to get >> it ready for master. Just one thing before I do, can you please >> configure the Travis build for Scilab ? Just merge .travis.yml from >> master then there should be just a couple of simple changes to add in >> Scilab. Travis builds will be needed for master and I can also see the >> current state online before tackling the review. > I configured the travis build in the gsoc2012-scilab branch. > Is it possible to have it running on a branch ? > Indeed. I've tweaked .travis.yml to run on this branch, results can be seen at https://travis-ci.org/swig/swig/branches. William |
From: Sylvestre L. <syl...@sc...> - 2013-08-07 12:29:08
|
On 06/08/2013 14:24, Sylvestre Ledru wrote: > Hello, > > > On 30/07/2013 20:17, William S Fulton wrote: >> >> On Jul 30, 2013 9:23 AM, "Simon Marchetto" >> <sim...@sc... >> <mailto:sim...@sc...>> wrote: > [...] >> This all sounds great. I'll gladly review the code with the aim to get >> it ready for master. Just one thing before I do, can you please >> configure the Travis build for Scilab ? Just merge .travis.yml from >> master then there should be just a couple of simple changes to add in >> Scilab. Travis builds will be needed for master and I can also see the >> current state online before tackling the review. > I configured the travis build in the gsoc2012-scilab branch. > Is it possible to have it running on a branch ? OK. It is now running: https://travis-ci.org/swig/swig/jobs/9940064 However, the Scilab installed is a 5.3.3. It is possible to have a more recent version or is that fixed by the Ubuntu distro ? Thanks, Sylvestre |
From: William S F. <ws...@fu...> - 2013-08-07 19:17:37
|
On 07/08/13 13:29, Sylvestre Ledru wrote: > On 06/08/2013 14:24, Sylvestre Ledru wrote: >> Hello, >> >> >> On 30/07/2013 20:17, William S Fulton wrote: >>> >>> On Jul 30, 2013 9:23 AM, "Simon Marchetto" >>> <sim...@sc... >>> <mailto:sim...@sc...>> wrote: >> [...] >>> This all sounds great. I'll gladly review the code with the aim to get >>> it ready for master. Just one thing before I do, can you please >>> configure the Travis build for Scilab ? Just merge .travis.yml from >>> master then there should be just a couple of simple changes to add in >>> Scilab. Travis builds will be needed for master and I can also see the >>> current state online before tackling the review. >> I configured the travis build in the gsoc2012-scilab branch. >> Is it possible to have it running on a branch ? > OK. It is now running: > https://travis-ci.org/swig/swig/jobs/9940064 > However, the Scilab installed is a 5.3.3. It is possible to have a more > recent version or is that fixed by the Ubuntu distro ? This is indeed the version shipped with Ubuntu 12.04, see http://packages.ubuntu.com/precise/scilab. Presumably you don't want to support the version of Scilab available on the most recent Long Term Support (LTS) version of Ubuntu (12.04)? If so, you'll have to go to a bit more trouble to package up a more recent version as a ppa. This would have the added advantage of for Scilab's Ubuntu users on the LTS version too. as a ppa is what users would look for first if they want a later version. I don't see much that is around though - https://launchpad.net/ubuntu/+source/scilab. Sylvestre, I notice that you packaged up 5.3.3 for Ubuntu 12.04, so I'd expect you'd know what to do to create a ppa, then in the Travis script would contain one extra command, something like sudo add-apt-repository ppa:sylvestre/scilab before the: sudo apt-get update sudo apt-get install scilab Hopefully you can just backport the package easily from a newer Ubuntu or Debian. William |
From: Simon M. <sim...@sc...> - 2013-08-12 16:00:50
|
Le 07/08/2013 21:17, William S Fulton a écrit : > On 07/08/13 13:29, Sylvestre Ledru wrote: >> On 06/08/2013 14:24, Sylvestre Ledru wrote: >>> Hello, >>> >>> >>> On 30/07/2013 20:17, William S Fulton wrote: >>>> >>>> On Jul 30, 2013 9:23 AM, "Simon Marchetto" >>>> <sim...@sc... >>>> <mailto:sim...@sc...>> wrote: >>> [...] >>>> This all sounds great. I'll gladly review the code with the aim to get >>>> it ready for master. Just one thing before I do, can you please >>>> configure the Travis build for Scilab ? Just merge .travis.yml from >>>> master then there should be just a couple of simple changes to add in >>>> Scilab. Travis builds will be needed for master and I can also see the >>>> current state online before tackling the review. >>> I configured the travis build in the gsoc2012-scilab branch. >>> Is it possible to have it running on a branch ? >> OK. It is now running: >> https://travis-ci.org/swig/swig/jobs/9940064 >> However, the Scilab installed is a 5.3.3. It is possible to have a more >> recent version or is that fixed by the Ubuntu distro ? > This is indeed the version shipped with Ubuntu 12.04, see > http://packages.ubuntu.com/precise/scilab. > > Presumably you don't want to support the version of Scilab available > on the most recent Long Term Support (LTS) version of Ubuntu (12.04)? > If so, you'll have to go to a bit more trouble to package up a more > recent version as a ppa. This would have the added advantage of for > Scilab's Ubuntu users on the LTS version too. as a ppa is what users > would look for first if they want a later version. I don't see much > that is around though - https://launchpad.net/ubuntu/+source/scilab. > Sylvestre, I notice that you packaged up 5.3.3 for Ubuntu 12.04, so > I'd expect you'd know what to do to create a ppa, then in the Travis > script would contain one extra command, something like > > sudo add-apt-repository ppa:sylvestre/scilab > before the: > sudo apt-get update > sudo apt-get install scilab > > Hopefully you can just backport the package easily from a newer Ubuntu > or Debian. > > William William, After discussed with Sylvestre : I will finally try to add support for Scilab 5.3.3, which may be the easiest way for the user (but maybe not for us). If it involves too much effort, we'll go on another solution, probably create a ppa, like you said. Simon Marchetto |
From: Simon M. <sim...@sc...> - 2013-08-19 16:15:35
|
Le 12/08/2013 18:00, Simon Marchetto a écrit : > > William, > > After discussed with Sylvestre : > I will finally try to add support for Scilab 5.3.3, which may be the > easiest way for the user (but maybe not for us). > If it involves too much effort, we'll go on another solution, probably > create a ppa, like you said. > > Simon Marchetto > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel William, There was not so many changes to support Scilab 5.3.3. I am able to run the examples and it should be the same for the test suite. I am pulling the patch now. Regards, Simon Marchetto |