problem with TeXmacs interface

[Kostas Oikonomou]

Something that has to do with Greek symbols seems to have changed with
FriCAS 1.3.6 and TeXmacs.
Please see the attached files: TeXmacs session "bug.tm" and the PDF
version "bug.pdf".

Any help would be appreciated.

                        Kostas

[Kostas Oikonomou]

I just found out that what I previously reported as a problem with the TeXmacs interface also occurs
in "plain" FriCAS:

$ fricas
Checking for foreign routines
FRICAS="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.1"
spad-lib="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.1/lib/libspad.so"
foreign routines found
openServer result 0
                       FriCAS Computer Algebra System
                            Version: FriCAS 1.3.6
                   Timestamp: Sat Jul 11 03:10:07 UTC 2020
-----------------------------------------------------------------------------
   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) -> f(x) == c*x^2
                                                                   Type: Void
(2) ->f(α))
  Line   1: f(α)
           .A.BC
  Error  A: Missing mate.
  Error  B: syntax error at top level
  Error  B: Possibly missing a )
  Error  C: The character #\PLUS-MINUS_SIGN is not an FriCAS character.
   4 error(s) parsing


Note that the double right parentheses on line (2) are not a typing error by me, but are somehow
echoed back by the system itself when I type 'f(α)'.

[Ralf Hemmecke]

Hello Kostas,

thanks for reporting.

I simply typed one α and FriCAS is showing a double α on the input line.
Strange.

(3) ->αα

(3) α
Type: Variable(α)

But I cannot confirm your second problem.


(7) -> f(x)==c*x^2
Type: Void
(8) ->f(α))
Compiling function f with type Variable(α) -> Polynomial(Integer)

2
(8) c α
Type: Polynomial(Integer)

So there is somehow a problem with printing unicode characters, but on
the INPUT not OUTPUT line. Still strange, but I don't yet know where the
input is REPRINTED.

Ralf

PS: Oh I am working with

(9) -> )version

Value = "FriCAS 99b0ed3ba53afbba57169283e803b2009020047d compiled at Sun
Oct 4 17:43:38 CEST 2020"

So maybe your problem appears in 1.3.6, but not in the current master
branch.

Ralf

[Kostas Oikonomou]

Hi Ralf,

Thanks for responding.  It may be that the master branch fixes (part) of
the problem.
Meanwhile I reverted to 1.3.5, which has this behavior:

(1) -> f(x) == c*x^2
Type: Void

(2) ->f(α))

   Compiling function f with type Variable(α) -> Polynomial(Integer)

              2

   (2)  c α
                                                    Type:
Polynomial(Integer)
(3) -αα

   (3)  α
                                                           Type:
Variable(α)


                            Kostas

[Bill Page]

Try starting fricas like this:

$ fricas -noclef

Doing this avoids the command line problem for me.

"clef" is the old Axiom alternative to readline and is still used by default. Of course without clef (and without building FriCAS especially to support readline) you lose the usual command line editing.

I am not sure if the TeXmacs interface already avoids using clef or not. If not then I think it should. I vaguely recall that it used to use the -nosman option which also implies -noclef and -noht. Sorry, I don't have TeXmacs installed on this desktop system any more or I would try it.

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/7a67572d-fe20-4fd1-c15a-50ac605f7e11%40gmail.com.

[Ralf Hemmecke]

On 10/22/20 8:39 PM, Bill Page wrote:
> Try starting fricas like this:
>
> $ fricas -noclef
>
> Doing this avoids the command line problem for me.

Indeed. CLEF is the problem.

Just edit your fricas script. Edit the one in your PATH if you do not
want to recompile fricas.

> "clef" is the old Axiom alternative to readline and is still used by
> default. Of course without clef (and without building FriCAS especially to
> support readline) you lose the usual command line editing.

But in the master branch is now the -rl option. If you have rlwrap
installed on your computer, then "fricas -rl" will choose readline
instead of clef and you have full editing features.

> I am not sure if the TeXmacs interface already avoids using clef or not. If
> not then I think it should. I vaguely recall that it used to use the
> -nosman option which also implies -noclef and -noht. Sorry, I don't have
> TeXmacs installed on this desktop system any more or I would try it.

It doesn't use -nosman, but basically it does, because it calls
FRICASsys directly. But I am not sure whether that actually means that
it doesn't use clef.

https://github.com/fricas/fricas/blob/master/src/etc/fricas#L102

Anyway, maybe replacing

if [ "$*" = "-texmacs" ] ; then
exec "$FRICAS/bin/FRICASsys" -- -eval "$algebra_off" -eval
"$markers" -eval "$texmacs_on"
fi

by

if [ "$*" = "-texmacs" ] ; then
exec "rlwrap $FRICAS/bin/FRICASsys" -- -eval "$algebra_off" -eval
"$markers" -eval "$texmacs_on"
fi

