I packaged up my code for solving eigenvalue BVPs, and put it on GitHub with a paclet installer. Any feedback on anything that I should do differently would be appreciated, this is my first time both making a package and using GitHub. Package is at: github.com/KraZug/CompoundMatrixMethod
Computation is no longer the preserve of science and engineering, so I thought I would share a simple computational literary analysis that I did with my daughter. Hannah’s favorite book is Lord of the Flies by William Golding, and as part of a project she was doing, she wanted to find some quantitative information to [...]
The "Download the latest release" link in your readme is broken.
The paclet file should be hosted on GitHub's releases page, not in the repo itself. Create a tag for the repo (e.g. v0.1), then go to the releases page, click draft release, select the tag, upload the corresponding paclet.
If you want v9-compatibility, then the PacletInfo.m file should use MathematicaVersion, not WolframVersion.
The source code is not indented/formatted, therefore it is very hard to read, and it is easy to miss errors in it. There are immediately noticeable minor errors, such as e.g. lena, lenb not being localized in the Module.
I strongly suggest using halirutan's IDEA plugin: wlplugin.halirutan.de It'll make it easier to write code, easier to format code, and easier to spot many basic mistakes such as not localizing variables, forgetting a semicolon/comma, etc.
Instead of Print, it's nicer to use Message. This way warnings can be individually disabled.
Abort is ugly: it stops the kernel completely. It doesn't give your package's users the option to catch and handle errors automatically. Please don't do this. There are several techniques for handling errors. I suggest reading this:
In particular, what are the best ways to report errors about incorrect arguments to a function? Checking for the correct arguments is relatively easy using patterns, but how to report an informative error message specific to the situation is not obvious.
Most built-in functions will return unev...
And I suggest simply returning $Failed in case of an error (along with issuing a Message) because this is the easiest to implement.
Don't use $Aborted for this, use $Failed, or if you like, use Failure. That was introduced in v10.0, so it's not an option if you need 9.0-compatibility.
Easy way: Return[$Failed]. More complicated, but more flexible way: Catch[...; Throw[$Failed, myTag]; ..., myTag]. The advantage of Throw/Catch: it works even if you throw from one function and catch from another (Return doesn't).
@Szabolcs I'm not convinced on this one. Putting it in the repo makes it easier to install than if it's in the releases. One requires just using the raw.... url in PacletInstall while the other requires the GitHub API (unless I'm much mistaken). Unless you makes the user download and then install, but that feels like an unnecessary step.
The issue, of course, is for forking. One interesting thing @CarlWoll did was to pack a paclet server into a repo: github.com/carlwoll/TensorSimplify
I'm happy to use PacletManager, I just wondered if there was any point trying to say that my code works for v6 (say) if the Paclet installer didn't exist.
@KraZug They started in 6, but AFAIK big changes were made after v8. Personally I have only tested with v9+.
@KraZug The best way is to test in the earliest version you want to target. The next best way is to use the IDEA plugin I referenced. You can set a minimum version and it'll highlight functions that aren't available in it. It won't tell you about changes to these functions' syntaxes though.
I'm not quite certain if you need to have that minimum version installed to be able to do this, though.
Also, about MathematicaVersion vs WolframVersion in PacletInfo: while "MathematicaVersion" is deprecated, it at least has the advantage that v9 will recognize it and will refuse to install a paclet that's compatible only with v10+. This is why I use it even for v10+ compatible packages.
configurable code indenting (and automatic code formatting), better syntax highlighting, better auto-completion, refactoring (e.g. rename a Module variable without changing symbols with the same name outside the module), some warnings about common mistakes
@KraZug You do not need to use the IDE. You can just use the Mathematica front end if you wish. There are tradeoffs, and we need to decide what features are important and what we're willing to give up.
Actually it is possible to use Greek letters with an IDE. I have a Greek keyboard set up and can type αβγ with minimal fuss. In principle I could use these in a Mathematica package.
The problem is that then a specific encoding needs to be selected for the .m file. Most editors use UTF8. Mathematica interprets the file as UTF8 on OS X and probably on Linux. But not on Windows!
So the package may not properly load on Windows, depending on $CharacterEncoding
I do use non-ASCII characters in strings and comments only in my packages, and to deal with this issue I post-process the .m files before building a paclet, like this:
How can I re-encode a text file (or string) so that non-ASCII characters will be represented using Mathematica's standard names?
For example, if the original contents of the file was
xαy
then the re-encoded file should contain
x\[Alpha]y
Using the CharacterEncoding "Mathematica7" comes ...
Yes, of course I know what you mean. I do not think it is a good idea to put the release in the repo, but sometimes hacks like this are convenient or even necessary. I would still use separate GitHub repos for a paclet server, and for development.
@b3m2a1 The paclet server thing is another one of Wolfram's infamous "we need to re-invent the wheel" feature. Completely blind to what's going on in the rest of the tech-world.
@b3m2a1 The problem is not that it exists, the problem is that there is zero support for existing open source solutions. If you look how other languages distribute their packages (again, look at Julia) then you see that the support for GitHub works out of the box.
However, the amount of package developers is very very small compared to Mathematica users.
The problem is that many Mathematica users will stumble even on something as basic as downloading a paclet file and typing in the correct path for PacletInstall. Being able to give them a single line of code to install a package is valuable.
I tried to suggest to Wolfram to at least help the community standardize on a solution if they won't make their own, but they don't seem terribly interested.
@b3m2a1 11.2 came with lots of fixes for it, thanks to Kuba sending detailed problem reports
There were rumours that Wolfram wants to set up an "app marketplace". I don't know the details. I haven't been to any WTCs and I assume that those people who have had to sign NDAs.
@b3m2a1 Actually that's not good enough for me. I want something that works all the way back to v10.0. I'd much rather see some sort of openly implementable standard.
@Szabolcs I've heard those rumors too. I assumed with their data-repository and neural-net-repository and stuff a a package-repository was in the works.
@Szabolcs My personal feeling is that WRI will exploit everything that is currently done to make money. I expect that more things like an App-Store-like stuff appears.
That's also why I think that a proper package manager is so urgent. It'll take several years before packages that support older versions will start using it
Several people worked in this direction, first Leonid, much later Kuba and you. No solutions really caught on. WRI needs to show public support. How about patching up an existing project like @Kuba's MPM, hosting it under their own account and accepting pull requests form the community?
@Szabolcs yeah that's definitely something that WRI would need to get in-on too. I think a centralized system would be important too... like python's pip or Atom's apm.
They do give prizes to people for industry who are said to have developed amazing packages, but the packages never even get publicly released.
Actually this goes back many years. It's so typical to find presentations about interesting sounding packages on the Wolfram Library Archive, but there is often no trace of the package files.
@Szabolcs @b3m2a1 yeah, I feel sorry for abandoning MPM but I have less time now and I wasn't motivated by minimal usability as everything gets complicated if you need to inject several multifile packages into a cdf because your client is not able to Shift+Enter one line. To get MPM to that stage is beyond my imagination so I do custom packing anyway.
Does anyone know what precisely is causing Hyperlinks to turn black (instead of blue) when printing? Is it simply that this is the style they have in the Printout environment, or is there something more to it? Adding a new style for them for the Printout environment does work.
