On 08/25/2014 10:53 PM, kfp wrote: >> What do others say? Would (A) or (B) be the better alternative?
> IMHO definitively (B). OK. From the many people who replied ;-) , the "native" way seems to be preferred. > A 'native' kernel, however, might be a challenge, and is surely not a "one > day project". Certainly this will take longer. Given my more or less zero knowledge, I don't expect something this year. I would, however, be very happy if I wouldn't have to do this myself. If there were more enthusiasts that know about networking and/or sockets (maybe even zeromq) that could speed up that "little" project dramatically. > Fortunately, in the upcoming version IPy 3, it's possible to > write simple wrapper kernels. Yes, I know. And since ipython isn't part of FriCAS nor can one expect it to exist on the user system, I would rather make a small script and install IPy3 into a virtualenv. This removes the "problem" with IPy 2 vs 3. Going the pexpect way, would probably be much faster to achieve something. But I already feel that this something would have quite some problems in an ordinary workflow, since not all user inputs that lead to fricas error messages can be detected. (In particular, I saw already problems when the compilation aborts in the middle or some Ctrl-C stuff ends up at an SBCL prompt. > Eventually I've fallen back to the awesome TeXmacs interface. It's the most > promising in my view. Yeah, maybe. Nevertheless, would you be interested in helping with FriCAS kernel to IPython? What knowledge could you contribute? Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
