You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(64) |
Dec
(161) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(376) |
Feb
(195) |
Mar
(127) |
Apr
(30) |
May
(79) |
Jun
(83) |
Jul
(42) |
Aug
(39) |
Sep
(82) |
Oct
(102) |
Nov
(229) |
Dec
(76) |
2007 |
Jan
(62) |
Feb
(29) |
Mar
(83) |
Apr
(92) |
May
(84) |
Jun
(58) |
Jul
(36) |
Aug
(63) |
Sep
(131) |
Oct
(160) |
Nov
(46) |
Dec
(67) |
2008 |
Jan
(72) |
Feb
(82) |
Mar
(124) |
Apr
(144) |
May
(73) |
Jun
(38) |
Jul
(101) |
Aug
(26) |
Sep
(96) |
Oct
(35) |
Nov
(53) |
Dec
(92) |
2009 |
Jan
(92) |
Feb
(48) |
Mar
(90) |
Apr
(50) |
May
(104) |
Jun
(110) |
Jul
(136) |
Aug
(99) |
Sep
(80) |
Oct
(38) |
Nov
(106) |
Dec
(48) |
2010 |
Jan
(33) |
Feb
(70) |
Mar
(41) |
Apr
(54) |
May
(97) |
Jun
(76) |
Jul
(61) |
Aug
(27) |
Sep
(64) |
Oct
(74) |
Nov
(35) |
Dec
(55) |
2011 |
Jan
(66) |
Feb
(113) |
Mar
(101) |
Apr
(71) |
May
(93) |
Jun
(36) |
Jul
(30) |
Aug
(55) |
Sep
(30) |
Oct
(51) |
Nov
(59) |
Dec
(43) |
2012 |
Jan
(59) |
Feb
(32) |
Mar
(232) |
Apr
(174) |
May
(142) |
Jun
(38) |
Jul
(127) |
Aug
(99) |
Sep
(32) |
Oct
(8) |
Nov
(28) |
Dec
(144) |
2013 |
Jan
(105) |
Feb
(25) |
Mar
(70) |
Apr
(69) |
May
(40) |
Jun
(33) |
Jul
(20) |
Aug
(31) |
Sep
(82) |
Oct
(42) |
Nov
(78) |
Dec
(72) |
2014 |
Jan
(62) |
Feb
(68) |
Mar
(39) |
Apr
(54) |
May
(90) |
Jun
(87) |
Jul
(42) |
Aug
(76) |
Sep
(44) |
Oct
(49) |
Nov
(5) |
Dec
(28) |
2015 |
Jan
(33) |
Feb
(13) |
Mar
(12) |
Apr
(17) |
May
(15) |
Jun
(22) |
Jul
(16) |
Aug
(27) |
Sep
(8) |
Oct
(9) |
Nov
(14) |
Dec
(9) |
2016 |
Jan
(22) |
Feb
(15) |
Mar
(6) |
Apr
(6) |
May
(22) |
Jun
(83) |
Jul
(5) |
Aug
(9) |
Sep
(13) |
Oct
|
Nov
(31) |
Dec
(18) |
2017 |
Jan
(9) |
Feb
(15) |
Mar
(11) |
Apr
(11) |
May
(9) |
Jun
(10) |
Jul
(2) |
Aug
(1) |
Sep
(5) |
Oct
(4) |
Nov
(3) |
Dec
(9) |
2018 |
Jan
(3) |
Feb
(6) |
Mar
(1) |
Apr
(3) |
May
(8) |
Jun
(2) |
Jul
(3) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(3) |
Feb
(19) |
Mar
(11) |
Apr
(9) |
May
(7) |
Jun
(14) |
Jul
(1) |
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(3) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
(8) |
Feb
(1) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(4) |
Oct
(9) |
Nov
(14) |
Dec
|
2022 |
Jan
(1) |
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(1) |
2023 |
Jan
(2) |
Feb
|
Mar
|
Apr
(2) |
May
(6) |
Jun
(1) |
Jul
|
Aug
(4) |
Sep
(4) |
Oct
|
Nov
(2) |
Dec
(5) |
2024 |
Jan
(11) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: William S F. <ws...@fu...> - 2024-02-25 22:00:25
|
There is also %proxycode for C# which works the same as for Java as documented at https://swig.org/Doc4.2/Java.html#Java_proxycode. William On Wed, 31 Jan 2024 at 15:35, Mario Emmenlauer via Swig-devel < swi...@li...> wrote: > On 31.01.24 14:24, Julien Marrec wrote: > > Have you looked in cscode / csbody and co? > > > > see > https://www.swig.org/Doc4.2/SWIGDocumentation.html#CSharp_extending_proxy_class > > < > https://www.swig.org/Doc4.2/SWIGDocumentation.html#CSharp_extending_proxy_class> > and > https://www.swig.org/Doc4.2/SWIGDocumentation.html#CSharp_differences_java > > < > https://www.swig.org/Doc4.2/SWIGDocumentation.html#CSharp_differences_java > > > > Oh, this could be just what I need! I'll check it out later today, > thanks for the hint!! > > All the best, > > Mario > > > > -- > > Julien Marrec, EBCP, BPI MFBA > > Owner at EffiBEM <http://www.effibem.com> > > T: +33 6 95 14 42 13 > > > > LinkedIn (en <https://www.linkedin.com/in/julienmarrec>)/| /(fr < > https://fr.linkedin.com/in/julienmarrec/fr>) : > > <http://www.linkedin.com/in/julienmarrec> > > > > > > Le mer. 31 janv. 2024 à 13:00, Mario Emmenlauer via Swig-devel < > swi...@li... <mailto:swi...@li...>> > a écrit : > > > > > > Hi all, > > > > I'd like to perform some cast-operations on pointers in the target > > language (C# in my case). I have the matching C# code ready, but it > > would be great if I could just inject it directly from the interface > > file into the generated bindings. Basically the same that %{ ... %} > > does for C++, but on the target side. > > > > Is something like that possible? > > > > All the best, > > > > Mario Emmenlauer > > > > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: William S F. <ws...@fu...> - 2024-02-25 21:55:37
|
On Wed, 31 Jan 2024 at 23:35, Olly Betts <ol...@su...> wrote: > On 2023-12-31, William S Fulton <ws...@fu...> wrote: > > With the release of 4.2.0 now out of the way, I suspect we'll have to > push > > out a patch release 4.2.1 in a month or two. I suggest we keep master > open > > though for 4.3, so as to not hold up development of longer term > > improvements. If we could perhaps focus on minor improvements for the > 4.2.1 > > release in the near term that would be appreciated. I'll create a > > release-4.2 branch at a point just prior to any commit on master that is > > not a minor low risk change. > > Just to check, does that mean it's OK to push changes which aren't > suitable for 4.2.1? I.e. is it OK to essentially force you to need > to create this branch? > > In particular I'm thinking about switching the parser to be a GLR > parser, which would be good to start trying it for 4.3.0 sooner rather > than later (we already discussed and agreed on this plan in #2228). > > (Just the switch to a GLR parser would be trivial to revert, but > the next step would then be to start exploiting that change to fix > cases we fail to parse which are currently in the "too hard" pile.) > > Sorry, I got quite bogged down in the fixes for swig-4.2.1 and missed this query. Now that swig-4.2.1 is out of the way, master is for swig-4.3 development. You can definitely commit GLR changes to master for 4.3. If we do need to do a 4.2.2 release for any further reported regressions, then I'll create a release-4.2 branch off the v4.2.1 tag for this and cherry-pick just those needed off master onto the release-4.2 branch. > I am ready to spend time to get this into the main branch, but even if it is part of 4.3 - whenever 4.3 is released... Momtchil, could you please point me to an existing Gihub issue or create one if there isn't one to start discussing merging the Node-API improvements into master? William |
From: William S F. <ws...@fu...> - 2024-02-24 14:40:46
|
*** ANNOUNCE: SWIG 4.2.1 (24 Feb 2024) *** https://www.swig.org We're pleased to announce SWIG-4.2.1, the latest SWIG release. What is SWIG? ============= SWIG is a software development tool that reads C/C++ header files and generates the wrapper code needed to make C and C++ code accessible from other programming languages including Perl, Python, Tcl, Ruby, PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme), D, Ocaml, Octave, R, Scilab. SWIG can also export its parse tree in the form of XML. Major applications of SWIG include generation of scripting language extension modules, rapid prototyping, testing, and user interface development for large C/C++ systems. Release Notes ============= Detailed release notes are available with the release and are also published on the SWIG web site at https://swig.org/release.html. Availability ============ The release is available for download on Sourceforge at https://prdownloads.sourceforge.net/swig/swig-4.2.1.tar.gz A Windows version is also available at https://prdownloads.sourceforge.net/swig/swigwin-4.2.1.zip Please report problems with this release to the swig-devel mailing list, details at https://www.swig.org/mail.html. --- The SWIG Developers |
From: William S F. <ws...@fu...> - 2024-02-14 08:59:35
|
With quite a large bunch of regression fixes for 4.2.0 now completed, I'd like to release 4.2.1 next week on Saturday (24 Feb). Please add any regressions that have not been addressed to the swig-4.2.1 milestone: https://github.com/swig/swig/milestone/9 for priority attention for the release. William |
From: Olly B. <ol...@su...> - 2024-01-31 23:35:02
|
On 2023-12-31, William S Fulton <ws...@fu...> wrote: > With the release of 4.2.0 now out of the way, I suspect we'll have to push > out a patch release 4.2.1 in a month or two. I suggest we keep master open > though for 4.3, so as to not hold up development of longer term > improvements. If we could perhaps focus on minor improvements for the 4.2.1 > release in the near term that would be appreciated. I'll create a > release-4.2 branch at a point just prior to any commit on master that is > not a minor low risk change. Just to check, does that mean it's OK to push changes which aren't suitable for 4.2.1? I.e. is it OK to essentially force you to need to create this branch? In particular I'm thinking about switching the parser to be a GLR parser, which would be good to start trying it for 4.3.0 sooner rather than later (we already discussed and agreed on this plan in #2228). (Just the switch to a GLR parser would be trivial to revert, but the next step would then be to start exploiting that change to fix cases we fail to parse which are currently in the "too hard" pile.) Cheers, Olly |
From: Mario E. <ma...@em...> - 2024-01-31 15:35:12
|
On 31.01.24 14:24, Julien Marrec wrote: > Have you looked in cscode / csbody and co? > > see https://www.swig.org/Doc4.2/SWIGDocumentation.html#CSharp_extending_proxy_class > <https://www.swig.org/Doc4.2/SWIGDocumentation.html#CSharp_extending_proxy_class> and https://www.swig.org/Doc4.2/SWIGDocumentation.html#CSharp_differences_java > <https://www.swig.org/Doc4.2/SWIGDocumentation.html#CSharp_differences_java> Oh, this could be just what I need! I'll check it out later today, thanks for the hint!! All the best, Mario > -- > Julien Marrec, EBCP, BPI MFBA > Owner at EffiBEM <http://www.effibem.com> > T: +33 6 95 14 42 13 > > LinkedIn (en <https://www.linkedin.com/in/julienmarrec>)/| /(fr <https://fr.linkedin.com/in/julienmarrec/fr>) : > <http://www.linkedin.com/in/julienmarrec> > > > Le mer. 31 janv. 2024 à 13:00, Mario Emmenlauer via Swig-devel <swi...@li... <mailto:swi...@li...>> a écrit : > > > Hi all, > > I'd like to perform some cast-operations on pointers in the target > language (C# in my case). I have the matching C# code ready, but it > would be great if I could just inject it directly from the interface > file into the generated bindings. Basically the same that %{ ... %} > does for C++, but on the target side. > > Is something like that possible? > > All the best, > > Mario Emmenlauer > |
From: Julien M. <jul...@gm...> - 2024-01-31 13:24:44
|
Have you looked in cscode / csbody and co? see https://www.swig.org/Doc4.2/SWIGDocumentation.html#CSharp_extending_proxy_class and https://www.swig.org/Doc4.2/SWIGDocumentation.html#CSharp_differences_java -- Julien Marrec, EBCP, BPI MFBA Owner at EffiBEM <http://www.effibem.com> T: +33 6 95 14 42 13 LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) *| *(fr <https://fr.linkedin.com/in/julienmarrec/fr>) : <http://www.linkedin.com/in/julienmarrec> Le mer. 31 janv. 2024 à 13:00, Mario Emmenlauer via Swig-devel < swi...@li...> a écrit : > > Hi all, > > I'd like to perform some cast-operations on pointers in the target > language (C# in my case). I have the matching C# code ready, but it > would be great if I could just inject it directly from the interface > file into the generated bindings. Basically the same that %{ ... %} > does for C++, but on the target side. > > Is something like that possible? > > All the best, > > Mario Emmenlauer > > > -- > Mario Emmenlauer Tel: +49-176-23463809 > Balanstr. 43 mailto: mario * emmenlauer.de > 81669 Muenchen http://www.emmenlauer.de > > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: Mario E. <ma...@em...> - 2024-01-31 12:00:09
|
Hi all, I'd like to perform some cast-operations on pointers in the target language (C# in my case). I have the matching C# code ready, but it would be great if I could just inject it directly from the interface file into the generated bindings. Basically the same that %{ ... %} does for C++, but on the target side. Is something like that possible? All the best, Mario Emmenlauer -- Mario Emmenlauer Tel: +49-176-23463809 Balanstr. 43 mailto: mario * emmenlauer.de 81669 Muenchen http://www.emmenlauer.de |
From: Momtchil M. <mom...@mo...> - 2024-01-23 16:39:17
|
Hello, I would like to announce SWIG JavaScript Evolution which has reached a usable state. It is available as *main* from https://github.com/mmomtchev/swig SWIG JSE contains a number of significant additions to the JavaScript generator: * Node-API support which allows to produce and distribute binary modules compatible with all versions of Node.js and to support various Node.js-derivatives such as Electron (/this feature has already been merged in the main trunk and it is available in 4.2.0/) * Automatic generation of asynchronous wrappers for both CPU-heavy and I/O tasks, each C/C++ function can be wrapped to run as an async method to be executed in a background thread without blocking the event loop (/this feature is currently pending a review for merging in the mainline SWIG/) * Full TypeScript and ECMAScript 6 support, SWIG produces TypeScript typings (.d.ts) and ECMAScript 6 named exports * Full WASM compatibility - bindings generated by SWIG are compatible out-of-the box with dual-build setups - *reusing the same interface file* - the same code can be built both as a native shared library for Node.js or as a WASM binary that is compatible with both Node.js and browser JavaScript - sharing the same API, the same TypeScript types and the asynchronous support - between Node.js and the browser * Code splitting, allowing to produce multiple compilation units to reduce the memory requirements when compiling (Node-API makes extensive use of C++ templates and the compilation is quite heavy) Finally, the true power of JavaScript - which is sharing of code between the front-end and the back-end - is also extended to its C/C++ extensions. I would like to invite all JavaScript users to give it a try - your feedback will be appreciated when it comes to what and when will be merged to the mainline SWIG trunk. I have set up an example project skeleton at https://github.com/mmomtchev/swig-napi-example-project which features dual-build setup (native and WASM), combined Node.js + browser unit testing, a demo webpage using webpack, Github Actions and some basic examples. Accordingly, node-magickwand - which was the showcase project of SWIG Node-API - is now called magickwand.js - and it features a dual-build 3+1 setup - with Node.js native libraries for Windows, Linux and macOS and an universal WASM build that works in the browser. You can use it as an example for a real-world application based on SWIG JSE - https://github.com/mmomtchev/magickwand.js. You can find the JavaScript section of SWIG JSE manual here: https://htmlpreview.github.io/?https://github.com/mmomtchev/swig/blob/main/Doc/Manual/Javascript.html There are no other differences relative to the mainline SWIG besides the JavaScript section. -- Momtchil Momtchev<mom...@mo...> |
From: Momtchil M. <mom...@mo...> - 2024-01-06 01:02:28
|
Well, WASM is mostly about the browser. Whoever will be using it, will probably be using it to create bindings for C/C++ software to be used in browsers. Although it is sometimes touted as the next major universal binary platform, currently - and in the near future - it is used mostly to port existing C/C++ software to the browser. And alas, in the very short history of WASM, there are already incompatibilities and competing standards. I think that any serious unit testing of WASM has to use browsers - preferably all major ones. Maybe Node.js, or run-times such as Wasmer can also be thrown in the mix - but once again - I think that 99% of the users will be using it in a browser. And browser testing is a notoriously difficult problem - browsers are some of the most complex software projects to be every made, they are very fast moving targets and they usually lack any other interface besides the GUI. On 06/01/2024 00:13, Alexey Sokolov wrote: > Hi > Why does wasm testing require browser? There are ways to run wasm code > from command line. > > 04.01.2024 20:26, Momtchil Momtchev пишет: >> >> >> Hello, >> >> >> The current state of SWIG Node-API is: >> >> * Basic support merged in >> * Asynchronous execution in PR ready for review with full unit >> testing >> * TypeScript support needs documentation but can be finished in >> a day or so >> * WASM support is also ready but unit testing will be a huge >> problem - it requires setting up tests with browsers >> * Code splitting requires a lot more work before it is usable >> from the other languages >> >> I am ready to spend time to get this into the main branch, but even >> if it is part of 4.3 - whenever 4.3 is released - I still think that >> a separate release will at least allow me get feedback - and it will >> allow people to start using it. Especially since WASM is a very >> needed feature and merging the code splitting will require a major >> overhaul of all other languages. >> >> There is one first major project that uses it on npm - that is >> magickwand.js - so it is absolutely usable. >> >> >> On 03/01/2024 19:43, William S Fulton wrote: >>> Hi Momtchil >>> >>> I'd like to see your work in 4.3 and we there's probably no reason >>> why we can't release 4.3 in a couple of months. I'd be quite happy >>> to spend some time working with you getting this all into master >>> assuming there are no regressions in 4.2.0 to deal with (there >>> doesn't seem to be anything at the moment), so I'm looking for >>> something useful to focus on next. It probably is also best for you >>> to have committer access in order to properly maintain the Node-API >>> and Typescript modules. >>> >>> If that sounds good, how would you prefer to proceed? I wasn't aware >>> of a node API branch, perhaps focus on that first? >>> >>> William >>> >>> On Mon, 1 Jan 2024 at 21:35, Momtchil Momtchev >>> <mom...@mo...> wrote: >>> >>> >>> In this case, and given the significance of the Node-API branch >>> - which includes TypeScript, async, WASM and code splitting - I >>> plan to package it and release it separately. >>> >>> >>> >>> On 31/12/2023 15:13, William S Fulton wrote: >>>> With the release of 4.2.0 now out of the way, I suspect we'll >>>> have to push out a patch release 4.2.1 in a month or two. I >>>> suggest we keep master open though for 4.3, so as to not hold >>>> up development of longer term improvements. If we could perhaps >>>> focus on minor improvements for the 4.2.1 release in the near >>>> term that would be appreciated. I'll create a release-4.2 >>>> branch at a point just prior to any commit on master that is >>>> not a minor low risk change. >>>> >>>> William >>>> >>>> On Fri, 1 Dec 2023 at 09:07, William S Fulton >>>> <ws...@fu...> wrote: >>>> >>>> I would like to release swig-4.2.0 mid December ideally, >>>> but definitely before the end of the year. As it is now >>>> over a year since the last release, the issues I'd hoped to >>>> address for this release may have to be deferred to a later >>>> version, see the 4.2 milestone: >>>> https://github.com/swig/swig/milestone/5. I am going >>>> through them. If anyone has a must have for 4.2, add it to >>>> the milestone and please aim to have it ready by mid-month. >>>> Or otherwise speak up to replan. >>>> >>>> Thanks >>>> William >>>> >>>> >>>> >>>> _______________________________________________ >>>> Swig-devel mailing list >>>> Swi...@li... >>>> https://lists.sourceforge.net/lists/listinfo/swig-devel >>> >>> -- >>> Momtchil Momtchev<mom...@mo...> <mailto:mom...@mo...> >>> >>> _______________________________________________ >>> Swig-devel mailing list >>> Swi...@li... >>> https://lists.sourceforge.net/lists/listinfo/swig-devel >>> >> -- >> Momtchil Momtchev<mom...@mo...> > > > > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel -- Momtchil Momtchev<mom...@mo...> |
From: Alexey S. <al...@as...> - 2024-01-05 23:31:29
|
Hi Why does wasm testing require browser? There are ways to run wasm code from command line. 04.01.2024 20:26, Momtchil Momtchev пишет: > Hello, > > The current state of SWIG Node-API is: > > - Basic support merged in > - Asynchronous execution in PR ready for review with full unit testing > - TypeScript support needs documentation but can be finished in a day or so > - WASM support is also ready but unit testing will be a huge problem - it requires setting up tests with browsers > - Code splitting requires a lot more work before it is usable from the other languages > > I am ready to spend time to get this into the main branch, but even if it is part of 4.3 - whenever 4.3 is released - I still think that a separate release will at least allow me get feedback - and it will allow people to start using it. Especially since WASM is a very needed feature and merging the code splitting will require a major overhaul of all other languages. > > There is one first major project that uses it on npm - that is magickwand.js - so it is absolutely usable. > > On 03/01/2024 19:43, William S Fulton wrote: > >> Hi Momtchil >> >> I'd like to see your work in 4.3 and we there's probably no reason why we can't release 4.3 in a couple of months. I'd be quite happy to spend some time working with you getting this all into master assuming there are no regressions in 4.2.0 to deal with (there doesn't seem to be anything at the moment), so I'm looking for something useful to focus on next. It probably is also best for you to have committer access in order to properly maintain the Node-API and Typescript modules. >> >> If that sounds good, how would you prefer to proceed? I wasn't aware of a node API branch, perhaps focus on that first? >> >> William >> >> On Mon, 1 Jan 2024 at 21:35, Momtchil Momtchev <mom...@mo...> wrote: >> >>> In this case, and given the significance of the Node-API branch - which includes TypeScript, async, WASM and code splitting - I plan to package it and release it separately. >>> >>> On 31/12/2023 15:13, William S Fulton wrote: >>> >>>> With the release of 4.2.0 now out of the way, I suspect we'll have to push out a patch release 4.2.1 in a month or two. I suggest we keep master open though for 4.3, so as to not hold up development of longer term improvements. If we could perhaps focus on minor improvements for the 4.2.1 release in the near term that would be appreciated. I'll create a release-4.2 branch at a point just prior to any commit on master that is not a minor low risk change. >>>> >>>> William >>>> >>>> On Fri, 1 Dec 2023 at 09:07, William S Fulton <ws...@fu...> wrote: >>>> >>>>> I would like to release swig-4.2.0 mid December ideally, but definitely before the end of the year. As it is now over a year since the last release, the issues I'd hoped to address for this release may have to be deferred to a later version, see the 4.2 milestone: https://github.com/swig/swig/milestone/5. I am going through them. If anyone has a must have for 4.2, add it to the milestone and please aim to have it ready by mid-month. Or otherwise speak up to replan. >>>>> >>>>> Thanks >>>>> William >>>> >>>> _______________________________________________ >>>> Swig-devel mailing list >>>> Swi...@li... >>>> >>>> https://lists.sourceforge.net/lists/listinfo/swig-devel >>> >>> -- >>> Momtchil Momtchev >>> [<mom...@mo...>](mailto:mom...@mo...) >>> >>> _______________________________________________ >>> Swig-devel mailing list >>> Swi...@li... >>> https://lists.sourceforge.net/lists/listinfo/swig-devel > > -- > Momtchil Momtchev > [<mom...@mo...>](mailto:mom...@mo...) |
From: Momtchil M. <mom...@mo...> - 2024-01-04 20:27:09
|
Hello, The current state of SWIG Node-API is: * Basic support merged in * Asynchronous execution in PR ready for review with full unit testing * TypeScript support needs documentation but can be finished in a day or so * WASM support is also ready but unit testing will be a huge problem - it requires setting up tests with browsers * Code splitting requires a lot more work before it is usable from the other languages I am ready to spend time to get this into the main branch, but even if it is part of 4.3 - whenever 4.3 is released - I still think that a separate release will at least allow me get feedback - and it will allow people to start using it. Especially since WASM is a very needed feature and merging the code splitting will require a major overhaul of all other languages. There is one first major project that uses it on npm - that is magickwand.js - so it is absolutely usable. On 03/01/2024 19:43, William S Fulton wrote: > Hi Momtchil > > I'd like to see your work in 4.3 and we there's probably no reason why > we can't release 4.3 in a couple of months. I'd be quite happy to > spend some time working with you getting this all into master assuming > there are no regressions in 4.2.0 to deal with (there doesn't seem to > be anything at the moment), so I'm looking for something useful to > focus on next. It probably is also best for you to have committer > access in order to properly maintain the Node-API and Typescript modules. > > If that sounds good, how would you prefer to proceed? I wasn't aware > of a node API branch, perhaps focus on that first? > > William > > On Mon, 1 Jan 2024 at 21:35, Momtchil Momtchev <mom...@mo...> > wrote: > > > In this case, and given the significance of the Node-API branch - > which includes TypeScript, async, WASM and code splitting - I plan > to package it and release it separately. > > > > On 31/12/2023 15:13, William S Fulton wrote: >> With the release of 4.2.0 now out of the way, I suspect we'll >> have to push out a patch release 4.2.1 in a month or two. I >> suggest we keep master open though for 4.3, so as to not hold up >> development of longer term improvements. If we could perhaps >> focus on minor improvements for the 4.2.1 release in the near >> term that would be appreciated. I'll create a release-4.2 branch >> at a point just prior to any commit on master that is not a minor >> low risk change. >> >> William >> >> On Fri, 1 Dec 2023 at 09:07, William S Fulton >> <ws...@fu...> wrote: >> >> I would like to release swig-4.2.0 mid December ideally, but >> definitely before the end of the year. As it is now over a >> year since the last release, the issues I'd hoped to address >> for this release may have to be deferred to a later version, >> see the 4.2 milestone: >> https://github.com/swig/swig/milestone/5. I am going through >> them. If anyone has a must have for 4.2, add it to the >> milestone and please aim to have it ready by mid-month. Or >> otherwise speak up to replan. >> >> Thanks >> William >> >> >> >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel > > -- > Momtchil Momtchev<mom...@mo...> <mailto:mom...@mo...> > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > -- Momtchil Momtchev<mom...@mo...> |
From: William S F. <ws...@fu...> - 2024-01-03 19:47:58
|
Nice work guys. I've been using an old version of this work from Roman Stanchak authored in 2006 and have just upgraded to your new version which is subtly better, I think (!). On Thu, 23 Nov 2023 at 10:00, Julien Marrec <jul...@gm...> wrote: > Hello Matěj, > > I made modifications to your PR to include autodetection, tests, and > syntax adjustments, cf https://github.com/openSUSE-Python/vim/pull/1 > > Best, > Julien > -- > Julien Marrec, EBCP, BPI MFBA > Owner at EffiBEM <http://www.effibem.com> > T: +33 6 95 14 42 13 > > LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) *| *(fr > <https://fr.linkedin.com/in/julienmarrec/fr>) : > <http://www.linkedin.com/in/julienmarrec> > > > Le mer. 22 nov. 2023 à 23:26, Matěj Cepl <mc...@ce...> a écrit : > >> Hi, >> >> I have found somewhere a syntax file for vim and editing SWIG >> files. I have decided to post it to the vim project upstream, >> so that it would have native SWIG support, and the result is >> https://github.com/vim/vim/pull/13540 >> >> Can I ask for help here with the questions posted on that PR? >> >> 1. Most complicated seems to be how to autodetect >> SWIG file. Any thoughts. I cannot even find any >> other editor modules which would do something like >> that. Emacs module (https://github.com/dholm/swig-mode) >> doesn't seem to have anything. VS Code module >> (https://github.com/starofrainnight/vscode-swiglang), Atom >> (https://github.com/kankaristo/language-swig-wrapper) module, >> or Submile (https://github.com/jonschlinkert/sublime-swig) >> don't seem to be much helpful either. >> >> 2. Any more comments on the syntax file itself? >> >> Best, >> >> Matěj >> >> -- >> http://matej.ceplovi.cz/blog/, @mc...@fl...cial >> GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 >> >> When you’re happy that cut and paste actually works I think it’s >> a sign you’ve been using X-Windows for too long. >> -- from /. discussion on poor integration between KDE and >> GNOME >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel >> > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: William S F. <ws...@fu...> - 2024-01-03 19:10:44
|
Hi Momtchil I'd like to see your work in 4.3 and we there's probably no reason why we can't release 4.3 in a couple of months. I'd be quite happy to spend some time working with you getting this all into master assuming there are no regressions in 4.2.0 to deal with (there doesn't seem to be anything at the moment), so I'm looking for something useful to focus on next. It probably is also best for you to have committer access in order to properly maintain the Node-API and Typescript modules. If that sounds good, how would you prefer to proceed? I wasn't aware of a node API branch, perhaps focus on that first? William On Mon, 1 Jan 2024 at 21:35, Momtchil Momtchev <mom...@mo...> wrote: > > In this case, and given the significance of the Node-API branch - which > includes TypeScript, async, WASM and code splitting - I plan to package it > and release it separately. > > > > On 31/12/2023 15:13, William S Fulton wrote: > > With the release of 4.2.0 now out of the way, I suspect we'll have to push > out a patch release 4.2.1 in a month or two. I suggest we keep master open > though for 4.3, so as to not hold up development of longer term > improvements. If we could perhaps focus on minor improvements for the 4.2.1 > release in the near term that would be appreciated. I'll create a > release-4.2 branch at a point just prior to any commit on master that is > not a minor low risk change. > > William > > On Fri, 1 Dec 2023 at 09:07, William S Fulton <ws...@fu...> > wrote: > >> I would like to release swig-4.2.0 mid December ideally, but definitely >> before the end of the year. As it is now over a year since the last >> release, the issues I'd hoped to address for this release may have to be >> deferred to a later version, see the 4.2 milestone: >> https://github.com/swig/swig/milestone/5. I am going through them. If >> anyone has a must have for 4.2, add it to the milestone and please aim to >> have it ready by mid-month. Or otherwise speak up to replan. >> >> Thanks >> William >> > > > _______________________________________________ > Swig-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/swig-devel > > -- > Momtchil Momtchev <mom...@mo...> <mom...@mo...> > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: Momtchil M. <mom...@mo...> - 2024-01-01 21:35:00
|
In this case, and given the significance of the Node-API branch - which includes TypeScript, async, WASM and code splitting - I plan to package it and release it separately. On 31/12/2023 15:13, William S Fulton wrote: > With the release of 4.2.0 now out of the way, I suspect we'll have to > push out a patch release 4.2.1 in a month or two. I suggest we keep > master open though for 4.3, so as to not hold up development of longer > term improvements. If we could perhaps focus on minor improvements for > the 4.2.1 release in the near term that would be appreciated. I'll > create a release-4.2 branch at a point just prior to any commit on > master that is not a minor low risk change. > > William > > On Fri, 1 Dec 2023 at 09:07, William S Fulton > <ws...@fu...> wrote: > > I would like to release swig-4.2.0 mid December ideally, but > definitely before the end of the year. As it is now over a year > since the last release, the issues I'd hoped to address for this > release may have to be deferred to a later version, see the 4.2 > milestone: https://github.com/swig/swig/milestone/5. I am going > through them. If anyone has a must have for 4.2, add it to the > milestone and please aim to have it ready by mid-month. Or > otherwise speak up to replan. > > Thanks > William > > > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel -- Momtchil Momtchev<mom...@mo...> |
From: William S F. <ws...@fu...> - 2023-12-31 14:14:06
|
With the release of 4.2.0 now out of the way, I suspect we'll have to push out a patch release 4.2.1 in a month or two. I suggest we keep master open though for 4.3, so as to not hold up development of longer term improvements. If we could perhaps focus on minor improvements for the 4.2.1 release in the near term that would be appreciated. I'll create a release-4.2 branch at a point just prior to any commit on master that is not a minor low risk change. William On Fri, 1 Dec 2023 at 09:07, William S Fulton <ws...@fu...> wrote: > I would like to release swig-4.2.0 mid December ideally, but definitely > before the end of the year. As it is now over a year since the last > release, the issues I'd hoped to address for this release may have to be > deferred to a later version, see the 4.2 milestone: > https://github.com/swig/swig/milestone/5. I am going through them. If > anyone has a must have for 4.2, add it to the milestone and please aim to > have it ready by mid-month. Or otherwise speak up to replan. > > Thanks > William > |
From: William S F. <ws...@fu...> - 2023-12-31 01:10:53
|
*** ANNOUNCE: SWIG 4.2.0 (30 Dec 2023) *** https://www.swig.org We're pleased to announce SWIG-4.2.0, the latest SWIG release. What is SWIG? ============= SWIG is a software development tool that reads C/C++ header files and generates the wrapper code needed to make C and C++ code accessible from other programming languages including Perl, Python, Tcl, Ruby, PHP, C#, Go, Java, Javascript, Lua, Scheme (Guile, MzScheme), D, Ocaml, Octave, R, Scilab. SWIG can also export its parse tree in the form of XML. Major applications of SWIG include generation of scripting language extension modules, rapid prototyping, testing, and user interface development for large C/C++ systems. Release Notes ============= Detailed release notes are available with the release and are also published on the SWIG web site at https://swig.org/release.html. Availability ============ The release is available for download on Sourceforge at https://prdownloads.sourceforge.net/swig/swig-4.2.0.tar.gz A Windows version is also available at https://prdownloads.sourceforge.net/swig/swigwin-4.2.0.zip Please report problems with this release to the swig-devel mailing list, details at https://www.swig.org/mail.html. --- The SWIG Developers |
From: William S F. <ws...@fu...> - 2023-12-21 01:52:47
|
I have made a beta version of SWIG 4.2.0 available for testing before making the official release. I aim to turn this into the official release on 30 Dec if there are no major issues reported, so please test it before then and send feedback via the Github issue tracker or reply to this email including the mailing lists. Download it from here: Source tarball: http://prdownloads.sourceforge.net/swig/swig-4.2.0-beta1.tar.gz Windows prebuilt executable: http://prdownloads.sourceforge.net/swig/swigwin-4.2.0-beta1.zip SWIG-4.2.0 summary: - Various template wrapping improvements: template template parameters, variadic templates, partially specialized templates, const template parameters and improved error checking instantiating templates. - Improved decltype() support for expressions. - C++14 auto without trailing return type and C++11 auto variables. - Numerous C++ using declarations improvements. - Numerous fixes for constructors, destructors and assignment operators: implicit, default and deleted and related non-assignable variable wrappers. - STL: std::array and std::map improvements, std::string_view support added. - Various C preprocessor improvements. - Various issues fixed to do with architecture specific long type. - Various Doxygen improvements. - D1/Tango support removed. D2/Phobos is now the supported D version and SWIG now generates code which works with recent D2 releases. - New Javascript generator targeting Node.js binary stable ABI Node-API. - Octave 8.1 support added. - PHP7 support removed, PHP8 is now the supported PHP version. - Python STL container wrappers now use the Python Iterator Protocol. - Python stable ABI support added. - Python 3.12 support added. - Ruby 3.2 and 3.3 support. - Scilab 2023.* support added. - Various minor enhancements for C#, Go, Guile, Javascript, Lua, Ocaml, Perl, PHP, R, Racket, Ruby, Scilab and Tcl. - A number of deprecated features have been removed. William |
From: Momtchil M. <mom...@mo...> - 2023-12-01 16:36:00
|
From SWIG Node-API, currently: * async is ready for merging and should work reasonably well as it used by magickwand.js on npm * TypeScript is mostly ready to merge, from what I remember there were one or two unit tests that depended on changes in async that must be modified before merging, TypeScript should also work reasonably well but needs documentation which is not a problem since it is very simple to use, it boils down to two new typemaps that specify the TypeScript type * WASM support with emnapi is a collection of small compatibility fixes that can be merged along async and TypeScript, however WASM will require setting up a complex testing using browsers and cannot be official - although it will probably work * Code splitting cannot be ready in time On 01/12/2023 10:07 am, William S Fulton wrote: > I would like to release swig-4.2.0 mid December ideally, but > definitely before the end of the year. As it is now over a year since > the last release, the issues I'd hoped to address for this release may > have to be deferred to a later version, see the 4.2 milestone: > https://github.com/swig/swig/milestone/5. I am going through them. If > anyone has a must have for 4.2, add it to the milestone and please aim > to have it ready by mid-month. Or otherwise speak up to replan. > > Thanks > William > > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel -- Momtchil Momtchev <mom...@mo...> |
From: William S F. <ws...@fu...> - 2023-12-01 09:13:17
|
I would like to release swig-4.2.0 mid December ideally, but definitely before the end of the year. As it is now over a year since the last release, the issues I'd hoped to address for this release may have to be deferred to a later version, see the 4.2 milestone: https://github.com/swig/swig/milestone/5. I am going through them. If anyone has a must have for 4.2, add it to the milestone and please aim to have it ready by mid-month. Or otherwise speak up to replan. Thanks William |
From: Julien M. <jul...@gm...> - 2023-11-23 10:00:34
|
Hello Matěj, I made modifications to your PR to include autodetection, tests, and syntax adjustments, cf https://github.com/openSUSE-Python/vim/pull/1 Best, Julien -- Julien Marrec, EBCP, BPI MFBA Owner at EffiBEM <http://www.effibem.com> T: +33 6 95 14 42 13 LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) *| *(fr <https://fr.linkedin.com/in/julienmarrec/fr>) : <http://www.linkedin.com/in/julienmarrec> Le mer. 22 nov. 2023 à 23:26, Matěj Cepl <mc...@ce...> a écrit : > Hi, > > I have found somewhere a syntax file for vim and editing SWIG > files. I have decided to post it to the vim project upstream, > so that it would have native SWIG support, and the result is > https://github.com/vim/vim/pull/13540 > > Can I ask for help here with the questions posted on that PR? > > 1. Most complicated seems to be how to autodetect > SWIG file. Any thoughts. I cannot even find any > other editor modules which would do something like > that. Emacs module (https://github.com/dholm/swig-mode) > doesn't seem to have anything. VS Code module > (https://github.com/starofrainnight/vscode-swiglang), Atom > (https://github.com/kankaristo/language-swig-wrapper) module, > or Submile (https://github.com/jonschlinkert/sublime-swig) > don't seem to be much helpful either. > > 2. Any more comments on the syntax file itself? > > Best, > > Matěj > > -- > http://matej.ceplovi.cz/blog/, @mc...@fl...cial > GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 > > When you’re happy that cut and paste actually works I think it’s > a sign you’ve been using X-Windows for too long. > -- from /. discussion on poor integration between KDE and > GNOME > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: Matěj C. <mc...@ce...> - 2023-11-22 22:25:27
|
Hi, I have found somewhere a syntax file for vim and editing SWIG files. I have decided to post it to the vim project upstream, so that it would have native SWIG support, and the result is https://github.com/vim/vim/pull/13540 Can I ask for help here with the questions posted on that PR? 1. Most complicated seems to be how to autodetect SWIG file. Any thoughts. I cannot even find any other editor modules which would do something like that. Emacs module (https://github.com/dholm/swig-mode) doesn't seem to have anything. VS Code module (https://github.com/starofrainnight/vscode-swiglang), Atom (https://github.com/kankaristo/language-swig-wrapper) module, or Submile (https://github.com/jonschlinkert/sublime-swig) don't seem to be much helpful either. 2. Any more comments on the syntax file itself? Best, Matěj -- http://matej.ceplovi.cz/blog/, @mc...@fl...cial GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 When you’re happy that cut and paste actually works I think it’s a sign you’ve been using X-Windows for too long. -- from /. discussion on poor integration between KDE and GNOME |
From: William S F. <ws...@fu...> - 2023-09-22 07:47:09
|
I'm sure the Magickwand and Node.js communities will appreciate all your work adding Node.js support to SWIG, but on behalf of the SWIG community, I would like to thank you for your contribution. Adding another first class, popular target language variant to SWIG strengthens the SWIG project and has knock on benefits for C++ and inter-language operability in general. Thanks. Looking forward to the Typescript submission! William On Wed, 20 Sept 2023 at 09:13, Momtchil Momtchev <mom...@mo...> wrote: > > Hello, > > > I am very proud to announce that node-magickwand, the Node.js bindings > for the famous ImageMagick C++ library, has graduated to beta status and it > is now feature-complete. > > This project, which totals 412k lines of C++ code (13MB) in its default > configuration would never have been possible without SWIG Node-API. A true > testament to SWIG, it comes with: > > * Full native language feel, completely indistinguishable from a > hand-written native JS module > > * Full Promise-based modern asynchronous support, including asynchronous > I/O that never blocks the Node.js event loop and supports both I/O and > CPU-heavy multi-threading with automatic locking > > * Automatically generated TypeScript bindings (3800 exported symbols) > > * Node-API interface to Node.js which allows the publishing of binary > modules to NPM that are compatible with all Node.js versions and can be > used from Node.js-derivatives such as Electron > > > The 412k of resulting code come at the price of 687 lines of generously > commented SWIG code, an amazing 1:600 ratio. > > The project is also meant as a tutorial for the upcoming SWIG Node-API: > > > https://medium.com/@mmomtchev/effortlessly-porting-a-major-c-library-to-node-js-with-swig-napi-3c1a5c4a233f > > (the tutorial is geared mainly towards experienced Node-API developers who > are new to SWIG) > > > Currently, the base SWIG Node-API has already been merged in SWIG, the > asynchronous support PR is currently in review and the TypeScript support > is in final stages of development. A highly experimental SWIG version that > includes the merge of all three is available from > https://github.com/mmomtchev/swig.git branch mmom (it is a very fast > moving target and it should be expected to break). > > > node-magickwand can be installed from npm (pre-built binaries are > available only for Windows x64, Linux x64 and macOS x64): > > npm i node-magickwand > > > -- > Momtchil Momtchev <mom...@mo...> <mom...@mo...> > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: William S F. <ws...@fu...> - 2023-09-22 07:07:37
|
I've never been too sure when %types is really needed, so I can't advise much on that. There is actually support for the C++ implicit conversions you desire. Python has the reference implementation, but it looks like Octave also has support for it, but I'm not sure it works as I can't find a test for it. The support is in the core, but requires target language support too and it will need porting from Python to Javascript in order to use it. Search for "implicitconv" in the Source tree. Best user level docs are in the CHANGES file, see https://github.com/swig/swig/blob/4b6b711fa3ee8649487bace3e3837edf7ed6d2be/CHANGES#L11367. Testcase is Examples/test-suite/implicittest.i. William On Mon, 11 Sept 2023 at 16:01, Momtchil Momtchev <mom...@mo...> wrote: > Hello, > > In node-magickwand, the ImageMagick bindings for Node.js, I have the > following situation: > > Image constructor: > > Image::Image(const Geometry &geom) > > Geometry constructor: > > Geometry::Geometry(const std::string &spec) > > > In C++, the combination of these two allows me to construct an image by > simply typing > > Image im("640x480"); > > While in Javascript, with the SWIG-generated bindings I will have to type: > > const im = new Image(new Geometry('640x480'); > > > I would like to support the first syntax in the most efficient way. > > I have found the *%types* directive, but extending it to work with > primitive types will require some major changes that will impact many > generators. Currently primitive types do not have a *swig_info* structure > and cannot be cast. > > I have settled on the following construction: > > > https://github.com/mmomtchev/node-magickwand/blob/implicit-casting/src/ImplicitCasting.i > > %typemap(in) SWIGTYPE &FROM_STRING ($ltype from_string_temp) %{ > if ($input.IsString()) { > { > // If it is a string, apply the string typemap > // construct a new object > std::string *$1; > $typemap(in, const std::string &); > from_string_temp = new $*ltype(*$1); > } > $1 = from_string_temp; > } else { > // Otherwise apply the default generic typemap > from_string_temp = SWIG_NULLPTR; > $typemap(in, const $*ltype &); > } > %} > %typemap(freearg) SWIGTYPE &FROM_STRING %{ > // If the temp is not NULL, it must be freed > delete from_string_temp$argnum; > %} > > I then apply this generic typemap too all arguments (such as Geometry or > Color) that may be constructed from strings. > > Besides being somewhat complex, It has only one drawback: I cannot apply > it to all argument names, I must enumerate them one by one - or otherwise I > end up with an infinite typemap recursion since I reference the generic > typemap. > > > Does anyone see a better way to do this with SWIG? > > -- > Momtchil Momtchev <mom...@mo...> <mom...@mo...> > > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: Momtchil M. <mom...@mo...> - 2023-09-20 08:12:52
|
Hello, I am very proud to announce that node-magickwand, the Node.js bindings for the famous ImageMagick C++ library, has graduated to beta status and it is now feature-complete. This project, which totals 412k lines of C++ code (13MB) in its default configuration would never have been possible without SWIG Node-API. A true testament to SWIG, it comes with: * Full native language feel, completely indistinguishable from a hand-written native JS module * Full Promise-based modern asynchronous support, including asynchronous I/O that never blocks the Node.js event loop and supports both I/O and CPU-heavy multi-threading with automatic locking * Automatically generated TypeScript bindings (3800 exported symbols) * Node-API interface to Node.js which allows the publishing of binary modules to NPM that are compatible with all Node.js versions and can be used from Node.js-derivatives such as Electron The 412k of resulting code come at the price of 687 lines of generously commented SWIG code, an amazing 1:600 ratio. The project is also meant as a tutorial for the upcoming SWIG Node-API: https://medium.com/@mmomtchev/effortlessly-porting-a-major-c-library-to-node-js-with-swig-napi-3c1a5c4a233f (the tutorial is geared mainly towards experienced Node-API developers who are new to SWIG) Currently, the base SWIG Node-API has already been merged in SWIG, the asynchronous support PR is currently in review and the TypeScript support is in final stages of development. A highly experimental SWIG version that includes the merge of all three is available from https://github.com/mmomtchev/swig.git branch mmom (it is a very fast moving target and it should be expected to break). node-magickwand can be installed from npm (pre-built binaries are available only for Windows x64, Linux x64 and macOS x64): |npm i node-magickwand| -- Momtchil Momtchev<mom...@mo...> |