just works. (I haven't tested that!)

Ralf

[Bill Page]

On Thu, Oct 22, 2020 at 3:19 PM Ralf Hemmecke <ra...@hemmecke.org> wrote:
>
> It doesn't use -nosman, but basically it does, because it calls
> FRICASsys directly. But I am not sure whether that actually
> means that it doesn't use clef.
>

In that case it definitely does not use clef.

>
> https://github.com/fricas/fricas/blob/master/src/etc/fricas#L102
>
> Anyway, maybe replacing
>
> if [ "$*" = "-texmacs" ] ; then
> exec "$FRICAS/bin/FRICASsys" -- -eval "$algebra_off" -eval
> "$markers" -eval "$texmacs_on"
> fi
>
> by
>
> if [ "$*" = "-texmacs" ] ; then
> exec "rlwrap $FRICAS/bin/FRICASsys" -- -eval "$algebra_off" -eval
> "$markers" -eval "$texmacs_on"
> fi
>
> just works. (I haven't tested that!)

I do not see why texmacs would require readline for the interface with fricas.

[Ralf Hemmecke]

>> if [ "$*" = "-texmacs" ] ; then
>> exec "rlwrap $FRICAS/bin/FRICASsys" -- -eval "$algebra_off" -eval
>> "$markers" -eval "$texmacs_on"
>> fi
>>
>> just works. (I haven't tested that!)
>
> I do not see why texmacs would require readline for the interface with fricas.

True. Why did I do that? Should have said that just calling wrapping
with rlwrap for running fricas in the console.

Sorry.

Ralf

[Kostas Oikonomou]

Thank you Bill and Ralph.
Ok, I went back to 1.3.6.  But I still see a problem:

$ fricas -noclef

Checking for foreign routines
FRICAS="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.1"
spad-lib="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.1/lib/libspad.so"
foreign routines found
openServer result 0
                       FriCAS Computer Algebra System
                            Version: FriCAS 1.3.6
                   Timestamp: Sat Jul 11 03:10:07 UTC 2020
-----------------------------------------------------------------------------
   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) -> α
  Line   1: α
           .AB
  Error  A: Improper syntax.
  Error  B: The character #\PLUS-MINUS_SIGN is not an FriCAS character.
   2 error(s) parsing

(1) ->

Bill, are you using 1.3.6?

I also tried

fricas -clefprog rlwrap

but this never even prints out a prompt.

                        Kostas

[Bill Page]

I am now using fricas built from git master today

(1) -> )version
Value = "FriCAS 2020-04-23 compiled at Thu Oct 22 20:23:50 EDT 2020"

I also tried fricas with the -rl option as suggested by Ralf. After
installing the rlwrap program

wspage@desktop:~$ rlwrap --version
rlwrap 0.43

$ fricas -rl

worked perfectly for me - including command line editing with Greek characters.

I am running Linux Mint 18.3 on my desktop.

You might want to check the locale setting on your computer. I have

$ wspage@desktop:~$ locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC="en_CA.UTF-8"
LC_TIME="en_CA.UTF-8"
LC_COLLATE="en_CA.UTF-8"
LC_MONETARY="en_CA.UTF-8"
LC_MESSAGES="en_CA.UTF-8"
LC_PAPER="en_CA.UTF-8"
LC_NAME="en_CA.UTF-8"
LC_ADDRESS="en_CA.UTF-8"
LC_TELEPHONE="en_CA.UTF-8"
LC_MEASUREMENT="en_CA.UTF-8"
LC_IDENTIFICATION="en_CA.UTF-8"
LC_ALL=

You should probably have something similar regarding UTF-8 but
probably different language.

Bill.

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/7c3f7917-0c42-8b2c-9054-0e1f22948276%40gmail.com.

[Ralf Hemmecke]

> fricas -clefprog rlwrap

That is not enough.

See
https://github.com/fricas/fricas/commit/6fb0bbadfe376c05cce3c9cdd98606259b1f1b05

and the two followup fixing commits. In particular the script
fricas-readline is needed.

Ralf

[Dima Pasechnik]

clef (it probably pre-dates Unicode!) should have been removed from
Fricas years ago
- but it seems that preference is for drowning in technical debt here. :-)

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/7c3f7917-0c42-8b2c-9054-0e1f22948276%40gmail.com.

[Ralf Hemmecke]

On 10/23/20 9:50 AM, Dima Pasechnik wrote:
> clef (it probably pre-dates Unicode!) should have been removed from
> Fricas years ago
> - but it seems that preference is for drowning in technical debt here. :-)

Unfortunately if FriCAS stays under BSD license, it cannot use use
readline as ist is GPL. Anyway, we have enough good interfaces, emacs,
jfricas, texmacx, that I would just dump that clef code and free us from
legacy.

It would be easy for any user to just type "fricas -rl" and get readline
support with very little friction on his/her side.

Waldek, what about removing CLEF?

Ralf

[Dima Pasechnik]

On Fri, 23 Oct 2020, 16:12 Ralf Hemmecke, <ra...@hemmecke.org> wrote:

On 10/23/20 9:50 AM, Dima Pasechnik wrote:
> clef (it probably pre-dates Unicode!) should have been removed from
> Fricas years ago
> - but it seems that preference is for drowning in technical debt here. :-)

Unfortunately if FriCAS stays under BSD license, it cannot use use
readline as ist is GPL.

this is a very hardline licensing view, IMHO.

Anyway, libedit, a Netbsd implementation of most of readline, is under BSD, and is probably enough 

Anyway, we have enough good interfaces, emacs,
jfricas, texmacx, that I would just dump that clef code and free us from
legacy.

It would be easy for any user to just type "fricas -rl" and get readline
support with very little friction on his/her side.

