from:"Qian Yun"

Re: [fricas-devel] [PATCH] improvements to the reference book

2024-06-05 Thread Qian Yun





On 6/2/24 08:29, Qian Yun wrote:



On 6/2/24 02:24, Waldek Hebisch wrote:



It seems that all discovered issues are resolved now.  It is not
clear to me it is worth splitting disscusion into separate threads.
Concerning splitting patches, I think it would be natural to
commit chages to HyperDoc program and graphics as one piece (assuming
they are compatible with current way of building book) and changes
to FriCAS book and src/doc Makefile as another piece.


I think the HyperDoc patch is relatively independent and should
commit separately, after all it solves Greg's problem.

As for the "file truncation problem", or let's rephrase it as
"sman in pipe problem". (I just noticed it is mentioned in the
"doc/fricas.1" man page.)  One thing I'm still not very sure:
what's the purpose of "wait_for_client_read" in "sread"?
In which context is it useful?  I'm inclined to remove it.


To answer my own question: we should remove "wait_for_client_read".
This function is intended for the scenario "client closes connection
and tries to connect again."  But for Unix domain socket,
they can't be closed unexpectedly, unlike TCP connection over Internet.
And since the reconnection needs to exchange PID and 'purpose',
but there's no code to handle this logic on the client side.

So when "fricas_read" returns 0, it means the other end of the
unix domain socket is closed, and we should prepare for proper shutdown.


Another thing that I'm more certain: since in session.c
we use "session_socket_mask" instead of "socket_mask",
"sread" ("get_int" etc) can have unexpected side effects,
I need to take a deeper look to see if there's a better solution.


In session.c, we should pay extra attention when the socket peer
closes, I think these cases are already considered.


A final problem is, should "sman" restart "viewman" if it exits?
(https://github.com/fricas/fricas/pull/101)
If "viewman" exits normally, "sman" should not restart it,
otherwise "sman" (and the whole session) will not quit to terminal.


I modify "sman" to check for the return status of its subprocesses,
and do not restart a child process if it exits successfully.

Branch rebased and updated.  Please review and test.
https://github.com/oldk1331/fricas/tree/new-ps-book

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/b75464bb-e442-4fae-b6b7-8b8d4ea3e54d%40gmail.com.

Re: [fricas-devel] [PATCH] improvements to the reference book

2024-06-01 Thread Qian Yun

On 6/2/24 02:24, Waldek Hebisch wrote:

On Sat, Jun 01, 2024 at 12:56:26PM +0800, oldk1331 wrote:

Hmm... cannot we also have something like this -paste option
for the .ps file generation?

To Ralf: we can, but we also decided to decouple book generation
with hypertex pages generation.

Well, I am not sure why Ralf wants decoupling, but for me it
is no-goal. In fact, since at core process is similar it is
natural to reuse as much code as possible. And reuse already
done computations. Which means doing what code in FriCAS
wiki is doing: produce both text and LaTeX output in the same
run.

There's \htonly and \texonly, so it has to run twice.

It seems that all discovered issues are resolved now. It is not
clear to me it is worth splitting disscusion into separate threads.
Concerning splitting patches, I think it would be natural to
commit chages to HyperDoc program and graphics as one piece (assuming
they are compatible with current way of building book) and changes
to FriCAS book and src/doc Makefile as another piece.

I think the HyperDoc patch is relatively independent and should
commit separately, after all it solves Greg's problem.

As for the "file truncation problem", or let's rephrase it as
"sman in pipe problem". (I just noticed it is mentioned in the
"doc/fricas.1" man page.) One thing I'm still not very sure:
what's the purpose of "wait_for_client_read" in "sread"?
In which context is it useful? I'm inclined to remove it.

Another thing that I'm more certain: since in session.c
we use "session_socket_mask" instead of "socket_mask",
"sread" ("get_int" etc) can have unexpected side effects,
I need to take a deeper look to see if there's a better solution.

A final problem is, should "sman" restart "viewman" if it exits?
(https://github.com/fricas/fricas/pull/101)
If "viewman" exits normally, "sman" should not restart it,
otherwise "sman" (and the whole session) will not quit to terminal.

I have some small comment to changes that you did in .htex files.
Namely on page 876 subsection 'abbrs' you changed 'limited to 7
characters' into 'limited to 8 characters'. The exact statement
is that _category_ abbreviations are limited to 7 characters
and domain/package abbreviations can use 8 characters.
I would probably skip 'limited to' part here.

Abbreviations are mentioned in other places and we probably should
put precise statement somewhere, but description of 'Browse' does
not look like good place. And such change is independent of other
changes that you are making.

Branch rebased and updated.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/8896f2e4-669e-4454-adb8-dd2b32441bc1%40gmail.com.

[fricas-devel] [PATCH] exit HyperDoc properly

2024-06-01 Thread Qian Yun


This patch is to fix https://github.com/fricas/fricas/issues/170,
aka when quitting FriCAS, the HyperDoc started by ")hd" should
exit properly.

"viewman" started by ")startGraphics" can exit properly,
see src/graph/viewman/viewman.c line 188:

  viewType = get_int(spadSock);
  if (viewType == -1) goodbye(-1);

The key here is to detect SpadServer shutdown.
HyperDoc didn't do this check.

Another issue recently discovered by Greg is that
HyperDoc can exit only after mouse passes it.

That's because when you enter a line to FRICASsys,
a SIGUSR2 signal is sent to HyperDoc indicating "EndOfOutput".
This signal will cause system call "select" to fail.
The correct thing to do is using "sselect" to restart
this system call, instead of letting it fail silently.
(Just like what sman.c and seesion.c did.)

BTW, "$PageStuff in hypertex.boot" is recently removed,
so C function "get_new_window" can be removed as well?

- Qian

diff --git a/src/hyper/event.c b/src/hyper/event.c
index a0f0c058..2300a07e 100644
--- a/src/hyper/event.c
+++ b/src/hyper/event.c
@@ -114,7 +114,11 @@ mainEventLoop(void)
 handle_event();
 }
 else {
-  select(FD_SETSIZE,(void *),(void *),(void 
*),NULL);

+  int ret_val = sselect(FD_SETSIZE, , , , NULL);
+  if (ret_val == -1) {
+exitHyperDoc();
+exit(1);
+  }
   if (FD_ISSET(Xcon, ) ||
   XEventsQueued(gXDisplay, QueuedAfterFlush)) {
 XNextEvent(gXDisplay, );
@@ -127,10 +131,14 @@ mainEventLoop(void)
  * $PageStuff in hypertex.boot
  */
 {
-if (100 == get_int(spad_socket)) {
+int cmd = get_int(spad_socket);
+if (100 == cmd) {
 set_window(gParentWindow->fMainWindow);
 make_busy_cursors();
 get_new_window();
+} else if (-1 == cmd) {
+exitHyperDoc();
+exit(0);
 }
 }
 /*

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/d4707e43-e8c8-4cce-bcd4-cd95b559ec71%40gmail.com.

Re: [fricas-devel] [PATCH] improvements to the reference book

2024-06-01 Thread Qian Yun





On 6/1/24 13:04, Ralf Hemmecke wrote:

On 6/1/24 06:56, oldk1331 wrote:

Hmm... cannot we also have something like this -paste option
for the .ps file generation?


To Ralf:  we can, but we also decided to decouple book generation
with hypertex pages generation.


I somehow meant that there is another option that is passed to the 
fricas call that works similar to -paste in terms of serializing IO as 
you described for the -paste option, but works for generating .ps files.

Of course, the overall goal is decoupling the book and hyperdoc generation.

But if you have solved the problem in another way, also fine. I can only 
test from Monday on. Which patch do you mean?


Ralf



The patch was sent on May 29.  Anyway, I've rebased
https://github.com/oldk1331/fricas/tree/new-ps-book

And the patch is updated a little at
https://github.com/oldk1331/fricas/commit/233020620ac6d83b5a8c497541c4d3e38148ceec

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/12893d1d-de80-4db3-9492-e1374525335f%40gmail.com.

[fricas-devel] radicalSolve regression by commit fcacacff

2024-05-31 Thread Qian Yun


Commit fcacacff fixed one regression in radicalSolve,
but it introduces another:

(1) -> radicalSolve(8*x^3+12*x^2+6*x-1,x)

+---+ +-+   +---+ +-+
 - \|- 1 \|3  - 3  \|- 1 \|3  - 3
   (1)  [x = , x = --, x = 0]
 44

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/1a12426e-8cdd-4ca2-90ec-bae4746d1e08%40gmail.com.

Re: [fricas-devel] [PATCH] improvements to the reference book

2024-05-30 Thread Qian Yun

On 5/31/24 00:38, Waldek Hebisch wrote:

On Thu, May 30, 2024 at 07:43:30PM +0800, Qian Yun wrote:

On 5/29/24 22:51, Waldek Hebisch wrote:

first build went fine, but a few later failed. Actually, it looks
worse than previous version where probability of success looked
higher.

Yes, problem is because some .tex files are truncated. In one run it
was 'ug10.tex', in few cases it was 'SEGBIND.tex'. In other cases
I did not check the files but LaTeX error messuge indicated truncation.

Can you try my patch from yesterday and see if this one helps.

I could, but it takes time. And such tweaking is risky, while it
may solve problem on my machine we risk breaking other. I would
prefer to get closer to reasons so that we can be confident that
book build really works.

I'll explain more. The output is truncated because some subprocess
of sman are killed before socket buffer is outputted.

The direction of IO goes like this:

FRICASsys <=> (forked child) sman <=> session <=> spadclient <=> stdio

When FRICASsys quits, the SpadServer socket and pty closes,
sman detects that and quits, causing SessionIOServer to be closed,
session detects that and quits, causing SessionServer to be closed,
spadclient detects that and quits.
(I ignored hypertex in this picture, it should also quit properly.)

Each process quits before processing all of its IO, so the output
will not be truncated.

The core idea is to detect socket shutdown, from "man recv":

When a stream socket peer has performed an orderly shutdown,
the return value will be 0.

I removed my previous workaround and applied this patch,
and I no longer have this truncation issue.

If this patch works on your side as well, I can improve the
details of this patch and upstream it.

Concerning book, I did a few trials with version in the trunk, and
it worked fine on each trial. That is too little to be sure,
but is strong indication that trouble is due to recent changes.

Trunk version uses "FRICASsys" in pipe, that is fine.
My version uses "sman with FRICASsys" in pipe, which causes problem,
but I think it existed in the past as well.

The "sman -paste" invocation of "hypertex" does not have this problem
because it uses only socket IO to FRICASsys, it's purely sequential.

Yes, socket I/O is free from worst races. Pure use of stdio also
should be good.

While the "usage of sman/FRICASsys in pipe" is more complex, it involves
both socket IO and stdio, so the race happens there.

Well, clearly we should try to limit simultaneous use of socket IO
and stdio.

A minor correction: socket IO and stdio are sequential, but the signal
to kill the process is parallel, causing the race problem.
As I explained, this patch makes each process exits normally, instead
of being killed by sman simultaneously.

- Qian

Re: [fricas-devel] [PATCH] improvements to the reference book

2024-05-30 Thread Qian Yun

On 5/29/24 22:51, Waldek Hebisch wrote:

first build went fine, but a few later failed. Actually, it looks
worse than previous version where probability of success looked
higher.

Can you try my patch from yesterday and see if this one helps.

Do you think this is a problem that needs to be fixed before commit?

We should understand what is happening. As I wrote, HyperDoc and
graphics protocal is inherently racy, but in previously it worked
relatively well. Ocasional hangs did happen. But truncated files
is a new thing.

I do not think this "truncated file" problem is a new thing.
We simply did not test it before, so it was not noticed until now.

The "sman -paste" invocation of "hypertex" does not have this problem
because it uses only socket IO to FRICASsys, it's purely sequential.

While the "usage of sman/FRICASsys in pipe" is more complex, it involves
both socket IO and stdio, so the race happens there.

- Qian

Re: [fricas-devel] [PATCH] improvements to the reference book

2024-05-29 Thread Qian Yun


I tried more debugging and I hope I solve this problem
in the correct direction.

Everything is connected now... These are all related:

https://github.com/fricas/fricas/issues/171
https://github.com/fricas/fricas/issues/170
https://github.com/fricas/fricas/pull/101


One thing remains unclear to me: is "wait_for_client_read"
really useful?

Basically what this patch does is:
close the process (sman/session/spadbuf/viewman/hypertex)
only after its input source is closed.

This should make sure no data is lost in the socket buffer.

Please test if this patch solves the problem.

- Qian

On 5/29/24 19:37, Ralf Hemmecke wrote:

On 5/29/24 11:24, Qian Yun wrote:

Do you think this is a problem that needs to be fixed before commit?


If I had something to say, I would like to solve that problem once and 
for all. Would it be too hard to synchronize the writeout of files by a 
temporary file on hard disk (or some cheaper option if possible)?


I could also imagine another solution.
If I am not wrong then these truncated files come from .htex files.
So, the respective .input files that are fed to fricas are generated.
We simply add two lines to these files, one at the beginning, and one at 
the end something like


-- %%% BEGIN %%%

-- %%% ENE %%%

and then check the generated file for existence of these lines. If they 
are not there, then the .input file has to be sent again through fricas.
That has the chance of looping forever. But is probability of an 
infinite loop higher or lower than what we have now?


I especially do not like that the beginning or end of the file can be 
truncated  at a place that does not lead to a LaTeX error.
(I know that this can also already happen on "master", but we should do 
something about it.)


So the book would be incomplete, but that would only be recognized if 
someone actually reads the book and figures out that something is 
missing. However, the book will most probably only be read by newcomers 
that cannot be expected to see that something is (wrongly) missing.


Opinions?

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/150ffce1-80f3-461a-a4b7-984235bd0d8b%40gmail.com.
diff --git a/src/hyper/event.c b/src/hyper/event.c
index a0f0c058..49ef7b4e 100644
--- a/src/hyper/event.c
+++ b/src/hyper/event.c
@@ -127,10 +127,13 @@ mainEventLoop(void)
  * $PageStuff in hypertex.boot
  */
 {
-if (100 == get_int(spad_socket)) {
+int cmd = get_int(spad_socket);
+if (100 == cmd) {
 set_window(gParentWindow->fMainWindow);
 make_busy_cursors();
 get_new_window();
+} else if (-1 == cmd) {
+exitHyperDoc();
 }
 }
 /*
diff --git a/src/lib/sockio-c.c b/src/lib/sockio-c.c
index e89163ce..5ed214e2 100644
--- a/src/lib/sockio-c.c
+++ b/src/lib/sockio-c.c
@@ -257,7 +257,7 @@ sread(Sock *sock, char *buf, int buf_size, char *msg)
 FD_CLR(sock->socket, _mask);
 purpose_table[sock->purpose] = NULL;
 fricas_close_socket(sock->socket);
-return wait_for_client_read(sock, buf, buf_size, msg);
+return -1; // wait_for_client_read(sock, buf, buf_size, msg);
   }
   if (ret_val == -1) {
 if (msg) {
@@ -819,7 +819,7 @@ remote_stdio(Sock *sock)
 }
 if (FD_ISSET(sock->socket, )) {
   len = sread(sock, buf, 1024, "stdio");
-  if (len == -1)
+  if (len == -1 || len == 0)
 return;
   else {
 *(buf + len) = '\0';
diff --git a/src/sman/session.c b/src/sman/session.c
index bfba94f9..fd3547bd 100644
--- a/src/sman/session.c
+++ b/src/sman/session.c
@@ -173,7 +173,11 @@ static void
 read_SpadServer_command(void)
 {
   int cmd, frame, num;
-  cmd  = get_int(spad_server);
+  int ret = fricas_read(spad_server, (char *) , sizeof(int));
+  if (0 == ret) {
+FD_CLR(spad_server->socket, _socket_mask);
+return;
+  }
   switch (cmd) {
   case EndOfOutput:
 if (menu_client != (Sock *) 0) send_signal(menu_client, SIGUSR2);
@@ -259,8 +263,9 @@ static void
 read_from_spad_io(void)
 {
   int ret_code;
-  ret_code = sread(spad_io, big_bad_buf, BufSize, "session: stdout socket");
+  ret_code = fricas_read(spad_io, big_bad_buf, BufSize);
   if (ret_code == -1) return;
+  if (ret_code == 0) exit(0);
   if(active_session != (Sock *) 0) {
 ret_code = swrite(active_session, big_bad_buf, ret_code,
   NULL);
diff --git a/src/sman/sman.c b/src/sman/sman.c
index 652e2708..6e35e687

Re: [fricas-devel] [PATCH] improvements to the reference book

2024-05-29 Thread Qian Yun




On 5/27/24 22:10, Waldek Hebisch wrote:>

What's its CPU model and how many threads are you using to build
the book?


Quad core Core 2 2.4.GHz.  I just did 'make book', that is serial
build.



I limit my CPU to 800MHz, but still can't reproduce it.


I suspect that this may disc drive.  I have mirrored pair of
hard discs.  After large writes processes writing to disc effectively
stop for few seconds, but CPU bound go forward.



Can't reproduce it on my mechanical hard drives either.

From your description it looks like it's the missing lines
at the end problem.

Do you think this is a problem that needs to be fixed before commit?

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/ddf436c8-da84-4a65-a58d-9d5ff5b2a530%40gmail.com.

Re: [fricas-devel] Counting spad function calls during a computation

2024-05-29 Thread Qian Yun


Seems like ")trace" can count function calls:

)trace COMPLEX )math )count
complex(2,3)^2
)trace )stats


- Traced function execution counts -
   Complex.*,33 : 1 times
   Complex.+,31 : 0 times
   Complex.-,32 : 0 times
   Complex.OMwrite,20 : 0 times
   Complex.coerce,29 : 0 times
   Complex.complex,30 : 1 times
   Complex.exquo,41 : 0 times
   Complex.imag,15 : 7 times
   Complex.one?,28 : 0 times
   Complex.real,13 : 7 times
   Complex.zero?,26 : 0 times


- Qian

On 5/29/24 08:00, Grégory Vanuxem wrote:

Hello,

Is there an already implemented way to count the number of Spad
function calls needed to compute a more general computation? I could
add a global counter to a routine/macro like spadcall or something
like that, but I am wondering if this was already done? I don't think
it is simple. I have seen in the code some comments about this but I
do not know how to do it exactly. As an illustration, in the Complex(R
: CommutativeRing) domain there is this comment:

Ops ==>
x + y == [x.real + y.real, x.imag + y.imag]
-- by re-defining this here, we save 5 fn calls
x - y == [x.real - y.real, x.imag - y.imag]
x : % * y : % ==
[x.real * y.real - x.imag * y.imag,
 x.imag * y.real + y.imag * x.real] -- here we save nine!

if R is DoubleFloat then
-- we inline from DoubleFloat here
Ops
else
-- general case
Ops
- Greg



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/dc568fe3-b55f-4a3c-aafe-d8bdbcd7853a%40gmail.com.

Re: [fricas-devel] [PATCH] improvements to the reference book

2024-05-27 Thread Qian Yun




On 5/27/24 10:00, Waldek Hebisch wrote:

On Mon, May 27, 2024 at 08:50:31AM +0800, Qian Yun wrote:

OK, what's the version of texlive on this old machine?


epstopdf has inside comment saying: 2014-06-18


Changelog shows "2017/01/07 v2.26".  I can add "--output="
to make it more backwards compatible.


What's its CPU model and how many threads are you using to build
the book?


Quad core Core 2 2.4.GHz.  I just did 'make book', that is serial
build.



I limit my CPU to 800MHz, but still can't reproduce it.

Can you tweak the sleep value in commit 8009c4f2 and see if
that helps.  If file gets truncated at the end, tweak value in
src/sman/sman.c, if file gets truncated at the beginning,
tweak value in src/sman/spadclient.c.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/5ce992c4-a78e-4791-bd1c-dc9d43fbf78f%40gmail.com.

Re: [fricas-devel] [PATCH] improvements to the reference book

2024-05-26 Thread Qian Yun


OK, what's the version of texlive on this old machine?
What's its CPU model and how many threads are you using to build
the book?

- Qian

On 5/27/24 07:37, Waldek Hebisch wrote:

On Fri, May 17, 2024 at 08:38:35PM +0800, Qian Yun wrote:

I'd like to upstream my improvements to the reference book.


I fetched your branch.  Book builds fine on new machine, but failed
on my old one.  One problem is that on old machine I need
'--outfile=...' option to 'epstopdf' like:

 epstopdf tmp/3DOptCf3.VIEW/image.ps --outfile=tmp/3DOptCf3.pdf

After fixing this build failed later with latex error, probably
one of the files is truncated.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/f821d0f1-c669-493e-8e80-c7e2a8001811%40gmail.com.

Re: [fricas-devel] [PATCH] fix title related memory issues

2024-05-26 Thread Qian Yun


See my updated attachment.

In this version I did not try to do cleanups, instead I
declare errorStr as local variable.

As for "check", I find that it gets redefined in
graph/viewAlone/viewAlone.h, graph/viewman/viewman.h:

#define check(code) checker(code,__LINE__,"")

Also I don't like its overhead when we only read a few bytes,
I hope in the future we can avoid the overhead if we are
building in release mode (aka when there is no DEBUG defined).

- Qian

On 5/26/24 20:05, Waldek Hebisch wrote:

On Sat, May 25, 2024 at 06:27:10PM +0800, Qian Yun wrote:

Sorry, the problem is not "fricas_sprintf_to_buf", but
"extern char errorStr [80];".

I want to avoid this global variable and implementation
detail to leak to util.c.


So you are trying to clean up the code.  I must say that
I would prefer to have 'checked' read that would loop in
case of short read (usually 'read' delivers all requested
data, but it can return only part of what was requested
in in such case we should loop (this is not handled in
current code)).  Such 'checked' read would get parameters
needed to build error message (so no global buffer and no
'sprintf' at call site).




--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/f2e8714f-8d3a-44ac-aa7a-51ee4750209a%40gmail.com.
diff --git a/src/graph/include/spadAction2d.H1 b/src/graph/include/spadAction2d.H1
index 455fef4a..fd4457ad 100644
--- a/src/graph/include/spadAction2d.H1
+++ b/src/graph/include/spadAction2d.H1
@@ -1,2 +1 @@
-extern int readViewman(void *, int);
 extern int spadAction(void);
diff --git a/src/graph/include/spadAction3d.H1 b/src/graph/include/spadAction3d.H1
index cc2cc432..753346ae 100644
--- a/src/graph/include/spadAction3d.H1
+++ b/src/graph/include/spadAction3d.H1
@@ -1,3 +1,2 @@
-extern int readViewman(void *, int);
 extern void scalePoint(viewTriple *);
 extern int spadAction(void);
diff --git a/src/graph/view2D/spadAction2d.c b/src/graph/view2D/spadAction2d.c
index a923ad88..c5d71714 100644
--- a/src/graph/view2D/spadAction2d.c
+++ b/src/graph/view2D/spadAction2d.c
@@ -44,22 +44,6 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #include "util.H1"
 #include "strutil.h"
 
-/**
- * int readViewman(info,size) *
- **/
-
-int
-readViewman(void * info,int size)
-{
-  int mold = 0;
-
-  fricas_sprintf_to_buf3(errorStr, "%s %d %s", "read of ", size,
-  " bytes from viewport manager\n");
-  mold = check(read(0,info,size));
-  return(mold);
-
-}
-
 /
  * int spadAction() *
  /
@@ -95,8 +79,7 @@ spadAction(void)
 
   case changeTitle:
 readViewman(,intSize);
-readViewman(viewport->title,i1);
-viewport->title[i1] = '\0';
+readViewmanStr(viewport->title, i1, sizeof(viewport->title));
 writeTitle();
 writeControlTitle();
 XFlush(dsply);
@@ -105,9 +88,7 @@ spadAction(void)
 
   case writeView:
 readViewman(,intSize);
-readViewman(filename,i1);
-filename[i1] = '\0';
-fricas_sprintf_to_buf1(errorStr, "%s", "writing of viewport data");
+readViewmanStr(filename, i1, sizeof(filename));
 i3 = 0;
 readViewman(,intSize);
 while (i2) {
diff --git a/src/graph/view2D/viewport2D.c b/src/graph/view2D/viewport2D.c
index 95b15f21..bc428ce5 100644
--- a/src/graph/view2D/viewport2D.c
+++ b/src/graph/view2D/viewport2D.c
@@ -514,7 +514,7 @@ makeViewport(char *title,int vX,int vY,int vW,int vH,int showCP)
   fprintf(stderr,"view2D: Made a viewport\n");
 #endif
 
-  strcpy(viewport->title,title);
+  strncpy(viewport->title, title, sizeof(viewport->title) - 1);
 
   viewport->closing  = no;
   viewport->allowDraw= yes;   /* just draw axes the first time around */
diff --git a/src/graph/view3D/header.h b/src/graph/view3D/header.h
index 21009335..622b744e 100644
--- a/src/graph/view3D/header.h
+++ b/src/graph/view3D/header.h
@@ -269,7 +269,7 @@ typedef struct _buttonStruct {
 
 typedef struct _controlPanelStruct {
   WindowcontrolWindow, messageWindow, colormapWindow;
-  char  message[40];
+  char  message[80];
   buttonStruct  buttonQueue[maxButtons3D];
 } controlPanelStruct;
 
diff --git a/src/graph/view3D/spadAction3d.c b/src/graph/view3D/spadAction3d.c
index 1cf79001..4f1c1313 100644
--- a/src/graph/view3D/spadAction3d.c
+++ b/src/graph/view3D/spadAction3d.c
@@ -46,17 +46,6 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #include "all_3d.H1"
 #include "strutil.h"
 
-int
-readViewman (void *info,int size)
-{
-

[fricas-devel] Re: [PATCH] improvements to the reference book

2024-05-25 Thread Qian Yun

Any comments?

I believe the first and second patch are good to go.

As for the third patch, I think the png image can be improved a bit
more, by tweaking the fonts a little.

And for the fourth patch, I'd like to include
)set output length 88
in src/doc/htex2input.awk, because for those verbatim
"algebra stream" output, the default setting is a bit short.

- Qian

On 5/17/24 20:38, Qian Yun wrote:

I'd like to upstream my improvements to the reference book.

The patches are in this branch:
https://github.com/oldk1331/fricas/commits/new-ps-book/

1. build book with PS images generated by FriCAS
https://github.com/oldk1331/fricas/commit/b1def5000c1fe4db3c68ac6a189dccb6b839d667

2. fix chapter 14 "Browse", remove unused part and fix
some lines to match the behavior of current HyperDoc
https://github.com/oldk1331/fricas/commit/41b56c63c32b7eb30585fb809ffb698100d51888

3. build book with pdflatex, with png images replacing
the old PS images
https://github.com/oldk1331/fricas/commit/b66627d44257d1c85ef9d9668ef95f107e92c3c4

4. fix display issue of "output" in book section 6.19
https://github.com/oldk1331/fricas/commit/4276c76327ab731770506908753162fa7d918de8

There has been a few minor improvements in the past days,
and I've built the book many times without failure.

Note that in patch 3, I've changed the Makefile target
from "book.pdf" to "book".

- Qian

Re: [fricas-devel] [PATCH] fix title related memory issues

2024-05-25 Thread Qian Yun


Sorry, the problem is not "fricas_sprintf_to_buf", but
"extern char errorStr [80];".

I want to avoid this global variable and implementation
detail to leak to util.c.

- Qian

On 5/24/24 23:40, Waldek Hebisch wrote:

On Fri, May 24, 2024 at 05:04:08PM +0800, Qian Yun wrote:

I wanted to avoid pulling in "fricas_sprintf_to_buf".

Turns out I can use

   const char *errorStr = "read from viewport manager\n";

Are you OK with this?


OK if we really need to remove uses of "fricas_sprintf_to_buf".
But why do you want to remove such uses?



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/afa5c34c-5878-4b9b-aaea-b6150ae26681%40gmail.com.

Re: [fricas-devel] Serial part of build

2024-05-24 Thread Qian Yun





On 5/24/24 06:32, Waldek Hebisch wrote:


I am not sure.  At least we world need proper dependencies.  Most of
those files are categories.  We compile categories because compiling
may need to load compiled categories.  And compiling a category need
categories that it uses.  Our list of categories to compile is sorted
so that dependencies are compiled first.



I was not aware that there's order in CATLIST.

Can you update this information to doc/algebra_build.txt?
Also does other parts of that file need update?

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0e8f306b-7a9d-4c2e-98b3-bab553ccd780%40gmail.com.

Re: [fricas-devel] [PATCH] fix title related memory issues

2024-05-24 Thread Qian Yun


I wanted to avoid pulling in "fricas_sprintf_to_buf".

Turns out I can use

  const char *errorStr = "read from viewport manager\n";

Are you OK with this?

- Qian

On 5/24/24 07:19, Waldek Hebisch wrote:


It is good to fix buffer overflow.  But you also remove error
checking (use of 'check').  Admited, this is minimal error
checking, just printing error message, but this is better than
nothing.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/2ee6714f-170e-49ca-810a-2c43ef1bcb94%40gmail.com.

Re: [fricas-devel] Serial part of build

2024-05-23 Thread Qian Yun


The daase generation is not that long on a fast machine:
it's around 25 seconds with sbcl.

 boo_db.input
)boot $SaveParseOnly := true
)read komp_all.input
)boot processGlobals()
)boot $SaveParseOnly := nil
)boot $bootStrapMode := true
)boot $bootstrapDomains := true
)boot $createLocalLibDb := false
)read komp_all.input
)boot $bootStrapMode := false
)boot $tryRecompileArguments := false
)read boot_doms.input
)boot make_databases([], false)


