enthought/enaml — comment on commit 3a6d947d8dd305f8824972197e2dfd9392c9873b
File:  line 0
By sccolbert:

Thanks.

Regarding your points:

* What's the problem with LGPL? The plan is to get it working by porting it,
then changing it up significantly to be more Pythonic.
* I did the same with scipy.optimize.fmin_slsqp. It worked, but was 3ms per
solution for a ui with 3 widgets.
* The plan is to get it working with pure Python, then Cythonize it. Since
cassowary uses a sparse matrix dictionary and set representation, we
shouldn't need numpy or scipy.

On Wed, Oct 19, 2011 at 5:00 AM, Robert Kern <
reply@reply.github.com>wrote:

> A couple things:
>
> * Directly translating the Cassowary source to Python does not remove the
> LGPL license of the code.
> * I've experimented with this before using a slightly different solver. It
> was a more naive approach, using a plain LP solver anew for each layout when
> resizing. The performance when dragging was barely acceptable. You really
> need the sophistication of Cassowary's iterative algorithm that lets you
> change the parameters slightly and reuse the solution to the previous,
> closely related problem as a starting point. Even with the full Cassowary
> algorithm, I don't expect that pure Python code will be fast enough.
> * Requiring numpy/scipy would be a bummer if we want anyone else to use it.
> For most Enthought projects, it doesn't matter much.
>
> --
> Reply to this email directly or view it on GitHub:
>
> https://github.com/enthought/enaml/commit/3a6d947d8dd305f8824972197e2dfd9392c9873b#commitcomment-660710
>