Waldek, what about removing CLEF?

Ralf

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/47cf1fbd-6585-2cd7-f30b-2e9df8cb37ce%40hemmecke.org.

[Kostas Oikonomou]

Hello Bill (and Ralph)

I just built FriCAS from git.  The problem is still there:

[ko@wiley ~]$ /opt/fricas/bin/fricas -rl
Checking for foreign routines
FRICAS="/opt/fricas/lib/fricas/target/x86_64-x-freebsd12.1"
spad-lib="/opt/fricas/lib/fricas/target/x86_64-x-freebsd12.1/lib/libspad.so"

foreign routines found
openServer result 0
                       FriCAS Computer Algebra System

                         Version: FriCAS 2020-04-23
                   Timestamp: Fri Oct 23 17:34:26 EDT 2020

-----------------------------------------------------------------------------
   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) -> )version
Value = "FriCAS 2020-04-23 compiled at Fri Oct 23 17:34:26 EDT 2020"

(1) -> α
  Line   1: α
           .AB
  Error  A: Improper syntax.

  Error  B: The character #\PLUS-MINUS_SIGN is not a FriCAS character.
   2 error(s) parsing

(1) -> )quit


[ko@wiley ~]$ rlwrap --version
rlwrap 0.42
[ko@wiley ~]$

Same behavior with -noclef.

Finally,

[ko@wiley ~]$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=


How do you actually type the 'α'?   I switch my keyboard to Greek layout.

It still seems to me that the cause is something that changed between
1.3.5 and 1.3.6:

[ko@wiley ~]$ fricas
Checking for foreign routines
AXIOM="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.0"
spad-lib="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.0/lib/libspad.so"

foreign routines found
openServer result 0
                       FriCAS Computer Algebra System

                            Version: FriCAS 1.3.5
                   Timestamp: Fri Oct 25 10:22:54 UTC 2019

-----------------------------------------------------------------------------
   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) ->αα

   (1)  α
                                                            Type:
Variable(α)
(2) ->


                                            Kostas

On 10/22/20 8:46 PM, Bill Page wrote:
> rlwrap --version

[Bill Page]

On Fri, Oct 23, 2020 at 6:20 PM Kostas Oikonomou
<kostas.oi...@gmail.com> wrote:

> ...

> How do you actually type the 'α'? I switch my keyboard to Greek layout.
>

I just cut-and-paste from the email. I also use a desktop app called
"Character Map" which is more general but more awkward.

Can I assume that you successfully use Greek with other applications?
E.g. In the system text editor?

Maybe the actual version of Linux that you are using is relevant?

Sorry that I can't be much more help.

[Dima Pasechnik]

On Fri, Oct 23, 2020 at 4:12 PM Ralf Hemmecke <ra...@hemmecke.org> wrote:
>
> On 10/23/20 9:50 AM, Dima Pasechnik wrote:
> > clef (it probably pre-dates Unicode!) should have been removed from
> > Fricas years ago
> > - but it seems that preference is for drowning in technical debt here. :-)
>
> Unfortunately if FriCAS stays under BSD license, it cannot use use
> readline as ist is GPL.

PS. Python (cpython) happily links readline, and is distributed under
a GPL-compatible license, but not under GPL
https://docs.python.org/3/license.html
(which is a modified BSD license, just as your
https://github.com/fricas/fricas/blob/master/license/LICENSE.AXIOM -
which, I think, is a "3-clause BSD license", thus GPL-compatible, too).
Do you have a reason not to follow their example?

> Anyway, we have enough good interfaces, emacs,
> jfricas, texmacx, that I would just dump that clef code and free us from
> legacy.
>
> It would be easy for any user to just type "fricas -rl" and get readline
> support with very little friction on his/her side.
>
> Waldek, what about removing CLEF?
>
> Ralf
>

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/47cf1fbd-6585-2cd7-f30b-2e9df8cb37ce%40hemmecke.org.

[Kostas Oikonomou]

Yes, Greek works fine with many other applications, e.g. emacs.  Or
shell windows.  Or LibreOffice, Thunderbird, etc.
I am not running Linux, but FreeBSD (you can see what FriCAS reports
when it starts.)

[Andrey G. Grozin]

On Fri, 23 Oct 2020, Dima Pasechnik wrote:
> Unfortunately if FriCAS stays under BSD license, it cannot use use
> readline as ist is GPL.
> this is a very hardline licensing view, IMHO.

