tcltk-perl — Perl Tcl::Tk bridge module discussion

RE: [tcltk-perl] Makefile.PL cleanup [PATCH]

[Jeff H. <je...@Ac...>]

Gisle Aas wrote:
> "Konovalov, Vadim" <vko...@sp...> writes:
> 
> > BTW once CVS will be working on "tcltk" project of SF site, you will 
> > have write access and apply reasonable changes by your own?
> 
> Thanks.  I'm known as 'gisle' at sourceforge if you want to 
> add me as a maintainer.  Please tell me if you think patches 
> are inappropriate for the list until then.  At least they 
> create some traffic :-)

I've added you to 'tcltk', I will announce on this list when we
get the CVS moved.

> I think discussing patches on the list is the best way to 
> reach consensus on the approach to take.  Trivial stuff which 
> nobody is likely to disagree with (like my Tcl::Ev patch) is 
> best checked in directly without telling the list.

Agreed.

Jeff

RE: [tcltk-perl] What version of perl is required?

[Jeff H. <je...@Ac...>]

> Related question is what versions of 'tcl' is the Tcl.pm 
> supposed to be compatible with?

I'm ignoring anything below 8.4, but it's theoretically
compatible with Tcl 8.1+ still (I think).

Jeff

RE: [tcltk-perl] Drop listify [PATCH]

[Jeff H. <je...@Ac...>]

> "Konovalov, Vadim" <vko...@sp...> writes:
> > To be honest, I did not tried that Jeff's subroutine yet, but why do 
> > you think it should not be included?
> 
> Because it is dead code which i not needed.  Also the 'it is 
> also not "comprehensive"' make me think it is actually buggy.

That is correct, it is buggy (given certain input, it will not
produce a 100% correct list), and it isn't used anywhere at the
moment.  The xs changes I made alleviate the need - for now.

This touches on stuff that I think requires rethinking in the
whole Tcl module - array/list handling.

The SvFromTclObj and TclObjFromSv procedures that I added allow
for the efficient transformation of data at the object level
between Perl and Tcl.  An SvIV becomes a Tcl int object and vice
versa.  What is not completely round-tripped are Tcl lists, but
an AV will become a pure Tcl list.

You can see the part in SvFromTclObj where I try to create an
AV back from a Tcl list.  The problem with this is that we then
return an array reference, and I think it's complicated by the
code in Tcl.xs:prepare_Tcl_result that handles G_SCALAR and
G_ARRAY differently, in addition to the code in Tcl.pm:call()
that does at the end:

    return @res if wantarray;
    return $res[0];

Let's make some concrete examples.  Here is a code block:

use Tcl;
my $interp = Tcl->new;

my $lres = $interp->Eval("set var [list a b c]");    #1
my $sres = $interp->Eval("set var {a b c}");         #2
my (@lares) = $interp->Eval("set var [list a b c]"); #3
my (@sares) = $interp->Eval("set var {a b c}");      #4
print STDOUT "list:    ", $lres, "\n";
print STDOUT "string:  ", $sres, "\n";
print STDOUT "litems:  ", $_, "\n" for (@lares);
print STDOUT "sitems:  ", $_, "\n" for (@sares);

This will currently work "as expected" whether we get a true
(pure) list back from Tcl, or a string that can be broken into
a list.  #1 returns a Tcl_Obj of tclListType, whereas #2 returns
just a string (NULL object type).  For a small list, the time
difference is negligible, but for 1000 items lists, we should
really be treating it right.  The results with current code are:

list:    a b c
string:  a b c
litems:  a
litems:  b
litems:  c
sitems:  a
sitems:  b
sitems:  c

