To test the documentation you have to be on Linux (or Cygwin). makeinfo mpir.texi make pdf
I believe (but am not sure) that it's all part of the texinfo system, which is a GNU project. As such I'm sure it is completely portable and has been designed from the ground up to be very easy to use on Windows, Mac and other proprietary systems. Bill. On 15 January 2016 at 18:57, Bill Hart <goodwillh...@googlemail.com> wrote: > Hi Alex, > > On 15 January 2016 at 17:44, Alex Dyachenko <adya...@gmail.com> wrote: > >> Hello MPIR team, >> >> In my fork, I have created Visual Studio solutions (for versions 2012, >> 2013, and 2015) to build an adapter using C++/CLI that exposes MPIR for >> consumption by .Net 4.5+ languages. The basic idea is that first you build >> the LIB version of MPIR using one of the existing VS solutions, for your >> desired processor architecture. Then you build my solution that links to >> that LIB and produces a .Net assembly which exposes .Net classes for >> ints, rationals, and floats, and forwards the methods and overloaded >> operators on those classes to native MPIR calls. Similarly to the native >> C++ interface, most operations are implemented through overloaded operators >> that produce expressions with deferred-to-assignment evaluation, such that >> a single operation (e.g. a = b + c) results in a single MPIR call >> (mp*_add), while more complicated expressions will use temporaries as >> necessary. (The actual syntax would be a.Value = b + c; the reason for >> that is that .Net does not support overloaded assignment). This is not >> just a set of pinvoke signatures, but a full OO interface. >> > > This sounds really great. I'm mildly surprised to hear that something like > this didn't already exist for GMP. I know Peter Luschny has a GMP wrapper > for C#, though I don't believe he uses delayed evaluation. > > >> >> This effort is now complete with a full suite of unit tests and XML >> comments on the entire public interface (which feed nicely into Visual >> Studio intellisense), tested under both Win32 and Win64, and can of course >> be linked to any processor-specific assembly-optimized build of MPIR. I >> had to make one small refactoring to the existing MPIR code in the raw IO >> area where the existing entry point was at too high a level to be reused, >> and I split a method in two so I could use my own memory allocation and >> call into the "meat" of the raw IO. This resulted in a couple of new entry >> points being added to mpir.h but no existing signatures were changed. I >> could have re-implemented this method entirely in my code to avoid making >> any changes to the MPIR proper, but that wouldn't have been in the spirit >> of writing an adapter whose internals are all forwarded. >> >> I would like to create a pull request to have this addition code reviewed >> and eventually merged in. I realize this may take a while, and I'll be >> happy to answer your questions and/or tweak the implementation based on >> your input. I'm also willing to support it in future MPIR releases. >> Before I do the pull request, I wanted to post this as a heads up and to >> get initial feedback from you as to whether you're interested in general. >> > > We will definitely take a look at this. It sounds like a very valuable > addition to the project. I'm not clear whether you only want to contribute > the diff to MPIR or the whole project to MPIR. The former is probably > better from your point of view, since you will get more credit for it. > > Of course the question remains as to whether your code can be made to work > on Linux too. Now that MS has made C# open source (or is it just the CLR > implementation, I forget), it is now possible to run such code on Linux and > other OS's. > > But Visual Studio assumes Windows, no? > > >> >> Also I would like to write up a chapter for the manual, which will >> probably be similar in size and structure to the C++ interface chapter, >> however I'm not sure what tool chain you're using for that. I have a linux >> VM where I'm able to edit texi sources in the doc folder and produce a PDF >> from them, but if I understand correctly these are dual-purpose sources >> that also work in some other tool that perhaps parses out the special texi >> instructions that don't seem to do anything for PDF output, and I wouldn't >> want to break that. If you let me know the official way to edit and test >> the documentation, I can get started. >> > > I don't use a particular tool. I figured out what format the table of > contents options use and just do it by hand. Silly, I know, but it's not a > bottleneck in my day-to-day work routine. I rarely add new sections to the > manual. I have no idea what tool free software people use. Probably some > emacs module. > > As for including a section in the manual, this doesn't make sense if you > are only contributing the diff to MPIR and not the whole interface. In that > case I recommend writing a separate manual for your project. These days I > don't think you can do much better than Sphinx documentation. > > Of course you are more than welcome to add a small section to the MPIR > manual providing the URL of your project and a paragraph explaining what it > does. > > I'll leave it to you to decide whether you want to contribute the whole > thing to MPIR. Of course I'd love it if you did, and provided Brian doesn't > object that would be fine, but I can't help thinking you'd get less > recognition for your project if you did that. Whilst we try to do as much > as we can to promote individual authors, people ultimately end up > associating large projects like MPIR with very few people. It's worth > thinking about carefully anyway. > > We will definitely provide a link to your project on the website and in > our documentation at the very least. I'm really glad this exists. > > Bill. > > >> Cheers, >> Alex >> >> -- >> You received this message because you are subscribed to the Google Groups >> "mpir-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to mpir-devel+unsubscr...@googlegroups.com. >> To post to this group, send email to mpir-devel@googlegroups.com. >> Visit this group at https://groups.google.com/group/mpir-devel. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
