Mathematics Tool Kit

Scratch that about Windows. The download link is a VM with Sage pre-installed. OK, back to the plan to support Mac and Linux and investigate putting together a Linux re-spin so Windows users can run MTK in a VM.

I checked around a little bit and it still looks like Kile is the best bet. http://kile.sourceforge.net/

Resources on creating your own Ubuntu respin.

• http://www.linux.com/learn/tutorials/739139-roll-your-own-customized-ubuntu-with-uck
• http://sneekygeekers.com/2014/06/09/how-to-create-your-own-ubuntu-respin/

The amount of stuff you have to install is a drawback to using kile, since it depends on so much of the KDE underpinnings. Got this message when installing kile from the repository.

After this operation, 735 MB of additional disk space will be used.

I've got the steps that we worked on in the Hangout last night in a script. I'd like for Linux users to be able to use wget to download the file from the terminal, which is pretty standard for setup shell scripts like this. However, the file needs to be tracked in version control too. I would suggest that we put the finalized version of the script on DMSF for wget access, and maybe put the script under trunk/scripts or something similar in subversion.

Thoughts?

That's great news, Jeremy. Yeah, I think we can set up something along those lines. I will lay in an SVN folder structure this weekend and turn on DMSF. I'll let you know when I get that taken care of.

Jeremy,

