Ticket #123 (new defect)
Opened 18 months ago
Can't find Csr when Csr.mul(...) is overloaded
| Reported by: | jmaessen | Owned by: | jmaessen |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | interpreter | Version: | |
| Keywords: | Cc: |
Description
Uncomment the following code in source:trunk/Library/Sparse.fss :
(* Right now uncommenting unearths an obscure unification bug.
mul[\nat p\](other: Csc[\N,m,p\]) = do
(* Follow the structure of our rows, return Csr matrix. *)
resultRows = rows.replica[\SparseVector[\N,p\]\]()
resultRows.init(i,sparse(row other)), (i,row)<-rows.indexValuePairs()
Csr[\N,n,p\](resultRows)
end
*)
Doing so yields the following error:
com.sun.fortress.interpreter.evaluator.ProgramError:
/Users/jmaessen/PFC/Library/Sparse.fsi:34:7~10: Missing type Csr
Context:
/Users/jmaessen/PFC/Library/Sparse.fsi:34:7~10
ProjectFortress/tests/sparseMatrix.fss:81:2~29
ProjectFortress/tests/sparseMatrix.fss:81:2~29
at com.sun.fortress.interpreter.evaluator.ProgramError.error(ProgramError.java:91)
at com.sun.fortress.interpreter.evaluator.CommonEnv.getType(CommonEnv.java:165)
at com.sun.fortress.interpreter.evaluator.EvalType.forId(EvalType.java:446)
at com.sun.fortress.interpreter.evaluator.EvalType.evalType(EvalType.java:75)
at com.sun.fortress.interpreter.evaluator.types.FTraitOrObject.unifyNonVarGeneric(FTraitOrObject.java:305)
at com.sun.fortress.interpreter.evaluator.types.FTypeObjectInstance.unifyNonVar(FTypeObjectInstance.java:85)
at com.sun.fortress.interpreter.evaluator.types.FType.unify(FType.java:573)
at com.sun.fortress.interpreter.evaluator.EvaluatorBase.inferAndInstantiateGenericFunction(EvaluatorBase.java:238)
at com.sun.fortress.interpreter.evaluator.values.FGenericFunction.applyInner(FGenericFunction.java:204)
at com.sun.fortress.interpreter.evaluator.values.Fcn.apply(Fcn.java:100)
at com.sun.fortress.interpreter.evaluator.EvaluatorBase.functionInvocation(EvaluatorBase.java:87)
at com.sun.fortress.interpreter.evaluator.EvaluatorBase.functionInvocation(EvaluatorBase.java:77)
...
Which is clearly a runtime name-lookup problem of some sort.
Note: See
TracTickets for help on using
tickets.

