[PATCH] [WIP] cleanup OBEY

17 views
Skip to first unread message

Qian Yun

unread,
Jan 4, 2024, 9:16:39 AM1/4/24
to fricas-devel
I introduced a new function |run_program|:

(defun |run_program| (command arguments)
;; Execute "command" with a list of "arguments" synchronously.
;; Output to the standard output stream.
;; The return value is the exit code of "command".

And try to replace "OBEY" with it.

This is still in early stages, definitely should not go to
the up coming release. Some comments are left there need
clearing up, more testing are needed, especially on Windows.

See patch at https://github.com/oldk1331/fricas/tree/cleanup-obey
or in attachment.

Some potential problems:

0. Rename 'OBEY' to '|run_shell_command|'?

1. jfricas and *OBEY-STDOUT*

This change will affect jfricas. I'll not sure what's the best
approach to fix it yet, maybe make a duplicated definition?
Or redirect various streams? I'll take a deeper look.

2. editFile and SPADEDIT

Related code is messy and not working on my side. (I did not
try hard.)

Is this functionality still useful? This surely is not how
programs interactwith users these days.

3. Aldor related

"asList" in as.boot: can use '(directory "as/*.asy")' to replace
OBEY. However is this function still needed?

"compile-as-file" in foam_l.lisp. Is it used during Aldor interface
build? I plan to change the type of optional argument "opts" from
(or nil string) to (list string).

4. In buildLibdb, I skipped rename-file. Should not be a problem.

5. "grepFile" in br-search.boot uses IO redirection, so it has to use
OBEY instead of |run_program|.

- Qian
cleanup-obey.patch

Qian Yun

unread,
Jan 15, 2024, 7:48:21 AM1/15/24
to fricas-devel
Ping?

P.S: Comments on shell and windows:

Even when building native windows version, we strongly depend
on a POSIX shell environment instead of CMD shell.

In the past, we have only used SBCL for native windows version.
I tried Clozure CL successfully recently.

GCL can only be built using mingw instead mingw64 so I didn't try.

CLISP provides a 32bit mingw version binary but that's 14 years old.
I failed to build a mingw64 version after trivial attempts.

ECL doesn't provide prebuilt windows binaries. Apparently it can
be built by MSVC or mingw64. I can build a mingw64 version but
failed to build FriCAS.

Since this patch works for SBCL on windows, so I don't believe
it will introduce breakages.

- Qian

Waldek Hebisch

unread,
Jan 15, 2024, 11:53:11 AM1/15/24
to fricas...@googlegroups.com
On Thu, Jan 04, 2024 at 10:16:34PM +0800, Qian Yun wrote:
> I introduced a new function |run_program|:
>
> (defun |run_program| (command arguments)
> ;; Execute "command" with a list of "arguments" synchronously.
> ;; Output to the standard output stream.
> ;; The return value is the exit code of "command".
>
> And try to replace "OBEY" with it.
>
> This is still in early stages, definitely should not go to
> the up coming release. Some comments are left there need
> clearing up, more testing are needed, especially on Windows.
>
> See patch at https://github.com/oldk1331/fricas/tree/cleanup-obey
> or in attachment.
>
> Some potential problems:
>
> 0. Rename 'OBEY' to '|run_shell_command|'?

Yes.

> 2. editFile and SPADEDIT
>
> Related code is messy and not working on my side. (I did not
> try hard.)
>
> Is this functionality still useful? This surely is not how
> programs interactwith users these days.

As I wrote in the past this is used to show source code in
HyperDoc. When I find a constructor in HyperDoc and click
on "Source file", then a window pop up showing source of the
constructor. This is useful thing.

> 3. Aldor related
>
> "asList" in as.boot: can use '(directory "as/*.asy")' to replace
> OBEY. However is this function still needed?
>
> "compile-as-file" in foam_l.lisp. Is it used during Aldor interface
> build? I plan to change the type of optional argument "opts" from
> (or nil string) to (list string).

Well, AFAICS there are significant functionlity that is not
excercised by interface build and current test (only one!).

In principle one should be able use any FriCAS library code from
Aldor and in turn use any Aldor code from FriCAS. There are
several different cases, interface build uses one case (or maybe two),
that is export of FriCAS constructors to Aldoer. 'sieve.as' tests
calling standalone Aldor functions. Calling Aldor constructors
is different than this.

There is good chance that some Aldor related parts are no longer
needed: in general NAG sources contained a lot of unused code
and Spad to Aldor translatar is removed for FriCAS, but there
still may be pieces of code only to supprt the translator.
But unless somebody want to dig deeper, or there is significant
gain I would not remove code from Aldor related parts.

> @@ -82,8 +82,8 @@ buildLibdb(domainList) == --called by make-databases (daase.lisp)
> domainList => 'done --leave new database in temp.text
> -- FIXME: This is confusing: result is in olibdb.text,
> -- but this is expected by save_browser_data
> - OBEY '"sort _"temp.text_" > _"libdb.text_""
> - RENAME_-FILE('"libdb.text", '"olibdb.text")
> + -- use OBEY here, otherwise SBCL will choose C:/Windows/System32/sort.exe
> + OBEY('"sort temp.text -o olibdb.text")

That is fragile. We should either come with sane PATH or use full
pathname of needed sort.

> +(defun |run_program| (command arguments)
<snip>
> + #+:poplog
> + (pop11:sysobey (format nil "~{~a~^ ~}" (cons command arguments))))
> +

Poplog has two argument version of sysobey, first argument is the
full pathname to the command, second is argument list. Due to
need for full pathname it will need some extra handling, but the
'env' trick shoul do:

(pop11:sysobey "/usr/bin/env" (cons "env" (cons command arguments)))


--
Waldek Hebisch
Reply all
Reply to author
Forward
0 new messages