Personally I like the idea of rabidly forking the "main" repository, i.e. everyone maintain their own repo and let me know of patches and I'll pull them onto the master repo. Everyone can track that and merge patches into their own repos.
Does that work? Next question is what to do about Windows. Brian Gladman will not be using the command line and so we need to ensure that whatever we come up with works smoothly for him. Relying on one of us to push changes onto an svn repo somewhere and then to merge back when he makes changes seems like too much effort. It would be better if we could figure out how to get git working properly on Windows. Surely someone has sorted that out by now! Bill. On 13 April 2010 18:31, Antony Vennard <antony.venn...@gmail.com> wrote: > Hi Bill, > > Sorry for the delay. > > Basically, we have two options: > > * One, we all work off that repository and just push our work to our own > dedicated branches (git being distributed means we can do what we like > on our own local copies provided we push to the correct remote branch). > Someone will have to co-ordinate merges and pushes to "master" and any > "main" branches i.e. branches with multiple users on, otherwise it gets > complicated very quickly. > * Two, we all establish our own git repositories everywhere, preferably > publicly accessible. Then, you or someone else pulls branches from other > people's repositories and pushes it to yours. This is how linux > development works, linux-2.6.git on kernel.org is "the" kernel but there > are lots of other repositories there too. You could also have your own > personal repository, Bill, so that you've not just got to rely on not > hosing the main one and so that you can if you want give someone else > the "keys" for a while whilst keeping your work. > > I've answered questions on git several times on Stack Overflow. Here, > probably, is my best one. The question contains a horrendous amount of > links to all sorts of questions already asked which seem to cover most > bases: > http://stackoverflow.com/questions/2621610/what-git-branching-models-actually-work-the-final-question > (I am ninefingers, the second answer). > > I can work with either mechanism. If you have a box somewhere I can > configure it a bit like kernel.org if that's easiest? Well ok, probably > not as good as them, but you get the idea! > > Antony > > On 04/13/2010 12:15 AM, Bill Hart wrote: >> 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. > > -- 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.
