Cheers,Did you manage to get anything useful from PROC_lisp_eval or execute_lisp_function?I wonder how does "PROC_" interface relate to interactive modes of Reduce: algebraic and symbolic. Does it implement full functionality of both? of one? a subset of one?Hi Kurt,Thanks for the links. I've seen already pure interface, but not your python interface (could've saved myself half an hour if I knew about it).
BTW it seems that conversion to "fixnum"/smallint is not completely bulletproof in your Expr class (they are supposed to be maximum 28-bit long).
ValeryOn 6 April 2014 22:15, Kurt Pagani <email@example.com> wrote:
KurtGreetingsHello ValeryIt's not as bad as you might think. There are lots of REDUCE users who are using it in embedded applications. There is a phantastic procedural interface which allows one to use REDUCE as a library. See e.g. Pure (http://puredocs.bitbucket.org/pure-reduce.html) or Python (https://bitbucket.org/kfp/pyreduce). There are also several sophisticated TeXmacs plugins for REDUCE available (e.g. http://arxiv.org/html/1204.3020v1).
On 6 April 2014 01:54, Valery Yundin <firstname.lastname@example.org> wrote:
------------------------------------------------------------------------------Cheers,Do you think a mirror of the official SVN repository on github.com (git interoperate with svn seamlessly) would be useful? Also maybe a separate repository with a cut-down minimal version which contains only CSL and packages (without things like packages/rubi_red/rubi4/IntegrationTestResults/MathematicaTestResults/MathematicaNotebookFiles/) for people to get started easily?Another thing is tests, some of them are not producing reference output. Is it a known problem/not a problem or have I done something wrong?I'm curious how much user interface is fused with the backend in Reduce. In particular what kind of inevitable limitations will a library with everything except the UI have? Is it possible to more cleanly separate interface from the core and make it easier to create alternative UI? It seems that now it is all glued with #ifdefs scattered around and for instance --without-gui option seems to be slightly broken (perhaps because developers don't use it often).Also I noticed that profiling doesn't see to work with EMBEDDED=1, I'm not sure why yet (might be related to point 3?). It would be useful to be able to compile optimized version of library, at the moment my scripts can do it only with EMBEDDED not set.3. Disables something related to dynamically loadable code2. Tweaks something in terminal input/output1. Sets hard-coded stack limit to 2MBI've managed to approximately identify what -DEMBEDDED=1 does, please correct me if I'm wrongI've noticed that there is a way to compile something like a library in csl/new-embedded sub-directory. I had to make a few changes to make it compile, and got a few questions in the process.I think that Reduce gets much less attention than it deserves. There might be many reasons for this, like people being scared away by lisp, but one of them IMO is a bit messy build system and there is no library to use in other projects.Hi,First of all, I'm new to Reduce so some questions may be naive and have been already discussed somewhere.
Could anyone give more details?I started writing autoconf/automake build scripts to compile a library similar to new-embedded but with more flexibility. For that purpose it would be useful to split EMBEDDED functionality into logical subsets. For instance hard-coding stack limit might be useful sometimes, but it is completely unrelated to other things which EMBEDDED does (and which I don't understand fully).
Reduce-algebra-developers mailing list