RMS has forced the original author of clisp (don't remember his name) to
switch the license of clisp to GPL.

> Anyway, libedit, a Netbsd implementation of most of readline, is under BSD, and is probably enough 

Yes, libedit should be sufficient.

Andrey

[Ralf Hemmecke]

>> Unfortunately if FriCAS stays under BSD license, it cannot use use
>> readline as ist is GPL.
>
> PS. Python (cpython) happily links readline, and is distributed under
> a GPL-compatible license, but not under GPL
> https://docs.python.org/3/license.html
> (which is a modified BSD license, just as your
> https://github.com/fricas/fricas/blob/master/license/LICENSE.AXIOM -
> which, I think, is a "3-clause BSD license", thus GPL-compatible, too).

Personally, I would have nothing against distributing FriCAS under GPL.

In my understanding of the GPL, you have to distribute the sources under
GPL if you like against GPL software. In other words, if readline is
used, then together with the BINARY distribution, there must be a GPL'd
source distribution of FriCAS.

Of course, that still allows to distribute FriCAS under the licese as we
have it now. It just needs to be GPL-compatible, which it is.

> Do you have a reason not to follow their example?

I don't exactly see where and how (c)python uses readline, but a binary
distribution must then be under GPL.

As far as I understand, the situation in FriCAS is much simpler. In the
same way as "fricas -rl" calls rlwrap, a FriCAS binary distribution
could include rlwrap (as a separate program undert GPL) and be itself
(without this readline stuff) under mBSD. As far as I currently
understand, sman just calls an external program "clef"

https://github.com/fricas/fricas/blob/master/src/sman/sman.c#L74
https://github.com/fricas/fricas/blob/master/src/sman/sman.c#L183

so if this is generally replaced by readline, there is absolutely no
danger for other parts of FriCAS, but only a gain for users.

Anyone who wants to provide a patch?

Ralf

[Kurt Pagani]

FreeBSD migt be tricky regarding to UTF-8. Apparently "alpha" appears as
U+00B1 (PLUS-MINUS SIGN) in FriCAS. There must be some mismatch. Perhaps
setting LC_COLLATE=C will help?

"""
FreeBSD, like many UNIX-based operating systems, is unfortunately not configured
to use UTF-8 by default. This sometimes causes confusion about whether Unicode
is supported on FreeBSD. Fortunately, it is easy to enable UTF-8 on FreeBSD.
"""

Consult:
https://www.b1c1l1.com/blog/2011/05/09/using-utf-8-unicode-on-freebsd/




---

FriCAS Computer Algebra System
Version: FriCAS 1.3.5

Timestamp: Mi, 17. Apr 2019 03:15:11

-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------

Function declaration sixel : TexFormat -> Void has been added to
workspace.
Type: Void
Function declaration quickLoad : String -> Void has been added to
workspace.
Type: Void

Type: Variable(alpha)
(1) -> α

(1) α

[Waldek Hebisch]

On Thu, Oct 22, 2020 at 07:05:37AM -0700, Kostas Oikonomou wrote:
> I just found out that what I previously reported as a problem with the
> TeXmacs interface also occurs
> in "plain" FriCAS:
>
> $ fricas
> Checking for foreign routines
> FRICAS="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.1"
> spad-lib="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.1/lib/libspad.so"
> foreign routines found
> openServer result 0
> FriCAS Computer Algebra System
> Version: FriCAS 1.3.6
> Timestamp: Sat Jul 11 03:10:07 UTC 2020
> -----------------------------------------------------------------------------
> 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) -> f(x) == c*x^2
> Type:
> Void

> (2) ->f(??))
> Line 1: f(??)

> .A.BC
> Error A: Missing mate.
> Error B: syntax error at top level
> Error B: Possibly missing a )
> Error C: The character #\PLUS-MINUS_SIGN is not an FriCAS character.
> 4 error(s) parsing
>
>
> Note that the double right parentheses on line (2) are not a typing error
> by me, but are somehow

> echoed back by the system itself when I type 'f(??)'.

You did not include most important information: which Lisp do you
use to compile FriCAS? AFAICS relevant code in FriCAS 1.3.5 and
1.3.6 is the same. But important part is done by Lisp and if
Lisp used to compile FriCAS does not support Unicode, then
what you see is expected.

--
Waldek Hebisch

[Kostas Oikonomou]

Hi Kurt,

I tried your suggestion, no difference.  My locale is set to
"en_US.UTF-8", as I posted earlier.
In any case, FreeBSD is fully "internationalized", has been so for a
while. See

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/l10n.html

I don't know what the issue is, but it seems like a difference between
1.3.5 and 1.3.6.

                            Kostas

[Kostas Oikonomou]

Sorry, I neglected to specify that.  Both 1.3.5 and 1.3.6 are built with

[ko@wiley ~]$ sbcl --version
SBCL 2.0.6
[ko@wiley ~]$

[Kurt Pagani]

Hi Kostas

> I tried your suggestion, no difference.

Well, a pity :(

I guess Waldek is on the right track. Can you confirm the lines below in your
envirnoment?

(3) -> )lisp (code-char 945)

Value = #\GREEK_SMALL_LETTER_ALPHA
(3) -> )lisp (code-char 177)

Value = #\PLUS-MINUS_SIGN
(3) -> )lisp

(3) -> )lisp (format t "~a" (code-char 177))
±
Value = NIL
(3) -> )lisp (format t "~a" (code-char 945))
α
Value = NIL
(3) ->

[Waldek Hebisch]

On Sat, Oct 24, 2020 at 06:41:25PM -0400, Kostas Oikonomou wrote:
> Sorry, I neglected to specify that.=C2=A0 Both 1.3.5 and 1.3.6 are built wi=

> th
>
> [ko@wiley ~]$ sbcl --version
> SBCL 2.0.6
> [ko@wiley ~]$
>

Good. Could you try command from attached Lisp file in sbcl.
And the same preceded by

)lisp

on FriCAS command line? Please start FriCAS using -nosman option
(this case is relevant to Texmacs). Correct result is:

#\GREEK_SMALL_LETTER_ALPHA

