From: Valery Y. <yu....@gm...> - 2014-04-05 23:54:18
|
Hi, First of all, I'm new to Reduce so some questions may be naive and have been already discussed somewhere. 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. I'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've managed to approximately identify what -DEMBEDDED=1 does, please correct me if I'm wrong 1. Sets hard-coded stack limit to 2MB 2. Tweaks something in terminal input/output 3. Disables something related to dynamically loadable code 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). 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. 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). 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? 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? Cheers, Valery |
From: Kurt P. <ni...@gm...> - 2014-04-06 20:15:12
|
Hello Valery It'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). Greetings Kurt On 6 April 2014 01:54, Valery Yundin <yu....@gm...> wrote: > Hi, > > First of all, I'm new to Reduce so some questions may be naive and have > been already discussed somewhere. > > 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. > > I'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've managed to approximately identify what -DEMBEDDED=1 does, please > correct me if I'm wrong > 1. Sets hard-coded stack limit to 2MB > 2. Tweaks something in terminal input/output > 3. Disables something related to dynamically loadable code > 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). > > 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. > > 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). > > 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? > > 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? > > Cheers, > Valery > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > > |
From: Valery Y. <yu....@gm...> - 2014-04-07 08:16:22
|
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). 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? Did you manage to get anything useful from PROC_lisp_eval or execute_lisp_function? Cheers, Valery On 6 April 2014 22:15, Kurt Pagani <ni...@gm...> wrote: > Hello Valery > > It'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). > > Greetings > Kurt > > > > > On 6 April 2014 01:54, Valery Yundin <yu....@gm...> wrote: > >> Hi, >> >> First of all, I'm new to Reduce so some questions may be naive and have >> been already discussed somewhere. >> >> 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. >> >> I'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've managed to approximately identify what -DEMBEDDED=1 does, please >> correct me if I'm wrong >> 1. Sets hard-coded stack limit to 2MB >> 2. Tweaks something in terminal input/output >> 3. Disables something related to dynamically loadable code >> 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). >> >> 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. >> >> 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). >> >> 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? >> >> 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? >> >> Cheers, >> Valery >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Red...@li... >> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >> >> > |
From: Kurt P. <ni...@gm...> - 2014-04-07 13:38:44
|
Hi Valery There are some minor sticking points in the interface, however, Albert Gräf wrote a patch which you can find in ( https://bitbucket.org/purelang/pure-lang/downloads/pure-reduce-0.4.tar.gz). He also wrote a remarkable TeXmacs plugin ( https://bitbucket.org/purelang/pure-lang/wiki/pure-texmacs.en.pdf) which heavily relies on PROC_lisp_eval. Morevover, the Lisp eval function is indispensable if you want to use some/many of the packages. How all works is best seen in the "reduce.pure" file (contained in the tgz mentioned above). To be short, the PROC_ interface provides full functionality when using some Lisp by lisp_eval/execute_lisp_function. The Python script is merely a hack to check if it works, so forget about it. Best Kurt On 7 April 2014 10:16, Valery Yundin <yu....@gm...> wrote: > 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). > > 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? > > Did you manage to get anything useful from PROC_lisp_eval or > execute_lisp_function? > > Cheers, > Valery > > > On 6 April 2014 22:15, Kurt Pagani <ni...@gm...> wrote: > >> Hello Valery >> >> It'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). >> >> Greetings >> Kurt >> >> >> >> >> On 6 April 2014 01:54, Valery Yundin <yu....@gm...> wrote: >> >>> Hi, >>> >>> First of all, I'm new to Reduce so some questions may be naive and have >>> been already discussed somewhere. >>> >>> 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. >>> >>> I'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've managed to approximately identify what -DEMBEDDED=1 does, please >>> correct me if I'm wrong >>> 1. Sets hard-coded stack limit to 2MB >>> 2. Tweaks something in terminal input/output >>> 3. Disables something related to dynamically loadable code >>> 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). >>> >>> 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. >>> >>> 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). >>> >>> 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? >>> >>> 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? >>> >>> Cheers, >>> Valery >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Reduce-algebra-developers mailing list >>> Red...@li... >>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >>> >>> >> > |
From: Valery Y. <yu....@gm...> - 2014-04-09 16:26:04
|
Hi, Can you explain what PROC_make_cons does? Thanks, Valery On 7 April 2014 15:38, Kurt Pagani <ni...@gm...> wrote: > > Hi Valery > > There are some minor sticking points in the interface, however, Albert > Gräf wrote a patch which you can find in ( > https://bitbucket.org/purelang/pure-lang/downloads/pure-reduce-0.4.tar.gz). > He also wrote a remarkable TeXmacs plugin ( > https://bitbucket.org/purelang/pure-lang/wiki/pure-texmacs.en.pdf) which > heavily relies on PROC_lisp_eval. Morevover, the Lisp eval function is > indispensable if you want to use some/many of the packages. How all works > is best seen in the "reduce.pure" file (contained in the tgz mentioned > above). To be short, the PROC_ interface provides full functionality when > using some Lisp by lisp_eval/execute_lisp_function. > > The Python script is merely a hack to check if it works, so forget about > it. > > > Best > Kurt > > > > > > On 7 April 2014 10:16, Valery Yundin <yu....@gm...> wrote: > >> 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). >> >> 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? >> >> Did you manage to get anything useful from PROC_lisp_eval or >> execute_lisp_function? >> >> Cheers, >> Valery >> >> >> On 6 April 2014 22:15, Kurt Pagani <ni...@gm...> wrote: >> >>> Hello Valery >>> >>> It'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). >>> >>> Greetings >>> Kurt >>> >>> >>> >>> >>> On 6 April 2014 01:54, Valery Yundin <yu....@gm...> wrote: >>> >>>> Hi, >>>> >>>> First of all, I'm new to Reduce so some questions may be naive and have >>>> been already discussed somewhere. >>>> >>>> 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. >>>> >>>> I'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've managed to approximately identify what -DEMBEDDED=1 does, please >>>> correct me if I'm wrong >>>> 1. Sets hard-coded stack limit to 2MB >>>> 2. Tweaks something in terminal input/output >>>> 3. Disables something related to dynamically loadable code >>>> 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). >>>> >>>> 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. >>>> >>>> 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). >>>> >>>> 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? >>>> >>>> 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? >>>> >>>> Cheers, >>>> Valery >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Reduce-algebra-developers mailing list >>>> Red...@li... >>>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >>>> >>>> >>> >> > |
From: Arthur N. <ac...@ca...> - 2014-04-09 17:06:37
|
If others who have been using this can not explain prompty I will when I am home next week. The "embedded" version and all these ways to interface it are maybe not terribly weel documented - apologies. But hotel wifi and an expectation that I might be getting a break mean that today is not they day for me to join in! Arthur On Wed, 9 Apr 2014, Valery Yundin wrote: > Hi, > > Can you explain what PROC_make_cons does? > > Thanks, > Valery > > > On 7 April 2014 15:38, Kurt Pagani <ni...@gm...> wrote: > > Hi Valery > > There are some minor sticking points in the interface, however, Albert > Gräf wrote a patch which you can find in(https://bitbucket.org/purelang/pure-lang/downloads/pure-reduce-0.4.tar.gz) > . He also wrote a remarkable TeXmacs plugin > (https://bitbucket.org/purelang/pure-lang/wiki/pure-texmacs.en.pdf) > which heavily relies on PROC_lisp_eval. Morevover, the Lisp eval > function is indispensable if you want to use some/many of the > packages. How all works is best seen in the "reduce.pure" file > (contained in the tgz mentioned above). To be short, the PROC_ > interface provides full functionality when using some Lisp by > lisp_eval/execute_lisp_function. > > The Python script is merely a hack to check if it works, so forget > about it. > > > Best > Kurt > > > > > > On 7 April 2014 10:16, Valery Yundin <yu....@gm...> wrote: > 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). > > 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? > > Did you manage to get anything useful from PROC_lisp_eval or > execute_lisp_function? > > Cheers, > Valery > > > On 6 April 2014 22:15, Kurt Pagani <ni...@gm...> wrote: > Hello Valery > > It'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). > > Greetings > Kurt > > > > > On 6 April 2014 01:54, Valery Yundin <yu....@gm...> > wrote: > Hi, > > First of all, I'm new to Reduce so some questions > may be naive and have been already discussed > somewhere. > > 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. > > I'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've managed to approximately identify what > -DEMBEDDED=1 does, please correct me if I'm wrong > 1. Sets hard-coded stack limit to 2MB > 2. Tweaks something in terminal input/output > 3. Disables something related to dynamically > loadable code > 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). > > 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. > > 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). > > 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? > > 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 likepackages/rubi_red/rubi4/IntegrationTestResults/MathematicaTestResults/Mathe > maticaNotebookFiles/) for people to get started > easily? > > Cheers, > Valery > > > --------------------------------------------------------------------------- > --- > > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > > > > > > > |
From: Kurt P. <ni...@gm...> - 2014-04-10 18:03:52
|
> Can you explain what PROC_make_cons does? As the name indicates "PROC_make_cons" creates a Lisp "cons" from a qcar/qcdr pair in the PROC stack. To really understand what's going on one should consult http://sourceforge.net/p/reduce-algebra/code/HEAD/tree/trunk/csl/cslbase/csl.c, especially the part at the end of the file. On 9 April 2014 18:25, Valery Yundin <yu....@gm...> wrote: > Hi, > > Can you explain what PROC_make_cons does? > > Thanks, > Valery > > > On 7 April 2014 15:38, Kurt Pagani <ni...@gm...> wrote: > >> >> Hi Valery >> >> There are some minor sticking points in the interface, however, Albert >> Gräf wrote a patch which you can find in ( >> https://bitbucket.org/purelang/pure-lang/downloads/pure-reduce-0.4.tar.gz). >> He also wrote a remarkable TeXmacs plugin ( >> https://bitbucket.org/purelang/pure-lang/wiki/pure-texmacs.en.pdf) which >> heavily relies on PROC_lisp_eval. Morevover, the Lisp eval function is >> indispensable if you want to use some/many of the packages. How all works >> is best seen in the "reduce.pure" file (contained in the tgz mentioned >> above). To be short, the PROC_ interface provides full functionality when >> using some Lisp by lisp_eval/execute_lisp_function. >> >> The Python script is merely a hack to check if it works, so forget about >> it. >> >> >> Best >> Kurt >> >> >> >> >> >> On 7 April 2014 10:16, Valery Yundin <yu....@gm...> wrote: >> >>> 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). >>> >>> 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? >>> >>> Did you manage to get anything useful from PROC_lisp_eval or >>> execute_lisp_function? >>> >>> Cheers, >>> Valery >>> >>> >>> On 6 April 2014 22:15, Kurt Pagani <ni...@gm...> wrote: >>> >>>> Hello Valery >>>> >>>> It'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). >>>> >>>> Greetings >>>> Kurt >>>> >>>> >>>> >>>> >>>> On 6 April 2014 01:54, Valery Yundin <yu....@gm...> wrote: >>>> >>>>> Hi, >>>>> >>>>> First of all, I'm new to Reduce so some questions may be naive and >>>>> have been already discussed somewhere. >>>>> >>>>> 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. >>>>> >>>>> I'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've managed to approximately identify what -DEMBEDDED=1 does, please >>>>> correct me if I'm wrong >>>>> 1. Sets hard-coded stack limit to 2MB >>>>> 2. Tweaks something in terminal input/output >>>>> 3. Disables something related to dynamically loadable code >>>>> 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). >>>>> >>>>> 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. >>>>> >>>>> 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). >>>>> >>>>> 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? >>>>> >>>>> 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? >>>>> >>>>> Cheers, >>>>> Valery >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Reduce-algebra-developers mailing list >>>>> Red...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >>>>> >>>>> >>>> >>> >> > |
From: Kurt P. <ni...@gm...> - 2014-04-10 18:18:00
|
Sorry, I forgot to mention that PROC_make_cons is not part of the official REDUCE distribution, it's an addon for Pure (pure-lang/pure.reduce/proc-add.c. This only said to avoid any confusion (not to speak of bothering the developers). On 10 April 2014 20:03, Kurt Pagani <ni...@gm...> wrote: > > > Can you explain what PROC_make_cons does? > > As the name indicates "PROC_make_cons" creates a Lisp "cons" from a > qcar/qcdr pair in the PROC stack. To really understand what's going on one > should consult > http://sourceforge.net/p/reduce-algebra/code/HEAD/tree/trunk/csl/cslbase/csl.c, > especially the part at the end of the file. > > > > > On 9 April 2014 18:25, Valery Yundin <yu....@gm...> wrote: > >> Hi, >> >> Can you explain what PROC_make_cons does? >> >> Thanks, >> Valery >> >> >> On 7 April 2014 15:38, Kurt Pagani <ni...@gm...> wrote: >> >>> >>> Hi Valery >>> >>> There are some minor sticking points in the interface, however, Albert >>> Gräf wrote a patch which you can find in ( >>> https://bitbucket.org/purelang/pure-lang/downloads/pure-reduce-0.4.tar.gz). >>> He also wrote a remarkable TeXmacs plugin ( >>> https://bitbucket.org/purelang/pure-lang/wiki/pure-texmacs.en.pdf) >>> which heavily relies on PROC_lisp_eval. Morevover, the Lisp eval function >>> is indispensable if you want to use some/many of the packages. How all >>> works is best seen in the "reduce.pure" file (contained in the tgz >>> mentioned above). To be short, the PROC_ interface provides full >>> functionality when using some Lisp by lisp_eval/execute_lisp_function. >>> >>> The Python script is merely a hack to check if it works, so forget about >>> it. >>> >>> >>> Best >>> Kurt >>> >>> >>> >>> >>> >>> On 7 April 2014 10:16, Valery Yundin <yu....@gm...> wrote: >>> >>>> 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). >>>> >>>> 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? >>>> >>>> Did you manage to get anything useful from PROC_lisp_eval or >>>> execute_lisp_function? >>>> >>>> Cheers, >>>> Valery >>>> >>>> >>>> On 6 April 2014 22:15, Kurt Pagani <ni...@gm...> wrote: >>>> >>>>> Hello Valery >>>>> >>>>> It'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). >>>>> >>>>> Greetings >>>>> Kurt >>>>> >>>>> >>>>> >>>>> >>>>> On 6 April 2014 01:54, Valery Yundin <yu....@gm...> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> First of all, I'm new to Reduce so some questions may be naive and >>>>>> have been already discussed somewhere. >>>>>> >>>>>> 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. >>>>>> >>>>>> I'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've managed to approximately identify what -DEMBEDDED=1 does, please >>>>>> correct me if I'm wrong >>>>>> 1. Sets hard-coded stack limit to 2MB >>>>>> 2. Tweaks something in terminal input/output >>>>>> 3. Disables something related to dynamically loadable code >>>>>> 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). >>>>>> >>>>>> 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. >>>>>> >>>>>> 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). >>>>>> >>>>>> 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? >>>>>> >>>>>> 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? >>>>>> >>>>>> Cheers, >>>>>> Valery >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> Reduce-algebra-developers mailing list >>>>>> Red...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >>>>>> >>>>>> >>>>> >>>> >>> >> > |
From: Valery Y. <yu....@gm...> - 2014-04-10 21:37:11
|
I was wondering what was the motivation to introduce it, simple convenience or some missing functionality in the official interface? It looks to me that the same effect can be achieved with: PROC_make_function_call("cons!-quote", 2); PROC_lisp_eval(); where cons!-quote is defined as (df cons!-quote (v u) (cons (quote u) (quote v))) Cheers, Valery On 10 April 2014 20:03, Kurt Pagani <ni...@gm...> wrote: > > > Can you explain what PROC_make_cons does? > > As the name indicates "PROC_make_cons" creates a Lisp "cons" from a > qcar/qcdr pair in the PROC stack. To really understand what's going on one > should consult > http://sourceforge.net/p/reduce-algebra/code/HEAD/tree/trunk/csl/cslbase/csl.c, > especially the part at the end of the file. > > > > > On 9 April 2014 18:25, Valery Yundin <yu....@gm...> wrote: > >> Hi, >> >> Can you explain what PROC_make_cons does? >> >> Thanks, >> Valery >> >> >> On 7 April 2014 15:38, Kurt Pagani <ni...@gm...> wrote: >> >>> >>> Hi Valery >>> >>> There are some minor sticking points in the interface, however, Albert >>> Gräf wrote a patch which you can find in ( >>> https://bitbucket.org/purelang/pure-lang/downloads/pure-reduce-0.4.tar.gz). >>> He also wrote a remarkable TeXmacs plugin ( >>> https://bitbucket.org/purelang/pure-lang/wiki/pure-texmacs.en.pdf) >>> which heavily relies on PROC_lisp_eval. Morevover, the Lisp eval function >>> is indispensable if you want to use some/many of the packages. How all >>> works is best seen in the "reduce.pure" file (contained in the tgz >>> mentioned above). To be short, the PROC_ interface provides full >>> functionality when using some Lisp by lisp_eval/execute_lisp_function. >>> >>> The Python script is merely a hack to check if it works, so forget about >>> it. >>> >>> >>> Best >>> Kurt >>> >>> >>> >>> >>> >>> On 7 April 2014 10:16, Valery Yundin <yu....@gm...> wrote: >>> >>>> 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). >>>> >>>> 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? >>>> >>>> Did you manage to get anything useful from PROC_lisp_eval or >>>> execute_lisp_function? >>>> >>>> Cheers, >>>> Valery >>>> >>>> >>>> On 6 April 2014 22:15, Kurt Pagani <ni...@gm...> wrote: >>>> >>>>> Hello Valery >>>>> >>>>> It'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). >>>>> >>>>> Greetings >>>>> Kurt >>>>> >>>>> >>>>> >>>>> >>>>> On 6 April 2014 01:54, Valery Yundin <yu....@gm...> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> First of all, I'm new to Reduce so some questions may be naive and >>>>>> have been already discussed somewhere. >>>>>> >>>>>> 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. >>>>>> >>>>>> I'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've managed to approximately identify what -DEMBEDDED=1 does, please >>>>>> correct me if I'm wrong >>>>>> 1. Sets hard-coded stack limit to 2MB >>>>>> 2. Tweaks something in terminal input/output >>>>>> 3. Disables something related to dynamically loadable code >>>>>> 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). >>>>>> >>>>>> 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. >>>>>> >>>>>> 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). >>>>>> >>>>>> 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? >>>>>> >>>>>> 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? >>>>>> >>>>>> Cheers, >>>>>> Valery >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> Reduce-algebra-developers mailing list >>>>>> Red...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >>>>>> >>>>>> >>>>> >>>> >>> >> > |
From: Valery Y. <yu....@gm...> - 2014-04-17 20:39:19
|
Hi Arthur, I'd appreciate if you could find a minute to have a look at and possibly comment on my earlier questions (they are quoted at the end of this email for convenience). And I have a few more. I was trying get Reduce to process a bunch of expressions, so I was looking for a way to relatively easily access its algebraic mode from procedural interface (mainly because I don't want to parse them myself, which I would need if I stayed on lisp/symbolic side, but there are other nice things in algebraic mode too). 'execute_lisp_function' seems right for the job and 'begin' looks like a good candidate for the actual function to call. But it sets "!*echo := not !*int" which is a bit inconvenient. So I wrote a simplified version of 'begin' which sets flags I want: (de begin-batch nil (prog nil (fluid (quote (!*echo !*mode !*int))) (global (quote (ifl!* ipl!* ofl!* crbuf!* !*extraecho))) (setq ifl!* nil) (setq ipl!* nil) (setq ofl!* nil) (setq !*echo nil) (setq !*extraecho nil) (verbos nil) (setq !*mode (quote algebraic)) (while (errorp (errorset (quote (begin1)) !*backtrace !*backtrace)) nil) (setq crbuf!* nil) (return nil))) It has some problems though. Firstly the "(while (errorp (errorset ..." part doesn't seem to catch any errors, especially stuff like "Undefined symbol", which causes segmentation faults. It seems that in regular Reduce this kind of errors are caught by C-code, is it possible at all to catch them using procedural interface? Things like this: symbolic rubbish(); would cause "Error undefined function" in Reduce, but will crash everything if it happens somewhere inside procedural call such as 'execute_lisp_function'. Another smaller problem is that if input ends with (bye) then (setq crbuf!* nil) above will never be executed. I guess the simplest thing is to redefine 'bye and 'quit to do something less destructive like (return nil), but I wonder if it could cause some adverse side-effects somewhere else? Cheers, Valery On 6 April 2014 01:54, Valery Yundin <yu....@gm...> >> wrote: >> Hi, >> >> First of all, I'm new to Reduce so some questions >> may be naive and have been already discussed >> somewhere. >> >> 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. >> >> I'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've managed to approximately identify what >> -DEMBEDDED=1 does, please correct me if I'm wrong >> 1. Sets hard-coded stack limit to 2MB >> 2. Tweaks something in terminal input/output >> 3. Disables something related to dynamically >> loadable code >> 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). >> >> 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. >> >> 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). >> >> 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? >> >> 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 likepackages/rubi_red/rubi4/ >> IntegrationTestResults/MathematicaTestResults/Mathe >> maticaNotebookFiles/) for people to get started >> easily? >> >> Cheers, >> Valery >> >> |
From: Valery Y. <yu....@gm...> - 2014-05-13 07:45:17
|
Hi, Possible my previous message was lost, any ideas how to deal with errors in procedural interface? (questions quoted below) Hi Arthur, > > I'd appreciate if you could find a minute to have a look at and possibly > comment on my earlier questions (they are quoted at the end of this email > for convenience). And I have a few more. > > I was trying get Reduce to process a bunch of expressions, so I was > looking for a way to relatively easily access its algebraic mode from > procedural interface (mainly because I don't want to parse them myself, > which I would need if I stayed on lisp/symbolic side, but there are other > nice things in algebraic mode too). > > 'execute_lisp_function' seems right for the job and 'begin' looks like a > good candidate for the actual function to call. But it sets "!*echo := not > !*int" which is a bit inconvenient. So I wrote a simplified version of > 'begin' which sets flags I want: > > (de begin-batch nil > (prog nil > (fluid (quote (!*echo !*mode !*int))) > (global (quote (ifl!* ipl!* ofl!* crbuf!* !*extraecho))) > (setq ifl!* nil) (setq ipl!* nil) (setq ofl!* nil) (setq !*echo nil) > (setq !*extraecho nil) (verbos nil) > (setq !*mode (quote algebraic)) > (while > (errorp (errorset (quote (begin1)) !*backtrace !*backtrace)) > nil) > (setq crbuf!* nil) > (return nil))) > > It has some problems though. Firstly the "(while (errorp (errorset ..." > part doesn't seem to catch any errors, especially stuff like "Undefined > symbol", which causes segmentation faults. It seems that in regular Reduce > this kind of errors are caught by C-code, is it possible at all to catch > them using procedural interface? > > Things like this: > symbolic rubbish(); > would cause "Error undefined function" in Reduce, but will crash > everything if it happens somewhere inside procedural call such as > 'execute_lisp_function'. > > Another smaller problem is that if input ends with (bye) then (setq > crbuf!* nil) above will never be executed. I guess the simplest thing is to > redefine 'bye and 'quit to do something less destructive like (return nil), > but I wonder if it could cause some adverse side-effects somewhere else? > > Cheers, > Valery > > > On 6 April 2014 01:54, Valery Yundin <yu....@gm...> >>> wrote: >>> Hi, >>> >>> First of all, I'm new to Reduce so some questions >>> may be naive and have been already discussed >>> somewhere. >>> >>> 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. >>> >>> I'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've managed to approximately identify what >>> -DEMBEDDED=1 does, please correct me if I'm wrong >>> 1. Sets hard-coded stack limit to 2MB >>> 2. Tweaks something in terminal input/output >>> 3. Disables something related to dynamically >>> loadable code >>> 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). >>> >>> 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. >>> >>> 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). >>> >>> 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? >>> >>> 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 likepackages/rubi_red/rubi4/ >>> IntegrationTestResults/MathematicaTestResults/Mathe >>> maticaNotebookFiles/) for people to get started >>> easily? >>> >>> Cheers, >>> Valery >>> >>> > Best, Valery |