I've not used githib before. But there's now a git repo at: g...@github.com:wbhart/bsdnt.git
So how do we make this work. Does everyone just push onto a branch there? I can add your ssh public key if you provide it to me. Bill. On 12 April 2010 23:48, Bill Hart <goodwillh...@googlemail.com> wrote: > Yeah, I'll do a git repo now, if I can remember how. > > Note I haven't licensed my files BSD yet. I will if there is > sufficient interest to warrant it. So far there seems to be some > interest. > > Bill. > > On 12 April 2010 23:37, Antony Vennard <antony.venn...@gmail.com> wrote: >> I was just about to reply that OpenMP is supported in MSVC. I wouldn't >> have suggested it for MPIR otherwise as it wouldn't build. icc is free >> for non-commercial use on Linux, which this constitutes, and supports >> OpenMP too. However, I think it does some funny business with binaries >> i.e. optimising them per intel chipset and defaulting amd chips to the >> slowest, so maybe this is a nice to have rather than a most? Unless that >> feature can be disabled. I will download it again and look into it. >> >> Available from: >> http://software.intel.com/en-us/articles/non-commercial-software-development/ >> >> Digital Mars is a free C/C++ compiler for Windows. I don't think many >> people use it, but I have in the past. In truth, I've no idea what it is >> like, really, I just thought wide support would be better than targeting >> say just gcc. (http://www.digitalmars.com/) >> >> I actually don't mind following any coding style... the GNU convention >> isn't my favourite but at the end of the day it's all C/C++/Assembly >> anyway, there's not much in it. >> >> Names was a bit of poor humour on my part. What it's called really >> doesn't matter - however, I think calling it mpir-something will be >> confusing, just as if we called mpir gmp-x, especially as this will be a >> near ground-up re-write. Hey, this is a debate for later stages though. >> >> I could look at the build system and see what I can come up with for an >> arch system? I can also admin a git repository on my vps if people want >> to, or we could use github or somewhere else. No matter, I can admin it >> if that is needed (to be honest once you've done git init --bare and git >> update-server-info there's not much else to do). >> >> Antony >> >> On 04/12/2010 11:16 PM, Bill Hart wrote: >>> Brian points out that MSVC has openMP support. As it is just pragmas >>> it'll be ignored by PCC (so long as we don't call OpenMP functions). >>> So yeah, why not. Let's fill the code with pragmas. >>> >>> So we should target pcc, gcc, MSVC and possibly icc. >>> >>> Six problems we have right off: >>> >>> * no longlong.h (so far I only use count_leading_zeros though) >>> * no TMP_ALLOC function >>> * no timing code (I suggest we use Dan Bernstein's library for this). >>> * no test framework >>> * no tuning framework >>> * no arch framework for assembly in my magic build system >>> >>> And all this is dependent on whether Jason Moxham is interested in >>> licensing his assembly BSD. We can't get within 50% of MPIR/GMP >>> without it. >>> >>> Bill. >>> >>> On 12 April 2010 23:05, Bill Hart <goodwillh...@googlemail.com> wrote: >>>> 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. >> >> > -- 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.
