octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC - Octave code sharing


From: siko1056
Subject: Re: GSoC - Octave code sharing
Date: Fri, 20 Apr 2018 00:49:50 -0700 (MST)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]