If you flip on the tclListType conversion (to AV ref) in
SvFromTclObj (there is a #if there), you instead get:

list:    ARRAY(0x191ea5c)
string:  a b c
litems:  a
litems:  b
litems:  c
sitems:  a
sitems:  b
sitems:  c

and I believe that this may lead to problems (it broke an app
that I was converting from pTk code) where I had this:

my $themes = $interp->Eval("style theme names");

OK, so I really should have this:

my (@themes) = $interp->Eval("style theme names");

but I think making the change leads to issues that force users
to think more about the return value.  The above code returns a
pure Tcl list - but the coder could have been lazy and created
a list-like string instead (as many people still do), and it
would all work.

Am I wrong in thinking that users should be forced to code
properly (whether they expect list/array or string/scalar) in
the first place?

I'm also unsure about both $interp->icall and $interp->call
behavior handling G_ARRAY and G_SCALAR differently.  See this
difference (this behaves the same whether you do the pure list
conversion or not):

my $res   = $interp->call('set', 'var', 'a b c');
my $ires  = $interp->icall('set', 'var', 'a b c');
my @ares  = $interp->call('set', 'var', 'a b c');
my @iares = $interp->icall('set', 'var', 'a b c');
print STDOUT "call:   ", $res, "\n";
print STDOUT "icall:  ", $ires, "\n";
print STDOUT "lcall:  ", $_, "\n" for (@ares);
print STDOUT "licall: ", $_, "\n" for (@iares);

outputs:

call:   a
icall:  a b c
lcall:  a
lcall:  b
lcall:  c
licall: a
licall: b
licall: c

but I guess that's an expectation for Perl users (for $res to
grab first element of a list), but when I change to pure list
form in calling convention and use tclListType conversion with:

my @list  = $interp->icall('list', 'a', 'b', 'c');
my $res   = $interp->call('set', 'var', [@list]);
my $ires  = $interp->icall('set', 'var', [@list]);
my @ares  = $interp->call('set', 'var', [@list]);
my @iares = $interp->icall('set', 'var', [@list]);
print STDOUT "call:   ", $res, "\n";
print STDOUT "icall:  ", $ires, "\n";
print STDOUT "lcall:  ", $_, "\n" for (@ares);
print STDOUT "licall: ", $_, "\n" for (@iares);

I get:

call:   a
icall:  ARRAY(0x191e9ec)
lcall:  a
lcall:  b
lcall:  c
licall: a
licall: b
licall: c

again, basically same as above.  Is this something that won't
surprise Perl users?

Jeff

RE: [tcltk-perl] What version of perl is required?

[Jeff H. <je...@Ac...>]

> > If perl-5.6 is the baseline, then it is a good idea to put a:
> >
> >    require 5.006;
>
> At some moment I managed things to work with 5.005_03, and,
> to be honest, not very glad for 'Tcl' perl module to require 5.8.0.
>
> 5.6.1 compatibility could be approached however, but we must
> decide whether elder than 5.6.0 are supported.

FWIW, I think supporting only 5.6.0 up officially is the way
to go.  I have only been testing with 5.8, and I know that
there are unicode issues with 5.6 (which may be alleviated by
some of the C code changes I made), but 5.005 has no value in
maintaining things for anymore.

Jeff

Re: [tcltk-perl] ChangeLog

[Jeff H. <je...@Ac...>]

Gisle Aas wrote:
> How is the ChangeLog maintained?  Is it some script that adds to it or
> is it manually updated?

It is manually updated, but I use emacs, which has a lot of
"ChangeLog" knowledge built in.  ^x-4-a in a function will
go up the dir tree looking for a ChangeLog.  If none is found,
it creates a new one in the current directory.  It creates
the ChangeLog entry, auto-inserting a lot of the information
(for example, if you are in a perl sub or C function, it knows
they func name and adds that to the file part).

My ChangeLog habits are based on this and other conventions
used by the Tcl core team to manage change information over
time in CVS (p4 or bk would be better, but we are on CVS for
now).

Jeff

RE: [tcltk-perl] ChangeLog

[Konovalov, V. <vko...@sp...>]

> How is the ChangeLog maintained?  Is it some script that adds to it or
> is it manually updated?

Jeff will probably shed a light on how he maintains it.

I, personally, add changes to it manually, and, in case this approach is too
newbie-ish, I'll follow a wise advice on this.

Best regards,
Vadim.

[tcltk-perl] ChangeLog

[Gisle A. <gi...@Ac...>]

How is the ChangeLog maintained?  Is it some script that adds to it or
is it manually updated?

--Gisle

RE: [tcltk-perl] Drop listify [PATCH]

[Konovalov, V. <vko...@sp...>]

> > For sure we need an addition in test files to check 
> handling array refs.
> 
> It looks like the tests could need more work in other areas too.  I'll
> try to contribute some to it in the days ahead.

