[Tcl Java] Re: [Tcl Java] A Tcl or TclBlend problem?
Am I missing something? I do not see this behavior in the 8.2.3 Tcl shell:
% proc fern {} {
set x [java::new String foo]
after 1 "$x toString"
unset x
update
}
% fern
bgerror failed to handle background error.
Original error: invalid command name "java0x1"
Error in bgerror: invalid command name "bgerror"
% proc fern2 {} {
set x [java::new String foo]
after 1 [list eval $x toString]
unset x
update
}
% fern2
bgerror failed to handle background error.
Original error: invalid command name "java0x2"
Error in bgerror: invalid command name "bgerror"
Jiang Wu wrote:
This problem may be related to Dr Wes Munsil's problem on "invalid command
name". Here is the problem script:
set x [java::new String foo]
after 1000 "$x toString"
unset x
update
You will get an error "invalid command name". Comparing that to the script
below:
set x [java::new String foo]
after 1000 [list eval $x toString]
unset x
update
Your will not get an error. The problem seems to be that Tcl believes that
a string representation of an object can always be converted back into the
original object. This is not true in the case of the Java object. The
first script uses the string form of the Java object to reference the
object. But that does not increment the ref count of the real object. As a
result, the later 'unset' call removed the real Java object. Why can't you
not use "unset x"? Well if this script is inside a proc, then x might be a
local variable, which will be removed after the proc returns.
The same script rewritten using an explicit list does use the real Java
object rather than its string form. As a result, the 2nd script works.
I am encountering this problem right now in a different form. I am
constructing an asynchronous callback function inside Java using a TclList
object, {command_name java_obj_1 java_obj_2}. The list contains some Java
objects, which are the arguments to the callback function. However, when
the callback function is invoked, the function is getting the string
representation of the argument rather than the real Java objects. This is
not good because you can't easily find your Java object given a string
representation.
I wonder if similar problem happens in the C world. But a C object can
always use a pointer address as its string representation. Then, given the
string representation, a valid C object can be found.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] Re: [Tcl Java] A Tcl or TclBlend problem?
Yes, but if you read on you will see that I also tried your proposed
workaround, and it gave the same error.
Jiang Wu wrote:
Your log says:
% fern
bgerror failed to handle background error.
Original error: invalid command name "java0x1"
^^
Error in bgerror: invalid command name "bgerror"
Is that not the same error you encountered?
-- Jiang Wu
[EMAIL PROTECTED]
-Original Message-
From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 28, 2000 12:16 AM
To: Jiang Wu
Cc: [EMAIL PROTECTED]
Subject: [Tcl Java] Re: [Tcl Java] A Tcl or TclBlend problem?
Am I missing something? I do not see this behavior in the
8.2.3 Tcl shell:
% proc fern {} {
set x [java::new String foo]
after 1 "$x toString"
unset x
update
}
% fern
bgerror failed to handle background error.
Original error: invalid command name "java0x1"
Error in bgerror: invalid command name "bgerror"
% proc fern2 {} {
set x [java::new String foo]
after 1 [list eval $x toString]
unset x
update
}
% f
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] Re: [Tcl Java] Re: [Tcl Java] A Tcl or TclBlend problem?
-Original Message-
From: Dr Wes Munsil [mailto:[EMAIL PROTECTED]]
Yes, but if you read on you will see that I also tried your proposed
workaround, and it gave the same error.
But the script does work under Tcl 8.3.1. I need to point out that my 2nd
script is NOT a "workaround". It is not a workaround because you can't
convert all callback scripts into this list form; it is not the normal way
of writing Tcl; and you can't change other people's code this way. It is
there to demonstrate a more fundamental problem: "Java objects in Tcl
should be treated as global system resources like file handles (explicit
create/remove) rather than other normal Tcl objects (implicit
create/duplicate/remove)."
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
The eval command will convert its arguments to strings.
This has the effect of removing the Java object from
the reflect table right before you invoke the Java cmd.
This is my point. As soon as any Java objects are converted into their
string form. The Java object from the reflect table would be removed. It
is not just the "eval" command. It is the whole Tcl interpreter (maybe the
byte code compiler in particular). The interpreter seems to change objects
into string form in various places. The fact that [list eval $x toString]
works under Tcl 8.3.1, but not under Tcl 8.2.3 also demonstrate this.
I was doing something even simpler:
proc foo {arg} {
set x $arg
}
I call "foo" using an "arg" that was a TclObject with a ReflectObject. The
debugger shows that the execution of "set x $arg" happening inside the byte
code executor. The argument is retrieved from the Tcl's procedure stack,
which is just a string only representation of what I passed in.
I had to write my workaround using a string-object mapping scheme like the
ones used in ReflectObject, but without the reference counting.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] A Tcl or TclBlend problem?
This problem may be related to Dr Wes Munsil's problem on "invalid command
name". Here is the problem script:
set x [java::new String foo]
after 1000 "$x toString"
unset x
update
You will get an error "invalid command name". Comparing that to the script
below:
set x [java::new String foo]
after 1000 [list eval $x toString]
unset x
update
Your will not get an error. The problem seems to be that Tcl believes that
a string representation of an object can always be converted back into the
original object. This is not true in the case of the Java object. The
first script uses the string form of the Java object to reference the
object. But that does not increment the ref count of the real object. As a
result, the later 'unset' call removed the real Java object. Why can't you
not use "unset x"? Well if this script is inside a proc, then x might be a
local variable, which will be removed after the proc returns.
The same script rewritten using an explicit list does use the real Java
object rather than its string form. As a result, the 2nd script works.
I am encountering this problem right now in a different form. I am
constructing an asynchronous callback function inside Java using a TclList
object, {command_name java_obj_1 java_obj_2}. The list contains some Java
objects, which are the arguments to the callback function. However, when
the callback function is invoked, the function is getting the string
representation of the argument rather than the real Java objects. This is
not good because you can't easily find your Java object given a string
representation.
I wonder if similar problem happens in the C world. But a C object can
always use a pointer address as its string representation. Then, given the
string representation, a valid C object can be found.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] Re: [Tcl Java] A Tcl or TclBlend problem?
...
I am encountering this problem right now in a different form. I am
constructing an asynchronous callback function inside Java using a TclList
object, {command_name java_obj_1 java_obj_2}. The list contains some Java
objects, which are the arguments to the callback function. However, when
the callback function is invoked, the function is getting the string
representation of the argument rather than the real Java objects. This is
not good because you can't easily find your Java object given a string
representation.
You mentioned that doing an after with a list object solved the problem,
but here you are using a TclList so it should incr the ref counts of
the objects in the list. Seems like that should work, I guess I
do not understand why your method arguments would be getting converted
to strings instead of TclObjects. Is this something that Interp.eval()
is doing?
I wonder if similar problem happens in the C world. But a C object can
always use a pointer address as its string representation. Then, given the
string representation, a valid C object can be found.
The problem is the mixing of GC and a type that can not be converted to
a string. You can not convert a Java reference into a string because
the GC system does not see that as a valid reference. You could convert
a C pointer into a string and then back to a pointer but you would
need to manage that memory on your own. In fact, Tcl Blend does this
sort of thing behind the scenes, it stores a C pointer inside a Java
long. It then converts this back to a pointer that is uses to find
the actual object (yes it is scary and wrong, but JNI sucks so we
are stuck with it).
Also, that convert a pointer to a string and back again trick
would not work if you were using a GC for your C code.
Mo DeJong
Red Hat Inc
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
[Tcl Java] RE: [Tcl Java] A Tcl or TclBlend problem?
-Original Message-
From: Mo DeJong [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 23, 2000 3:15 PM
To: Jiang Wu
Cc: [EMAIL PROTECTED]
Subject: Re: [Tcl Java] A Tcl or TclBlend problem?
You mentioned that doing an after with a list object solved
the problem,
but here you are using a TclList so it should incr the ref counts of
the objects in the list. Seems like that should work, I guess I
do not understand why your method arguments would be getting converted
to strings instead of TclObjects. Is this something that Interp.eval()
is doing?
I have a Tcl script text file that looks something this:
proc my_proc {arg1 arg2 ...} {
...
variable x
set x $arg2
...
}
The script is loaded (sourced) into the interpreter upon program startup.
arg2 is supposed to contains a script to be invoked later in a fileevent
handler such as {command arg arg ...}. All this works fine if "arg2" is a
"normal" Tcl script.
Then I want to pass in a Java command with some Java object arguments to
"arg2" so that a Java method is invoked in the callback. So I call my_proc
from within Java using a TclList as the 2nd argument and wrap all my Java
objects inside TclObject's. When the interpreter executes "set x $arg2"
part of the Tcl script, it no longer has the original list. Inside a
debugger, I can see that the arg2 contains a string representation of the
TclList I passed in.
My conclusion is that the C version Tcl interpreter is very liberal about
interchanging the string presentation and real object representation. For
example, if you have a TclList, and you called "TclList.toString()" followed
by "eval(TclList)". The native Tcl code will use the string version of your
TclList rather than the real list object. I wonder how Jacl behaves in
similar situation.
-- Jiang Wu
[EMAIL PROTECTED]
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe:send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
