Tcl and Tcl::Tk w/ Tcl 7.5, 7.6 and Tk 4.1, 4.2 
Author Message
 Tcl and Tcl::Tk w/ Tcl 7.5, 7.6 and Tk 4.1, 4.2

Are the Tcl and Tcl::Tk modules being used by anyone and in particular,
still being maintained?

Note: These are not the same as the Perl-Tk extension.

I've started using the beta-1 versions in a project and have noticed
that the Tcl moodule at least has not been updated in a long while. It
doesn't seem to compile cleanly against recent versions of Tcl and it
still has a lot of problems.

I've made some changes to get the modules to work against Tk 4.1 and am
working on 7.6/4.2. I've also made some changes to get Tcl::Tk to deal
with multiple Tk interpreters. At the moment I'm trying to stop a
coredump that occurs when you try to trap a Perl error and return a Tcl
error from a Perl function. I still don't know why it happens, but I've
found a workaround that requires significant changes in the way errors
are handled.

There are also some other problems:

1) $interp->AppendResult doesn't work.
2) $interp->EvalFileHandle doesn't work.
3) The syntax for the Tk command interface needs to be reworked to
better deal with multiple Tk interps.
4) Can't use "package require Tk" inside a non-Tk subinterpreter of a Tk
interpreter--- symbol resolution difficulties.
5) Should add an XSUB to TclCommandComplete.
6) support for manipulating safe Tcl interpreters

and some things that would be nice

1) some basic Tcl list processing routines that don't require a handle
to an interpreter.

2) some support for embedding (and manipulating) Perl code inside a Tcl
script.

I am very interested in using these modules extensively and am willing
to spend effort to improve them but cannot justify maintaining or
finishing them myself to my boss. Are there enough intersted people to
really make this a usable interface? Are you, Malcomm, still interested
in the project? Where is it going?



Sun, 06 Jun 1999 03:00:00 GMT  
 Tcl and Tcl::Tk w/ Tcl 7.5, 7.6 and Tk 4.1, 4.2

Quote:
> coredump that occurs when you try to trap a Perl error and return a Tcl
> error from a Perl function. I still don't know why it happens, but I've
> found a workaround that requires significant changes in the way errors
> are handled.

Actually, I've narrowed down the conditions under which this occurs and
have come up with a fix that doesn't change the error handling much at
all. In fact, I think it simplifies it immensely.

This is the patch for Tcl.xs. Instead of requiring the perl sub to catch
errors using eval and then stuff the error into $interp->result and
return undef, you can now just croak out of the
Perl routine and have this automatically set $interp->result and return
TCL_ERROR.

_________________________________________________________________________

59c59
<     count = perl_call_sv(*av_fetch(av, 0, FALSE), G_SCALAR|G_EVAL);
---

Quote:
>     count = perl_call_sv(*av_fetch(av, 0, FALSE), G_SCALAR);

70,72c70,74
<     else

<             TCL_VOLATILE);
---
Quote:
>     /*
>      * If the routine returned undef, it indicates that it has done the
>      * SetResult itself and that we should return TCL_ERROR
>      */

____________________________________________________________________________

This is a Perl script which demonstrates the core dump, or, at least, on
Redhat Linux 4.0, Kernel 2.0.18 with Perl 5.003


This is perl, version 5.003 with EMBED
        built under linux at Aug 19 1996 12:22:38
        + suidperl security patch

________________________________________________________________________________

#!/usr/bin/perl

use Tcl;
use Carp;
#use diagnostics;

sub testCommand
{

        eval {croak "Hi\n"};

        return undef;

Quote:
} # testCommand

$interp = new Tcl;
$interp->CreateCommand("testCommand", \&testCommand, undef, undef);
$interp->Eval("testCommand");

___________________________________________________________________________________

This seems to act suspiciously like the bug described in the perlcall
manpage that was supposed to go away in 5.002. From the man:      

        2.   In Perl 5.000 and 5.001 there is a problem with using
            perl_call_* if the Perl sub you are calling attempts
            to trap a die.

            The symptom of this problem is that the called Perl
            sub will continue to completion, but whenever it
            attempts to pass control back to the XSUB, the
            program will immediately terminate.

The symptoms being described in the rest of that section seem to exactly
match whats going on here. In any case, even if this isn't a ::Tcl bug
per se, I think the patch is still
an improvement to the current error handling code.

This is a modified script that shows the effect of the patch- notice
that $interp->result doesn't need to be set and it doesn't dump core!

____________________________________________________________________________________
#!/usr/bin/perl

use Tcl;
use Carp;
#use diagnostics;

sub testCommand
{

        croak "Hi\n";

Quote:
} # testCommand

$interp = new Tcl;
$interp->CreateCommand("testCommand", \&testCommand, undef, undef);
eval {$interp->Eval("testCommand")};


_______________________________________________________________________________________

Questions? Comments? Criticisms? Flames?



Mon, 07 Jun 1999 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Tcl::Tk and Tcl modules are available to provide Tk GUI to perl

2. Tcl/2K : The 7th USENIX Tcl/Tk Conference Call for Papers

3. ANNOUNCE: Tcl and Tcl::Tk extensions to Perl5

4. Tcl/2K : The 7th USENIX Tcl/Tk Conference Call for Papers

5. Tcl/2k : The 7th USENIX Tcl/Tk Conference Call for Papers

6. Tcl/2k : The 7th USENIX Tcl/Tk Conference Call for Papers

7. Improving Tcl/Tk program with Perl/Tk?

8. opinions on tcl/tk vs perl/tk

9. perl/tk vs.tcl/tk

10. Perl/Tk vs. Tcl/Tk

11. starting Tcl/Tk from perl/Tk

12. tcl/tk->perl/tk translator

 

 
Powered by phpBB® Forum Software