I set up svn. Under trunk there is now an empty examples directory (I will start working on an initial example or two this week) and an install directory. Under the install directory there is a linux directory (https://opendesignengine.net/svn/mtk/trunk/install/linux). This is where I suggest we put the source for the scripts. I also added DMSF and added a Releases folder (for released installers and scripts) and an Examples directory (for example PDFs so visitors can see what the tool can generate and have an easy way to get a file to compare with the examples as generated from their own copies of MTK).

-J

I've committed what we have in the script so far to the linux/install folder. Once we've completed the setup process I'll run the script on a clean Ubuntu 14.04 VM, tweak it as needed, then drop it on DMSF/Documents/Releases. Do we need a linux folder under Releases as well?

Good point. All taken care of. Thanks for getting the current script committed.

Two new tests available under examples (with typeset versions posted to dmsf). The first exercises minted and demonstrates how to incorporate custom Python source files in MTK documents. The second is the very first demonstration of using units in MTK by way of Pint. I am very happy to report that it works. I was able to assign two variables units of length (meters specifically), multiply them together, and the result was in square meters!

The are still several things to smooth out, though, where units are concerned. The display in LaTeX is very awkward right now. I tried for about an hour to use Pint's built in formatting and ended up with mixed success. If you take a look at the PDF you will see the magnitude of the values are unformatted (that is the default number of decimals) and the units are directly attached to the magnitude. I also could not get the units abbreviation formatting to work. The good news is the LaTeX formatting mode in Pint properly formatted the m^2 when I made a small adjustment to the formatting string.

I think the root of the problems is some sort of odd interaction between Pint, Sage, and LaTeX when we go to pull the results out of Sage and into LaTeX. But I think we can fix these issues with some custom formatting work. And I think we can build in that custom formatting into a helper package that we can include (and instantiate) in a real MTK LaTeX template (a .cls file). I'm seeing an MTK package that does the following:

• imports Pint
• instantiates a document wide units registry and assigns it to MTK.units so users can access units just by calling MTK.units.<name of unit>
• sets the unit registry to format to abbreviated units names by default
• provides a set of methods for displaying formatted results and units, all of the below would return strings and would be called in MTK inside a \sagestr{} command
  • displayValue(x, stringFormat) - constructs a string of value's magnitude and units with string format applied to the magnitude (for easy rounding) and adding a space between units and magnitude (note, units would be disabled in LaTeX format with appropriate modifiers, $<units>$, applied)
  • displayMagnitude(x, stringFormat) - like above but without displaying units (for use in tables where units are displayed in first row or column)
  • displayUnits(x) - like above but only displaying the units

I'm sure some more features will come to mind as we move forward. Once we have a real LaTeX template, we can also look at formatting and inclusion of LaTeX packages in more detail (like advanced math formatting, auto-including the Minted package, line spacing, fonts, how sections are labeled, etc). Lots of fun stuff. We will also probably want to create a test case that is all about pulling in lots of units for display to ensue things format correctly.

I ran the setup script on a clean Lubuntu 14.04 install last night. It ran though to completion without errors, and eveything worked fine in Kile. The only thing left to do is have the script alter the kilerc file with the changes MTK needs to automate document compilation for the user.

The kilerc edit steps I see are as follows.

1. Pre-pend --shell-escape to the options for the PDFLaTeX build tool.
2. Append a Sage compilation build tool option.
3. Append an MTK sequence build tool that runs the PDFLaTeX tool, then the Sage tool, then PDFLaTeX again on the proper documents in the chain.

That is great news, Jeremy. I have not looked into the Kile customization as much as you have, but those steps sound correct to me. In particular, the key to the final setup is that when we build an MTK document, it must first run PDFLaTeX (with the -shell-escape option, notice it only has one leading hyphen iirc), then run sage (on the generated .sage file), and finally run PDFLaTeX again (still with the -shell-escape option). After that, the ball is back in my court to sort out the document class and add in the necessary helper objects/methods to support using units in MTK and easily reporting them.

1. Pre-pend -shell-escape to the options for the PDFLaTeX build tool.

This is handled in the latest version of the install script.

2. Append a Sage compilation build tool option.

This is the next step.

So, for the #EngineerSpeak Hangout tonight, I'll be working on the Sage and sequence build tools for Kile.

2. Append a Sage compilation build tool option.
3. Append an MTK sequence build tool that runs the PDFLaTeX tool, then the Sage tool, then PDFLaTeX again on the proper documents in the chain.

This looks like a pretty good how-to resource for it.

Well, I started in and everything kind of fell into place. The following is the Sage tool's config that goes in the kilerc file.

[Tool/Sage/Default]
autoRun=no
checkForRoot=no
class=Compile
close=no
command=sage
jumpToFirstError=no
menu=Compile
options='%S.sagetex.sage'
state=Editor
type=Process

And here's the MTK sequence build tool

[Tool/MTK/Default]
autoRun=
checkForRoot=
class=Sequence
close=
jumpToFirstError=
menu=Compile
sequence=PDFLaTeX,Sage,PDFLaTeX
state=
type=Sequence

The next step is getting the Linux install script to add these config sections in the right place in the kilerc file. I'm tempted to have the script just download the whole config file rather than making changes to the existing one. The only drawback is that it would overwrite any changes that user had already made to their Kile configuration. If our target audience is going to install Kile from scratch, then the script can just make a backup of kilerc and dump our MTK kilerc file in its place. If we need to accommodate existing Kile installations with custom configurations, then I need to have the script directly manipulate kilerc, which is more complicated and still runs the risk of causing conflicts with previous configuration customizations.

Thoughts?

Wow, that's great news. Here's hoping my work next week on a custom document class goes have as well.

In terms of download the kilerc file or edit the existing one, I'm leaning more with the download one. I am pretty concerned about trying to auto-merge things without using a patch tool, and I think our early audience will be doing clean installs anyway. We can always circle around to an in place upgrade from Kile to MTK later if the need arises. Plus, backing up the old kilerc file will let users manually merge things for the time being.

Great work!

Ok, so that install script now does what we just discussed above, and the kilerc file gets downloaded from DMSF here .

BTW - This script gives a good example of how to download files from DMSF using wget. It takes a little extra effort because DMSF doesn't provide a direct file link, but it's definitely doable.

We'll need to test this on a fresh VM against all of the examples next week, but the Linux installer should be extremely close to being finished.

Is doing a VM download the next step in providing an easy way to try MTK?