Also, to check output, please try in FriCAS:

ucodeToString(945)

That should print string consisting just of smallcase Greek alpha.

--
Waldek Hebisch

[Kostas Oikonomou]

With fricas 1.3.5:

(1) -> )lisp  (code-char 945)
Value = #\GREEK_SMALL_LETTER_ALPHA
(1) -> )lisp  (code-char 177)

Value = #\PLUS-MINUS_SIGN
(1) -> )lisp (format t "~a" (code-char 177))
±
Value = NIL
(1) -> )lisp (format t "~a" (code-char 945))
α
Value = NIL
(1) ->

With fricas 1.3.6:

(1) -> )lisp  (code-char 945)
Value = #\GREEK_SMALL_LETTER_ALPHA
(1) -> )lisp  (code-char 177)

Value = #\PLUS-MINUS_SIGN
(1) -> )lisp (format t "~a" (code-char 177))
�
Value = NIL
(1) -> )lisp (format t "~a" (code-char 945))
?
Value = NIL
(1) ->

[Waldek Hebisch]

On Sun, Oct 25, 2020 at 06:56:36PM -0400, Kostas Oikonomou wrote:
> [ko@wiley ~]$ sbcl
> This is SBCL 2.0.6, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses.?? See the CREDITS and COPYING files in the
> distribution for more information.
> ;;; loading #P"/usr/local/lib/sbcl/asdf/asdf.lisp"
> * (aref "??" 0)
> #\GREEK_SMALL_LETTER_ALPHA
> *
>
>
> And now FriCAS:
>
>
> ko@wiley ~]$ fricas

> Checking for foreign routines
> FRICAS="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.1"
> spad-lib="/usr/local/lib/fricas/target/amd64-portbld-freebsd12.1/lib/libspad.so"
> foreign routines found
> openServer result 0

> ???????????????????????????????????????????? FriCAS Computer Algebra System
> ?????????????????????????????????????????????????????? Version: FriCAS 1.3.6
> ???????????????????????????????????? Timestamp: Sat Jul 11 03:10:07 UTC 2020
> -----------------------------------------------------------------------------
> ???? 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 (aref "??" 0))
> Value = #\LATIN_CAPITAL_LETTER_I_WITH_CIRCUMFLEX
> (1) ->

That is strong indication that sbcl used to build FriCAS either
does not support Unicode or rather have its Unicode support
turned off. To clarfy: FriCAS uses Lisp function 'read-line'
to read input line. If line begins with ')lisp ' to rest is
passed to Lisp. When you interact with sbcl the first step
is equivalent to 'read-line'. So both test are supposed to
produce the same result (and they do on my machine, using
slightly different sbcl version). Actually, the character
above has code 206 which is the first byte of UTF-8
encoding of smallcase alpha. So clearly Lisp used by
FriCAS for some reason is switched to work in single-byte
mode.

So the problem seem to be mostly with sbcl and Free BSD.
FriCAS just uses what is provided by sbcl. My understanding
is that actually FriCAS has no way to influence it, sbcl
chooses mode for standard input before FriCAS can do
anything and does not allow changing mode afterwords.

One can try to find out when exactly problem is introduced.
Your test indicate that sbcl alone works in Unicode mode.
As first step FriCAS creates copy of sbcl whith a
bunch of useful routines. If you keep build tree
(worth doing when testing) there should be
subdrectory like

build/x86_64-freebsd/bin/

(on my Linux machine it is build/x86_64-linux-gnu/bin/).
In this directory there are 3 exacutables. One, called
'lisp' is above mentioned copy of sbcl. You should be
able to run it like sbcl and it should behave almost
the same (the difference is where it looks for files,
but built-in thing should be exactly the same). The
secodn one is 'bootsys'. It has more routines loaded
but still should give the same results as sbcl.
If alredy 'lisp' can not handle Unicode (meaning
the sigle line test I gave), then this would
significantly narrow down the problem

P.S. Please keep info on the mailing list.

--
Waldek Hebisch

[Kostas Oikonomou]

Hello Waldek,

Thank you for the informative reply.

Here is what happens with the "copy" of sbcl that fricas makes:

[ko@wiley ~/build/ax-build/build/x86_64-x-freebsd12.1/bin]$ lisp
* (aref "α" 0)
#\LATIN_CAPITAL_LETTER_I_WITH_CIRCUMFLEX
*


I also see that the system sbcl (i.e. the one I install using a system
binary package, similar to a Linux .rpm I would think) is a
significantly smaller file:

