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.
