On Fri, Jan 06, 2012 at 11:43:53PM +0100, Waldek Hebisch wrote:
> Serge D. Mechveliani wrote:
> >
> > Dear Axiom developers,
> >
> > I am trying to build a string interface between C and Axiom
> > by
> > named pipes in Linux (Unix)
> >
> > (in future, the C end needs to change to Haskell).
> >
> > The C <--> C interface works,
> > The C <--> Axiom interface works in half.
> >
> > The pipes are created by the Linux shell commands
> >
> > > mkfifo toA
> > > mkfifo fromA
> >
> > The user programs operate with these pipes as with files:
> > open, close, read, write, ....
> > The difference to files is that the named pipe operations for the two
> > processes are automatically synchronized.
> >
> > A C function cAxiom
> > * outputs the given line string to toA,
> > waits for the respond from Axiom in fromA,
> > * inputs a string from fromA to the array pointed by res.
> >
> > fricas is run first -- in the terminal-2:
> >
> > > fricas
> > ...
> > (1) )read fifoToC
> >
> > Then, ./fifoToAxiom is run in terminal-1.
> >
> > A loop body in the program fifoToC.input
> >
> > for the Axiom interpreter does the following.
> > * Reads a string from toA,
> > * parses, interprets it,
> > * converts the result to a string resStr,
> > * writes resStr to fromA.
> >
> > The C part also has the function main,
> >
> > which makes certain n different strings and applies cAxiom
> > to each string.
> > For example, for n = 3, the strings are
> > "((2*x + y + x^2*z^3) ^ 2) + 0",
> > "((2*x + y + x^2*z^3) ^ 2) + 1",
> > "((2*x + y + x^2*z^3) ^ 2) + 2".
> >
> > As the preliminary test, I replaced Axiom with the C program fifoToC.c.
> > It inputs from toA, then skips evaluation, and only outputs a single
> > letter to fromA.
> >
> > Now, C <--> C works correct,
> > but slow: 6600 strings/sec for a 1 GHz machine
> > (probably, the speed can be fixed, probably, repeated fclose needs
> > to be replaced by something, but this is another subject).
> >
> > C <--> Axiom only does the first string (so, it looks almost correct),
> > but then, the very fricas breaks silently.
> >
> > Please, what might this mean ?
> >
> > The Axiom part is in fifoToC.input :
> >
> > -------------------------------------------------------
> > repeat
> > toA: File String := open("toA", "input")
> > iStr := readIfCan! toA
> > close! toA
> > if iStr = "failed" then (output ""; output "input -> failed"; break)
> > output "iStr = "
> > output iStr
> >
> > -- parse iStr, interpret, unparse, output to fromA
> > iForm := parse(iStr)$InputForm
> > oForm := interpret iForm
> > resIForm := oForm :: InputForm
> > resStr := unparse(resIForm)$InputForm
> > output "resStr = "
> > output resStr
> >
> > fromA: File String := open("fromA", "output")
> > write!(fromA, resStr)
> > close! fromA
> > output "resStr is output"
> > output ""
> > -------------------------------------------------------
> >
> >
> >
> > terminal-2 shows
> >
> > ----------------------------------------------
> > (1) -> )r fifoToC
> > repeat
> > toA: File String := open("toA", "input")
> > <the loop body printing>
> > ...
> >
> > iStr =
> > "((2*x + y + x^2*z^3) ^ 2) + 0"
> > ----------------------------------------------
> > -- and fricas breaks out.
> >
> >
> > terminal-1 shows
> >
> > -----------------------------------
> > n = 4
> > line = "((2*x + y + x^2*z^3) ^ 2) + 0"
> > res = "x^4*z^6+(2*x^2*y+4*x^3)*z^3+(y^2+4*x*y+4*x^2)"
> >
> > line = "((2*x + y + x^2*z^3) ^ 2) + 1"
> > -----------------------------------
> > -- hangs at this point.
> >
> >
> > The files fifoToAxiom.c, fifoToC.c
> >
> > are not large to consider but, probably, are too large for this broad
> > mail list. Can you, please, take them from
> >
> > http://botik.ru/pub/local/Mechveliani/axiQuest/fifoC.zip
> >
> > and comment the effect ?
> >
>
> [..]
> OTOH it seems that code which simply writes and reads lines
> does not work due to bug in sbcl (in version used for release,
> seems to be fixed in newer versions).
>
I use FriCAS 1.1.5 made from source with the option
--with-lisp=/usr/bin/clisp
in ./configure
on the Debian Linux system.
And /usr/bin/clisp === GNU CLISP 2.48 (2009-07-28).
Do you mean that FriCAS still has sbcl inside it?
Do I need to install sbcl and to build FriCAS under it?
> You are closing and opening pipes in each iteration. I did
> not analyse this in detail, but it looks like asking for
> trouble (and certainly is huge performance sink).
Yes, I though that fopen and fclose should be called once before this
loop and once after the loop respectively.
For these two C programs in fifoC.zip, I tried to
avoid fopen-fclose in the inner loop, by replacing fclose with
fflush. But all my attempts with moving fopen-fclose and/or setting
fflush (for something still needs to push off the buffer) lead either
to fail of fgets or to hanging in waiting IO.
And I remain in wonder how to avoid these repeated fopen and fclose.
I could try read-write (in C), but expect to meet the same problem
with open-close.
If I am stuck with the named pipes, the next attempt will be either a
(1) socket or a
(2) fork + shared memory (or what it is called) for the two processes.
But, probably this needs an iterface to C for Axiom.
C interface
-----------
Haskell has such. I tried it for Haskell <-> C program for a function
String -> String -- only this type is needed.
A Haskell function calls the C function convString which outputs a
string to the named pape and inputs the response string from the back
pipe. The loop works, but again, slowly, due to the repeated
fopen-fclose in the C function. The pure Haskell function for this
(without interface) runs 90 times faster.
Has Axiom (FriCAS) a C interface?
If it has, then the Haskell -- Axiom interface by (1) or (2)
will be reduced to the Haskell -- C program interface by a (1) or (2)
-- ?
Regards,
------
Sergei
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