[ko@wiley ~]$ ll /usr/local/bin/sbcl
-rwxr-xr-x  1 root  wheel  289880 Jul  9 15:29 /usr/local/bin/sbcl
[ko@wiley ~]$ file /usr/local/bin/sbcl
/usr/local/bin/sbcl: ELF 64-bit LSB executable, x86-64, version 1
(FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for
FreeBSD 12.1, FreeBSD-style, stripped
[ko@wiley ~]$

Whereas the fricas sbcl is:

[ko@wiley ~/build/ax-build/build/x86_64-x-freebsd12.1/bin]$ ll lisp
-rwxr-xr-x  1 ko  ko  36608992 Oct 23 17:34 lisp
[ko@wiley ~/build/ax-build/build/x86_64-x-freebsd12.1/bin]$ file lisp
lisp: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.1,
FreeBSD-style, stripped
[ko@wiley ~/build/ax-build/build/x86_64-x-freebsd12.1/bin]$


                        Kostas

[Waldek Hebisch]

On Sun, Oct 25, 2020 at 11:02:42PM -0400, Kostas Oikonomou wrote:
>
> Here is what happens with the "copy" of sbcl that fricas makes:
>
> [ko@wiley ~/build/ax-build/build/x86_64-x-freebsd12.1/bin]$ lisp

> * (aref "=CE=B1" 0)
> #\LATIN_CAPITAL_LETTER_I_WITH_CIRCUMFLEX
> *

AFAICS we now can say that this is change in sbcl. When
I use sbcl 1.2.4 Unicode works as expected. When I use
sbcl 2.0.9 I see result as above.

> I also see that the system sbcl (i.e. the one I install using a system=20
> binary package, similar to a Linux .rpm I would think) is a=20
> significantly smaller file:

That is normal: system sbcl keeps almost all code in a separate
("core") file and what you see is small loader program. 'lisp'
is created as self-contained executable and all code is in
a single file. Putting things in single file need the same
disc space as separate core, but is much easier to invoke.

--
Waldek Hebisch

[Kurt Pagani]

We seemingly have to blame SBCL. The changelog reveals a change in 2.0.3 related
to UTF, so it might be the case that < 2.0.3 will work for you, although I have
no clue why it should - merely based on the description below.

"""
New in version 2.0.3

incompatible change: the external format now defaults to UTF-8 and is not
affected by LANG. SB-EXT:*DEFAULT-EXTERNAL-FORMAT* is now the only way to change
it.
"""

Unfortunately I have no SBCL >= 2.x in use yet. Let us know if you get new
insights.

[Waldek Hebisch]

On Mon, Oct 26, 2020 at 12:39:34PM +0100, Waldek Hebisch wrote:
> On Sun, Oct 25, 2020 at 11:02:42PM -0400, Kostas Oikonomou wrote:
> >
> > Here is what happens with the "copy" of sbcl that fricas makes:
> >
> > [ko@wiley ~/build/ax-build/build/x86_64-x-freebsd12.1/bin]$ lisp
> > * (aref "=CE=B1" 0)
> > #\LATIN_CAPITAL_LETTER_I_WITH_CIRCUMFLEX
> > *
>
> AFAICS we now can say that this is change in sbcl. When
> I use sbcl 1.2.4 Unicode works as expected. When I use
> sbcl 2.0.9 I see result as above.

Before Unicode support in FriCAS I tried to switch sbcl
to 8-bit clean mode. That did not work at that time,
but code remained in the repository. Recent change
in sbcl made this code active and switched FriCAS
to 8-bit mode. I have now removed this old code,
this should fix the problem.

--
Waldek Hebisch

[Kostas Oikonomou]

Thanks to everyone who helped resolve this problem.

As an aside, if anyone wants to try the latest TeXmacs, there are
*static* binaries for Linux
now available, which should make the installation painless:

http://www.texmacs.org/tmweb/download/linux.en.html

(There seem to be static binaries for MacOS and Windows as well.)

                        Kostas

[Bill Page]

Kostas,

Thank you for the link to the updated Linux binaries for TeXmacs.
After some initial testing I think things seem to have improved
significantly since the last time I used TeXmacs and FriCAS together a
few years ago. TeXmacs seems more reliable and more responsive than it
did back then. I had no problem accessing FriCAS immediately after
installing TeXmacs and Greek characters and other special symbols
worked as expected. I will probably try using this combination for my
next FriCAS project.

I have a couple of questions. Do you also use TeXmacs to edit SPAD
code? If so, do you have any "best practices" advice about editing,
compiling and running custom SPAD code in this environment? Second, is
there some way to embed FriCAS-generated graphics/plots into TeXmacs
documents?

Maybe this is a good time to put a little more emphasis on this
alternative user interface for FriCAS.

Bill Page.

[Kostas Oikonomou]

Hi Bill,

Yes, TeXmacs has made huge progress over the last few years, and is
continuing to do so.
Just as one example, the Fricas interface typesets the integral on p. 66
of the Fricas book with
very nice line breaking.

To answer your questions, I am not a very sophisticated Fricas user, so
I don't write SPAD code.
But, more importantly, TeXmacs is not really a programmer's editor like
Emacs. It is an editor for
scientific (technical) documents.  (Nevertheless, it knows how to
typeset fragments of many programming
languages so they look good when included in a document. By "programming
languages" we also mean
computer algebra systems.)  So for writing SPAD code I would use Emacs,
or some other IDE, if you prefer.

With respect to including graphics in a document, there is a
sophisticated interface that handles eps, pdf, png.
You can access it by the button with the picture of a tree in the second
row of the buttons at the top of the window.
To understand it in detail, the TeXmacs help system is very good, like
that of Emacs.  E.g., Help -> Search -> Documentation, and then typing
"picture" gives a number of hits, the relevant one being "inserting images".

Even better, if you are not adverse to reading manuals, the full TeXmacs
manual in PDF is an excellent source:

http://www.texmacs.org/tmweb/help/learn.en.html

This contains all of the material in the "Help" menu in one document.
For images, see sec. 5.2.

                        Kostas

[Bill Page]

On Wed, Oct 28, 2020 at 11:56 AM Kostas Oikonomou
<kostas.oi...@gmail.com> wrote:
>
> To answer your questions, I am not a very sophisticated Fricas
> user, so I don't write SPAD code.

:) Well, you are already using FriCAS so I would say that you are
rather sophisticated!

