gmane.comp.lang.fortress.general

ZZ to ZZ64 or ZZ32

James Cranch — 2008-10-04T13:28:15

Hi there, I'm pretty happy with the support for bignums given by the trait ZZ. Except... I understand that if I have a small number which I wish to coerce to a ZZ, the way to do it is to add and then subtract something humongous (indeed, the definition of zero() in trait ZZ in the FortressLibrary uses 1934791870947204798109283471902037419). What if I have a ZZ, and I'm willing to guarantee it's actually small: how do I recover a ZZ32 or a ZZ64 out of it? Cheers, James \/\/\

Abwesenheitsnachricht

2008-10-02T02:00:56

Ich werde ab 28.08.2008 nicht im Büro sein. Ich kehre zurück am 06.10.2008. In dringende Fällen senden Sie Ihre Nachricht an iuk-K6Ck2cH0joNmeKtsT5rLx1NpE/a5I+DW< at >public.gmane.org oder wenden Sie sich an den Helpdesk, Tel. 07461/926-3000

No error description message for expression with generator

Sorin Miklós Zsejki — 2008-10-01T21:20:02

This only reports "Syntax error", with no other message: {{{ component Sample export Executable run(args) = println i, i <- 0:1 end }}} If I surround it with do end it works as expected. Should it be possible to write it like I did? Unrelated to this, thanks for r2895!

Some problems with test

Sorin Miklós Zsejki — 2008-09-18T22:59:40

I have components like Com.Example/Component.fss (not Com.Example.Component.fss), and when I run fortress test Com.Example.Component.fss it cannot find the file. If I do fortress test Com.Example/Component.fss it finds the file, but it throws something like: "Missing api name Com.Example.Component".

ant fails with the latest source code

Tom Trauth — 2008-09-17T09:37:24

I did an SVN Update this morning and then tried to compile fortress with ant. The ant compilation failed because "nodes/ModifierTransient.java:39 cannot find symbol: method forModifierTransient(com.sun.fortress.nodes.ModifierTransient)". This is the first time ant has had any problems. Does anyone have any idea what forModifierTransient is and where I can get it from? Thanks. Regards, Tom

EOL comments now supported

Jan-Willem Maessen — 2008-09-16T19:21:16

Sukyoung Ryu just implemented end of line comments, which are indicated by (*) (and can be used inside existing comments). It would be lovely if folks familiar with the various editors could fix the highlighting, etc. to handle these (I just looked at emacs comment support and mostly ended up confused). And of course you should feel free to try them out in your code. -Jan

rangeIntersect output when testing

Sorin Miklós Zsejki — 2008-09-12T23:47:29

In CordedString.fss, the rangeIntersect() test function prints the "starting rangeIntersect: " and "rangeIntersect done" messages, and this is called when I call Fortress with -test. I was a bit disoriented when I saw that output. Are these necessary? Or is it necessary to run all the tests in the standard libraries with -test?

Creating threads from native code

Sorin Miklós Zsejki — 2008-09-10T03:08:09

I am playing with creating windows from Fortress and calling back Fortress code from user events. The problem is that these events run in a thread created by AWT, so when I do anything else than calling a native method with no arguments from there, I get this error: Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: java.awt.EventDispatchThread cannot be cast to com.sun.fortress.interpreter.evaluator.tasks.FortressTaskRunner Is there a quick way to fix this? (I guess I also have to read the threads/tasks part of the interpreter....)

Are strided for-loops implemented?

Tom Trauth — 2008-09-07T19:59:36

To all: Section 13.16 of the v.10 spec (which defines a range to be "Expr?:Expr(:?Expr)?") and Ticket #200 (which is about how to handle a range defined as a:b:c where c = 0) imply that one can do a strided (stepped) for-loop as follows: for <- 0:10:2 do . But the following program fails with a message that "Failed to find any matching overload, args = (ParRange[\ZZ32,true\],2: ZZ32)": component tom export Executable run(args:String...):() = do for i <- 0:10:2 do println(i) end end end If I change the range to "0:10", it works fine, so I know that the ":2" is the culprit. Did I make a subtle mistake or is this feature not yet implemented? And if it's not yet implemented, is the planned future implementation a multifix colon range operator that takes 3 parameters (a:b:c), or an infix colon stride operator that takes a range as its first parameter and a stride as its second (r:c, where r = a:b)? And sorry if the above is a stupid question, but I am relatively new to this language and just downloaded it recently. Regards, -Tom

