Fwd: GSoC - Octave code sharing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Fwd: GSoC - Octave code sharing

Sahil
Hi Kai

I've made a timeline for octave code sharing. I've given a Google Doc link in my User Profile page (https://wiki.octave.org/User:Batterylow) on octave so that anyone can directly comment on the exact line/section. Alternatively, anyone can view the same link [1] here. Please have a look at my proposed path and suggest your valuable inputs. 

Thanks and Regards

Sahil


---------- Forwarded message ----------
From: Kai Torben Ohlhus <[hidden email]>
Date: 17 April 2018 at 13:03
Subject: Re: GSoC - Octave code sharing
To: Sahil <[hidden email]>
Cc: Ankit Raj <[hidden email]>


Greetings Sahil,

On Sun, Apr 15, 2018 at 6:44 PM Sahil <[hidden email]> wrote:
Hello Kai

I started by first learning RESTful web services. I followed some blog post about deploying a web application based on Apache Maven. That being done, I tried to deploy one other app based on Apache Tomcat server. I had some problems with the second approach (some java class was not being on the config path, but I got it working after a few hours of fidgetting around the directory structure.) I learnt about various methods, error types and terms associated with the HTTP requests that REST makes and saw how they actually work. Read about the MediaWiki introduction that you've written

I think dealing with Apache Tomcat and alike is a bit overkill for this particular project, but maybe interesting for you.  Just to be clear: we do have already a webserver (that one https://wiki.octave.org is running or https://nbviewer.jupyter.org/, depending on a decision we will do in the next days) and the major task I imagine is "How to communicate with the existing webserver?".   Therefore I use the term "RESTful", because it just means to give the stateless HTTP protocol some state via cookies to enable logins for MediaWiki installations.

Until you are accepted, I suggest the following steps:

1. All following communication should be moved back to the maintainers mailing list.
 
2. The project outline (the task for the code sharing project should be updated in your blog, https://wiki.octave.org/User:Batterylow, or [https://wiki.octave.org/Agora_Octave --> redirected to something like https://wiki.octave.org/Code_sharing])  A good starting point is the content of your project proposal.


Now regarding your questions:
 
That being said, I also understood the existing curl wrapper that you've already written and executing it after making some amendment, from your repository. I have a few questions:

1. There's this second subpoint of the second point in this :
It should be possible to opt it's functionality out, even after Octave was built, without making it useless.
    Does it means that we should be able to 'toggle' the connection to wiki.octave.org or should it be able to ? 'publish' and 'grabcode' should remain          as it is for this, I believe? 
 
This project is more Octave core related.  My imagined scenario is, that you can delete for example "__curl_wrapper__.oct", with Octave just detecting thi.  Maybe some security admin doesn't want Octave being able to connect to the internet and decides to delete this wrapper in his installation to ensure this.  This is very low priority.

2. Kindly correct me if I am wrong, we will need to inculcate the RESTful services in the following yet-to-implement functions:
   web, webread, webwrite, websave, weboptions,sendmail.
    The libcurl wrapper should be used by the above mentioned functions, right?

Not all of them are required for the project (your time is limited), but any implementation of the wrapper should aim for compatibility of this MATLAB interface.
 
3. I do not think there should be a need to change 'publish' and 'grabcode'. Can we simply use 'output_format' field as 'xml' and use its output to get        the RESTful service work?

We might later use some function like publishToWiki.m to upload the mediawiki formatted file to https://wiki.octave.org.
  
4. It would be really helpful to me if you can help me understand how is cURL interacting with wikiLogin.sh when we are using the libcurl_wrapper in        the functions mentioned in point 2.

For now this file publishToWiki.m uses the system shell (e.g. the bash script wikiLogin.sh) to get it's work done.  THIS IS YOUR PROJECT!  Last year, I started an attempt using Java to do the RESTful login to the wiki wiki_login.m, which is incomplete.  Instead of Java a more ambitioned project is not to just make this particular use case work, moreover to use libCURL to teach Octave itself to do RESTful (e.g. cookies) connections to an existing webserver.
 
5. Since 'urlread' cannot handle session cookies, will we need to save the cookies in the octave workspace itself?

If you decide to implement the functions of your point 2. Then the session handling will be controlled by these functions (the Octave workspace will just get a handle to the connection itself).  All the connection associated data will be implicitly available from that connection handle and the user should not care about them.
 
6. Do I need to touch theseambitioned files or everything is to be done on the functions in point 2 and the libcurl wrapper? Most of them will ease my work, I              believe.
 
All in all, from what I've gathered, the path looks something like this for the project:
1. Create an interface between libcurl (by implementing octave::curl_transfer ?) and publish() and provide an abstraction to it in the form of a single function to publish it on https://wiki.octave.org/Agora_Octave.
2. Create the RESTful web services for octave which could be flexibly (by a user's will) used by the functions mentioned in point 2 above.
3. Come up with a solution to store session cookies.

See my previous answers.
 
This is what all I could get by reading your email:

 Regarding the project I figured out last year was to "misuse" the 
possibilities of MediaWiki to easily store Octave functions and scripts 
(including MediaWiki's version control and nice builtin code presentation) 
by using "publish" and "grabcode" from GNU Octave to 
https://wiki.octave.org. 

The major work of this project was to "teach" Octave the RESTful web service 
functions [2] (especially cookies using libcurl or alike).  The syntax 
highlighting etc. is already included into GNU Octave and the MediaWiki 
part.  There is NO need to establish a new website (e.g. Agora) 

and your Oct Conf slides. I'm really sorry if I interpreted it in some other way or if there's something horribly wrong in the above written approach and questions. I would be really glad if you could help me in getting the right directions and major changes which I deduced that need working upon. 
I may set up a proper timeline if you believe my understanding for the project is fine.

Any other advice is wholeheartedly welcomed. 

Thanks for your time.

Regards 

-- 
*************************************

Sahil Yadav
Bachelor (III) in Computer Science and Engineering
Indian Institute of Technology, Mandi(H.P.), India - 175005
 
**************************************


I think we start with a detailed project outline in the wiki or blog as basis for further discussions.

Best,
Kai 



-- 
*************************************

Sahil Yadav
Bachelor (III) in Computer Science and Engineering
Indian Institute of Technology, Mandi(H.P.), India - 175005

**************************************

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Sahil
Hello Kai

I've sent the trailing mail to [hidden email] but idk why it's not showing up in the archive as well as nabble. Can you please see how can I get this conversation to the mailing list? 

Thanks
Sahil

PS: I've made the time frame for the project for your review.

On 18 April 2018 at 21:39, Sahil <[hidden email]> wrote:
Hi Kai

I've made a timeline for octave code sharing. I've given a Google Doc link in my User Profile page (https://wiki.octave.org/User:Batterylow) on octave so that anyone can directly comment on the exact line/section. Alternatively, anyone can view the same link [1] here. Please have a look at my proposed path and suggest your valuable inputs. 

Thanks and Regards

Sahil


---------- Forwarded message ----------
From: Kai Torben Ohlhus <[hidden email]>
Date: 17 April 2018 at 13:03
Subject: Re: GSoC - Octave code sharing
To: Sahil <[hidden email]>
Cc: Ankit Raj <[hidden email]>


Greetings Sahil,

On Sun, Apr 15, 2018 at 6:44 PM Sahil <[hidden email]> wrote:
Hello Kai

I started by first learning RESTful web services. I followed some blog post about deploying a web application based on Apache Maven. That being done, I tried to deploy one other app based on Apache Tomcat server. I had some problems with the second approach (some java class was not being on the config path, but I got it working after a few hours of fidgetting around the directory structure.) I learnt about various methods, error types and terms associated with the HTTP requests that REST makes and saw how they actually work. Read about the MediaWiki introduction that you've written

I think dealing with Apache Tomcat and alike is a bit overkill for this particular project, but maybe interesting for you.  Just to be clear: we do have already a webserver (that one https://wiki.octave.org is running or https://nbviewer.jupyter.org/, depending on a decision we will do in the next days) and the major task I imagine is "How to communicate with the existing webserver?".   Therefore I use the term "RESTful", because it just means to give the stateless HTTP protocol some state via cookies to enable logins for MediaWiki installations.

Until you are accepted, I suggest the following steps:

1. All following communication should be moved back to the maintainers mailing list.
 
2. The project outline (the task for the code sharing project should be updated in your blog, https://wiki.octave.org/User:Batterylow, or [https://wiki.octave.org/Agora_Octave --> redirected to something like https://wiki.octave.org/Code_sharing])  A good starting point is the content of your project proposal.


Now regarding your questions:
 
That being said, I also understood the existing curl wrapper that you've already written and executing it after making some amendment, from your repository. I have a few questions:

1. There's this second subpoint of the second point in this :
It should be possible to opt it's functionality out, even after Octave was built, without making it useless.
    Does it means that we should be able to 'toggle' the connection to wiki.octave.org or should it be able to ? 'publish' and 'grabcode' should remain          as it is for this, I believe? 
 
This project is more Octave core related.  My imagined scenario is, that you can delete for example "__curl_wrapper__.oct", with Octave just detecting thi.  Maybe some security admin doesn't want Octave being able to connect to the internet and decides to delete this wrapper in his installation to ensure this.  This is very low priority.

2. Kindly correct me if I am wrong, we will need to inculcate the RESTful services in the following yet-to-implement functions:
   web, webread, webwrite, websave, weboptions,sendmail.
    The libcurl wrapper should be used by the above mentioned functions, right?

Not all of them are required for the project (your time is limited), but any implementation of the wrapper should aim for compatibility of this MATLAB interface.
 
3. I do not think there should be a need to change 'publish' and 'grabcode'. Can we simply use 'output_format' field as 'xml' and use its output to get        the RESTful service work?

We might later use some function like publishToWiki.m to upload the mediawiki formatted file to https://wiki.octave.org.
  
4. It would be really helpful to me if you can help me understand how is cURL interacting with wikiLogin.sh when we are using the libcurl_wrapper in        the functions mentioned in point 2.

For now this file publishToWiki.m uses the system shell (e.g. the bash script wikiLogin.sh) to get it's work done.  THIS IS YOUR PROJECT!  Last year, I started an attempt using Java to do the RESTful login to the wiki wiki_login.m, which is incomplete.  Instead of Java a more ambitioned project is not to just make this particular use case work, moreover to use libCURL to teach Octave itself to do RESTful (e.g. cookies) connections to an existing webserver.
 
5. Since 'urlread' cannot handle session cookies, will we need to save the cookies in the octave workspace itself?

If you decide to implement the functions of your point 2. Then the session handling will be controlled by these functions (the Octave workspace will just get a handle to the connection itself).  All the connection associated data will be implicitly available from that connection handle and the user should not care about them.
 
6. Do I need to touch theseambitioned files or everything is to be done on the functions in point 2 and the libcurl wrapper? Most of them will ease my work, I              believe.
 
All in all, from what I've gathered, the path looks something like this for the project:
1. Create an interface between libcurl (by implementing octave::curl_transfer ?) and publish() and provide an abstraction to it in the form of a single function to publish it on https://wiki.octave.org/Agora_Octave.
2. Create the RESTful web services for octave which could be flexibly (by a user's will) used by the functions mentioned in point 2 above.
3. Come up with a solution to store session cookies.

See my previous answers.
 
This is what all I could get by reading your email:

 Regarding the project I figured out last year was to "misuse" the 
possibilities of MediaWiki to easily store Octave functions and scripts 
(including MediaWiki's version control and nice builtin code presentation) 
by using "publish" and "grabcode" from GNU Octave to 
https://wiki.octave.org. 

The major work of this project was to "teach" Octave the RESTful web service 
functions [2] (especially cookies using libcurl or alike).  The syntax 
highlighting etc. is already included into GNU Octave and the MediaWiki 
part.  There is NO need to establish a new website (e.g. Agora) 

and your Oct Conf slides. I'm really sorry if I interpreted it in some other way or if there's something horribly wrong in the above written approach and questions. I would be really glad if you could help me in getting the right directions and major changes which I deduced that need working upon. 
I may set up a proper timeline if you believe my understanding for the project is fine.

Any other advice is wholeheartedly welcomed. 

Thanks for your time.

Regards 

-- 
*************************************

Sahil Yadav
Bachelor (III) in Computer Science and Engineering
Indian Institute of Technology, Mandi(H.P.), India - 175005
 
**************************************


I think we start with a detailed project outline in the wiki or blog as basis for further discussions.

Best,
Kai 



-- 
*************************************

Sahil Yadav
Bachelor (III) in Computer Science and Engineering
Indian Institute of Technology, Mandi(H.P.), India - 175005

**************************************

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Ankit
Hello Sahil,


I have gone through your timeline. IT looks good and achievable from my side. It would be great if you include the testcases there which you wanted to write.

Thanks,
Ankit Raj




On Wed, Apr 18, 2018 at 10:28 PM, Sahil <[hidden email]> wrote:
Hello Kai

I've sent the trailing mail to [hidden email] but idk why it's not showing up in the archive as well as nabble. Can you please see how can I get this conversation to the mailing list? 

Thanks
Sahil

PS: I've made the time frame for the project for your review.

On 18 April 2018 at 21:39, Sahil <[hidden email]> wrote:
Hi Kai

I've made a timeline for octave code sharing. I've given a Google Doc link in my User Profile page (https://wiki.octave.org/User:Batterylow) on octave so that anyone can directly comment on the exact line/section. Alternatively, anyone can view the same link [1] here. Please have a look at my proposed path and suggest your valuable inputs. 

Thanks and Regards

Sahil


---------- Forwarded message ----------
From: Kai Torben Ohlhus <[hidden email]>
Date: 17 April 2018 at 13:03
Subject: Re: GSoC - Octave code sharing
To: Sahil <[hidden email]>
Cc: Ankit Raj <[hidden email]>


Greetings Sahil,

On Sun, Apr 15, 2018 at 6:44 PM Sahil <[hidden email]> wrote:
Hello Kai

I started by first learning RESTful web services. I followed some blog post about deploying a web application based on Apache Maven. That being done, I tried to deploy one other app based on Apache Tomcat server. I had some problems with the second approach (some java class was not being on the config path, but I got it working after a few hours of fidgetting around the directory structure.) I learnt about various methods, error types and terms associated with the HTTP requests that REST makes and saw how they actually work. Read about the MediaWiki introduction that you've written

I think dealing with Apache Tomcat and alike is a bit overkill for this particular project, but maybe interesting for you.  Just to be clear: we do have already a webserver (that one https://wiki.octave.org is running or https://nbviewer.jupyter.org/, depending on a decision we will do in the next days) and the major task I imagine is "How to communicate with the existing webserver?".   Therefore I use the term "RESTful", because it just means to give the stateless HTTP protocol some state via cookies to enable logins for MediaWiki installations.

Until you are accepted, I suggest the following steps:

1. All following communication should be moved back to the maintainers mailing list.
 
2. The project outline (the task for the code sharing project should be updated in your blog, https://wiki.octave.org/User:Batterylow, or [https://wiki.octave.org/Agora_Octave --> redirected to something like https://wiki.octave.org/Code_sharing])  A good starting point is the content of your project proposal.


Now regarding your questions:
 
That being said, I also understood the existing curl wrapper that you've already written and executing it after making some amendment, from your repository. I have a few questions:

1. There's this second subpoint of the second point in this :
It should be possible to opt it's functionality out, even after Octave was built, without making it useless.
    Does it means that we should be able to 'toggle' the connection to wiki.octave.org or should it be able to ? 'publish' and 'grabcode' should remain          as it is for this, I believe? 
 
This project is more Octave core related.  My imagined scenario is, that you can delete for example "__curl_wrapper__.oct", with Octave just detecting thi.  Maybe some security admin doesn't want Octave being able to connect to the internet and decides to delete this wrapper in his installation to ensure this.  This is very low priority.

2. Kindly correct me if I am wrong, we will need to inculcate the RESTful services in the following yet-to-implement functions:
   web, webread, webwrite, websave, weboptions,sendmail.
    The libcurl wrapper should be used by the above mentioned functions, right?

Not all of them are required for the project (your time is limited), but any implementation of the wrapper should aim for compatibility of this MATLAB interface.
 
3. I do not think there should be a need to change 'publish' and 'grabcode'. Can we simply use 'output_format' field as 'xml' and use its output to get        the RESTful service work?

We might later use some function like publishToWiki.m to upload the mediawiki formatted file to https://wiki.octave.org.
  
4. It would be really helpful to me if you can help me understand how is cURL interacting with wikiLogin.sh when we are using the libcurl_wrapper in        the functions mentioned in point 2.

For now this file publishToWiki.m uses the system shell (e.g. the bash script wikiLogin.sh) to get it's work done.  THIS IS YOUR PROJECT!  Last year, I started an attempt using Java to do the RESTful login to the wiki wiki_login.m, which is incomplete.  Instead of Java a more ambitioned project is not to just make this particular use case work, moreover to use libCURL to teach Octave itself to do RESTful (e.g. cookies) connections to an existing webserver.
 
5. Since 'urlread' cannot handle session cookies, will we need to save the cookies in the octave workspace itself?

If you decide to implement the functions of your point 2. Then the session handling will be controlled by these functions (the Octave workspace will just get a handle to the connection itself).  All the connection associated data will be implicitly available from that connection handle and the user should not care about them.
 
6. Do I need to touch theseambitioned files or everything is to be done on the functions in point 2 and the libcurl wrapper? Most of them will ease my work, I              believe.
 
All in all, from what I've gathered, the path looks something like this for the project:
1. Create an interface between libcurl (by implementing octave::curl_transfer ?) and publish() and provide an abstraction to it in the form of a single function to publish it on https://wiki.octave.org/Agora_Octave.
2. Create the RESTful web services for octave which could be flexibly (by a user's will) used by the functions mentioned in point 2 above.
3. Come up with a solution to store session cookies.

See my previous answers.
 
This is what all I could get by reading your email:

 Regarding the project I figured out last year was to "misuse" the 
possibilities of MediaWiki to easily store Octave functions and scripts 
(including MediaWiki's version control and nice builtin code presentation) 
by using "publish" and "grabcode" from GNU Octave to 
https://wiki.octave.org. 

The major work of this project was to "teach" Octave the RESTful web service 
functions [2] (especially cookies using libcurl or alike).  The syntax 
highlighting etc. is already included into GNU Octave and the MediaWiki 
part.  There is NO need to establish a new website (e.g. Agora) 

and your Oct Conf slides. I'm really sorry if I interpreted it in some other way or if there's something horribly wrong in the above written approach and questions. I would be really glad if you could help me in getting the right directions and major changes which I deduced that need working upon. 
I may set up a proper timeline if you believe my understanding for the project is fine.

Any other advice is wholeheartedly welcomed. 

Thanks for your time.

Regards 

-- 
*************************************

Sahil Yadav
Bachelor (III) in Computer Science and Engineering
Indian Institute of Technology, Mandi(H.P.), India - 175005
 
**************************************


I think we start with a detailed project outline in the wiki or blog as basis for further discussions.

Best,
Kai 



-- 
*************************************

Sahil Yadav
Bachelor (III) in Computer Science and Engineering
Indian Institute of Technology, Mandi(H.P.), India - 175005

**************************************


Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

siko1056
Ankit wrote
> On Wed, Apr 18, 2018 at 10:28 PM, Sahil &lt;

> yadavsahil5198@

> &gt; wrote:
>
>> Hello Kai
>>
>> I've sent the trailing mail to

> octave-maintainers@

>  but idk why
>> it's not showing up in the archive as well as nabble. Can you please see
>> how can I get this conversation to the mailing list?
>>
>> Thanks
>> Sahil
>>
>> PS: I've made the time frame for the project for your review.
>>
>> On 18 April 2018 at 21:39, Sahil &lt;

> yadavsahil5198@

> &gt; wrote:
>>
>>> Hi Kai
>>>
>>> I've made a timeline for octave code sharing. I've given a Google Doc
>>> link in my User Profile page (https://wiki.octave.org/User:Batterylow)
>>> on octave so that anyone can directly comment on the exact line/section.
>>> Alternatively, anyone can view the same link [1] here. Please have a
>>> look
>>> at my proposed path and suggest your valuable inputs.
>>>
>>> Thanks and Regards
>>>
>>> Sahil
>>>
>>> [1] https://docs.google.com/document/d/1InJhgZQkW61a42qPwiIW
>>> jYz7xPo4Gk9fKhsdrd3G_7M/edit?usp=sharing
>>>
>>> ---------- Forwarded message ----------
>>> From: Kai Torben Ohlhus &lt;

> k.ohlhus@

> &gt;
>>> Date: 17 April 2018 at 13:03
>>> Subject: Re: GSoC - Octave code sharing
>>> To: Sahil &lt;

> yadavsahil5198@

> &gt;
>>> Cc: Ankit Raj &lt;

> aktjha@

> &gt;
>>>
>>>
>>> Greetings Sahil,
>>>
>>> On Sun, Apr 15, 2018 at 6:44 PM Sahil &lt;

> yadavsahil5198@

> &gt; wrote:
>>>
>>>> Hello Kai
>>>>
>>>> I started by first learning RESTful web services. I followed some blog
>>>> post about deploying a web application based on Apache Maven. That
>>>> being
>>>> done, I tried to deploy one other app based on Apache Tomcat server. I
>>>> had
>>>> some problems with the second approach (some java class was not being
>>>> on
>>>> the config path, but I got it working after a few hours of fidgetting
>>>> around the directory structure.) I learnt about various methods, error
>>>> types and terms associated with the HTTP requests that REST makes and
>>>> saw
>>>> how they actually work. Read about the MediaWiki introduction that
>>>> you've
>>>>  written
>>>> &lt;https://siko1056.github.io/blog/2017/03/10/getting-to-know-the-mediawiki-api.html&gt;
>>>> .
>>>>
>>>
>>> I think dealing with Apache Tomcat and alike is a bit overkill for this
>>> particular project, but maybe interesting for you.  Just to be clear: we
>>> do
>>> have already a webserver (that one https://wiki.octave.org is running or
>>> https://nbviewer.jupyter.org/, depending on a decision we will do in the
>>> next days) and the major task I imagine is "How to communicate with the
>>> existing webserver?".   Therefore I use the term "RESTful", because it
>>> just
>>> means to give the stateless HTTP protocol some state via cookies to
>>> enable
>>> logins for MediaWiki installations.
>>>
>>> Until you are accepted, I suggest the following steps:
>>>
>>> 1. All following communication should be moved back to the maintainers
>>> mailing list.
>>>
>>> 2. The project outline (the task for the code sharing project should be
>>> updated in your blog, https://wiki.octave.org/User:Batterylow, or [
>>> https://wiki.octave.org/Agora_Octave --> redirected to something like
>>> https://wiki.octave.org/C
>>> &lt;https://wiki.octave.org/Agora_Octave&gt;ode_sharing])
>>> A good starting point is the content of your project proposal.
>>>
>>>
>>> Now regarding your questions:
>>>
>>>
>>>> That being said, I also understood the existing curl wrapper that
>>>> you've
>>>> already written and executing it after making some amendment, from your
>>>> repository &lt;https://github.com/octave-de/octave-web&gt;. I have a
>>>> few
>>>> questions:
>>>>
>>>> 1. There's this second subpoint of the second point in this
>>>> &lt;https://github.com/octave-de/octave-web#things-to-improve&gt; :
>>>>
>>>>> It should be possible to opt it's functionality out, even after Octave
>>>>> was built, without making it useless.
>>>>
>>>>     Does it means that we should be able to 'toggle' the connection to
>>>> wiki.octave.org or should it be able to ? 'publish' and 'grabcode'
>>>> should remain          as it is for this, I believe?
>>>>
>>>
>>> This project is more Octave core related.  My imagined scenario is, that
>>> you can delete for example "__curl_wrapper__.oct", with Octave just
>>> detecting thi.  Maybe some security admin doesn't want Octave being able
>>> to
>>> connect to the internet and decides to delete this wrapper in his
>>> installation to ensure this.  This is very low priority.
>>>
>>> 2. Kindly correct me if I am wrong, we will need to inculcate the
>>> RESTful
>>>> services in the following yet-to-implement functions:
>>>>    web, webread, webwrite, websave, weboptions,sendmail.
>>>>     The libcurl wrapper should be used by the above mentioned
>>>> functions,
>>>> right?
>>>>
>>>
>>> Not all of them are required for the project (your time is limited), but
>>> any implementation of the wrapper should aim for compatibility of this
>>> MATLAB interface.
>>>
>>>
>>>> 3. I do not think there should be a need to change 'publish' and
>>>> 'grabcode'. Can we simply use 'output_format' field as 'xml' and use
>>>> its
>>>> output to get        the RESTful service work?
>>>>
>>>
>>> We might later use some function like publishToWiki.m
>>> &lt;https://github.com/octave-de/OctConf2017/blob/master/demo2/publishToWiki.m&gt;
>>> to
>>> upload the mediawiki formatted file to https://wiki.octave.org.
>>>
>>>
>>>> 4. It would be really helpful to me if you can help me understand how
>>>> is
>>>>  cURL interacting with wikiLogin.sh
>>>> &lt;https://rawgit.com/siko1056/Octconf2017/master/octconf2017-publish-ohlhus-slides.pdf#page=8&gt;
>>>>  when we are using the libcurl_wrapper in        the functions
>>>> mentioned in point 2.
>>>>
>>>
>>> For now this file publishToWiki.m
>>> &lt;https://github.com/octave-de/OctConf2017/blob/master/demo2/publishToWiki.m&gt;
>>> uses
>>> the system shell (e.g. the bash script wikiLogin.sh
>>> &lt;https://github.com/octave-de/OctConf2017/blob/master/demo2/wikiLogin.sh&gt;)
>>> to get it's work done.  THIS IS YOUR PROJECT!  Last year, I started an
>>> attempt using Java to do the RESTful login to the wiki wiki_login.m
>>> &lt;https://github.com/octave-de/OctConf2017/blob/master/demo2/wiki_login.m&gt;,
>>> which is incomplete.  Instead of Java a more ambitioned project is not
>>> to
>>> just make this particular use case work, moreover to use libCURL to
>>> teach
>>> Octave itself to do RESTful (e.g. cookies) connections to an existing
>>> webserver.
>>>
>>>
>>>> 5. Since 'urlread' cannot handle session cookies, will we need to save
>>>> the cookies in the octave workspace itself?
>>>>
>>>
>>> If you decide to implement the functions of your point 2. Then the
>>> session handling will be controlled by these functions (the Octave
>>> workspace will just get a handle to the connection itself).  All the
>>> connection associated data will be implicitly available from that
>>> connection handle and the user should not care about them.
>>>
>>>
>>>> 6. Do I need to touch theseambitioned files
>>>> &lt;https://github.com/octave-de/OctConf2017/tree/master/demo2&gt; or
>>>> everything is to be done on the functions in point 2 and the libcurl
>>>> wrapper? Most of them will ease my work, I              believe.
>>>>
>>>
>>>
>>>> All in all, from what I've gathered, the path looks something like this
>>>> for the project:
>>>> 1. Create an interface between libcurl (by implementing
>>>> octave::curl_transfer ?) and publish() and provide an abstraction to it
>>>> in
>>>> the form of a single function to publish it on
>>>> https://wiki.octave.org/Agora_Octave.
>>>> 2. Create the RESTful web services for octave which could be flexibly
>>>> (by a user's will) used by the functions mentioned in point 2 above.
>>>> 3. Come up with a solution to store session cookies.
>>>>
>>>
>>> See my previous answers.
>>>
>>>
>>>> This is what all I could get by reading your email:
>>>>
>>>>  Regarding the project I figured out last year was to "misuse" the
>>>>> possibilities of MediaWiki to easily store Octave functions and
>>>>> scripts
>>>>>
>>>>> (including MediaWiki's version control and nice builtin code
>>>>> presentation)
>>>>> by using "publish" and "grabcode" from GNU Octave to
>>>>> https://wiki.octave.org.
>>>>>
>>>>> The major work of this project was to "teach" Octave the RESTful web
>>>>> service
>>>>> functions [2] (especially cookies using libcurl or alike).  The syntax
>>>>> highlighting etc. is already included into GNU Octave and the
>>>>> MediaWiki
>>>>>
>>>>> part.  There is NO need to establish a new website (e.g. Agora)
>>>>
>>>>
>>>> and your Oct Conf slides. I'm really sorry if I interpreted it in some
>>>> other way or if there's something horribly wrong in the above written
>>>> approach and questions. I would be really glad if you could help me in
>>>> getting the right directions and major changes which I deduced that
>>>> need
>>>> working upon.
>>>> I may set up a proper timeline if you believe my understanding for the
>>>> project is fine.
>>>>
>>>> Any other advice is wholeheartedly welcomed.
>>>>
>>>> Thanks for your time.
>>>>
>>>> Regards
>>>>
>>>> --
>>>> *************************************
>>>>
>>>> Sahil Yadav
>>>> Bachelor (III) in Computer Science and Engineering
>>>> Indian Institute of Technology, Mandi(H.P.), India - 175005
>>>>
>>>
>>>
>>>> **************************************
>>>>
>>>
>>>
>>> I think we start with a detailed project outline in the wiki or blog as
>>> basis for further discussions.
>>>
>>> Best,
>>> Kai
>>>
>>>
>>>
>>> --
>>> *************************************
>>>
>>> Sahil Yadav
>>> Bachelor (III) in Computer Science and Engineering
>>> Indian Institute of Technology, Mandi(H.P.), India - 175005
>>>
>>> **************************************
>>>
>>
>>
>
> Hello Sahil,
>
>
> I have gone through your timeline. IT looks good and achievable from my
> side. It would be great if you include the testcases there which you
> wanted
> to write.
>
> Thanks,
> Ankit Raj


Sahil,

Thank you for the detailed timeline.  I added some comments.  A short
summary:

- Devote more time (> 4 weeks) to the implementation of the libCURL wrapper,
weboptions.m, webread.m, webwrite.m, websave.m (in the given order).  The
communication with the MediaWiki (login, etc.) relies on those functions to
work.

- We need to setup a test MediaWiki (I can provide some installation, when
you start testing).

Another thing I did not mention is, that we need to handle JSON-data.
Currently Octave does not support `json(en/de)code` [1] and (bug #53100),
but we can make use of jsonlab in the meantime [2], which is pure m-code,
thus easily replaceable but not high-performance.

Kai.

[1] https://www.mathworks.com/help/matlab/ref/jsondecode.html
[2] https://github.com/fangq/jsonlab



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Sahil
Thanks a lot, Kai and Ankit for your valuable comments and suggestions. I've
changed the timeline a bit with needed changes.
Now for  the summary part:

> Sahil,
>
> Thank you for the detailed timeline.  I added some comments.  A short
> summary:
>
> - Devote more time (> 4 weeks) to the implementation of the libCURL
> wrapper,
> weboptions.m, webread.m, webwrite.m, websave.m (in the given order).  The
> communication with the MediaWiki (login, etc.) relies on those functions
> to
> work.

The second week that you see (point 3) has which adds the "wiki" as an
output_format in publish() will not exactly span the complete week and so
libCURL will effectively get almost two weeks there. I do not think that I
should be giving the first two weeks only to libCURL wrapper because from
June 1 to June 10, there won't be any progress and so I think there should
at least be something significant work done before the first evaluation.
Maybe I'll start early with the implementation of wrapper before May 13
itself so that I get more time to focus on the wrapper?


> - We need to setup a test MediaWiki (I can provide some installation, when
> you start testing).

What exactly are we trying to do here? Will it be setting up a new wiki page
on wiki.octave.org or has it something to do with this kind of MediaWiki[3]
installation? If latter, how will we be communicating to the wiki pages on
wiki.octave.org then? I'm sorry but I'm a bit confused here.


> Another thing I did not mention is, that we need to handle JSON-data.
> Currently Octave does not support `json(en/de)code` [1] and (bug #53100),
> but we can make use of jsonlab in the meantime [2], which is pure m-code,
> thus easily replaceable but not high-performance.
>
> Kai.

Should I add this to timeline to implement jsonencode and jsondecode because
these look like a higher priority than the RESTful MATLAB compatible
interface functions?

And kindly mark the comments on Google doc as 'resolved' if you think the
query is resolved.

[1] https://www.mathworks.com/help/matlab/ref/jsondecode.html
[2] https://github.com/fangq/jsonlab
[3]
https://siko1056.github.io/blog/2017/03/10/getting-to-know-the-mediawiki-api.html#prerequisites-and-preparation


--
Sent from:
http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html





--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

siko1056
Sahil wrote

> Thanks a lot, Kai and Ankit for your valuable comments and suggestions.
> I've
> changed the timeline a bit with needed changes.
>
> [...]
>
> I do not think that I
> should be giving the first two weeks only to libCURL wrapper because from
> June 1 to June 10, there won't be any progress and so I think there should
> at least be something significant work done before the first evaluation.
> Maybe I'll start early with the implementation of wrapper before May 13
> itself so that I get more time to focus on the wrapper?

Basically, you can start any time.  The GSoC timeline is a guide to get good
work done.  If you finish the project by tomorrow, no one will blame you.
But take your time, your contribution should not be quick&dirty hacks and we
like to see GSoC contributors around after the project is done.


Sahil wrote

>> - We need to setup a test MediaWiki (I can provide some installation,
>> when
>> you start testing).
>
> What exactly are we trying to do here? Will it be setting up a new wiki
> page
> on wiki.octave.org or has it something to do with this kind of
> MediaWiki[3]
> installation? If latter, how will we be communicating to the wiki pages on
> wiki.octave.org then? I'm sorry but I'm a bit confused here.

Exactly, for testing we should not use wiki.octave.org (we might mess up a
lot).  At the end of GSoC, we just switch the API address from
"www.crashtest.org/wiki/api.php" to "wiki.octave.org/api.php" and use your
work.


Sahil wrote
>> Another thing I did not mention is, that we need to handle JSON-data.
>> Currently Octave does not support `json(en/de)code` [1] and (bug #53100),
>> but we can make use of jsonlab in the meantime [2], which is pure m-code,
>> thus easily replaceable but not high-performance.
>
> Should I add this to timeline to implement jsonencode and jsondecode
> because
> these look like a higher priority than the RESTful MATLAB compatible
> interface functions?

No, I don't think that jsonencode and jsondecode should be part of your GSoC
project.  Do not underestimate the effort to get the webread/write/options
done properly!  When we introduce these functions, they should not only work
for our toy JSON data (a few kilobyte) but also for larger data sets.  There
are existing libraries for doing this, but no one so far evaluated their
performance, and included the best one into Octave core using a Matlab
compatible interface.


Sahil wrote
> And kindly mark the comments on Google doc as 'resolved' if you think the
> query is resolved.
>
> [1] https://www.mathworks.com/help/matlab/ref/jsondecode.html
> [2] https://github.com/fangq/jsonlab
> [3]
> https://siko1056.github.io/blog/2017/03/10/getting-to-know-the-mediawiki-api.html#prerequisites-and-preparation

Done.

Kai



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Sahil
Hi Kai

Thanks for the detailed review of timeline and answers to my queries. I've
changed the output format of 'webread' function to text, do you think I
should be adding some more details and technicalities to it (the complete
timeline)?

Sahil



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

siko1056
Sahil wrote
> Hi Kai
>
> Thanks for the detailed review of timeline and answers to my queries. I've
> changed the output format of 'webread' function to text, do you think I
> should be adding some more details and technicalities to it (the complete
> timeline)?
>
> Sahil

To me your timeline looks pretty good.  All the implementation details have
to go into the function documentation later.

Kai.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Sahil
Hello All

I've been selected as one of the GSoC student this year for the project
Octave Code Sharing. Thanks a lot to all the members of Octave community.
Special thanks to Kai T Ohulus, Doug Stewart, Ankit Raj and Nir Krakauer for
believing in me even when there were a bit of conflicts about the project
choices. I will try my best to keep up with your expectations not only
during the GSoC period but also after it.

May I get to know about how should we be proceeding now onwards, i.e, the
frequency and time of meetings, availability on IRC channel, any other thing
which should be care taken of, etc.

Again, thanks a lot for giving me the opportunity.

Warm Regards
Sahil




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Ankit
Good Luck Sahil

On Tue 24 Apr, 2018, 8:43 PM Sahil, <[hidden email]> wrote:
Hello All

I've been selected as one of the GSoC student this year for the project
Octave Code Sharing. Thanks a lot to all the members of Octave community.
Special thanks to Kai T Ohulus, Doug Stewart, Ankit Raj and Nir Krakauer for
believing in me even when there were a bit of conflicts about the project
choices. I will try my best to keep up with your expectations not only
during the GSoC period but also after it.

May I get to know about how should we be proceeding now onwards, i.e, the
frequency and time of meetings, availability on IRC channel, any other thing
which should be care taken of, etc.

Again, thanks a lot for giving me the opportunity.

Warm Regards
Sahil




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

siko1056
Ankit wrote
> On Tue 24 Apr, 2018, 8:43 PM Sahil, &lt;

> yadavsahil5198@

> &gt; wrote:
>
>> Hello All
>>
>> I've been selected as one of the GSoC student this year for the project
>> Octave Code Sharing. Thanks a lot to all the members of Octave community.
>> Special thanks to Kai T Ohulus, Doug Stewart, Ankit Raj and Nir Krakauer
>> for
>> believing in me even when there were a bit of conflicts about the project
>> choices. I will try my best to keep up with your expectations not only
>> during the GSoC period but also after it.
>>
>> May I get to know about how should we be proceeding now onwards, i.e, the
>> frequency and time of meetings, availability on IRC channel, any other
>> thing
>> which should be care taken of, etc.
>>
>> Again, thanks a lot for giving me the opportunity.
>>
>> Warm Regards
>> Sahil
>>
>>
>>
>>
>> --
>> Sent from:
>> http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html
>>
>>
>
> Good Luck Sahil

From me as well Sahil!

To start I suggest you establish some kind of blog (at wordpress, blogger,
github pages, ...), see for example [1], and we send Jordi the link to
syndicate on our aggregator http://planet.octave.org/ .  In this blog you
should give at least once a week a short report about your progress to the
Octave community.  As initial post you might present your preliminary
timeline [2].

A second step would be to create some kind of public repository(ies), where
you regularly push your (~daily) code changes.  You can also mention this
location in your blog.  This makes it easier for other maintainers and me to
follow your progress and enables us to help if required.  I would recommend
Bitbucket (and SourceForge) as they support Mercurial.  When becoming an
Octave maintainer you should get used to Mercurial (but as you wrote on your
wiki user page, you are familiar with it anyway).

Regarding the communication: I try to be more online in IRC <siko1056>.  But
the best way to reach me, is by mail(ing list).  If you need help on a
particular topic, we can arrange a meeting in IRC.  We'll see in the first
weeks, how you get along with the task and if more communication (channels)
is required.

Wish you a great summer of code,

Kai


[1] https://gsocinterval.blogspot.de//edit
[2]
https://docs.google.com/document/d/1InJhgZQkW61a42qPwiIWjYz7xPo4Gk9fKhsdrd3G_7M



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Sahil
siko1056 wrote
> To start I suggest you establish some kind of blog (at wordpress, blogger,
> github pages, ...), see for example [1], and we send Jordi the link to
> syndicate on our aggregator http://planet.octave.org/ .  In this blog you
> should give at least once a week a short report about your progress to the
> Octave community.  As initial post you might present your preliminary
> timeline [2].

My blog can be viewed at [3]. This will not change even after GSoC. RSS feed
link is there in [3] but can alternatively be viewed here [4]. I've updated
Week 1 with the abstract and timeline.


siko1056 wrote

> A second step would be to create some kind of public repository(ies),
> where
> you regularly push your (~daily) code changes.  You can also mention this
> location in your blog.  This makes it easier for other maintainers and me
> to
> follow your progress and enables us to help if required.  I would
> recommend
> Bitbucket (and SourceForge) as they support Mercurial.  When becoming an
> Octave maintainer you should get used to Mercurial (but as you wrote on
> your
> wiki user page, you are familiar with it anyway).

The bitbucket repository is at [5]. I've also sent you an invitation for the
same.
The repository has a branch named 'ocs' for the project as all the commits
show up in draft phase of mercurial and I would not want to mess up with the
default branch anyhow. Needless to say,
ocs = https://me_ydv_5@.../me_ydv_5/octave 
could be added in .hgrc to facilitate one's pulling/pushing.


siko1056 wrote
> Regarding the communication: I try to be more online in IRC
> <siko1056>
> .  But
> the best way to reach me, is by mail(ing list).  If you need help on a
> particular topic, we can arrange a meeting in IRC.  We'll see in the first
> weeks, how you get along with the task and if more communication
> (channels)
> is required.

I'm fine with mailing lists. May be I can just accumulate a few doubts and
then we can talk about them either here on list or on the IRC channel. I'm
always available on IRC. So you can just drop any message if you feel
something to be conveyed and I'll read the same when I run open my IRC
client.


siko1056 wrote
> Wish you a great summer of code,
>
> Kai

Thanks :-)

Regards
Sahil


[3] https://me-ydv-5.github.io/gsoc2018
[4] https://me-ydv-5.github.io/feed.xml
[5] https://bitbucket.org/me_ydv_5/octave



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

siko1056
Sahil wrote
> siko1056 wrote
>> [...] we send Jordi the link to syndicate on our aggregator
>> http://planet.octave.org/ [...]

I managed to add your blog to the aggregator http://planet.octave.org/
myself, as I obtained the necessary permissions by jwe recently.

If the other GSoC blogs go online, I can save Jordi some work, and can add
them to the planet.octave as well.


Sahil wrote
> [...] The bitbucket repository is at [5]. I've also sent you an invitation
> for the same. [...]
>
> [3] https://me-ydv-5.github.io/gsoc2018
> [4] https://me-ydv-5.github.io/feed.xml
> [5] https://bitbucket.org/me_ydv_5/octave

Thankfully received your repo invitation.

Best,
Kai



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Sudeepam Pandey


On Thu, Apr 26, 2018 at 11:17 AM, siko1056 <[hidden email]> wrote:
Sahil wrote
> siko1056 wrote
>> [...] we send Jordi the link to syndicate on our aggregator
>> http://planet.octave.org/ [...]

I managed to add your blog to the aggregator http://planet.octave.org/
myself, as I obtained the necessary permissions by jwe recently.
 
Hello Kai, I am also a GSoC student for this year. Can you please add my blog [6] to the aggregator as well?


If the other GSoC blogs go online, I can save Jordi some work, and can add
them to the planet.octave as well.


Sahil wrote
> [...] The bitbucket repository is at [5]. I've also sent you an invitation
> for the same. [...]
>
> [3] https://me-ydv-5.github.io/gsoc2018
> [4] https://me-ydv-5.github.io/feed.xml
> [5] https://bitbucket.org/me_ydv_5/octave

Thankfully received your repo invitation.

Best,
Kai

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

siko1056
Sudeepam Pandey wrote
> Hello Kai, I am also a GSoC student for this year. Can you please add my
> blog [6] to the aggregator as well?
>
> [6]: https://sudeepam.blogspot.in/

Sure and done,

Kai.



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Sudeepam Pandey

On Fri, Apr 27, 2018 at 3:06 AM, siko1056 <[hidden email]> wrote:
Sudeepam Pandey wrote
> Hello Kai, I am also a GSoC student for this year. Can you please add my
> blog [6] to the aggregator as well?
>
> [6]: https://sudeepam.blogspot.in/

Sure and done,

Thank you Kai.

Kai.

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Sahil
In reply to this post by siko1056
Hi Kai

I've read the various files that are of a concern to the project. I have a
few questions/thoughts regarding the same:

1. We'll need to refactor the __publish_wiki_output__.m file. Is there any
guidelines or should I  try to implement it analogous to what is written in
__publish_html_output__.m, i.e, the various functions that are defined in
the latter file? Also, the MediaWiki of wiki.octave.org is not able to
render LaTex text properly (I had already changed the 'do_inlinemath' and
'do_blockmath' in the former file according to wikimedia guidelines)and
gives the following error [1] whereas the same text appears without any
problems when I try it on mediawiki.org. And the place for
__publish_wiki_output__.m should be /scripts/miscellaneous/private, right?
Also please tell if I am missing something in this part, like if there's a
need to recheck the parser, etc.

2. Do we need to identify our client [2] when interacting with the webserver
(I believe yes) and if yes, what would be the client name?

3. $wgEnableAPI has been removed in MediaWiki version 1.32.0 [3]. Is this a
problem, because I'm unaware of our webserver's version of MediaWiki.

4. I'll be continuing with your implementation of libcurl_wrapper.cc and
adding the option CURLOPT_COOKIEFILE, CURLOPT_COOKIEJAR for storing cookies
for a session and the "ALL" command here [4] for deleting them. I'm assuming
wikiLogin.sh [5] is complete in itself to get an idea of the components that
need to be there in our wrapper. Also, will it be a problem if I put the
file in libinterp/corefcn, DEFUN macros are compiled faster than DEFUN_DLD I
believe? I'll let you know more on this once I actually try to implement it.

5. Just for my knowledge, why aren't we using 'curl_multi' interface? We can
have non-blocking transfer with it.

Any other advice is always welcomed.
I'll first start refactoring __publish_wiki_output__.m and then come to
wrapper in the next days.

Thanks  & Regards
Sahil

[1]
https://www.mediawiki.org/w/index.php?title=Manual:Troubleshooting_math_display_errors#.22Failed_to_parse_.28PNG_conversion_failed.3B_check_for_correct_installation_of_latex.2C_dvips.2C_gs.2C_and_convert.29.22

[2] https://www.mediawiki.org/wiki/API:Main_page#Identifying_your_client

[3] https://www.mediawiki.org/wiki/Manual:$wgEnableAPI

[4] https://ec.haxx.se/libcurl-http-cookies.html#cookie-store-commands

[5] https://github.com/octave-de/OctConf2017/blob/master/demo2/wikiLogin.sh



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

siko1056
Sahil wrote

> Hi Kai
>
> I've read the various files that are of a concern to the project. I have a
> few questions/thoughts regarding the same:
>
> 1. We'll need to refactor the __publish_wiki_output__.m file. Is there any
> guidelines or should I  try to implement it analogous to what is written
> in
> __publish_html_output__.m, i.e, the various functions that are defined in
> the latter file? Also, the MediaWiki of wiki.octave.org is not able to
> render LaTex text properly (I had already changed the 'do_inlinemath' and
> 'do_blockmath' in the former file according to wikimedia guidelines)and
> gives the following error [1] whereas the same text appears without any
> problems when I try it on mediawiki.org. And the place for
> __publish_wiki_output__.m should be /scripts/miscellaneous/private, right?
> Also please tell if I am missing something in this part, like if there's a
> need to recheck the parser, etc.

I am responsible for the LaTeX rendering error and work out a solution
during this week.  The problem is, I upgraded the wiki installation and ever
since texvc is reluctant to do it's work [6].  But for now accept the wiki
output and we will do an integration test later on a test system (week 3-4
or so?).

The location /scripts/miscellaneous/private/__publish_wiki_output__.m is
good.  If you want to touch the parser (e.g. publish.m, a maybe toooooo
loooooong file ;-) ) go ahead and if your changes proof to be beneficial, we
can merge your improvements.


Sahil wrote
> 2. Do we need to identify our client [2] when interacting with the
> webserver
> (I believe yes) and if yes, what would be the client name?

Maybe this is new.  Last year I did not hit this item.  Good point for
investigation from your side and content for the blog.


Sahil wrote
> 3. $wgEnableAPI has been removed in MediaWiki version 1.32.0 [3]. Is this
> a
> problem, because I'm unaware of our webserver's version of MediaWiki.

This is good news, for the upcoming releases: If you read the full story [7]
the api.php is now a builtin feature and no longer an opt-in feature of EACH
Mediawiki =) *hooray*

We are on 1.30.0 currently [8]


Sahil wrote

> 4. I'll be continuing with your implementation of libcurl_wrapper.cc and
> adding the option CURLOPT_COOKIEFILE, CURLOPT_COOKIEJAR for storing
> cookies
> for a session and the "ALL" command here [4] for deleting them. I'm
> assuming
> wikiLogin.sh [5] is complete in itself to get an idea of the components
> that
> need to be there in our wrapper. Also, will it be a problem if I put the
> file in libinterp/corefcn, DEFUN macros are compiled faster than DEFUN_DLD
> I
> believe? I'll let you know more on this once I actually try to implement
> it.

This is a bit more delicate.   For the development, I think it is fine to
just use one path location in Octave's c++ tree (for example
libinterp/corefcn).  The story about DEFUN and DEFUN_DLD is that the latter
are dynamically loaded functions (.oct files) and the first ones are builtin
functions that are loaded when Octave starts.  When compiling DEFUN
functions, libinterp.so has to be linked again, whereas DEFUN_DLD just link
against all Octave libraries.  Try out both versions, but build time issues
should be neglectable, depending on your hardware.


Sahil wrote
> 5. Just for my knowledge, why aren't we using 'curl_multi' interface? We
> can
> have non-blocking transfer with it.

By just transferring some text (and maybe some images later) as a start, we
would not hit a performance barrier and can stick to the easy-interface.


Sahil wrote
[6]
https://www.mediawiki.org/wiki/Manual:Troubleshooting_math_display_errors#%22Failed_to_parse_(PNG_conversion_failed;_check_for_correct_installation_of_latex,_dvips,_gs,_and_convert)%22

[7] https://phabricator.wikimedia.org/T115414

[8] https://wiki.octave.org/Special:Version



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

Sahil
Hi Kai

Can you please spare sometime tomorrow (Tuesday) after 1530 hours UTC +0 or
on Wednesday (whatever suits you) to discuss my progress and further
guidance? I'll write this week's post by tomorrow morning or noon. Let me
know whenever you'll be comfortable.

Thanks
Sahil



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: GSoC - Octave code sharing

siko1056
Greetings Sahil,

The trial&error wiki is online:

    https://wiki.octave.space
    https://wiki.octave.space/api.php

Later you just have to switch "space" to "org" and you're done.  Maybe you
can try to create some account there?

Best,
Kai



--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

12