Hello<div>I'm sorry because what I said has no sence: i didn't know how swig works before.<br><div>I have been reading how swig works <a href="http://www.swig.org/Doc2.0/Extending.html#Extending_nn5" target="_blank">http://www.swig.org/Doc2.0/Extending.html#Extending_nn5</a> and I started understanding.</div>
<div><br></div>
<div>I didn't have the time to read the hole documentation of swig, however I think that the best moment to include use implement the zend api is in the prepossessing: when preprocessor reads the collection of configuration files , we will then translate these config file to zend api code .</div>
<div>In the code generation phase, we will not generate wrapper code since we don't need anymore.</div><div>What do you think please?</div><div><br></div><div>Yours sincerely</div><div>Riadh<br><br><div class="gmail_quote">
2012/4/4 Olly Betts <span dir="ltr"><<a href="mailto:olly@survex.com" target="_blank">olly@survex.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, Apr 03, 2012 at 02:12:56PM +0200, riadh chtara wrote:<br>
> I will take you comment suggestion about timing in consideration.<br>
> What do you thing about this Schedule?<br>
><br>
</div>> 1. April 30 ? May 20 : Checking the Coding guidelines, Installing<br>
<div>> development environment, Reading and understanding deeply the source<br>
> SWIG and wrapped API , Discussing with mentors about the final<br>
> details of the project<br>
</div>> 2. May 21 ? May 29: Defining the changes needed in SWIG<br>
> 3. May 28 - July 13: adding new function to SWIG<br>
<br>
You need much more detail here - that's 6 weeks with a really vague one<br>
phrase description. In mid-June, how can we tell you are doing? Even<br>
on July 13th, how can we tell how you are doing?<br>
<br>
> 4. JULY 13<br>
> 5. MID TERM EVALUATION Dead line<br>
> 6. July 13 ?July 22: adding new function to SWIG, Testing SWIG,<br>
> Writing the documentation for SWIGo<br>
<br>
I think you need to investigate how SWIG's PHP backend currently<br>
works, and think about what you would change about that to make<br>
the change from defining the PHP classes in a generated PHP wrapper<br>
script to doing this in the generated C++ wrapper code using PHP's<br>
Zend API. And what a logical order to tackle these changes would<br>
be.<br>
<br>
SWIG already has an extensive testsuite, which I think all currently<br>
passes for PHP - certainly most of it does. So you have a natural<br>
measure of progress here - how much of SWIG's testsuite passes with your<br>
changes to the SWIG PHP backend?<br>
<br>
> 7. July 23 ? August 15: Improving the xapian php api<br>
> 8. August 16-August 20: Testing the new version of the xapian<br>
<div>> api, Writing the documentation for it<br>
<br>
</div>Much too vague, and you really want to implement, test, and document<br>
each improvement in turn.<br>
<div><br>
> For the mid term evaluation do I need to make a deliverable?<br>
<br>
</div>Ideally the project should provide a series of deliverables, not<br>
just one in the middle and one at the end.<br>
<br>
On Wed, Apr 04, 2012 at 12:37:55AM +0200, riadh chtara wrote:<br>
> I have an approach for handling php with swig.<br>
> Swig needs to act like this when we use it for php<br>
><br>
> - first it analyses the code<br>
> - then it inserts the zend api instuctions into the code<br>
> - finally it generates and compiles the zend extensions<br>
><br>
> What do you think?<br>
> I that couldn't work , please tell me how could I make that.<br>
<br>
You really need to make this fit with how SWIG already works, so trying<br>
to think about how to implement this without having looked at that is<br>
rather futile.<br>
<br>
Cheers,<br>
Olly<br>
</blockquote></div><br></div></div>