vmkit: JVM for LLVM

Michael Spiegel — 2008-09-04T18:14:58

Some food for thought on future Fortress compiler targets. Unfortunately, LLVM currently has no concurrent garbage collector. That's the biggest loss. And a whole host of other features would need to be implemented in order for LLVM to be a viable target. But some of the performance metrics in this presentation are quite interesting: http://llvm.org/devmtg/2008-08/ (Check under "The VMKit Project" and watch the video). --Michael

Testing for specific thrown exceptions

Sorin Miklós Zsejki — 2008-09-03T19:13:44

Some time ago I searched in the FortressLibrary for a way to unit test that my fortress code throws a specific error and I didn't find something like that (is there?). So I have written such a function that I find quite useful and probably others might find it useful too. I am attaching my version of it for the curious and for the willing to comment and give me advice on my current fortress coding style (or lack of it). The code is very simple, and the most common use is something like this: expect[\ExpectedExceptionType\](f) where ExpectedExceptionType is the type of exception that should be thrown by f(). There are 2 alternative forms for more specific testing: expect[\E\](f, expectedException) that checks that the exception that is thrown is equal to expectedException and: expect[\E\](f, fn(e: Exception) => (* check that the thrown exception satisfies any other condition *) ) Please tell me what you think.

Is there a problem?

Russel Winder — 2008-08-30T06:56:04

