Those both seem to be optional, so I don't see how that affects us.

2009/11/30 Andrew Dai <andy.dai@gmail.com>
I think Keith's referring to the use of MPFR and GMP. Both of which
are definitely overkill for how we use fparser. If fparser is really
becoming a full-on scientifically oriented numeric library then we
will have to think about alternatives.

2009/11/30 Mike Gist <xordan@gmail.com>:
> Bloat isn't always proportional to code size. If the additions are
> optimisations then it's probably okay.
>
> 2009/11/30 Keith Fulton <keith.fulton@gmail.com>
>>
>> fparser looks like it is getting more and more bloated.  Perhaps it is
>> time to look for something else tighter.
>>
>
>
> --
> -Mike
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> PlaneShift-cvs mailing list
> PlaneShift-cvs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/planeshift-cvs
>
>



--
-Mike