From: Oliver B. <oli...@go...> - 2014-02-14 12:26:49
|
Hey William and list, I want to report on the state of the Javascript module. I finished a first draft of the documentation: https://github.com/oliver----/swig-v8/blob/devel/Doc/Manual/Javascript.md It does not cover Swig basics, only the bits that are specific to the Javascript module. It would be great to receive support from an En-native and of course general feedback. About the v8 version macro issue: an issue has finally been accepted. However, today I think that it is less of a problem for us. In the common use-cases, which are Node.js extensions, and Webkit/JSC extensions we do not need it. Node.js comes with its own v8 bundled and provides its own version macros. Those who really embed a custom v8 engine, have to be more of v8-experts. And probably they are capable of using the introduced command-line switch or add an appropriate #define by themselves. The next steps: I will check the module on different platforms and see if I need to add more information. And I will iterate some more times over the documentation adding missing pieces. Eventually, I can finalize the work this weekend. Cheers, Oliver |
From: Vadim Z. <vz...@ze...> - 2014-02-14 14:42:23
|
On Fri, 14 Feb 2014 13:26:38 +0100 Oliver Buchtala <oli...@go...> wrote: OB> Hey William and list, OB> OB> I want to report on the state of the Javascript module. OB> I finished a first draft of the documentation: OB> https://github.com/oliver----/swig-v8/blob/devel/Doc/Manual/Javascript.md This looks great! It was clear (at least in theory, I didn't try actually doing this yet) even for somebody as completely JS-ignorant as me. Maybe the only thing missing would be a simple example of using a C function (like the one you show) and a simple C++ class from JS because I'm not sure how exactly is this done (but this could well be obvious to anybody more fluent in JS). In any case, once again: excellent work! VZ |
From: Oliver B. <oli...@go...> - 2014-02-14 15:50:21
|
Am 2/14/14 3:42 PM, schrieb Vadim Zeitlin: > This looks great! It was clear (at least in theory, I didn't try actually > doing this yet) even for somebody as completely JS-ignorant as me. Maybe > the only thing missing would be a simple example of using a C function > (like the one you show) and a simple C++ class from JS because I'm not sure > how exactly is this done (but this could well be obvious to anybody more > fluent in JS). > > In any case, once again: excellent work! > VZ > Great. Thanks! I will add a full example. Cheers, Oliver |
From: William S F. <ws...@fu...> - 2014-02-14 17:14:15
|
On 14 February 2014 15:50, Oliver Buchtala <oli...@go...>wrote: > > Am 2/14/14 3:42 PM, schrieb Vadim Zeitlin: > > This looks great! It was clear (at least in theory, I didn't try > actually > > doing this yet) even for somebody as completely JS-ignorant as me. Maybe > > the only thing missing would be a simple example of using a C function > > (like the one you show) and a simple C++ class from JS because I'm not > sure > > how exactly is this done (but this could well be obvious to anybody more > > fluent in JS). > > > > In any case, once again: excellent work! > > VZ > > > Great. Thanks! I will add a full example. > > Can you please replicate the examples already there, just the simple and class will do, but more if you like. These are the 2 examples which should be the same across all languages which I think is useful for users and developers who are not particularly familiar with the multitude of different languages. Could you also fill any missing gaps required by http://www.swig.org/Doc2.0/Extending.html#Extending_prerequisites. Thanks William |
From: Oliver B. <oli...@go...> - 2014-03-06 07:01:12
|
Another update: The test-suite is now passing for JavascriptCore. For v8/node I have two which I do not understand yet: - c_delete.i:10: Error: Syntax error in input(1). - c_delete_function.i:8: Error: Syntax error in input(1). Find the current version of the merge commit for review: https://github.com/oliver----/swig-v8/commit/20ca51a3b55d93d8891ea021abd9b55da4fb6418 Cheers, Oliver |
From: William S F. <ws...@fu...> - 2014-03-21 23:30:41
|
On 06/03/14 07:01, Oliver Buchtala wrote: > Another update: > > The test-suite is now passing for JavascriptCore. > For v8/node I have two which I do not understand yet: > > - c_delete.i:10: Error: Syntax error in input(1). > - c_delete_function.i:8: Error: Syntax error in input(1). > > Find the current version of the merge commit for review: > https://github.com/oliver----/swig-v8/commit/20ca51a3b55d93d8891ea021abd9b55da4fb6418 That test requires the wrappers to be compiled as C. Looks like the JavaScript wrappers are compiled as C++ even for C code. Presumably there is only a C++ interface for v8/node? This info should go into the docs - it can cause some problems because not all C code can compile as C++ code. Fix the test-case like it is 'fixed' for octave in the .i file - just don't test it for javascript! Are there 3 different preprocessor macros defined for the 3 different javascript engines so that we can detect which engine SWIG is generating wrappers for? I think that is needed if they aren't in place. Document them in Doc/Manual/Preprocessor.html like other languages. I'm ready to work on this with you now if you are. I had a quick look today and initial comments are: - Can you fix that testcases so that Travis testing goes green? Shout if you need any more help. - .travis.yml: Can you modify to install just the one appropriate JS buildengine at a time, so there will be 3 separate sudo apt-get installs. Currently all 3 get installed even though only one of them is tested at a time. This will make sure each install works independently and make the testing a bit faster. I'll have a few things which will be easier to modify myself than request you to do it. A branch we can both work on is best before merging to master. Either in the SWIG repo or yours. I'm okay doing this in a branch in the SWIG repo unless you'd rather do it in your repo. Before committing it to the SWIG repo, I'd like you to separate the non-Javascript from the javascript components so that there are multiple separate patches. For example the swigprinters and cmake support are not javascript related and should be in two separate patches from the javascript patch. William |
From: Oliver B. <oli...@go...> - 2014-03-21 23:52:06
|
Hi William! On Sat, 22 Mar 2014 00:30:31 +0100, William S Fulton <ws...@fu...> wrote: > > That test requires the wrappers to be compiled as C. Looks like the > JavaScript wrappers are compiled as C++ even for C code. Presumably > there is only a C++ interface for v8/node? This info should go into the > docs - it can cause some problems because not all C code can compile as > C++ code. Fix the test-case like it is 'fixed' for octave in the .i file > - just don't test it for javascript! Yep... that seems to be the problem. Will do. > Are there 3 different preprocessor macros defined for the 3 different > javascript engines so that we can detect which engine SWIG is generating > wrappers for? Actually it is 2 of them. node.js adds an extra Macro to v8. > I think that is needed if they aren't in place. Document them in > Doc/Manual/Preprocessor.html like other languages. > Will do. > I'm ready to work on this with you now if you are. I think we can do a sprint this weekend... (if you like) > I had a quick look today and initial comments are: > - Can you fix that testcases so that Travis testing goes green? Shout if > you need any more help. Will do. > - .travis.yml: Can you modify to install just the one appropriate JS > buildengine at a time, so there will be 3 separate sudo apt-get > installs. Currently all 3 get installed even though only one of them is > tested at a time. This will make sure each install works independently > and make the testing a bit faster. Agreed. > I'll have a few things which will be easier to modify myself than > request you to do it. A branch we can both work on is best before > merging to master. Either in the SWIG repo or yours. I'm okay doing this > in a branch in the SWIG repo unless you'd rather do it in your repo. > Before committing it to the SWIG repo, I'd like you to separate the > non-Javascript from the javascript components so that there are multiple > separate patches. For example the swigprinters and cmake support are not > javascript related and should be in two separate patches from the > javascript patch. I am totally not sure about the cmake stuff... It is simply still not feasible to make the test-suite work with cmake. PITA. Let us create a branch that we would rebase every once in a while so that people can use to e.g. build conveniently under windows. The gdb things... I don't know... maybe the same strategy? (is there real interest?) Cheers, Oliver |
From: Oliver B. <oli...@go...> - 2014-03-22 00:07:09
|
JS-aficionados! I am currently working with node-webkit. This provides a means to create native apps which can be extended using our node.js generator. I feel, that this is the future for hybrid c++-js development. I will complement the documentation adding a section in that regard. Cheers, Oliver |
From: William S F. <ws...@fu...> - 2014-03-22 14:47:42
|
On 21/03/14 23:51, Oliver Buchtala wrote: > Hi William! > > On Sat, 22 Mar 2014 00:30:31 +0100, William S Fulton > <ws...@fu...> wrote: > >> I'm ready to work on this with you now if you are. > > I think we can do a sprint this weekend... (if you like) > I can put in a bit of sporadic time this weekend. Let me know which repo/branch you want to collaborate on. I'd like it hooked up to Travis. You now have commit privileges on the SWIG repo. > > I am totally not sure about the cmake stuff... > It is simply still not feasible to make the test-suite work with cmake. > PITA. > Let us create a branch that we would rebase every once in a while so > that people can use > to e.g. build conveniently under windows. > I'd like to one day see a good working CMakeLists.txt file in the master even if it just builds the swig exe at a minimum. I don't know what state this is in your repo, but i'll look at it as a separate patch after the JS merge if it is in good shape. It should use a common (to automake) file containing the SWIG source files. > The gdb things... I don't know... maybe the same strategy? (is there > real interest?) I liked these gdb debuggers when I looked at it a year or two back. I think we should keep them as an option to the current Tools/swig.gdb as they should be a whole lot better. William |
From: Oliver B. <oli...@go...> - 2014-03-31 02:09:55
|
Hi William! On 22.03.2014 00:51, Oliver Buchtala wrote: >> >> That test requires the wrappers to be compiled as C. Looks like the >> JavaScript wrappers are compiled as C++ even for C code. Presumably >> there is only a C++ interface for v8/node? This info should go into >> the docs - it can cause some problems because not all C code can >> compile as C++ code. Fix the test-case like it is 'fixed' for octave >> in the .i file - just don't test it for javascript! > Done. >> Are there 3 different preprocessor macros defined for the 3 different >> javascript engines so that we can detect which engine SWIG is >> generating wrappers for? I think that is needed if they aren't in >> place. Document them in Doc/Manual/Preprocessor.html like other >> languages. >> Done. I added the following: SWIGJAVASCRIPT Defined when using Javascript SWIG_JAVASCRIPT_JSC Defined when using Javascript for JavascriptCore SWIG_JAVASCRIPT_V8 Defined when using Javascript for v8 or node.js There is an extra #define for nodejs `BUILDING_NODE_EXTENSION` which is necessary to control node.js. But it is actually not swig specific so I did not add it here. > - Can you fix that testcases so that Travis testing goes green? Shout > if you need any more help. > Done. >> - .travis.yml: Can you modify to install just the one appropriate JS >> buildengine at a time, so there will be 3 separate sudo apt-get >> installs. Currently all 3 get installed even though only one of them >> is tested at a time. This will make sure each install works >> independently and make the testing a bit faster. > Done. Now, I am having two remaining test-cases: > checking testcase enum_forward under javascript (v8) > enum_forward_wrap.cxx:1365:6: error: use of enum ‘ForwardEnum3’ without previous declaration > enum ForwardEnum3; > checking testcase nested_structs under javascript (v8) > nested_structs_wrap.cxx: In function ‘int nestedByVal(Named)’: > nested_structs_wrap.cxx:1380:5: error: ‘s’ has incomplete type > int nestedByVal(struct Named s) { return s.val; } ^ I'll investigate what might be the problem here. If you have a hint let me know. >> I am totally not sure about the cmake stuff... >> It is simply still not feasible to make the test-suite work with cmake. >> PITA. >> Let us create a branch that we would rebase every once in a while so >> that people can use >> to e.g. build conveniently under windows. >> > I'd like to one day see a good working CMakeLists.txt file in the > master even if it just builds the swig exe at a minimum. I don't know > what state this is in your repo, but i'll look at it as a separate > patch after the JS merge if it is in good shape. It should use a > common (to automake) file containing the SWIG source files. I pushed my CMake configuration to a new branch 'cmake'. We can discuss how to proceed with it in future. >> The gdb things... I don't know... maybe the same strategy? (is there >> real interest?) > I liked these gdb debuggers when I looked at it a year or two back. I > think we should keep them as an option to the current Tools/swig.gdb > as they should be a whole lot better. > Likewise, I pushed this work to an extra branch 'gdb_pretty_printers'. I need to take another round to check if it is still working and to add some documentation. Cheers, Oliver |
From: Oliver B. <oli...@go...> - 2014-03-31 02:11:23
|
On 31.03.2014 04:09, Oliver Buchtala wrote: > Hi William! > > On 22.03.2014 00:51, Oliver Buchtala wrote: >>> >>> That test requires the wrappers to be compiled as C. Looks like the >>> JavaScript wrappers are compiled as C++ even for C code. Presumably >>> there is only a C++ interface for v8/node? This info should go into >>> the docs - it can cause some problems because not all C code can >>> compile as C++ code. Fix the test-case like it is 'fixed' for octave >>> in the .i file - just don't test it for javascript! >> > Done. > >>> Are there 3 different preprocessor macros defined for the 3 >>> different javascript engines so that we can detect which engine SWIG >>> is generating wrappers for? I think that is needed if they aren't in >>> place. Document them in Doc/Manual/Preprocessor.html like other >>> languages. >>> > > Done. I added the following: > > SWIGJAVASCRIPT Defined when using Javascript > SWIG_JAVASCRIPT_JSC Defined when using Javascript for JavascriptCore > SWIG_JAVASCRIPT_V8 Defined when using Javascript for v8 or node.js > > There is an extra #define for nodejs `BUILDING_NODE_EXTENSION` which > is necessary to control node.js. But it is actually not swig specific > so I did not add it here. > >> - Can you fix that testcases so that Travis testing goes green? Shout >> if you need any more help. >> > > Done. > >>> - .travis.yml: Can you modify to install just the one appropriate JS >>> buildengine at a time, so there will be 3 separate sudo apt-get >>> installs. Currently all 3 get installed even though only one of them >>> is tested at a time. This will make sure each install works >>> independently and make the testing a bit faster. >> > Done. > > > Now, I am having two remaining test-cases: > > > checking testcase enum_forward under javascript (v8) > > enum_forward_wrap.cxx:1365:6: error: use of enum ‘ForwardEnum3’ > without previous declaration > > enum ForwardEnum3; > > > > checking testcase nested_structs under javascript (v8) > > nested_structs_wrap.cxx: In function ‘int nestedByVal(Named)’: > > nested_structs_wrap.cxx:1380:5: error: ‘s’ has incomplete type > > int nestedByVal(struct Named s) { return s.val; } > ^ > > I'll investigate what might be the problem here. If you have a hint > let me know. > > >>> I am totally not sure about the cmake stuff... >>> It is simply still not feasible to make the test-suite work with cmake. >>> PITA. >>> Let us create a branch that we would rebase every once in a while so >>> that people can use >>> to e.g. build conveniently under windows. >>> >> I'd like to one day see a good working CMakeLists.txt file in the >> master even if it just builds the swig exe at a minimum. I don't know >> what state this is in your repo, but i'll look at it as a separate >> patch after the JS merge if it is in good shape. It should use a >> common (to automake) file containing the SWIG source files. > > I pushed my CMake configuration to a new branch 'cmake'. > We can discuss how to proceed with it in future. > >>> The gdb things... I don't know... maybe the same strategy? (is there >>> real interest?) >> I liked these gdb debuggers when I looked at it a year or two back. I >> think we should keep them as an option to the current Tools/swig.gdb >> as they should be a whole lot better. >> > Likewise, I pushed this work to an extra branch 'gdb_pretty_printers'. > I need to take another round to check if it is still working and to > add some documentation. > > Cheers, > Oliver > Ahh, and... I pushed the javascript merge candidate to swig@javascript. Cheers |
From: William S F. <ws...@fu...> - 2014-04-10 07:21:23
|
On 31/03/14 03:11, Oliver Buchtala wrote: > > On 31.03.2014 04:09, Oliver Buchtala wrote: >> Hi William! >> >> On 22.03.2014 00:51, Oliver Buchtala wrote: >>>> >>>> That test requires the wrappers to be compiled as C. Looks like the >>>> JavaScript wrappers are compiled as C++ even for C code. Presumably >>>> there is only a C++ interface for v8/node? This info should go into >>>> the docs - it can cause some problems because not all C code can >>>> compile as C++ code. Fix the test-case like it is 'fixed' for octave >>>> in the .i file - just don't test it for javascript! >>> >> Done. >> >> Now, I am having two remaining test-cases: >> >> > checking testcase enum_forward under javascript (v8) >> > enum_forward_wrap.cxx:1365:6: error: use of enum ‘ForwardEnum3’ >> without previous declaration >> > enum ForwardEnum3; >> >> >> > checking testcase nested_structs under javascript (v8) >> > nested_structs_wrap.cxx: In function ‘int nestedByVal(Named)’: >> > nested_structs_wrap.cxx:1380:5: error: ‘s’ has incomplete type >> > int nestedByVal(struct Named s) { return s.val; } >> ^ >> >> I'll investigate what might be the problem here. If you have a hint >> let me know. >> Same as mentioned before, are you compiling C code as C++? If so Octave has solutions - ignore the enum_forward testcase and document the limitations of wrapping C code. Use Swig_cparse_cplusplusout to fix nested_struct. > > Ahh, and... I pushed the javascript merge candidate to swig@javascript. I'm not sure if you noticed, but I committed some changes into the javascript branch last week before I got distracted fixing the 3.0.0 regressions. I enabled the Travis testing. At least one of the three versions of Javascript passed. I think the breakages in the other two are the above problem you mentioned. William |
From: Oliver B. <oli...@go...> - 2014-04-10 10:25:07
|
Hi, On Thu, 10 Apr 2014 09:21:10 +0200, William S Fulton <ws...@fu...> wrote: > Same as mentioned before, are you compiling C code as C++? If so Octave > has solutions - ignore the enum_forward testcase and document the > limitations of wrapping C code. Use Swig_cparse_cplusplusout to fix > nested_struct. > Ok, will 'fix' it. > >> >> Ahh, and... I pushed the javascript merge candidate to swig@javascript. > I'm not sure if you noticed, but I committed some changes into the > javascript branch last week before I got distracted fixing the 3.0.0 > regressions. I enabled the Travis testing. At least one of the three > versions of Javascript passed. I think the breakages in the other two > are the above problem you mentioned. Ok, great! Cheers, Oliver |
From: William S F. <ws...@fu...> - 2014-04-22 05:52:04
|
On 10/04/14 11:24, Oliver Buchtala wrote: > Hi, > > On Thu, 10 Apr 2014 09:21:10 +0200, William S Fulton > <ws...@fu...> wrote: > >> Same as mentioned before, are you compiling C code as C++? If so >> Octave has solutions - ignore the enum_forward testcase and document >> the limitations of wrapping C code. Use Swig_cparse_cplusplusout to >> fix nested_struct. >> > > Ok, will 'fix' it. > >> >>> >>> Ahh, and... I pushed the javascript merge candidate to swig@javascript. >> I'm not sure if you noticed, but I committed some changes into the >> javascript branch last week before I got distracted fixing the 3.0.0 >> regressions. I enabled the Travis testing. At least one of the three >> versions of Javascript passed. I think the breakages in the other two >> are the above problem you mentioned. > > Ok, great! > I've been tidying up the branch as I've been reviewing it. There are some things I'm not sure about... When using the v8 and jsc engines, is node required to be installed? configure.ac seems to indicate this atm, but it doesn't seem right. Also is node-gyp required for testing with the v8 and jsc engines? It seems to work without it on Travis. If it isn't needed, do we really need node-gyp for testing node? Oliver, can you sort out the node and v8 Travis builds? There are some failures (although currently I've left it with v8 being skipped because node-gyp is not found - this needs fixing when the answers to the above questions are clear). William |
From: Oliver B. <oli...@go...> - 2014-04-23 02:00:54
|
On 22.04.2014 07:51, William S Fulton wrote: > I've been tidying up the branch as I've been reviewing it. There are > some things I'm not sure about... > > When using the v8 and jsc engines, is node required to be installed? > configure.ac seems to indicate this atm, but it doesn't seem right. > Also is node-gyp required for testing with the v8 and jsc engines? It > seems to work without it on Travis. If it isn't needed, do we really > need node-gyp for testing node? > > Oliver, can you sort out the node and v8 Travis builds? There are some > failures (although currently I've left it with v8 being skipped > because node-gyp is not found - this needs fixing when the answers to > the above questions are clear). > > William Hi William, thank you for your many improvements on the configuration. I fixed the remaining issues and Travis is eventually green. Cheers, Oliver |
From: William S F. <ws...@fu...> - 2014-04-25 19:54:29
|
On 23/04/14 03:00, Oliver Buchtala wrote: > > thank you for your many improvements on the configuration. > I fixed the remaining issues and Travis is eventually green. > Looking good. I've made some more minor changes and pretty much reviewed it all now. Overall, it looks excellent to me and so thanks to all the contributors, especially Oliver who has pulled it all together. There are just a few points to address, then I'd like to merge to master: 1) ./javascript/v8/node.i:%insert("begin") => The begin section is reserved for users only. Can you change this to generate into the header section or somewhere else? 2) 'swig -node -v8': this should generate an error message as only one engine can be specified at a time. 3) Rather than use SWIG_V8_VERSION, why not use the proper V8_VERSION everywhere and just set it to the default value you've chosen if is not defined in the actual wrapper? So just generate this: #ifndef V8_VERSION #define V8_VERSION 0x031110 #endif I'm just thinking readers of the code are more likely to recognise V8_VERSION, so the generated code is a bit more readable. 4) check.list has these examples commented out: exception namespace reference. Is something wrong with them? 5) 'emitter type', mode and engine... aren't these all the same thing? It would be better to use the same term for them all in the code and documentation / user messages. 6) Can you add in std::string &INPUT and std::string *INPUT typemaps for the li_std_string testcase. I'll probably keep tinkering with the build system in the meantime. The only real weak point is the html documentation, but we can address that when it has been merged to master. I'll put my thoughts together on this a little later. Regarding the Travis build for ENGINE=node, it looks to me that node is already installed on the machines, do you install the version from ppa:chris-lea just to get a newer version? Also are the rlwrap and python-software-properties installs needed for Travis? William |
From: Oliver B. <oli...@go...> - 2014-04-25 20:14:31
|
Am 4/25/14 9:54 PM, schrieb William S Fulton: > Looking good. I've made some more minor changes and pretty much > reviewed it all now. Overall, it looks excellent to me and so thanks > to all the contributors, especially Oliver who has pulled it all together. Thanx :) > There are just a few points to address, then I'd like to merge to master: > > 1) ./javascript/v8/node.i:%insert("begin") => The begin section is > reserved for users only. Can you change this to generate into the > header section or somewhere else? > > 2) 'swig -node -v8': this should generate an error message as only one > engine can be specified at a time. > > 3) Rather than use SWIG_V8_VERSION, why not use the proper V8_VERSION > everywhere and just set it to the default value you've chosen if is > not defined in the actual wrapper? So just generate this: > #ifndef V8_VERSION > #define V8_VERSION 0x031110 > #endif > I'm just thinking readers of the code are more likely to recognise > V8_VERSION, so the generated code is a bit more readable. > Will do. > 4) check.list has these examples commented out: exception namespace > reference. Is something wrong with them? Need to check. > > 5) 'emitter type', mode and engine... aren't these all the same thing? > It would be better to use the same term for them all in the code and > documentation / user messages. Ok. I try to consolidate this. > > 6) Can you add in std::string &INPUT and std::string *INPUT typemaps > for the li_std_string testcase. Will do. > > I'll probably keep tinkering with the build system in the meantime. > The only real weak point is the html documentation, but we can address > that when it has been merged to master. I'll put my thoughts together > on this a little later. > > Regarding the Travis build for ENGINE=node, it looks to me that node > is already installed on the machines, do you install the version from > ppa:chris-lea just to get a newer version? Also are the rlwrap and > python-software-properties installs needed for Travis? I wanted to use a 'real-world' version of nodejs. The repository versions are too old. I will keep you updated on progress. Cheers, Oliver |
From: William S F. <ws...@fu...> - 2014-05-01 21:24:32
|
On 25/04/14 21:14, Oliver Buchtala wrote: > > Am 4/25/14 9:54 PM, schrieb William S Fulton: >> Looking good. I've made some more minor changes and pretty much >> reviewed it all now. Overall, it looks excellent to me and so thanks >> to all the contributors, especially Oliver who has pulled it all >> together. > Thanx :) > >> There are just a few points to address, then I'd like to merge to master: I've now merged this into master for 3.0.1 and where development can continue like any of the other official modules. The 3 Javascript Travis (Ubuntu) builds all look good. Oliver, would you be able to develop a patch for modifying .travis.yml for testing JS on Travis OSX in the travis-osx branch? Test as many of the Javascript variants you feel are commonly used on OSX. Also if you know how to install the appropriate packages on Fedora/Redhat/Suse, then let me know and I'll add the install for testing on the openSUSE Build Service. I need the package name for adding into https://build.opensuse.org/package/view_file/home:kwk:swig/swig-raw/swig.spec?expand=1 William |
From: Oliver B. <oli...@go...> - 2014-04-26 22:43:05
|
Hi William, On 25.04.2014 21:54, William S Fulton wrote: > > 4) check.list has these examples commented out: exception namespace > reference. Is something wrong with them? > All of them were broken. 'exception': I fixed a misconfiguration problem 'namespace': there was a regression and an extra bug which I fixed. 'reference' is still not working for v8. I am pretty sure that it has been working someday and supposedely is a regression regarding cleanup (it also detects a memory leak). I leave it deactivated and will fix try to fix it soon. Cheers, Oliver |
From: William S F. <ws...@fu...> - 2014-04-28 19:02:15
|
On 26/04/14 23:42, Oliver Buchtala wrote: > Hi William, > > On 25.04.2014 21:54, William S Fulton wrote: >> >> 4) check.list has these examples commented out: exception namespace >> reference. Is something wrong with them? >> > All of them were broken. > > 'exception': I fixed a misconfiguration problem > 'namespace': there was a regression and an extra bug which I fixed. As this is testing %nspace, can you make it the same as the other nspace example (from Lua) and call it nspace too like in Lua. Regarding the nspace implementation, you should be using Language::getNSpace() in the implementation. It looks like you have re-implemented this, and I'd rather see the base class functionality used. > 'reference' is still not working for v8. I am pretty sure that it has > been working someday and supposedely is a regression regarding cleanup > (it also detects a memory leak). > I leave it deactivated and will fix try to fix it soon. > Okay, there is no problem doing it after the merge to master. So nearly there, just 3) to finish up. I didn't check, but is 5) done? William |
From: Oliver B. <oli...@go...> - 2014-04-28 20:21:25
|
On Mon, 28 Apr 2014 21:02:01 +0200, William S Fulton <ws...@fu...> wrote: > On 26/04/14 23:42, Oliver Buchtala wrote: >> Hi William, >> >> On 25.04.2014 21:54, William S Fulton wrote: >>> >>> 4) check.list has these examples commented out: exception namespace >>> reference. Is something wrong with them? >>> >> All of them were broken. >> >> 'exception': I fixed a misconfiguration problem >> 'namespace': there was a regression and an extra bug which I fixed. > As this is testing %nspace, can you make it the same as the other nspace > example (from Lua) and call it nspace too like in Lua. Ok. Will do. > Regarding the nspace implementation, you should be using > Language::getNSpace() in the implementation. It looks like you have > re-implemented this, and I'd rather see the base class functionality > used. Mainly it is there because I need to do some book-keeping, e.g., every namespace needs its own tables for declaring functions and variables. But, yes, concerning the name part I can try to make use of Language::getNSpace(). > So nearly there, just 3) to finish up. I didn't check, but is 5) done? 5 is done. Cheers, Oliver |
From: Oliver B. <oli...@go...> - 2014-05-18 21:41:56
|
On 28.04.2014 21:02, William S Fulton wrote: > > Regarding the nspace implementation, you should be using > Language::getNSpace() in the implementation. It looks like you have > re-implemented this, and I'd rather see the base class functionality > used. I tried this, however, in certain cases (global/nspace functions) Language::getNSpace() does not work as I would expect. E.g., in the 'nspace' test-case +++ cdecl ---------------------------------------- | feature:nspace - "1" | feature:copyctor - "1" | name - "Outer::Inner1::namespaceFunction" | sym:symtab - 0x2b364de2a5d0 | kind - "function" | sym:name - "namespaceFunction" | decl - "f(Outer::Inner1::Color)." | parms - Outer::Inner1::Color k | type - "Outer::Inner1::Color" | code - "{ return k; }" | sym:overname - "__SWIG_0" | Language::getNSpace() gives "" instead of "Outer.Inner1". It seems that for functions the underlying state variable is not set (lang.cxx, static String NSpace). Cheers, Oliver |
From: Eric W. <ewm...@gm...> - 2014-05-19 11:42:35
|
I just filed issue #42. https://github.com/oliver----/swig/issues/42 There is a bug with JSCore and multiple out-values. The crux of the problem is that the code in SWIGJSC_AppendOutput to detect if you already have an array or not, is not reliable. I have a proposal on how to fix it, but I don't know this part of the SWIG implementation. Is this an easy fix? Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ |
From: Eric W. <ewm...@gm...> - 2014-05-20 08:37:44
|
On 5/19/14, Eric Wing <ewm...@gm...> wrote: > I just filed issue #42. > https://github.com/oliver----/swig/issues/42 > > There is a bug with JSCore and multiple out-values. The crux of the > problem is that the code in SWIGJSC_AppendOutput to detect if you > already have an array or not, is not reliable. > > I have a proposal on how to fix it, but I don't know this part of the > SWIG implementation. Is this an easy fix? > Here is my fix/pull request for this multiple output bug. https://github.com/swig/swig/pull/181 Thanks, Eric |
From: Oliver B. <oli...@go...> - 2014-05-20 08:56:12
|
Am 5/20/14 10:37 AM, schrieb Eric Wing: > On 5/19/14, Eric Wing <ewm...@gm...> wrote: >> I just filed issue #42. >> https://github.com/oliver----/swig/issues/42 >> >> There is a bug with JSCore and multiple out-values. The crux of the >> problem is that the code in SWIGJSC_AppendOutput to detect if you >> already have an array or not, is not reliable. >> >> I have a proposal on how to fix it, but I don't know this part of the >> SWIG implementation. Is this an easy fix? >> > Here is my fix/pull request for this multiple output bug. > https://github.com/swig/swig/pull/181 > > Thanks, > Eric Hi Eric, Thanks. I don't have time right now to dive into it. I will take a look at the end of the week. Cheers, Oliver |