that would be nive, thanks!

RE: [tcltk-perl] What version of perl is required?

[Konovalov, V. <vko...@sp...>]

> Related question is what versions of 'tcl' is the Tcl.pm supposed to
> be compatible with?

Ohhhh.... Tricky question...

At first, when Malcolm Beattie, famous perl pumpking released module, only
old Tcl/Tk existed, and nowadays module  crashed when newer Tcl/Tk was used.
RTFS-ing proved a necessity to call Tcl_FindExecutable in this case, so I
added this, and both old and new versions were supported.

Nowadays Tcl/Tk moved to "Object" system and looks like we're losing elder
Tcl/Tk, and at least 0.72 supported both old and new Tcl/Tk.
(worked perl-581+Tcl/Tk-800, and perl-5.005_03+Tcl/Tk-8.4-Unicodish)

It appears that CPAN testers use old Tcl/Tk and *will* report FAILs in case
their version is very old.

In case support for old Tcl/Tk will be dropped, we must include proper check
in Makefile.PL, for people not even trying testing in this case.

My dream is to have something like Tcl.xs and Tcl800.xs, and Tcl800.xs could
just contain old non-Unicodish non-tcl-Object, just to have working bridge
even for such cases..

Best regards,
Vadim.

RE: [tcltk-perl] Makefile.PL cleanup [PATCH]

[Konovalov, V. <vko...@sp...>]

> > BTW once CVS will be working on "tcltk" project of SF site, 
> you will have
> > write access and apply reasonable changes by your own?
> 
> Thanks.  I'm known as 'gisle' at sourceforge if you want to add me as
> a maintainer.  Please tell me if you think patches are inappropriate
> for the list until then.  At least they create some traffic :-)
> 
> I think discussing patches on the list is the best way to reach
> consensus on the approach to take.  Trivial stuff which nobody is
> likely to disagree with (like my Tcl::Ev patch) is best checked in
> directly without telling the list.


I am very agree with you.

But "tcltk" does not have CVS yet, and I do not have rights to include you
anyway for that project.

Currently CVS from "tcltkce" project is used, now I've included you so you
should be able to do commits.
But anyway development is moving to "tcltk" project, and I am sure Jeff will
manage things correctly to include those who can help us developing module.

I hope Jeff will help us and inform more exact dates of CVS moving.

Best regards,
Vadim.

Re: [tcltk-perl] What version of perl is required?

[Gisle A. <gi...@Ac...>]

Related question is what versions of 'tcl' is the Tcl.pm supposed to
be compatible with?

--Gisle

Re: [tcltk-perl] Drop listify [PATCH]

[Gisle A. <gi...@Ac...>]

"Konovalov, Vadim" <vko...@sp...> writes:

> For sure we need an addition in test files to check handling array refs.

It looks like the tests could need more work in other areas too.  I'll
try to contribute some to it in the days ahead.

--Gisle

RE: [tcltk-perl] Drop listify [PATCH]

[Konovalov, V. <vko...@sp...>]

> > To be honest, I did not tried that Jeff's subroutine yet, 
> but why do you
> > think it should not be included?
> 
> Because it is dead code which i not needed.  Also the 'it is also not
> "comprehensive"' make me think it is actually buggy.

Now I see.
Looks like Jeff implemented it in Tcl.xs, so it is not needed indeed.

For sure we need an addition in test files to check handling array refs.

Vadim.

Re: [tcltk-perl] Makefile.PL cleanup [PATCH]

[Gisle A. <gi...@Ac...>]

"Konovalov, Vadim" <vko...@sp...> writes:

> BTW once CVS will be working on "tcltk" project of SF site, you will have
> write access and apply reasonable changes by your own?

Thanks.  I'm known as 'gisle' at sourceforge if you want to add me as
a maintainer.  Please tell me if you think patches are inappropriate
for the list until then.  At least they create some traffic :-)

I think discussing patches on the list is the best way to reach
consensus on the approach to take.  Trivial stuff which nobody is
likely to disagree with (like my Tcl::Ev patch) is best checked in
directly without telling the list.

--Gisle

Re: [tcltk-perl] Drop listify [PATCH]

[Gisle A. <gi...@Ac...>]

