Re: [tcljava-user] TclBlend issue with uplevel in proc
Brought to you by:
mdejong
From: Dan D. <dda...@ya...> - 2011-05-26 19:58:42
|
Ahh, thanks for the quick reply. Unfortunately that wouldn't work for what I am really trying to do. I have a proc with a while loop reading a socket, to read in tcl commands. I'd prefer to have those commands executed at the global/top level, but I have found that I have the issue even just using eval. Here's the new condensed look at it. proc reading { sock } while { 1 } { if {[gets $sock buff] == -1} { puts "Client connection has been broken. Exiting." exit } # execute the command if {[catch { set ret [uplevel #0 $buff] } errmsg]} { puts $sock "ERROR:[lindex [split $errmsg "\n"] 0]" } else { puts "Executed: $buff" set retr [regsub -all "\n" $ret " "] puts $sock "SUCCESS:$retr" } } } Maybe I have a slightly different problem than my original email. If I send "set x [java::new String]" over the socket, unlike my previous example the [java::new String] isn't executed until I am entering the uplevel command, so it should be quickly set to the global x variable. But, if I send "set x [java::new String];set bogus 0", the x does hold a valid Java object reference. As long as the java operation isn't the last command to execute, it seems to work ok. The issue seems to be that the InternalRep isn't accepting the x variable inside the uplevel command as valid, unless another command is also executed in the uplevel. By adding "set bogus 0", it forces the uplevel to actually return $bogus instead of the $x. I wonder if this is a factor. If I just add ";set bogus 0" to all the received commands, things actually work, but I am returning 0 back on all successful executions, instead of the actual value I may be interested in. if {[catch { set ret [uplevel #0 "$buff;set bogus 0"] } errmsg]} { BTW, this happens the same even if I just use "eval" instead of "uplevel". Dan ________________________________ From: Mo DeJong <mo...@mo...> To: Dan Diolosa <dda...@ya...>; A list for users of tcljava <tcl...@li...> Sent: Thursday, May 26, 2011 2:21 PM Subject: Re: [tcljava-user] TclBlend issue with uplevel in proc The most likely cause of the problem is that you are expecting "x" to get set at the global scope, but by the time the set command is executed at the global scope, the internal rep is losing the Java representation. The most simple way to work around this would be to set a specific variable to the Java object, and then in the uplevel you reference that variable instead of passing the value to uplevel. Something like this: set ::GObj [java::new String] execute {set x $GObj} Mo On May 26, 2011, at 11:08 AM, Dan Diolosa wrote: Can anyone explain why TclBlend is not holding on to the Java object when I use uplevel in a proc? And what I can do to work around it. > >package require java > >proc execute { args } { > > #puts "Executing: $args" <-- COMMENTED OR NOT COMMENTED > > # execute the command > if {[catch { set ret [uplevel #0 $args] } errmsg]} { > return "ERROR:[lindex [split $errmsg "\n"] 0]" > } else { > puts "Executed: $args" > return "SUCCESS:$ret" > } >} > >With the puts executing line commented out in works: > >% execute set x [java::new String] >SUCCESS:java0x2 >% puts $x >java0x2 >% java::info class $x >java.lang.String >% > >With the puts executing line enabled: >% execute set x [java::new String] >Executing: set x java0x4 >Executed: set x java0x4 >SUCCESS:java0x4 >% puts $x >java0x4 >% java::info class $x >unknown java object "java0x4" >% > >Is this because the [java::new String] actually executes before entering the execute function and if it is not immediately set to a variable in the next command, it will be released? > >My real script does something a little more complicated, reading the command(s) to be executed via a socket. This was the simplest example that demonstrates the problem. > > >------------------------------------------------------------------------------ >vRanger cuts backup time in half-while increasing security. >With the market-leading solution for virtual backup and recovery, >you get blazing-fast, flexible, and affordable data protection. >Download your free trial now. >http://p.sf.net/sfu/quest-d2dcopy1_______________________________________________ >tcljava-user mailing list >tcl...@li... >https://lists.sourceforge.net/lists/listinfo/tcljava-user > |