Waldek, Thank you for this explanation. Your closing comment is the final nail in the coffin.
Kindly, Mark. On 22 Mar 2018 13:47, Waldek Hebisch <[email protected]> wrote: Mark Clements wrote; > > For 2), the functionality is potentially interesting -- albeit > orthogonal to most uses and users. I found an example of some calling > code at: > > http://axiom-wiki.newsynthesis.org/images/axiom--test--1/src/algebra/c05.spad.tex > > I agree that this is ugly. I tried to debug the code with: > > )expose FORT > )boot $addUnderscoreToFortranNames := true > )boot $fortranDirectory := nil > )boot $fortranLibraries := '"-lm" > )boot $fortranTmpDir := '"/tmp/" > )boot $fortranCompilerName := '"gfortran" > -- the following is incorrectly specified > )boot makeFort("test",[], [], [], [], []) > > This gave a system error: "The function BOOT::SYSTEM is undefined". As I wrote the code is non-working. And if we want to call Fortran there is better way. I do not know why NAG did things in so complicated way, possible because they did not want to depend on dynamical loading of libraries. Another possiblity is that they wanted capability of calling functions on remote machines. Currently FriCAS needs dynamical loading anyway, so we could use it for calling Fortran code. And for running code on remote machines there are established ways which we shall use in case we want to have such functionality. To clarify: the alternatives I mention need implementing, but implementing them is probably less effort than trying to resurect NAG interface code. > naive question, what is a standard way of calling an OS function in > boot? OBEY. This is wrapper to OS and Lisp dependent specific function. For serious work we probably need better interface, but existence of Windows means that we can not make that really smooth, there will be ugly differences. > I assume that NAG spent considerable effort to get the Fortran code to > work - and it seems a pity to throw all of this away, although this > would have an opportunity cost. Several years ago NAG folks discouraged us from using old interface code -- apparently they were also not satisfied with the code. -- Waldek Hebisch -- 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout. On 22 Mar 2018 13:47, Waldek Hebisch <[email protected]> wrote: Mark Clements wrote; > > For 2), the functionality is potentially interesting -- albeit > orthogonal to most uses and users. I found an example of some calling > code at: > > http://axiom-wiki.newsynthesis.org/images/axiom--test--1/src/algebra/c05.spad.tex > > I agree that this is ugly. I tried to debug the code with: > > )expose FORT > )boot $addUnderscoreToFortranNames := true > )boot $fortranDirectory := nil > )boot $fortranLibraries := '"-lm" > )boot $fortranTmpDir := '"/tmp/" > )boot $fortranCompilerName := '"gfortran" > -- the following is incorrectly specified > )boot makeFort("test",[], [], [], [], []) > > This gave a system error: "The function BOOT::SYSTEM is undefined". As I wrote the code is non-working. And if we want to call Fortran there is better way. I do not know why NAG did things in so complicated way, possible because they did not want to depend on dynamical loading of libraries. Another possiblity is that they wanted capability of calling functions on remote machines. Currently FriCAS needs dynamical loading anyway, so we could use it for calling Fortran code. And for running code on remote machines there are established ways which we shall use in case we want to have such functionality. To clarify: the alternatives I mention need implementing, but implementing them is probably less effort than trying to resurect NAG interface code. > naive question, what is a standard way of calling an OS function in > boot? OBEY. This is wrapper to OS and Lisp dependent specific function. For serious work we probably need better interface, but existence of Windows means that we can not make that really smooth, there will be ugly differences. > I assume that NAG spent considerable effort to get the Fortran code to > work - and it seems a pity to throw all of this away, although this > would have an opportunity cost. Several years ago NAG folks discouraged us from using old interface code -- apparently they were also not satisfied with the code. -- Waldek Hebisch -- 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout. On 22 Mar 2018 13:47, Waldek Hebisch <[email protected]> wrote: Mark Clements wrote; > > For 2), the functionality is potentially interesting -- albeit > orthogonal to most uses and users. I found an example of some calling > code at: > > http://axiom-wiki.newsynthesis.org/images/axiom--test--1/src/algebra/c05.spad.tex > > I agree that this is ugly. I tried to debug the code with: > > )expose FORT > )boot $addUnderscoreToFortranNames := true > )boot $fortranDirectory := nil > )boot $fortranLibraries := '"-lm" > )boot $fortranTmpDir := '"/tmp/" > )boot $fortranCompilerName := '"gfortran" > -- the following is incorrectly specified > )boot makeFort("test",[], [], [], [], []) > > This gave a system error: "The function BOOT::SYSTEM is undefined". As I wrote the code is non-working. And if we want to call Fortran there is better way. I do not know why NAG did things in so complicated way, possible because they did not want to depend on dynamical loading of libraries. Another possiblity is that they wanted capability of calling functions on remote machines. Currently FriCAS needs dynamical loading anyway, so we could use it for calling Fortran code. And for running code on remote machines there are established ways which we shall use in case we want to have such functionality. To clarify: the alternatives I mention need implementing, but implementing them is probably less effort than trying to resurect NAG interface code. > naive question, what is a standard way of calling an OS function in > boot? OBEY. This is wrapper to OS and Lisp dependent specific function. For serious work we probably need better interface, but existence of Windows means that we can not make that really smooth, there will be ugly differences. > I assume that NAG spent considerable effort to get the Fortran code to > work - and it seems a pity to throw all of this away, although this > would have an opportunity cost. Several years ago NAG folks discouraged us from using old interface code -- apparently they were also not satisfied with the code. -- Waldek Hebisch -- 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout. -- 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
