On Tue, May 14, 2024 at 02:07:28AM +0200, Waldek Hebisch wrote:
>
> Little extra info: if I force call to 'updateCategoryTable' I get
> failure. If I load first 'UnivariatePuiseuxSeries' without
> 'updateCategoryTable' and force 'updateCategoryTable' for other
> loaded domains, then there is no f
On Tue, May 14, 2024 at 08:05:58AM +0800, Qian Yun wrote:
> 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.
Yes
> The following patch passes CI test now.
>
> Please commit it if it
On Mon, May 13, 2024 at 01:05:03PM +0200, 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
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
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 p
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
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
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 some
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,
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 d
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
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.
> The corresponding fricas0 changes is here, is this expected?
>
> https://github.com/oldk1331/fri
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 ab
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 wo
On Sun, May 12, 2024 at 04:01:56PM +0200, Grégory Vanuxem wrote:
> Hello,
>
> I have also found this but the problem seems more complicate:
>
> On WSL2/Linux (uname -a: Linux ellipse
> 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024
> x86_64 GNU/Linux):
>
> Checking for f
Hello,
I have also found this but the problem seems more complicate:
On WSL2/Linux (uname -a: Linux ellipse
5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024
x86_64 GNU/Linux):
Checking for foreign routines
FRICAS="/usr/local/lib/fricas/target/x86_64-linux-gnu"
spad-lib="/u
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)
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
On Fri, May 10, 2024 at 09:32:37PM +0800, Qian Yun wrote:
> 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
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.
Seems to be Windows specific. Could be interesting to investigate this for
the SBCL community and there
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 s
21 matches
Mail list logo
