Hi Shivam
I think I may have clarified this in another email. The aim is to
eliminate the C++ code. I believe that the STL-based code is very heavy,
so would like to try going back to pure C-based wrapper. It may require
tweaking some function definitions in the C layer of ASCEND. The C++
code should be a pointer for the places to look for that. Hope this helps,
Cheers
JP
On 16/03/15 22:55, Shivam Chaturvedi wrote:
Hello John,
I'm not sure my previous mail was clear with the doubts that I had
encountered. As I'm a bit stuck with it, I would like to know whether
I should try to make the SWIG bindings while keeping the CPP code
intact, or should I try to convert the Instance module to the C Code
and then try to have a go at the SWIG bindings.
Let me know at the earliest so that I can start on my proposal for the
same.
Thank you!
On Sat, Mar 14, 2015 at 4:44 AM Shivam Chaturvedi <[email protected]
<mailto:[email protected]>> wrote:
Hello John,
I had a good look at the interface file that has been described in
the ascxx interface file as well as the ones described for the
fprops module. Although the fprops module is fully written in C
and hence is easily convertable to corresponding python bindings,
I've had some trouble doing the same for the ascxx module, one of
which, as you described was the 'Instanc' module. What I'm not
sure at the moment is whether the module needs a complete C++ to C
rewrite or not. Although that can be done by converting the
classes to their corresponding structures with the methods built
for each class method, while the members, as I can see, would be
the member variables of the structure. To remove the STL part, for
example where Template class T structure occurs, it could be
normalized for the exact variables for each of the types possible.
I saw that the two types that would be replaces by the template
have long and SymChar as the candidates for template substitution.
Also, I wasn't sure why the headers are straight on pasted into
the interface file. We could potentially normalize the template
substitution and then define the same in the instance.h file and
then just include the instance.h file in the ascxx interface file.
Also, if we were to start removing C++ code and replace it with
pure C code, which though possible, seems like a task that should
take the duration of the GSoC project.
It would be awesome if you could clear the above doubts and we
could move further in our development.
Thank you!
On Thu, Mar 12, 2015 at 10:25 AM John Pye <[email protected]
<mailto:[email protected]>> wrote:
Hi Shivam
Sounds like you are on the right path. Have a go at the SWIG
bindings for Instance following the pattern of FPROPS. Give it
a try, let me know when you have something.
Thanks for the clarification about the wiki info. I will try
to get that updated ASAP.
Cheers
JP
On 10/03/15 02:50, Shivam Chaturvedi wrote:
Hello John,
I've had a look at the ascxx interface file and I saw how the
Instance file is defined as a list of the prototypes instead
of a single header file as the other classes have been
defined. I believe the task right now is to convert this list
of prototypes to a similar header file that can directly be
included in the interface file. I've studies the involved
source codes. I'm continuing to understand the system by
looking at the FPROPS module as you told me to.
I believe it would be good for me to develop the SWIG
interface file for the Instance class so that you could see
if I have developed enough understanding of the rewriting
process.
Would love to hear from you on further steps.
*PS* I looked at the Building ASCEND wiki page, and the svn
checkout link is incorrectly stated as
' svn co svn://ascend4.org/
<http://ascend4.org/>code/trunk ascend ' which seems to
refuse connections.
instead of
' svn co http://svn.ascend4.org/trunk/ascend ' which works
fine.
Thank you!
On Thu, Mar 5, 2015 at 3:30 PM Shivam Chaturvedi
<[email protected] <mailto:[email protected]>> wrote:
Thank you for such a detailed response. I looked at SWIG
before I found this project interesting and I agree that
it would make our lives quite easier if we followed SWIG
and later came up with binding for R, Octave etc. (which
was also something I thought of when I looked at SWIG as
a project, but yeah, later developments).
I'll look into the suggested readings and get back to you
with my ideas.
Thanks,
Shivam
On Thu, Mar 5, 2015 at 6:59 AM John Pye
<[email protected] <mailto:[email protected]>> wrote:
Hi Shivam
As you can probably appreciate, this project
represents a pretty major effort and will require
both a deep and broad understanding of the ASCEND
APIs in C, as well as the requirements of the current
PyGTK GUI. I think that the work should probably
start with Pallav Tinna's branch of the repository,
which already migrates the GUI from GTK2 to GTK3
toolkit. The goal would be to eliminate the C++ and
STL code as far as possible, and aim for faster and
lighter Python bindings, while also aiming at a clean
and maintainable approach. I believe that SWIG is
quite capable as a tool for doing this, and I myself
am very comfortable with SWIG, but if you can see a
strong case for adopting another tool then we can
consider that. One aspect of SWIG that is a appealing
is that in principle it can be used to target several
different scripting languages. Of interest for
scientific work would be R, Octave, Scilab and
possibly a couple of others. This is not a priority
for us, but is a mild reason to stick with the SWIG
approach, as I see it.
For some inspiration on bindings from Python to C, I
suggest you look at the code of FPROPS [1]. That
wrapper builds object-oriented Python classes based
around C structs and associated methods. I think that
an early start on the proposed project could be made
by attempting to reproduce this approach for the
'instance' data structures in the ASCEND C API. You
can take a look at how this is done currently at
[2-4]. There is probably benefit in also wrapping
some of the generic types in ASCEND, such as gl_list
[5], which are used extensively if not quite
universally, in the ASCEND C code.
Hopefully that provides some starting points for you.
Take a look and let me know how you go.
Cheers
JP
[1]
http://code.ascend4.org/ascend/trunk/models/johnpye/fprops/python/fprops.i?revision=2774&view=markup
[2]
http://code.ascend4.org/ascend/trunk/ascxx/instance.cpp?view=markup
[3]
http://code.ascend4.org/ascend/trunk/ascxx/instance.h?view=log
[4]
http://code.ascend4.org/ascend/trunk/ascxx/ascpy.i?view=markup
[5]
http://code.ascend4.org/ascend/trunk/ascend/general/list.h?view=markup
On 05/03/15 06:31, Shivam Chaturvedi wrote:
Hello ASCEND Devs,
I am Shivam Chaturvedi. I had a look at one of your
projects that I became keenly interested on. It was
the "Python Bindings Rewrite" project, which
understandably requires the knowledge of Python, C++
and knowledge of concerned programming paradigms
such as interfaces, etc. I'm fluent in both the
languages at a decent level and have previously
worked a bit in both (Even taught Python to
undergrad students!).
I have downloaded ASCEND on my linux machine (and
started to fiddle with it!) to see how I would think
the software must've been put up, in addition to
(trying) to read the source (mainly examples for now).
I wish to contribute in all ways possible to this
project.
Might be needless, but to state, I'm a student at
IIIT-Delhi, India, and would love to work with you guys.
Please let me know what more I can do to help out.
Thanks!
Shivam Chaturvedi
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel
Website, sponsored
by Intel and developed in partnership with Slashdot Media, is
your hub for all
things parallel software development, from weekly thought
leadership blogs to
news, videos, case studies, tutorials and more. Take a look and
join the
conversation now.http://goparallel.sourceforge.net/
_______________________________________________
Ascend-sim-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/ascend-sim-users
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Ascend-sim-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ascend-sim-users
