Bill Janssen
2011-02-26, 23:07
Andi Vajda
2011-02-26, 23:21
Bill Janssen
2011-02-26, 23:48
Andi Vajda
2011-02-27, 00:12
Bill Janssen
2011-02-27, 18:08
Andi Vajda
2011-03-01, 04:05
Andi Vajda
2011-03-03, 03:46
Bill Janssen
2011-03-03, 20:50
Bill Janssen
2011-03-03, 22:42
Andi Vajda
2011-03-03, 23:12
Andi Vajda
2011-03-03, 23:35
Bill Janssen
2011-03-04, 01:45
Bill Janssen
2011-03-04, 02:51
Andi Vajda
2011-03-04, 03:42
Andi Vajda
2011-03-04, 03:42
Andi Vajda
2011-03-04, 03:49
Bill Janssen
2011-03-04, 05:43
Bill Janssen
2011-03-04, 05:44
Bill Janssen
2011-03-04, 06:09
Andi Vajda
2011-03-04, 06:21
Andi Vajda
2011-03-04, 06:42
Bill Janssen
2011-03-07, 19:18
Andi Vajda
2011-03-07, 19:46
Bill Janssen
2011-03-07, 21:08
Andi Vajda
2011-03-07, 22:07
Bill Janssen
2011-03-08, 00:33
Andi Vajda
2011-03-08, 00:36
Andi Vajda
2011-03-08, 00:40
Bill Janssen
2011-03-08, 02:30
Andi Vajda
2011-03-25, 17:46
Bill Janssen
2011-03-25, 18:37
jason_ni
2011-08-20, 07:49
Andi Vajda
2011-08-20, 21:59
jason_ni
2011-08-24, 00:10
Andi Vajda
2011-08-24, 00:44
Andi Vajda
2011-08-28, 23:25
Jason Ni
2011-08-29, 13:59
-
issue with automatic iterable detection?Bill Janssen 2011-02-26, 23:07
I'm seeing a lot of errors of the form:
build/_GoodStuff/__wrap07__.cpp:57522: error: ‘class com::parc::goodstuff::t_FooIterator’ has no member named ‘parameters’
Apparently relating to code like this:
if (!parseArgs(args, ""))
{
OBJ_CALL(result = self->object.nextElement());
return self->parameters[0] != NULL ? \
wrapType(self->parameters[0], result.this$) : \
java::lang::t_Object::wrap_Object(result);
}
I look in the header files, and, sure enough, there's no "parameters"
field to be found.
FooIterator is pretty complicated; it extends an abstract class, and
implements several interfaces as well. I wonder if something is getting
mixed up about where the "parameters" member should be emitted.
Bill
build/_GoodStuff/__wrap07__.cpp:57522: error: ‘class com::parc::goodstuff::t_FooIterator’ has no member named ‘parameters’
Apparently relating to code like this:
if (!parseArgs(args, ""))
{
OBJ_CALL(result = self->object.nextElement());
return self->parameters[0] != NULL ? \
wrapType(self->parameters[0], result.this$) : \
java::lang::t_Object::wrap_Object(result);
}
I look in the header files, and, sure enough, there's no "parameters"
field to be found.
FooIterator is pretty complicated; it extends an abstract class, and
implements several interfaces as well. I wonder if something is getting
mixed up about where the "parameters" member should be emitted.
Bill
-
Re: issue with automatic iterable detection?Andi Vajda 2011-02-26, 23:21
On Sat, 26 Feb 2011, Bill Janssen wrote:
> I'm seeing a lot of errors of the form:
>
> build/_GoodStuff/__wrap07__.cpp:57522: error: ?class com::parc::goodstuff::t_FooIterator? has no member named ?parameters?
>
> Apparently relating to code like this:
>
> if (!parseArgs(args, ""))
> {
> OBJ_CALL(result = self->object.nextElement());
> return self->parameters[0] != NULL ? \
> wrapType(self->parameters[0], result.this$) : \
> java::lang::t_Object::wrap_Object(result);
> }
>
> I look in the header files, and, sure enough, there's no "parameters"
> field to be found.
>
> FooIterator is pretty complicated; it extends an abstract class, and
> implements several interfaces as well. I wonder if something is getting
> mixed up about where the "parameters" member should be emitted.
Maybe you found an unrelated bug ?
It may be simplest if you can send me the source file for this class as well
as a small jar file I can use to reproduce this ?
Andi..
-
Re: issue with automatic iterable detection?Bill Janssen 2011-02-26, 23:48
Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> On Sat, 26 Feb 2011, Bill Janssen wrote:
>
> > I'm seeing a lot of errors of the form:
> >
> > build/_GoodStuff/__wrap07__.cpp:57522: error: ?class com::parc::goodstuff::t_FooIterator? has no member named ?parameters?
> >
> > Apparently relating to code like this:
> >
> > if (!parseArgs(args, ""))
> > {
> > OBJ_CALL(result = self->object.nextElement());
> > return self->parameters[0] != NULL ? \
> > wrapType(self->parameters[0], result.this$) : \
> > java::lang::t_Object::wrap_Object(result);
> > }
> >
> > I look in the header files, and, sure enough, there's no "parameters"
> > field to be found.
> >
> > FooIterator is pretty complicated; it extends an abstract class, and
> > implements several interfaces as well. I wonder if something is getting
> > mixed up about where the "parameters" member should be emitted.
>
> Maybe you found an unrelated bug ?
> It may be simplest if you can send me the source file for this class
> as well as a small jar file I can use to reproduce this ?
Yes, that would be great, but it's part of a huge shaggy jarball I'm
trying to wrap. Don't know if it really has any significant relation
to the iteraction detection.
I'm guessing what's going on is that I actually have two huge shaggy jar
files, goodstuff.jar and libstuff.jar. I'm using "--jar goodstuff.jar
--include libstuff.jar". The actual iterator class is in libstuff.jar,
but the derived class is in goodstuff.jar. I thought that perhaps JCC
was thinking that the "parameters" member would be generated for the
class in libstuff.jar, but since that wasn't actually being processed,
the expected member variable wasn't there.
I'll see what I can figure out.
Bill
>
> On Sat, 26 Feb 2011, Bill Janssen wrote:
>
> > I'm seeing a lot of errors of the form:
> >
> > build/_GoodStuff/__wrap07__.cpp:57522: error: ?class com::parc::goodstuff::t_FooIterator? has no member named ?parameters?
> >
> > Apparently relating to code like this:
> >
> > if (!parseArgs(args, ""))
> > {
> > OBJ_CALL(result = self->object.nextElement());
> > return self->parameters[0] != NULL ? \
> > wrapType(self->parameters[0], result.this$) : \
> > java::lang::t_Object::wrap_Object(result);
> > }
> >
> > I look in the header files, and, sure enough, there's no "parameters"
> > field to be found.
> >
> > FooIterator is pretty complicated; it extends an abstract class, and
> > implements several interfaces as well. I wonder if something is getting
> > mixed up about where the "parameters" member should be emitted.
>
> Maybe you found an unrelated bug ?
> It may be simplest if you can send me the source file for this class
> as well as a small jar file I can use to reproduce this ?
Yes, that would be great, but it's part of a huge shaggy jarball I'm
trying to wrap. Don't know if it really has any significant relation
to the iteraction detection.
I'm guessing what's going on is that I actually have two huge shaggy jar
files, goodstuff.jar and libstuff.jar. I'm using "--jar goodstuff.jar
--include libstuff.jar". The actual iterator class is in libstuff.jar,
but the derived class is in goodstuff.jar. I thought that perhaps JCC
was thinking that the "parameters" member would be generated for the
class in libstuff.jar, but since that wasn't actually being processed,
the expected member variable wasn't there.
I'll see what I can figure out.
Bill
-
Re: issue with automatic iterable detection?Andi Vajda 2011-02-27, 00:12
On Feb 26, 2011, at 18:48, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>>
>> On Sat, 26 Feb 2011, Bill Janssen wrote:
>>
>>> I'm seeing a lot of errors of the form:
>>>
>>> build/_GoodStuff/__wrap07__.cpp:57522: error: ?class
>>> com::parc::goodstuff::t_FooIterator? has no member named ?
>>> parameters?
>>>
>>> Apparently relating to code like this:
>>>
>>> if (!parseArgs(args, ""))
>>> {
>>> OBJ_CALL(result = self->object.nextElement());
>>> return self->parameters[0] != NULL ? \
>>> wrapType(self->parameters[0], result.this$) : \
>>> java::lang::t_Object::wrap_Object(result);
>>> }
>>>
>>> I look in the header files, and, sure enough, there's no
>>> "parameters"
>>> field to be found.
>>>
>>> FooIterator is pretty complicated; it extends an abstract class, and
>>> implements several interfaces as well. I wonder if something is
>>> getting
>>> mixed up about where the "parameters" member should be emitted.
>>
>> Maybe you found an unrelated bug ?
>> It may be simplest if you can send me the source file for this class
>> as well as a small jar file I can use to reproduce this ?
>
> Yes, that would be great, but it's part of a huge shaggy jarball I'm
> trying to wrap. Don't know if it really has any significant relation
> to the iteraction detection.
>
> I'm guessing what's going on is that I actually have two huge shaggy
> jar
> files, goodstuff.jar and libstuff.jar. I'm using "--jar goodstuff.jar
> --include libstuff.jar". The actual iterator class is in
> libstuff.jar,
> but the derived class is in goodstuff.jar. I thought that perhaps JCC
> was thinking that the "parameters" member would be generated for the
> class in libstuff.jar, but since that wasn't actually being processed,
> the expected member variable wasn't there.
The parameters stuff is related to Java generics. It's represents the
type parameters for a generic class.
Andi..
>
> I'll see what I can figure out.
>
> Bill
-
Re: issue with automatic iterable detection?Bill Janssen 2011-02-27, 18:08
Andi Vajda <[EMAIL PROTECTED]> wrote:
> It may be simplest if you can send me the source file for this class
> as well as a small jar file I can use to reproduce this ?
Turns out to be simple to reproduce. Put the attached in a file called
test.java, and run this sequence:
% javac -classpath . test.java
% jar cf test.jar *.class
% python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
Bill
> It may be simplest if you can send me the source file for this class
> as well as a small jar file I can use to reproduce this ?
Turns out to be simple to reproduce. Put the attached in a file called
test.java, and run this sequence:
% javac -classpath . test.java
% jar cf test.jar *.class
% python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
Bill
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-01, 04:05
On Sun, 27 Feb 2011, Bill Janssen wrote:
> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>> It may be simplest if you can send me the source file for this class
>> as well as a small jar file I can use to reproduce this ?
>
> Turns out to be simple to reproduce. Put the attached in a file called
> test.java, and run this sequence:
>
> % javac -classpath . test.java
> % jar cf test.jar *.class
> % python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
This was a tougher one. It was triggered by a combination of things:
- no wrapper requested for java.io.File or --package java.io
- a subclass of a parameterized class or interface implementor of a
parameterized interface wasn't pulling in classes used as type
parameters (java.io.File here).
A fix is checked into jcc trunk/branch_3x rev 1075642.
This also includes the earlier fix about using absolute class names.
Andi..
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-03, 03:46
Bill,
Did that solve your problem ?
Andi..
On Feb 28, 2011, at 20:05, Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> On Sun, 27 Feb 2011, Bill Janssen wrote:
>
>> Andi Vajda <[EMAIL PROTECTED]> wrote:
>>
>>> It may be simplest if you can send me the source file for this class
>>> as well as a small jar file I can use to reproduce this ?
>>
>> Turns out to be simple to reproduce. Put the attached in a file called
>> test.java, and run this sequence:
>>
>> % javac -classpath . test.java
>> % jar cf test.jar *.class
>> % python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
>
> This was a tougher one. It was triggered by a combination of things:
> - no wrapper requested for java.io.File or --package java.io
> - a subclass of a parameterized class or interface implementor of a
> parameterized interface wasn't pulling in classes used as type
> parameters (java.io.File here).
>
> A fix is checked into jcc trunk/branch_3x rev 1075642.
> This also includes the earlier fix about using absolute class names.
>
> Andi..
Did that solve your problem ?
Andi..
On Feb 28, 2011, at 20:05, Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> On Sun, 27 Feb 2011, Bill Janssen wrote:
>
>> Andi Vajda <[EMAIL PROTECTED]> wrote:
>>
>>> It may be simplest if you can send me the source file for this class
>>> as well as a small jar file I can use to reproduce this ?
>>
>> Turns out to be simple to reproduce. Put the attached in a file called
>> test.java, and run this sequence:
>>
>> % javac -classpath . test.java
>> % jar cf test.jar *.class
>> % python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
>
> This was a tougher one. It was triggered by a combination of things:
> - no wrapper requested for java.io.File or --package java.io
> - a subclass of a parameterized class or interface implementor of a
> parameterized interface wasn't pulling in classes used as type
> parameters (java.io.File here).
>
> A fix is checked into jcc trunk/branch_3x rev 1075642.
> This also includes the earlier fix about using absolute class names.
>
> Andi..
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-03, 20:50
Andi Vajda <[EMAIL PROTECTED]> wrote:
> Bill,
>
> Did that solve your problem ?
Haven't had a chance to try it yet. Will report back when I do.
Bill
>
> Andi..
>
> On Feb 28, 2011, at 20:05, Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> >
> > On Sun, 27 Feb 2011, Bill Janssen wrote:
> >
> >> Andi Vajda <[EMAIL PROTECTED]> wrote:
> >>
> >>> It may be simplest if you can send me the source file for this class
> >>> as well as a small jar file I can use to reproduce this ?
> >>
> >> Turns out to be simple to reproduce. Put the attached in a file called
> >> test.java, and run this sequence:
> >>
> >> % javac -classpath . test.java
> >> % jar cf test.jar *.class
> >> % python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
> >
> > This was a tougher one. It was triggered by a combination of things:
> > - no wrapper requested for java.io.File or --package java.io
> > - a subclass of a parameterized class or interface implementor of a
> > parameterized interface wasn't pulling in classes used as type
> > parameters (java.io.File here).
> >
> > A fix is checked into jcc trunk/branch_3x rev 1075642.
> > This also includes the earlier fix about using absolute class names.
> >
> > Andi..
> Bill,
>
> Did that solve your problem ?
Haven't had a chance to try it yet. Will report back when I do.
Bill
>
> Andi..
>
> On Feb 28, 2011, at 20:05, Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> >
> > On Sun, 27 Feb 2011, Bill Janssen wrote:
> >
> >> Andi Vajda <[EMAIL PROTECTED]> wrote:
> >>
> >>> It may be simplest if you can send me the source file for this class
> >>> as well as a small jar file I can use to reproduce this ?
> >>
> >> Turns out to be simple to reproduce. Put the attached in a file called
> >> test.java, and run this sequence:
> >>
> >> % javac -classpath . test.java
> >> % jar cf test.jar *.class
> >> % python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
> >
> > This was a tougher one. It was triggered by a combination of things:
> > - no wrapper requested for java.io.File or --package java.io
> > - a subclass of a parameterized class or interface implementor of a
> > parameterized interface wasn't pulling in classes used as type
> > parameters (java.io.File here).
> >
> > A fix is checked into jcc trunk/branch_3x rev 1075642.
> > This also includes the earlier fix about using absolute class names.
> >
> > Andi..
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-03, 22:42
This looks like a problem.
This is with an svn checkout of branch_3x.
Bill
122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py", line 98, in <module>
cpp.jcc(sys.argv)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 548, in jcc
addRequiredTypes(cls, typeset, generics)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 233, in addRequiredTypes
addRequiredTypes(cls, typeset, True)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 238, in addRequiredTypes
addRequiredTypes(ta, typeset, True)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 240, in addRequiredTypes
raise NotImplementedError, repr(cls)
NotImplementedError: <Type: double[]>
%
This is with an svn checkout of branch_3x.
Bill
122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py", line 98, in <module>
cpp.jcc(sys.argv)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 548, in jcc
addRequiredTypes(cls, typeset, generics)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 233, in addRequiredTypes
addRequiredTypes(cls, typeset, True)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 238, in addRequiredTypes
addRequiredTypes(ta, typeset, True)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 240, in addRequiredTypes
raise NotImplementedError, repr(cls)
NotImplementedError: <Type: double[]>
%
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-03, 23:12
Indeed, this is why I put that assertion there :-)
It's a bit of guesswork what all the possibilities are there.
I'll add support for arrays there.
Andi..
On Thu, 3 Mar 2011, Bill Janssen wrote:
> This looks like a problem.
>
> This is with an svn checkout of branch_3x.
>
> Bill
>
> 122, in _run_module_as_main
> "__main__", fname, loader, pkg_name)
> File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
> exec code in run_globals
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py", line 98, in <module>
> cpp.jcc(sys.argv)
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 548, in jcc
> addRequiredTypes(cls, typeset, generics)
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 233, in addRequiredTypes
> addRequiredTypes(cls, typeset, True)
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 238, in addRequiredTypes
> addRequiredTypes(ta, typeset, True)
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 240, in addRequiredTypes
> raise NotImplementedError, repr(cls)
> NotImplementedError: <Type: double[]>
> %
>
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-03, 23:35
On Thu, 3 Mar 2011, Andi Vajda wrote:
> Indeed, this is why I put that assertion there :-)
> It's a bit of guesswork what all the possibilities are there.
> I'll add support for arrays there.
Fix is checked into rev 1076883.
Back to you, Bill.
Thanks !
Andi..
>
> Andi..
>
> On Thu, 3 Mar 2011, Bill Janssen wrote:
>
>> This looks like a problem.
>>
>> This is with an svn checkout of branch_3x.
>>
>> Bill
>>
>> 122, in _run_module_as_main
>> "__main__", fname, loader, pkg_name)
>> File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
>> exec code in run_globals
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py",
>> line 98, in <module>
>> cpp.jcc(sys.argv)
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
>> line 548, in jcc
>> addRequiredTypes(cls, typeset, generics)
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
>> line 233, in addRequiredTypes
>> addRequiredTypes(cls, typeset, True)
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
>> line 238, in addRequiredTypes
>> addRequiredTypes(ta, typeset, True)
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
>> line 240, in addRequiredTypes
>> raise NotImplementedError, repr(cls)
>> NotImplementedError: <Type: double[]>
>> %
>>
>
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-04, 01:45
Did a fresh checkout and here's the next issue.
This one may be harder to fix...
Bill
Traceback (most recent call last):
File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py", line 98, in <module>
cpp.jcc(sys.argv)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 551, in jcc
addRequiredTypes(cls, typeset, generics)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 233, in addRequiredTypes
addRequiredTypes(cls, typeset, True)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 238, in addRequiredTypes
addRequiredTypes(ta, typeset, True)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 238, in addRequiredTypes
addRequiredTypes(ta, typeset, True)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 243, in addRequiredTypes
raise NotImplementedError, repr(cls)
NotImplementedError: <Type: ?>
This one may be harder to fix...
Bill
Traceback (most recent call last):
File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py", line 98, in <module>
cpp.jcc(sys.argv)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 551, in jcc
addRequiredTypes(cls, typeset, generics)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 233, in addRequiredTypes
addRequiredTypes(cls, typeset, True)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 238, in addRequiredTypes
addRequiredTypes(ta, typeset, True)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 238, in addRequiredTypes
addRequiredTypes(ta, typeset, True)
File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 243, in addRequiredTypes
raise NotImplementedError, repr(cls)
NotImplementedError: <Type: ?>
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-04, 02:51
Andi Vajda <[EMAIL PROTECTED]> wrote:
> Bill,
>
> Did that solve your problem ?
Hmmm, I'm still seeing it. And some other stuff:
build/_GoodStuff/__wrap03__.cpp: In function ‘PyObject* com::parc::goodstuff::relations::t_Something1SeqIterator_nextElement(com::parc::goodstuff::relations::t_Something1SeqIterator*, PyObject*)’:
build/_GoodStuff/__wrap03__.cpp:9122: error: ‘class com::parc::goodstuff::relations::t_Something1SeqIterator’ has no member named ‘parameters’
build/_GoodStuff/__wrap03__.cpp:9122: error: ‘class com::parc::goodstuff::relations::t_Something1SeqIterator’ has no member named ‘parameters’
build/_GoodStuff/__wrap03__.cpp: In function ‘PyObject* com::parc::goodstuff::family::t_Something2Iterator_nextElement(com::parc::goodstuff::family::t_Something2Iterator*, PyObject*)’:
build/_GoodStuff/__wrap03__.cpp:15376: error: ‘class com::parc::goodstuff::family::t_Something2Iterator’ has no member named ‘parameters’
build/_GoodStuff/__wrap03__.cpp:15376: error: ‘class com::parc::goodstuff::family::t_Something2Iterator’ has no member named ‘parameters’
build/_GoodStuff/__wrap03__.cpp: At global scope:
build/_GoodStuff/__wrap03__.cpp:27749: error: ‘t_JArray’ was not declared in this scope
build/_GoodStuff/__wrap03__.cpp:27749: error: parse error in template argument list
build/_GoodStuff/__wrap03__.cpp:27749: error: insufficient contextual information to determine type
build/_GoodStuff/__wrap03__.cpp:27749: warning: ‘>>’ operator will be treated as two right angle brackets in C++0x
build/_GoodStuff/__wrap03__.cpp:27749: warning: suggest parentheses around ‘>>’ expression
build/_GoodStuff/__wrap03__.cpp:27749: error: spurious ‘>>’, use ‘>’ to terminate a template argument list
build/_GoodStuff/__wrap03__.cpp:27749: error: expected primary-expression before ‘)’ token
build/_GoodStuff/__wrap03__.cpp:27749: error: too many initializers for ‘PyTypeObject’
build/_GoodStuff/__wrap03__.cpp:41430: error: ‘t_JArray’ was not declared in this scope
build/_GoodStuff/__wrap03__.cpp:41430: error: parse error in template argument list
build/_GoodStuff/__wrap03__.cpp:41430: error: insufficient contextual information to determine type
build/_GoodStuff/__wrap03__.cpp:41430: error: expected primary-expression before ‘)’ token
build/_GoodStuff/__wrap03__.cpp:41430: error: too many initializers for ‘PyTypeObject’
error: command 'gcc' failed with exit status 1
I think when I tried it this afternoon (I was running out the door and
kind of rushed) I just did a wrap, and not a --build.
Sorry about that.
Bill
>
> Andi..
>
> On Feb 28, 2011, at 20:05, Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> >
> > On Sun, 27 Feb 2011, Bill Janssen wrote:
> >
> >> Andi Vajda <[EMAIL PROTECTED]> wrote:
> >>
> >>> It may be simplest if you can send me the source file for this class
> >>> as well as a small jar file I can use to reproduce this ?
> >>
> >> Turns out to be simple to reproduce. Put the attached in a file called
> >> test.java, and run this sequence:
> >>
> >> % javac -classpath . test.java
> >> % jar cf test.jar *.class
> >> % python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
> >
> > This was a tougher one. It was triggered by a combination of things:
> > - no wrapper requested for java.io.File or --package java.io
> > - a subclass of a parameterized class or interface implementor of a
> > parameterized interface wasn't pulling in classes used as type
> > parameters (java.io.File here).
> >
> > A fix is checked into jcc trunk/branch_3x rev 1075642.
> > This also includes the earlier fix about using absolute class names.
> >
> > Andi..
> Bill,
>
> Did that solve your problem ?
Hmmm, I'm still seeing it. And some other stuff:
build/_GoodStuff/__wrap03__.cpp: In function ‘PyObject* com::parc::goodstuff::relations::t_Something1SeqIterator_nextElement(com::parc::goodstuff::relations::t_Something1SeqIterator*, PyObject*)’:
build/_GoodStuff/__wrap03__.cpp:9122: error: ‘class com::parc::goodstuff::relations::t_Something1SeqIterator’ has no member named ‘parameters’
build/_GoodStuff/__wrap03__.cpp:9122: error: ‘class com::parc::goodstuff::relations::t_Something1SeqIterator’ has no member named ‘parameters’
build/_GoodStuff/__wrap03__.cpp: In function ‘PyObject* com::parc::goodstuff::family::t_Something2Iterator_nextElement(com::parc::goodstuff::family::t_Something2Iterator*, PyObject*)’:
build/_GoodStuff/__wrap03__.cpp:15376: error: ‘class com::parc::goodstuff::family::t_Something2Iterator’ has no member named ‘parameters’
build/_GoodStuff/__wrap03__.cpp:15376: error: ‘class com::parc::goodstuff::family::t_Something2Iterator’ has no member named ‘parameters’
build/_GoodStuff/__wrap03__.cpp: At global scope:
build/_GoodStuff/__wrap03__.cpp:27749: error: ‘t_JArray’ was not declared in this scope
build/_GoodStuff/__wrap03__.cpp:27749: error: parse error in template argument list
build/_GoodStuff/__wrap03__.cpp:27749: error: insufficient contextual information to determine type
build/_GoodStuff/__wrap03__.cpp:27749: warning: ‘>>’ operator will be treated as two right angle brackets in C++0x
build/_GoodStuff/__wrap03__.cpp:27749: warning: suggest parentheses around ‘>>’ expression
build/_GoodStuff/__wrap03__.cpp:27749: error: spurious ‘>>’, use ‘>’ to terminate a template argument list
build/_GoodStuff/__wrap03__.cpp:27749: error: expected primary-expression before ‘)’ token
build/_GoodStuff/__wrap03__.cpp:27749: error: too many initializers for ‘PyTypeObject’
build/_GoodStuff/__wrap03__.cpp:41430: error: ‘t_JArray’ was not declared in this scope
build/_GoodStuff/__wrap03__.cpp:41430: error: parse error in template argument list
build/_GoodStuff/__wrap03__.cpp:41430: error: insufficient contextual information to determine type
build/_GoodStuff/__wrap03__.cpp:41430: error: expected primary-expression before ‘)’ token
build/_GoodStuff/__wrap03__.cpp:41430: error: too many initializers for ‘PyTypeObject’
error: command 'gcc' failed with exit status 1
I think when I tried it this afternoon (I was running out the door and
kind of rushed) I just did a wrap, and not a --build.
Sorry about that.
Bill
>
> Andi..
>
> On Feb 28, 2011, at 20:05, Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> >
> > On Sun, 27 Feb 2011, Bill Janssen wrote:
> >
> >> Andi Vajda <[EMAIL PROTECTED]> wrote:
> >>
> >>> It may be simplest if you can send me the source file for this class
> >>> as well as a small jar file I can use to reproduce this ?
> >>
> >> Turns out to be simple to reproduce. Put the attached in a file called
> >> test.java, and run this sequence:
> >>
> >> % javac -classpath . test.java
> >> % jar cf test.jar *.class
> >> % python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
> >
> > This was a tougher one. It was triggered by a combination of things:
> > - no wrapper requested for java.io.File or --package java.io
> > - a subclass of a parameterized class or interface implementor of a
> > parameterized interface wasn't pulling in classes used as type
> > parameters (java.io.File here).
> >
> > A fix is checked into jcc trunk/branch_3x rev 1075642.
> > This also includes the earlier fix about using absolute class names.
> >
> > Andi..
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-04, 03:42
On Thu, 3 Mar 2011, Bill Janssen wrote:
> Did a fresh checkout and here's the next issue.
>
> This one may be harder to fix...
No, it's just another one of these Type classes, WildcardType.
I should have a fix shortly. Sorry for the mess.
Andi..
>
> Bill
>
> Traceback (most recent call last):
> File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
> "__main__", fname, loader, pkg_name)
> File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
> exec code in run_globals
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py", line 98, in <module>
> cpp.jcc(sys.argv)
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 551, in jcc
> addRequiredTypes(cls, typeset, generics)
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 233, in addRequiredTypes
> addRequiredTypes(cls, typeset, True)
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 238, in addRequiredTypes
> addRequiredTypes(ta, typeset, True)
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 238, in addRequiredTypes
> addRequiredTypes(ta, typeset, True)
> File "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py", line 243, in addRequiredTypes
> raise NotImplementedError, repr(cls)
> NotImplementedError: <Type: ?>
>
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-04, 03:42
On Thu, 3 Mar 2011, Bill Janssen wrote:
> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>> Bill,
>>
>> Did that solve your problem ?
>
> Hmmm, I'm still seeing it. And some other stuff:
Could you please send me the Java code that triggers this ?
Andi..
> build/_GoodStuff/__wrap03__.cpp: In function ?PyObject* com::parc::goodstuff::relations::t_Something1SeqIterator_nextElement(com::parc::goodstuff::relations::t_Something1SeqIterator*, PyObject*)?:
> build/_GoodStuff/__wrap03__.cpp:9122: error: ?class com::parc::goodstuff::relations::t_Something1SeqIterator? has no member named ?parameters?
> build/_GoodStuff/__wrap03__.cpp:9122: error: ?class com::parc::goodstuff::relations::t_Something1SeqIterator? has no member named ?parameters?
> build/_GoodStuff/__wrap03__.cpp: In function ?PyObject* com::parc::goodstuff::family::t_Something2Iterator_nextElement(com::parc::goodstuff::family::t_Something2Iterator*, PyObject*)?:
> build/_GoodStuff/__wrap03__.cpp:15376: error: ?class com::parc::goodstuff::family::t_Something2Iterator? has no member named ?parameters?
> build/_GoodStuff/__wrap03__.cpp:15376: error: ?class com::parc::goodstuff::family::t_Something2Iterator? has no member named ?parameters?
> build/_GoodStuff/__wrap03__.cpp: At global scope:
> build/_GoodStuff/__wrap03__.cpp:27749: error: ?t_JArray? was not declared in this scope
> build/_GoodStuff/__wrap03__.cpp:27749: error: parse error in template argument list
> build/_GoodStuff/__wrap03__.cpp:27749: error: insufficient contextual information to determine type
> build/_GoodStuff/__wrap03__.cpp:27749: warning: ?>>? operator will be treated as two right angle brackets in C++0x
> build/_GoodStuff/__wrap03__.cpp:27749: warning: suggest parentheses around ?>>? expression
> build/_GoodStuff/__wrap03__.cpp:27749: error: spurious ?>>?, use ?>? to terminate a template argument list
> build/_GoodStuff/__wrap03__.cpp:27749: error: expected primary-expression before ?)? token
> build/_GoodStuff/__wrap03__.cpp:27749: error: too many initializers for ?PyTypeObject?
> build/_GoodStuff/__wrap03__.cpp:41430: error: ?t_JArray? was not declared in this scope
> build/_GoodStuff/__wrap03__.cpp:41430: error: parse error in template argument list
> build/_GoodStuff/__wrap03__.cpp:41430: error: insufficient contextual information to determine type
> build/_GoodStuff/__wrap03__.cpp:41430: error: expected primary-expression before ?)? token
> build/_GoodStuff/__wrap03__.cpp:41430: error: too many initializers for ?PyTypeObject?
> error: command 'gcc' failed with exit status 1
>
> I think when I tried it this afternoon (I was running out the door and
> kind of rushed) I just did a wrap, and not a --build.
>
> Sorry about that.
>
> Bill
>
>
>>
>> Andi..
>>
>> On Feb 28, 2011, at 20:05, Andi Vajda <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> On Sun, 27 Feb 2011, Bill Janssen wrote:
>>>
>>>> Andi Vajda <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> It may be simplest if you can send me the source file for this class
>>>>> as well as a small jar file I can use to reproduce this ?
>>>>
>>>> Turns out to be simple to reproduce. Put the attached in a file called
>>>> test.java, and run this sequence:
>>>>
>>>> % javac -classpath . test.java
>>>> % jar cf test.jar *.class
>>>> % python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
>>>
>>> This was a tougher one. It was triggered by a combination of things:
>>> - no wrapper requested for java.io.File or --package java.io
>>> - a subclass of a parameterized class or interface implementor of a
>>> parameterized interface wasn't pulling in classes used as type
>>> parameters (java.io.File here).
>>>
>>> A fix is checked into jcc trunk/branch_3x rev 1075642.
>>> This also includes the earlier fix about using absolute class names.
>>>
>>> Andi..
>
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-04, 03:49
On Thu, 3 Mar 2011, Andi Vajda wrote:
> On Thu, 3 Mar 2011, Bill Janssen wrote:
>
>> Did a fresh checkout and here's the next issue.
>>
>> This one may be harder to fix...
>
> No, it's just another one of these Type classes, WildcardType.
> I should have a fix shortly. Sorry for the mess.
Fixed in rev trunk/branch_3x 1077171.
Andi..
>
> Andi..
>
>>
>> Bill
>>
>> Traceback (most recent call last):
>> File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
>> "__main__", fname, loader, pkg_name)
>> File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
>> exec code in run_globals
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py",
>> line 98, in <module>
>> cpp.jcc(sys.argv)
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
>> line 551, in jcc
>> addRequiredTypes(cls, typeset, generics)
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
>> line 233, in addRequiredTypes
>> addRequiredTypes(cls, typeset, True)
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
>> line 238, in addRequiredTypes
>> addRequiredTypes(ta, typeset, True)
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
>> line 238, in addRequiredTypes
>> addRequiredTypes(ta, typeset, True)
>> File
>> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
>> line 243, in addRequiredTypes
>> raise NotImplementedError, repr(cls)
>> NotImplementedError: <Type: ?>
>>
>
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-04, 05:43
Andi Vajda <[EMAIL PROTECTED]> wrote:
> Could you please send me the Java code that triggers this ?
Sorry, I can't. It's too tangled with proprietary code (both ours and
others').
But I'll see if I can mock up an example.
Bill
>
> Andi..
>
> > build/_GoodStuff/__wrap03__.cpp: In function ?PyObject* com::parc::goodstuff::relations::t_Something1SeqIterator_nextElement(com::parc::goodstuff::relations::t_Something1SeqIterator*, PyObject*)?:
> > build/_GoodStuff/__wrap03__.cpp:9122: error: ?class com::parc::goodstuff::relations::t_Something1SeqIterator? has no member named ?parameters?
> > build/_GoodStuff/__wrap03__.cpp:9122: error: ?class com::parc::goodstuff::relations::t_Something1SeqIterator? has no member named ?parameters?
> > build/_GoodStuff/__wrap03__.cpp: In function ?PyObject* com::parc::goodstuff::family::t_Something2Iterator_nextElement(com::parc::goodstuff::family::t_Something2Iterator*, PyObject*)?:
> > build/_GoodStuff/__wrap03__.cpp:15376: error: ?class com::parc::goodstuff::family::t_Something2Iterator? has no member named ?parameters?
> > build/_GoodStuff/__wrap03__.cpp:15376: error: ?class com::parc::goodstuff::family::t_Something2Iterator? has no member named ?parameters?
> > build/_GoodStuff/__wrap03__.cpp: At global scope:
> > build/_GoodStuff/__wrap03__.cpp:27749: error: ?t_JArray? was not declared in this scope
> > build/_GoodStuff/__wrap03__.cpp:27749: error: parse error in template argument list
> > build/_GoodStuff/__wrap03__.cpp:27749: error: insufficient contextual information to determine type
> > build/_GoodStuff/__wrap03__.cpp:27749: warning: ?>>? operator will be treated as two right angle brackets in C++0x
> > build/_GoodStuff/__wrap03__.cpp:27749: warning: suggest parentheses around ?>>? expression
> > build/_GoodStuff/__wrap03__.cpp:27749: error: spurious ?>>?, use ?>? to terminate a template argument list
> > build/_GoodStuff/__wrap03__.cpp:27749: error: expected primary-expression before ?)? token
> > build/_GoodStuff/__wrap03__.cpp:27749: error: too many initializers for ?PyTypeObject?
> > build/_GoodStuff/__wrap03__.cpp:41430: error: ?t_JArray? was not declared in this scope
> > build/_GoodStuff/__wrap03__.cpp:41430: error: parse error in template argument list
> > build/_GoodStuff/__wrap03__.cpp:41430: error: insufficient contextual information to determine type
> > build/_GoodStuff/__wrap03__.cpp:41430: error: expected primary-expression before ?)? token
> > build/_GoodStuff/__wrap03__.cpp:41430: error: too many initializers for ?PyTypeObject?
> > error: command 'gcc' failed with exit status 1
> >
> > I think when I tried it this afternoon (I was running out the door and
> > kind of rushed) I just did a wrap, and not a --build.
> >
> > Sorry about that.
> >
> > Bill
> >
> >
> >>
> >> Andi..
> >>
> >> On Feb 28, 2011, at 20:05, Andi Vajda <[EMAIL PROTECTED]> wrote:
> >>
> >>>
> >>> On Sun, 27 Feb 2011, Bill Janssen wrote:
> >>>
> >>>> Andi Vajda <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> It may be simplest if you can send me the source file for this class
> >>>>> as well as a small jar file I can use to reproduce this ?
> >>>>
> >>>> Turns out to be simple to reproduce. Put the attached in a file called
> >>>> test.java, and run this sequence:
> >>>>
> >>>> % javac -classpath . test.java
> >>>> % jar cf test.jar *.class
> >>>> % python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
> >>>
> >>> This was a tougher one. It was triggered by a combination of things:
> >>> - no wrapper requested for java.io.File or --package java.io
> >>> - a subclass of a parameterized class or interface implementor of a
> >>> parameterized interface wasn't pulling in classes used as type
> >>> parameters (java.io.File here).
> >>>
> >>> A fix is checked into jcc trunk/branch_3x rev 1075642.
> >>> This also includes the earlier fix about using absolute class names.
> >>>
> >>> Andi..
> >
> Could you please send me the Java code that triggers this ?
Sorry, I can't. It's too tangled with proprietary code (both ours and
others').
But I'll see if I can mock up an example.
Bill
>
> Andi..
>
> > build/_GoodStuff/__wrap03__.cpp: In function ?PyObject* com::parc::goodstuff::relations::t_Something1SeqIterator_nextElement(com::parc::goodstuff::relations::t_Something1SeqIterator*, PyObject*)?:
> > build/_GoodStuff/__wrap03__.cpp:9122: error: ?class com::parc::goodstuff::relations::t_Something1SeqIterator? has no member named ?parameters?
> > build/_GoodStuff/__wrap03__.cpp:9122: error: ?class com::parc::goodstuff::relations::t_Something1SeqIterator? has no member named ?parameters?
> > build/_GoodStuff/__wrap03__.cpp: In function ?PyObject* com::parc::goodstuff::family::t_Something2Iterator_nextElement(com::parc::goodstuff::family::t_Something2Iterator*, PyObject*)?:
> > build/_GoodStuff/__wrap03__.cpp:15376: error: ?class com::parc::goodstuff::family::t_Something2Iterator? has no member named ?parameters?
> > build/_GoodStuff/__wrap03__.cpp:15376: error: ?class com::parc::goodstuff::family::t_Something2Iterator? has no member named ?parameters?
> > build/_GoodStuff/__wrap03__.cpp: At global scope:
> > build/_GoodStuff/__wrap03__.cpp:27749: error: ?t_JArray? was not declared in this scope
> > build/_GoodStuff/__wrap03__.cpp:27749: error: parse error in template argument list
> > build/_GoodStuff/__wrap03__.cpp:27749: error: insufficient contextual information to determine type
> > build/_GoodStuff/__wrap03__.cpp:27749: warning: ?>>? operator will be treated as two right angle brackets in C++0x
> > build/_GoodStuff/__wrap03__.cpp:27749: warning: suggest parentheses around ?>>? expression
> > build/_GoodStuff/__wrap03__.cpp:27749: error: spurious ?>>?, use ?>? to terminate a template argument list
> > build/_GoodStuff/__wrap03__.cpp:27749: error: expected primary-expression before ?)? token
> > build/_GoodStuff/__wrap03__.cpp:27749: error: too many initializers for ?PyTypeObject?
> > build/_GoodStuff/__wrap03__.cpp:41430: error: ?t_JArray? was not declared in this scope
> > build/_GoodStuff/__wrap03__.cpp:41430: error: parse error in template argument list
> > build/_GoodStuff/__wrap03__.cpp:41430: error: insufficient contextual information to determine type
> > build/_GoodStuff/__wrap03__.cpp:41430: error: expected primary-expression before ?)? token
> > build/_GoodStuff/__wrap03__.cpp:41430: error: too many initializers for ?PyTypeObject?
> > error: command 'gcc' failed with exit status 1
> >
> > I think when I tried it this afternoon (I was running out the door and
> > kind of rushed) I just did a wrap, and not a --build.
> >
> > Sorry about that.
> >
> > Bill
> >
> >
> >>
> >> Andi..
> >>
> >> On Feb 28, 2011, at 20:05, Andi Vajda <[EMAIL PROTECTED]> wrote:
> >>
> >>>
> >>> On Sun, 27 Feb 2011, Bill Janssen wrote:
> >>>
> >>>> Andi Vajda <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> It may be simplest if you can send me the source file for this class
> >>>>> as well as a small jar file I can use to reproduce this ?
> >>>>
> >>>> Turns out to be simple to reproduce. Put the attached in a file called
> >>>> test.java, and run this sequence:
> >>>>
> >>>> % javac -classpath . test.java
> >>>> % jar cf test.jar *.class
> >>>> % python -m jcc.__main__ --python test --shared --jar /tmp/test.jar --build --vmarg -Djava.awt.headless=true
> >>>
> >>> This was a tougher one. It was triggered by a combination of things:
> >>> - no wrapper requested for java.io.File or --package java.io
> >>> - a subclass of a parameterized class or interface implementor of a
> >>> parameterized interface wasn't pulling in classes used as type
> >>> parameters (java.io.File here).
> >>>
> >>> A fix is checked into jcc trunk/branch_3x rev 1075642.
> >>> This also includes the earlier fix about using absolute class names.
> >>>
> >>> Andi..
> >
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-04, 05:44
Thanks.
Bill
Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> On Thu, 3 Mar 2011, Andi Vajda wrote:
>
> > On Thu, 3 Mar 2011, Bill Janssen wrote:
> >
> >> Did a fresh checkout and here's the next issue.
> >>
> >> This one may be harder to fix...
> >
> > No, it's just another one of these Type classes, WildcardType.
> > I should have a fix shortly. Sorry for the mess.
>
> Fixed in rev trunk/branch_3x 1077171.
>
> Andi..
>
> >
> > Andi..
> >
> >>
> >> Bill
> >>
> >> Traceback (most recent call last):
> >> File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
> >> "__main__", fname, loader, pkg_name)
> >> File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
> >> exec code in run_globals
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py",
> >> line 98, in <module>
> >> cpp.jcc(sys.argv)
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> >> line 551, in jcc
> >> addRequiredTypes(cls, typeset, generics)
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> >> line 233, in addRequiredTypes
> >> addRequiredTypes(cls, typeset, True)
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> >> line 238, in addRequiredTypes
> >> addRequiredTypes(ta, typeset, True)
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> >> line 238, in addRequiredTypes
> >> addRequiredTypes(ta, typeset, True)
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> >> line 243, in addRequiredTypes
> >> raise NotImplementedError, repr(cls)
> >> NotImplementedError: <Type: ?>
> >>
> >
Bill
Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> On Thu, 3 Mar 2011, Andi Vajda wrote:
>
> > On Thu, 3 Mar 2011, Bill Janssen wrote:
> >
> >> Did a fresh checkout and here's the next issue.
> >>
> >> This one may be harder to fix...
> >
> > No, it's just another one of these Type classes, WildcardType.
> > I should have a fix shortly. Sorry for the mess.
>
> Fixed in rev trunk/branch_3x 1077171.
>
> Andi..
>
> >
> > Andi..
> >
> >>
> >> Bill
> >>
> >> Traceback (most recent call last):
> >> File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
> >> "__main__", fname, loader, pkg_name)
> >> File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
> >> exec code in run_globals
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py",
> >> line 98, in <module>
> >> cpp.jcc(sys.argv)
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> >> line 551, in jcc
> >> addRequiredTypes(cls, typeset, generics)
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> >> line 233, in addRequiredTypes
> >> addRequiredTypes(cls, typeset, True)
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> >> line 238, in addRequiredTypes
> >> addRequiredTypes(ta, typeset, True)
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> >> line 238, in addRequiredTypes
> >> addRequiredTypes(ta, typeset, True)
> >> File
> >> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> >> line 243, in addRequiredTypes
> >> raise NotImplementedError, repr(cls)
> >> NotImplementedError: <Type: ?>
> >>
> >
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-04, 06:09
Here's one of the generated lines that's causing me grief.
DECLARE_TYPE(RankIterator, t_RankIterator, ::java::lang::Object, RankIterator, t_RankIterator_init_, PyObject_SelfIter, ((PyObject *(*)(t_RankIterator *)) get_next<t_RankIterator,t_JArray< jint >,JArray< jint >>), t_RankIterator__fields_, 0, 0);
It yields this:
build/_PPD/__wrap02__.cpp:27284: error: ‘t_JArray’ was not declared in this scope
build/_PPD/__wrap02__.cpp:27284: error: parse error in template argument list
build/_PPD/__wrap02__.cpp:27284: error: insufficient contextual information to determine type
build/_PPD/__wrap02__.cpp:27284: warning: ‘>>’ operator will be treated as two right angle brackets in C++0x
build/_PPD/__wrap02__.cpp:27284: warning: suggest parentheses around ‘>>’ expression
build/_PPD/__wrap02__.cpp:27284: error: spurious ‘>>’, use ‘>’ to terminate a template argument list
build/_PPD/__wrap02__.cpp:27284: error: expected primary-expression before ‘)’ token
build/_PPD/__wrap02__.cpp:27284: error: too many initializers for ‘PyTypeObject’
Where does t_JArray get defined? I can't find it.
Bill
DECLARE_TYPE(RankIterator, t_RankIterator, ::java::lang::Object, RankIterator, t_RankIterator_init_, PyObject_SelfIter, ((PyObject *(*)(t_RankIterator *)) get_next<t_RankIterator,t_JArray< jint >,JArray< jint >>), t_RankIterator__fields_, 0, 0);
It yields this:
build/_PPD/__wrap02__.cpp:27284: error: ‘t_JArray’ was not declared in this scope
build/_PPD/__wrap02__.cpp:27284: error: parse error in template argument list
build/_PPD/__wrap02__.cpp:27284: error: insufficient contextual information to determine type
build/_PPD/__wrap02__.cpp:27284: warning: ‘>>’ operator will be treated as two right angle brackets in C++0x
build/_PPD/__wrap02__.cpp:27284: warning: suggest parentheses around ‘>>’ expression
build/_PPD/__wrap02__.cpp:27284: error: spurious ‘>>’, use ‘>’ to terminate a template argument list
build/_PPD/__wrap02__.cpp:27284: error: expected primary-expression before ‘)’ token
build/_PPD/__wrap02__.cpp:27284: error: too many initializers for ‘PyTypeObject’
Where does t_JArray get defined? I can't find it.
Bill
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-04, 06:21
On Mar 3, 2011, at 22:09, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Here's one of the generated lines that's causing me grief.
>
> DECLARE_TYPE(RankIterator, t_RankIterator, ::java::lang::Object, RankIterator, t_RankIterator_init_, PyObject_SelfIter, ((PyObject *(*)(t_RankIterator *)) get_next<t_RankIterator,t_JArray< jint >,JArray< jint >>),
Ah yes, that's invalid c++. Nested generics need to insert a space between '>'. Otherwise, the c++ parser gets it as the bit shifting operator, believe it or not. Should be easy enough to fix in jcc.
Andi..
> t_RankIterator__fields_, 0, 0);
>
> It yields this:
>
> build/_PPD/__wrap02__.cpp:27284: error: ‘t_JArray’ was not declared in this scope
> build/_PPD/__wrap02__.cpp:27284: error: parse error in template argument list
> build/_PPD/__wrap02__.cpp:27284: error: insufficient contextual information to determine type
> build/_PPD/__wrap02__.cpp:27284: warning: ‘>>’ operator will be treated as two right angle brackets in C++0x
> build/_PPD/__wrap02__.cpp:27284: warning: suggest parentheses around ‘>>’ expression
> build/_PPD/__wrap02__.cpp:27284: error: spurious ‘>>’, use ‘>’ to terminate a template argument list
> build/_PPD/__wrap02__.cpp:27284: error: expected primary-expression before ‘)’ token
> build/_PPD/__wrap02__.cpp:27284: error: too many initializers for ‘PyTypeObject’
>
> Where does t_JArray get defined? I can't find it.
>
> Bill
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-04, 06:42
On Thu, 3 Mar 2011, Andi Vajda wrote:
>
> On Mar 3, 2011, at 22:09, Bill Janssen <[EMAIL PROTECTED]> wrote:
>
>> Here's one of the generated lines that's causing me grief.
>>
>> DECLARE_TYPE(RankIterator, t_RankIterator, ::java::lang::Object, RankIterator, t_RankIterator_init_, PyObject_SelfIter, ((PyObject *(*)(t_RankIterator *)) get_next<t_RankIterator,t_JArray< jint >,JArray< jint >>),
>
> Ah yes, that's invalid c++. Nested generics need to insert a space between '>'. Otherwise, the c++ parser gets it as the bit shifting operator, believe it or not. Should be easy enough to fix in jcc.
Fixed in trunk/branch_3x rev 1077828.
Andi..
>
> Andi..
>
>> t_RankIterator__fields_, 0, 0);
>>
>> It yields this:
>>
>> build/_PPD/__wrap02__.cpp:27284: error: ?t_JArray? was not declared in this scope
>> build/_PPD/__wrap02__.cpp:27284: error: parse error in template argument list
>> build/_PPD/__wrap02__.cpp:27284: error: insufficient contextual information to determine type
>> build/_PPD/__wrap02__.cpp:27284: warning: ?>>? operator will be treated as two right angle brackets in C++0x
>> build/_PPD/__wrap02__.cpp:27284: warning: suggest parentheses around ?>>? expression
>> build/_PPD/__wrap02__.cpp:27284: error: spurious ?>>?, use ?>? to terminate a template argument list
>> build/_PPD/__wrap02__.cpp:27284: error: expected primary-expression before ?)? token
>> build/_PPD/__wrap02__.cpp:27284: error: too many initializers for ?PyTypeObject?
>>
>> Where does t_JArray get defined? I can't find it.
>>
>> Bill
>
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-07, 19:18
Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> On Thu, 3 Mar 2011, Andi Vajda wrote:
>
> >
> > On Mar 3, 2011, at 22:09, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >
> >> Here's one of the generated lines that's causing me grief.
> >>
> >> DECLARE_TYPE(RankIterator, t_RankIterator, ::java::lang::Object, RankIterator, t_RankIterator_init_, PyObject_SelfIter, ((PyObject *(*)(t_RankIterator *)) get_next<t_RankIterator,t_JArray< jint >,JArray< jint >>),
> >
> > Ah yes, that's invalid c++. Nested generics need to insert a space between '>'. Otherwise, the c++ parser gets it as the bit shifting operator, believe it or not. Should be easy enough to fix in jcc.
>
> Fixed in trunk/branch_3x rev 1077828.
Yeah, but not for me. After installing the latest JCC, I get this:
build/_PPD/__wrap03__.cpp:15149: error: ‘t_JArray’ was not declared in this scope
build/_PPD/__wrap03__.cpp:15149: error: parse error in template argument list
build/_PPD/__wrap03__.cpp:15149: error: insufficient contextual information to determine type
build/_PPD/__wrap03__.cpp:15149: error: expected primary-expression before ‘>’ token
build/_PPD/__wrap03__.cpp:15149: error: expected primary-expression before ‘)’ token
build/_PPD/__wrap03__.cpp:15149: error: too many initializers for ‘PyTypeObject’
And the line it's complaining about is now:
DECLARE_TYPE(RankIterator, t_RankIterator, ::java::lang::Object, RankIterator, t_RankIterator_init_, PyObject_SelfIter, ((PyObject *(*)(t_RankIterator *)) get_next< t_RankIterator,t_JArray< jint >,JArray< jint > >), t_RankIterator__fields_, 0, 0);
> >> Where does t_JArray get defined? I can't find it.
Still can't find it.
Bill
>
> On Thu, 3 Mar 2011, Andi Vajda wrote:
>
> >
> > On Mar 3, 2011, at 22:09, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >
> >> Here's one of the generated lines that's causing me grief.
> >>
> >> DECLARE_TYPE(RankIterator, t_RankIterator, ::java::lang::Object, RankIterator, t_RankIterator_init_, PyObject_SelfIter, ((PyObject *(*)(t_RankIterator *)) get_next<t_RankIterator,t_JArray< jint >,JArray< jint >>),
> >
> > Ah yes, that's invalid c++. Nested generics need to insert a space between '>'. Otherwise, the c++ parser gets it as the bit shifting operator, believe it or not. Should be easy enough to fix in jcc.
>
> Fixed in trunk/branch_3x rev 1077828.
Yeah, but not for me. After installing the latest JCC, I get this:
build/_PPD/__wrap03__.cpp:15149: error: ‘t_JArray’ was not declared in this scope
build/_PPD/__wrap03__.cpp:15149: error: parse error in template argument list
build/_PPD/__wrap03__.cpp:15149: error: insufficient contextual information to determine type
build/_PPD/__wrap03__.cpp:15149: error: expected primary-expression before ‘>’ token
build/_PPD/__wrap03__.cpp:15149: error: expected primary-expression before ‘)’ token
build/_PPD/__wrap03__.cpp:15149: error: too many initializers for ‘PyTypeObject’
And the line it's complaining about is now:
DECLARE_TYPE(RankIterator, t_RankIterator, ::java::lang::Object, RankIterator, t_RankIterator_init_, PyObject_SelfIter, ((PyObject *(*)(t_RankIterator *)) get_next< t_RankIterator,t_JArray< jint >,JArray< jint > >), t_RankIterator__fields_, 0, 0);
> >> Where does t_JArray get defined? I can't find it.
Still can't find it.
Bill
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-07, 19:46
On Mon, 7 Mar 2011, Bill Janssen wrote:
> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>>
>> On Thu, 3 Mar 2011, Andi Vajda wrote:
>>
>>>
>>> On Mar 3, 2011, at 22:09, Bill Janssen <[EMAIL PROTECTED]> wrote:
>>>
>>>> Here's one of the generated lines that's causing me grief.
>>>>
>>>> DECLARE_TYPE(RankIterator, t_RankIterator, ::java::lang::Object, RankIterator, t_RankIterator_init_, PyObject_SelfIter, ((PyObject *(*)(t_RankIterator *)) get_next<t_RankIterator,t_JArray< jint >,JArray< jint >>),
>>>
>>> Ah yes, that's invalid c++. Nested generics need to insert a space between '>'. Otherwise, the c++ parser gets it as the bit shifting operator, believe it or not. Should be easy enough to fix in jcc.
>>
>> Fixed in trunk/branch_3x rev 1077828.
>
> Yeah, but not for me. After installing the latest JCC, I get this:
So you found not one bug but two. The first one (about >>) is fixed, as you
can see in the new error message.
> build/_PPD/__wrap03__.cpp:15149: error: ?t_JArray? was not declared in this scope
> build/_PPD/__wrap03__.cpp:15149: error: parse error in template argument list
> build/_PPD/__wrap03__.cpp:15149: error: insufficient contextual information to determine type
> build/_PPD/__wrap03__.cpp:15149: error: expected primary-expression before ?>? token
> build/_PPD/__wrap03__.cpp:15149: error: expected primary-expression before ?)? token
> build/_PPD/__wrap03__.cpp:15149: error: too many initializers for ?PyTypeObject?
>
> And the line it's complaining about is now:
>
> DECLARE_TYPE(RankIterator, t_RankIterator, ::java::lang::Object, RankIterator, t_RankIterator_init_, PyObject_SelfIter, ((PyObject *(*)(t_RankIterator *)) get_next< t_RankIterator,t_JArray< jint >,JArray< jint > >), t_RankIterator__fields_, 0, 0);
>
>>>> Where does t_JArray get defined? I can't find it.
I'm not sure there is one. If you can provide me with a piece of Java to
reproduce this, I can fix it faster.
Andi..
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-07, 21:08
Andi Vajda <[EMAIL PROTECTED]> wrote:
> >>>> Where does t_JArray get defined? I can't find it.
>
> I'm not sure there is one. If you can provide me with a piece of Java
> to reproduce this, I can fix it faster.
I've narrowed this down to three iterator classes which cause this
issue. Now I've got to see what's the common factor.
Bill
> >>>> Where does t_JArray get defined? I can't find it.
>
> I'm not sure there is one. If you can provide me with a piece of Java
> to reproduce this, I can fix it faster.
I've narrowed this down to three iterator classes which cause this
issue. Now I've got to see what's the common factor.
Bill
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-07, 22:07
On Mon, 7 Mar 2011, Bill Janssen wrote:
> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>>>>>> Where does t_JArray get defined? I can't find it.
>>
>> I'm not sure there is one. If you can provide me with a piece of Java
>> to reproduce this, I can fix it faster.
>
> I've narrowed this down to three iterator classes which cause this
> issue. Now I've got to see what's the common factor.
Probably an array being used as a type parameter ?
Andi..
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-08, 00:33
Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> On Mon, 7 Mar 2011, Bill Janssen wrote:
>
> > Andi Vajda <[EMAIL PROTECTED]> wrote:
> >
> >>>>>> Where does t_JArray get defined? I can't find it.
> >>
> >> I'm not sure there is one. If you can provide me with a piece of Java
> >> to reproduce this, I can fix it faster.
> >
> > I've narrowed this down to three iterator classes which cause this
> > issue. Now I've got to see what's the common factor.
>
> Probably an array being used as a type parameter ?
Like this?
public ArrayList<int[]> state;
Or
public class foo2 implements Iterator<int[]>{
Or
public int[] next() {
Bill
>
> On Mon, 7 Mar 2011, Bill Janssen wrote:
>
> > Andi Vajda <[EMAIL PROTECTED]> wrote:
> >
> >>>>>> Where does t_JArray get defined? I can't find it.
> >>
> >> I'm not sure there is one. If you can provide me with a piece of Java
> >> to reproduce this, I can fix it faster.
> >
> > I've narrowed this down to three iterator classes which cause this
> > issue. Now I've got to see what's the common factor.
>
> Probably an array being used as a type parameter ?
Like this?
public ArrayList<int[]> state;
Or
public class foo2 implements Iterator<int[]>{
Or
public int[] next() {
Bill
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-08, 00:36
On Mon, 7 Mar 2011, Bill Janssen wrote:
> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>>
>> On Mon, 7 Mar 2011, Bill Janssen wrote:
>>
>>> Andi Vajda <[EMAIL PROTECTED]> wrote:
>>>
>>>>>>>> Where does t_JArray get defined? I can't find it.
>>>>
>>>> I'm not sure there is one. If you can provide me with a piece of Java
>>>> to reproduce this, I can fix it faster.
>>>
>>> I've narrowed this down to three iterator classes which cause this
>>> issue. Now I've got to see what's the common factor.
>>
>> Probably an array being used as a type parameter ?
>
> Like this?
>
> public ArrayList<int[]> state;
>
> Or
>
> public class foo2 implements Iterator<int[]>{
>
> Or
>
> public int[] next() {
Yes.
Andi..
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-08, 00:40
On Mon, 7 Mar 2011, Bill Janssen wrote:
> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>>
>> On Mon, 7 Mar 2011, Bill Janssen wrote:
>>
>>> Andi Vajda <[EMAIL PROTECTED]> wrote:
>>>
>>>>>>>> Where does t_JArray get defined? I can't find it.
>>>>
>>>> I'm not sure there is one. If you can provide me with a piece of Java
>>>> to reproduce this, I can fix it faster.
>>>
>>> I've narrowed this down to three iterator classes which cause this
>>> issue. Now I've got to see what's the common factor.
>>
>> Probably an array being used as a type parameter ?
>
> Like this?
>
> public ArrayList<int[]> state;
>
> Or
>
> public class foo2 implements Iterator<int[]>{
>
> Or
>
> public int[] next() {
Although rigging up your original test.java class to use this doesn't seem
to trigger the bug for me.
Andi..
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-08, 02:30
Andi Vajda <[EMAIL PROTECTED]> wrote:
> >> Probably an array being used as a type parameter ?
> >
> > Like this?
> >
> > public ArrayList<int[]> state;
> >
> > Or
> >
> > public class foo2 implements Iterator<int[]>{
> >
> > Or
> >
> > public int[] next() {
>
> Although rigging up your original test.java class to use this doesn't
> seem to trigger the bug for me.
These were uses of arrays by the three iterator classes that were giving
me problems. I'll see what I can gen up.
Bill
> >> Probably an array being used as a type parameter ?
> >
> > Like this?
> >
> > public ArrayList<int[]> state;
> >
> > Or
> >
> > public class foo2 implements Iterator<int[]>{
> >
> > Or
> >
> > public int[] next() {
>
> Although rigging up your original test.java class to use this doesn't
> seem to trigger the bug for me.
These were uses of arrays by the three iterator classes that were giving
me problems. I'll see what I can gen up.
Bill
-
Re: issue with automatic iterable detection?Andi Vajda 2011-03-25, 17:46
On Mon, 7 Mar 2011, Bill Janssen wrote:
> Andi Vajda <[EMAIL PROTECTED]> wrote:
>
>>>> Probably an array being used as a type parameter ?
>>>
>>> Like this?
>>>
>>> public ArrayList<int[]> state;
>>>
>>> Or
>>>
>>> public class foo2 implements Iterator<int[]>{
>>>
>>> Or
>>>
>>> public int[] next() {
>>
>> Although rigging up your original test.java class to use this doesn't
>> seem to trigger the bug for me.
>
> These were uses of arrays by the three iterator classes that were giving
> me problems. I'll see what I can gen up.
Hi Bill,
Has this issue been resolved or is it just falling behind other things ?
Andi..
-
Re: issue with automatic iterable detection?Bill Janssen 2011-03-25, 18:37
Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> On Mon, 7 Mar 2011, Bill Janssen wrote:
>
> > Andi Vajda <[EMAIL PROTECTED]> wrote:
> >
> >>>> Probably an array being used as a type parameter ?
> >>>
> >>> Like this?
> >>>
> >>> public ArrayList<int[]> state;
> >>>
> >>> Or
> >>>
> >>> public class foo2 implements Iterator<int[]>{
> >>>
> >>> Or
> >>>
> >>> public int[] next() {
> >>
> >> Although rigging up your original test.java class to use this doesn't
> >> seem to trigger the bug for me.
> >
> > These were uses of arrays by the three iterator classes that were giving
> > me problems. I'll see what I can gen up.
>
> Hi Bill,
>
> Has this issue been resolved or is it just falling behind other things ?
Just falling behind... Too many other higher-priority items right now.
Bill
>
> On Mon, 7 Mar 2011, Bill Janssen wrote:
>
> > Andi Vajda <[EMAIL PROTECTED]> wrote:
> >
> >>>> Probably an array being used as a type parameter ?
> >>>
> >>> Like this?
> >>>
> >>> public ArrayList<int[]> state;
> >>>
> >>> Or
> >>>
> >>> public class foo2 implements Iterator<int[]>{
> >>>
> >>> Or
> >>>
> >>> public int[] next() {
> >>
> >> Although rigging up your original test.java class to use this doesn't
> >> seem to trigger the bug for me.
> >
> > These were uses of arrays by the three iterator classes that were giving
> > me problems. I'll see what I can gen up.
>
> Hi Bill,
>
> Has this issue been resolved or is it just falling behind other things ?
Just falling behind... Too many other higher-priority items right now.
Bill
-
Re: issue with automatic iterable detection?jason_ni 2011-08-20, 07:49
Hi,
I tried to compile openrdf Sesame api today, and encountered same problems
with Andi. First "parameters" issue. Then I found here by google. Then I
upgrade my jcc to 2.10. Then found the "t_JArray" problem...
The Java code is:
----------------------------------
public class GraphQueryResultImpl extends IterationWrapper<Statement,
QueryEvaluationException> implements
GraphQueryResult
{
/*-----------*
* Variables *
*-----------*/
private Map<String, String> namespaces;
/*--------------*
* Constructors *
*--------------*/
public GraphQueryResultImpl(Map<String, String> namespaces,
Iterable<? extends Statement> statements) {
this(namespaces, statements.iterator());
}
public GraphQueryResultImpl(Map<String, String> namespaces,
Iterator<? extends Statement> statementIter) {
this(namespaces, new CloseableIteratorIteration<Statement,
QueryEvaluationException>(statementIter));
}
public GraphQueryResultImpl(Map<String, String> namespaces,
CloseableIteration<? extends Statement, ? extends
QueryEvaluationException> statementIter)
{
super(statementIter);
this.namespaces = Collections.unmodifiableMap(namespaces);
}
/*---------*
* Methods *
*---------*/
public Map<String, String> getNamespaces() {
return namespaces;
}
}
-------------------------------------
Hope this problem can be solved earlier. Thanks a lot!
Jason.
--
View this message in context: http://pylucene-users-developers-list.2474766.n2.nabble.com/issue-with-automatic-iterable-detection-tp6068928p6705808.html
Sent from the PyLucene users & developers list mailing list archive at Nabble.com.
I tried to compile openrdf Sesame api today, and encountered same problems
with Andi. First "parameters" issue. Then I found here by google. Then I
upgrade my jcc to 2.10. Then found the "t_JArray" problem...
The Java code is:
----------------------------------
public class GraphQueryResultImpl extends IterationWrapper<Statement,
QueryEvaluationException> implements
GraphQueryResult
{
/*-----------*
* Variables *
*-----------*/
private Map<String, String> namespaces;
/*--------------*
* Constructors *
*--------------*/
public GraphQueryResultImpl(Map<String, String> namespaces,
Iterable<? extends Statement> statements) {
this(namespaces, statements.iterator());
}
public GraphQueryResultImpl(Map<String, String> namespaces,
Iterator<? extends Statement> statementIter) {
this(namespaces, new CloseableIteratorIteration<Statement,
QueryEvaluationException>(statementIter));
}
public GraphQueryResultImpl(Map<String, String> namespaces,
CloseableIteration<? extends Statement, ? extends
QueryEvaluationException> statementIter)
{
super(statementIter);
this.namespaces = Collections.unmodifiableMap(namespaces);
}
/*---------*
* Methods *
*---------*/
public Map<String, String> getNamespaces() {
return namespaces;
}
}
-------------------------------------
Hope this problem can be solved earlier. Thanks a lot!
Jason.
--
View this message in context: http://pylucene-users-developers-list.2474766.n2.nabble.com/issue-with-automatic-iterable-detection-tp6068928p6705808.html
Sent from the PyLucene users & developers list mailing list archive at Nabble.com.
-
Re: issue with automatic iterable detection?Andi Vajda 2011-08-20, 21:59
Hi Jason,
On Sat, 20 Aug 2011, jason_ni wrote:
> I tried to compile openrdf Sesame api today, and encountered same problems
> with Andi. First "parameters" issue. Then I found here by google. Then I
> upgrade my jcc to 2.10. Then found the "t_JArray" problem...
Could you please where I can download the source code for this library and
reproduce this bug. If the source is not available, please isolate the bug
into a class that can be javac-compiled by itself and attach it to your
message.
Without being able to reproduce the bug there isn't much I can do.
Thanks !
Andi..
> The Java code is:
> ----------------------------------
> public class GraphQueryResultImpl extends IterationWrapper<Statement,
> QueryEvaluationException> implements
> GraphQueryResult
> {
>
> /*-----------*
> * Variables *
> *-----------*/
>
> private Map<String, String> namespaces;
>
> /*--------------*
> * Constructors *
> *--------------*/
>
> public GraphQueryResultImpl(Map<String, String> namespaces,
> Iterable<? extends Statement> statements) {
> this(namespaces, statements.iterator());
> }
>
> public GraphQueryResultImpl(Map<String, String> namespaces,
> Iterator<? extends Statement> statementIter) {
> this(namespaces, new CloseableIteratorIteration<Statement,
> QueryEvaluationException>(statementIter));
> }
>
> public GraphQueryResultImpl(Map<String, String> namespaces,
> CloseableIteration<? extends Statement, ? extends
> QueryEvaluationException> statementIter)
> {
> super(statementIter);
> this.namespaces = Collections.unmodifiableMap(namespaces);
> }
>
> /*---------*
> * Methods *
> *---------*/
>
> public Map<String, String> getNamespaces() {
> return namespaces;
> }
> }
> -------------------------------------
> Hope this problem can be solved earlier. Thanks a lot!
>
> Jason.
>
> --
> View this message in context: http://pylucene-users-developers-list.2474766.n2.nabble.com/issue-with-automatic-iterable-detection-tp6068928p6705808.html
> Sent from the PyLucene users & developers list mailing list archive at Nabble.com.
>
-
Re: issue with automatic iterable detection?jason_ni 2011-08-24, 00:10
Hi Andi,
Please download my compiling package from:
http://pbmice.fudan.edu.cn/pysesame-0821-comp-err.tar.gz
Source code can be download from:
http://repo.aduna-software.org/svn/org.openrdf/sesame/tags/2.1.2/
I didn't compile the jar from source code, but I think the compiled Java
class should be from that source.
Thanks!
Jason.
--
View this message in context: http://pylucene-users-developers-list.2474766.n2.nabble.com/issue-with-automatic-iterable-detection-tp6068928p6718369.html
Sent from the PyLucene users & developers list mailing list archive at Nabble.com.
Please download my compiling package from:
http://pbmice.fudan.edu.cn/pysesame-0821-comp-err.tar.gz
Source code can be download from:
http://repo.aduna-software.org/svn/org.openrdf/sesame/tags/2.1.2/
I didn't compile the jar from source code, but I think the compiled Java
class should be from that source.
Thanks!
Jason.
--
View this message in context: http://pylucene-users-developers-list.2474766.n2.nabble.com/issue-with-automatic-iterable-detection-tp6068928p6718369.html
Sent from the PyLucene users & developers list mailing list archive at Nabble.com.
-
Re: issue with automatic iterable detection?Andi Vajda 2011-08-24, 00:44
On Tue, 23 Aug 2011, jason_ni wrote:
> Please download my compiling package from:
> http://pbmice.fudan.edu.cn/pysesame-0821-comp-err.tar.gz
> Source code can be download from:
> http://repo.aduna-software.org/svn/org.openrdf/sesame/tags/2.1.2/
> I didn't compile the jar from source code, but I think the compiled Java
> class should be from that source.
Thank you for the links.
Andi..
-
Re: issue with automatic iterable detection?Andi Vajda 2011-08-28, 23:25
Hi Jason,
On Tue, 23 Aug 2011, jason_ni wrote:
> Please download my compiling package from:
> http://pbmice.fudan.edu.cn/pysesame-0821-comp-err.tar.gz
> Source code can be download from:
> http://repo.aduna-software.org/svn/org.openrdf/sesame/tags/2.1.2/
> I didn't compile the jar from source code, but I think the compiled Java
> class should be from that source.
I was able to reproduce and fix this bug.
Code for returning arrays from iterators was missing.
It's checked into rev 1162608.
Thank you for the bug report !
Andi..
-
Re: issue with automatic iterable detection?Jason Ni 2011-08-29, 13:59
Awesome! Many thanks!
It can be compiled. I will do more test later.
Jason
2011/8/29 Andi Vajda <[EMAIL PROTECTED]>
>
> Hi Jason,
>
>
> On Tue, 23 Aug 2011, jason_ni wrote:
>
> Please download my compiling package from:
>> http://pbmice.fudan.edu.cn/**pysesame-0821-comp-err.tar.gz<http://pbmice.fudan.edu.cn/pysesame-0821-comp-err.tar.gz>
>> Source code can be download from:
>> http://repo.aduna-software.**org/svn/org.openrdf/sesame/**tags/2.1.2/<http://repo.aduna-software.org/svn/org.openrdf/sesame/tags/2.1.2/>
>> I didn't compile the jar from source code, but I think the compiled Java
>> class should be from that source.
>>
>
> I was able to reproduce and fix this bug.
> Code for returning arrays from iterators was missing.
>
> It's checked into rev 1162608.
>
> Thank you for the bug report !
>
> Andi..
>
It can be compiled. I will do more test later.
Jason
2011/8/29 Andi Vajda <[EMAIL PROTECTED]>
>
> Hi Jason,
>
>
> On Tue, 23 Aug 2011, jason_ni wrote:
>
> Please download my compiling package from:
>> http://pbmice.fudan.edu.cn/**pysesame-0821-comp-err.tar.gz<http://pbmice.fudan.edu.cn/pysesame-0821-comp-err.tar.gz>
>> Source code can be download from:
>> http://repo.aduna-software.**org/svn/org.openrdf/sesame/**tags/2.1.2/<http://repo.aduna-software.org/svn/org.openrdf/sesame/tags/2.1.2/>
>> I didn't compile the jar from source code, but I think the compiled Java
>> class should be from that source.
>>
>
> I was able to reproduce and fix this bug.
> Code for returning arrays from iterators was missing.
>
> It's checked into rev 1162608.
>
> Thank you for the bug report !
>
> Andi..
>
