TeXmacs format contribution
Alexander Solovets
Some month ago I had started to develop TeXmacs format output for
fricas. Now it's completed and I want to ask how should I prepare my
contribution (big patch, a series of patches, etc)?
Regards, Alexander.
Bill Page
> --
> 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 fricas...@googlegroups.com.
> To unsubscribe from this group, send email to fricas-devel...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
>
>
Ralf Hemmecke
svn repo. Just use github. It's easy to rebase to trunk from there.
See
https://sites.google.com/site/hemmecke/fricas-svn
for more details.
I think a series of carefully crafted patches (each handling one idea at
a time) would be nice. But since your work seemingly adds _one_ new
feature, namely the TeXmacs connection, it's probably also OK if it just
lives in _one_ big patch.
My suggestion would be, make it first public on github as described
above, then it is easier to say how to integrate your work.
Ralf
Alexander Solovets
Ralf Hemmecke
Looking at
https://github.com/hemmecke/fricas-svn/blob/master/src/interp/i-util.boot#L70
and
https://github.com/hemmecke/fricas-svn/blob/master/src/interp/int-top.boot#L167
it is quite surprising that Alexander's patch
https://github.com/mbait/fricas/commit/4192a3a6ac357905a2db1d03b91d6d85e5db3517
is not yet in trunk.
Patch is attached.
Martin, can you also confirm that this is a good patch?
Ralf
Ralf Hemmecke
> https://github.com/mbait/fricas
Hi Alexander,
from what I see, you basically adapted the mathml output. And I quite
like your _series_ of patches. So I am more in favour of several patches
instead of one big patch.
I had a little problem during rebasing your patches onto trunk, but the
conflict in src/algebra/boo-dom1.input was easily resolvable.
No problem with compilation and ")set output texmacs on" seems to work
as proposed.
Aleander, maybe you should revise texmacs.spad.pamphlet a bit more in
order to mention your name in the "++ Author:" information, correcting
year etc. You should probably also try
build/scripts/document texmacs.spad.pamphlet
in order to check whether your file compiles correctly. At the moment it
doesn't.
I am in favour of supporting texmacs and volunteer to commit to trunk.
Waldek, do you give green light for the commit?
Ralf
PS: Alexander, I've installed TeXmacs 1.0.7.4 via apt-get in Maverick.
There appears an "Axiom" session type, but that doesn't work for me.
What would be the new texmacs-way to take advantage of your new feature
of fricas?
Alexander Solovets
Thanks for the review! I am glad you appreciate that. However there
are still a few things to fix.
> Aleander, maybe you should revise texmacs.spad.pamphlet a bit more in order
> to mention your name in the "++ Author:" information, correcting year etc.
> You should probably also try
>
> build/scripts/document texmacs.spad.pamphlet
>
> in order to check whether your file compiles correctly. At the moment it
> doesn't.
Sure, I'll make it. I just wanted to be sure that my changes are at
most acceptable.
> PS: Alexander, I've installed TeXmacs 1.0.7.4 via apt-get in Maverick. There
> appears an "Axiom" session type, but that doesn't work for me. What would be
> the new texmacs-way to take advantage of your new feature of fricas?
Yeah, that problem isn't solved yet. We have had a little discussion
about proper way of implementing that. The main idea of my work is let
TeXmacs to communicate with Fricas directly. So I guess to use here
some kind of command line switches that would enable TeXmacs format as
default at start. More common way is to add optional argument that
will run external script.
At the moment I use additional plugin(in attachment) in couple with .axiom.input
Ralf Hemmecke
>> appears an "Axiom" session type, but that doesn't work for me. What would be
>> the new texmacs-way to take advantage of your new feature of fricas?
>
> Yeah, that problem isn't solved yet. We have had a little discussion
> about proper way of implementing that. The main idea of my work is let
> TeXmacs to communicate with Fricas directly. So I guess to use here
> some kind of command line switches that would enable TeXmacs format as
> default at start. More common way is to add optional argument that
> will run external script.
> At the moment I use additional plugin(in attachment) in couple with .axiom.input
Can you be a little more precise of how exactly I can use your
fricas-plugin. I'm not familiar with texmacs and thus have no idea of
how and where to install the plugin. Perhaps somewhere inside ~/.TeXmacs ?
Ralf
Alexander Solovets
Ralf Hemmecke
> Exactly =) Just put "fricas" in .TeXmacs/plugins and two other scripts in "~".
Oh, not quite...
I had to execute the commands appearing at the top of the fricas shell
script, namely
AXIOM='/home/hemmecke/software/lib/fricas/target/i686-pc-linux'
export AXIOM
PATH=${AXIOM}/bin:${PATH}
export PATH
otherwise the FriCAS menu item doesn't appear in the session menu of
texmacs.
But you cannot require someone to set the AXIOM variable manually. So
you better change fricas/progs/init-fricas.scm to something like this:
(plugin-configure fricas
(:require (url-exists-in-path? "fricas"))
;(:initialize (fricas-initialize))
(:launch "fricas -nosman")
(:session "FriCAS"))
Calling "fricas -nosman" has the same effect as calling AXIOMsys with
the AXIOM and PATH env variables set appropriately.
Second, you provided .axiom.input and texmacs.input. The standard init
script for Fricas is ~/.fricas.input . So I've now created this file
with content:
)set output algebra off
)set output texmacs on
)lisp (setf |$ioHook| (lambda (x &optional args) (cond ((eq x
'|startPrompt|) (princ (concat (code-char 2) "prompt#") )) ((eq x
'|endOfTeXmacsOutput|) (princ (concat (code-char 5) (code-char 10))))
((eq x '|startTeXmacsOutput|) (princ (code-char 2))) ((eq x
'|startKeyedMsg|) (princ (concat (code-char 2) "verbatim:"))) ((eq x
'|endOfKeyedMsg|) (princ (code-char 5))) ((eq x '|endOfPrompt|) (princ
(code-char 5) )) )))
)lisp (setf |$inputPromptType| '|plain|)
With the above modifications I can report to have a FriCAS running
inside TeXmacs. Nice!
There are a few issues remaining, though.
1) Since you don't start the sman process, there is no graphics
and no hyperdoc.
2) Globally changing ~/.fricas.input is not a good idea in my opinion.
As for 1) I have no idea why starting "fricas" instead of "fricas
-nosman" does not work. Maybe, because sman is starting AXIOMsys and
texmacs simply does not realize that sman is not giving back control.
For 2), I wish FriCAS had a way to run scripts specified on the command
line, i.e. something like "fricas -read texmacs.input".
hemmecke
> line, i.e. something like "fricas -read texmacs.input".
like
fricas -c "fricas commands here"
but concerning .fricas.input file, one could use pipes. Just something
like
(plugin-configure fricas
(:require (url-exists-in-path? "fricas"))
(:session "FriCAS"))
I have no file ~/.fricas.input. This file lives inside the
~/.TeXmacs/plugins/fricas/ subdir.
The only problem I can see at the moment is that typing ")quit" inside
a texmacs fricas session will hang the fricas session, since the
fricas
process is terminated but the cat command (and therefore texmacs)
doesn't recognise that fricas is now dead and so will wait for further
input.
It shows "Busy..." and the session cannot be restarted.
That looks like a corner case, but I'd rather like a proper solution.
Ralf
Waldek Hebisch
>
> On 12/31/2010 06:33 AM, Alexander Solovets wrote:
> > https://github.com/mbait/fricas
>
> Hi Alexander,
>
> from what I see, you basically adapted the mathml output. And I quite
> like your _series_ of patches. So I am more in favour of several patches
> instead of one big patch.
>
> I had a little problem during rebasing your patches onto trunk, but the
> conflict in src/algebra/boo-dom1.input was easily resolvable.
>
> No problem with compilation and ")set output texmacs on" seems to work
> as proposed.
>
> Aleander, maybe you should revise texmacs.spad.pamphlet a bit more in
> order to mention your name in the "++ Author:" information, correcting
> year etc. You should probably also try
>
> build/scripts/document texmacs.spad.pamphlet
>
> in order to check whether your file compiles correctly. At the moment it
> doesn't.
>
> I am in favour of supporting texmacs and volunteer to commit to trunk.
> Waldek, do you give green light for the commit?
>
I think it make sense to wait few days to resolve problem that
are likely to show up. Today I am in a hurry but tomorrow I will
take look at the code.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Alexander Solovets
>> line, i.e. something like "fricas -read texmacs.input".
I think either script or command sequence is fine, but it seems that
AXIOMsys doesn't receive command line argument at all. If there are
any they are processed either by "axiom" script or by "sman".
Therefore I need some help in this question.
Ralf Hemmecke
Oh, maybe it is easier than I thought. The file .fricas.input is not
only tried from the path $HOME, but first from the current directory.
In other words writing something like ...
(plugin-configure fricas
(:require (url-exists-in-path? "fricas"))
(:launch "cd ~/.TeXmacs/plugins/fricas; fricas -nosman")
(:session "FriCAS"))
in ~/.TeXmacs/plugins/fricas/progs/init-fricas.scm tries to read
~/.TeXmacs/plugins/fricas/.fricas.input.
Ralf
Waldek Hebisch
'sayTeX'. This is wrong, TexmacsFormat should use its own
function, logically it should be called 'sayTexmacs'. Namely,
'sayTeX' sends its output to $texOutputStream. Texmacs output
should go to a separate stream (so that it is possible to send
TeX output to a file via Texmacs interface). In TexmacsFormat
the minmal change could be addition of line:
sayTeX ==> sayTexmacs
but global renaming may be good for readability. In particular,
the '$Lisp' part is better hidden in a macro.
Of course, we need to add code to create appropriate stream
and define the 'sayTexmacs' function, I will do this.
BTW: I wonder if I am looking at correct file. Github shows
me date 2010-11-04 and I still see a lot of MathML stuff
in the file.
BTW2: IIUC texmacs.spad.pamphlet compared to MathML version
is changed so much that it is better to treat it as new file.
But for other files I would like to see just the diff as
a single patch, so that I can see all changes and only the
changes. How can I get such diff?
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> me date 2010-11-04 and I still see a lot of MathML stuff
> in the file.
This is Alexander's last commit
https://github.com/mbait/fricas/commit/bec51d296ffb9872713600067536d3be3103c9ae
and it indeed has a commit date 05-Nov-2010.
Judging from where he branched, I guess he used git even before I told
him around Christmas.
https://github.com/mbait/fricas/network
> BTW2: IIUC texmacs.spad.pamphlet compared to MathML version
> is changed so much that it is better to treat it as new file.
> But for other files I would like to see just the diff as
> a single patch, so that I can see all changes and only the
> changes. How can I get such diff?
Use the above (network) URL. You can click on any of these bullets and
see the respective commit. Also at the first above URL you find a
"parent" link and thus can go back in time.
Easier, of course, is if you do everything locally.
There are two ways to get the patches to your computer.
Preferred way should be (1).
(1) You follow https://sites.google.com/site/hemmecke/fricas-svn to
create your own clone and then fetch the changes of Alexander to your
local git repo as described here
https://sites.google.com/site/hemmecke/fricas-svn#collaborating-with-other-people
Create an account whebisch on github and follow the steps at
https://sites.google.com/site/hemmecke/fricas-svn#how-to-work-with
at least until (including) step 3. The rest you can do later.
I assume now, you have done
git clone g...@github.com:whebisch/fricas.git
Add Alexander's repository as a "remote" and fetch his branches.
cd fricas
git remote add alex git://github.com/mbait/fricas.git
git fetch alex
git checkout alex/texmacs-format
(2) Without creating a github account you directly get Alexander's
repository.
git clone git://github.com/mbait/fricas.git
cd fricas
git checkout texmacs-format
Now, the best way to look at the patches is with
gitk --all
And if you want patch files, try
git format-patch -k18
this will create the 18 commits that Alexander is proposing.
But actually it's easier (in case (1)) with
git rebase master
(Unfortunately, it is not totally trivial, since as I wrote some days
ago, it involves resolving a simple merge conflict.)
Hope that helps.
Ralf
Ralf Hemmecke
> 'sayTeX'. This is wrong, TexmacsFormat should use its own
> function, logically it should be called 'sayTexmacs'. Namely,
> 'sayTeX' sends its output to $texOutputStream. Texmacs output
> should go to a separate stream (so that it is possible to send
> TeX output to a file via Texmacs interface). In TexmacsFormat
> the minmal change could be addition of line:
>
> sayTeX ==> sayTexmacs
>
> but global renaming may be good for readability. In particular,
> the '$Lisp' part is better hidden in a macro.
Yes, there are still a few issues. But now we can look at them and improve.
> Of course, we need to add code to create appropriate stream
> and define the 'sayTexmacs' function, I will do this.
For me it looks as if Alexander has already considered it here.
https://github.com/mbait/fricas/commit/23fe66bb3f85905ca1189006bc2bc1cf54bb50d7#diff-5
> BTW2: IIUC texmacs.spad.pamphlet compared to MathML version
> is changed so much that it is better to treat it as new file.
> But for other files I would like to see just the diff as
> a single patch, so that I can see all changes and only the
> changes. How can I get such diff?
To me it looks pretty similar.
Ralf
Arthur Ralfs
> First comment: I see that TexmacsFormat (like MathMLFormat) uses
> 'sayTeX'. This is wrong, TexmacsFormat should use its own
> function, logically it should be called 'sayTexmacs'.
Thanks for pointing this out.
I've replaced all occurrences of 'sayTeX' with 'sayMml' in my posted
version mathml.spad.pamphlet. To make it work requires also executing
)lisp (defun |sayMml| (x) (if (null x) nil (sayBrightly1 x
|$mathmlOutputStream|)))
Arthur
Alexander Solovets
supports middleware, which can be any executables =) So I can add such
a program. All that will remain is to send ")set output texmacs on"
and other commands at initialization.
Ralf Hemmecke
> I've found the most neutral solution. TeXmacs plugin interface
> supports middleware, which can be any executables =) So I can add such
> a program. All that will remain is to send ")set output texmacs on"
> and other commands at initialization.
>> (plugin-configure fricas
>> (:require (url-exists-in-path? "fricas"))
>> (:launch "cd ~/.TeXmacs/plugins/fricas; fricas -nosman")
>> (:session "FriCAS"))
If you mean that you can call any program in the ":launch" part, then
this is not the problem. The problem is that your "middleware" will have
to kill all respective processes if the user types ")quit" inside
fricas. But if you know how to do that, then maybe you can even start
"fricas" instead of "fricas -nosman".
Ralf
Alexander Solovets
have TeXmacs sources there will be C program that reads fricas output,
processes and sends result to texmacs.
Andrey G. Grozin
> I've found the most neutral solution. TeXmacs plugin interface
> supports middleware, which can be any executables =) So I can add such
> a program. All that will remain is to send ")set output texmacs on"
> and other commands at initialization.
an overkill, I think. It would be much better to have a method to read an
extra file before starting an interactive session. For example, just after
.fricas.input. Is it too difficult to find the place in the sources which
reads .fricas.input, and to duplicate it, with the file name taken from
the command line?
Andrey
Ralf Hemmecke
I've already described how to work around.
The problem is more that fricas starts several processes (hyperdoc,
graphics) itself. Usually that all is managed by sman. If one calles
"fricas -sman", one either has no hyperdoc or starts it from the fricas
input via ")hd". But such a process is then not killed if you quit
fricas. That's at least what I experienced.
Reading of the .fricas.input is started from here.
https://github.com/hemmecke/fricas-svn/blob/master/src/interp/i-toplev.boot#L63
It's in the functions readSpadProfileIfThere. I have, however no idea,
how to pass command line arguments to AXIOMsys.
Ralf
Alexander Solovets
arguments and I don't know how to access them =( As for the overkill I
am at the same point here. Therefore I've asked texmacs developers
about the way to send some data to opened session at startup.
Andrey G. Grozin
> Reading of the .fricas.input is started from here.
> https://github.com/hemmecke/fricas-svn/blob/master/src/interp/i-toplev.boot#L63
> It's in the functions readSpadProfileIfThere. I have, however no idea, how
> to pass command line arguments to AXIOMsys.
EXTRAFILE=<something>
export EXTRAFILE
Each supported lisp has a method to get values of environment variables.
The only drawback is that this method is different in each lisp :-( So, we
can abstract details like
(defun (getenv name)
#+gcl (...)
#+ecl (...)
#+sbcl (...)
...
)
and then just call getenv from i-toplev.boot.
Andrey
Waldek Hebisch
We already have getEnv function. Each supported Lisp allows getting
command line arguments and I have code to get them. The problem
is that some Lisps will interpret arguments before we can do
anything. So we need a protocol to make sure that arguments
intended for AXIOMsys do not have some unexpected effect on
host Lisp. Unfortunatly, this means analysing argument handling code
in each Lisp and it takes time.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> intended for AXIOMsys do not have some unexpected effect on
> host Lisp. Unfortunatly, this means analysing argument handling code
> in each Lisp and it takes time.
Isn't that easy? Each command line that is intended for AXIOMsys is
called something like --axiomsys-initfile --axiomsys-lisp-expr. I am
sure no LISP is looking for an option starting with --axiomsys-*.
Anyway, since we start AXIOMsys always via the fricas script, that
script could just put the command like arguments into an environment
variable (FRICASARGS, say) and pass it over to AXIOMsys as Andrey
suggested. Then picking out the arguments and react to them
appropriately should be easy.
Ralf
Waldek Hebisch
> > So we need a protocol to make sure that arguments
> > intended for AXIOMsys do not have some unexpected effect on
> > host Lisp. Unfortunatly, this means analysing argument handling code
> > in each Lisp and it takes time.
>
> Isn't that easy? Each command line that is intended for AXIOMsys is
> called something like --axiomsys-initfile --axiomsys-lisp-expr. I am
> sure no LISP is looking for an option starting with --axiomsys-*.
>
Not that easy:
bash-3.2$ clisp --axiomsys-initfile
GNU CLISP: invalid argument: '--axiomsys-initfile'
GNU CLISP: use '-h' for help
With clisp '-- --axiomsys-initfile' works, but I need to make
sure that there are no unexpected interactions with other Lisps.
> Anyway, since we start AXIOMsys always via the fricas script, that
> script could just put the command like arguments into an environment
> variable (FRICASARGS, say) and pass it over to AXIOMsys as Andrey
> suggested. Then picking out the arguments and react to them
> appropriately should be easy.
Yes, we can pass arguments via environment. I am looking at
command line in case somebody wants to start AXIOMsys directly
and does not want to mess with environment. To say the truth
since passing arguments via environment works fine I cosidered
command line of very low priority. But apparently command
line is first thing that somebody new to FriCAS wants to
use so it would be good to have something working.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> FriCAS wants to use so it would be good to have something working.
Not only that. I think sooner or later the necessity of X for graphics
should be dropped. I don't know how much the work of Martin Baker helps
here, but I heard rumours that X will be replaced by something else in
Ubuntu 11.04. (Although there will probably still be a way to run X
programs.)
I'd somehow find it better if graphics worked through the browser and
the same for hyperdoc.
That's probably lots of work, but there seem to be people around that
can actively help here.
Ralf
Ralf Hemmecke
> directly and does not want to mess with environment.
I must say, I am not in favour of starting AXIOMsys directly. AXIOMsys
requires the AXIOM environment variable to be set. Furthermore, in an
installation of FriCAS, it is not clear where exactly AXIOMsys is.
I'd rather think that the fricas script should be the _only_ way to talk
to fricas.
Ralf
Waldek Hebisch
As a soft rule yes. But starting AXIOMsys directly is essential
for debugging, so I want to keep this easy. Also, shell script
are not allowed as interpreters for '#!' scripts, so there
may be requirement for true binary.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Andrey G. Grozin
> We already have getEnv function.
for passing command-line arguments. Now there is a pressing need, for
starting FriCAS from TeXmacs, to do something like that:
* TeXmacs calls
fricas -pre texmacs.input
* fricas script does
export FRICAS_PRE=texmacs.input
* i-toplev.boot calls getEnv("FRICAS_PRE") and, if this variable is set,
reads the file after .fricas.input but before starting the interactive
session
This mechanism is quite useful in itself, without TeXmacs. Any user can
have several files with initial settings for different kinds of sessions,
and using just one init file .fricas.input for temporary needs is
inconvenient because it's too permanent.
What do you think about this specific proposal? Of course, the names (-pre
and FRICAS_PRE) can be replaced by something better.
Andrey
Alexander Solovets
fricas in such a way, he'll have to care about coresponding working
dir value (or provide absolute file path).
Ralf Hemmecke
commandline way to start arbitrary code before the fricas input line
appears, but isn't
(:launch "cd ~/.TeXmacs/plugins/fricas; fricas -nosman")
enough to start FriCAS from TeXmacs in an appropriate way?
http://groups.google.com/group/fricas-devel/msg/34dca31edc6621a8
I suppose if all the parts are distributed with TeXmacs, the :launch
path will be something like "/usr/share/texmacs/TeXmacs/plugins/fricas".
Is that a problem?
Of course a fricas user might expect that the current working directory
does not change, i.e. he might expect that the fricas working directory
is the same as from where he started texmacs. But honestly, I wouldn't
trust that assumption if I start another program (fricas) from within a
program (texmacs). Furthermore, doing in fricas something that involves
interaction with the filesystem is probably not the primary use case.
And the advantage of my suggestion from above is that you can do it even
with current (unpatched versions of fricas) no need to wait. And it is
probably also not going away in any future version of fricas.
Ralf
Andrey G. Grozin
> I don't understand you guys. Of course, it would be good to have a
> commandline way to start arbitrary code before the fricas input line
> appears, but isn't
>
> (:launch "cd ~/.TeXmacs/plugins/fricas; fricas -nosman")
>
> enough to start FriCAS from TeXmacs in an appropriate way?
session, but it is not.
> Of course a fricas user might expect that the current working directory
> does not change, i.e. he might expect that the fricas working directory is
> the same as from where he started texmacs.
Exactly!
> But honestly, I wouldn't trust
> that assumption if I start another program (fricas) from within a program
> (texmacs).
Only if the implementation is broken.
> Furthermore, doing in fricas something that involves interaction
> with the filesystem is probably not the primary use case.
I think it is. A user edits some file in emacs, and than from fricas
(inside texmacs) says
)read myfile.input
Isn't this a typical use case?
Andrey
Ralf Hemmecke
> session, but it is not.
If you think that this is a problem, then what about adding
)cd
)read ".fricas.input"
at the end of texmacs.input?
>> Of course a fricas user might expect that the current working
>> directory does not change, i.e. he might expect that the fricas
>> working directory is the same as from where he started texmacs.
> Exactly!
>> But honestly, I wouldn't trust that assumption if I start another
>> program (fricas) from within a program (texmacs).
> Only if the implementation is broken.
Well, of course, you are right. Currently, it's not perfect. I am just
suggesting something that you can use *now*.
>> Furthermore, doing in fricas something that involves interaction with
>> the filesystem is probably not the primary use case.
> I think it is. A user edits some file in emacs, and than from fricas
> (inside texmacs) says
>
> )read myfile.input
>
> Isn't this a typical use case?
Yep. But as above, I wouldn't necessarily trust that the current
directory is the same as the one I started texmacs from. Let's say, I
started Maxima inside TeXmacs and (I am now assuming that Maxima can
change the current directory---don't know if that is true) change the
current directory to something else and then start FriCAS. Is there a
clear statement in the TeXmacs documentation that a former "cd" does not
influence other sessions?
Ralf
Waldek Hebisch
Yes, that is useful. I think that 'pre' is too unspecific, what
about 'FRICAS_PREINIT' and '--preinit'? Also I similar way we can
add 'FRICAS_EVAL_LISP' and '--eval-lisp' to evaluate arbitrary
piece of Lisp code. And maybe 'FRICAS_EVAL' and '--eval' for
interpreter input. The execution order would be Lisp, then
preinit then eval.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Rubey
> Yes, that is useful. I think that 'pre' is too unspecific, what
> about 'FRICAS_PREINIT' and '--preinit'? Also I similar way we can
> add 'FRICAS_EVAL_LISP' and '--eval-lisp' to evaluate arbitrary
> piece of Lisp code.
This would help fricas.el quite a bit, actually, if it takes lisp code
on the command line!
However, I think it's not so useful to have an extra variable for
executing a file containing lisp code, since we could put it into an
ordinary input file with )lisp prepended.
Martin
Waldek Hebisch
My understanding is that preinit is FriCAS file, like .fricas.input,
only with arbitrary name and executed earlier. Of course given
eval one can use ')read somefile.input' as an argument, but
it is more convenient to have both eval and file input.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Alexander Solovets
Andrey G. Grozin
> Yes, that is useful. I think that 'pre' is too unspecific, what
> about 'FRICAS_PREINIT' and '--preinit'? Also I similar way we can
> add 'FRICAS_EVAL_LISP' and '--eval-lisp' to evaluate arbitrary
> piece of Lisp code. And maybe 'FRICAS_EVAL' and '--eval' for
> interpreter input. The execution order would be Lisp, then
> preinit then eval.
--eval ')lisp (lisp-code)'
--eval ')read something.input'
The file something.input can contain )lisp lines
All possibilities are covered.
This should be evaluated after .fricas.input but before an interactive
session, so that something.input could adjust things from .fricas.input
for the purpose of the present session (for example, a session from
TeXmacs or from emacs).
Andrey
Ralf Hemmecke
Another point for not providing '--eval-lisp' is that we should not burn
it to much into the API that LISP is the underlying system (although it
will be for many years from now).
The option --eval ')lisp ...' is good enough if needed.
I would, however, allow multiple appearances of --eval so that one is
not forced to create a file if one just wants to execute two system
commands like ")cd" or ")read" etc.
Piled syntax in --eval would be a problem anyway and should be rewritten
into a non-piled form. I just don't know exactly whether current fricas
allows such a transformation for every possible source code. However,
Code in --eval should not be too long anyway.
Ralf
Waldek Hebisch
The following (minimally tested) patch implements 'FRICAS_EVAL' in
AXIOMsys:
Index: src/interp/int-top.boot
===================================================================
--- src/interp/int-top.boot (revision 972)
+++ src/interp/int-top.boot (working copy)
@@ -93,11 +93,17 @@
$ncmMacro := NIL
$ncmPhase := NIL
+do_pre_eval() ==
+ ec := getEnv('"FRICAS__EVAL")
+ if ec then
+ CATCH('SPAD__READER, CATCH('top__level, parseAndEvalStr ec))
+
spad() ==
-- starts the interpreter, read in profiles, etc.
$PrintCompilerMessageIfTrue: local
setOutputAlgebra "%initialize%"
readSpadProfileIfThere()
+ do_pre_eval()
runspad()
'EndOfSpad
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Alexander Solovets
various Lisp-s(excluding poplog)
https://github.com/mbait/fricas/commit/488721e72aa495103cfc09475a0e4a706ef682ac
Alexander Solovets
lists in Boot in terms of Lisp (car and cdr). Also, please, notice
that the various Lisp dialects may return CL list both with 0th
argument and without it, so extraction function should take that into
account.
Alexander Solovets
may find it here http://github.com/mbait/fricas/tree/arg_values Just
build and try "axiom -eval ")set" -nosman". However, one issue still
remains - at least sbcl doesn't allow to pass a string with spaces, it
splits the string onto separate args. I don't know whether this is the
same for all Lisp-s.
On Wed, Jan 12, 2011 at 10:27 AM, Alexander Solovets
Waldek Hebisch
> Finally, I've implemented full support of eval in CL arguments. You
> may find it here http://github.com/mbait/fricas/tree/arg_values Just
> build and try "axiom -eval ")set" -nosman". However, one issue still
> remains - at least sbcl doesn't allow to pass a string with spaces, it
> splits the string onto separate args. I don't know whether this is the
> same for all Lisp-s.
>
Trying on sbcl-based FriCAS:
bash-3.2$ ax-build26/target/x86_64-unknown-linux/bin/AXIOMsys --eval "foo bar"
Checking for foreign routines
AXIOM=NIL
spad-lib="/lib/libspad.so"
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2010-09-22
Timestamp: Saturday December 4, 2010 at 11:53:04
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------
(1) -> )lisp sb-ext::*posix-argv*
Value = ("ax-build26/target/x86_64-unknown-linux/bin/AXIOMsys" "--eval"
"foo bar")
I see string with space inside, so something else is probably
responsible for splitting arguments.
Actually, sbcl seem to be easy case, it seems to behave better than
its docomentation suggests. clisp and Closuse CL are problematic.
AFAICS if you give only one argument Closuse CL treats it as name of
image (this make no sense for executable, but is still done...).
Also Closuse CL treats many things which start with '-' and single
letter as its option. In particluar it wants to take over '--eval'.
One has to put '--' on command line to stop Closuse CL from
searching the rest of command line for its arguments.
clisp seem to be worse (it signals errors for anyting it does not
recognize), but also for clisp '--' in command line protects rest
of command line form beeing treated as an argument.
To the moment I did not check ecl and gcl, but I think that we need
'--' in command line. Then command line parsing code in AXIOMsys
should remove '--'.
> On Wed, Jan 12, 2011 at 10:27 AM, Alexander Solovets
> <asol...@gmail.com> wrote:
> > I'd wirte "--eval" argument extraction too if I knew how to process
> > lists in Boot in terms of Lisp (car and cdr). Also, please, notice
> > that the various Lisp dialects may return CL list both with 0th
> > argument and without it, so extraction function should take that into
> > account.
> >
> > On Wed, Jan 12, 2011 at 10:20 AM, Alexander Solovets
> > <asol...@gmail.com> wrote:
> >> Here is the patch providing access to command-line arguments for
> >> various Lisp-s(excluding poplog)
> >> https://github.com/mbait/fricas/commit/488721e72aa495103cfc09475a0e4a706=
> ef682ac
> >>
> >> On Wed, Jan 12, 2011 at 3:52 AM, Waldek Hebisch
> >> <heb...@math.uni.wroc.pl> wrote:
> >>> Andrey G. Grozin wrote:
> >>>>
> >>>> On Mon, 10 Jan 2011, Waldek Hebisch wrote:
> >>>> > Yes, that is useful. =A0I think that 'pre' is too unspecific, what
> >>>> > about 'FRICAS_PREINIT' and '--preinit'? =A0Also I similar way we can
> >>>> > add 'FRICAS_EVAL_LISP' and '--eval-lisp' to evaluate arbitrary
> >>>> > piece of Lisp code. =A0And maybe 'FRICAS_EVAL' and '--eval' for
> >>>> > interpreter input. =A0The execution order would be Lisp, then
> >>>> > preinit then eval.
> >>>> It seems that --eval provides all the necessary functionality.
> >>>> --eval ')lisp (lisp-code)'
> >>>> --eval ')read something.input'
> >>>> The file something.input can contain )lisp lines
> >>>> All possibilities are covered.
> >>>>
> >>>> This should be evaluated after .fricas.input but before an interactive
> >>>> session, so that something.input could adjust things from .fricas.inpu=
> t
> >>>> for the purpose of the present session (for example, a session from
> >>>> TeXmacs or from emacs).
> >>>>
> >>>
> >>> The following (minimally tested) patch implements 'FRICAS_EVAL' in
> >>> AXIOMsys:
> >>>
> >>>
> >>> Index: src/interp/int-top.boot
> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>> --- src/interp/int-top.boot =A0 =A0 (revision 972)
> >>> +++ src/interp/int-top.boot =A0 =A0 (working copy)
> >>> @@ -93,11 +93,17 @@
> >>> =A0$ncmMacro :=3D =A0 =A0 =A0 =A0 =A0 =A0NIL
> >>> =A0$ncmPhase :=3D =A0 =A0 =A0NIL
> >>>
> >>> +do_pre_eval() =3D=3D
> >>> + =A0 =A0ec :=3D getEnv('"FRICAS__EVAL")
> >>> + =A0 =A0if ec then
> >>> + =A0 =A0 =A0 =A0CATCH('SPAD__READER, CATCH('top__level, parseAndEvalSt=
> r ec))
> >>> +
> >>> =A0spad() =3D=3D
> >>> =A0 -- starts the interpreter, read in profiles, etc.
> >>> =A0 $PrintCompilerMessageIfTrue: local
> >>> =A0 setOutputAlgebra "%initialize%"
> >>> =A0 readSpadProfileIfThere()
> >>> + =A0do_pre_eval()
> >>> =A0 runspad()
> >>> =A0 'EndOfSpad
> >>>
> >>>
> >>> --
> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Waldek Hebis=
> ch
> >>> heb...@math.uni.wroc.pl
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google Grou=
> ps "FriCAS - computer algebra system" group.
> >>> To post to this group, send email to fricas...@googlegroups.com.
> >>> To unsubscribe from this group, send email to fricas-devel+unsubscribe@=
> googlegroups.com.
> >>> For more options, visit this group at http://groups.google.com/group/fr=
> icas-devel?hl=3Den.
> >>>
> >>>
> >>
> >
>
> --=20
> 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 fricas...@googlegroups.com.
> To unsubscribe from this group, send email to fricas-devel+unsubscribe@goog=
> legroups.com.
> For more options, visit this group at http://groups.google.com/group/fricas=
> -devel?hl=3Den.
>
>
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
look at the first line after invocation. I am at
fd9397585e98e72b718d5ce811af0c4812af290f.
>fricas -eval "a+b" -nosman
/home/hemmecke/software/bin/fricas: line 130: [: a+b: binary operator
expected
... snip ...
(1) b + a
Type:
Polynomial(Integer)
You should probably put quotes arout the argument of -z. At least it
works for me then.
if [ "$1" = "-eval" ] ; then
shift
if [ -z "$*" ] ; then
echo "Parameter -eval must be provided with a value"
ciao
else
otheropts="-eval $1"
shift
fi
fi
In my case /bin/sh -> bash.
Ralf
Andrey G. Grozin
> The following (minimally tested) patch implements 'FRICAS_EVAL' in
> AXIOMsys:
>
>
> Index: src/interp/int-top.boot
> ===================================================================
> --- src/interp/int-top.boot (revision 972)
> +++ src/interp/int-top.boot (working copy)
> @@ -93,11 +93,17 @@
> $ncmMacro := NIL
> $ncmPhase := NIL
>
> +do_pre_eval() ==
> + ec := getEnv('"FRICAS__EVAL")
> + if ec then
> + CATCH('SPAD__READER, CATCH('top__level, parseAndEvalStr ec))
> +
> spad() ==
> -- starts the interpreter, read in profiles, etc.
> $PrintCompilerMessageIfTrue: local
> setOutputAlgebra "%initialize%"
> readSpadProfileIfThere()
> + do_pre_eval()
> runspad()
> 'EndOfSpad
This is a patch for the fricas script to use this mechanism. It allows one
to have several -eval parameters.
================================
--- /usr/bin/fricas 2010-11-24 06:40:41.000000000 +0600
+++ fricas 2011-01-14 19:55:11.000000000 +0600
@@ -20,2 +20,3 @@
# [-list] list workspaces only
+# [-eval command] evaluate command before the session
# [-grprog fname] use named program for Graphics
@@ -63,2 +64,3 @@
echo " [-list] list workspaces only"
+echo " [-eval command] evaluate command before the session"
#echo " [-grprog fname] use named program for Graphics"
@@ -138,2 +140,3 @@
otheropts=""
+FRICAS_EVAL=""
@@ -164,2 +167,14 @@
;;
+
+ -eval)
+ if [ "$2" = "" ] ; then needsubopt "$1" ; fi
+ if [ "$FRICAS_EVAL" = "" ] ; then
+ FRICAS_EVAL="$2"
+ else
+ FRICAS_EVAL="$FRICAS_EVAL
+$2"
+ fi
+ shift
+ ;;
+
-clef|-noclef|-gr|-nogr|-ht|-noht|-iw|-noiw|-ihere|-noihere|-nox|-nag|-nonag)
@@ -215,2 +230,6 @@
fi
+
+if [ "$FRICAS_EVAL" != "" ] ; then
+ export FRICAS_EVAL
+fi
================================
Andrey
Alexander Solovets
1. otheropts="-eval $1" must be changed to otheropts="-eval \"$1\"".
That will be anough to make axiom -eval "some code" -nosman workable
even with having spaces string.
2. There is already mechanism in sman.c to pass parameters to AXIOMsys
avoiding them to be captured by Lisp interpreter. So the fix is to put
"-eval" after "--" in sman.c . I could do it myself, but I am on a
little vacation now where internet connection is very slow. So I'll be
able to fix that only at the next weekend.
Alexander Solovets
eval "the code" should work.
Ralf Hemmecke
I've merged, your two branches
https://github.com/hemmecke/fricas/commits/arg-texmacs
and put
(:launch "fricas -eval ')read
/home/hemmecke/.TeXmacs/plugins/fricas/.fricas.input' -nosman")
into ~/.TeXmacs/plugins/fricas/progs/init-fricas.
It seems to work well. It's only that I see the content of my input file
in texmacs at the time I start the FriCAS session.
What I don't find perfect is that
fricas -eval 'some code' -nosman
will word, while
fricas -nsman -eval 'some code'
will not. Since -eval must be given before -nosman is evalutated.
But maybe that's not overly important to be fixed.
What would be more important is that fricas should accept several -eval
options. Otherwise I wouldn't have any clue how to put your init code
------
)set output algebra off
)set output texmacs on
)lisp (setf |$ioHook| (lambda (x &optional args) (cond ((eq x
'|startPrompt|) (princ (concat (code-char 2) "prompt#") )) ((eq x
'|endOfTeXmacsOutput|) (princ (concat (code-char 5) (code-char 10))))
((eq x '|startTeXmacsOutput|) (princ (code-char 2))) ((eq x
'|startKeyedMsg|) (princ (concat (code-char 2) "verbatim:"))) ((eq x
'|endOfKeyedMsg|) (princ (code-char 5))) ((eq x '|endOfPrompt|) (princ
(code-char 5) )) )))
)lisp (setf |$inputPromptType| '|plain|)
-------
directly into the :launch specification above, i.e. no separate
.fricas.init file.
Anyway, independent from texmacs, it would be good to be able to pass
several lines to fricas, i.e. several -eval commands.
Ralf
Alexander Solovets
indeed multiply -eval will help. "-eval" after "-nosman" doesn't work
as expected because of the strict condition: if $* = "-nosman" -> run
AXIOMsys and I tried to make as few changes as possible. I think I'll
be able to fix that both with implementing multiply evals.
> I've merged, your two brancheshttps://github.com/hemmecke/fricas/commits/arg-texmacs
Alexander Solovets
mode, i.e. neither of "axiom -nosman -eval" or "axiom -eval -nosman"
works. However, there is "-texmacs" option that does all required to
start communication with TeXmacs. "AXIOMsys -eval" works also.
Multiply eval-s are supported.
Alexander Solovets
Ralf Hemmecke
I don't quite understand what you are indending with this patch:
https://github.com/mbait/fricas/commit/35ff9a71b838440fcf16eee5aee14d5726086a09#diff-1
It is inherently unsafe when the -eval's become longer than 1024 bytes.
http://en.wikipedia.org/wiki/Strcpy#Buffer_overflows
Same problem for augmented_ws_path. There it's even only 256 bytes long.
Also
https://github.com/mbait/fricas/commit/81359c8186a4de6a3ee2d0d745328372c9f97de9#diff-1
can cause a buffer overflow.
Ralf
Ralf Hemmecke
fricas -nosman -eval
i.e. no argument to eval?
evalInlineCode() ==
args := getCLArgs()
while #args > 0 repeat
arg := CAR args
if arg = '"-eval" then
CATCH('SPAD__READER,CATCH('top__level,parseAndEvalStr CADR(args)))
args := CDDR args
else
args := CDR args
Ralf
Alexander Solovets
allocated and reallocated if it requires. AXIOMsys will do nothing if
meet empty eval argument.
> --
> 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 fricas...@googlegroups.com.
> To unsubscribe from this group, send email to
> fricas-devel...@googlegroups.com.
> For more options, visit this group at
Waldek Hebisch
> Can anyone review my branches and commit if they are ok?
>
I would like to get your code commited as soon as possible. However
IIUC command line arguments are currently needed by Texmacs, so
that should go in first. I had some trouble with command line
arguments. First, ECL needs more complicated code for getting
arguments and also in Closure CL variable containing command line
arguments has different name (you used name of _function_).
Next, by default Closure CL would try to interpret whole
command line and would complain if there were extra items
(worse, it would try to perform '-eval') -- I had to disable
default argument processing in Closure CL. Similarely gcl
would try to perform '-eval', I had to disable that too.
And we need '--' as first argument to AXIOMsys (just after
name of executable) to avoid problems with Closure CL
and clisp (otherwise clisp would complain that it does not
understand the whole command line).
Also, it is not enough to just use '"' for quoting, for example
'--eval "String with space"' would fail. AFAICS the only safe
way is to use backslashes to quote all potentially unsafe
characters. And we need to do quoting twice, once in axiom/fricas
script, the second time in sman (currently sman passes command
line to the shell).
One more remark: replacing 'exec' by 'eval' means that the shell
executing axiom/fricas script would wait for sman/AXIOMsys to
finish which uses unnecessary extra process. It is better to
use 'eval exec' to avoid extra process.
I have now comitted argument handling with fixes as above (without
the texmacs hunk as this one really belongs to the texmacs branch).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Alexander Solovets
eval/exec. Also I tried to insert "--" before arguments, but
|getCLArgs| returned then empty list. That might be because I used
sbcl.
One more thing I want to ask you about: can you compose some tests
which would produce expressions with INDEFINTEGRAL, VCONCAT, TAG,
EQUATNUM, ZAG, SIGMA/SIGMA2/PI/PI2(in terms of binary operation),
RARROW. Also I completely do not know how to get partial
derivatives(differentials).
P.S. What kind of output should be "ZAG" turned into? I look at it in
"alegebra" mode and really saw a big zig-zag. But what is the kind of
math operation it?
Ralf Hemmecke
> "alegebra" mode and really saw a big zig-zag. But what is the kind of
> math operation it?
Not the best example, but maybe it helps.
Ralf
(2) -> )set output tex on
(2) -> continuedFraction(2/3)
1 | 1 |
(2) +---+ + +---+
| 1 | 2
$$
\zag{1}{1}+ \zag{1}{2}
\leqno(2)
$$
Waldek Hebisch
>
> One more thing I want to ask you about: can you compose some tests
> which would produce expressions with INDEFINTEGRAL, VCONCAT, TAG,
> EQUATNUM, ZAG, SIGMA/SIGMA2/PI/PI2(in terms of binary operation),
> RARROW. Also I completely do not know how to get partial
> derivatives(differentials).
>
Little comment: I think that subscripts and superscrips are most
visible missing part (they are also used for derivatives).
RARROW does not appear in FriCAS (it is only in your
'texmacs.spad.pamphlet'). TAG means right arrow:
(27) -> mT := MoebiusTransform(Fraction(Integer))
(27) MoebiusTransform(Fraction(Integer))
Type: Type
(28) -> moebius(2, 1,1, 1)$mT
2%x + 1
(28) %x -> -------
1%x + 1
Type: MoebiusTransform(Fraction(Integer))
(29) -> ((moebius(2, 1,1, 1)$mT )::OutputForm)::SEX
(29) (TAG %x (/ (+ (* 2 %x) 1) (+ (* 1 %x) 1)))
Type: SExpression
EQUATNUM is produced by 'label' function, it is in examples I gave
you. AFAICS there is no other way to get it in TexmacsFormat
(for text output EQUATNUM is used to attach the number, but
this happens inside i-output.boot and do not propagate to
TexmacsFormat).
AFAICS currently INDEFINTEGRAL is unused. My impression is
that INTSIGN was intended for definite integrals, but currently
it is used for indefinite integrals and INDEFINTEGRAL is unused.
As Ralf wote continuedFraction(314159/100000) gives you ZAG:
(1) -> (continuedFraction(314159/100000)::OutputForm)::SEX
(1)
(+ 3
(+
(+ (+ (+ (+ (+ (ZAG 1 7) (ZAG 1 15)) (ZAG 1 1)) (ZAG 1 25)) (ZAG 1 1))
(ZAG 1 7))
(ZAG 1 4))
)
Type: SExpression
AFAICS you handle this. But somewhat nested ZAG-s cause trouble.
Differentials:
(4) -> D(besselJ(v, x), v)
(4) besselJ (v,x)
,1
Type: Expression(Integer)
(30) -> (D(besselJ(v, x), v)::OutputForm)::SEX
(30) ((SUB besselJ (CONCAT , 1)) v x)
Type: SExpression
(5) -> D(hypergeometricF([a, b], [c, d], z), c)
(5) hypergeometricF ([a,b],[c,d],z)
,3
Type: Expression(Integer)
Sums:
(6) -> (sum(n^n, n=1..m)::OutputForm)::SEX
(6) (SIGMA2 (= n 1) m (^ n n))
Type: SExpression
(7) -> (sum(n^n, n)::OutputForm)::SEX
(7) (SIGMA n (^ n n))
Type: SExpression
(8) -> sum(n^n, n=1..m)
m
--+ n
(8) > n
--+
n= 1
Type: Expression(Integer)
(9) -> sum(n^n, n)
--+ n
(9) > n
--+
n
Type: Expression(Integer)
Products:
(11) -> (product(n^n, n=1..m)::OutputForm)::SEX
(11) (PI2 (= n 1) m (^ n n))
Type: SExpression
(12) -> (product(n^n, n)::OutputForm)::SEX
(12) (PI n (^ n n))
Type: SExpression
(13) -> product(n^n, n=1..m)
m
++-++ n
(13) | | n
| |
n= 1
Type: Expression(Integer)
(14) -> product(n^n, n)
++-++ n
(14) | | n
| |
n
Type: Expression(Integer)
VCONCAT is rarely used and real eaxmple would require some effort,
but artifical is easy:
(19) -> of1 := ('f)::OutputForm
(19) f
Type: OutputForm
(20) -> of2 := ('z)::OutputForm
(20) z
Type: OutputForm
(21) -> vconcat(of1, of2)
(21) f
z
Type: OutputForm
(22) -> vconcat(of1, of2)::SEX
(22) (VCONCAT f z)
Type: SExpression
As you see the intent is to put one part on top of the other.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
>
> Can anyone review my branches and commit if they are ok?
>
AFAICS texmacs.spad.pamphlet is still unifinished. After looking
at other output formatters I think that we should do the following
changes:
- rename formatMml, formatTexmacs, formatTex, formatHtml, formatFormula
to formatExpr (the functions are doing the same job, but for
different output formats and using different names obscures
similarity)
- instead of sayTeX$Lisp, sayTexmacs$Lisp, etc we should have
sayOutput. At the beginning we should have macro expanding
to correct value, like:
sayOutput ==> sayTexmacs$Lisp
or
sayOutput ==> sayTex$Lisp
That way we preserve similarity and avoid spreading $Lisp all
over the source.
Also, there is bug in MathML format which propageted to
HTML and Texmacs formats:
1) -> of1 := ('f)::OutputForm
(1) f
Type: OutputForm
(2) -> of2 := ('z)::OutputForm
(2) z
Type: OutputForm
(3) -> zag(zag(of1, of2),zag(of1, of2))::OutputForm::SEX
(3) (ZAG (ZAG f z) (ZAG f z))
Type: SExpression
(4) -> )set output mathml on
(4) -> zag(zag(of1, of2),zag(of1, of2))::OutputForm::SEX
(4) (ZAG (ZAG f z) (ZAG f z))
>> System error:
The value ZAG is not of type LIST.
(we get error or crash). This bug is not present in TeX
format and it would be good to fix other formats.
The changes can be done _after_ Texmacs format is commited, I just
mention them now to allow better planing.
Concerning commit: I prefer to commit finished pieces, it saves time
spent testing. But the implemented part of texmacs.spad.pamphlet
looks OK and contains enough functionality that it can be commited
now. Other parts of 'texmacs-format' branch can go unchanged. One
only needs to add the '-texmacs' option handling from argument
branch. In this hunk one should replace 'eval' by 'exec' and
eliminate one level of backslashes.
ATM on my main machine I can not install Texmacs because my system
lacks Guille developement files and Guille dependences essentially
means that I need to upgrade my whole system. I intended to do this
anyway, but it will take some time. Any, this means that there
will be delay before I will be able to test if '-texmacs' works.
Alexander, will you have more complete version quickly? If yes
maybe we should wait for this version? Otherwise we should go
with your current version.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> sayOutput. At the beginning we should have macro expanding
> to correct value, like:
>
> sayOutput ==> sayTexmacs$Lisp
>
> or
>
> sayOutput ==> sayTex$Lisp
>
> That way we preserve similarity and avoid spreading $Lisp all
> over the source.
Actually, I'd rather have sayOutput in a package Foo which takes a
parameter "TeX", "TeXmacs", etc. (whether string or an integer that is
used for selection, I don't care much), but then one would have
say x ==> sayOutput("TeXmacs", x)$Foo
then all the Lisp stuff would be concentrated in Foo.
Ralf
Ralf Hemmecke
> spent testing.
I can commit directly from git if the branch is rebased on top of trunk.
But I can probably only do that not before the weekend.
I just hope that I did understand correctly what Waldek just suggested.
Waldek, are you interested in a series of patches or rather in one huge
commit?
Ralf
Ralf Hemmecke
> over the source.
Actually, when I took a quick look over all this different output
routines, they looked terribly similar. I'm sure one could even factor
out the common parts. But that would mean quite a bit of
planning/designing and I was not in the mood to get too much involved in
that part.
Anyway, if someone can think of a better way to avoid duplication of
code, that would be wonderful.
Ralf
Waldek Hebisch
I think about one commit. I am not sure why you use word "huge":
in 'src/algebra' subdirectory besides 'texmacs.spad.pamphlet' there
are 4 tiny hunks. In 'src/interp' there is 6 hunks totaling in about
200 lines. And few lines in 'src/etc'. Unless I misses some
other parts I would rather call it 'moderate'. And all those
hunks strongly depend on each other and serve single purpose.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
Why do you want to introduce parameter? It looks like completly
unnecessary indirection.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Alexander Solovets
> maybe we should wait for this version? Otherwise we should go
> with your current version.
Sorry, I won't. I will try to implement remaining constructions ASAP,
but I have no much time because I've been starting to work on my
thesis. If you want to test 'texmacs-format' without having TeXmacs
installed, you can grad output and ask someone to put it in TeXmacs
via 'Edit->Paste from->Scheme'. Not pretty, but works =)
P.S. Can I find a list of common used functions for boot? Especially,
how can I check whether a variable is a list?
Waldek Hebisch
>
> > Alexander, will you have more complete version quickly? =A0If yes
> > maybe we should wait for this version? =A0Otherwise we should go
> > with your current version.
>
> Sorry, I won't. I will try to implement remaining constructions ASAP,
> but I have no much time because I've been starting to work on my
> thesis. If you want to test 'texmacs-format' without having TeXmacs
> installed, you can grad output and ask someone to put it in TeXmacs
>
> P.S. Can I find a list of common used functions for boot? Especially,
> how can I check whether a variable is a list?
You can use Lisp functions writing name in upper case, in particular
LISTP tests if its argument is a list. However, typically one needs
to do more. For such cases Boot has pattern matching, for example
l is ["Mapping",:.]
checks that l is a list with first element beeing symbol "Mapping"
(note that in Boot unlike most other languages double quotes mean
symbol). As a byproduct of test you can assign subpaterns to
variables, like:
l is ["Mapping", x, y]
which checks if l is a three element list beginning in "Mapping"
and if yes assigns second element to 'x' and third to 'y'.
Note that the match as whole is a boolean expression which you
can use as other tests.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
>
> > Alexander, will you have more complete version quickly? =A0If yes
> > maybe we should wait for this version? =A0Otherwise we should go
> > with your current version.
>
> Sorry, I won't. I will try to implement remaining constructions ASAP,
> but I have no much time because I've been starting to work on my
> thesis.
OK, I have now commited texmacs format. I have changed it a bit
so that it correctly outputs sub and superscripts. Note: of
your contribution there is one remaining hunk to be commited,
namely change to axiom/fricas script. It requires a little
adjustment and still have to check that after adjustment it
works correctly with Texmacs.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Alexander Solovets
> so that it correctly outputs sub and superscripts. Note: of
> your contribution there is one remaining hunk to be commited,
> namely change to axiom/fricas script.
That is good news! Thanks for fixing those issues about sub/super
scripts. Could you clarify the required changes, please? Btw, here is
screenshot with some working examples
http://www.linux.org.ru/gallery/5941838.png
Waldek Hebisch
>
> That is good news! Thanks for fixing those issues about sub/super
> scripts. Could you clarify the required changes, please?
MathML format tries to make distinction between sub/super scripts
and derivatives. The code to handle this has some problems.
AFAICS for Texmacs this distinction is not needed, so I changed
code to go to formatSpecial to handle sub/super scripts. In
formatSpecial SUB case I basicaly reused what you had in formatSub1.
In SUPERSUB case I introduced 'optionalWrap' routine to avoid
repetitive code, but the logic is quite similar to what you
had in formatSuperSub. The problem you had was that formatSub1
and formatSuperSub had several branches and you did not handle
all of them. And AFAICS MathML version do not handle/mishandle
some less common cases... Doing sub/super scripts in formatSpecial
means that we need less code to handle them.
BTW: I do not know how to express prescripts in Texmas so they
are currently not handled.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Alexander Solovets
> are currently not handled.
I'll look at the code. Making prescripts is quite easy -- lsup/lsub. I
thin I've added them, perhaprs didn't cover all scripts cases.
And I was asking about axiom/fricas. What do I have to fix/improve in
order to see "-texmacs" option in trunk?
Waldek Hebisch
I want to know that it works as intended. AFAICS in axiom/fricas
script tiny change of quoting should be enough. But to test it one
needs to adjust code of fricas plugin -- I fetched your 'fricas-plugin.tgz'
but clearly it assumes initialization via '.fricas.input'. I have
now working Texmacs and I hope to work out needed changes in next
days. Of course if you provided updated version it would be
faster.
BTW1: Compared to your version change may look trivial. But
experience showed that such changes frequently introduce bugs.
BTW2: We probably should put (updated) content of 'fricas-plugin.tgz'
in 'contrib' subdirectory, so that somebody trying to use the interface
has all pieces handy.
BTW3: The change to axiom script probably should look like below,
but as I wrote this needs testing:
--- ../trunk.pp8/src/etc/axiom 2011-02-25 14:35:44.000000000 -0500
+++ etc/axiom 2011-03-01 14:02:40.000000000 -0500
@@ -66,6 +66,7 @@
#echo " [-clientprog fname] use named program for spadclient"
echo " [-h] show usage"
echo " [-eval code] evaluate specified code at start"
+echo " [-texmacs] setup Fricas for communication in TeXmacs protocol"
}
# 1. Ensure the environment is set.
@@ -121,9 +122,18 @@
rootwsdir=$SPAD/bin
# 2. Process command line arguments.
+algebra_off=')set output algebra off'
+texmacs_on=')set output texmacs on'
+markers=")lisp (setf |\$ioHook| (lambda (x &optional args) (cond ((eq x '|startPrompt|) (princ (concat (code-char 2) \"prompt\#\") )) ((eq x '|endOfTeXmacsOutput|) (princ (concat (code-char 5) (code-char 10)))) ((eq x '|startTeXmacsOutput|) (princ (code-char 2))) ((eq x '|startKeyedMsg|) (princ (concat (code-char 2) \"verbatim:\"))) ((eq x '|endOfKeyedMsg|) (princ (code-char 5))) ((eq x '|endOfPrompt|) (princ (code-char 5) )) )))"
+
+
+if [ "$*" = "-texmacs" ] ; then
+ exec "$SPAD/bin/AXIOMsys" -- -eval "$algebra_off" -eval "$markers" -eval "$texmacs_on"
+fi
+
if [ "$*" = "-nosman" ] ; then
- exec $SPAD/bin/AXIOMsys
+ exec "$SPAD/bin/AXIOMsys"
exit 1
fi
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Alexander Solovets
> but clearly it assumes initialization via '.fricas.input'. I have
> now working Texmacs and I hope to work out needed changes in next
> days. Of course if you provided updated version it would be
> faster.
> BTW2: We probably should put (updated) content of 'fricas-plugin.tgz'
> in 'contrib' subdirectory, so that somebody trying to use the interface
> has all pieces handy.
My fault, sorry. Of course there is newer one, look at the attached archive.
Waldek Hebisch
>
> > I fetched your 'fricas-plugin.tgz'
> > now working Texmacs and I hope to work out needed changes in next
> > faster.
>
> > BTW2: We probably should put (updated) content of 'fricas-plugin.tgz'
> > in 'contrib' subdirectory, so that somebody trying to use the interface
> > has all pieces handy.
>
> .
Thanks, I have now commited changes to axiom/fricas script.
Looking at formatting routines I think that there is time for a
cleanup. I did some limited cleanup of TMFORM (and added support
for prescripts) current version (and a diff) is at:
http://www.math.uni.wroc.pl/~hebisch/fricas/TMFORM.spad
http://www.math.uni.wroc.pl/~hebisch/fricas/TMFORM.diff
However, I think more changes are needed. First, currently
OutputForm uses mixture of symbols and strings. I would
standarise and declare that a form either is a Lisp atom
(which in particular may be a string) or a list such
that the first element ("operator") is a symbol. One
possible reasun for current use of strings is that
in symbols we need to escape special charaters -- I find
escaping acceptable, but alternatively we may write
strings and immediately coerce to symbols.
Next, MathML format currently tries to parse OutputForm
to reconstruct derivatives (from superscript primes) and
continuous fractions (from ZAG-s). This code has serious
problem -- current version which parses textual representation
of OutputForm basically can not work correctly, but even
if we change it to work on level of S-expression it still
will be somewhat unreliable. So, I think that if MathML
really needs to know about derivatives, then we should
change OutputForm so that derivatives would use different
operator than superscripts. Similarely for ZAG (however,
it would be better to somewhat represent ZAG in MathML,
because big continouous fraction printed as fraction is
harder to read than the same fraction printed using ZAG).
To some degree the same applies to Texmacs and Html formats
since they borrowed code from MathML.
Next, currently some convertion routines output result of
conversion -- this is wrong: convertion should be silent and
the output should be done by 'display'.
Finally, it looks that significant part of output formatter
analyses form, handles priorities and dispatches to
elementary operation. AFAICS we could share this code
by changing formatters to be categories: top category
would contain common code, specific format would provide
primitives.
Note: we need categories to get OO-style dispatch.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
Since you are working on OutputForm, would it be possible to provide
some common escape mechanism for unicode characters?
I realise that unicode characters may not be passed through by the
command line or lisp but if there were some acceptable escape
character, such as,
/Theta/
or
/0x1234/
which could be embedded in strings, variable names and operator names,
then each instance of OutputForm could translate that into its own
format.
Just an idea,
Martin Baker
Waldek Hebisch
I admit that I do not understand what effect you want to get.
Simple mechanizm like "output unicode string" is problematic
as there is no way to do this on ASCII-only console (in fact
unrestricted Unicode is problematic for _all_ output formats
because most of Unicode fonts is quite incomplete). Basically
I see the following constraints:
- we need resonable fallback for non-Unicode media. Outputing
something like 'UnicodeString("0xbaab123456") where inside
double quotes is hexadecimal representation of octets is
easy, but I am affraid is not reasonable
- currently symbols names (and consequently variable names) are
Lisp strings. Moreover any legal Lisp string may serve as
variable name (and in practice convertions between strings
and variable names are quite frequent). This means that
any "escaping convention" on variable names in practice
would have to be used for all strings. If details of
escaping would be visible on user level IMHO this would
make string manipulations quite unpleasent. If details
are hidden, than we effectively get support for Unicode
strings regardless of what is provided by Lisp -- my
plan is to provide Unicode strings at Spad level, but
I hope to this simpler than via escape sequences.
For now, if needed we could add a lot of new operators (say
"full" set of TeX/LaTeX operators), here since operators
have names textual falback is easy and there is no need to
use Unicode to represent them internally.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
alphabet, in this case I guess mainly for variable names. Also it
would be useful to output something like μ in a string so that the
program can append units or something like that. Also something like Σ
might be a function name.
In the case of html and mathml they are represented by ampersand
followed by the name followed by a semicolon.
α = α
β = β
Γ = Γ γ = γ
Δ = Δ δ = δ
δ = ε
ζ = ζ
η = η
Θ = Θ θ = θ
ι = ι
κ = κ
Λ = Λ λ = λ
μ = μ
ν = ν
Ξ = Ξ ξ = ξ
ο = ο
Π = Π π = π
ρ = ρ
Σ = Σ σ = σ
Τ = Τ τ = τ
Υ = Υ υ = υ
Φ = Φ φ = φ
χ = χ
Ψ = Ψ ψ = ψ
Ω = Ω ω = ω
What I'm suggesting is something like this, but using escape
characters that are transparent to command line and list, then html
and mathml would translate to this form, other output forms would
translate to their own format. Output forms which only support ascii
could just use the name like: 'alpha' which seems a reasonable
fallback.
I hope the unicode characters display in this message otherwise it
won't make much sense. It displayed all right when I typed it into
Google Groups.
Martin Baker
Bill Page
Do you think it might be sufficient if unicode support was limited to
the Symbol domain? See for example now how subscripts are handled via
script:(Symbol, List List OutputForm) -> Symbol
When a Symbol is coerced to OutputForm and rendered as algebra, tex,
mathml etc. subscripts and superscripts are displayed as appropriate
to the presentation format. It seems to me that supporting unicode
symbols as part of the Symbol domain would not be so hard. So then for
example
_&alpha()^2
would be a polynomial and might render as
2
alpha
\alpha^2
α<sup>2</sup>
etc.
On the other hand this would not allow the use of unicode in
interpreted and SPAD variable names.
BTW, the unicode symbols displayed just fine for me in gmail.
Regards,
Bill Page.
2011/3/6 Martin Baker <ax8...@martinb.com>:
Waldek Hebisch
> As an example I think it would be useful to support the greek
> alphabet, in this case I guess mainly for variable names. Also it
> program can append units or something like that. Also something like =D3
> might be a function name.
>
> In the case of html and mathml they are represented by ampersand
> followed by the name followed by a semicolon.
>
> characters that are transparent to command line and list, then html
> and mathml would translate to this form, other output forms would
> translate to their own format. Output forms which only support ascii
> could just use the name like: 'alpha' which seems a reasonable
> fallback.
>
> I hope the unicode characters display in this message otherwise it
> won't make much sense. It displayed all right when I typed it into
> Google Groups.
My mailer conveted this to "quoted printable", but no problem,
I know how HTML character entities work. Let me explain why
I am not entusiastic about escapes. Namely, if you want
something quick and dirty you can do this now like below:
(3) -> )set output mathml on
(3) -> ("α"::Symbol)::Polynomial(Integer)
(3) α
<math xmlns="http://www.w3.org/1998/Math/MathML" mathsize="big" display="block">
<mi>α</mi>
</math>
Type: Polynomial(Integer)
(4) -> )set output tex on
(4) -> )set output mathml off
(4) -> ("\alpha"::Symbol)::Polynomial(Integer)
(4) \alpha
$$
\alpha
\leqno(4)
$$
Type: Polynomial(Integer)
In other words you can use strings denoting HTML entities or TeX
characters as variable names and they will get to external format,
so they will render as apropriate symbol. Arguably this works
only because our output formaters are lousy -- careful formatter
would escape all special characters so that in MathML output
form 'α' we would get '&alpha;' which would render the
same as textual version (so not a Greek letter). However, this
illustrates problems with escaping: reliably getting correct
results is painful. Escapes are unavoidable for input form
limited media and may be also neccessary in output, but
using escaping during processing should be best avoided,
and if really needed escaping should be encapsulated so that
it is transparent. Also, this example illustrates that sometimes
beeing lousy (literally trasmitting special sequences) is
useful.
Few more remarks:
1) It seems that you really ask for "complete" support for Unicode
(or at least mathematical subset of Unicode). Namely, for
something better than hack above we really need a worked out
design. For processing Unicode is done and really I see
no reason to design something different. Of course there
remain issue of input and output (where escapes may be
neccessary), but is is not clear how much is really needed.
For use in source code relatively crude techniques (like
having a function which conerts Unicode code point (integer)
to correspinding character) should be enough. For interactive
use your suggestion goes into direction of turning FriCAS
into a word processor. Since there exist several fine
text editors and two of them (emacs and now Texmacs) have
interfaces to FriCAS and AFAIK allow rich variety of Unicode
input/output the logical thing to do is to use editor to get
charaters from/to user and just transmit UTF-8 to/from FriCAS.
2) The reason I started to look at output routines (beyond
Texmacs format which was direct cause) is that we accumulated
a lot ad hoc stuff and confusion in output routines so that
getting something done is getting hard. So I would like
to decrease ad-hockery (and not increase it). Of course
some ad-hoc solutions are useful, but they are really like
taking high-interest loan -- they cost a lot of effort
in future. And like loan they make sense if there is
emergency or prospect for big payoff.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
Thanks for both your replies, I take your point that you are trying to
simplify the code rather than make it more complex. I just thought
that, if I'm going to mention it, better to do it while people are
working on the code.
> (3) -> ("α"::Symbol)::Polynomial(Integer)
and far from ideal, but its useful to know about this.
> 1) It seems that you really ask for "complete" support for Unicode
> (or at least mathematical subset of Unicode). Namely, for
> something better than hack above we really need a worked out
> design.
> For processing Unicode is done and really I see
> no reason to design something different.
about this, are you saying that SPAD and Lisp can handle Unicode but
command line I/O is the only thing preventing this?
Although this is non-ideal, I can certainly live with this issue (by
using the hacks that you mentioned and if required I can hack my own
local copy of html formatter) however I would be quite surprised if I
am the only one who has wanted to uses non-ascii characters with
FriCAS. Is there a list of known issues for new users where all these
workarounds could be put in one place?
Come to think of it, is there a wish-list for FriCAS? I could think of
a long list, but perhaps I should keep quiet, I suspect you won't
agree with most of them?
Martin
Bill Page
> Hi Bill and Waldek,
>
> Thanks for both your replies, I take your point that you are trying to
> simplify the code rather than make it more complex. I just thought
> that, if I'm going to mention it, better to do it while people are
> working on the code.
>
>> (3) -> ("α"::Symbol)::Polynomial(Integer)
>
> I didn't realise this until you both mentioned it, definitely a hack
> and far from ideal, but its useful to know about this.
Actually I did not recommend this although I knew that it was
possible. What I was suggesting was adding some new (internal)
representations in the Symbol domain and some association function
names, e.g.
_&alpha: () -> Symbol
that return these symbols. These new Symbols would have to be rendered
as appropriate depending on )set output.
>
>> 1) It seems that you really ask for "complete" support for Unicode
>> (or at least mathematical subset of Unicode). Namely, for
>> something better than hack above we really need a worked out
>> design.
>
> Exactly!
Of course one could also have a function such as
unicode: Integer -> Symbol
that does this in a more general manner.
>
>> For processing Unicode is done and really I see
>> no reason to design something different.
>
> I don't quite understand this. Just so that I am completely clear
> about this, are you saying that SPAD and Lisp can handle Unicode but
> command line I/O is the only thing preventing this?
If you are talking about unicode character support in a console
session (as opposed to MathML or LaTeX) then current the command
)set output algebra on
does not (and I think is not intended) to handle this. "algebra" mode
might be better named "ASCII" mode. The intention is to "draw"
symbols, subscripts, superscripts etc. as "ASCII art".
For unicode support in a console session that supports unicode one
would need yet another output format, say
)set output unicode on
Then the internal representation of a Symbol could be rendered as
appropriate for that presentation form, i.e. as a specific unicode
character encoded for example in the UTF-16 character set. In this
case there would be some serious decisions that might need to be made
for unicode support of symbols for certain operations such as integral
signs and sums etc. This might be quite non-trivial.
>
> Although this is non-ideal, I can certainly live with this issue (by
> using the hacks that you mentioned and if required I can hack my own
> local copy of html formatter) however I would be quite surprised if I
> am the only one who has wanted to uses non-ascii characters with
> FriCAS. Is there a list of known issues for new users where all these
> workarounds could be put in one place?
>
> Come to think of it, is there a wish-list for FriCAS? I could think of
> a long list, but perhaps I should keep quiet, I suspect you won't
> agree with most of them?
>
I think you should not be discouraged by Waldek's response. I would
like to see what you have on your mind. If you feel inclined to
elaborate you are welcome to post such ideas on
http://axiom-wiki.newsynthesis.org
in addition to this list.
Regards,
Bill Page
Jalaluddin Morris
Are you all familiar with the way Isabelle/HOL handles TeX characters?
Regards,
Jalaluddin
Martin Baker
> If you feel inclined to
> elaborate you are welcome to post such ideas on
>
> http://axiom-wiki.newsynthesis.org
http://axiom-wiki.newsynthesis.org/AxiomIssues
Martin
Ralf Hemmecke
Have you looked at time point 43:30?
http://www.infoq.com/presentations/fortress-steele
And move to time point 17:40 to see a bit about unicode.
Ralf
Martin Baker
It looks like there are a lot of interesting ideas in the Fortress
language although this talk was given in Jan 2008 and I get the
impression that things have gone quiet on that project (even before
the Oracle takeover).
What I heard on that talk was that, as a matter of policy, they do not
support operator overloading and they only use operators for
traditional mathematical operations.
What I take that to mean, although I may have misunderstood, is that
infix operators can only be used for built-in types? That looks fine
for a scientific programming language like Fortress but is it really
practical for a CAS?
Martin
Ralf Hemmecke
> not support operator overloading and they only use operators for
> traditional mathematical operations.
My subject line mentions "precedence". If you look at the slides at
46:00 and 47:00. Steele basically says yes to operator if the language
uses unicode and programmers are disciplined enough to use unicode
operators with traditional mathematical meaning. (Well, I guess, there
are quite some operators in math that don't have a "traditional" meaning.)
But the point I wanted to make was that precedence is a difficult thing.
Since it is (traditionally) not transitive. Steele basically says that
it is better to use parentheses in order to make the meaning of the
program clear.
> What I take that to mean, although I may have misunderstood, is that
> infix operators can only be used for built-in types?
Wrong. Look the following slides.
> That looks fine for a scientific programming language like Fortress
> but is it really practical for a CAS?
It would be good if SPAD used UTF-8 as an input character set and would
enable programmers to define operators as prefix, infix or postfix to
get close to mathematical notation.
In fact, we all know that mathematical notation is not always precise to
the last bit. Steele shows examples like how to parse:
3 x sin x cos 2 x log log x (40:00)
We should accept that programming languages can help to make things more
precise.
Ralf
Waldek Hebisch
Waldek Hebisch
> > 1) It seems that you really ask for "complete" support for Unicode
> > (or at least mathematical subset of Unicode). Namely, for
> > something better than hack above we really need a worked out
> > design.
>
> Exactly!
>
> > For processing Unicode is done and really I see
> > no reason to design something different.
>
> I don't quite understand this. Just so that I am completely clear
> about this, are you saying that SPAD and Lisp can handle Unicode but
> command line I/O is the only thing preventing this?
>
Not exactly. First, problem of processing "rich" charcter data
appeared long ago and various appraches were tried. One worth
mentioning was based on codepage switching: there are special
seqences of characters which signal change of used character
set. That way it is possible to switch between 8-bit and
16-bit encodings (and theoretically 24-bit (and more) are
possible). And even using 8-bit encodings it is possible to
use rich character set. Unicode movement began due to
dissatifaction with codepage switching -- one of design goals
of Unicode was to avoid escape sequences and/or codepage switching.
In other words Unicode characters were supposed to have the
same meaning regardless of neighbouring characters -- note
that when escape seqences are in use you need to scan the whole
string to determine if given character is part of escape
seqence (or it meaning is modified by escape seqence).
So, what is wrong with escape seqences? Well, due to
stateful nature they very much complicate processing. To
get some feel of difficulties you may look at recent
changes to axiom/fricas script. The task was trivial:
get character string from one command line and put it
in another command line. The problem was that on the
way escape seqences where transformed ("expanded") by
shell and we had to effectively undo this transformation.
The resulting code is not very complicated, but went
trough few buggy iterations.
Why the rant above: as I wrote escape seqences are
necessary evil when communicating via limited media,
but should be avoided (at leat logically) during
processing (note that with escape seqences trivial tasks,
like replacing all occurences of substing 'pha' in given
string by some other substring becomes not so trivial).
For processing one should use format which is more or
less free from escape seqences. Unicode seem to be
quite good in this respect. Now, Unicode is not
entirely free from escape seqences, there are so
called combing characters. Moreover UTF-8 uses
multiple octets to encode single Unicode codepoint
and conseqently meaning of given octet in UTF-8
encoded string may depend on previous octets.
However, Unicode (and UTF-8) were specially designed
to avoid various bad effects. For example, the
second octet of multioctet character can not occur
alone: just seeing this octet you know that there
must be octet before belonging to the same character.
Writing "Unicode is done" I meant that it makes no sense to
invent a system of escape seqence to encode special characters
_during processing_. Note: character entities on Web pages
logically are purely input/output mechanizm. Logically when
browser gets a page character entities are replaced by characters.
Then page is parsed to get a tree and all interesting things
happen at the level of parse tree (or above).
Concerning Unicode in Spad: UTF-8 can be used in any 8-bit
clean system. In particular using UTF-8 we can process
Unicode in non-Unicode aware Lisp. And Unicode aware Lisp
by definition can handle Unicode.
There are three problems with this. One is that all
Unicode aware Lisps use UTF-32 encoding which is different
than UTF-8. Conseqently we need different code when
using Unicode aware Lisp compared to non-Unicode aware Lisp.
The second problem is that Lisp typically performs some recoding
on input/output and rejects invalid encodings. This is a problem
because at least theoretically needed encoding may be not
installed. Also, at least clisp does not allow changing
encoding on already open stream, which means that for example
on standard input we are stuck with encoding which was
active when clisp started up. The third problem is that
current Spad character type is 8-bit. This means that
using UTF-32 encoding we currently can not extract characters
from them without risking out-of-range character codes
(but if instead of characters one uses one-character long
strings things should work fine). For UTF-8 8-bit
"characters" would work, but actually they whould not
be Unicode characters but octets.
Bottom line: to use Unicode we need to:
- decide what to do with Spad character type (extending it to
21 bits needed for UTF-32 looks trivial, but there may be
some hidden gotcha). In particular we need to decide if
Spad character correspond to Unicode code point or to
units of encoding (that is octets in case of UTF-8).
- normalize ways of creating Unicode strings/characters. In
particular how to represent them in source code.
One possible way is to declare that we support Unicode only
in Unicode aware Lisps, extend Spad character type to 21 bits
and invent some notation to put Unicode characters in strings
(and maybe identifiers).
> Although this is non-ideal, I can certainly live with this issue (by
> using the hacks that you mentioned and if required I can hack my own
> local copy of html formatter) however I would be quite surprised if I
> am the only one who has wanted to uses non-ascii characters with
> FriCAS. Is there a list of known issues for new users where all these
> workarounds could be put in one place?
>
> Come to think of it, is there a wish-list for FriCAS? I could think of
> a long list, but perhaps I should keep quiet, I suspect you won't
> agree with most of them?
I certainly want to know what wishes other have. As Bill wrote
good place to put them is Axiom wiki.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
>
> Looking at formatting routines I think that there is time for a
> cleanup.
Now I have comited modified version of TEX and TMFORM. Main
change is to use symbols instead of strings when deciding
which kind of Output for we have. In TEX I also changed
operator priorites so that now
summation(operator(f)(i)+1,i=1..n)
gives correct result (this change is similar to what Bill Page
did some time ago).
In TMFORM I did similar changes and removed unused code taken
from MMLFORM. Also, I changed priority handling to be like
in TEX (previous version, taken from MMLFORM had serious problems).
MMLFORM should be changed in similar way, I started this but
it will take few more days to finish.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Jalaluddin Morris
The first thing I would like to say, having struggled with Isabelle for at least a month is that she may be Isabelle NQT - that is "Not Quite There", however despite possibly being NQT, I think that parts of the system have definitely arrived and in particular the way it handles mathematical symbols.
Lifted straight from the website:
What is Isabelle?
Isabelle is a generic proof assistant. It allows mathematical formulas to be expressed in a formal language and provides tools for proving those formulas in a logical calculus. Isabelle is developed at University of Cambridge (Larry Paulson), Technische Universität München (Tobias Nipkow) and Université Paris-Sud (Makarius Wenzel). See the Isabelle overview for a brief introduction.
For main page go to:http://www.cl.cam.ac.uk/research/hvg/Isabelle/
For download, http://www.cl.cam.ac.uk/research/hvg/Isabelle/download.html
Note that the Apple OS 10.5/10.6 install via Isabelle2011.dmg is perhaps easiest, however I also have it running under Fedora 13.
Go to say: /Applications/Isabelle2011.app/Contents/Resources/Isabelle2011/src/HOL/Hahn_Banach
Run the file: Vector_Space.thy
Once Isabelle is running: Proof-General --> Quick Options --> Display --> Unicode Tokens
Change the settings and the display should change as indicated by the attachments.
Regards,
Jalaluddin
Martin Baker
> > I don't quite understand this. Just so that I am completely clear
> > about this, are you saying that SPAD and Lisp can handle Unicode but
> > command line I/O is the only thing preventing this?
>
> Not exactly. First, problem of processing "rich" charcter data
> appeared long ago and various appraches were tried. One worth
> I certainly want to know what wishes other have. As Bill wrote
> good place to put them is Axiom wiki.
hope you don't mind but I have copied this to keep it with a statement
of the issues that I have put here:
http://axiom-wiki.newsynthesis.org/AxiomIssues
Its just that I can never find what I am looking for on forums like
this so I like to try to keep all the information pertaining to each
issue together in one place.
I know its not fair to ask you about timescales, given all the work
you do on this, but it would be nice to get a rough estimate so that I
can judge if there is a requirement for a shorter term hack for
unicode.
Martin
Martin Baker
> In fact, we all know that mathematical notation is not always precise to
> the last bit. Steele shows examples like how to parse:
>
> 3 x sin x cos 2 x log log x (40:00)
>
> We should accept that programming languages can help to make things more
> precise.
fundamentally tree structures (or perhaps directed graphs) so the
problem comes from notating them as linear sequences of characters.
The best way to represent tree structures is XML such as MathML.
I therefore think that the only real answer to this is to store
'source code' as a superset of MathML. Of course users would not want
to work with a low level editors and have to know about tags and so
on. This means that all code editing would be done at a high level
using a WYSIWYG MathML editor.
You might accuse me of mixing up editing and programming issues but I
think I am suggesting the reverse, that is separating the fundamental
structure from the notation.
So at the centre we have the code base stored as a superset of MathML.
On one side of this we have I/O formatters and editors, they know
about various types of bracket, whitespace, prefix, infix or postfix
notation and so on. On the other side are the compilers, interpreters,
they don't need to know about brackets, whitespace, lex analysis,
prefix, infix or postfix notation or anything like that, they just
read the code in a completely unambiguous way. Code completion and
error highlighting tools would also be easier to implement.
BTW - For others - its worth watching the video to get a feel for what
it might look like programming using a more mathematical style of
notation.
Martin Baker
Waldek Hebisch
>
> I know its not fair to ask you about timescales, given all the work
> you do on this, but it would be nice to get a rough estimate so that I
> can judge if there is a requirement for a shorter term hack for
> unicode.
>
Just now using sbcl based FriCAS you can do:
1) start FriCAS in Unicode setting, for example:
(export LC_CTYPE=en_US.UTF-8; fricas)
Make sure your console is set to UTF-8
2) In FriCAS:
new(1, char(8721))$String
You should see sigma sign on the screen. In the same way you
can create any unicode character you want.
What does not work:
1) printing characters (that is easy to fix)
2) functions from CharacterClass. It would be easy to change
CharacterClass so that for ASCII it works as before and
non-ASCII is ignored. Proper support requires getting
database of data about Unicode characters. Adapting
database for FriCAS is easy (IIUC database can be obtained
from Unicode website), but adds bulk (IIUC its is several
megabytes in size). Also, naively extending CharacterClass
to full Unicode is likely to lead to poor performance
(currently CharacterClass uses bitwectors of length 256,
changing that to 1114112 means much bigger bitwectors and
conseqently much more work creating them and poorer
cache utilization).
If we are satisfied with CharacterClass which works correctly
only for ASCII the changes can be done in a day or two. This
may be reasonable because currently CharacterClass is used
only for few internal functions in Character, String and
StringAggregate and the functions are only used with ASCII.
For non-Unicode Lisps we could add function, for example called
'ucodeToString' which given integer produces UTF-8 encoded string
corresponding to given Unicode codepoint. For Unicode Lisps
'ustring' is as simple as:
ucodeToString(c : Integer) : String == new(1, char(c))$String
but for non-Unicode Lisps it is a bit more complicated. Given
'ustring' one can do things like
alpha := ucodeToString(945)::Symbol
alpha^2+1
In principle we could provide domain(s) which would give access
to large number of special symbols via names (I am not sure if
this is really useful).
As I wrote simple-minded Unicode support can be done in few
days. For better support it is hard to give timeline because
once you try to use Unicode you will find that some things
do not work as expected, some things suddenly are extremally
slow and need to be rewritten to get reasonable speed.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Baker
> Just now using sbcl based FriCAS you can do:
>
> 1) start FriCAS in Unicode setting, for example:
>
> (export LC_CTYPE=en_US.UTF-8; fricas)
>
> Make sure your console is set to UTF-8
information specifically about unicode that I have put it together on
a separate page at:
http://axiom-wiki.newsynthesis.org/UnicodeIssues?root=AxiomIssues
and the original page contains a summary of this issue together with
all my other 'wish-list' issues:
http://axiom-wiki.newsynthesis.org/AxiomIssues?root=Axiom%20Problems
I tried this:
new(1, char(8721))$String
and it worked immediately on my OpenSUSE 10.3 computer. I did not need
export LC_CTYPE=en_US.UTF-8 or any changes to the console!
I guess what I need to do is to do some experiments to see if I can
read and write unicode strings to/from the console and files using
various combinations of interpreter and compiled code.
It would be good if you can do some of the easier things before the
next release of FriCAS, then I can do some more experiments after you
release it (I'm assuming the next release may not be far away?).
> In principle we could provide domain(s) which would give access
> to large number of special symbols via names (I am not sure if
> this is really useful).
characters in string literals provided that the source file is UTF-8.
For inputting unicode into the interpreter via the console are there
any programs already existing that could provided a virtual keyboard
for special character sets? Otherwise I guess unicode characters can
always be entered by their numerical value. If the symbol name are
still required for the various file formats and if their designation
happens to be the same, there may be some benefit in a common table?
Martin Baker
Waldek Hebisch
>
> I tried this:
> new(1, char(8721))$String
>
> and it worked immediately on my OpenSUSE 10.3 computer. I did not need
> export LC_CTYPE=en_US.UTF-8 or any changes to the console!
>
> I guess what I need to do is to do some experiments to see if I can
> read and write unicode strings to/from the console and files using
> various combinations of interpreter and compiled code.
>
> It would be good if you can do some of the easier things before the
> next release of FriCAS, then I can do some more experiments after you
> release it (I'm assuming the next release may not be far away?).
>
See patch in other post. I plan to commit it or a better
version (it is likely that more issues will show up).
> > In principle we could provide domain(s) which would give access
> > to large number of special symbols via names (I am not sure if
> > this is really useful).
>
> Presumably (I haven't tried it yet) the compiler could read unicode
> characters in string literals provided that the source file is UTF-8.
> For inputting unicode into the interpreter via the console are there
> any programs already existing that could provided a virtual keyboard
> for special character sets? Otherwise I guess unicode characters can
> always be entered by their numerical value. If the symbol name are
> still required for the various file formats and if their designation
> happens to be the same, there may be some benefit in a common table?
UTF-8 strings probably work in Spad compiler, but there are several
places where tables with entry for each character are in use.
Currently such tables have 256 entries -- we need to find places
using them and fix to allow bigger character codes -- otherwise
we will get runtime errors when Unicode characters get into
unexpected places.
On Linux consoles Unicode was supported for many years: on text
console loadkeys program allows to load new keyboard map and
such map may designate various characters as modifiers. In
Xwindows similar capability is available via xkbd extension.
--
Waldek Hebisch
heb...@math.uni.wroc.pl