From: SourceForge.net <no...@so...> - 2010-04-29 19:44:03
|
Bugs item #2994324, was opened at 2010-04-29 20:44 Message generated for change (Tracker Item Submitted) made by l_butler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2994324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leo Butler (l_butler) Assigned to: Nobody/Anonymous (nobody) Summary: tests in rtest_dot fail in 2nd run Initial Comment: If I run the test suite twice, then 'tests' 3, 52, 53 in rtest_dot fail on the second run. It appears that the dot operator is being redefined in some other test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2994324&group_id=4933 |
From: SourceForge.net <no...@so...> - 2010-04-29 22:47:36
|
Bugs item #2994324, was opened at 2010-04-29 21:44 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2994324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leo Butler (l_butler) Assigned to: Nobody/Anonymous (nobody) Summary: tests in rtest_dot fail in 2nd run Initial Comment: If I run the test suite twice, then 'tests' 3, 52, 53 in rtest_dot fail on the second run. It appears that the dot operator is being redefined in some other test. ---------------------------------------------------------------------- >Comment By: Dieter Kaiser (crategus) Date: 2010-04-30 00:47 Message: The problem is caused by the interaction of the commands reset and kill. This is the simplest example I have found to generate the error: We trace the function kill-operator: (%i1) :lisp (trace kill-operator) (KILL-OPERATOR) Declare the dot-operator commutative: (%i1) declare(".",commutative); (%o1) done First, we do a reset: (%i2) reset(); (%o1) [features, _, __, mopl, labels, %, linenum, tr-unique, lispdisp] Second, we call kill(all). The trace shows that the dot-operator is killed: (%i2) kill(all); 0: (KILL-OPERATOR ${) 0: KILL-OPERATOR returned NIL 0: (KILL-OPERATOR $}) 0: KILL-OPERATOR returned NIL 0: (KILL-OPERATOR MNCTIMES) 0: KILL-OPERATOR returned (DIMENSION DISSYM LBP RBP) (%o0) done If we try again a declaration we get a Lisp error: (%i1) declare(".",commutative); Maxima encountered a Lisp error: The value "." is not of type LIST. Automatically continuing. To enable the Lisp debugger set *debugger-hook* to nil. We get the Lisp error because Maxima no longer translates the name of the dot-operator "." to mnctimes: (%i2) :lisp (getopr ".") . I think the problem is that the internal list mopl which does some bookkeeping of operators is reseted by the command reset. I will have a look at this point. Dieter Kaiser ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2994324&group_id=4933 |
From: SourceForge.net <no...@so...> - 2010-04-29 23:41:32
|
Bugs item #2994324, was opened at 2010-04-29 21:44 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2994324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Leo Butler (l_butler) Assigned to: Nobody/Anonymous (nobody) Summary: tests in rtest_dot fail in 2nd run Initial Comment: If I run the test suite twice, then 'tests' 3, 52, 53 in rtest_dot fail on the second run. It appears that the dot operator is being redefined in some other test. ---------------------------------------------------------------------- >Comment By: Dieter Kaiser (crategus) Date: 2010-04-30 01:41 Message: I have changed the definition of mopl in suprv1.lisp from (defmvar mopl nil) to (defvar mopl nil) and it works. The build-in operator "." is no longer killed by kill-operator. The testsuite has no problems and can be executed more than one times. The global list mopl is used by declare to store build-in operators which get new properties, but are not allowed to be killed. If a kill command is executed, operators which are on this list are not killed. Therefore, it is an error to reset the list mopl. With the change we get: (%i1) declare(".",commutative); (%o1) done The function declare1 puts the dot-operator on the list mopl: (%i2) :lisp mopl (. } {) The list mopl is no longer reseted: (%i2) reset(); (%o1) [_, __, labels, %, linenum, lispdisp] When we execute the command kill, the dot-operator is not killed: (%i2) kill(all); (%o0) done (%i1) :lisp (getopr ".") MNCTIMES Remark: The change of the definition of mopl does not change the possibility to remove additional properties from build-in operators with the command kill, it only prevents the operator to be killed too, e.g. (%i1) declare(".",commutative); (%o1) done The property list show the in addition the property $commutative: (%i2) :lisp (symbol-plist 'mnctimes) (OPERS T $COMMUTATIVE T DATA (((KIND MNCTIMES $COMMUTATIVE) CON $INITIAL)) +LABS (1) ASSOCIATIVE T TEXSYM (\cdot ) TEX TEX-NARY DISTRIBUTE_OVER (MEQUAL) RBP 129 LBP 130 GRIND MSIZE-NARY DISSYM ( . ) DIMENSION DIMENSION-NARY TRANSLATE #<FUNCTION (LAMBDA #) {962403D}> OPERATORS SIMPNCT MSIMPIND (MNCTIMES SIMP) OP .) This property is removed with kill(all): (%i2) kill(all); (%o0) done (%i1) :lisp (symbol-plist 'mnctimes) (ASSOCIATIVE T TEXSYM (\cdot ) TEX TEX-NARY DISTRIBUTE_OVER (MEQUAL) RBP 129 LBP 130 GRIND MSIZE-NARY DISSYM ( . ) DIMENSION DIMENSION-NARY TRANSLATE #<FUNCTION (LAMBDA #) {962403D}> OPERATORS SIMPNCT MSIMPIND (MNCTIMES SIMP) OP .) Dieter Kaiser ---------------------------------------------------------------------- Comment By: Dieter Kaiser (crategus) Date: 2010-04-30 00:47 Message: The problem is caused by the interaction of the commands reset and kill. This is the simplest example I have found to generate the error: We trace the function kill-operator: (%i1) :lisp (trace kill-operator) (KILL-OPERATOR) Declare the dot-operator commutative: (%i1) declare(".",commutative); (%o1) done First, we do a reset: (%i2) reset(); (%o1) [features, _, __, mopl, labels, %, linenum, tr-unique, lispdisp] Second, we call kill(all). The trace shows that the dot-operator is killed: (%i2) kill(all); 0: (KILL-OPERATOR ${) 0: KILL-OPERATOR returned NIL 0: (KILL-OPERATOR $}) 0: KILL-OPERATOR returned NIL 0: (KILL-OPERATOR MNCTIMES) 0: KILL-OPERATOR returned (DIMENSION DISSYM LBP RBP) (%o0) done If we try again a declaration we get a Lisp error: (%i1) declare(".",commutative); Maxima encountered a Lisp error: The value "." is not of type LIST. Automatically continuing. To enable the Lisp debugger set *debugger-hook* to nil. We get the Lisp error because Maxima no longer translates the name of the dot-operator "." to mnctimes: (%i2) :lisp (getopr ".") . I think the problem is that the internal list mopl which does some bookkeeping of operators is reseted by the command reset. I will have a look at this point. Dieter Kaiser ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2994324&group_id=4933 |
From: SourceForge.net <no...@so...> - 2010-04-30 00:22:14
|
Bugs item #2994324, was opened at 2010-04-29 21:44 Message generated for change (Comment added) made by crategus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2994324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Leo Butler (l_butler) Assigned to: Nobody/Anonymous (nobody) Summary: tests in rtest_dot fail in 2nd run Initial Comment: If I run the test suite twice, then 'tests' 3, 52, 53 in rtest_dot fail on the second run. It appears that the dot operator is being redefined in some other test. ---------------------------------------------------------------------- >Comment By: Dieter Kaiser (crategus) Date: 2010-04-30 02:22 Message: As suggested fixed in suprv1.lisp revision 1.94. Closing this bug report as fixed. Dieter Kaiser ---------------------------------------------------------------------- Comment By: Dieter Kaiser (crategus) Date: 2010-04-30 01:41 Message: I have changed the definition of mopl in suprv1.lisp from (defmvar mopl nil) to (defvar mopl nil) and it works. The build-in operator "." is no longer killed by kill-operator. The testsuite has no problems and can be executed more than one times. The global list mopl is used by declare to store build-in operators which get new properties, but are not allowed to be killed. If a kill command is executed, operators which are on this list are not killed. Therefore, it is an error to reset the list mopl. With the change we get: (%i1) declare(".",commutative); (%o1) done The function declare1 puts the dot-operator on the list mopl: (%i2) :lisp mopl (. } {) The list mopl is no longer reseted: (%i2) reset(); (%o1) [_, __, labels, %, linenum, lispdisp] When we execute the command kill, the dot-operator is not killed: (%i2) kill(all); (%o0) done (%i1) :lisp (getopr ".") MNCTIMES Remark: The change of the definition of mopl does not change the possibility to remove additional properties from build-in operators with the command kill, it only prevents the operator to be killed too, e.g. (%i1) declare(".",commutative); (%o1) done The property list show the in addition the property $commutative: (%i2) :lisp (symbol-plist 'mnctimes) (OPERS T $COMMUTATIVE T DATA (((KIND MNCTIMES $COMMUTATIVE) CON $INITIAL)) +LABS (1) ASSOCIATIVE T TEXSYM (\cdot ) TEX TEX-NARY DISTRIBUTE_OVER (MEQUAL) RBP 129 LBP 130 GRIND MSIZE-NARY DISSYM ( . ) DIMENSION DIMENSION-NARY TRANSLATE #<FUNCTION (LAMBDA #) {962403D}> OPERATORS SIMPNCT MSIMPIND (MNCTIMES SIMP) OP .) This property is removed with kill(all): (%i2) kill(all); (%o0) done (%i1) :lisp (symbol-plist 'mnctimes) (ASSOCIATIVE T TEXSYM (\cdot ) TEX TEX-NARY DISTRIBUTE_OVER (MEQUAL) RBP 129 LBP 130 GRIND MSIZE-NARY DISSYM ( . ) DIMENSION DIMENSION-NARY TRANSLATE #<FUNCTION (LAMBDA #) {962403D}> OPERATORS SIMPNCT MSIMPIND (MNCTIMES SIMP) OP .) Dieter Kaiser ---------------------------------------------------------------------- Comment By: Dieter Kaiser (crategus) Date: 2010-04-30 00:47 Message: The problem is caused by the interaction of the commands reset and kill. This is the simplest example I have found to generate the error: We trace the function kill-operator: (%i1) :lisp (trace kill-operator) (KILL-OPERATOR) Declare the dot-operator commutative: (%i1) declare(".",commutative); (%o1) done First, we do a reset: (%i2) reset(); (%o1) [features, _, __, mopl, labels, %, linenum, tr-unique, lispdisp] Second, we call kill(all). The trace shows that the dot-operator is killed: (%i2) kill(all); 0: (KILL-OPERATOR ${) 0: KILL-OPERATOR returned NIL 0: (KILL-OPERATOR $}) 0: KILL-OPERATOR returned NIL 0: (KILL-OPERATOR MNCTIMES) 0: KILL-OPERATOR returned (DIMENSION DISSYM LBP RBP) (%o0) done If we try again a declaration we get a Lisp error: (%i1) declare(".",commutative); Maxima encountered a Lisp error: The value "." is not of type LIST. Automatically continuing. To enable the Lisp debugger set *debugger-hook* to nil. We get the Lisp error because Maxima no longer translates the name of the dot-operator "." to mnctimes: (%i2) :lisp (getopr ".") . I think the problem is that the internal list mopl which does some bookkeeping of operators is reseted by the command reset. I will have a look at this point. Dieter Kaiser ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2994324&group_id=4933 |
From: SourceForge.net <no...@so...> - 2010-04-30 14:06:58
|
Bugs item #2994324, was opened at 2010-04-29 20:44 Message generated for change (Comment added) made by l_butler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2994324&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Leo Butler (l_butler) Assigned to: Nobody/Anonymous (nobody) Summary: tests in rtest_dot fail in 2nd run Initial Comment: If I run the test suite twice, then 'tests' 3, 52, 53 in rtest_dot fail on the second run. It appears that the dot operator is being redefined in some other test. ---------------------------------------------------------------------- >Comment By: Leo Butler (l_butler) Date: 2010-04-30 15:06 Message: Thanks, that has fixed the bug. ---------------------------------------------------------------------- Comment By: Dieter Kaiser (crategus) Date: 2010-04-30 01:22 Message: As suggested fixed in suprv1.lisp revision 1.94. Closing this bug report as fixed. Dieter Kaiser ---------------------------------------------------------------------- Comment By: Dieter Kaiser (crategus) Date: 2010-04-30 00:41 Message: I have changed the definition of mopl in suprv1.lisp from (defmvar mopl nil) to (defvar mopl nil) and it works. The build-in operator "." is no longer killed by kill-operator. The testsuite has no problems and can be executed more than one times. The global list mopl is used by declare to store build-in operators which get new properties, but are not allowed to be killed. If a kill command is executed, operators which are on this list are not killed. Therefore, it is an error to reset the list mopl. With the change we get: (%i1) declare(".",commutative); (%o1) done The function declare1 puts the dot-operator on the list mopl: (%i2) :lisp mopl (. } {) The list mopl is no longer reseted: (%i2) reset(); (%o1) [_, __, labels, %, linenum, lispdisp] When we execute the command kill, the dot-operator is not killed: (%i2) kill(all); (%o0) done (%i1) :lisp (getopr ".") MNCTIMES Remark: The change of the definition of mopl does not change the possibility to remove additional properties from build-in operators with the command kill, it only prevents the operator to be killed too, e.g. (%i1) declare(".",commutative); (%o1) done The property list show the in addition the property $commutative: (%i2) :lisp (symbol-plist 'mnctimes) (OPERS T $COMMUTATIVE T DATA (((KIND MNCTIMES $COMMUTATIVE) CON $INITIAL)) +LABS (1) ASSOCIATIVE T TEXSYM (\cdot ) TEX TEX-NARY DISTRIBUTE_OVER (MEQUAL) RBP 129 LBP 130 GRIND MSIZE-NARY DISSYM ( . ) DIMENSION DIMENSION-NARY TRANSLATE #<FUNCTION (LAMBDA #) {962403D}> OPERATORS SIMPNCT MSIMPIND (MNCTIMES SIMP) OP .) This property is removed with kill(all): (%i2) kill(all); (%o0) done (%i1) :lisp (symbol-plist 'mnctimes) (ASSOCIATIVE T TEXSYM (\cdot ) TEX TEX-NARY DISTRIBUTE_OVER (MEQUAL) RBP 129 LBP 130 GRIND MSIZE-NARY DISSYM ( . ) DIMENSION DIMENSION-NARY TRANSLATE #<FUNCTION (LAMBDA #) {962403D}> OPERATORS SIMPNCT MSIMPIND (MNCTIMES SIMP) OP .) Dieter Kaiser ---------------------------------------------------------------------- Comment By: Dieter Kaiser (crategus) Date: 2010-04-29 23:47 Message: The problem is caused by the interaction of the commands reset and kill. This is the simplest example I have found to generate the error: We trace the function kill-operator: (%i1) :lisp (trace kill-operator) (KILL-OPERATOR) Declare the dot-operator commutative: (%i1) declare(".",commutative); (%o1) done First, we do a reset: (%i2) reset(); (%o1) [features, _, __, mopl, labels, %, linenum, tr-unique, lispdisp] Second, we call kill(all). The trace shows that the dot-operator is killed: (%i2) kill(all); 0: (KILL-OPERATOR ${) 0: KILL-OPERATOR returned NIL 0: (KILL-OPERATOR $}) 0: KILL-OPERATOR returned NIL 0: (KILL-OPERATOR MNCTIMES) 0: KILL-OPERATOR returned (DIMENSION DISSYM LBP RBP) (%o0) done If we try again a declaration we get a Lisp error: (%i1) declare(".",commutative); Maxima encountered a Lisp error: The value "." is not of type LIST. Automatically continuing. To enable the Lisp debugger set *debugger-hook* to nil. We get the Lisp error because Maxima no longer translates the name of the dot-operator "." to mnctimes: (%i2) :lisp (getopr ".") . I think the problem is that the internal list mopl which does some bookkeeping of operators is reseted by the command reset. I will have a look at this point. Dieter Kaiser ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2994324&group_id=4933 |