For the last few days I have been unable to build Fortress. Has there been a change to the way things have to be built or is it just that there is an error in the source? BTW is there a CI server? |> ( cd Subversion/Fortress_Trunk/ && ./ant clean compile ) Buildfile: build.xml clean: cleanCache: [delete] Deleting directory /home/Checkouts/Subversion/Fortress_Trunk/default_repository/caches clean: [delete] Deleting directory /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build [delete] Deleting directory /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/nodes [delete] Deleting directory /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/junit-results [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/preparser/PreFortress.java [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser_util/precedence_resolver/Operators.java [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/Library/FortressAst.fsi [delete] Deleting: /home/Checkouts/Subversion/Fortress_Trunk/Library/FortressAst.fss compile: init: [echo] basedir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress [mkdir] Created dir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build [mkdir] Created dir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/junit-results compileCommon: [javac] Compiling 103 source files to /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. checkAstgen: astGenerators: [javac] Compiling 14 source files to /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build checkNodesUptodate: [echo] Nodes up to date? ${nodes.uptodate} makeAST: [echo] Processing /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/astgen/Fortress.ast [move] Moving 1357 files to /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/nodes [move] Moving 2 files to /home/Checkouts/Subversion/Fortress_Trunk/Library checkParserUptodate: [echo] Parser up to date? ${parser.uptodate} checkOperatorsUptodate: [echo] Operators up to date? ${operators.uptodate} operatorsGen: [echo] Regenerating operators [java] Groups: [tri_contains, multiplication_and_division, square_union, superset_comparison_operators, curly_succeeds, curly_precedes, equivalence_operators, number_sign, c_2_1_division, single_colon, square_intersection, set_union, less_than_operators, square_image_of, dot_above_multiplication_and_division, misc_set_comparison, square_original_of, square_misc, boolean_disjunction, squared_addition_and_subtraction, c_2_1_multiplication, dot_above_addition_and_subtraction, chickenfoot_smaller, enclosing_right, plain_comparison, tri_subgroup, boolean_misc_nonAssociative, squared_multiplication_and_division, misc_addition, inequivalence_operators, curly_misc, dot_below_addition_and_subtraction, boolean_misc_leftAssociative, subset_comparison_operators, chickenfoot_greater, other_operators, set_intersection, curly_or, circled_multiplication_and_division, curly_and, tri_addition_and_subtraction, greater_than_operators, relational_misc, misc_set, tri_misc, circled_addition_and_subtraction, enclosing, addition_and_subtraction, enclosing_left, tri_multiplication_and_division, boolean_conjunction, double_colon] parser: Trying to override old definition of task astgen init: [echo] basedir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress checkFortressParserUptodate: [echo] Fortress parser up to date? ${parser.uptodate} fortressparser: [echo] Rebuilding Fortress... [java] Rats! Parser Generator, v. 1.14.1, (C) 2004-2008 Robert Grimm [java] Processing Fortress.rats ... Trying to override old definition of task astgen init: [echo] basedir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress checkPreparserUptodate: [echo] Preparser up to date? ${preparser.uptodate} preparser: [echo] Rebuilding preparser... [java] Rats! Parser Generator, v. 1.14.1, (C) 2004-2008 Robert Grimm [java] Processing PreFortress.rats ... Trying to override old definition of task astgen init: [echo] basedir: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress checkTemplateparserUptodate: [echo] Templateparser up to date? ${templateparser.uptodate} templateparser: [echo] Rebuilding template parser... [java] Rats! Parser Generator, v. 1.14.1, (C) 2004-2008 Robert Grimm [java] Processing TemplateParser.rats ... compile: [javac] Compiling 1920 source files to /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/preparser/PreFortress.java:1311: cannot find symbol [javac] symbol : constructor ImportNames(com.sun.fortress.nodes_util.Span,com.sun.fortress.nodes.APIName,java.util.List) [javac] location: class com.sun.fortress.nodes.ImportNames [javac] Import imp = new ImportNames(createSpan(yyStart,yyCount), api, [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java:2289: cannot find symbol [javac] symbol : constructor ImportNames(com.sun.fortress.nodes_util.Span,com.sun.fortress.nodes.APIName,java.util.List) [javac] location: class com.sun.fortress.nodes.ImportNames [javac] Import imp = new ImportNames(createSpan(yyStart,yyCount), api, [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java:4348: cannot find symbol [javac] symbol : method makeVarargsParam(com.sun.fortress.nodes.VarargsParam,java.util.List) [javac] location: class com.sun.fortress.nodes_util.NodeFactory [javac] yyValue = NodeFactory.makeVarargsParam(a1, FortressUtil.mkList( [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java:16246: cannot find symbol [javac] symbol : constructor AbsVarDecl(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.AbsVarDecl [javac] yyValue = new AbsVarDecl(createSpan(yyStart,yyCount), [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java:28313: cannot find symbol [javac] symbol : constructor GroupSymbol(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.GroupSymbol [javac] yyValue = new NoWhitespaceSymbol(createSpan(yyStart,yyCount), new GroupSymbol(createSpan(yyStart, yyCount), FortressUtil.mkList(((NoWhitespaceSymbol) s).getSymbol())) ); [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/Fortress.java:28315: cannot find symbol [javac] symbol : constructor GroupSymbol(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.GroupSymbol [javac] yyValue = new GroupSymbol(createSpan(yyStart, yyCount), FortressUtil.mkList(s)); } [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java:2309: cannot find symbol [javac] symbol : constructor ImportNames(com.sun.fortress.nodes_util.Span,com.sun.fortress.nodes.APIName,java.util.List) [javac] location: class com.sun.fortress.nodes.ImportNames [javac] Import imp = new ImportNames(createSpan(yyStart,yyCount), api, [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java:4380: cannot find symbol [javac] symbol : method makeVarargsParam(com.sun.fortress.nodes.VarargsParam,java.util.List) [javac] location: class com.sun.fortress.nodes_util.NodeFactory [javac] yyValue = NodeFactory.makeVarargsParam(a1, FortressUtil.mkList( [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java:16298: cannot find symbol [javac] symbol : constructor AbsVarDecl(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.AbsVarDecl [javac] yyValue = new AbsVarDecl(createSpan(yyStart,yyCount), [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java:28369: cannot find symbol [javac] symbol : constructor GroupSymbol(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.GroupSymbol [javac] yyValue = new NoWhitespaceSymbol(createSpan(yyStart,yyCount), new GroupSymbol(createSpan(yyStart, yyCount), FortressUtil.mkList(((NoWhitespaceSymbol) s).getSymbol())) ); [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/parser/templateparser/TemplateParser.java:28371: cannot find symbol [javac] symbol : constructor GroupSymbol(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.GroupSymbol [javac] yyValue = new GroupSymbol(createSpan(yyStart, yyCount), FortressUtil.mkList(s)); } [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/tests/unit_tests/ConstructorsJUTest.java:130: cannot find symbol [javac] symbol : constructor Export(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.Export [javac] Export e1 = new Export(span1, FortressUtil.mkList(newAPIName("some", "exported", "apiname"))); [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/tests/unit_tests/ConstructorsJUTest.java:131: cannot find symbol [javac] symbol : constructor Export(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.Export [javac] Export e2 = new Export(span1, FortressUtil.mkList(newAPIName("some", "exported", "apiname"))); [javac] ^ [javac] /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/src/com/sun/fortress/tests/unit_tests/ConstructorsJUTest.java:132: cannot find symbol [javac] symbol : constructor Export(com.sun.fortress.nodes_util.Span,java.util.List) [javac] location: class com.sun.fortress.nodes.Export [javac] Export e3 = new Export(span1, FortressUtil.mkList(newAPIName("an", "exported", "apiname"))); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 14 errors BUILD FAILED /home/Checkouts/Subversion/Fortress_Trunk/build.xml:8: The following error occurred while executing this line: /home/Checkouts/Subversion/Fortress_Trunk/ProjectFortress/build.xml:400: Compile failed; see the compiler error output for details. Total time: 2 minutes 31 seconds

Abwesenheitsnachricht

2008-08-29T02:00:46

Ich werde ab 28.08.2008 nicht im Büro sein. Ich kehre zurück am 08.09.2008. In dringende Fällen senden Sie Ihre Nachricht an iuk-K6Ck2cH0joNmeKtsT5rLx1NpE/a5I+DW< at >public.gmane.org oder wenden Sie sich an den Helpdesk, Tel. 07461/926-3000

Proposal to tweak | | syntax

Guy Steele — 2008-08-28T20:36:25

In observing how the "absolute-value" notation is used in practice to refer to the size of a string or a list (thank you, Andrew Black and Steve Heller for walking me through some of your code), I have noticed that certain very plausible expressions are awkward to write in Fortress because of our current rules for deciding whether any given occurrence of "|" is a left encloser, a right encloser, or an infix operator. For example, 0#|a| works but |a|#|b| does not. It is also awkward to make | |a| - |b| | work; one must use parentheses inside the outer absolute value brackets: |(|a| - |b|)| which looks terrible. I propose to tweak the rules given in Fortress spec Figure 16.2 Operator Fixity (II) as follows. Here is the existing table: and here is the proposed modification: The asterisks indicate places that have changed. The first and most important change is to the case "primary|OPERATOR" with no whitespace, to make it interpret the "|" as a right encloser rather than an infix operator. This is an incompatible change, but I doubt it will affect any existing code. The second set of changes is upward compatible, because they merely provide valid interpretations for situations that were formerly static errors: primary |, OPERATOR | OPERATOR OPERATOR | , OPERATOR |, OPERATOR| , OPERATOR|, OPERATOR | linebreak OPERATOR |linebreak OPERATOR| linebreak OPERATOR|linebreak The third set of changes deals with situations formerly unaddressed by the table which should have been: what happens right after a line break. With these changes, the following expressions would become valid: |a|:|a|+3 |a|#|b| |a|#|b|+|c| |a|+|b|+|c| | |a| - |b| | when it occurs within enclosers or between commas "The length " || |a| || " is just right." I think this change would make |...| notation (and ||...|| notation) much more convenient to use. --Guy

What should the arguments to Fcn.apply() be?

Sorin Miklós Zsejki — 2008-08-26T21:48:53

I am calling a Fortress function from a NativeMeth1.act(), but I don't know what HasAt and Environment to pass to Fcn.apply(). Now I just put nulls and it works, which I doubted before I just tried (especially about Environment). I would be grateful if anyone has a little time to discuss this a little bit. By the way, getters/setters rock!

ไม่ต้องประชุมไม่ต้องขายให้คอมพิวเตอร์หาเงินให้ท่านเดือนละครึ่งแสน

pornphol — 2008-08-22T10:18:02

ถูกที่ถูกเวลาถูกระบบถูกทีมงานสำเร็จแน่ออนไลน์100% “ คนที่ร่ำรวยที่สุดในโลก แสวงหาการสร้างเครือข่าย” งานประจำ ไม่ทำให้ร่ำรวย มีแต่หนี้ ถ้าต้องการความสำเร็จ ต้องเป็นเจ้าของธุรกิจ ลงทุนน้อย สร้างรายได้มหาศาล ไม่ต้องประชุมไม่ต้องขายต่อสายงานให้อัตโนมัติ มีเวปไซด์ภาษาไทยให้ฟรี มีโปรแกรมที่ทำให้คอมพิวเตอร์โปรโมทงานให้ท่านโดยที่ไม่ต้องเฝ้าหน้าจอ ฟรี 087-8054646 พล http://rejuvenate.blog.mthai.com/2008/08/21/public-1 ขออภัยที่เมล์นี้รบกวนท่าน

Miễn phí tặng bạn 7 website!

WebHosting — 2008-08-21T09:51:08

Conflicting overloadings in an evolving trait hierarchy

Andrew P. Black — 2008-08-15T20:59:29

I'm trying to get to grips with the consequences of the "overloading rules" as Fortress uses them to implement multiple dispatch. Here is a concrete example to explain the problem. I'm re-jigging the String hierarchy to allow multiple implementations of String. String is, in effect, and abstract supertype. The idea is that it should be possible to add new implementations for specific purposes. The first three are EmptyString, CatString, which is a concatenation of two other strings, and JavaString, which is the flat sequence of characters that you know from Java. Let's look at how we define the concatenation operation || trait String opr ||(String, String): String end object EmptyString extends String opr || (self, other:String): String = other opr || (other: String, self): String = other(* This is an optimization --- Originally CordedString line 72 *) opr || (self, _: EmptyString): String = self(* this is required to disambiguate the previous two *) end object CatString extends String opr || (self, other:String): String = CatString(self, other) opr || (self, _:EmptyString) = self(* This is an optimization *) end object JavaString extends String opr ||(self, b:JavaString):String = ... opr ||(self, b:String):String = (* Originally JavaString line 69 *) CatString(self, b) opr ||(self, b:EmptyString):String =(* Originally JavaString line 71 *) self end Without line JavaString line 71, there is an ambiguity between lines 72 ||(other:String,self:EmptyString):String and line 69 || (self:JavaString,b:String):String. I added line 71 to resolve this. The larger problem is that with this design, it seems that each time someone adds the (n+1)th implementation of String, the other n object definitions will need a new method to resolve the ambiguity that would otherwise be introduced. This is not scalable. It's no worse than writing in a single-dispatch language, when the double dispatches have to be hand-coded, but it's not better either. Isn't Fortress supposed to be better? Is there a way to structure this code to avoid this problem? I also have a more specific problem. After adding JavaString line 71, I still get a conflicting overloading: Overloading of (first) ||(other:String,self:EmptyString):Stringfn meth(self 1): (String,EmptyString)->String (CordedString:72) and (second) ||(self:JavaString,b:String):Stringfn meth(self 0): (JavaString,String)->String (JavaString:69) fails Why didn't line 71 resolve this?

un-concreting a method

Michael Spiegel — 2008-08-14T20:34:40

Is this the intended behavior of the language? We are un-concreting a method and get an error message in the interpreter. component UnConcreteMethodTest export Executable trait A foo():ZZ32 = 5 end A trait B extends {A} foo():ZZ32 end B object C extends {B} end C run(args:String...) = do println C.foo() end end UnConcreteMethodTest

Professional Grant Proposal Writing Workshop (August 2008: Philadelphia, Pennsylvania - University of Phoenix Campus)

Anthony Jones — 2008-08-06T05:50:10

Static parameters for functional methods

Sorin Miklós Zsejki — 2008-07-23T22:58:36

Is this a bug? This code: component Sample export Executable trait X m[\T extends X\](self): T end run(args) = () end gives a "Missing type T" error. In fact, wherever I use T, for example as the type of a parameter, I get the same error, but it works if it's a regular method. I am almost sure I could do this some time ago.