The majority time seems to be spent in "boot_doms.input".
Which compiles 314 spad files.  But I think we can compile those
files in parallel if we dump a Lisp image here?

- Qian

On 5/22/24 23:43, Waldek Hebisch wrote:

I looked a what takes time during serial part of build.  More
precisly, during database bootstrap step (that is 'boo_db.input').
 From top-level point of view most time goes into compilation
of Spad files (about 90%) and about 10% of time is spent in
'make-databases'.  At lower level time usage of mostly spread
out into many small contibutions.  Biggest single item is
'COMPILE-FILE' (23.3%), next is pretty printer (about 15%) and
EVAl.  Also, significant time goes into parsing and scanning of
Spad sources (2.9% + 8.5%).  Surprisingly expensive is clearing
of category caches (7%).  What could be improved?  We probably
could save part of time spent in 'COMPILE-FILE', say by tweaking
optimization setting or (as Qian did) loading files in interpret
mode.  But trying

)lisp (proclaim '(optimize (speed 0) (safety 1) (compilation-speed 3)))

before database bootstrap made no differece.

I am affraid that bigger gain is possible only as sum of several
small improvements.  For example both Lisp pretty
printing and Spad syntactic processing take much more time than
they should (on my machine pretty printer spends about 880 clocks
per output charater), but speeding them up really means new
faster implementation, so nontrivial work.  Some gains may be
easy, but probably would produce only small effect, so we would
need many such improvements to have visible speedup.


Top positions (slightly abbreviated to make it clear) in profile are:


   2750  23.3   |compDefineLisplib| [986]
  1   0.0   2750  23.3   COMPILE-FILE [991]

  2   0.0   (LABELS #:BODY-NAME-2161 :IN PPRINT-FILL) [108]
   1405  11.9   (LABELS SB-IMPL::HANDLE-IT :IN 
SB-KERNEL:OUTPUT-O
BJECT) [142]
 14   0.1   1852  15.7   SB-PRETTY:OUTPUT-PRETTY-OBJECT [157]

  1   0.0   |DomainSubstitutionFunction| [2232]
  1   0.0   |get_database2| [134]
  1   0.0   |compSPADSLAM| [1703]
   1104   9.3   |eval| [96]
 21   0.2   PRINT-AND-EVAL-DEFUN [1702]
   1176   9.9   |npboot| [1629]
 19   0.2   2322  19.6   EVAL [124]
  2   0.0   SB-INT:EVAL-IN-LEXENV [881]
 28   0.2   SB-KERNEL:MAKE-NULL-LEXENV [61]
   2266  19.2   SB-EVAL:EVAL-IN-NATIVE-ENVIRONMENT [38]

   1176   9.9   SB-EVAL::EVAL-TAGBODY [1665]
  0   0.0   1176   9.9   SB-EVAL::EVAL-RETURN-FROM [1664]
   1098   9.3   |make_databases| [2968]
 78   0.7   |processGlobals| [1663]

164   1.4   |merge_info_from_nrlib1| [1769]
665   5.6   |compDefineLisplib| [986]
  0   0.0830   7.0   |clearConstructorCaches| [1885]
  1   0.0   PNAME [238]
  1   0.0   |clearConstructorCaches| [1885]
  1   0.0   SB-IMPL::GETHASH3 [45]
828   7.0   |clearCategoryCaches| [115]

  10484  88.7   |compilerDoit| [1540]
  0   0.0  10484  88.7   |spadCompile1| [1539]
  2   0.0   |ncloopIncFileName| [1622]
  10482  88.7   |handle_input_file| [1538]

662   5.6   |merge_info_from_objects| [1770]
  11727  99.2   |intloopInclude| [1548]
  10482  88.7   |spadCompile1| [1539]
  0   0.0  11727  99.2   |handle_input_file| [1538]
  5   0.0   (FLET #:CLEANUP-FUN-610 :IN 
|handle_input_file|) [2199]
 23   0.2   |sayKeyedMsg| [893]
614   5.2   |merge_info_from_nrlib1| [1769]
 23   0.2   OPEN [627]
  9   0.1   SB-SYS:MAKE-FD-STREAM [490]
   1117   9.4

[fricas-devel] [PATCH] fix title related memory issues

2024-05-22 Thread Qian Yun


This patch fixes many memory issues related with title --
especially with long titles in graphs.

The fix includes:

1. memory overwrite in 'spadAction'

(1) -> vp := draw(x,x=1..2); title(vp, new(100, "a".1)$String)
   Compiling function %C with type DoubleFloat -> DoubleFloat
   Graph data being transmitted to the viewport manager...
   FriCAS2D data being transmitted to the viewport manager...
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  3 (X_GetWindowAttributes)
  Resource id in failed request:  0x61616161
  Serial number of failed request:  777
  Current serial number in output stream:  778

2. buffer overflow in 'makeViewport'

3. memory leakage in 'funView2D'/'funView3D'

(if you run "title" in a loop)

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/8c7e41a7-de44-4daf-9bd6-68ebf9943aa1%40gmail.com.
diff --git a/src/graph/include/spadAction2d.H1 b/src/graph/include/spadAction2d.H1
index 455fef4a..fd4457ad 100644
--- a/src/graph/include/spadAction2d.H1
+++ b/src/graph/include/spadAction2d.H1
@@ -1,2 +1 @@
-extern int readViewman(void *, int);
 extern int spadAction(void);
diff --git a/src/graph/include/spadAction3d.H1 b/src/graph/include/spadAction3d.H1
index cc2cc432..753346ae 100644
--- a/src/graph/include/spadAction3d.H1
+++ b/src/graph/include/spadAction3d.H1
@@ -1,3 +1,2 @@
-extern int readViewman(void *, int);
 extern void scalePoint(viewTriple *);
 extern int spadAction(void);
diff --git a/src/graph/view2D/spadAction2d.c b/src/graph/view2D/spadAction2d.c
index a923ad88..8440b639 100644
--- a/src/graph/view2D/spadAction2d.c
+++ b/src/graph/view2D/spadAction2d.c
@@ -44,22 +44,6 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #include "util.H1"
 #include "strutil.h"
 
-/**
- * int readViewman(info,size) *
- **/
-
-int
-readViewman(void * info,int size)
-{
-  int mold = 0;
-
-  fricas_sprintf_to_buf3(errorStr, "%s %d %s", "read of ", size,
-  " bytes from viewport manager\n");
-  mold = check(read(0,info,size));
-  return(mold);
-
-}
-
 /
  * int spadAction() *
  /
@@ -95,8 +79,7 @@ spadAction(void)
 
   case changeTitle:
 readViewman(,intSize);
-readViewman(viewport->title,i1);
-viewport->title[i1] = '\0';
+readViewmanStr(viewport->title, i1, sizeof(viewport->title));
 writeTitle();
 writeControlTitle();
 XFlush(dsply);
@@ -105,8 +88,7 @@ spadAction(void)
 
   case writeView:
 readViewman(,intSize);
-readViewman(filename,i1);
-filename[i1] = '\0';
+readViewmanStr(filename, i1, sizeof(filename));
 fricas_sprintf_to_buf1(errorStr, "%s", "writing of viewport data");
 i3 = 0;
 readViewman(,intSize);
diff --git a/src/graph/view2D/viewport2D.c b/src/graph/view2D/viewport2D.c
index 95b15f21..bc428ce5 100644
--- a/src/graph/view2D/viewport2D.c
+++ b/src/graph/view2D/viewport2D.c
@@ -514,7 +514,7 @@ makeViewport(char *title,int vX,int vY,int vW,int vH,int showCP)
   fprintf(stderr,"view2D: Made a viewport\n");
 #endif
 
-  strcpy(viewport->title,title);
+  strncpy(viewport->title, title, sizeof(viewport->title) - 1);
 
   viewport->closing  = no;
   viewport->allowDraw= yes;   /* just draw axes the first time around */
diff --git a/src/graph/view3D/header.h b/src/graph/view3D/header.h
index 21009335..622b744e 100644
--- a/src/graph/view3D/header.h
+++ b/src/graph/view3D/header.h
@@ -269,7 +269,7 @@ typedef struct _buttonStruct {
 
 typedef struct _controlPanelStruct {
   WindowcontrolWindow, messageWindow, colormapWindow;
-  char  message[40];
+  char  message[80];
   buttonStruct  buttonQueue[maxButtons3D];
 } controlPanelStruct;
 
diff --git a/src/graph/view3D/spadAction3d.c b/src/graph/view3D/spadAction3d.c
index 1cf79001..23260f05 100644
--- a/src/graph/view3D/spadAction3d.c
+++ b/src/graph/view3D/spadAction3d.c
@@ -46,17 +46,6 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #include "all_3d.H1"
 #include "strutil.h"
 
-int
-readViewman (void *info,int size)
-{
-  int m = 0;
-
-  fricas_sprintf_to_buf1(errorStr, "%s", "read from viewport manager\n");
-  m = check(read( 0, info, size));
-
-  return(m);
-
-}
 void
 scalePoint (viewTriple *p)
 {
@@ -398,8 +387,7 @@ spadAction (void)
 
   case changeTitle:
 readViewman(,intSize);
-readViewman(viewport->title,i1);
-viewport->title[i1] = '\0';
+readViewmanStr(viewport->title, i1, sizeof(viewport->title));
 writeTitle();
 switch (doingPanel) {
 case CONTROLpanel:
@@ -418,8 +406,7 @@ spadAction (void)
 
   case writeView:
 readViewman(,intSize);
-

[fricas-devel] [PATCH] improvements to the reference book

2024-05-17 Thread Qian Yun


I'd like to upstream my improvements to the reference book.

The patches are in this branch:
https://github.com/oldk1331/fricas/commits/new-ps-book/

1. build book with PS images generated by FriCAS
https://github.com/oldk1331/fricas/commit/b1def5000c1fe4db3c68ac6a189dccb6b839d667

2. fix chapter 14 "Browse", remove unused part and fix
some lines to match the behavior of current HyperDoc
https://github.com/oldk1331/fricas/commit/41b56c63c32b7eb30585fb809ffb698100d51888

3. build book with pdflatex, with png images replacing
the old PS images
https://github.com/oldk1331/fricas/commit/b66627d44257d1c85ef9d9668ef95f107e92c3c4

4. fix display issue of "output" in book section 6.19
https://github.com/oldk1331/fricas/commit/4276c76327ab731770506908753162fa7d918de8



There has been a few minor improvements in the past days,
and I've built the book many times without failure.

Note that in patch 3, I've changed the Makefile target
from "book.pdf" to "book".

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/caa46f78-78bd-4caf-9ead-cbc18b6bb69f%40gmail.com.

Re: [fricas-devel] bug?: difficulty to extract imaginary part

2024-05-15 Thread Qian Yun


OK, so for radicals, there should be a much more effective
method to determine its sign.  Seems like current method is
mostly focused on polynomials and pretty limited for radicals.

- Qian

On 5/15/24 19:12, Waldek Hebisch wrote:

On Wed, May 15, 2024 at 06:47:45PM +0800, Qian Yun wrote:

You said before AlgebraicNumber should represent any branch
of the root, but here we are talking about the sign of radical.

Does that mean we are taking a specific branch interpretation here?


Yes.  Othewise there is problem with meaning of 'imag'.  Also
note that this is in extra package, not in core domains.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/2a34dffa-4913-492a-827e-6cc0ccda0953%40gmail.com.

Re: [fricas-devel] bug?: difficulty to extract imaginary part

2024-05-15 Thread Qian Yun

You said before AlgebraicNumber should represent any branch
of the root, but here we are talking about the sign of radical.

Does that mean we are taking a specific branch interpretation here?

- Qian

On 5/15/24 17:42, Waldek Hebisch wrote:

TrigonometricManipulations (which implements imag) is using
sign$ElementaryFunctionSign to determine if a root is complex.
'sign' may return "failed" and 'imag' treats this the same as
nonnegative, so assumes that root is real. 'sign' for numbers
tries interval approximation. If precision it too low, then
this fails and 'sign' returns "failed"...

Mathematically determining sign of numbers (which is needed to choose
form of roots) requires numerical computation potentially of much
higher precision than input data. So there will be a cutoff or
we would run out of memory (or time) in some cases. So one question
is how hard FriCAS should try, currently FriCAS just uses current
numeric preciion and do not try to escalate. Another question
is what to do in case of failure. Honestly FriCAS should return
"failed" or signal error in such case. 'sign' returns "failed"
which IMO is OK. Probably 'imag' should signal error. I can
guess that possibly users call 'imag' and related functions
without real need, so lying (as done now) could be a pragmatic
choice. Or simply this is piece of research code that never
really get finished.

Re: [fricas-devel] bug?: difficulty to extract imaginary part

2024-05-14 Thread Qian Yun


One possible explanation:

)compile a spad file clears internal Kernel cache.

So the following computation can have messed up Kernel order.

So after compiling a spad file, do not use kernels created before that.

- Qian

On 5/14/24 22:40, Ralf Hemmecke wrote:

Some more experiments with the imaginary part...

Can someone reproduce/explain the strange behaviour of the attached script?

Please modify the path to efstruc.spad accordingly.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/36eefa4a-975a-4502-8420-95311e4908ff%40gmail.com.

Re: [fricas-devel] Windows installer for official l FriCAS - GitHub commit: 06a45d0

2024-05-14 Thread Qian Yun


Hi,

Can you tell me more about the advantages of installer over zip file?
(Other than start menu entry and desktop icon.)

Also, it would be good to integrate it with Github CI.

- Qian

On 5/13/24 07:43, Grégory Vanuxem wrote:

Hello folks,

Below is a link to a Windows setup program to install FriCAS, usually
in "USER_HOME"/AppData/local/programs/.

A FriCAS start menu entry is added, and optionally it can also create
a desktop icon. The icon used is an old one I created before an
official icon was chosen.

Starting FriCAS will open a Microsoft Windows Terminal running it. I
just partially reverted a commit [1] to allow running
'series(sin(x))*1.0' but this is unsatisfactory.

Please give it a try, for example it is compiled with GMP integer
multiplication support but I don't know how it behaves in other
settings than me.

https://drive.google.com/file/d/1sRNXFCBvrD70ISbTyKEpHuOoUmFA7V4G/view?usp=sharing

wget or curl need special parameters to download it, but even with a
good link for them, I don't think you will be able to download it
because of Google anti-virus settings. Use a browser instead.

- Greg

[1] src/interp/macros.lisp - line 224:
;(defun GLESSEQP (X Y) (|lt_sexp| X Y))
(defun GLESSEQP (X Y) (NOT (GGREATERP X Y)))



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/98416336-a0b2-4b5c-a124-680a9ed1c172%40gmail.com.

Re: [fricas-devel] regression on windows

2024-05-13 Thread Qian Yun


I didn't realize that "isSystemDirectory" checks for prefix.
Well, it also needs to check for string length, otherwise it
will mistakenly accept shorter paths.

The following patch passes CI test now.

Please commit it if it looks good to you as well.

- Qian

diff --git a/src/interp/lisplib.boot b/src/interp/lisplib.boot
index 9c37eacc..b11d9603 100644
--- a/src/interp/lisplib.boot
+++ b/src/interp/lisplib.boot
@@ -71,7 +71,7 @@ loadLibIfNotLoaded libName ==
 loadLib cname ==
   startTimingProcess 'load
   fullLibName := get_database(cname, 'OBJECT) or return nil
-  systemdir? := isSystemDirectory(pathnameDirectory fullLibName)
+  systemdir? := isSystemDirectory(fullLibName)
   update? := not systemdir?
   loadLibNoUpdate1(cname, fullLibName)
   kind := get_database(cname, 'CONSTRUCTORKIND)
diff --git a/src/interp/pathname.boot b/src/interp/pathname.boot
index 7bd1f1b3..c350733f 100644
--- a/src/interp/pathname.boot
+++ b/src/interp/pathname.boot
@@ -61,4 +61,6 @@ isExistingFile f ==

 --% Scratchpad II File Name Functions

-isSystemDirectory dir == EVERY(function CHAR_=,$spadroot,dir)
+isSystemDirectory path ==
+  -- check if $spadroot is the prefix of 'path'
+  # path >= # $spadroot and EVERY(function CHAR_=, $spadroot, path)


On 5/14/24 01:40, Waldek Hebisch wrote:

On Mon, May 13, 2024 at 08:52:12PM +0800, Qian Yun wrote:

The following patch works.

Do we need to compare PATHNAME_-DEVICE as well
(returns "C" in this case) in 'isSystemDirectory'?


I would prefer different approach.  I mean, the patch may be correct
solution to problem "Do two Windows paths point to the same file?"
(for such problem you probably want to include PATHNAME_-DEVICE).
What I do not like is fact that this would propagate Windows
weirdness deper into FriCAS code.

Pathname here comes from 'get_database' and in 'get_database' be
have

 if key = 'OBJECT then
 if CONSP(data) then
 data := first(data)
 if NULL(PATHNAME_-DIRECTORY(data)) then
 data := STRCONC($spadroot, '"/algebra/", data,
'".", $lisp_bin_filetype)
 data

So, returned patname has '$spadroot' as a prefix and AFAICS all we need
is to avoid mangling the pathname.  Maybe just remove 'pathnameDirectory'
call (that is use first part of the patch without the second  part).
  


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/8d78f114-eab8-4688-837d-b2306b9b50de%40gmail.com.

Re: [fricas-devel] regression on windows

2024-05-13 Thread Qian Yun


The following patch works.

Do we need to compare PATHNAME_-DEVICE as well
(returns "C" in this case) in 'isSystemDirectory'?

- Qian

diff --git a/src/interp/lisplib.boot b/src/interp/lisplib.boot
index 9c37eacc..b11d9603 100644
--- a/src/interp/lisplib.boot
+++ b/src/interp/lisplib.boot
@@ -71,7 +71,7 @@ loadLibIfNotLoaded libName ==
 loadLib cname ==
   startTimingProcess 'load
   fullLibName := get_database(cname, 'OBJECT) or return nil
-  systemdir? := isSystemDirectory(pathnameDirectory fullLibName)
+  systemdir? := isSystemDirectory(fullLibName)
   update? := not systemdir?
   loadLibNoUpdate1(cname, fullLibName)
   kind := get_database(cname, 'CONSTRUCTORKIND)
diff --git a/src/interp/pathname.boot b/src/interp/pathname.boot
index 7bd1f1b3..5a81eb49 100644
--- a/src/interp/pathname.boot
+++ b/src/interp/pathname.boot
@@ -61,4 +61,7 @@ isExistingFile f ==

 --% Scratchpad II File Name Functions

-isSystemDirectory dir == EVERY(function CHAR_=,$spadroot,dir)
+isSystemDirectory file ==
+  p1 := BUTLAST PATHNAME_-DIRECTORY file
+  p2 := PATHNAME_-DIRECTORY pad_directory_name $spadroot
+  p1 = p2


On 5/13/24 19:52, Qian Yun wrote:

Yes, make 'updateCategoryTable' a no-op and the problem goes away.

As for the system directory issue:

(3) -> )boot get_database('Integer, 'OBJECT)

(EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
   (PROG () (RETURN (|get_database| '|Integer| 'OBJECT
Value = 
"C:/msys64/home/oldk1331/build/target/x86_64-w64-mingw32/algebra/INT.fasl"

(3) -> )boot pathnameDirectory get_database('Integer, 'OBJECT)

(EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
   (PROG () (RETURN (|pathnameDirectory| (|get_database| '|Integer| 
'OBJECT)

Value = "/msys64/home/oldk1331/build/target/x86_64-w64-mingw32/algebra/"
(3) -> )boot isSystemDirectory pathnameDirectory get_database('Integer, 
'OBJECT)


(EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
   (PROG ()
     (RETURN
  (|isSystemDirectory|
   (|pathnameDirectory| (|get_database| '|Integer| 'OBJECT))
Value = NIL


I'll look into where this originates and how to fix it.

- Qian

On 5/13/24 19:05, Waldek Hebisch wrote:

On Mon, May 13, 2024 at 06:32:10PM +0800, Qian Yun wrote:

I modified i-coerce.boot, then in FRICASsys,
   )read i-coerce
   )lisp (defun GLESSEQP (X Y) (BREAK))
   series(sin x)

The above has no problem in Linux, but fails under
windows, backtrace is in attachment.


AFAICS there is something wrong on Windows with detection of
system directories.  "Integer" is system domain and
'updateCategoryTable' should not be called for it.

On Linux, when I force call to 'updateCategoryTable' I get
the same failure as on Windows.

In principle extra 'updateCategoryTable' should cause no trouble,
ATM I do not know why it triggers failue in the test.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/7c1898ff-ed3e-4f9d-b74c-06796d644e2d%40gmail.com.

Re: [fricas-devel] regression on windows

2024-05-13 Thread Qian Yun


Yes, make 'updateCategoryTable' a no-op and the problem goes away.

As for the system directory issue:

(3) -> )boot get_database('Integer, 'OBJECT)

(EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
  (PROG () (RETURN (|get_database| '|Integer| 'OBJECT
Value = 
"C:/msys64/home/oldk1331/build/target/x86_64-w64-mingw32/algebra/INT.fasl"

(3) -> )boot pathnameDirectory get_database('Integer, 'OBJECT)

(EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
  (PROG () (RETURN (|pathnameDirectory| (|get_database| '|Integer| 
'OBJECT)

Value = "/msys64/home/oldk1331/build/target/x86_64-w64-mingw32/algebra/"
(3) -> )boot isSystemDirectory pathnameDirectory get_database('Integer, 
'OBJECT)


(EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
  (PROG ()
(RETURN
 (|isSystemDirectory|
  (|pathnameDirectory| (|get_database| '|Integer| 'OBJECT))
Value = NIL


I'll look into where this originates and how to fix it.

- Qian

On 5/13/24 19:05, Waldek Hebisch wrote:

On Mon, May 13, 2024 at 06:32:10PM +0800, Qian Yun wrote:

I modified i-coerce.boot, then in FRICASsys,
   )read i-coerce
   )lisp (defun GLESSEQP (X Y) (BREAK))
   series(sin x)

The above has no problem in Linux, but fails under
windows, backtrace is in attachment.


AFAICS there is something wrong on Windows with detection of
system directories.  "Integer" is system domain and
'updateCategoryTable' should not be called for it.

On Linux, when I force call to 'updateCategoryTable' I get
the same failure as on Windows.

In principle extra 'updateCategoryTable' should cause no trouble,
ATM I do not know why it triggers failue in the test.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/c0f97af1-d2ac-4bb1-8f7a-2488db50c0d0%40gmail.com.

Re: [fricas-devel] regression on windows

2024-05-13 Thread Qian Yun


I modified i-coerce.boot, then in FRICASsys,
  )read i-coerce
  )lisp (defun GLESSEQP (X Y) (BREAK))
  series(sin x)

The above has no problem in Linux, but fails under
windows, backtrace is in attachment.

- Qian

On 5/13/24 18:10, Waldek Hebisch wrote:

On Mon, May 13, 2024 at 05:07:56PM +0800, Qian Yun wrote:

Some other updates:

This happens for Clozure CL as well.

This does not happen for fricas0, either compile-mode or
interpret-mode.


Very strange indeed.

I'll compare call stack to interpreter later.


On Linux I can do the following and the example still works:

1) Disable 'canCoercePermute' and 'coerceIntPermute' by adding

 true => nil

as first line

2) Replace GLESSEQP by the following:

(defun GLESSEQP (X Y) (BREAK))

Which means that 'coerceIntPermute' is the only place using
'GLESSEQP' to handle the example (in fact cases when it is used
are quite rare).

I wonder if on Windows there are extra uses of GLESSEQP?  The above
would allow to find them.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/5c3233a1-e2c5-4936-987b-8119dd064aa4%40gmail.com.
(1) -> series(sin x)

debugger invoked on a SIMPLE-CONDITION in thread
#:
  break

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE] Return from BREAK.
  1: [ABORT   ] Exit from the current thread.

(SB-EVAL::EVAL-BLOCK (GLESSEQP (BREAK)) #)
0] :backtrace

Backtrace for: #
0: (SB-EVAL::EVAL-BLOCK (GLESSEQP (BREAK)) #)
1: (|mergeSort| # # 
((|OMwrite| ((|Void|) (|OpenMathDevice|) % (|Boolean|)) . T) (|OMwrite| 
((|Void|) (|OpenMathDevice|) %) . T)) 2) 
2: (|mergeSort| # # 
# 4)
3: (|categoryParts1| |category| (|OpenMath|) (|Join| (CATEGORY |domain| 
(SIGNATURE |OMwrite| ((|String|) %)) (SIGNATURE |OMwrite| ((|String|) % 
(|Boolean|))) (SIGNATURE |OMwrite| ((|Void|) 
(|OpenMathDevice|) %)) (SIGNATURE |OMwrite| ((|Void|) (|OpenMathDevice|) % 
(|Boolean|) T)
4: (|mkCategoryExtensionAlist| (|OpenMath|))
5: (|getCategoryExtensionAlist0| (|OpenMath|))
6: (|addDomainToTable| |Integer| ((|IntegerNumberSystem|) 
(|LinearlyExplicitOver| (|Integer|)) (|PolynomialFactorizationExplicit|) 
(|ConvertibleTo| (|String|)) (|OpenMath|) (|Canonical|) (|
canonicalsClosed|) (|Hashable|)))
7: (|updateCategoryTableForDomain| |Integer| ((|IntegerNumberSystem|) 
(|LinearlyExplicitOver| (|Integer|)) (|PolynomialFactorizationExplicit|) 
(|ConvertibleTo| (|String|)) (|OpenMath|) (|Ca
nonical|) (|canonicalsClosed|) (|Hashable|)))
8: (|updateCategoryTable| |Integer| |domain|)
9: (|loadLib| |Integer|)
10: ((LAMBDA ( ARGS) :IN |mkAutoLoad|))
11: (SB-EVAL::EVAL-ARGS ((|Integer|)) #)
12: (SB-EVAL::%EVAL (|Expression| (|Integer|)) #)
13: (SB-EVAL:EVAL-IN-NATIVE-ENVIRONMENT (|Expression| (|Integer|)) 
#)
14: (EVAL (|Expression| (|Integer|)))
15: (|eval| (|Expression| (|Integer|)))
16: (|evalDomain| (|Expression| (|Integer|)))
17: (|interpLookup;| |coerce| (% (|Symbol|)) (|Expression| (|Integer|)))
18: (|interpLookup| |coerce| (% (|Symbol|)) (|Expression| (|Integer|)))
19: (|coerceByFunction| ((|Symbol|) WRAPPED . |x|) (|Expression| (|Integer|)))
20: (|coerceIntTower| ((|Symbol|) WRAPPED . |x|) (|Expression| (|Integer|)))
21: (|coerceInt1| ((|Symbol|) WRAPPED . |x|) (|Expression| (|Integer|)))
22: (|coerceInt| ((|Symbol|) WRAPPED . |x|) (|Expression| (|Integer|)))
23: (|coerceInt0| ((|Variable| |x|) WRAPPED . |x|) (|Expression| (|Integer|)))
24: (|coerceInteractive| ((|Variable| |x|) WRAPPED . |x|) (|Expression| 
(|Integer|)))
25: (|coerceOrRetract| ((|Variable| |x|) WRAPPED . |x|) (|Expression| 
(|Integer|)))
26: (|getArgValue1| #(|x| NIL (#1=(|Variable| |x|) WRAPPED . |x|) (#1#) 
((|totalArgs| . 1) (|argumentNumber| . 1) (|callingFunction| . |sin|))) 
(|Expression| (|Integer|)))
27: (|getArgValue| #(|x| NIL (#1=(|Variable| |x|) WRAPPED . |x|) (#1#) 
((|totalArgs| . 1) (|argumentNumber| . 1) (|callingFunction| . |sin|))) 
(|Expression| (|Integer|)))
28: (|evalForm| #(|sin| NIL NIL NIL ((|totalArgs| . 1) (|argumentNumber| . 1) 
(|callingFunction| . |series|))) |sin| (#(|x| NIL (#1=(|Variable| |x|) WRAPPED 
. |x|) (#1#) ((|totalArgs| . 1) 
(|argumentNumber| . 1) (|callingFunction| . |sin| (((#1=(|Expression| 
(|Integer|)) #1# #1#) (% %) (NIL
29: (|bottomUpForm2| (#(|sin| NIL NIL NIL ((|totalArgs| . 1) (|argumentNumber| 
. 1) (|callingFunction| . |series|))) #(|x| NIL (#1=(|Variable| |x|) WRAPPED . 
|x|) (#1#) ((|totalArgs| . 1) (
|argumentNumber| . 1) (|callingFunction| . |sin| #(|sin| NIL NIL NIL 
((|totalArgs| . 1) (|argumentNumber| . 1) (|callingFunction| . |series|))) 
|sin| (#(|x| NIL (#1=(|Variable| |x|) WRA
PPED . |x|) (#1#) ((|totalArgs| . 1) (|arg

[fricas-devel] [PATCH] fix build with CCL on windows, again

2024-05-13 Thread Qian Yun


I build with CCL on windows again today, and find that my
previous fix d2d7e978d3de17cdadb184ee7c08deed182116fe
is not enough:

I think it needs to have the :win32 feature at compile time,
otherwise the reader macro will discard unused branch
when compiling |trim_directory_name|.

So I moved the code from fricas-lisp.lisp to fricas-package.lisp,
which already have a code block modifying *FEATURES*.

- Qian

diff --git a/src/lisp/fricas-lisp.lisp b/src/lisp/fricas-lisp.lisp
index be51b6fb..bf46a61a 100644
--- a/src/lisp/fricas-lisp.lisp
+++ b/src/lisp/fricas-lisp.lisp
@@ -236,9 +236,6 @@ with this hack and will try to convince the GCL 
crowd to fix this.

 ;;; For ECL assume :unix, when :netbsd or :darwin
 #+(and :ecl (or :darwin :netbsd)) (push :unix *features*)

-;;; For Clozure CL assume :win32, when :windows
-#+(and :openmcl :windows) (push :win32 *features*)
-
 ;;; -

 ;;; Deleting files ignoring errors
diff --git a/src/lisp/fricas-package.lisp b/src/lisp/fricas-package.lisp
index fdc02117..279eeb30 100644
--- a/src/lisp/fricas-package.lisp
+++ b/src/lisp/fricas-package.lisp
@@ -65,6 +65,8 @@
 )
 #+:openmcl
 (eval-when (:execute :compile-toplevel :load-toplevel)
+  ;;; For Clozure CL assume :win32, when :windows
+  #+:windows (push :win32 *features*)
   (setf *features* (delete :CCL *features*)))

 ;;; Package containing Shoe to Lisp translator

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/b26f5ac2-99cc-4ba3-8008-2508eab85c7b%40gmail.com.

Re: [fricas-devel] regression on windows

2024-05-13 Thread Qian Yun


Some other updates:

This happens for Clozure CL as well.

This does not happen for fricas0, either compile-mode or
interpret-mode.


Very strange indeed.

I'll compare call stack to interpreter later.

- Qian

On 5/13/24 09:51, Waldek Hebisch wrote:

On Mon, May 13, 2024 at 08:23:20AM +0800, Qian Yun wrote:

The *.daase generated on linux and windows are *exactly* the same
(except for the timestamp, of course).


Thanks, so that was bad guess.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/b31343fe-feae-4bca-9889-9ad5a21da590%40gmail.com.

Re: [fricas-devel] regression on windows

2024-05-12 Thread Qian Yun

The *.daase generated on linux and windows are *exactly* the same
(except for the timestamp, of course).

The corresponding fricas0 changes is here, is this expected?

https://github.com/oldk1331/fricas0-repo/commit/74b1193cfcf2f33909f8bad55785c14cf9e02cd8.patch

BTW, can you explain a bit more about the thoughts behind
this commit? Is GGREATERP in Fractored next step?

- Qian

On 5/13/24 07:59, Waldek Hebisch wrote:

On Sun, May 12, 2024 at 07:44:50PM +0200, Waldek Hebisch wrote:

AFAICS uses of GLESSEQP during this computation are trivial.
I think that real impact of GLESSEQP is on database structure.
More precisely, that entries in 'interp.daase' and other
databases are in different order.

It is worth checking if the trouble still happens when you use
databases created on Linux? And if error happens on Linux
when using databases created on Windows?

BTW: it seems that there is a difference between databases
created by ECL and databases created by sbcl. There is unused
"slot" in modemaps, AFAICS this slot has value 6 when using
sbcl, but is NIL with ECL. This difference affects ordering.
I am not sure if all differences can be explained by this
useless slot.

Re: [fricas-devel] regression on windows

2024-05-12 Thread Qian Yun


The problematic part is this line.

- Qian

diff --git a/src/interp/macros.lisp b/src/interp/macros.lisp
index f2bb9ecc..5db4335d 100644
--- a/src/interp/macros.lisp
+++ b/src/interp/macros.lisp
@@ -221,7 +221,7 @@
   (GO LP)))
   (RETURN (GGREATERP T1 T2)) ) )

-(defun GLESSEQP (X Y) (NOT (GGREATERP X Y)))
+(defun GLESSEQP (X Y) (|lt_sexp| X Y))

 (defun LEXLESSEQP (X Y) (|lt_sexp| X Y))

On 5/11/24 00:05, Waldek Hebisch wrote:

On Fri, May 10, 2024 at 05:10:45PM +0200, Grégory Vanuxem wrote:

For information, exhibited on SBCL-2.3.2 (GiHub) but also on SBCL-2.4.4. I
tried early this morning to revert parts of this commit without success, I
abandoned, it is too Lispish for me I think.


You can try to revert change to symbol.spad, change to i-resolv.boot,
second hunk in macros.lisp + change to vmlisp.lisp.  Those 3 are
independent on each other and to remaining changes.

At first glance change to i-resolv.boot is most likely to produce
effect below.  OTOH it should do the same thing an all systems...


Le ven. 10 mai 2024 à 15:32, Qian Yun  a écrit :


The recent commit "Simplify and fix ordering predicate"
causes regression on windows only, strange.

The failed test is in series3.input:

testcase "crashes coercing power series (#122, #136)"
a := series(sin(x))
testTrue("(a*1.0; true)")
testTrue("(1.0*a; true)")


Interpreter can't find proper signature.

- Qian



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/e5a1b4e0-0032-446a-9742-826834f3f39f%40gmail.com.

[fricas-devel] regression on windows

2024-05-10 Thread Qian Yun


The recent commit "Simplify and fix ordering predicate"
causes regression on windows only, strange.

The failed test is in series3.input:

testcase "crashes coercing power series (#122, #136)"
a := series(sin(x))
testTrue("(a*1.0; true)")
testTrue("(1.0*a; true)")


Interpreter can't find proper signature.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/dfa27b87-4807-4489-aaf0-11c9f6072ba7%40gmail.com.

[fricas-devel] [PATCH] build book with pdflatex

2024-05-08 Thread Qian Yun


I've updated
https://github.com/oldk1331/fricas/commits/new-ps-book/
to
https://github.com/oldk1331/fricas/commit/d88925e40c7aa14c776d7b2c99d1fc8483a57d27

This enables build of the book with pdflatex.

Together with previous commit "build with ps image",
these two commits removes almost 113K lines of ps code.

I've added 22 png files, total size 356KB.

As I said in the other thread, Chapter 14 needs some
modifications before this patch goes in.

This is just the first attempt, comments welcome.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/b22499e5-3db1-4985-9c40-0859f7f9aac2%40gmail.com.

[fricas-devel] obsolete hyperdoc buttons in chapter 14?

2024-05-08 Thread Qian Yun


For the reference book built with 1.3.10 release,
I believe the following 3 buttons are no longer available:

"Related operations" Figure 14.14 (page 874)

"generalize" Figure 14.19 (page 883)

"all domains" Figure 14.20 (page 883)

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/540f7365-16f7-446c-88e7-a730a9790634%40gmail.com.

Re: [fricas-devel] typesetting issue with spadfunFrom

2024-05-07 Thread Qian Yun


OK, there's 2 "write" on that page, the one under "viewWriteAvailable"
is wrong, the one under "viewWriteDefault" is right, but this one is
\spadfun, not \spadfunFrom.

Can you double check the one under "viewWriteAvailable"?

- Qian

On 5/8/24 05:23, Waldek Hebisch wrote:

On Mon, May 06, 2024 at 08:29:44PM +0800, Qian Yun wrote:

In page 242 of book.pdf (from 1.3.10 release), the "write" under
item "viewWriteDefault" is not correctly colored: only a quote is
colored as red.

The definition from fricas.sty is:

 \NewDocumentCommand{\spadfunFrom}{v v}{\spadfun`#1`}

Looks like the "`" is colored here.  But this doesn't happen
for other \spadfunFrom elsewhere.


Like Ralf I see correct coloring.  I would rather suspect that you
see a glitch in .pdf viewer (IME sometimes .pdf viewers show different
thing than they should).



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/712fc0d0-e279-48b5-8c47-16b2f1565d78%40gmail.com.

Re: [fricas-devel] on building the book with pdflatex

2024-05-07 Thread Qian Yun





On 5/7/24 22:08, Dima Pasechnik wrote:


sorry, typo, I meant

ps2eps knot3.ps



Thanks, I didn't know about this ps2eps tool.
It does convert knot3.ps to a proper eps format.


knot3.ps (and a few other vector images) will be removed very soon,
because we'll be able to generate them during build.  And yes,
to build with pdflatex, those ps images will be converted to pdf
format by epstopdf.


as I said, it's not needed. (eps is smaller than pdf)



Yes, pdflatex+graphics can use this eps file directly,
(but looks like it uses package epstopdf-pkg to do the
conversion in the background automatically.)

But eps is not smaller than pdf, for knot3, eps is 1.2MB
(same as ps format), pdf is 148KB.


So it looks like we have to use one of ps2eps or epstopdf.
And epstopdf is used in the background if we use ps2eps first.
So it still looks like using only epstopdf is the better
solution here.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/d0654251-01a4-49da-8f65-e33e0ebcb339%40gmail.com.

Re: [fricas-devel] on building the book with pdflatex

2024-05-07 Thread Qian Yun

On 5/7/24 21:45, Dima Pasechnik wrote:

On Tue, May 7, 2024 at 12:51 PM Qian Yun wrote:

Some decisions need to be made in order to build book with pdflatex.

1. src/doc/ps/ images.

These are hyperdoc images. They are in ps format, but actually are
bitmap images. pdflatex can't handle ps format directly, so I
suggest to convert them into png format.

pdflatex/xelatex/lualatex can handle eps images just fine.
You can first run ps2eps on the ps files.

E.g. I can take knot3.ps - one of the files, (which is not bitmap, but
a proper postscript) run

ps2pdf knot3.ps

producing knot3.eps, move knot3.ps out of the way, and then

You used both eps and pdf. I think you meant pdf here?

knot3.ps (and a few other vector images) will be removed very soon,
because we'll be able to generate them during build. And yes,
to build with pdflatex, those ps images will be converted to pdf
format by epstopdf.

The rest ps images are all bitmaps.

\documentclass{article}
\usepackage{graphics}
\begin{document}
\includegraphics{knot3}
\end{document}

works just fine.
Or, perhaps, you prefer xelatex, then you'd need
\usepackage[xetex]{graphics}

Dutto for lualatex, you'd use
\usepackage[luatex]{graphics}

IMHO one should not use pdflatex, which is obsolete, but switch to
lualatex or xelatex.

Dima

I think it'll be easy to support pdflatex/lualatex/xelatex all
at current stage, because there's no breaking features that
are used in tex source files, for example unicode support.

- Qian

[fricas-devel] on building the book with pdflatex

2024-05-07 Thread Qian Yun


Some decisions need to be made in order to build book with pdflatex.

1. src/doc/ps/ images.

These are hyperdoc images. They are in ps format, but actually are
bitmap images.  pdflatex can't handle ps format directly, so I
suggest to convert them into png format.

2. If the answer to previous question is yes, then shall we convert
from ps format, or shall we do the screenshots again to create
a higher resolution of those images.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0768deef-035e-474f-a14f-9cc5e59cf902%40gmail.com.

Re: [fricas-devel] [PATCH] fix races in sman

2024-05-06 Thread Qian Yun


Does this error persist if you redo the build by
cd src/doc; make clean; make book.pdf ?

If it persists, can you examine tmp/ug07.spool to see if there's
error related with the generation of this image.

- Qian

On 5/7/24 01:05, Ralf Hemmecke wrote:
This time the following error shows. And indeed 23DColB.ps is nowhere to 
be found.


Ralf

LaTeX Warning: File `23DColB.ps' not found on input line 612.


tmp/ug07.tex:612: LaTeX Error: File `23DColB.ps' not found.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
  ...

l.612 \epsffile[0 0 295 295]{23DColB.ps}

Output written on book.dvi (238 pages, 1767652 bytes).
Transcript written on book.log.
==> Detected problem while running LaTeX.
==> LaTeX must be installed.
==> The following LaTeX packages must be available.
==> amsmath, breqn, tensor, mleftright, graphicx, verbatim,
==> hyperref, color, listings, makeidx, xparse, tikz
make: *** [Makefile:895: book.dvi] Error 1
make: *** Waiting for unfinished jobs



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/e456e833-0e2a-42e8-aeee-7e62731cd7b1%40gmail.com.

[fricas-devel] typesetting issue with spadfunFrom

2024-05-06 Thread Qian Yun


In page 242 of book.pdf (from 1.3.10 release), the "write" under
item "viewWriteDefault" is not correctly colored: only a quote is
colored as red.

The definition from fricas.sty is:

\NewDocumentCommand{\spadfunFrom}{v v}{\spadfun`#1`}

Looks like the "`" is colored here.  But this doesn't happen
for other \spadfunFrom elsewhere.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/1623ccc7-a449-4bb6-b95f-643baf62b776%40gmail.com.

[fricas-devel] [PATCH] fix races in sman

2024-05-06 Thread Qian Yun


I have not met the races in graphics, but Ralf, Waldek and
I have all met the races in sman:

Namely, when building the book, sometimes there's a few lines
missing at the beginning or at the end of the tex file.
The tex file comes from spool file, which is the piped output
of "fricas" script.

This is quiet easily to reproduce if you build the book with
more jobs in parallel than the number of your threads of CPU.

First, the missing lines at the end.

sman kills all of its child processes if the FRICASsys quits.

For FRICASsys, its output goes to a pty, captured by "sman"
and forwards to "session" via socket, then "session" forward
to "spadclient" via socket, finally "spadclient" prints to
stdio.

So when FRICASsys outputs everything and quits, sometimes
sman kill everything while there's still a few final lines
in socket buffer, not printed out yet.

I solve this by adding sleep 100ms before "kill_all_children".


Second, for the missing liens at the beginning.

At startup, "spadclient" connects to "session", then "session"
connects to "FRICASsys" and get a prompt ("(1) -> ") back.

So after "connect_to_local_server", there's quite a few things
going on in the background.  So it is necessary to sleep a while
before forwarding stdio (in this case, ")read xxx" from pipe)
to "FRICASsys".  Otherwise sometimes the output order is messed up.


Ralf, please test if this fixes the build problem on your side.

- Qian

diff --git a/src/sman/sman.c b/src/sman/sman.c
index d5114624..05208cd3 100644
--- a/src/sman/sman.c
+++ b/src/sman/sman.c
@@ -773,9 +773,10 @@ monitor_children(void)
 }
 switch(proc->death_action) {
 case Die:
+  fricas_sleep(100);
   kill_all_children();
   clean_up_sockets();
-  fricas_sleep(200);
+  fricas_sleep(100);
   exit(0);
 case NadaDelShitsky:
   break;
diff --git a/src/sman/spadclient.c b/src/sman/spadclient.c
index b0121181..0e3f5bb9 100644
--- a/src/sman/spadclient.c
+++ b/src/sman/spadclient.c
@@ -56,6 +56,7 @@ main(void)
 {
   sock = connect_to_local_server(SessionServer, InterpWindow, Forever);
   bsdSignal(SIGINT, inter_handler,RestartSystemCalls);
+  fricas_sleep(60);
   remote_stdio(sock);
   return(0);
 }

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/2454d345-7990-40ac-ab93-2a278ebb16a9%40gmail.com.

Re: [fricas-devel] devaluate(Domain) at beginning of new domain in Spad

2024-05-06 Thread Qian Yun

On 5/6/24 13:35, Grégory Vanuxem wrote:

Hello Qian,

Le sam. 4 mai 2024 à 09:58, Qian Yun a écrit :

On 5/4/24 15:30, Grégory Vanuxem wrote:

As a matter of fact, use of FLINT in FriCAS:

My experience with FLINT is that is uses dense representation
for univariate polynomial.

That representation makes it fast for multiplication (when polynomials
are dense).

But I think very spare polynomial will choke it, for example

(x^1000+1)^n (for n is some small integer).

Wow, very specific here. In the real world, is it of use?
Cryptography? Theoretical mathematics?

Well, is your example ((2*x+2*x^5+13*x^9)^5)^750 useful in real world?
;-)

I think it's better to implement both and let user to choose dense
or sparse representation, or make an abstract interface that the
algorithm itself determines whether to use dense or sparse
representation.

I looked at SAGE and they also use FLINT for generic cases like the
one I mentioned.

I will likely take a look at PARI/GP, NTL and Singular, just to inform
me, I don't really know some libraries/softwares that handle
specifically well sparse representations of polynomials, For now I
will have a look at SAGE with the keyword :sparse when instantiating a
polynomial ring. Thanks for this example.

- Greg

FLINT uses sparse representation for multivariate polynomial.

- Qian

Re: [fricas-devel] [PATCH] generate book.pdf with PS image instead of bitmap image

2024-05-05 Thread Qian Yun





On 5/5/24 00:09, Waldek Hebisch wrote:

On Sat, May 04, 2024 at 11:13:14PM +0800, Qian Yun wrote:


On 5/4/24 22:01, Ralf Hemmecke wrote:


Anyway, by building with -j1 I got your branch compiled with a view3D
still running with 100% cpu usage after the build had successfully
finished.


I've never met this before.


I have written about it in messsage titled "Races in graphics".


I can't find this message.  Is this the recent reply to
"remove sleep to speed up draw" thread or an older mail?


This is not a new thing and core reason is not due to your patch.
Simply, your patch affects timing and _maybe_ increased probabilty
of this happening.  Or maybe the hang is just bad luck.

This 100% cpu usage is principle should be not very hard to
eliminate, but involves some tedious work.  And before doing
this work it would be good to know what Wayland folks are going to
break.



Regarding wayland, I believe XWayland will continue to provide
compatibility.  I've being using wayland for a long time and
hit no problems so far.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/9884ac44-895a-4d49-9e25-6791988d87bf%40gmail.com.

Re: [fricas-devel] [PATCH] generate book.pdf with PS image instead of bitmap image

2024-05-04 Thread Qian Yun




On 5/4/24 22:01, Ralf Hemmecke wrote:


Anyway, by building with -j1 I got your branch compiled with a view3D 
still running with 100% cpu usage after the build had successfully 
finished.


I've never met this before.


Looking at the book is a pleasure now. Qian, you really did a great job.
Some pictures look even better than in the printed version of the 
original Jenks book.


I think I can savely upstream

https://github.com/hemmecke/fricas/commit/d460657632ce3fb9f8b9ea83112642ba59a9e3a9

and then please recheck that there will be no hanging view3D (and 
friends) in your patch. I would like to test it again before you commit.


Ralf



I've rebased https://github.com/oldk1331/fricas/commits/new-ps-book/
to 
https://github.com/oldk1331/fricas/commit/7102a38052a58de2ac5dba33ec9ccb13b8981798


Please try this with a fresh build.  There should be no more problems.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/e0549719-254f-4f28-9bea-44962e6c72da%40gmail.com.

Re: [fricas-devel] [PATCH] generate book.pdf with PS image instead of bitmap image

2024-05-04 Thread Qian Yun


That's probably caused by tmp/ug07.input.

It doesn't hang here, but I do find that there are remaining processes
like viewman and view3D.

The problem is that there are multiple unclosed viewports.

The following fixup patch should solve that: by adding 5 images to
the book (section 7.1.9 and 7.1.10) and using "nullXtc" to
disable viewport creation in section 7.2.4 and 7.2.5.

https://github.com/oldk1331/fricas/commit/32716305e0e00ce1499e1d578092502e42badbf5


So I think that "nullXtc" should not be removed.
It is useful for the cases that we show the command into the book,
but do not actually execute it.

- Qian

On 5/4/24 16:08, Ralf Hemmecke wrote:

Qian,

I just compiled your new-ps-book branch
https://github.com/oldk1331/fricas/commit

https://github.com/oldk1331/fricas/commit/e34fadc066ee34b4b6a56ceadfa3284934166999

It leave one process hanging and thus does not finish. I must 
investigate, but have no time now. Will try more as soon as possible.


The process was a spadclient that ran with 100% CPU.

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/2a327466-e52f-4cfb-9f73-9b7f20e08764%40gmail.com.

[fricas-devel] [PATCH] fix display issue of "output" in book section 6.19

2024-05-04 Thread Qian Yun




On 5/2/24 20:51, Ralf Hemmecke wrote:


Another solution might be to add some ioHook to the "output" function.
I haven't actually looked into that.



I believe this is the correct path to go.

The documentation of "output$OutputPackage" explicitly says this
function displays its argument to ``algebra output'' stream.

So for the book, although we explicitly have
  )set out algebra off
This section and other places (e.g. section 2.5.1) still use
this "output" to do some basic IO to the algebra stream.

So in the patch I added ioHook for "mathprint2",
support the new ioHook in htex2input.awk and spool2tex.awk.

And I added a new file tex2tex.awk to combine adjacent blocks
which are both "AlgebraOutput" block or "MessageOutput".
(I think it can't be done cleanly in the same spool2tex.awk file.)

Also the change to REGSET.htex is to prevent long irrelevant output.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/c31318b4-5f01-4711-b458-1c672fd4a43b%40gmail.com.
diff --git a/src/algebra/out.spad b/src/algebra/out.spad
index 3ef0cb44..cc053346 100644
--- a/src/algebra/out.spad
+++ b/src/algebra/out.spad
@@ -30,14 +30,13 @@ OutputPackage : with
 == add
 --ExpressionPackage()
 E  ==> OutputForm
-putout ==> mathprint$Lisp
 
 s : String
 e : OutputForm
 l : List Any
 
 output e ==
-mathprint(e)$Lisp
+mathprint2(e)$Lisp
 void()
 output s ==
 output(s pretend E)
diff --git a/src/doc/Makefile.in b/src/doc/Makefile.in
index 83d317f2..0742b38f 100644
--- a/src/doc/Makefile.in
+++ b/src/doc/Makefile.in
@@ -134,7 +134,7 @@ HTEX2HT   = ${AWK} -f ${srcdir}/ht.awk
 HTEX2SECMENU  = ${AWK} -f ${srcdir}/secmenu.awk
 UGSYSCMD2HELP = ${AWK} -f ${srcdir}/syscmd.awk
 HTEX2INPUT= ${AWK} -f ${srcdir}/htex2input.awk
-SPOOL2TEX = ${AWK} -f ${srcdir}/spool2tex.awk
+SPOOL2TEX = ${AWK} -f ${srcdir}/spool2tex.awk | ${AWK} -f ${srcdir}/tex2tex.awk
 UGEXAMPLES= ${AWK} -f ${srcdir}/ugexamples.awk
 
 ###
diff --git a/src/doc/fricas.sty b/src/doc/fricas.sty
index 1f063a30..d22faeb4 100644
--- a/src/doc/fricas.sty
+++ b/src/doc/fricas.sty
@@ -267,6 +267,9 @@
 \lstnewenvironment{MessageOutput}%
   {\lstset{backgroundcolor=\color{bgmessagecolor}}}%
   {}
+\lstnewenvironment{AlgebraOutput}%
+  {\lstset{backgroundcolor=\color{bgalgebracolor}}}%
+  {}
 
 %% This one does not reset the line numbers. Does have horizontal rules.
 \lstnewenvironment{xmpLinesNoReset}%
@@ -403,6 +406,7 @@ Uni-var-iate-Poly-nomial
 % color settings
 \definecolor{bgspadinputcolor}{rgb}{0.95,1,0.95} % (green)  spad input boxes
 \definecolor{bgmessagecolor}{rgb}{1,0.95,0.95}   % (rose)   output messages
+\definecolor{bgalgebracolor}{rgb}{0.95,0.95,1}   % (blue)   algebra output
 \definecolor{bgcode}{rgb}{1,1,0.7}   % (yellow) spad source code
-\backgroundColor{bgmathoutput}[rgb]{0.95,0.95,1} % (gray)   spad output
+\backgroundColor{bgmathoutput}[rgb]{0.95,0.95,1} % (blue)   spad output
 \backgroundColor{bgresulttype}[rgb]{0.98,0.98,1} % (gray)   result type
diff --git a/src/doc/htex/REGSET.htex b/src/doc/htex/REGSET.htex
index f14e00ae..81de311a 100644
--- a/src/doc/htex/REGSET.htex
+++ b/src/doc/htex/REGSET.htex
@@ -378,7 +378,7 @@ Define a polynomial system.
 \begin{texonly}
 \typeout{--rhx: Warning: Remove semicolon in input --> output too long}
 \end{texonly}
-\xtc{
+\noOutputXtc{
 Let us try the information option.
 N.B. The timing should be between 1 and 10 minutes, depending on your machine.
 }{
diff --git a/src/doc/htex2input.awk b/src/doc/htex2input.awk
index 60f36221..bfe75a35 100644
--- a/src/doc/htex2input.awk
+++ b/src/doc/htex2input.awk
@@ -2,7 +2,16 @@ BEGIN {
 print ")set message autoload off"
 print "-- \\begin{inputonly}"
 print ")set break resume"
-print ")lisp (setf |$ioHook| (lambda (x  args) (cond ((eq x '|startKeyedMsg|) (SAY \"-- begin{MessageOutput}\")) ((eq x '|endOfKeyedMsg|) (SAY \"-- end{MessageOutput}\")) ((eq x '|startSysCmd|) (SAY \"-- begin{SysCmdOutput}\")) ((eq x '|endSysCmd|) (SAY \"-- end{SysCmdOutput}\")) ((eq x '|startPatternMsg|) (SAY \"-- begin{MessageOutput}\")) ((eq x '|endPatternMsg|) (SAY \"-- end{MessageOutput}\")"
+print ")lisp (setf |$ioHook| \
+(lambda (x  args) \
+  (cond ((eq x '|startKeyedMsg|) (SAY \"-- begin{MessageOutput}\")) \
+((eq x '|endOfKeyedMsg|) (SAY \"-- end{MessageOutput}\")) \
+((eq x '|startSysCmd|) (SAY \"-- begin{SysCmdOutput}\")) \
+((eq x '|endSysCmd|) (SAY \"-- end{SysCmdOutput}\")) \
+((eq x

[fricas-devel] bug in radicalSolve caused by 50f391bc

2024-05-04 Thread Qian Yun


I found this by accident, when comparing trunk book against
1.3.10 book.

In section 8.5.3 (page 316), there were 6 solutions.

(1) -> radicalSolve([3*x^3+y+1,y^2-4],[x,y])

   (1)  [[x = - 1, y = 2], [x = - 1, y = 2]]

Git bisect points to 50f391bc.



This raises the question that how can we make sure the
book content does not change unexpectedly like this?

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/aca4439c-5c0f-4557-9d5f-90c2e987169e%40gmail.com.

Re: [fricas-devel] devaluate(Domain) at beginning of new domain in Spad

2024-05-04 Thread Qian Yun





On 5/4/24 15:30, Grégory Vanuxem wrote:

As a matter of fact, use of FLINT in FriCAS:



My experience with FLINT is that is uses dense representation
for univariate polynomial.

That representation makes it fast for multiplication (when polynomials
are dense).

But I think very spare polynomial will choke it, for example

(x^1000+1)^n  (for n is some small integer).




So for FriCAS, lacking a dense representation makes it
performs very bad at certain tasks (for example, multiplication).

The karatsuba method implemented in
UnivariatePolynomialMultiplicationPackage is not working
at all because of the spare representation we have.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/cbee840e-8104-4f39-839e-87c91c962cac%40gmail.com.

Re: [fricas-devel] devaluate(Domain) at beginning of new domain in Spad

2024-05-03 Thread Qian Yun





On 5/4/24 12:43, Grégory Vanuxem wrote:

Hello,

I have found 'devaluate' in some Spad files and it can be handy. Some
domains are parameterized and it is not possible, or at least I don't
know how to do it, to use ' is ' instead of ' has ' (Domain vs.
Category) for them:

if R is Foo then
 new(n) == bar(n)
else
new...

it is not possible to use:
if Foo(p) then

Or like #1 in "SubDomain(Integer, #1 >= 0)" used for NonNegativeInteger?


I'm not sure I understand your problem 100%, are you looking for
something like PrimeField in ffdoms.spad?

if not prime?(p)$IntegerPrimesPackage(Integer) then


Also it's difficult to know your problem with 'devaluate' in your
code snippet. Is there a minimal reproducible example?

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/81462d8e-17a9-4d2f-8589-e3b76c049f39%40gmail.com.

Re: [fricas-devel] [PATCH] generate book.pdf with PS image instead of bitmap image

2024-05-02 Thread Qian Yun

I have committed all related patches, the patch in this thread is
the last one.

I have updated it a little bit to improve the build process and
fixed the pictures in section 10.5.

https://github.com/oldk1331/fricas/commit/e34fadc066ee34b4b6a56ceadfa3284934166999

So your changes should be based on master branch from now on.

But before I commit this patch, I really would like to see
you to commit
https://github.com/hemmecke/fricas/commit/d460657632ce3fb9f8b9ea83112642ba59a9e3a9

and

https://github.com/hemmecke/fricas/commit/32a50eeb2c762e4df3b42c5f0f9cb38aa4f2a811

first. These "noOutputXtc" patches.

I'm more familiar with these related areas and I'm confident
these changes are good to go.

- Qian

On 4/29/24 04:09, Ralf Hemmecke wrote:

Qian,

I assume that your patches are the same as your new-ps-book branch.
I somehow liked your idea for the "stamp-pics" target.
Currently, I am going slowly through the documentation and found a
number of bugs. See my branch

https://github.com/hemmecke/fricas/tree/wip/fricas-book.
(DANGER! I will freely rebase that on top of "master")
I'm not yet that far to include all you stuff of the ps generation.
As you see, I still have some old remnants of your old patches from your
ps-book branch. Maybe with your recent commits to master, some of them
could be removed from my branch.

Sorry that I am so slow, but I am working on it.

Ralf

Re: [fricas-devel] Missing /: (%, S) -> % in Fraction

2024-05-02 Thread Qian Yun


I guess by adding this new signature, it will cause problems for
type conferencing in compiler/interpreter.

There will be much more possibilities to consider.

IIRC, there's already performance issues when compiling expressions
with lots of "/", for example when solving radical roots for
degree 3/4 polynomials.  The recent radical denesting file may
be a similar case.

So it makes sense to let user do the coercion manually:

f : %
d : S
f/(d::%)

- Qian

On 5/3/24 01:22, Ralf Hemmecke wrote:

It is, of course, only a convenience, but I find it somewhat weird that
SPAD does not allow to divide a rational number by an integer.
The available signatures only say

http://fricas.github.io/api/Fraction.html#l4672616374696f6e-2f

   /: (%, %) -> %
   /: (S, S) -> %

but not

   /: (%, S) -> %

Would it be a bad idea to add such an implementation to Fraction?
Or even add a default implementationn like

((x: %) / (s: S)): % == numer(x) / (s*denom(x)

to QuotientFieldCategory?

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/1ea1d62e-fe8d-4842-9866-78d94c7ca194%40gmail.com.

[fricas-devel] display issue of "output" in book section 6.19

2024-05-02 Thread Qian Yun


In book section 6.19, the Pascal's triangle is not displayed.

It seems that "output" function displays stuff that are not
enclosed by ioHook.

Ralf, are you aware of this issue, and any ideas to fix it?

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/a5e66c5b-8f5e-4a8d-99f3-de63d3779c83%40gmail.com.

[fricas-devel] [PATCH] fix showing of units in "draw"

2024-05-02 Thread Qian Yun


Currently, draw(x,x=0..10,unit==[1.0,2.0])
does not show units by default, you have to click the control
panel button or use 'units(%,1,"on")'.

I think that by specifying "unit" options in "draw", the intention
is to show units.

This is also the case in some of the graphs in reference book,
for example in section 7.1.4 (page 234-236), where several graphs
should show units, but they didn't.

Following patch fixes this.

- Qian

diff --git a/src/algebra/view2D.spad b/src/algebra/view2D.spad
index bda55299..4799f336 100644
--- a/src/algebra/view2D.spad
+++ b/src/algebra/view2D.spad
@@ -808,6 +808,8 @@ TwoDimensionalViewport () : Exports == 
Implementation where

   viewport   := viewport2D()
   viewport.graphsField.1 := g
   viewport.optionsField := opts
+  if not empty? units(opts, []) then
+viewport.graphStatesField.1.units := yes
   makeViewport2D0 viewport

 makeViewport2D viewport == makeViewport2D0 copy(viewport::Rep)

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/bb88c685-409a-42f8-8567-89c1a3781304%40gmail.com.

[fricas-devel] [PATCH] misc fix "filecopy" "|waitForViewport|"

2024-05-01 Thread Qian Yun


For "filecopy", it's absurd to do IO char by char.

For "|waitForViewport|", this is left over of the previous
"obey" -> "|run_shell_command|" change.  Also avoid spawning
lot's of threads.

- Qian


diff --git a/src/graph/Gdraws/Gfun.c b/src/graph/Gdraws/Gfun.c
index 292f8b3b..2ec625c3 100644
--- a/src/graph/Gdraws/Gfun.c
+++ b/src/graph/Gdraws/Gfun.c
@@ -52,14 +52,16 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.

  * Given 2 file pointers, this function copies file ifp to file ofp
  */

+#define BUFFER_SIZE 4096
+
 static void
 filecopy(FILE * ifp, FILE * ofp)
 {
-
-  int c;
-
-  while ((c = getc(ifp)) != EOF)
-putc(c, ofp);
+  size_t bytesRead;
+  char buffer[BUFFER_SIZE];
+  while ((bytesRead = fread(buffer, 1, BUFFER_SIZE, ifp)) > 0) {
+  fwrite(buffer, 1, bytesRead, ofp);
+  }
 }

 /*
diff --git a/src/interp/util.lisp b/src/interp/util.lisp
index 939ddd19..faced223 100644
--- a/src/interp/util.lisp
+++ b/src/interp/util.lisp
@@ -273,11 +273,11 @@ After this function is called the image is clean 
and can be saved.

 (defun |waitForViewport| ()
   (progn
(do ()
-   ((not (zerop (obey
+   ((not (zerop (|run_shell_command|
 (concat
  "ps "
  |$ViewportProcessToWatch|
- " > /dev/null")
+ " > /dev/null && sleep 0.1")
())
(|sockSendInt| |$MenuServer| 1)
(|setIOindex| (- |$IOindex| 3))

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/33b71d79-3bc2-4149-b0cb-f60df00b7938%40gmail.com.

[fricas-devel] [PATCH] make the title font bigger in PS output

2024-05-01 Thread Qian Yun


This patch will make the font of title bigger than the axes label
(X/Y/Z) and units in PS image output.

This will make the default output more suitable for the book.
Unfortunately the font size is not customizable at SPAD level.

BTW, I checked the original book, most images are without title.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/398f32cf-5b2d-4000-aed7-a23592c68df1%40gmail.com.
diff --git a/src/graph/Gdraws/Gfun.c b/src/graph/Gdraws/Gfun.c
index 292f8b3b..7e5087b6 100644
--- a/src/graph/Gdraws/Gfun.c
+++ b/src/graph/Gdraws/Gfun.c
@@ -209,7 +209,7 @@ Gdraws_drawFrame(
   /* draw title text */
 
   psData[drawIstrps].flag = yes;
-  fprintf(fp, "\t%s\tloadFont\n\t%d\t(%s) stringwidth pop sub 2 div\n",
+  fprintf(fp, "\t%s\tloadTitleFont\n\t%d\t(%s) stringwidth pop sub 2 div\n",
   "frameDict", twInfo.width, title);
   fprintf(fp, "\t%d\t(%s)\t(%s)\tpsDrawIStr\n", 15, title, "title");
 
diff --git a/src/graph/Gdraws/ps_files/drawIstr.ps b/src/graph/Gdraws/ps_files/drawIstr.ps
index a33dda18..211a9bb4 100644
--- a/src/graph/Gdraws/ps_files/drawIstr.ps
+++ b/src/graph/Gdraws/ps_files/drawIstr.ps
@@ -1,20 +1,28 @@
 /psDrawIStr
 {   gsave
 newpath %% for rectangle
-loadFont
-
 /window exch def%% get window type
 
+window (title) eq
+{
+loadTitleFont
+/FontH TitleFontHeight def
+}
+{
+loadFont
+/FontH FontHeight def
+} ifelse
+
 %% draw bounding box with background color
 /str exch def   %% get text string
 str stringwidth pop 1 sub   %% width
-FontHeight 1 sub%% height
+FontH 1 sub %% height
 currentfont begin   %% get font height
 FontBBox
 end
 /ypos exch def pop  %% define ypos
 neg ypos add /offset exch def pop
-/offset ypos offset div FontHeight mul def %% define offset
+/offset ypos offset div FontH mul def   %% define offset
 /h exch def /w exch def %% define h
 /y0 exch def%% define y0
 /x0 exch def%% define x0
diff --git a/src/graph/Gdraws/ps_files/header.ps b/src/graph/Gdraws/ps_files/header.ps
index 037914ac..2cd7bb05 100644
--- a/src/graph/Gdraws/ps_files/header.ps
+++ b/src/graph/Gdraws/ps_files/header.ps
@@ -14,6 +14,7 @@
 100 dictbegin   %% using 100 entries in top level dictionary
 
 /FontHeight 12 def
+/TitleFontHeight 20 def
 
 /inch
 {   72 mul }
@@ -37,6 +38,10 @@
 {   /Times-Roman findfont FontHeight scalefont setfont }
 def
 
+/loadTitleFont
+{   /Times-Roman findfont TitleFontHeight scalefont setfont }
+def
+
 % draws a rectangle with input operand: 
 %   height
 %   width

Re: [fricas-devel] [PATCH] generate book.pdf with PS image instead of bitmap image

2024-04-27 Thread Qian Yun




On 4/26/24 18:23, Qian Yun wrote:



On 4/26/24 06:00, Waldek Hebisch wrote:


There is some problem with this.  On my machine I got faulty
'TEXTFILE.tex', it contained '\begin{noOutputXtc}' but no
matching end part, causing documentaion build failure.


This does not always happen, and sometimes happen to other
tmp/*tex file.  The problem is that this TeX file missing
a few last lines.

This commit changes the processing of input->spool->tex from
interpsys to fricas (with sman).  So I guess it is caused by
some buffering issues/race condition related to sman?

This can be workaround by adding a few "--" lines by
htex2input.awk.



More findings:

It seems that I can't reproduce this "missing final lines"
problem in single process environment.

So it seems like this doesn't happen when building book
with "make -j1".

Anyway, the attached patch make the generation of
input->spool->tex to use XVFB+sman only when needed.

Now I tested build with multiple processes many times
and encounter no failure.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/c7421509-bf38-42b2-a71c-0b9591cb397e%40gmail.com.
diff --git a/src/doc/Makefile.in b/src/doc/Makefile.in
index 0d4fa41a..74059d6b 100644
--- a/src/doc/Makefile.in
+++ b/src/doc/Makefile.in
@@ -632,9 +632,15 @@ ${HTEX_FILES_INPUT}: tmp/%.input: ${htexsrcdir}/%.htex
 HTEX_FILES_SPOOL = ${patsubst %, tmp/%.spool, ${HTEX_FILES}}
 ${HTEX_FILES_SPOOL}: tmp/%.spool: tmp/%.input
 	${MKDIR_P} tmp
-	(unset DAASE; FRICAS=${FRICAS}; export FRICAS; \
-		echo ')read $<' | FRICAS_INITFILE='' ${XVFB} \
-		${FRICAS}/bin/fricas -noht -noclef > $@)
+	if grep "^write.*postscript" $<; then \
+		(unset DAASE; FRICAS=${FRICAS}; export FRICAS; \
+			echo ')read $<' | FRICAS_INITFILE='' ${XVFB} \
+			${FRICAS}/bin/fricas -noht -noclef > $@); \
+	else \
+		(unset DAASE; FRICAS=${FRICAS}; export FRICAS; \
+			echo ')read $<' | FRICAS_INITFILE='' \
+			${FRICAS}/bin/fricas -nosman > $@); \
+	fi
 
 HTEX_FILES_TEX = ${patsubst %, tmp/%.tex, ${HTEX_FILES}}
 ${HTEX_FILES_TEX}: tmp/%.tex: tmp/%.spool

Re: [fricas-devel] fyi, update for Fricas 1.3.10 giving zero answer for integrate which is not zero

2024-04-27 Thread Qian Yun





On 4/19/24 22:01, Waldek Hebisch wrote:

On Fri, Apr 19, 2024 at 12:42:19AM -0700, 'Nasser M. Abbasi' via FriCAS - 
computer algebra system wrote:

FYI,

This is update for the final summer 2024 edition of CAS integration tests
about the issue Fricas giving zero for non zero integrand.

There are 4 such cases found out of 107,000 integrals.

Here they are


sqlite3 cas_integration_tests.db

sqlite> select COUNT(*) from main where fricas_anti="0";
6

But only 2 of these 6 cases should give zero. The rest should not.

  Here is the output from Fricas for the four cases:



The other 3 are plain bugs.



For those 3 bugs, they are all caused by dependent algebraic kernels.
FriCAS can solve them, if you substitute sqrt(6) to sqrt(2)*sqrt(3).

But is there a way to solve this kind of problems in general?

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/920ec8d4-ded6-4b87-8cd7-aa1fad7e5191%40gmail.com.

Re: [fricas-devel] [PATCH] generate book.pdf with PS image instead of bitmap image

2024-04-26 Thread Qian Yun

On 4/26/24 06:00, Waldek Hebisch wrote:

There is some problem with this. On my machine I got faulty
'TEXTFILE.tex', it contained '\begin{noOutputXtc}' but no
matching end part, causing documentaion build failure.

This does not always happen, and sometimes happen to other
tmp/*tex file. The problem is that this TeX file missing
a few last lines.

This commit changes the processing of input->spool->tex from
interpsys to fricas (with sman). So I guess it is caused by
some buffering issues/race condition related to sman?

This can be workaround by adding a few "--" lines by
htex2input.awk.

For me titles of pictures are too small, in bitmapped version
title letters are of comparable size to text letters, in .ps
version are smaller and almost unreadable when text has comfortable
size.

Yes, the old image is 300x300 while now is 400x400.
Also there is only one font size.

In the following patch I make the title font size different
from the axes label font and units font.

https://github.com/oldk1331/fricas/commit/103c0c04de8d6e1d38524a6d5aa2e4ee92742b0a.patch

I also noticed problem which has nothing to do with the patch:
in 5.4.5 there is an example computing 100!. In HyperDoc
number appears fine, but in the .pdf it is truncated.

Yeah, it would be hard to handle this automatically.
Solve this by introducing a new latex package to line
break long numbers?

In slightly different spirit: book convention of having separate
page numbers in "front matter" and in main part IMO is misguided
in .pdf: viewer allows navigation by page number, but number on
pages and numbers in viewer frequently diverge. IMO it would be
good to adopt uniform numbering.

Some pdf readers can handle this difference in page numbering.

Also, maybe print full section
number in the page header, that is 5.4.5 instad of current 5.4.

Well, even pages show chapter number, odd pages show section number,
leaves no space to show subsection number. Also some subsection
names are very long.

Also after this patch, src/doc/ps/arrowr.ps SEGBIND.ps knot3.ps
ribbon2r.ps ribbons2.ps ribbons2b.ps can be removed, saves 1.3MB
and 81123 lines from repo.

https://github.com/oldk1331/fricas/commit/46b2e034148674eb05834d8a642d337b1162b897.patch

I think that they should be removed in the same commit as your
patch (when it goes in).

Sure.

- Qian

[fricas-devel] [PATCH] generate book.pdf with PS image instead of bitmap image

2024-04-25 Thread Qian Yun


With this patch, the book.pdf uses PS format images instead of
using imagemagick to "covert" from bitmap xpm images.

Also as Ralf wishes, now the build of book is independent from
build of hypertex pages.

P.S to Ralf, this patch uses a few lines of your noOutputXtc patch,
you should upstream that first.

Also after this patch, src/doc/ps/arrowr.ps SEGBIND.ps knot3.ps
ribbon2r.ps ribbons2.ps ribbons2b.ps can be removed, saves 1.3MB
and 81123 lines from repo.

https://github.com/oldk1331/fricas/commit/46b2e034148674eb05834d8a642d337b1162b897.patch

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/3d4c161e-12ff-4bc3-8d82-7d0ed05f6d68%40gmail.com.
From 46b2e034148674eb05834d8a642d337b1162b897 Mon Sep 17 00:00:00 2001
From: Qian Yun 
Date: Thu, 25 Apr 2024 21:27:43 +0800
Subject: [PATCH] generate book with ps image instead of bitmap image

---
 src/doc/Makefile.in   | 29 +++--
 src/doc/fricas.sty|  4 +++-
 src/doc/htex/SEGBIND.htex |  2 +-
 src/doc/htex2input.awk| 28 ++--
 src/doc/spool2tex.awk |  3 +++
 src/doc/ugepsf.awk| 24 
 src/input/images1.input   |  7 ++-
 src/input/ug-pics.input   | 28 
 8 files changed, 82 insertions(+), 43 deletions(-)
 delete mode 100644 src/doc/ugepsf.awk
 create mode 100644 src/input/ug-pics.input

diff --git a/src/doc/Makefile.in b/src/doc/Makefile.in
index 7093802ec..68e214a62 100644
--- a/src/doc/Makefile.in
+++ b/src/doc/Makefile.in
@@ -46,9 +46,7 @@
 #
 # "make book.pdf" does the following:
 # - Copy pictures from the ps/ directory for (documentation of HyperDoc).
-# - Convert the *.VIEW/image.xpm pictures to .ps images (target stamp-pics).
-#   That expects all the .VIEW/ directories to exist (make viewports).
-#   It needs the convert program from ImageMagick. See ugepsf.awk.
+# - Copy pictures from tmp/*.VIEW/image.ps (target stamp-pics).
 # - Generate tmo/ug09.tex with the list of examples.
 # - Create tmp/*.input from htex/*.htex (target ${HTEX_FILES_INPUT}).
 #   The .input files contain the commands that should be executed.
@@ -138,7 +136,6 @@ UGSYSCMD2HELP = ${AWK} -f ${srcdir}/syscmd.awk
 HTEX2INPUT= ${AWK} -f ${srcdir}/htex2input.awk
 SPOOL2TEX = ${AWK} -f ${srcdir}/spool2tex.awk
 UGEXAMPLES= ${AWK} -f ${srcdir}/ugexamples.awk
-UGEPSF= ${AWK} -f ${srcdir}/ugepsf.awk
 
 ###
 # Most of the variables below are designed in the following way: If
@@ -297,7 +294,8 @@ HTEX_PASTEFILES = \
 # HyperDoc and book.pdf.
 # The list can be generated by the following command.
 # grep -R '\\spadcommand{)read' *| sed 's/[^ ]* //;s/[ \].*//'|sort -u
-INPUT_EXTRA = arrows bouquet newton ribbon vectors
+INPUT_EXTRA = arrows bouquet newton ribbon vectors \
+  ntube tknot images1 ug-pics
 
 ###
 # For these files .ht files will be generated.
@@ -634,7 +632,9 @@ ${HTEX_FILES_INPUT}: tmp/%.input: ${htexsrcdir}/%.htex
 HTEX_FILES_SPOOL = ${patsubst %, tmp/%.spool, ${HTEX_FILES}}
 ${HTEX_FILES_SPOOL}: tmp/%.spool: tmp/%.input
 	${MKDIR_P} tmp
-	echo ")read $<" | FRICAS_INITFILE='' ${INTERPSYS} > $@
+	(unset DAASE; FRICAS=${FRICAS}; export FRICAS; \
+		echo ')read $<' | FRICAS_INITFILE='' ${XVFB} \
+		${FRICAS}/bin/fricas -noht -noclef > $@)
 
 HTEX_FILES_TEX = ${patsubst %, tmp/%.tex, ${HTEX_FILES}}
 ${HTEX_FILES_TEX}: tmp/%.tex: tmp/%.spool
@@ -645,17 +645,12 @@ tmp/ug09.tex: tmp/examples.list
 	${MKDIR_P} tmp
 	${UGEXAMPLES} $< > $@
 
-pics.mk:
-	grep '\(\\head{\|\\psXtc\|\xtc\|\\noOutputXtc\|\\nullXtc\|epsffile\|\\spadgraph\)' ${srcdir}/htex/ug*.htex \
-	| ${UGEPSF} > $@
-
 ###
 # There are a number of pictures for sections in book.pdf that
 # demonstrate the use of HyperDoc.
 PS_FILES = \
   exit help home up	\
-  ribbon2r ribbons2 ribbons2b \
-  2Dctrl 3Dctrl SEGBIND arrowr knot3 \
+  2Dctrl 3Dctrl \
   h-alldoms h-allrank h-atsearch h-brfront h-comsearch h-consearch	\
   h-docsearch h-gensearch h-matargs h-matats h-matdesc h-matexamp	\
   h-matexports h-matimp h-matinv h-matmap h-matops h-matpage		\
@@ -665,8 +660,14 @@ PS_FILES_PS = ${patsubst %, %.ps, ${PS_FILES}}
 ${PS_FILES_PS}: %.ps: ${pssrcdir}/%.ps
 	cp $< $@
 
-stamp-pics: pics.mk viewports ${PS_FILES_PS}
-	${MAKE} -f pics.mk pics
+stamp-pics: ${INPUT_EXTRA_INPUT} ${HTEX_FILES_SPOOL} ${PS_FILES_PS}
+	${MKDIR_P} tmp
+	(unset DAASE; FRICAS=${FRICAS}; export FRICAS; \
+		echo ')read ug-pics' | FRICAS_INITFILE='' ${XVFB} \
+		${

[fricas-devel] [PATCH] enable "title" in PS format of image output

2024-04-23 Thread Qian Yun


This is the final piece of my fixes to PS output.

As discussed in previous thread, this patch enables title to
be shown in PS format output.

But I did not add a option to enable/disable the drawing of
frame over viewWindow and titleWindow.  First, this feature
does not exist for the screen output or bitmap output.
Second, this requires rather extensive changes, including
adding support on the SPAD side.  Third, this looks like
a debugging feature to me.  So I leave this portion of code
under "#if 0".

Some side notes: it looks like the PS related functions
are modeled after X11 APIs.  It looks like it was designed
with mono color at first, then added some color support,
but incomplete.  Some other parts also looks like unfinished
or unpolished.  Also the PS functions are too tightly tangled
with X11 logic, so it is too difficult to make the generation
of PS free of X11 dependency.


About next steps:

First is to use those generated PS images for the book.
I currently used a hack in htinp.c to generate PS image,
but a proper solution is needed, maybe by tweaking the
awk scripts.

Second is to make the book generated by pdflatex.

Third is to find a proper way to generate those fancy images
listed in appendix.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/5a8455d0-fd49-41bb-9377-859f86aba9ad%40gmail.com.
diff --git a/src/graph/Gdraws/Gfun.c b/src/graph/Gdraws/Gfun.c
index d86fdc07..43952d35 100644
--- a/src/graph/Gdraws/Gfun.c
+++ b/src/graph/Gdraws/Gfun.c
@@ -68,10 +68,10 @@ filecopy(FILE * ifp, FILE * ofp)
  */
 
 float Gdraws_computeScale(Window vw, Window tw) {
-  XWindowAttributes vwInfo;
+  XWindowAttributes twInfo;
   float pageWidth, pageHeight, scale;
 
-  XGetWindowAttributes(dsply, vw, );
+  XGetWindowAttributes(dsply, tw, );
   pageWidth = 575.0;
   pageHeight = 750.0;
 #if 0
@@ -81,8 +81,8 @@ float Gdraws_computeScale(Window vw, Window tw) {
   pageHeight *= 210.0;
   fprintf(stderr, "%f, %f\n", pageWidth, pageHeight);
 #endif
-  if ((vwInfo.width > pageWidth) || (vwInfo.height > pageHeight)) {
-scale = fminf(pageWidth / vwInfo.width, pageHeight / vwInfo.height);
+  if ((twInfo.width > pageWidth) || (twInfo.height > pageHeight)) {
+scale = fminf(pageWidth / twInfo.width, pageHeight / twInfo.height);
   } else {
 scale = 1.0;
   }
@@ -112,11 +112,7 @@ PSCreateFile(
   fprintf(fp, "\ngrestore\t%% restore graphics state\n\n");
   fclose(fp);
 
-#if 0
-  /* Make frame drawing optional. */
-
   Gdraws_drawFrame(bWidth, vw, tw, title);
-#endif
 
   /* put procedures and script together into OUTPUT.ps */
 
@@ -128,12 +124,12 @@ PSCreateFile(
 fprintf(ofp, "%%!PS-Adobe-2.0\n");
 
 /* Write a Bounding Box for psfig etc. */
-XWindowAttributes vwInfo;
-XGetWindowAttributes(dsply, vw, );
+XWindowAttributes twInfo;
+XGetWindowAttributes(dsply, tw, );
 float scale = Gdraws_computeScale(vw, tw);
 fprintf(fp, "BoundingBox: 0 0 %d %d\n",
-(int) ceilf(scale * vwInfo.width),
-(int) ceilf(scale * vwInfo.height));
+(int) ceilf(scale * twInfo.width),
+(int) ceilf(scale * twInfo.height));
 
 i = 1;
 while (i < psDrawNo) {  /* loops through each file/procedure */
@@ -195,16 +191,20 @@ Gdraws_drawFrame(
   fp = fopen(psData[scriptps].filename, "a");
 
   XGetWindowAttributes(dsply, viewWindow, );
+  XGetWindowAttributes(dsply, titleWindow, );
+
+  /* Make frame drawing optional. */
+#if 0
 
   /* draw title window */
 
-  XGetWindowAttributes(dsply, titleWindow, );
   fprintf(fp, "\t%s\t%d\t%d\t%d\t%d\ttitle\n", "frameDict",
   twInfo.height - vwInfo.height, twInfo.width, 0, vwInfo.height);
 
   /* draw viewport window */
 
   fprintf(fp, "\t%s\tdrawFrame\n", "frameDict");  /* using Gdraws_setDimension() */
+#endif
 
   /* draw title text */

[fricas-devel] [PATCH] fix 2D colored PS output

2024-04-22 Thread Qian Yun


Unlike the 3D case, where "GDrawPoint" is only limited involved,
in 2D case, "GFillArc" and "GDrawLine" are more widely used,
and even are used to draw the X11 interface itself.

So to avoid a bigger change and breakage, I duplicated code
to add new function "GColorFillArc" and "GColorLine".

This is not unprecedented, for example PSColorPolygon/PSFillPolygon.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/940d8bd0-a126-4f2c-823e-de1b2fe5bd1c%40gmail.com.
diff --git a/src/graph/Gdraws/Gfun.c b/src/graph/Gdraws/Gfun.c
index 5168de4e..d86fdc07 100644
--- a/src/graph/Gdraws/Gfun.c
+++ b/src/graph/Gdraws/Gfun.c
@@ -363,6 +363,47 @@ GDrawLine(
   return (s);
 }
 
+/*
+ * GColorLine draws a colored line, see GDrawLine
+ */
+
+int
+GColorLine(
+  GC gc,/* graphics context */
+  Window wid,   /* window id */
+  int x0, int y0, int x1, int y1, int color, int dFlag)
+{
+  int s = 0;
+
+  switch (dFlag) {
+  case Xoption:
+XSetForeground(dsply, gc, (unsigned long) color);
+XDrawLine(dsply, wid, gc, x0, y0, x1, y1);
+break;
+  case PSoption:
+{
+  PSsetrgbcolor(color);
+  FILE *fp;
+
+  if ((fp = fopen(psData[scriptps].filename, "a")) == NULL) {
+fprintf(stderr, "GColorLine cannot open %s\n",
+psData[scriptps].filename);
+return (psError);
+  }
+
+  psData[drawlineps].flag = yes;  /* sets procedure flag */
+  fprintf(fp, "\t%d\t%d\t%d\t%d\tpsColorLine\n",
+  x1, y1, x0, y0);
+  s = fclose(fp);
+}
+break;
+  default:
+fprintf(stderr, "GColorLine request (%d) not implemented yet.\n",
+dFlag);
+return (psError);
+  }
+  return (s);
+}
 
 
 
@@ -683,6 +724,52 @@ GFillArc(
   return (s);
 }
 
+/*
+ * Draws and fills an arc with color; see GFillArc
+ */
+
+int
+GColorFillArc(
+ GC gc, /* graphics context */
+ Window wid,/* window id */
+ int x, int y,
+ unsigned int wdth, unsigned int hght,
+ int ang1, int ang2, int color, int dFlag)
+{
+  int s = 0;
+
+  switch (dFlag) {
+  case Xoption:   /* angle: times 64 already */
+XSetForeground(dsply, gc, (unsigned long) color);
+XFillArc(dsply, wid, gc, x, y, wdth, hght, ang1, ang2);
+break;
+  case PSoption:
+{
+  PSsetrgbcolor(color);
+
+  FILE *fp;
+
+  if ((fp = fopen(psData[scriptps].filename, "a")) == NULL) {
+fprintf(stderr, "GColorFillArc cannot open %s\n",
+psData[scriptps].filename);
+return (psError);
+  }
+
+  psData[fillarcps].flag = yes;   /* sets procedure flag */
+  fprintf(fp, "\t%d %d\t%d %d\t%d %d\t%d %d\tpsColorFillArc\n",
+  x, y, hght, wdth, ang1 / 64, ang2 / 64,
+  x + wdth / 2, y + hght / 2);
+  s = fclose(fp);
+}
+break;
+  default:
+fprintf(stderr, "GColorFillArc request (%d) not implemented yet\n",
+dFlag);
+return (psError);
+  }
+  return (s);
+}
+
 /*
  * Initializes the path and files to be used.
  */
diff --git a/src/graph/Gdraws/ps_files/drawline.ps b/src/graph/Gdraws/ps_files/drawline.ps
index 80962689..74f3a059 100644
--- a/src/graph/Gdraws/ps_files/drawline.ps
+++ b/src/graph/Gdraws/ps_files/drawline.ps
@@ -7,3 +7,12 @@
 grestore }
 def
 
+/psColorLine
+{   gsave
+newpath
+yVal moveto
+yVal lineto
+stroke
+grestore }
+def
+
diff --git a/src/graph/Gdraws/ps_files/fillarc.ps b/src/graph/Gdraws/ps_files/fillarc.ps
index fb0547e1..f7e5d10e 100644
--- a/src/graph/Gdraws/ps_files/fillarc.ps
+++ b/src/graph/Gdraws/ps_files/fillarc.ps
@@ -18,3 +18,23 @@
 grestore }
 def
 
+/psColorFillArc
+{   gsave
+yVal moveto
+newpath
+/sfactor 4 index 4 index div def
+1 sfactor scale
+6 5 roll%%   x on top of stack
+3 index 2 div add   %% define x origin
+6 5 roll%%   y on top of stack
+6 5 roll%%   h on top of stack
+2 div add yVal sfactor div  %% define y origin
+5 4 roll%%   w on top of stack
+2 div   %% define radius
+5 3 roll%%   a1 a2 now on top
+1 index add
+arc %% draw clockwise arc
+fill
+

[fricas-devel] [PATCH] make the filename of PS output in viewport to "image.ps"

2024-04-21 Thread Qian Yun


Currently, when using "write" to write out a viewport, we have
"image.bm", "image.xpm", but also "fricas2D.ps", "fricas3D.ps".

This patch makes PS output to have unified name "image.ps".
This is more consistent and easier for follow up Makefile treatment.

Note that in the view2D/view3D control panel, you can also click
buttons to save image (instead of viewport directory) under
current directory, you can only save "fricas2D.ps" for 2D images,
and "fricas3D.xpm" "fricas3D.ps" for 3D images.  Here the name
distinction makes sense to avoid file overwrite.

- Qian

diff --git a/src/graph/view2D/write2d.c b/src/graph/view2D/write2d.c
index 05bbf62e..7968dd3a 100644
--- a/src/graph/view2D/write2d.c
+++ b/src/graph/view2D/write2d.c
@@ -184,15 +184,15 @@ writeViewport(int thingsToWrite)
   break;

 case Postscript:
-/*** Create postscript output for viewport (in fricas2D.ps) 
***/

+/*** Create postscript output for viewport (in image.ps) ***/
  fricas_sprintf_to_buf2(PSfilename, "%s%s", viewDirName,
-"/fricas2D.ps");
+"/image.ps");
  if (PSInit(viewport->viewWindow,viewport->titleWindow) == 
psError)

return (-1);
  drawViewport(PSoption);  /* write new script file in /tmp */
  if (PSCreateFile(viewBorderWidth,viewport->viewWindow,
   viewport->titleWindow, viewport->title) == 
psError)

-   return(-1);  /* concat script & proc into fricas2D.ps */
+   return(-1);  /* concat script & proc into image.ps */
   break;

 } /* switch on ii */
diff --git a/src/graph/view3D/write3d.c b/src/graph/view3D/write3d.c
index ac5a1210..344fb49e 100644
--- a/src/graph/view3D/write3d.c
+++ b/src/graph/view3D/write3d.c
@@ -194,15 +194,15 @@ writeViewport (int thingsToWrite)
   break;

 case Postscript:
-/*** Create postscript output for viewport (in fricas3D.ps) 
***/

+/*** Create postscript output for viewport (in image.ps) ***/
  fricas_sprintf_to_buf2(PSfilename, "%s%s", viewDirName,
-"/fricas3D.ps");
+"/image.ps");
  if (PSInit(viewport->viewWindow,viewport->titleWindow) == 
psError)

return(-1);
  drawViewport(PSoption);  /* write new script file in /tmp */
  if (PSCreateFile(viewBorderWidth,viewport->viewWindow,
   viewport->titleWindow, viewport->title) == 
psError)

-   return(-1);  /* concat script & proc into fricas3D.ps */
+   return(-1);  /* concat script & proc into image.ps */
  break;
 } /* switch on ii */
   }  /* if thingsToWrite >> ii */

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/e0635355-fedb-47cc-928c-5dbc105c7701%40gmail.com.

Re: [fricas-devel] [PATCH] remove "sleep" to speed up "draw"

2024-04-20 Thread Qian Yun


The patch deals with the beginning stage, transferring data
from fricas to view2/3D, that code deals with the ending stage,
writing data from view2/3D to disk.

Also the problem raised by "THEMOS" is mitigated by the "Fix" part.

But!!!  The mitigation was invalided by my "OBEY"->"|run_program|"
change.  Because |waitForViewport| uses a lowercase "obey" and
I missed it.

I was going to submit the following patch anyway.
There is a "sleep" to prevent spawning lots of processes.

- Qian

diff --git a/src/interp/util.lisp b/src/interp/util.lisp
index a3da8695..6f1ee95f 100644
--- a/src/interp/util.lisp
+++ b/src/interp/util.lisp
@@ -372,11 +372,11 @@ After this function is called the image is clean 
and can be saved.

 (defun |waitForViewport| ()
   (progn
(do ()
-   ((not (zerop (obey
+   ((not (zerop (|run_shell_command|
 (concat
  "ps "
  |$ViewportProcessToWatch|
- " > /dev/null")
+ " > /dev/null && sleep 0.05")
())
(|sockSendInt| |$MenuServer| 1)
(|setIOindex| (- |$IOindex| 3))


On 4/20/24 18:28, Ralf Hemmecke wrote:

Maybe this comment is connected to the sleep stuff...

https://github.com/fricas/fricas/blob/master/src/hyper/htinp.c#L351

==
THEMOS says: There is a problem here in that we issue the (|close|) and
then go on. If this is the last command, we will soon send a SIGTERM and
the whole thing will collapse maybe BEFORE the writing out has finished.
Fix: Call a Lisp function that checks (with \spadop{key} ps and grep) 
the health of the viewport. We do this after the (|close|).

==

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/6fd18a14-bcc5-4a11-a6e9-a9621b2d724f%40gmail.com.

[fricas-devel] Re: [PATCH] remove "sleep" to speed up "draw"

2024-04-20 Thread Qian Yun


I did not notice that "xvfb" is preinstall in the Linux CI
environment and thus the viewports have always been build
in the past.

Now after this patch, I can see the build time on Linux CI
(2 cores) has been dropped from 6m20s to 5m40s, about 10%.

And we can observe if this patch causes regression of build failures.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/9893943a-1e81-4c44-be4b-018f4bfe1eb3%40gmail.com.

Re: [fricas-devel] calling FriCAS functions from Lisp

2024-04-20 Thread Qian Yun


There is https://github.com/oldk1331/fricas0,
where fricas exists in the form of pure lisp,
but it is not in the sense of a "traditional lisp library"
by ASDF or DEFPACKAGE.

I can look into this direction.

- Qian

On 4/20/24 17:47, Dima Pasechnik wrote:

How does one do this?
(with ECL or SBCL).

Presumably if one makes a FriCAS fasl library (how?), it should be possible
to call FriCAS functions from Lisp without going through files or pipes.

That's certainly possible (and used in Sage) with Maxima.

Thanks
Dima

  



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/f325257c-70b5-47a0-8eb7-b7d9411cee3c%40gmail.com.

[fricas-devel] [PATCH] install fricas-readline to target directory

2024-04-19 Thread Qian Yun


Currently fricas-readline is not installed to ./target/*/bin/.

I find it useful to debug with readline support:

  cd target/x86_64-linux-gnu
  FRICAS=. ./bin/fricas -rl

Because readline's history feature is really convenient when
you need to input the same things over and over again during debugging.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/92f21094-b30b-4b5f-99b6-1d3670cda7fa%40gmail.com.
diff --git a/src/etc/Makefile.in b/src/etc/Makefile.in
index 35484b1f..a008c9de 100644
--- a/src/etc/Makefile.in
+++ b/src/etc/Makefile.in
@@ -18,6 +18,7 @@ stamp-databases:
 stamp: $(fricas_target_libdir)/summary \
 		$(fricas_target_libdir)/copyright \
 		$(fricas_target_bindir)/fricas \
+		$(fricas_target_bindir)/fricas-readline \
 $(fricas_target_libdir)/SPADEDIT \
 $(fricas_target_libdir)/command.list
 	$(STAMP) stamp
@@ -73,6 +74,10 @@ $(fricas_target_bindir)/fricas: $(srcdir)/fricas
 	cp $< $@
 	chmod +x $@
 
+$(fricas_target_bindir)/fricas-readline: $(srcdir)/fricas-readline
+	cp $< $@
+	chmod +x $@
+
 mostlyclean-local:
 	-rm -f stamp stamp-databases stamp-do-databases

[fricas-devel] Re: [PATCH] fix color in 3D "smooth" style in postscript output

2024-04-19 Thread Qian Yun


Also the calculation of rgb and print of "setrgbcolor"
should be made into a separate function, because the
2D PS output will need this as well.

- Qian

On 4/19/24 19:10, Qian Yun wrote:

I'd like to also include the following in this patch.

You will notice that the ps output has a strange gray background.

The following code snippet is responsible for setting color.

#define psShadeMax  17.0    /* same as XShadeMax */
#define psShadeMul  (1.0/(psShadeMax-1.0))  /* white and 16 gray 
shades */


It makes no sense to compute a constant grey color and use it.
(I guess it was mono color so put a grey background there?)

Let's simply have a white background instead.

- Qian

diff --git a/src/graph/view3D/smoothShade3d.c 
b/src/graph/view3D/smoothShade3d.c

index 7e80157a..432a0f98 100644
--- a/src/graph/view3D/smoothShade3d.c
+++ b/src/graph/view3D/smoothShade3d.c
@@ -567,8 +567,7 @@ scanLines(int dFlag)
  XFillRectangle(dsply,viewport->viewWindow,trashGC,0,0,
     vwInfo.width,vwInfo.height);
    } else {
-    GSetForeground(GC9991,
- 1.0-(float)((int)(psShadeMax-0.3*psShadeMax)-1)*psShadeMul,dFlag);
+    GSetForeground(GC9991, psWhite, dFlag);
  quadMesh[0].x = 0;  quadMesh[0].y = 0;
  quadMesh[1].x = graphWindowAttrib.width+2;
  quadMesh[1].y = 0;


On 4/18/24 17:57, Qian Yun wrote:

Currently we get mono color in postscript output of "smooth" style
3D drawings.

That's caused by "GSetForeground" before "GDrawPoint".
"GSetForeground" can only set gray scale.

Luckily the all four usage of "GDrawPoint" are all for the purpose
of generating "smooth" style image.  So this change will not break
anywhere else.

So I decode color and use "setrgbcolor" for it and remove
"installGC" from "drawpoint.ps" because that's responsible for
setting the grey color.

- Qian


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0e864821-510e-4880-89af-312fc1c94fd3%40gmail.com.

Re: [fricas-devel] [PATCH] remove "sleep" to speed up "draw"

2024-04-19 Thread Qian Yun

On 4/19/24 20:41, Waldek Hebisch wrote:

Long ago I looked at communication protocol between various
processes that we use and my conclusion was that it is
inherently racy: there are parallel chanels of communication
and both ends assume that data comes in right order. I added
a little piece of code to detect lost race, that mitigates
worst things. Machines now are faster than in the past,
so lost races probably are quite rare given 1s delay.
It is quite possible that original authors after realizing
that there are races put delays in places that are not necessary
(and wrogly placed delay could even make races worse).

To explain more: most of C code uses sockets and this alone should
be OK. However, data from FRICASsys sends textual output on
standard output, which is captured by 'sman'. But "event indicators"
are sent via sockets, so we depend on data on FRICASsys standard
output and data coming via sockets to arrive in order in which
it was sent.

In this particular case, it is not socket, but pipe.

The only reason to put a "sleep" here,
I presume it is a workaround for a bug in viewAlone:

See the "printf" I removed bellow: it writes to stdout instead of
stderr, causing the parent process function "readViewport" to return
early and make parent process exits, and the data passed to child
process via pipe is lost.

IIRC 'viewAlone' is started from HyperDoc when you click on a image.
Normal graphics uses 'view2D' and 'view3D' via 'viewman'.

Anyway, I think it would be reasonably safe to use smaller delay,
say 50 or 100 milliseconds (I use such delay during startup).
Quite possible that we can elliminate the delays, but that IMO
would require deeper analysis and more testing. As I wrote we
have several channels of communication and code assumes certain
ordering contraints. Without identifying contraints (and some
could be far from obvious) and analysing them it is hard to say
more than "there are races".

This case is rather straight forward I think, viewman/viewAlone
forks and passes data to child process view2D/view3D via pipe,
then child process writes a value after receiving all data,
then viewAlone exits while viewman sends it via sock to fricas
and continues to run.

I can accept the 100ms sleep as well. But could you give this
another review based on the new information I provided?

- Qian

BTW: My inital motivation for work on streams was to pass all
FRICASsys (actually it was called AXIOMsys at that time) output
to sockets, which would allow messages with confirmation.

[fricas-devel] [PATCH] remove "sleep" to speed up "draw"

2024-04-19 Thread Qian Yun


You can notice a "pause" when you draw a picture like:

(1) -> draw(x,x=1..2)
   Compiling function %C with type DoubleFloat -> DoubleFloat
   Graph data being transmitted to the viewport manager...
   FriCAS2D data being transmitted to the viewport manager...
<<<>>>
   (1)  TwoDimensionalViewport: "x"

It is also very noticeable when you generate the viewports.

The following numbers are build with 8 cores.

This is build without X11.

real1m52.533s
user6m47.266s
sys 0m58.385s


This is build with X11.  So it takes 11s more CPU time
to build hyperdoc/graphics binary and run them to
generate hyperpages and viewports.

But the user have to wait 1 more minute to see the build
finish.  Most time is wasted on this "sleep".

real2m52.534s
user6m58.368s
sys 0m55.921s


This is build with X11 and this patch.
This takes 14s more CPU time and 9s real time.

real2m1.381s
user7m0.911s
sys 0m56.194s


The "readViewport" and "send_int" are synchronized IO,
so no race condition here.  The only reason to put a "sleep" here,
I presume it is a workaround for a bug in viewAlone:

See the "printf" I removed bellow: it writes to stdout instead of
stderr, causing the parent process function "readViewport" to return
early and make parent process exits, and the data passed to child
process via pipe is lost.

- Qian

diff --git a/src/graph/viewAlone/spoon2D.c b/src/graph/viewAlone/spoon2D.c
index 480dab6b..0bc94a43 100644
--- a/src/graph/viewAlone/spoon2D.c
+++ b/src/graph/viewAlone/spoon2D.c
@@ -82,7 +82,6 @@ spoonView2D(void)
 close(pipe0[1]);
 close(pipe1[0]);
 close(pipe1[1]);
-printf("(spoon2D child) start the TwoDimensionalViewport process\n");
 fricas_sprintf_to_buf1(errorStr, "%s",
 "(viewAlone) execution of the TwoDimensionalViewport process");
 env_fricas = getenv("FRICAS");
@@ -150,7 +149,6 @@ spoonView2D(void)
 /*** get acknowledge from viewport */

 code = read(viewP.viewIn,&(viewP.viewWindow),sizeof(Window));
-sleep(1);  /* wait a second...*/
 exit(0);

   }   /* switch */
diff --git a/src/graph/viewAlone/spoonComp.c 
b/src/graph/viewAlone/spoonComp.c

index ed0ce619..dc0786cb 100644
--- a/src/graph/viewAlone/spoonComp.c
+++ b/src/graph/viewAlone/spoonComp.c
@@ -169,7 +169,6 @@ spoonView3D(int type)

 /*** get acknowledge from viewport */
 code = read(viewP.viewIn,&(viewP.viewWindow),sizeof(Window));
-sleep(1);  /* wait a second...*/
 exit(0);

   }   /* switch */
diff --git a/src/graph/viewman/fun2D.c b/src/graph/viewman/fun2D.c
index 4b55a963..87ec3350 100644
--- a/src/graph/viewman/fun2D.c
+++ b/src/graph/viewman/fun2D.c
@@ -294,7 +294,6 @@ forkView2D(void)
  /*** get acknowledge from viewport */

 code = readViewport(viewport,&(viewport->viewWindow),sizeof(Window));
-sleep(1);  /* wait a second...*/
 send_int(spadSock,viewport->PID);  /* acknowledge to spad */

   }   /* switch */
diff --git a/src/graph/viewman/fun3D.c b/src/graph/viewman/fun3D.c
index 795b23d3..53ab32c9 100644
--- a/src/graph/viewman/fun3D.c
+++ b/src/graph/viewman/fun3D.c
@@ -405,7 +405,6 @@ forkView3D(int typeOfViewport)

  /*** get acknowledge from viewport */
 code = readViewport(viewport,&(viewport->viewWindow),sizeof(Window));
-sleep(1);  /* wait a second...*/
 send_int(spadSock,viewport->PID);  /* acknowledge to spad */

   }   /* switch */

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0962a538-2ad2-45c5-b051-d4a71dc25c82%40gmail.com.

[fricas-devel] Re: [PATCH] fix color in 3D "smooth" style in postscript output

2024-04-19 Thread Qian Yun


I'd like to also include the following in this patch.

You will notice that the ps output has a strange gray background.

The following code snippet is responsible for setting color.

#define psShadeMax  17.0/* same as XShadeMax */
#define psShadeMul  (1.0/(psShadeMax-1.0))  /* white and 16 gray 
shades */


It makes no sense to compute a constant grey color and use it.
(I guess it was mono color so put a grey background there?)

Let's simply have a white background instead.

- Qian

diff --git a/src/graph/view3D/smoothShade3d.c 
b/src/graph/view3D/smoothShade3d.c

index 7e80157a..432a0f98 100644
--- a/src/graph/view3D/smoothShade3d.c
+++ b/src/graph/view3D/smoothShade3d.c
@@ -567,8 +567,7 @@ scanLines(int dFlag)
 XFillRectangle(dsply,viewport->viewWindow,trashGC,0,0,
vwInfo.width,vwInfo.height);
   } else {
-GSetForeground(GC9991,
- 1.0-(float)((int)(psShadeMax-0.3*psShadeMax)-1)*psShadeMul,dFlag);
+GSetForeground(GC9991, psWhite, dFlag);
 quadMesh[0].x = 0;  quadMesh[0].y = 0;
 quadMesh[1].x = graphWindowAttrib.width+2;
 quadMesh[1].y = 0;


On 4/18/24 17:57, Qian Yun wrote:

Currently we get mono color in postscript output of "smooth" style
3D drawings.

That's caused by "GSetForeground" before "GDrawPoint".
"GSetForeground" can only set gray scale.

Luckily the all four usage of "GDrawPoint" are all for the purpose
of generating "smooth" style image.  So this change will not break
anywhere else.

So I decode color and use "setrgbcolor" for it and remove
"installGC" from "drawpoint.ps" because that's responsible for
setting the grey color.

- Qian


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/18693513-a368-44c6-8783-a46980d51ffc%40gmail.com.

Re: [fricas-devel] generate images from sources in appendix

2024-04-18 Thread Qian Yun





On 4/16/24 22:38, Waldek Hebisch wrote:


Just a silly question: have you looked why the image is so big?
Your new image is 6.7M and bigger than scanned version (4.3M).
Old knot3.ps is 77k lines giving 1.1M size.  At first glance
adding color to this could double or maybe triple the size.
.pdf uses compression, compressed knot3.ps is 153k.  So
I would expect .pdf of order 0.5M.



Update on image size:

The 3D "smooth" style is pixel-for-pixel bitmap.
So for colored knot3 image (400x400):
ps is 2.1MB
xpm is 320KB
pdf is 208KB (converted from ps)
png is 28KB (converted from xpm)


The only difference/advantage of PS format is that it has
vector font (for x/y/z, title, etc).

So if the image have no axes and no title, just colored pixels,
we can use png format.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/e1fc0e76-cec0-4dc7-ae26-93c863624287%40gmail.com.

[fricas-devel] [PATCH] fix color in 3D "smooth" style in postscript output

2024-04-18 Thread Qian Yun


Currently we get mono color in postscript output of "smooth" style
3D drawings.

That's caused by "GSetForeground" before "GDrawPoint".
"GSetForeground" can only set gray scale.

Luckily the all four usage of "GDrawPoint" are all for the purpose
of generating "smooth" style image.  So this change will not break
anywhere else.

So I decode color and use "setrgbcolor" for it and remove
"installGC" from "drawpoint.ps" because that's responsible for
setting the grey color.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/32851d37-cad8-4a06-a69f-aa5090c07325%40gmail.com.
diff --git a/src/graph/Gdraws/Gfun.c b/src/graph/Gdraws/Gfun.c
index a4a3bb01..6fd0116d 100644
--- a/src/graph/Gdraws/Gfun.c
+++ b/src/graph/Gdraws/Gfun.c
@@ -425,6 +425,7 @@ int
 GDrawPoint(
Window wid,  /* window id */
GC gc,   /* graphics context */
+   int color,   /* color is represented as 0xRRGGBB */
int x0, int y0, int dFlag)
 {
   int s = 0;
@@ -444,8 +445,14 @@ GDrawPoint(
   }
 
   psData[drawpointps].flag = yes; /* sets procedure flag */
-  fprintf(fp, "\t%s\t%d\t%d\t%d\t%d\tpsDrawPoint\n",
-  PSfindGC(gc), x0, y0, x0 + 1, y0 + 1);
+
+  float r = ((color & 0xFF) >> 16) / 255.0;
+  float g = ((color & 0x00FF00) >> 8) / 255.0;
+  float b = (color & 0xFF) / 255.0;
+  fprintf(fp, "\t%f\t%f\t%f\tsetrgbcolor\n", r, g, b);
+  fprintf(fp, "\t%d\t%d\t%d\t%d\tpsDrawPoint\n",
+  x0, y0, x0 + 1, y0 + 1);
+
   s = fclose(fp);
 }
 break;
diff --git a/src/graph/Gdraws/ps_files/drawpoint.ps b/src/graph/Gdraws/ps_files/drawpoint.ps
index 1850f08a..1981e1ad 100644
--- a/src/graph/Gdraws/ps_files/drawpoint.ps
+++ b/src/graph/Gdraws/ps_files/drawpoint.ps
@@ -3,7 +3,7 @@
 newpath
 yVal moveto
 yVal lineto
-begin installGC stroke end   %%fills with foreground color
+stroke
 grestore }
 def
 
diff --git a/src/graph/include/Gfun.H1 b/src/graph/include/Gfun.H1
index b3993d99..702ce7be 100644
--- a/src/graph/include/Gfun.H1
+++ b/src/graph/include/Gfun.H1
@@ -5,7 +5,7 @@ extern int GDrawImageString(GC, Window, int, int, char *, int, int);
 extern int GDrawArc(GC, Window, int, int, unsigned int, unsigned int, int, int, int);
 extern int GDrawLine(GC, Window, int, int, int, int, int);
 extern int GDrawLines(GC, Window, XPoint *, int, int, int);
-extern int GDrawPoint(Window, GC, int, int, int);
+extern int GDrawPoint(Window, GC, int, int, int, int);
 extern int GDrawString(GC, Window, int, int, char *, int, int);
 extern int GFillArc(GC, Window, int, int, unsigned int, unsigned int, int, int, int);
 extern int PSGlobalInit(void);
diff --git a/src/graph/view3D/smoothShade3d.c b/src/graph/view3D/smoothShade3d.c
index 51761863..7e80157a 100644
--- a/src/graph/view3D/smoothShade3d.c
+++ b/src/graph/view3D/smoothShade3d.c
@@ -133,7 +133,7 @@ drawPhongSpan(triple pt,float N[3],int dFlag)
   put_cBuffer_axes(xpixel,'0');
   put_zBuffer(xpixel,zC);
   /* if mono (bw dsply) do black and white semi-random dithering */
-  if (mono || (dFlag == PSoption) || viewport->monoOn) {
+  if (mono || viewport->monoOn) {
 if (get_random() < 100.0*exp((double)-1.3*(pi_sq*(col-.2)*(col-.2  {
   put_cBuffer_indx(xpixel,black);
 } else {
@@ -649,8 +649,8 @@ scanLines(int dFlag)
 else pixColor = boxInline;
 if (i >=0 && iviewWindow, GC9991, i,scanline,dFlag);
+GDrawPoint(viewport->viewWindow, GC9991,
+   (int) psBlack, i, scanline, dFlag);
   }
 }
   }
@@ -662,8 +662,8 @@ scanLines(int dFlag)
 else pixColor = clipBoxInline;
 if (i >=0 && iviewWindow, GC9991, i,scanline,dFlag);
+GDrawPoint(viewport->viewWindow, GC9991,
+   (int) psBlack, i, scanline, dFlag);
   }
 }
   }
@@ -675,8 +675,8 @@ scanLines(int dFlag)
 else pixColor = monoColor(axesColor);
 if (i >=0 && iviewWindow, GC9991, i,scanline,dFlag);
+GDrawPoint(viewport->viewWindow, GC9991,
+   (int) psBlack, i, scanline, dFlag);
   }
 } /* if buffer slot is an axes point */
 tempA = get_cBuffer_axes(i);
@@ -689,8 +689,8 @@ scanLines(int dFlag)
   if (i >=0 && iviewWindow, GC9991, i,scanline,dFlag);
+  GDrawPoint(viewport->viewWindow, GC9991,
+ get_cBuffer_indx(i), i, scanline, dFlag);
 }
   }
 } /* for each pixel in scanline */

Re: [fricas-devel] Slow formal derivatives

2024-04-17 Thread Qian Yun


https://github.com/oldk1331/fricas/commit/642ce7d42e4168313816ba2dd703bfa04efa4cf0

Here is a sketch implementation of this idea,
now dummyvars are gone.  The new implementation
is much shorter than the old one.  The nesting kernels
of high order derivatives are gone as well.

- Qian

On 4/16/24 20:47, Qian Yun wrote:

(I have not tried to implement the following idea in FriCAS.)

I have always liked the idea presented in SICM (sister book
of SICP) Structure and Interpretation of Classical Mechanics:

https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/9579/sicm_edition_2.zip/chapter001.html

No dummy var involved. Instead view "diff" as a higher order
operator: it acts on other operator and returns a new operator.

So instead of the having new kernels (and new dummy var)
for each new argument,

(1) -> f := operator 'f

    (1)  f

(2) -> argument first kernels D(f(x),x)

    (2)  [f(%A), %A, x]

(3) -> argument first kernels D(f(x^2),x)

  2
    (3)  [f(%B), %B, x ]



(4) -> argument first kernels D(f(x^3),x)

  3
    (4)  [f(%C), %C, x ]

The new plan should be generating a "new operator" "%diff(f)"
and its argument are x,x^2,x^3 respectively.

This "new operator" "%diff(f)" can store the argument "f"
into its properties, I guess.  And add special "%equal" for it.

- Qian

On 4/16/24 09:43, Waldek Hebisch wrote:

If you look at 'src/input/derham.input' you will notice comment
saying that it is quite slow for large n.  I looked a bit
at this and first observation is that slowness is due to
kernel manipulations.  Profile shows that almost all time goes
into kernel maniputation, mainly 'SCACHE;linearSearch'.
This is called from 'FS-;diffdiff' which is responsible for
differentiating formal derivatives.  Linear search is necessary
due to the way we implement formal derivatives.  But it is
actually worse: repeating the same calculation shows growing
time.  Just to see scale, one of calculation in
'src/input/derham.input' is to calculate second exterior
derivative of general form in n variables.  General form
involves n formal function in n variables.  First exterior
derivative needs to compute n^2 partial derivatives (n functions
times n variables).  Second exterior derivative needs
n(n-1)n partial derivatives.  So togeter about n^3 derivatives.
For n=8 this is about 512.  Even squared (due to linear search)
this does not look like very large number of operations.
However, formal derivative of order 2 contains derivatives of
order 1.  And it seems that due to use of dummies we create
new kernels, so when we repeat calculation, then our cache keep
growing.

This suggest that we should re-think representation of formal
derivatives and possibly also use of dummies.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/23beda5b-86d1-440f-9556-84db25b67841%40gmail.com.

[fricas-devel] [PATCH] fix "write" of "smooth" style image in postscript format

2024-04-17 Thread Qian Yun


vp := draw(x*y,x=0..1,y=0..1,style=="smooth")
write(vp, "t1", "postscript")

Then check "t1.VIEW/fricas3D.ps", you'll see only axes there.

After this patch, there will be black and white image. (this is
another bug.)

However, if you save the image by clicking buttons in
the control panel, you can have the black and white image.

As you can see that in process3d.c (responsible for the button
to save PS file):

redoSmooth = yes;
drawViewport(PSoption); /* draw picture in PS; create ps script 
file */


- Qian

diff --git a/src/graph/view3D/write3d.c b/src/graph/view3D/write3d.c
index ac5a1210..9ccd4c32 100644
--- a/src/graph/view3D/write3d.c
+++ b/src/graph/view3D/write3d.c
@@ -199,6 +199,7 @@ writeViewport (int thingsToWrite)
 "/fricas3D.ps");
  if (PSInit(viewport->viewWindow,viewport->titleWindow) == 
psError)

return(-1);
+redoSmooth = yes;
  drawViewport(PSoption);  /* write new script file in /tmp */
  if (PSCreateFile(viewBorderWidth,viewport->viewWindow,
   viewport->titleWindow, viewport->title) == 
psError)


--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/28e84d63-3d81-4be9-b89d-61501723828d%40gmail.com.

[fricas-devel] "title" in image output

2024-04-17 Thread Qian Yun


This "title" thing is more complex than I thought.

For  vp:=draw(x,x=0..1); write(vp,"pic", FORMAT)

When FORMAT is:

"pixmap" or "bitmap":
generates 400x400 image, title is the same as screen output

"image":
generates 300x324 image, title is 24 pixel higher than screen output

"postscript":
generates 400x376 image currently, no title.
I can modify it to generate 400x400 image with title the same
as screen output.


The "image" format is currently used by hypertex to generate
*.VIEW and convert to images used in book.


I will change "postscript" to generate 400x400 image with title.

However, shall we change the "image" format?  I mean what's the
point of generating a smaller image and taller title?  Is that
required by hyperdoc somehow?

My guess is that making the image smaller can make the title
font relatively larger.
I think 300x324 is a mistake, it calculated titleHeight twice.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/03075a6a-318d-4d7d-8614-2ac1e4c2427c%40gmail.com.

Re: [fricas-devel] generate images from sources in appendix

2024-04-16 Thread Qian Yun





On 4/17/24 08:18, Waldek Hebisch wrote:


On average a "shade" style picture takes around 50-200KB and
a "smooth" style picture takes 200-400KB depending on the complexity
of the picture.


I admit that for me "shade" style looks better than "smooth".



For knot3 I'm OK with both "shade" and "smooth".  For some pics
"shade" look better and for others "smooth" look better.

Here I'm just mimicking the style from the scanned version.

Do you think we should include those pictures in
fricas-reference-book? (with styles tweaked, of course.)

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/922532de-43c8-4d2e-bf55-7496ceffe940%40gmail.com.

Re: [fricas-devel] generate images from sources in appendix

2024-04-16 Thread Qian Yun

On 4/16/24 22:38, Waldek Hebisch wrote:

On Tue, Apr 16, 2024 at 06:11:56PM +0800, Qian Yun wrote:

I can now generate all images from sources listed in appendix.

Good.

Although only src/doc/ps/knot3.ps is currentlly used in chapter 7.
We can delete this 70k line ps file from repo now.
(And it's black and white, I can generate colored ps files now.)

Those pictures were in the original Jenk book.

In attachment pics-new.pdf is my newly generated version.
Details are not tweaked yet, for example titles, axes, etc.

In attachment pics-old.pdf (see next mail) is the scanned
version from Axiom's bookvol0.pdf.

Just a silly question: have you looked why the image is so big?
Your new image is 6.7M and bigger than scanned version (4.3M).
Old knot3.ps is 77k lines giving 1.1M size. At first glance
adding color to this could double or maybe triple the size.
.pdf uses compression, compressed knot3.ps is 153k. So
I would expect .pdf of order 0.5M.

My new knot3.pdf is 480K. That's because my version is "smooth"
style aka made from many many dots while the trunk version
is the default "shade" style, aka made from lines.

There are a few other pics are in "smooth" style.

On average a "shade" style picture takes around 50-200KB and
a "smooth" style picture takes 200-400KB depending on the complexity
of the picture.

Also the scanned version is of low resolution, a high resolution scan
could easily take over 10MB size.

- Qian

Re: [fricas-devel] Slow formal derivatives

2024-04-16 Thread Qian Yun


(I have not tried to implement the following idea in FriCAS.)

I have always liked the idea presented in SICM (sister book
of SICP) Structure and Interpretation of Classical Mechanics:

https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/9579/sicm_edition_2.zip/chapter001.html

No dummy var involved. Instead view "diff" as a higher order
operator: it acts on other operator and returns a new operator.

So instead of the having new kernels (and new dummy var)
for each new argument,

(1) -> f := operator 'f

   (1)  f

(2) -> argument first kernels D(f(x),x)

   (2)  [f(%A), %A, x]

(3) -> argument first kernels D(f(x^2),x)

 2
   (3)  [f(%B), %B, x ]



(4) -> argument first kernels D(f(x^3),x)

 3
   (4)  [f(%C), %C, x ]

The new plan should be generating a "new operator" "%diff(f)"
and its argument are x,x^2,x^3 respectively.

This "new operator" "%diff(f)" can store the argument "f"
into its properties, I guess.  And add special "%equal" for it.

- Qian

On 4/16/24 09:43, Waldek Hebisch wrote:

If you look at 'src/input/derham.input' you will notice comment
saying that it is quite slow for large n.  I looked a bit
at this and first observation is that slowness is due to
kernel manipulations.  Profile shows that almost all time goes
into kernel maniputation, mainly 'SCACHE;linearSearch'.
This is called from 'FS-;diffdiff' which is responsible for
differentiating formal derivatives.  Linear search is necessary
due to the way we implement formal derivatives.  But it is
actually worse: repeating the same calculation shows growing
time.  Just to see scale, one of calculation in
'src/input/derham.input' is to calculate second exterior
derivative of general form in n variables.  General form
involves n formal function in n variables.  First exterior
derivative needs to compute n^2 partial derivatives (n functions
times n variables).  Second exterior derivative needs
n(n-1)n partial derivatives.  So togeter about n^3 derivatives.
For n=8 this is about 512.  Even squared (due to linear search)
this does not look like very large number of operations.
However, formal derivative of order 2 contains derivatives of
order 1.  And it seems that due to use of dummies we create
new kernels, so when we repeat calculation, then our cache keep
growing.

This suggest that we should re-think representation of formal
derivatives and possibly also use of dummies.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/cb15e9d8-e3ab-4e35-834e-1fe79872ba85%40gmail.com.

[fricas-devel] output filename of PostScript image

2024-04-15 Thread Qian Yun


Currently we have image.bm, image.xpm for bitmap image,
but for PS image, we have fricas2D.ps and fricas3D.ps.

I suggest to use "image.ps" instead, opinions?

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/108f3e7e-723f-41ca-a65d-227bc5a01234%40gmail.com.

Re: [fricas-devel] "title" and "frame" in PostScript output

2024-04-15 Thread Qian Yun


It is definitely possible to control the inclusion, but that means
adding another global variable.  Because it also affects the size of
BoundingBox.

Since this "title and frame" is not there for the past decades,
I think we can start freshly by choosing "title inside
viewWindow and no frame"?

- Qian

On 4/16/24 03:10, Waldek Hebisch wrote:


It is better to present consitent interface.  OTOH important use of
.ps is for inclusion inside text.  In such case title and frame
may be undesirable.  So I think we need a way to control inclusion
of title and frame.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/b7b53ef1-fea2-450a-ad46-8d914fb6bd2d%40gmail.com.

[fricas-devel] "title" and "frame" in PostScript output

2024-04-15 Thread Qian Yun


By default, there's no "title" in PostScript output.

Simply enable "Gdraws_drawFrame" in src/graph/Gdraws/Gfun.c
will give you "title" back, along with "frame" (thin lines)
around titleWindow and viewWindow.

That's a discrepancy with the xpm format.

Also the position of "title" in PS format is higher than the xpm format.

My point is, should we try to make the PS format and xpm format
look the same?

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/855cd4f5-ea17-4d70-b77e-9e4a62bd3df7%40gmail.com.

Re: [fricas-devel] default arguments to sbcl, again

2024-04-13 Thread Qian Yun


diff --git a/configure.ac b/configure.ac
index 073f3e96..0c66c8de 100644
--- a/configure.ac
+++ b/configure.ac
@@ -452,6 +452,8 @@ case $fricas_lisp_flavor in
 sbcl)
fricas_quiet_flags='--noinform --noprint --no-sysinit 
--no-userinit'

fricas_eval_flags='--eval'
+   sbcl_memory_size=`echo "(princ (sb-ext:dynamic-space-size))" | 
$fricas_lisp $fricas_quiet_flags`
+   test $sbcl_memory_size -gt 2147483647 || 
fricas_quiet_flags="--dynamic-space-size 2048 $fricas_quiet_flags"

;;
 cmucl)
fricas_quiet_flags='-batch -nositeinit -noinit'


This should work.

BTW, I should update configure with which autoconf, 2.71?

Regarding "--disable-ldb --disable-debugger", they should not be
used when dumping lisp image, instead they can be used when batch
compiling lisp files.

- Qian

On 4/13/24 21:31, Waldek Hebisch wrote:

On Fri, Apr 12, 2024 at 06:25:26PM +0800, Qian Yun wrote:

We have discussed this before, namely the default dynamic-space-size
is not enough during build.

Recently there is a github issue hitting by this on freebsd.

I get hit by this issue a few times as well, because the default
"./configure" no longer works and sometimes I forget to use
'./configure --with-lisp="sbcl --dynamic-space-size 2048"'.

I believe current situation is not friendly for new users,
(and it's not documented explicitly in INSTALL), and cumbersome
for developers.

We should make "./configure" work by default.

I think the following is a good solution:

1. Check the dynamic-space-size of the given SBCL.
2. If it is not enough, we append a proper argument to it.

This has the advantage that the user can still specify a
larger dynamic-space-size and will not be overwritten by
our default value, which was the old plan in previous discussion.


Yes, it would be good if you can do this.
  

Also from the freebsd bug report [1], shall we use
"--disable-ldb --disable-debugger" by default as well?


"--disable-ldb" probably yes.  "--disable-debugger" is somewhat
debatable.  Namely, when debugging build problems in typical cases
most work is to get debugger prompt.  Once in debugger, many problems
can be easily diagnosed.  Also, if you do "--disable-debugger"
at sbcl command line, can you enable it later in running image?
I hope so, just ask because I never used "--disable-debugger".



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0e6a66f3-1a35-47b0-bc2b-54c2ae6de7a4%40gmail.com.

Re: [fricas-devel] fix "BoundingBox" in generated postscript files

2024-04-13 Thread Qian Yun


OK, in attachment are 2 patch files, please review.

First one fixes several problems:
1. The most outstanding bug is that the width and height should
exchange positions in BoundingBox!!

2. The logic to determine scale factor is a mess, including
several minor logical problems.

And I extract it into a separate function, because it will be
used in both Gdraws_setDimension and PSCreateFile.


Second patch is to adjust the position of BoundingBox.

- Qian


On 4/13/24 21:14, Waldek Hebisch wrote:

On Sat, Apr 13, 2024 at 05:25:17PM +0800, Qian Yun wrote:

One of the problems of postscript files generated by "draw" is that
it is not proper "embedded postscript file", aka "eps".

When trying to include such image files in latex document, there are
huge padding around image.

The problem is caused by "BoundingBox".  We have "BoundingBox" in
generated PS file, but almost all utilities such as "ps2pdf",
"epstopdf" only recognize "BoundingBox" in the header comment section.

FriCAS generates "BoundingBox" in the middle of the PS file.

Following patch is a proof of concept to fix this issue.

After this patch, I can use "epstopdf" to convert PS file to
properly cropped pdf file.


Thanks for looking into this.
  

I think for a proper fix, a better way is to split "headerps"
into two and add a "boundingbox" patch in between?


Hmm, I would remove the '%!PS-Adobe-2.0' comment from 'header.ps'
(as you do).  IIUC 'BoundingBox' comment is supposed to appear
just after '%!PS-Adobe-2.0', so it is natural to print both
together, like you do.

I have some doubts concerning use 'vwInfo.height' and 'vwInfo.width'.
Namely, 'Gdraws_setDimension' clearly make some effort to fit
image onto page (it put appropriate rescaling operation into .ps file).
So, it seems that 'Gdraws_setDimension' computes _real_ bounding
box and we should use it in 'BoundingBox' comment.  Currently,
as you noted 'BoundingBox' comment is ignored and typical
images fit inside page, so nothing bad happens due to possibly
incorrect bouding box.  But for people with big screens and
in case we make 'Gdraws_setDimension' smarter we should use
dimensions computed in 'Gdraws_setDimension' when emiting
'BoundingBox' comment.  Which probably means that we should
propagate information from 'Gdraws_setDimension' to
'PSCreateFile'.





- Qian



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/04cae6f4-5408-4cfe-89b0-c73fc5eeb585%40gmail.com.
diff --git a/src/graph/Gdraws/Gfun.c b/src/graph/Gdraws/Gfun.c
index e21defd4..f9bdd047 100644
--- a/src/graph/Gdraws/Gfun.c
+++ b/src/graph/Gdraws/Gfun.c
@@ -125,6 +125,15 @@ PSCreateFile(
 return (psError);
   }
   else {
+fprintf(ofp, "%%!PS-Adobe-2.0\n");
+
+/* Write a Bounding Box for psfig etc. */
+XWindowAttributes vwInfo;
+XGetWindowAttributes(dsply, vw, );
+float scale = Gdraws_computeScale(vw, tw);
+fprintf(fp, "BoundingBox: 0 0 %d %d\n",
+(int) (scale * vwInfo.width), (int) (scale * vwInfo.height));
+
 i = 1;
 while (i < psDrawNo) {  /* loops through each file/procedure */
   if (psData[i].flag) { /* if set, procedure/file is used */
@@ -230,11 +239,6 @@ Gdraws_setDimension(
   fprintf(fp, "\t%d\t%d\t%d\tsetDim\n", twInfo.height - vwInfo.height,
   vwInfo.height, vwInfo.width);
 
-  /* Write a Bounding Box for psfig etc. */
-
-  fprintf(fp, "BoundingBox: 0 0 %d %d\n",
-  (int) (scale * vwInfo.width), (int) (scale * vwInfo.height));
-
   fprintf(fp, "\tmaxX maxY\t0 0\trectangle\tclip\t%% set clip path\n\n");
   return (fclose(fp));
 }
diff --git a/src/graph/Gdraws/ps_files/header.ps b/src/graph/Gdraws/ps_files/header.ps
index e945bec4..037914ac 100644
--- a/src/graph/Gdraws/ps_files/header.ps
+++ b/src/graph/Gdraws/ps_files/header.ps
@@ -1,4 +1,3 @@
-%!PS-Adobe-2.0
 %%DocumentFonts: Times-Roman
 %%Creator: FriCAS
 %%CreationDate: today
diff --git a/src/graph/Gdraws/Gfun.c b/src/graph/Gdraws/Gfun.c
index 808822aa..e21defd4 100644
--- a/src/graph/Gdraws/Gfun.c
+++ b/src/graph/Gdraws/Gfun.c
@@ -38,6 +38,7 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #include 
 #include 
 #include 
+#include 
 
 #include "Gdraws0.h"
 #include "G.h"
@@ -61,6 +62,32 @@ filecopy(FILE * ifp, FILE * ofp)
 putc(c, ofp);
 }
 
+/*
+ * Gdraws_computeScale calculates a scale factor based on the
+ * dimensions of the picture and page size.
+ */
+
+float Gdraws_computeScale(Window vw, Window tw) {
+  XWindowAttributes vwInfo;
+  float pageWidth, pageHeight,

[fricas-devel] fix "BoundingBox" in generated postscript files

2024-04-13 Thread Qian Yun


One of the problems of postscript files generated by "draw" is that
it is not proper "embedded postscript file", aka "eps".

When trying to include such image files in latex document, there are
huge padding around image.

The problem is caused by "BoundingBox".  We have "BoundingBox" in
generated PS file, but almost all utilities such as "ps2pdf",
"epstopdf" only recognize "BoundingBox" in the header comment section.

FriCAS generates "BoundingBox" in the middle of the PS file.

Following patch is a proof of concept to fix this issue.

After this patch, I can use "epstopdf" to convert PS file to
properly cropped pdf file.

I think for a proper fix, a better way is to split "headerps"
into two and add a "boundingbox" patch in between?


- Qian

diff --git a/src/graph/Gdraws/Gfun.c b/src/graph/Gdraws/Gfun.c
index 808822aa..027e1dbe 100644
--- a/src/graph/Gdraws/Gfun.c
+++ b/src/graph/Gdraws/Gfun.c
@@ -98,6 +98,11 @@ PSCreateFile(
 return (psError);
   }
   else {
+fprintf(ofp, "%%!PS-Adobe-2.0\n");
+XWindowAttributes vwInfo;
+XGetWindowAttributes(dsply, vw, );
+/* Write a Bounding Box for psfig etc. */
+fprintf(fp, "BoundingBox: 0 0 %d %d\n", vwInfo.height, 
vwInfo.width);

 i = 1;
 while (i < psDrawNo) {  /* loops through each file/procedure */
   if (psData[i].flag) { /* if set, procedure/file is used */
@@ -226,10 +231,6 @@ Gdraws_setDimension(
   fprintf(fp, "\t%d\t%d\t%d\tsetDim\n", twInfo.height - vwInfo.height,
   vwInfo.height, vwInfo.width);

-  /* Write a Bounding Box for psfig etc. */
-
-  fprintf(fp, "BoundingBox: 0 0 %d %d\n", vwInfo.height, vwInfo.width);
-
   fprintf(fp, "\tmaxX maxY\t0 0\trectangle\tclip\t%% set clip path\n\n");
   return (fclose(fp));
 }
diff --git a/src/graph/Gdraws/ps_files/header.ps 
b/src/graph/Gdraws/ps_files/header.ps

index e945bec4..037914ac 100644
--- a/src/graph/Gdraws/ps_files/header.ps
+++ b/src/graph/Gdraws/ps_files/header.ps
@@ -1,4 +1,3 @@
-%!PS-Adobe-2.0
 %%DocumentFonts: Times-Roman
 %%Creator: FriCAS
 %%CreationDate: today

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/613e7b4e-d8b1-4283-9339-d57765b29cde%40gmail.com.

Re: [fricas-devel] Asking sman to start HyperDoc when fricas is started with fricas -noht

2024-04-12 Thread Qian Yun


The normal "hypertex" (started by sman) receives SIGTERM when we exit
fricas;

The "hypertex" started by ")hd" (with :input t) receives SIGHUP when
we exit fricas;

The "hypertex" started by ")hd" (with :input nil) receives no signal
when we exit fricas.

I have no further findings so far.

- Qian

On 4/10/24 21:36, Waldek Hebisch wrote:

On Wed, Apr 10, 2024 at 06:00:26PM +0800, Qian Yun wrote:

I was using 1.3.10 release, no problem.  Trunk version has this problem.

Bisect to commit 1936e863, "Rename 'OBEY' to '|run_shell_command|' and
implement with '|run_program|'".

This can be fixed by adding ":input t" to "sb-ext:run-program",
but I can not explain why.

diff --git a/src/lisp/fricas-lisp.lisp b/src/lisp/fricas-lisp.lisp
index 357aa063..5f3d58e2 100644
--- a/src/lisp/fricas-lisp.lisp
+++ b/src/lisp/fricas-lisp.lisp
@@ -918,7 +918,8 @@ with this hack and will try to convince the GCL crowd to
fix this.
(pop11:sysobey "/usr/bin/env" (cons command arguments))
#+:sbcl
(sb-ext:process-exit-code
-(sb-ext:run-program command arguments :search t :output
*standard-output*))
+(sb-ext:run-program command arguments :search t :output
*standard-output*
+:input t))
#+:gcl
(si:system (format nil "~{~a~^ ~}" (cons command arguments)))
  )


So in the trunk HyperDoc has /dev/null as standard input.  In 1.3.10
it had the same standard input as FRICASsys (or sman if started
by sman).  That still does not explain how HyperDoc decides if
it should exit.  And what we should do in 'run_program': most
program will not read standard input, so for them difference
should not matter.  But it is not clear what is better in
borderline cases.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/01640ab7-d237-4e3f-93c3-5da4c6f1c76c%40gmail.com.

[fricas-devel] default arguments to sbcl, again

2024-04-12 Thread Qian Yun


We have discussed this before, namely the default dynamic-space-size
is not enough during build.

Recently there is a github issue hitting by this on freebsd.

I get hit by this issue a few times as well, because the default
"./configure" no longer works and sometimes I forget to use
'./configure --with-lisp="sbcl --dynamic-space-size 2048"'.

I believe current situation is not friendly for new users,
(and it's not documented explicitly in INSTALL), and cumbersome
for developers.

We should make "./configure" work by default.

I think the following is a good solution:

1. Check the dynamic-space-size of the given SBCL.
2. If it is not enough, we append a proper argument to it.

This has the advantage that the user can still specify a
larger dynamic-space-size and will not be overwritten by
our default value, which was the old plan in previous discussion.



Also from the freebsd bug report [1], shall we use
"--disable-ldb --disable-debugger" by default as well?


[1] https://github.com/fricas/fricas/issues/161

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/ef15a76e-b6a5-44c4-ad0a-1d3e018e9458%40gmail.com.

Re: [fricas-devel] Asking sman to start HyperDoc when fricas is started with fricas -noht

2024-04-10 Thread Qian Yun


I was using 1.3.10 release, no problem.  Trunk version has this problem.

Bisect to commit 1936e863, "Rename 'OBEY' to '|run_shell_command|' and
implement with '|run_program|'".

This can be fixed by adding ":input t" to "sb-ext:run-program",
but I can not explain why.

diff --git a/src/lisp/fricas-lisp.lisp b/src/lisp/fricas-lisp.lisp
index 357aa063..5f3d58e2 100644
--- a/src/lisp/fricas-lisp.lisp
+++ b/src/lisp/fricas-lisp.lisp
@@ -918,7 +918,8 @@ with this hack and will try to convince the GCL 
crowd to fix this.

   (pop11:sysobey "/usr/bin/env" (cons command arguments))
   #+:sbcl
   (sb-ext:process-exit-code
-(sb-ext:run-program command arguments :search t :output 
*standard-output*))
+(sb-ext:run-program command arguments :search t :output 
*standard-output*

+:input t))
   #+:gcl
   (si:system (format nil "~{~a~^ ~}" (cons command arguments)))
 )


- Qian

On 4/10/24 10:22, Waldek Hebisch wrote:

On Wed, Apr 10, 2024 at 04:00:31AM +0200, Grégory Vanuxem wrote:

I can not reproduce that. Even with a freshly cloned Official FriCAS
on a pure Linux partition. That's very strange, you probably have a
setting that I don't know. Thanks anyway.


I see the same as you.  HyperDoc should quit, but it does not...
We need to investigate what is different in both cases.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/6566c2c5-eba2-4711-84cb-5fa568992f38%40gmail.com.

Re: [fricas-devel] Asking sman to start HyperDoc when fricas is started with fricas -noht

2024-04-09 Thread Qian Yun


When I start HyperDoc with ')hd', it automatically closes when
I quit FriCAS with ')q'.

- Qian

On 4/10/24 00:42, Grégory Vanuxem wrote:

Hello,

See email object.

I would like to be able to only use HyperDoc when I want, and,
usually, not at startup time. The problem is if I use the ')hd' system
synonym when I close FriCAS, HyperDoc is still in use. I have to
manually close HyperDoc windows after closing FriCAS. So is there a
command or something like that to start it such that it will be closed
automatically?

Regards,
- Greg



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/442c5e38-3c31-4588-98de-8cf3489d6d00%40gmail.com.

[fricas-devel] [PATCH] change remaining "import" to "import from"

2024-04-09 Thread Qian Yun


This patch changes all remaining "import" to "import from".

The removed lines are mostly "import from Record(...)".

Should we also modify "parse_Import" from "s-parser.boot"
so that it gives error on "import XXX"?

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/62790292-f360-4240-bf71-891f4d4840d5%40gmail.com.
diff --git a/src/algebra/computation.spad b/src/algebra/computation.spad
index ba9b0750..bcf58c28 100644
--- a/src/algebra/computation.spad
+++ b/src/algebra/computation.spad
@@ -2320,7 +2320,7 @@ compUtil(UT) : Exports == Implementation where
 
  Implementation ==> add
 
-  import OutputForm
+  import from OutputForm
 
   -- Keeps count of index number of variables created in Ski2Lambda.
   -- I am wary of defining a variable outside of a function but
diff --git a/src/algebra/efstruc.spad b/src/algebra/efstruc.spad
index 00edc1bb..613c8745 100644
--- a/src/algebra/efstruc.spad
+++ b/src/algebra/efstruc.spad
@@ -1115,7 +1115,6 @@ TrigonometricManipulations(R, F) : Exports == Implementation where
 -- returns f if it is certain that k is not a real kernel and k = f,
 -- "failed" otherwise
 kcomplex k ==
-  import Z
   op := operator k
   is?(k, 'nthRoot) =>
 arg := argument k
diff --git a/src/algebra/fortout.spad b/src/algebra/fortout.spad
index 10b08dbd..f4e19e93 100644
--- a/src/algebra/fortout.spad
+++ b/src/algebra/fortout.spad
@@ -886,7 +886,7 @@ FortranCodeTools : with
 FortranFormat : OutputFormatterCategory == add
 Rep := OutputForm
 
-import OutputFormTools
+import from OutputFormTools
 
 assignable_form?(o : OutputForm) : Boolean ==
 atom?(o) => true
@@ -902,7 +902,7 @@ FortranFormat : OutputFormatterCategory == add
 var := concat("R", convert(i)@String)::Symbol::OutputForm
 elt(outputForm("="::Symbol), [var, o])
 
-import FortranCodeTools
+import from FortranCodeTools
 
 display(x : %) : Void ==
 displayLines(fort_clean_lines(expression2Fortran(x::Rep)))
diff --git a/src/algebra/gnudraw.spad b/src/algebra/gnudraw.spad
index 80ed202c..2339a95b 100644
--- a/src/algebra/gnudraw.spad
+++ b/src/algebra/gnudraw.spad
@@ -29,8 +29,10 @@ GnuDraw(): with
   ++ \spad{gnuDraw} provides 3d surface plotting, default options
  == add
   -- 2-d plotting
+
+  import from TwoDimensionalViewport, GraphImage, TopLevelDrawFunctions EF
+
   gnuDraw(f:EF,segbind:SBF,filename:STR,opts:List DROP):Void ==
-import TwoDimensionalViewport, GraphImage, TopLevelDrawFunctions EF
 f1:TextFile:=open(filename::FileName,"output")
 -- handle optional parameters
 writeLine!(f1,concat(["set title _"",title(opts,"")$DROP0,"_""]))
@@ -43,8 +45,10 @@ GnuDraw(): with
   unparse(convert(p.2)@InputForm)]))
   writeLine!(f1); -- blank line need to mark a "branch"
 close! f1
+
+  import from TopLevelDrawFunctionsForPoints
+
   gnuDraw(l1:LDF,l2:LDF,filename:STR,opts:List DROP):Void ==
-import TwoDimensionalViewport, GraphImage, TopLevelDrawFunctionsForPoints
 f1:TextFile:=open(filename::FileName,"output")
 -- handle optional parameters
 writeLine!(f1,concat(["set title _"",title(opts,"")$DROP0,"_""]))
@@ -65,8 +69,10 @@ GnuDraw(): with
 gnuDraw(l1,l2,filename,[title("")$DROP])
 
   -- 3-d plotting
+
+  import from ThreeSpace DoubleFloat
+
   gnuDraw(f:EF,segbind1:SBF, segbind2:SBF, filename:STR, opts:List DROP):Void ==
-import ThreeSpace DoubleFloat, TopLevelDrawFunctions EF
 f1:TextFile:=open(filename::FileName,"output")
 -- process optional parameters
 writeLine!(f1,concat(["set title _"",title(opts,"")$DROP0,"_""]))
diff --git a/src/algebra/manip.spad b/src/algebra/manip.spad
index 3e6c163e..1e7a2d04 100644
--- a/src/algebra/manip.spad
+++ b/src/algebra/manip.spad
@@ -630,7 +630,7 @@ TranscendentalManipulations(R, F) : Exports == Implementation where
   Implementation ==> add
 import from FactoredFunctions(P)
 import from PolynomialCategoryLifting(IndexedExponents K, K, R, P, F)
-import
+import from
   PolynomialCategoryQuotientFunctions(IndexedExponents K, K, R, P, F)
 
 smpexp: P -> F
diff --git a/src/algebra/special2.spad b/src/algebra/special2.spad
index 13f2b74a..fc857855 100644
--- a/src/algebra/special2.spad
+++ b/src/algebra/special2.spad
@@ -1658,7 +1658,7 @@ DoubleFloatSpecialFunctions2() : with
 res1
 
 
-import FloatLiouvilianFunctions
+import from FloatLiouvilianFunctions
 
 to_sf(x) ==>
 obits := bits()$Float
diff --git a/src/algebra/xlpoly.spad b/src/algebra/xlpoly.spad
index 7c174a30..c2771992 100644
--- a/src/algebra/xlpoly.spad
+++ b/src/algebra/xlpoly.spad
@@ -484,7 +484,6 @@ LiePolynomial(VarSet

[fricas-devel] [PATCH] backport a fix from open-axiom

2024-04-09 Thread Qian Yun


This fix is a subset of this commit:

https://github.com/GabrielDosReis/open-axiom/commit/c18ddc965ea2ac28a2c32e99dc2ac90c946a7aee

- Qian

diff --git a/src/hyper/extent2.c b/src/hyper/extent2.c
index b0b4443f..524312d0 100644
--- a/src/hyper/extent2.c
+++ b/src/hyper/extent2.c
@@ -554,7 +554,7 @@ text_height1(TextNode * node, int Ender)
 {
 for (; node != NULL; node = node->next) {
 if (Ender == Endtokens) {
-if (node->type > -Endtokens)
+if (node->type >= Endtokens)
 return cur_height;
 }
 else if (node->type == Ender)

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/34744a44-63d2-4ab7-8be2-b7dd9dc9e208%40gmail.com.

[fricas-devel] "init_special_db_data" not called in recent commit

2024-04-08 Thread Qian Yun


"init_special_db_data" is defined but not called in recent commit.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/20a942d6-7bf6-4cd2-a089-3b3f6efafdd8%40gmail.com.

[fricas-devel] Fix ')edit' and its documentation

2024-04-07 Thread Qian Yun


Fix documentation from ')help edit', and running ')edit'
without arguments.

- Qian

diff --git a/src/doc/htex/ug16.htex b/src/doc/htex/ug16.htex
index 98b7dd44..d5a67a43 100644
--- a/src/doc/htex/ug16.htex
+++ b/src/doc/htex/ug16.htex
@@ -870,17 +870,15 @@ Thus
 will place  you in an editor looking at the  file
 {\tt /u/julius/matrix.input}.
 \index{editing files}
-By default, the editor is {\tt vi},
-\index{vi}
-but if you have an EDITOR shell environment variable defined, that editor
-will be used.
+By default, the editor is {\tt less} just for viewing purpose,
+but if you have a shell environment variable FRICASEDITOR defined,
+that editor will be used.
 When \Language{} is running under the X Window System,
 it will try to open a separate {\tt xterm} running your editor if
 it thinks one is necessary.
-\index{Korn shell}
-For example, under the Korn shell, if you issue
+For example, under the Bash shell, if you issue
 \begin{verbatim}
-export EDITOR=emacs
+export FRICASEDITOR=emacs
 \end{verbatim}
 then the emacs
 \index{emacs}
diff --git a/src/interp/i-toplev.boot b/src/interp/i-toplev.boot
index 6aaa8e55..91fea454 100644
--- a/src/interp/i-toplev.boot
+++ b/src/interp/i-toplev.boot
@@ -108,11 +108,11 @@ readSpadProfileIfThere() ==
   file := getEnv('"FRICAS_INITFILE")
   file = '"" => nil
   efile :=
-make_input_filename(file) => file
+fn := make_input_filename(file) => fn
 file := ['_.fricas, 'input]
-make_input_filename(file) => file
+fn := make_input_filename(file) => fn
 file := ['_.axiom, 'input]
-make_input_filename(file) => file
+fn := make_input_filename(file) => fn
 NIL
   efile =>
 $edit_file := efile

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/79c96039-53bf-4974-aba4-cc7ad2bcfcfa%40gmail.com.

Re: [fricas-devel] improve "dbReadLines"

2024-04-07 Thread Qian Yun

On 4/7/24 08:21, Waldek Hebisch wrote:

I admit that my long term plan is somewhat different: to do
substantial developements at Spad level. That means for example

I agree with this long term goal.

better file handling on Spad level. Of course, there is question
how much time Spad plan will take? FriCAS has more than 15 years
and there is still a lot of Boot code, so realistically we can
not expect fast change here. OTOH Spad code is slowly, but
steadily growing, Boot and Lisp oscilate at around fixed level,
new things are implemented but also things are removed or moved
to Spad code. _My_ main focus when working on Boot code it to
prepare transition to Spad. More precisely, IMO big advantage
of Spad code is that it forces clearer structure. And main
difficulty is that current Boot code has rather convolved
structure, for example code is reused in strange ways. Main
intent of changes to Boot code is to claryfy structure. When
structure is clear enough, then transition to Spad will be
relatively easy.

Agree.

On this subject, I find that you can call Spad function from Boot.
I wonder if i-output.boot is a good target to port to Spad first.

Some sharing is undesirable, but IMO to avoid massive code
duplication we should have significant code sharing between
subsystems. Which IMO means that trying to divide this between
directories is mostly futile

I'm not talking adding new sub-directories. What I meant is to
extract commonly used functionality into new files.

To put it differnely, I think that we should try to make sure
that given part works with appropiate "types" and in particular
that reuse respect types. Main cause of problems with reuse is
that diffent users of given functionality have different structure
of data (effectively different "type"). Boot does not have
type declarations, but one possible way forward is to add assertions,
that is signal errors when data has unexpected structure.

Coming back to your specific question, we can add new file
for utility type routines, but I do not expect such file to
get big and I prefer to keep 'src/interp' as a flat directory.

I'll modify "dbReadLines" in-place then. And I'll come up with
a list of functions that should exist in this new file "util.boot".

- Qian

Re: [fricas-devel] function "asList" in as.boot not used anywhere?

2024-04-05 Thread Qian Yun


OK, just build successfully with Aldor without this function.

Will commit later.

- Qian

On 4/6/24 10:06, Waldek Hebisch wrote:

On Sat, Apr 06, 2024 at 09:40:59AM +0800, Qian Yun wrote:

Seems like function "asList" in as.boot is not used anywhere?


Yes, looks so.


Can it be removed then?


Probably.  I admit that did little work on 'as.boot'.  It is used
to get info from Aldor compiled files into databases and otherwise
unused.  So it is untestable without Aldor.  I personally do not use
Aldor and building Aldor on my main machine either did not work or
was quite inconvenient.  So I was very conservative with respect
to 'as.boot', main thing was to avoid breakage as that could remain
undetected for longer time.

Having said this, removal of 'asList' looks resonable safe.



--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/47edbecc-a728-4dd3-81ea-8c8316db1f5b%40gmail.com.

[fricas-devel] improve "dbReadLines"

2024-04-05 Thread Qian Yun


I'd like to improve "dbReadLines" from br-search.boot
into the following:


read_text_stream stream ==
  if stream then
[read_line stream while not EOFP stream]

read_text_file filename ==
  handle_input_file(filename, function read_text_stream, [])


It's more correct (closes stream when exception happens) and
function name is more generic (not limited to db operation.)

However I can't find a proper place to put this function.

I think current naming scheme under src/interp/ lacks tiering:
there should be files that are libraries used by other modules,
then there should be files making up module A/B/C, then there
should be higher structure like compiler/interpreter depends on
module A/B/C.

Anyway, I suggest to add a new file under src/interp/ that
contains commonly used library functions, including this one.

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/0d509fa5-eaca-4a2d-8c6c-08624a4ffa0d%40gmail.com.

[fricas-devel] function "asList" in as.boot not used anywhere?

2024-04-05 Thread Qian Yun


Seems like function "asList" in as.boot is not used anywhere?
Can it be removed then?

- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/8ea93eae-9a20-46bf-af63-23fc8fe8ae47%40gmail.com.

[fricas-devel] line breaking feature in writeInputLines

2024-04-03 Thread Qian Yun


There is a line breaking feature in "writeInputLines":

it tries to break input lines to less than 72 chars,
see variable "breakChars".


This feature never worked.  Following patch fixes it,
however I wonder if this "feature" is worth keeping.

- Qian

diff --git a/src/interp/i-syscmd.boot b/src/interp/i-syscmd.boot
index df862af8..3013bd3d 100644
--- a/src/interp/i-syscmd.boot
+++ b/src/interp/i-syscmd.boot
@@ -1380,7 +1380,7 @@ writeInputLines(fn,initial) ==
   null fn =>
 throwKeyedMsg("S2IH0038", nil)  -- missing file name
   maxn := 72
-  breakChars := [" ","+"]
+  breakChars := [char '" ", char '"+"]
   for i in initial..$IOindex - 1 repeat
 vecl := first readHiFi i
 if STRINGP vecl then vecl := [vecl]

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/ff4199a3-6ed3-42bb-a529-3914ade93330%40gmail.com.

Re: [fricas-devel] History broken

2024-04-02 Thread Qian Yun





On 4/3/24 02:08, Waldek Hebisch wrote:

On Tue, Apr 02, 2024 at 07:51:53PM +0800, Qian Yun wrote:

It is caused by commit 68a3e8ee in 2023-Feb-9, the removal of
"makePathname" in "histInputFileName".

So the fix is the following.  Please review it before I do the
commit.


AFAICS the PNAME part is not needed: make_filename0 converts
symbols to strings.

At first glance, it looks that change below would break
')history )save' and ')undo'.   I think that we need to change
'historySpad2Cmd' to call an intermediate function to
convert arguments.


Yes, you are right about both points.

I believe the following is enough:

diff --git a/src/interp/i-syscmd.boot b/src/interp/i-syscmd.boot
index 8e337d59..31d2a1fe 100644
--- a/src/interp/i-syscmd.boot
+++ b/src/interp/i-syscmd.boot
@@ -1367,7 +1367,7 @@ historySpad2Cmd() ==
 opt = 'show=> showHistory optargs
 opt = 'change  => changeHistListLen first optargs
 opt = 'restore => restoreHistory optargs
-opt = 'write   => writeInputLines(optargs,1)
+opt = 'write   => writeInputLines(first optargs, 1)
   'done



- Qian

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/9ddd97ee-2693-4ce8-a773-d0d523f09f3c%40gmail.com.

Re: [fricas-devel] History broken

2024-04-02 Thread Qian Yun


It is caused by commit 68a3e8ee in 2023-Feb-9, the removal of
"makePathname" in "histInputFileName".

So the fix is the following.  Please review it before I do the
commit.

- Qian

diff --git a/src/interp/i-syscmd.boot b/src/interp/i-syscmd.boot
index 8e337d59..37c0e6ea 100644
--- a/src/interp/i-syscmd.boot
+++ b/src/interp/i-syscmd.boot
@@ -1308,7 +1308,7 @@ histFileName() ==
 histInputFileName(fn) ==
 null fn =>
 make_filename0($interpreterFrameName, 'INPUT)
-make_filename0(fn, 'INPUT)
+make_filename0(PNAME fn, 'INPUT)


 initHist() ==
@@ -1427,6 +1427,7 @@ writeInputLines(fn,initial) ==
 -- in case we can't find a breaking point
 if not done then n := 0
   lineList := [vec,:lineList]
+  fn := first(fn)
   file := histInputFileName(fn)
   maybe_delete_file(file)
   inp := MAKE_OUTSTREAM(file)



On 4/2/24 16:50, Prof. Dr. Johannes Grabmeier wrote:

in my recent installed system

    FriCAS Computer Algebra System
     Version: FriCAS 1.3.10 built with sbcl 2.4.0
    Timestamp: Mo 11 Mär 2024 17:56:31 CET
-
    Issue )copyright to view copyright notices.
    Issue )summary for a summary of useful system commands.
    Issue )quit to leave FriCAS and return to shell.
--

the history feature is broken:

(3) -> x+y

    (3)  y + x
Type: Polynomial(Integer)
(4) -> )history )write xx

debugger invoked on a SIMPLE-CONDITION in thread
#:
   break

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
   0: [CONTINUE] Return from BREAK.
   1: [ABORT   ] Exit from the current thread.

(|writeInputLines| (|xx|) 1)
    source: (|histInputFileName| |fn|)
0]





--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/d01bdbc8-c95e-44ec-9cb3-38f511d34e8d%40gmail.com.

1 2 3 4 5 6 >

1 - 100 of 597 matches

Mail list logo