Re: [fricas-devel] regression on windows
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 failure. If I do 'updateCategoryTable' > _only_ for 'UnivariatePuiseuxSeries', then also there is no > failure. So, it seems that failure is related to multiple > calls to 'updateCategoryTable' It seems that I found core trouble. There is huge search for possible operations. In this case "correct" operation is declared by RightModule. Float needs to be coerced to Expression(Float) and UnivariatePuiseuxSeries(Expression(Integer),x,0) to UnivariatePuiseuxSeries(Expression(Integer),x,0) Using fresh database )boot get_database(['UnivariatePuiseuxSeries, :'RightModule], 'HASCATEGORY) (EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL) (PROG () (RETURN (|get_database| (CONS '|UnivariatePuiseuxSeries| '|RightModule|) 'HASCATEGORY Value = (((|#1|) . T) (((|Fraction| (|Integer|))) OR (|has| |#1| (|Algebra| (|Fraction| (|Integer| (|has| |#1| (|Field|))) ((%) . T)) first position above, that is '((|#1|) . T)' means that UnivariatePuiseuxSeries unconditianlly has RightModule(#1), where #1 is first parameter to UnivariatePuiseuxSeries. Second position gives conditions for UnivariatePuiseuxSeries to have RightModule(Fraction(Integer)) and the third conditions for RightModule(%). From signature we need RightModule(Float), the first position gives RightModule(Expression(Integer)) and matching code resolves Float and Expression(Integer) to Expression(Float). This satisfies later checks and is OK. After 'updateCategoryTable' we get different list: Value = |Fraction| (|Integer|))) OR (|has| |#1| (|Field|)) (|has| |#1| (|Algebra| (|Fraction| (|Integer|) ((%) . T) ((|#1|) . T)) So thist time consition for RightModule(Fraction(Integer)) is first. Again, we need RightModule(Float) and matching code resolves Fraction(Integer) and Float to Float. However, this fails later checks. So the core trouble is that search for signatures early commits to first plausible alternative. Exhaustive seach should try all possibilities, but this is not done. -- Waldek Hebisch -- 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/ZkLZuJCQmW19gIZv%40fricas.org.
Re: [fricas-devel] regression on windows
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 looks good to you as well. Looks good. > - 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. -- Waldek Hebisch -- 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/ZkKuLW4kyy7PTrqa%40fricas.org.
Re: [fricas-devel] regression on windows
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, 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. 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 failure. If I do 'updateCategoryTable' _only_ for 'UnivariatePuiseuxSeries', then also there is no failure. So, it seems that failure is related to multiple calls to 'updateCategoryTable' -- Waldek Hebisch -- 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/ZkKrQIUrmeUcho5O%40fricas.org.
Re: [fricas-devel] regression on windows
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
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).
> - 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.
--
Waldek Hebisch
--
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/ZkJQfcWrAZ4fOqv6%40fricas.org.
Re: [fricas-devel] regression on windows
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
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
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. -- Waldek Hebisch -- 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/ZkHz3z3z_BZ2EnsX%40fricas.org.
Re: [fricas-devel] regression on windows
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 (&REST 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) (|argumentNumber| . 1) (|cal
Re: [fricas-devel] regression on windows
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. -- Waldek Hebisch -- 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/ZkHnHOaWticbP78x%40fricas.org.
Re: [fricas-devel] regression on windows
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
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/fricas0-repo/commit/74b1193cfcf2f33909f8bad55785c14cf9e02cd8.patch Yes. AFAICS there is the same info, just put is somewhat different order (which is expected with change of order predicate). > BTW, can you explain a bit more about the thoughts behind > this commit? Is GGREATERP in Fractored next step? Yes. In my developement tree Factored works without using Lisp order (I added extra code to handle unordered domains). After that GGREATERP will be unused an can be removed. Goal of this is to have simpler and sound code: the ordering functions had irreqularities so they actually failed definiton of order. GGREATERP in principle depends on internals of Lisp implementation. AFAICS 'lt_sexp' is actually an order and it refuses to handle anything potentially problematic. Change to ordering predicate also leads to change in output of ')show'. I view this as good change: prevous order had tendency to put more complex signatures first, current prefers simpler ones first. I consider anything depending on details of previous ordering functions as a potential bug, in particular type checking should not depend on details of order. It depends on order in various places being the same, but using single order reduces possibility of accidentally using different orders. So, each change has risk of breaking something, but I think that once we work out accidental breakage we will have cleaner and more robust code. -- Waldek Hebisch -- 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/ZkFyPBoz-2qAHAtL%40fricas.org.
Re: [fricas-devel] regression on windows
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. -- 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/ccd0df5b-58c5-4921-a102-0db542ab4568%40gmail.com.
Re: [fricas-devel] regression on windows
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. -- Waldek Hebisch -- 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/ZkFX8AiZ6iFMaBNH%40fricas.org.
Re: [fricas-devel] regression on windows
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 foreign routines > FRICAS="/usr/local/lib/fricas/target/x86_64-linux-gnu" > spad-lib="/usr/local/lib/fricas/target/x86_64-linux-gnu//lib/libspad.so" > foreign routines found > openServer result -2 >FriCAS Computer Algebra System > Version: FriCAS 1.3.11-dev built with SBCL 2.4.4 > Timestamp: dim. 12 mai 2024 15:40:31 CEST > - >Issue )copyright to view copyright notices. >Issue )summary for a summary of useful system commands. >Issue )quit to leave FriCAS and return to shell. > - > > (1) -> )tr GLESSEQP > >Function traced: GLESSEQP > (1) -> a:=series sin(x) > 1 1>exit GLESSEQP : NIL 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. -- Waldek Hebisch -- 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/ZkEAEhcZY_K99CJL%40fricas.org.
Re: [fricas-devel] regression on windows
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="/usr/local/lib/fricas/target/x86_64-linux-gnu//lib/libspad.so"
foreign routines found
openServer result -2
FriCAS Computer Algebra System
Version: FriCAS 1.3.11-dev built with SBCL 2.4.4
Timestamp: dim. 12 mai 2024 15:40:31 CEST
-
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-
(1) -> )tr GLESSEQP
Function traced: GLESSEQP
(1) -> a:=series sin(x)
1exit GLESSEQP : NIL
1 31 5 1 7 19 1 11 12
(1) x - - x + --- x - x + -- x - x + O(x )
6 120 5040 362880 39916800
Type: UnivariatePuiseuxSeries(Expression(Integer),x,0)
Time: 0.06 (OT) = 0.07 sec
(2) -> a*1.0
1exit GLESSEQP : NIL
(2)
3 5
x - 0.16_67 x + 0.008333_33_34 x
+
7 9
- 0.0001984126_9841269841_27 x + 0.027557_3192239858_90653 x
+
11 12
- 0.2505210838_5441718775 E -7 x + O(x )
Type: UnivariatePuiseuxSeries(Expression(Float),x,0.0)
Time: 0.02 (IN) + 0.01 (OT) = 0.03 sec
And see the two attached gzipped files, one with old GLESSEQP and the
other with newer GLESSEQP.
- Greg
Le dim. 12 mai 2024 à 10:38, Qian Yun a écrit :
>
> 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.
--
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/CAHnU2dZo30T_MOm4JYfYxhgUNeXozZoVwS_fD1eJojQG3TxEqA%40mail.gmail.com.
old_glesseqp.txt.gz
Description: GNU Zip compressed data
new_glesseqp.txt.gz
Description: GNU Zip compressed data
Re: [fricas-devel] regression on windows
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.
Re: [fricas-devel] regression on windows
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/dfa27b87-4807-4489-aaf0-11c9f6072ba7%40gmail.com
> > .
> >
>
> --
> 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/CAHnU2dZAH0GMDq9TVsVHym-Bg%2BwDqUA%3DF-UgGyfXLp2HQZ3b1g%40mail.gmail.com.
--
Waldek Hebisch
--
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/Zj5FyMTl0gtJn1QK%40fricas.org.
Re: [fricas-devel] regression on windows
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*1.0; true)")
> testTrue("(1.0*a; true)")
>
>
> Interpreter can't find proper signature.
Strange indeed. Looks that interpreter is buggy and result
depend on order (it should not). Order of entries in database
changed due to change to ordering predicate. And it is possible
that ordering on Windows is different than ordering on Linux.
--
Waldek Hebisch
--
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/Zj5DZlbYSB3Z-d-x%40fricas.org.
Re: [fricas-devel] regression on windows
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 therefore FiCAS.
- Greg
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/dfa27b87-4807-4489-aaf0-11c9f6072ba7%40gmail.com
> .
>
--
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/CAHnU2dZAH0GMDq9TVsVHym-Bg%2BwDqUA%3DF-UgGyfXLp2HQZ3b1g%40mail.gmail.com.
