Originally Posted by: mkraska That's worth being implemented in a plugin.
Hi Martin. I prefer the 'library style' instead the 'plugin style' for developing apps for SMath. Reasons have a lot. For instance, is the maple and matlab's historical grow path. Also I can point following benefits:
- improving SMath itself, discovering better ways for doing internals, or for requesting features.
- increase of bugs discovering
- source code in high level language (SMath lang), so, more easy for debugging
- more users can collab developing or improving the libraries
The biggest disadvantage: speed. But maybe this can help Andrey to find more robust algorithms.
As an application of these comments, I have this suggestions
- Add "nabla x" and "nabla dot" like grad and lapl to custom gliphs
- Same thing, but for several variables and vectorial integrals (path, flux, etc.)
- Improve at function for handling v=P where v and P are vectors (see green comments in the attached)
- Make custom gliphs and include plugins internal
- If include can't find in the sm file in the same folder than the current file, nor the specify path, search it in some "library folder" under apps default path.
- The set of 'libraries' could be a plugin itself, and have some kind of actualization, like the others plugins, examples or handbooks.
- In the attached, the 'library' style for the differentials applications, and help for get a large collection of coordinates systems, if in case that same one want to write the 'library'
coords v2.sm (111kb) downloaded 58 time(s).Best regards.
Alvaro.
Edited by user 26 November 2018 08:35:38(UTC)
| Reason: Not specified