The SPAD compiler is frustrating by modern standards but the language
itself is quite straightforward, albeit a bit overly pedantic,
compared to the interpreter. I think most people could easily learn to
program in SPAD from a few basic examples.

> But, more importantly, TeXmacs is not really a programmer's editor
> like Emacs. It is an editor for scientific (technical) documents.

What I had in mind is perhaps little like the literate programming
ideal that was promulgated by the original Axiom parent project (and
still in use there). I never liked the idea much when it came to
maintaining existing Axiom system code but it still makes sense to me
in the case of the activity of scientific application programming
itself.

> (Nevertheless, it knows how to typeset fragments of many
> programming languages so they look good when included in
> a document. By "programming languages" we also mean
> computer algebra systems.)

I agree.

> So for writing SPAD code I would use Emacs, or some other
> IDE, if you prefer.

Wel, OK. There are valid arguments however that code and
documentation really belong together, especially in the case of
research.

What I had in mind perhaps could be done in TeXmacs by inventing a new
FriCAS session type just for the compiler. The main difference would
be that the contents of a SPAD session would be compiled instead of
being interpreted.

>
> With respect to including graphics in a document, there
> is a sophisticated interface that handles eps, pdf, png.
> You can access it by the button with the picture of a tree
> in the second row of the buttons at the top of the window.

Hmm, FriCAS does have some preliminary support for the generation of
GNUplot input data. I wonder if that could be used together with the
GNU plot plugin for TeXmacs - or some other similar graphics plugin?

I think Kurt and Ralf are/were thinking of something like this for the
FriCAS Jupyter interface.

Bill Page.

[Kurt Pagani]

Hi Bill

On 29.10.2020 00:00, Bill Page wrote:
>
> Hmm, FriCAS does have some preliminary support for the generation of
> GNUplot input data. I wonder if that could be used together with the
> GNU plot plugin for TeXmacs - or some other similar graphics plugin?

Indeed, your GnuDraw works fine.
https://fricas.github.io/api/GnuDraw.html?highlight=gnudraw

It seems to be the only method at the moment (besides the built-in "draw") that
can reliably produce graphics using fricas data. It is easy to use it in
TeXmacs. One has to define a small function which calls gnuplot and inserts the
picture into TM (there is a package TexmacsSupport @
https://github.com/nilqed/spadlib/tree/master/tmspt (file src/tmspt.spad) which
may help to show how it might go (see test_gnudraw.pdf), i.e. one has to combine
the commands into a
function ...


(1) -> )system gnuplot -e 'set terminal dumb; plot x**2'


100 +--------------------------------------------------------------------+
|* + + + *|
90 |** x**2 ********|
| * * |
80 |-+* *+-|
| ** ** |
70 |-+ * * +-|
| ** ** |
60 |-+ * * +-|
| ** ** |
50 |-+ * * +-|
| ** ** |
40 |-+ * * +-|
| ** ** |
30 |-+ ** ** +-|
| ** ** |
20 |-+ ** ** +-|
| *** *** |
10 |-+ *** *** +-|
| + ***** + ***** + |
0 +--------------------------------------------------------------------+
-10 -5 0 5 10



Also works as SIXEL (https://github.com/nilqed/latex2sixel).
https://nilqed.github.io/drawfe/

Probably the Gnuplot plugin of TeXmacs could be called from within the fricas
plugin (the scheme commands are known), however, it seems more simple to me
using GnuDraw and insert produced png/ps or whatever than using another plugin.

>
> I think Kurt and Ralf are/were thinking of something like this for the
> FriCAS Jupyter interface.

We were (actually still are), but Ralf thought, it's better to start without
graphics in the first release. He's certainly right, as there still is the agony
of choice and lack of a reliable link to produce data from fricas objects.

Actually there wss Gnuplot in an earlier prototype (HTML5 canvas):
https://nilqed.github.io/jfricas.pip/sphinx/_build/html/gnuplot.html

Then we used matplotlib (like in SAGE, sample: att. ipysh_and_mplot.html)

My favourite still is GLE (BSD, c code, only QGLE is LGPL). Provides really HQ
(eps,pdf,...), or LaTeX/PGF/TikZ (GeoGebra, for instance, can export PGF).

https://kfp.bitbucket.io/tmp/GLE.html

You see, there are a lot of prototypes in the pipeline, however, without an
initial impetus/decision which system to use (lcd) it might take ages ...


BTW, I also find the "draw commands" not very flexible. It would be easy to
slightly modify the draw and view2/3.spad files (as I did 4y ago according
github;) in order to use one of the plot packages mentioned, but then you're
sticked to those few methods/parameters. IMO a free format like )gnuplot or
)mplot should be used if one needs more than a toy.
https://github.com/nilqed/fricas_input/tree/master/spad/draw


>
> Bill Page.
>

[Ralf Hemmecke]

