21
edits
(Strip "Octave code sharing" project. Was part of GSoC 2018.) |
AndrewJanke (talk | contribs) m (Fix configure invocation) |
||
(6 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 137: | 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 165: | 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 181: | 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 199: | Line 181: | ||
: Difficult. | : Difficult. | ||
* '''Potential mentors''' | * '''Potential mentors''' | ||
: | : ? | ||
=== Improve iterative methods for sparse linear systems === | === Improve iterative methods for sparse linear systems === | ||
Line 360: | 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 373: | 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. | |||
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. | 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. 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 {{ | 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 {{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 488: | 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