21
edits
No edit summary |
AndrewJanke (talk | contribs) m (Fix configure invocation) |
||
(7 intermediate revisions by 4 users not shown) | |||
Line 38: | Line 38: | ||
*: [http://en.wikipedia.org/wiki/GNU_build_system The GNU build system] is used to build Octave. | *: [http://en.wikipedia.org/wiki/GNU_build_system The GNU build system] is used to build Octave. | ||
*: While you generally don't need to understand too much unless you actually want to change how Octave is built, you should be able to understand enough to get a general idea of how to build Octave. | *: While you generally don't need to understand too much unless you actually want to change how Octave is built, you should be able to understand enough to get a general idea of how to build Octave. | ||
*: If you've ever done a {{Codeline|configure && make && make install}} series of commands, you have already used the GNU build system. | *: If you've ever done a {{Codeline|./configure && make && make install}} series of commands, you have already used the GNU build system. | ||
*: '''You must demonstrate that you are able to build the development version of Octave from sources before the application deadline.''' Linux is arguably the easiest system to work on. Instructions: | *: '''You must demonstrate that you are able to build the development version of Octave from sources before the application deadline.''' Linux is arguably the easiest system to work on. Instructions: | ||
*:* [[Building]] | *:* [[Building]] | ||
Line 98: | Line 98: | ||
|- | |- | ||
! <br />!! !! !! !! !! !! | ! <br />!! !! !! !! !! !! | ||
|- | |- | ||
| [[Summer_of_Code_Project_Ideas#ode15s_:_Matlab_Compatible_DAE_solver | ode15{i,s} : Matlab Compatible DAE solvers]] || Carlo de Falco || Francesco Faccio, Marco Caliari, Jacopo Corno, Sebastian Schöps || Numerical || No || Medium || GSoC 2016 | | [[Summer_of_Code_Project_Ideas#ode15s_:_Matlab_Compatible_DAE_solver | ode15{i,s} : Matlab Compatible DAE solvers]] || Carlo de Falco || Francesco Faccio, Marco Caliari, Jacopo Corno, Sebastian Schöps || Numerical || No || Medium || GSoC 2016 | ||
|- | |- | ||
| [[Summer_of_Code_Project_Ideas#Improve_logm.2C_sqrtm.2C_funm | Improve logm, sqrtm, funm]] || | | [[Summer_of_Code_Project_Ideas#Improve_logm.2C_sqrtm.2C_funm | Improve logm, sqrtm, funm]] || ? || Marco Caliari, Mudit Sharma || Numerical || [https://github.com/RickOne16/matrix No] || Hard || Independent devs 2016 | ||
|- | |- | ||
| [[Summer_of_Code_Project_Ideas#Improve_iterative_methods_for_sparse_linear_systems | Improve iterative methods for sparse linear systems]] || Marco Caliari || Carlo de Falco || Numerical || No || Hard || SOCIS 2016 | | [[Summer_of_Code_Project_Ideas#Improve_iterative_methods_for_sparse_linear_systems | Improve iterative methods for sparse linear systems]] || Marco Caliari || Carlo de Falco || Numerical || No || Hard || SOCIS 2016 | ||
Line 126: | Line 124: | ||
|- | |- | ||
| [[Summer_of_Code_Project_Ideas#Chebfun_in_Octave | Chebfun in Octave]] || Colin B. Macdonald || [[User:KaKiLa|KaKiLa]], Ankit Raj, needs core-Octave mentor/comentor || Infrastructure, Numerical || Yes || Hard || Never | | [[Summer_of_Code_Project_Ideas#Chebfun_in_Octave | Chebfun in Octave]] || Colin B. Macdonald || [[User:KaKiLa|KaKiLa]], Ankit Raj, needs core-Octave mentor/comentor || Infrastructure, Numerical || Yes || Hard || Never | ||
|- | |- | ||
| [[Summer_of_Code_Project_Ideas#GUI Variable Editor and Property Inspector | GUI Property Inspector]] || ? || || GUI || Yes || Medium || Never | | [[Summer_of_Code_Project_Ideas#GUI Variable Editor and Property Inspector | GUI Property Inspector]] || ? || || GUI || Yes || Medium || Never | ||
Line 139: | Line 135: | ||
These projects involve implementing certain mathematical functions, primarily in core Octave. | These projects involve implementing certain mathematical functions, primarily in core Octave. | ||
=== ode15{i,s} : Matlab Compatible DAE solvers === | === ode15{i,s} : Matlab Compatible DAE solvers === | ||
Line 167: | Line 148: | ||
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15i.m ode15i.m] and | [http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15i.m ode15i.m] and | ||
[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15s.m ode15s.m]. | [http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15s.m ode15s.m]. | ||
The list of | The list of outstanding tracker tickets concerning this implementation can be found | ||
[https://savannah.gnu.org/search/?Search=Search&words=ode15&type_of_search=bugs&only_group_id=1925&exact=1&max_rows=25#options here] | [https://savannah.gnu.org/search/?Search=Search&words=ode15&type_of_search=bugs&only_group_id=1925&exact=1&max_rows=25#options here] | ||
Line 183: | Line 164: | ||
to a possible project plan would be improving documentation and tests in odepkg and removing | to a possible project plan would be improving documentation and tests in odepkg and removing | ||
overlaps with the documentation in core Octave. | overlaps with the documentation in core Octave. | ||
* '''Required skills''' | * '''Required skills''' | ||
Line 201: | Line 181: | ||
: Difficult. | : Difficult. | ||
* '''Potential mentors''' | * '''Potential mentors''' | ||
: | : ? | ||
=== Improve iterative methods for sparse linear systems === | === Improve iterative methods for sparse linear systems === | ||
Line 362: | Line 342: | ||
=== Octave Package management === | === Octave Package management === | ||
Octave | [[Packages]] are extensions for Octave, that are mainly maintained by the [[Octave Forge]] community. | ||
To get those extension to work with Octave, there is a single function, {{manual|pkg}}, which does pretty much everything. | |||
This function has a few limitations which are hard to implement with the current codebase, and will most likely require a full rewrite. | |||
A major step forward for a rewritten package manager is the [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project] by Andrew Janke. | |||
The planned improvements are: | The planned improvements (see also {{bug|39479}}) are: | ||
* install and update from repositories (hg and git) | * install and update from repositories (hg and git) | ||
* automatic handling of dependencies | * automatic handling of dependencies | ||
Line 375: | Line 357: | ||
* support for multiple Octave installs | * support for multiple Octave installs | ||
* support for system-wide and user installed packages | * support for system-wide and user installed packages | ||
* testing packages (<code>pkg test <package-name></code>) | |||
* improved metadata acquisition (<code>pkg list -forge</code>) from https://octave.sourceforge.io/ | |||
The main objective of this project is to make {{ | The main objective of this project is to make {{manual|pkg}} more user friendly and to make it a tool to foster third party participation in Octave. | ||
However, the current {{manual|pkg}} also performs some maintenance functions which it probably should not. | |||
Instead a package for developers should be created with such tools. | Instead a package for developers should be created with such tools. | ||
To do this enhancement effectively, a refactoring of the current {{codeline|pkg}} code will be needed (see [https://github.com/apjanke/octave-packajoozle/ "packajoozle" project]). | |||
Many of these problems have been solved in other languages. | |||
[ | Familiarity with how other languages handle this problem will be useful to come up with elegant solutions. | ||
In some cases, there are standards to follow. | |||
For example, there are specifications published by freedesktop.org about where files should go ([http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html base directory spec]) and Windows seems to have its own standards. | |||
See bugs {{bug|36477}} and {{bug|40444}} for more details. | |||
In addition, package names may start to collide very easily. | |||
One horrible way to workaround this by is choosing increasingly complex package names that give no hint on the package purpose. | |||
In addition, package names may start to collide very easily. One horrible way to workaround this by is choosing increasingly complex package names that give no hint on the package purpose. A much better is option is providing an Authority category like Perl 6 does. Nested packages is also an easy way to provide packages for specialized subjects (think {{codeline|image::morphology}}). A new {{ | A much better is option is providing an Authority category like Perl 6 does. | ||
Nested packages is also an easy way to provide packages for specialized subjects (think {{codeline|image::morphology}}). | |||
A new {{manual|pkg}} would think all this things now, or allow their implementation at a later time. | |||
Read the [[OEP:pkg|unfinished plan]] for more details. | |||
* '''Minimum requirements''' | * '''Minimum requirements''' | ||
: Ability to read and write Octave code, experience with Octave packages, and understanding of the basics of autotools. The most important skill is software design. | : Ability to read and write Octave code, experience with Octave packages, and understanding of the basics of autotools. The most important skill is software design. | ||
* '''Difficulty''' | * '''Difficulty''' | ||
: | : Medium. | ||
* '''Mentor''' | * '''Mentor''' | ||
: [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco, Sebastian Schöps | : [[User:KaKiLa|KaKiLa]], Carnë Draug, Carlo de Falco, Sebastian Schöps | ||
=== SPQR Interface === | === SPQR Interface === | ||
Line 502: | Line 458: | ||
=== PolarAxes and Plotting Improvements === | === PolarAxes and Plotting Improvements === | ||
Octave currently provides supports for polar axes by using a Cartesian 2-D axes and adding a significant number of properties and callback listerners to get things to work. What is needed is a first class implementation of a "polaraxes" object in C++. This will require creating a new fundamental graphics object type, and programming in C++/OpenGL to render the object. When "polaraxes" exist as an object type then m-files will be written to access them including polaraxes.m, polarplot.m, rticks.m, rticklabels.m, thetaticks, thetaticklabels.m, rlim.m, thetalim.m | Octave currently provides supports for polar axes by using a Cartesian 2-D axes and adding a significant number of properties and callback listerners to get things to work. What is needed is a first class implementation of a "polaraxes" object in C++. This will require creating a new fundamental graphics object type, and programming in C++/OpenGL to render the object. When "polaraxes" exist as an object type then m-files will be written to access them including polaraxes.m, polarplot.m, rticks.m, rticklabels.m, thetaticks, thetaticklabels.m, rlim.m, thetalim.m. relates to {{bug|35565}}, {{bug|49804}}, {{bug|52643}}. | ||
* '''Minimum requirements''' | * '''Minimum requirements''' |
edits