Hi Shivam
Sorry for the delay in responding... lots of GSOC emails to get through
in the last few days! My suggestion for this would be that we basically
want to eliminate the C++ layer. The approach I took when first writing
the C++ layer in ASCEND was to try to create a disposable/light
interface on top of the C code in ASCEND that enabled some higher-level
constructs to be used, eg STL containers etc, which were then easier
(for me) to wrap with SWIG and hence access from Python. For example, I
can create an STL vector of pointers to certain ASCEND structures, and
then easily iterate over them etc in Python. To do the same in pure C
requires a different approach, and requires telling SWIG special stuff
such as not to destroy the things being pointed to when Python decides
that it's time to destroy the object(s) in question. This is the kind of
issue that would need careful attention when rewriting the Python
bindings. A fairly straightforward job, but requiring attention to
memory/object management, possibly reference counting, etc. Once the
first objects are wrapped, hopefully it gets easier and easier to do the
remaining ones. I am happy to concede that the job is a biggish one,
requiring probably most of the time of GSOC, so I am happy for you to
put forward a proposal along those lines if you would like to.
Cheers
JP
On 14/03/15 10:14, Shivam Chaturvedi 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