"Konovalov, Vadim" <vko...@sp...> writes:

> To be honest, I did not tried that Jeff's subroutine yet, but why do you
> think it should not be included?

Because it is dead code which i not needed.  Also the 'it is also not
"comprehensive"' make me think it is actually buggy.

> AFAIU it is used in perlTk compatibility widgets implementation.

I did not find any reference to this function in the Tcl-Tk module either.

--Gisle

RE: [tcltk-perl] Makefile.PL cleanup [PATCH]

[Konovalov, V. <vko...@sp...>]

Will apply this patch and a patch that you sent few letters ago :)

BTW once CVS will be working on "tcltk" project of SF site, you will have
write access and apply reasonable changes by your own?


> 
> 
> Suggested cleanup patch for Tcl's Makefile.PL. It gets rid of badly
> handcoded option parsing and replace it with Getopt::Long. Similar
> patch also makes sense for the Tcl-Tk one.
> 
> --Gisle
> 
> Index: Makefile.PL
> ===================================================================
> RCS file: /cvsroot/tcltkce/Tcl/Makefile.PL,v
> retrieving revision 1.3
> diff -u -p -u -r1.3 Makefile.PL
> --- Makefile.PL	9 Apr 2004 19:05:23 -0000	1.3
> +++ Makefile.PL	14 Apr 2004 08:52:43 -0000
> @@ -1,33 +1,24 @@
> +#!/usr/bin/perl -w
> +
>  # before running this script make sure you have 'tclsh' in 
> your path, 
>  # and this 'tcl' distribution is required one.
>  # FreeBSD users may want to modify name of tcl interpreter (this is
>  # $tclsh variable below) as long as 'tclsh' does not work in 
> their case
>  
> +use strict;
> +use Getopt::Long qw(GetOptions);
> +
>  my $tclsh = 'tclsh';
>  my $tclconfig;
>  my $buildspec;
>  my $libpath;
>  my $incpath;
>  
> -while (1) {
> -    # Handle any --options
> -    last unless @ARGV[0] =~ /^--/;
> -    my $opt = shift @ARGV;
> -    my $val = shift @ARGV;
> -    if ($opt eq "--tclsh") {
> -	$tclsh = $val;
> -    }
> -    elsif ($opt eq "--tclconfig") {
> -	$tclconfig = $val;
> -    }
> -    elsif ($opt eq "--buildspec") {
> -	$buildspec = 1;
> -    }
> -    else {
> -	die "unknown option '$opt', must be --tclsh, 
> --tclconfig or --buildspec\n";
> -    }
> -}
> -
> +GetOptions("tclsh=s", \$tclsh,
> +	   "tclconfig=s", \$tclconfig,
> +	   "buildspec", \$buildspec)
> +    || die "Usage: perl Makefile.PL [--tclsh <path>] 
> [--tclconfig <path>] " .
> +                                   "[--buildspec] 
> [<makemaker opts>...]\n";
>  
>  if ($tclconfig) {
>      die "Tcl config file '$tclconfig' not found\n" unless 
> (-f $tclconfig);
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Tcltk-perl mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcltk-perl
> 

RE: [tcltk-perl] Drop listify [PATCH]

[Konovalov, V. <vko...@sp...>]

To be honest, I did not tried that Jeff's subroutine yet, but why do you
think it should not be included? AFAIU it is used in perlTk compatibility
widgets implementation.

> This patch seems like a good idea to me.
> 
> --Gisle
> 
> 
> Index: Tcl.pm
> ===================================================================
> RCS file: /cvsroot/tcltkce/Tcl/Tcl.pm,v
> retrieving revision 1.9
> diff -u -p -u -r1.9 Tcl.pm
> --- Tcl.pm	12 Apr 2004 23:09:56 -0000	1.9
> +++ Tcl.pm	14 Apr 2004 09:18:45 -0000
> @@ -302,28 +302,6 @@ sub LINK_READ_ONLY ()	{ 0x80 }
>  
>  bootstrap Tcl;
>  
> -# This is a crude list-creating routine.  'icall' convert perl array
> -# refs into Tcl list objects efficiently, so this isn't necessary.
> -# It is also not "comprehensive", so should be used as a last resort.
> -sub listify {
> -    my $res;
> -    for my $arg (@_) {
> -	my $ref = ref($arg);
> -	$res .= " " if $res;
> -	if (!$ref && $arg =~ / /) {
> -	    $res .= "{$arg}";
> -	}
> -	elsif ($ref eq "ARRAY") {
> -	    $res .= "{" . listify(@$arg) . "}";
> -	}
> -	else {
> -	    $arg =~ s/\\/\\\\/g;
> -	    $res .= $arg;
> -	}
> -    }
> -    return $res;
> -}
> -
>  #TODO make better wording here
>  # %anon_refs keeps track of anonymous subroutines that were 
> created with
>  # "CreateComand" method during process of transformation of 
> arguments for
> @@ -386,12 +364,6 @@ sub call {
>  		# XXX needs testing
>  		$args[$argcnt] =
>  		    $interp->create_tcl_sub(sub 
> {$arg->[0]->(@$arg[1..$#$arg])});
> -	    }
> -	    else {
> -		# Do nothing here, as icall recurses into ARRAYs and
> -		# turns them into true Tcl lists
> -		# Should properly turn ARRAY into Tcl list
> -		#$args[$argcnt] = listify(@$arg);
>  	    }
>  	}
>      }
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Tcltk-perl mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcltk-perl
> 

RE: [tcltk-perl] What version of perl is required?

[Konovalov, V. <vko...@sp...>]

> > But did you used latest CVS version, where Jeff made many 
> improvements?
> 
> Yes, I'm using the CVS version as my baseline.

good...

RE: [tcltk-perl] Why is Tcl a subclass of Tck::Tk?

[Konovalov, V. <vko...@sp...>]

> > Could you please explain your way of doing things?
> 
> I would expect:
> 
>    $tcl = Tcl->new;
> 
> to give me an interpreter that only can do the plain Tcl stuff,
> i.e. what tclsh can do.
> 
> I would expect:
> 
>    $tcltk = Tcl::Tk->new
> 
> to be a subclass of Tcl that can do plain Tcl stuff as well as all the
> Tk stuff, ie. what wish can do.
> 
> I don't expect my $tcl to suddenly grow more capable or different just
> becase I happened to load the Tcl::Tk module in the same process
> later.  Perhaps I just misunderstand what tcl actually looks like
> underneath.  I have not used actually tcl in 15 years, so my memory of
> what it is is rusty.

All your arguments are very reasonable and in case you have patch please
give it to me.

Will you have commitment rights to CVS on SF?

Re: [tcltk-perl] What version of perl is required?

[Gisle A. <gi...@Ac...>]

"Konovalov, Vadim" <vko...@sp...> writes:

> But did you used latest CVS version, where Jeff made many improvements?

Yes, I'm using the CVS version as my baseline.

--Gisle

RE: [tcltk-perl] What version of perl is required?

[Konovalov, V. <vko...@sp...>]

> This patch is needed to get Tcl to build and have a clean 'make test'
> on perl5.005_04-RC1:


Thank you a lot.
Will insert those to next CPAN release.

But did you used latest CVS version, where Jeff made many improvements?

Best regards,
Vadim.

> 
> ==== //depot/users/gisle/hacks/Tcl/Tcl.xs#3 - 
> /home/gisle/hacks/Tcl/Tcl.xs ====
> Index: users/gisle/hacks/Tcl/Tcl.xs
> --- users/gisle/hacks/Tcl/Tcl.xs.~1~	Wed Apr 14 11:58:30 2004
> +++ users/gisle/hacks/Tcl/Tcl.xs	Wed Apr 14 11:58:30 2004
> @@ -15,6 +15,17 @@
>  #include "perl.h"
>  #include "XSUB.h"
>  
> +#ifndef dTHX
> +   #define dTHX ;
> +   #define pTHX_
> +   #define aTHX_
> +#endif
> +
> +#ifndef SvPV_nolen
> +    STRLEN my_na;
> +    #define SvPV_nolen(str) SvPV(str, my_na)
> +#endif
> +
>  #ifndef DEBUG_REFCOUNTS
>  #define DEBUG_REFCOUNTS 0
>  #endif
> @@ -136,9 +147,11 @@
>  	str = Tcl_GetStringFromObj(objPtr, &len);
>  	sv = newSVpvn(str, len);
>  	/* should turn on, but let's check this first for efficiency */
> +#ifdef SvUTF8_on
>  	if (len && has_highbit(str, len)) {
>  	    SvUTF8_on(sv);
>  	}
> +#endif
>      }
>      return sv;
>  }
> ==== //depot/users/gisle/hacks/Tcl/t/var.t#2 - 
> /home/gisle/hacks/Tcl/t/var.t ====
> Index: users/gisle/hacks/Tcl/t/var.t
> --- users/gisle/hacks/Tcl/t/var.t.~1~	Wed Apr 14 11:58:30 2004
> +++ users/gisle/hacks/Tcl/t/var.t	Wed Apr 14 11:58:30 2004
> @@ -41,6 +41,7 @@
>  
>  # some Unicode tests
>  if ($]>=5.006 && $i->GetVar("tcl_version")>=8.1) {
> +eval <<'EOT';  die $@ if $@;
>      $i->SetVar("univar","\x{abcd}\x{1234}");
>      if ($i->GetVar("univar") ne "\x{abcd}\x{1234}") {
>  	print "not ";
> @@ -55,6 +56,7 @@
>      print "ok 8 # Unicode persistence for tied variable\n";
>      binmode(STDOUT, ":utf8") if $] >= 5.008;
>      print "# $r\n";
> +EOT
>  }
>  else {
>      for (7..8) {print "ok $_  # skipped: not Unicode-aware 
> Perl or Tcl\n";}
> End of Patch.

[tcltk-perl] Tcl::Ev error check [PATCH]

[Gisle A. <gi...@Ac...>]

This patch make Tcl::Ev more correct.

==== //depot/users/gisle/hacks/Tcl/Tcl.pm#2 - /home/gisle/hacks/Tcl/Tcl.pm ====
Index: users/gisle/hacks/Tcl/Tcl.pm
--- users/gisle/hacks/Tcl/Tcl.pm.~1~	Wed Apr 14 13:12:40 2004
+++ users/gisle/hacks/Tcl/Tcl.pm	Wed Apr 14 13:12:40 2004
@@ -434,7 +434,7 @@
 }
 sub Ev {
     my $s = shift;
-    if (length($s)>1) {
+    if (!defined($s) || length($s) != 1) {
 	warn "Event variable must have length 1";
 	return;
     }
End of Patch.

Re: [tcltk-perl] Why is Tcl a subclass of Tck::Tk?

[Gisle A. <gi...@Ac...>]

"Konovalov, Vadim" <vko...@sp...> writes:

> > In Tcl.pm I see this code:
> > 
> >     unless (defined $Tcl::Tk::VERSION) {
> >         package Tcl::Tk; # define empty package
> >     }
> >     use vars qw(@ISA);
> >     @ISA = qw(DynaLoader Tcl::Tk);
> 
> I can agree this is not very correct way to do things...
> 
> > 
> > Why is Tcl as subclass of Tck::Tk insted of the other way around?  The
> > other way seems more logical.
> 
> Could you please explain your way of doing things?

I would expect:

   $tcl = Tcl->new;

to give me an interpreter that only can do the plain Tcl stuff,
i.e. what tclsh can do.

I would expect:

   $tcltk = Tcl::Tk->new

to be a subclass of Tcl that can do plain Tcl stuff as well as all the
Tk stuff, ie. what wish can do.

I don't expect my $tcl to suddenly grow more capable or different just
becase I happened to load the Tcl::Tk module in the same process
later.  Perhaps I just misunderstand what tcl actually looks like
underneath.  I have not used actually tcl in 15 years, so my memory of
what it is is rusty.

> The point here is that Tcl::Tk interpreter actually *is* plain Tcl
> interpreter and may be they be'll better joined intoone single module.

I think the separation is ok.

> OTOH having two different modules -- one is for low level communicating, and
> other is for Tk part (GUI and perlTk compatibility) is very handy for me:
> developing of Tcl::Tk could be done more easily and independent.

Agree.

--Gisle

Re: [tcltk-perl] What version of perl is required?

[Gisle A. <gi...@Ac...>]

"Konovalov, Vadim" <vko...@sp...> writes:

> > Apparently the code works with perl-5.6 and better, and fails with
> > perl-5.005.  Is this what is expected?  I ask because I was looking
> > into suggesting cleanups for the perl code, but was not sure which
> > perl's you try to stay portabe to.
> > 
> > If perl-5.6 is the baseline, then it is a good idea to put a:
> > 
> >    require 5.006;
> 
> At some moment I managed things to work with 5.005_03, and, to be honest,
> not very glad for 'Tcl' perl module to require 5.8.0.

Agree.  perl-5.6 is very much alive.  I'm not sure how many still are
stuck with 5.005 though.  I would suggest that perl-5.6 is made a
requirement.

> 5.6.1 compatibility could be approached however, but we must decide whether
> elder than 5.6.0 are supported.

> Could you please point out what is broken?

This patch is needed to get Tcl to build and have a clean 'make test'
on perl5.005_04-RC1:

==== //depot/users/gisle/hacks/Tcl/Tcl.xs#3 - /home/gisle/hacks/Tcl/Tcl.xs ====
Index: users/gisle/hacks/Tcl/Tcl.xs
--- users/gisle/hacks/Tcl/Tcl.xs.~1~	Wed Apr 14 11:58:30 2004
+++ users/gisle/hacks/Tcl/Tcl.xs	Wed Apr 14 11:58:30 2004
@@ -15,6 +15,17 @@
 #include "perl.h"
 #include "XSUB.h"
 
+#ifndef dTHX
+   #define dTHX ;
+   #define pTHX_
+   #define aTHX_
+#endif
+
+#ifndef SvPV_nolen
+    STRLEN my_na;
+    #define SvPV_nolen(str) SvPV(str, my_na)
+#endif
+
 #ifndef DEBUG_REFCOUNTS
 #define DEBUG_REFCOUNTS 0
 #endif
@@ -136,9 +147,11 @@
 	str = Tcl_GetStringFromObj(objPtr, &len);
 	sv = newSVpvn(str, len);
 	/* should turn on, but let's check this first for efficiency */
+#ifdef SvUTF8_on
 	if (len && has_highbit(str, len)) {
 	    SvUTF8_on(sv);
 	}
+#endif
     }
     return sv;
 }
==== //depot/users/gisle/hacks/Tcl/t/var.t#2 - /home/gisle/hacks/Tcl/t/var.t ====
Index: users/gisle/hacks/Tcl/t/var.t
--- users/gisle/hacks/Tcl/t/var.t.~1~	Wed Apr 14 11:58:30 2004
+++ users/gisle/hacks/Tcl/t/var.t	Wed Apr 14 11:58:30 2004
@@ -41,6 +41,7 @@
 
 # some Unicode tests
 if ($]>=5.006 && $i->GetVar("tcl_version")>=8.1) {
+eval <<'EOT';  die $@ if $@;
     $i->SetVar("univar","\x{abcd}\x{1234}");
     if ($i->GetVar("univar") ne "\x{abcd}\x{1234}") {
 	print "not ";
@@ -55,6 +56,7 @@
     print "ok 8 # Unicode persistence for tied variable\n";
     binmode(STDOUT, ":utf8") if $] >= 5.008;
     print "# $r\n";
+EOT
 }
 else {
     for (7..8) {print "ok $_  # skipped: not Unicode-aware Perl or Tcl\n";}
End of Patch.

RE: [tcltk-perl] Why is Tcl a subclass of Tck::Tk?

[Konovalov, V. <vko...@sp...>]

> In Tcl.pm I see this code:
> 
>     unless (defined $Tcl::Tk::VERSION) {
>         package Tcl::Tk; # define empty package
>     }
>     use vars qw(@ISA);
>     @ISA = qw(DynaLoader Tcl::Tk);

I can agree this is not very correct way to do things...

> 
> Why is Tcl as subclass of Tck::Tk insted of the other way around?  The
> other way seems more logical.

Could you please explain your way of doing things?

The point here is that Tcl::Tk interpreter actually *is* plain Tcl
interpreter and may be they be'll better joined intoone single module.

OTOH having two different modules -- one is for low level communicating, and
other is for Tk part (GUI and perlTk compatibility) is very handy for me:
developing of Tcl::Tk could be done more easily and independent.

Best regards,
Vadim.