On 12 April 2010 21:04, Antony Vennard <antony.venn...@gmail.com> wrote: > Yes. > > Can we manage it with git? Is there a git repo already...?
There's no git repo yet. But yes, we have to manage it with git. svn is too limiting. But we'd need to give very careful thought to how we do Windows support (git doesn't work very well on Windows GUI). > Can I write #pragma omp declarations all over it? I.e. can I start > parallelising things early on? This conflicts with one of your goals below. The only compilers which support OpenMP that I am aware of are the Intel compiler and GCC basically. Probably MSVC supports pthreads, not sure about OpenMP. > I'll license all contributions on MPIR as > BSD which is easily compatible with LGPLv3 then I'm good, really, > providing I don't duplicate any existing MPIR work. I shall be very > careful not to. > Can we make it build under various compilers i.e. pcc, gcc, icc, cl, > digital mars c etc? I think it is terribly important to target pcc and gcc, as you will get a lot more interest from BSD devels if you do that. I've never used icc personally, but I will be buying a copy some time soonish. So long as it does most of what gcc does, I don't see why not. I don't know anything about the others. I won't be buying copies. The main aim has got to be to get something working within 6-12 months. That means really restricting our goals. And that means not getting distracted with unimportant laundry lists of goals. Usually you find that if someone has an interest in doing something, they'll pop up and offer to do it. Just take them up on it when it happens, so long as it doesn't slow the whole project down. Can we get something working in 6-12 months. Yes we can, if we choose our goals carefully. > Obviously we might have to duplicate effort > sometimes, but one of my feelings for gnu software is that it can only > be compiled by gcc and I don't like that, or more specifically I don't > like being tied to one way of working should I want to change. > Can we not use the GNU coding style? The only reason for suggesting this > is I don't like it, there's no actual technical merit to it. I prefer > things with lots of braces in, 4-space tab width, functions all on one > line... you'll see when I start committing. Everyone has their preferred coding style. We'd have to agree on one, and it should be clear and readable. > > What's it gonna be called? I don't really care. So far I've had it called mpzz, libnt, mpir-bsd, flint3 and probably other things. I got sick of all of these pretty quick. I've already had far more off list interest in this idea than anything else we've floated. I'm leaning more and more towards actually doing it. Anything we come up with that is actually better than MPIR, we can insert into MPIR (so long as we keep the interface compatible enough), as BSD licensed code is still compatible with LGPL v3+. Bill. > > Antony > > On 04/12/2010 08:47 PM, Bill Hart wrote: >> Rather than talk about hypothetical code I wrote when I was thinking >> of producing BSD licensed library, I may as well expose it: >> >> http://sage.math.washington.edu/home/wbhart/mpir-bsd/ >> >> It has a magic makefile system such that if you drop files in, they >> just build automatically. >> >> Simply do make check to make it work (you have to edit the top level >> makefile to specify the location of MPIR and export LD_LIBRARY_PATH >> for MPIR and the top level source directory for this library). >> >> It is about the same speed as MPIR for multiplication up to about 100 >> limbs. Everywhere it was necessary to use assembly language, I just >> called MPIR, but these functions could be used in this library >> directly. >> >> Here's what I'd do if I were going to write a BSD library: >> >> For the first 6-12 months: >> >> * x86_64 only >> * linux, Windows and FreeBSD only >> * mpn layer only (what I've called nn) - the interface already exists, >> so work to it!! >> * no autotools >> * aim for performance within 20% of GMP/MPIR for everything up to 100 limbs >> * target PCC not GCC (a very clean and efficient BSD compiler which >> also works on Windows - trivial to port to Win64) >> * aim to have 5 regular committed contributors with 2 people able to >> manage releases by the end of 12 months >> * set up a donations system on the website with the aim of hiring >> contractors to address prespecified "bounties" >> * aim for the greatest possible simplicity of design, with performance >> a *secondary* goal >> * get the software architecture right from the start >> * very careful auditing of code for license, documentation and style >> (for the latter run it through indent) >> >> If it is judged a success at the 6 and 12 month stages, move the >> project forward and allow the goals to expand. >> >> Anyone interested? >> >> Bill. >> >> On 12 April 2010 14:57, Pierre Joye <pierre....@gmail.com> wrote: >>> hi Bill, >>> >>> Thanks for the extensive reply, very much appreciated. >>> >>> On Mon, Apr 12, 2010 at 1:55 PM, Bill Hart <goodwillh...@googlemail.com> >>> wrote: >>> >>> >>>> On 12 April 2010 11:18, Pierre Joye <pierre....@gmail.com> wrote: >>> >>>> The main appeal is that we can use code from GMP without replicating >>>> their efforts and accept code from developers who want to license >>>> their code v3+. It basically means less effort for us, and faster >>>> development times. It means that the bignum community is using a >>>> single license and is less fragmented. >>> >>> It makes sense, however I wonder if it is good for mpir users. But it >>> makes the work easier for mpir developers, that's a sure thing. >>> >>> I will have to split my reply as it is a rather large topic. >>> >>>> By "not compatible with the GPL", I assume you mean that you want to >>>> distribute PHP under terms that are more permissive than the GPL will >>>> allow. >>> >>> The GPL does not allow any GPL code to be linked with PHP Licensed >>> code, at least this restriction up to v2. For v3 there is a debate >>> about "linkage" and "usage" as in using GPL code in an external >>> process (calling a cmd line tool for example). But the whole v3 move >>> (gpl and lgpl) creates a lot of troubles lately for companies and >>> other OSS projects. The "or later" clause has also been ignored in the >>> past, but the v3 shows the implications and the direction the gpl >>> license takes is scary (no offense meant, only writing down my feeling >>> about the GPL movement for the last decade). >>> >>> Short reply but other will come in the next days :) >>> >>> Cheers, >>> -- >>> Pierre >>> >>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "mpir-devel" group. >>> To post to this group, send email to mpir-de...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> mpir-devel+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/mpir-devel?hl=en. >>> >>> >> > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