> BTW, I also find the "draw commands" not very flexible. It would be easy to
> slightly modify the draw and view2/3.spad files (as I did 4y ago according
> github;) in order to use one of the plot packages mentioned, but then you're
> sticked to those few methods/parameters. IMO a free format like )gnuplot or
> )mplot should be used if one needs more than a toy.
> https://github.com/nilqed/fricas_input/tree/master/spad/draw

The graphics system of FriCAS allows to interact with the graphics. If
ever there is a replacement, it should also allow interaction. So if you
want to choose an external plotting tool, choose something that allows
interaction.

If I were much interested in graphics, I would simply choose a tool and
then write a FriCAS package that simply translates plotting commands
from the FriCAS side to the appropriate equivalent in the external
plotting tool. But hey, Kurt, that is your favourite to experiment.

I am currently much more interested in someone who is able to connect
flintlib.org to FriCAS. That would help me (and FriCAS) quite a bit.

Ralf

[Ralf Hemmecke]

> My favourite still is GLE (BSD, c code, only QGLE is LGPL). Provides really HQ
> (eps,pdf,...), or LaTeX/PGF/TikZ (GeoGebra, for instance, can export PGF).
>
> https://kfp.bitbucket.io/tmp/GLE.html

Wow! That looks impressive. Kurt, I want that. Obviously you seem to
have connected the FriCAS drawing enginge with this to get something in
jfricas.

What exactly is needed to get this at least under jfricas?
Anything that must go into the fricas master branch?
What other prerequisites?

Kurt, you are really a great master.

Ralf

[Bill Page]

Thanks for taking the bait! :-)

On Thu, Oct 29, 2020 at 12:11 PM Kurt Pagani <nil...@gmail.com> wrote:
> ...

> https://fricas.github.io/api/GnuDraw.html?highlight=gnudraw
>
> It seems to be the only method at the moment (besides the built-in "draw")
> that can reliably produce graphics using fricas data. It is easy to use it in
> TeXmacs. One has to define a small function which calls gnuplot and
> inserts the picture into TM (there is a package TexmacsSupport @
> https://github.com/nilqed/spadlib/tree/master/tmspt (file src/tmspt.spad)
> which may help to show how it might go (see test_gnudraw.pdf), i.e.
> one has to combine the commands into a function ...
>

I greatly appreciate the hints and examples.

> ...

> Probably the Gnuplot plugin of TeXmacs could be called from within the
> fricas plugin (the scheme commands are known), however, it seems more
> simple to me using GnuDraw and insert produced png/ps or whatever than
> using another plugin.

Maybe you are right. I just seems a bit messy to have to use a
temporary file to communicate.

> >
> > I think Kurt and Ralf are/were thinking of something like this for the
> > FriCAS Jupyter interface.
>
> We were (actually still are), but Ralf thought, it's better to start
> without graphics in the first release. He's certainly right, as there
> still is the agony of choice and lack of a reliable link to produce
> data from fricas objects.

> ...

> My favourite still is GLE (BSD, c code, only QGLE is LGPL). Provides
> really HQ (eps,pdf,...), or LaTeX/PGF/TikZ (GeoGebra, for instance,
> can export PGF).
>
> https://kfp.bitbucket.io/tmp/GLE.html
>

Looks great to me.

> You see, there are a lot of prototypes in the pipeline, however,
> without an initial impetus/decision which system to use (lcd) it
> might take ages ...
>

Let me at least add my strong encouragement for this addition to jfricas.

>
> BTW, I also find the "draw commands" not very flexible. It would be
> easy to slightly modify the draw and view2/3.spad files (as I did 4y
> ago according github;) in order to use one of the plot packages
> mentioned, but then you're sticked to those few methods/parameters.
> IMO a free format like )gnuplot or )mplot should be used if one
> needs more than a toy.
> https://github.com/nilqed/fricas_input/tree/master/spad/draw
>

By )gnuplot are you suggesting a new command in FriCAS with this name?

Is your idea to provide tools in FriCAS just to generate package
independent data and then call an external package with the
desired options/functionality to actually produce the graphics?

Bill.

[Kurt Pagani]

On 29.10.2020 18:30, Bill Page wrote:
<snip>

>
> By )gnuplot are you suggesting a new command in FriCAS with this name?

Not really. In jfricas there are some fake system commands, ")python" for
instance, which are captured and handled by the ipython interpreter. One such
command was (deactivated at the moment) ")gnuplot", that allowed to write
arbitrary GnuPlot commands into the NB cell, wherbey data comes from Fricas via
the PLOT and PLOT3D domains.

>
> Is your idea to provide tools in FriCAS just to generate package
> independent data and then call an external package with the
> desired options/functionality to actually produce the graphics?

You hit the nail. The gle.spad that I mentioned in a former mail is quite old,
and I have a newer one (must have forgotten, although it is dated August 2020) here:

https://github.com/nilqed/spadlib/blob/master/gle/src/gle.spad

It requires (on debian): apt install gle-graphics.

GLE is similar to Asymptote, https://asymptote.sourceforge.io/ , but has IMO
some advanatges.

As you indicated, data is generated by another package: PLTSPT ==> PlotSupport
is required.

https://github.com/nilqed/spadlib/blob/master/pltspt/src/pltspt.spad

I suppose this could be a path, but I have to refresh mind and do some
documentation first.

Best wishes
Kurt
>
> Bill.
>