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

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

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

> > I think you misread.  Let me rephrase ... we can create our own Tcl 
> > object type to wrap Perl SVs.  No compatability will be lost.
> 
> I did not realized that it is possible to create new Tcl 
> object type outside Tcl (in extension), but now I realize 
> this could be quite possible. And looks like most correct way to go...

It is indeed possible, and this is what TclBlend does (the
Tcl/Java interface) to keep Java objects wrapped.

Jeff

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

[Vadim K. <va...@ar...>]

> > > creating our own object type in Tcl to wrap Perl SVs, so
> > > we never lose touch either way.
> >
> > but in this case we'll lose compatibility with current
> > version of Tcl/Tk, 8.4.x, which do not have such object type...
>
> I think you misread.  Let me rephrase ... we can create our
> own Tcl object type to wrap Perl SVs.  No compatability will
> be lost.

I did not realized that it is possible to create new Tcl object type outside
Tcl (in extension), but now I realize this could be quite possible.
And looks like most correct way to go...

Vadim.

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

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

> > creating our own object type in Tcl to wrap Perl SVs, so
> > we never lose touch either way.
>
> but in this case we'll lose compatibility with current
> version of Tcl/Tk, 8.4.x, which do not have such object type...

I think you misread.  Let me rephrase ... we can create our
own Tcl object type to wrap Perl SVs.  No compatability will
be lost.

Jeff

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

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

> I think it would be valuable to actually have the Tcl namespace 
> "empty".  All I think it should have is a AUTOLOAD that turns 
> all method calls into a tcl procedure call.  I.e. that:
>     $tcl->foo($a, $b)
> is always the same as
>     $tcl->call("foo", $a, $b)
> is now.  That has the potential of simpilifying the Tk stuff I think.

Yes!  This is definitely what I want out of the API.  This
is what I was expecting in some ways (more natural to me
from a Perl and Tcl point of view), I just didn't know the
magic to make it happen.

There are a few calls that we want to reserve.  We do need
to keep around a few core things (like Eval, call, etc), but
we might make a standard of how to name them.

> For the Tcl::Tk stuff I would really like to be able to move 
> all that deals with perlTk compatiblity to its own module.  
> The API to trigger it could be the same, but as this grows in 
> complexity you don't want to load it when all you need is to 
> use the Tk interface as it is.

We are all in agreement - my perl fu is just not up to the
task of doing this quickly.  I was thinking that Tcl::Tk and
Tcl::pTk should be separate modules, instead of the odd (to me)
	use Tcl::Tk q(:perlTk);
that is there now.

Jeff

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

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

"Jeff Hobbs" <je...@Ac...> writes:

> I'd like to actually remove some of the Tcl API crap that I
> think has been around for eons (all the Get|SetVar*, Append*).
> These things do truly expose some Tcl C APIs (all the old
> string-only ones), but to what purpose?

I agree with that.  API functions like that could also just move to
different namespace to get them out of the way.  I think it would be
valuable to actually have the Tcl namespace "empty".  All I think it
should have is a AUTOLOAD that turns all method calls into a tcl
procedure call.  I.e. that:

    $tcl->foo($a, $b)

is always the same as

    $tcl->call("foo", $a, $b)

is now.  That has the potential of simpilifying the Tk stuff I think.

For the Tcl::Tk stuff I would really like to be able to move all that
deals with perlTk compatiblity to its own module.  The API to trigger
it could be the same, but as this grows in complexity you don't want
to load it when all you need is to use the Tk interface as it is.

--Gisle

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

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

> "Konovalov, Vadim" <vko...@sp...> writes:
> > If no one mind, I'll release both modules with version 0.77. (or is it 
> > reasonable to make version 0.80 due to many changes and improvements 
> > that were done?)
> 
> I would not jump the number, but it is all up to you.

Sync'ing to the same number is good, but I'm ambivalent about
jumping the number.  On the one hand, this is significantly
different than previous versions, but on the other - at the
actual API level, it's still the same (with more features).

I'd like to actually remove some of the Tcl API crap that I
think has been around for eons (all the Get|SetVar*, Append*).
These things do truly expose some Tcl C APIs (all the old
string-only ones), but to what purpose?

Maybe I'm being anal about cleaning up a few useless APIs,
but I certainly think there are more we should add (I'd like
to more efficiently tie Tcl and Perl's IO stuff together).

Jeff

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

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

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

> BTW I am planning to release both modules to CPAN tomorrow or at end of
> weekend.

Good.  I should probably hold back on changing more stuff for a while
then.

> If no one mind, I'll release both modules with version 0.77. (or is it
> reasonable to make version 0.80 due to many changes and improvements that
> were done?)

I would not jump the number, but it is all up to you.

--Gisle

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

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

> > > 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.
> 
> This patch make Tcl::Tk a subclass of Tcl instead of the other way
> around.  The test suite certainly still passes as well as it did
> before; t/optmenu.t have some failures but from its cvs log they
> appear to be know.

Very very nice.

t/optmenu.t has failures because test was borrowed from perlTk, and
Optionmenu there has possibility to display different string than
appropriate variable holds.
Probably this feature could be just ignored and protected from tests? Must
decide. 
Additionally, there exists in that test something like 
 $varref = $widget->cget('textvariable};
 $$varref;

So I'll add temporarily a wrapper function "wcall" to have this implemented,
later we'll improve that.
$int->wcall will call "$int->call" and will substitute result value from
%anon_refs hash.

BTW I am planning to release both modules to CPAN tomorrow or at end of
weekend.

If no one mind, I'll release both modules with version 0.77. (or is it
reasonable to make version 0.80 due to many changes and improvements that
were done?)

Best regards,
Vadim/

> 
> --Gisle
> 
> 
> Index: Tcl.pm
> ===================================================================
> RCS file: /cvsroot/tcltkce/Tcl/Tcl.pm,v
> retrieving revision 1.14
> diff -u -p -r1.14 Tcl.pm
> --- Tcl.pm	15 Apr 2004 13:25:20 -0000	1.14
> +++ Tcl.pm	16 Apr 2004 09:31:26 -0000
> @@ -272,11 +272,8 @@ See http://www.perl.com/perl/misc/Artist
>  
>  use strict;
>  use DynaLoader;
> -unless (defined $Tcl::Tk::VERSION) {
> -    package Tcl::Tk; # define empty package
> -}
>  use vars qw(@ISA);
> -@ISA = qw(DynaLoader Tcl::Tk);
> +@ISA = qw(DynaLoader);
>  
>  Tcl->bootstrap($Tcl::VERSION);
>  
> Index: Tcl.xs
> ===================================================================
> RCS file: /cvsroot/tcltkce/Tcl/Tcl.xs,v
> retrieving revision 1.21
> diff -u -p -r1.21 Tcl.xs
> --- Tcl.xs	15 Apr 2004 10:47:16 -0000	1.21
> +++ Tcl.xs	16 Apr 2004 09:31:27 -0000
> @@ -871,7 +871,7 @@ FETCH(av, key = NULL)
>  	    croak("bad object passed to Tcl::Var::FETCH");
>  	}
>  	sv = *av_fetch(av, 0, FALSE);
> -	if (sv_isa(sv, "Tcl")) {
> +	if (sv_derived_from(sv, "Tcl")) {
>  	    IV tmp = SvIV((SV *) SvRV(sv));
>  	    interp = (Tcl) tmp;
>  	}
> @@ -904,7 +904,7 @@ STORE(av, sv1, sv2 = NULL)
>  	if (AvFILL(av) != 1 && AvFILL(av) != 2)
>  	    croak("bad object passed to Tcl::Var::STORE");
>  	sv = *av_fetch(av, 0, FALSE);
> -	if (sv_isa(sv, "Tcl")) {
> +	if (sv_derived_from(sv, "Tcl")) {
>  	    IV tmp = SvIV((SV *) SvRV(sv));
>  	    interp = (Tcl) tmp;
>  	}
> Index: lib/Tcl/Tk.pm
> ===================================================================
> RCS file: /cvsroot/tcltkce/TclTk/lib/Tcl/Tk.pm,v
> retrieving revision 1.21
> diff -u -p -r1.21 Tk.pm
> --- lib/Tcl/Tk.pm	15 Apr 2004 22:07:31 -0000	1.21
> +++ lib/Tcl/Tk.pm	16 Apr 2004 09:32:00 -0000
> @@ -5,7 +5,7 @@ use Tcl;
>  use Exporter;
>  use DynaLoader;
>  use vars qw(@ISA @EXPORT_OK %EXPORT_TAGS);
> -@ISA = qw(Exporter DynaLoader);
> +@ISA = qw(DynaLoader Exporter Tcl);
>  
>  $Tcl::Tk::VERSION = '0.77';
>  
> @@ -340,6 +340,7 @@ sub new {
>  	$sync = 0;
>      }
>      $i = new Tcl;
> +    bless $i, $class;
>      if (!defined($tkinterp)) {
>  	# CreateMainWindow is no longer necessary (was for pre-Tk8)
>  	#$i->CreateMainWindow($display, $name, $sync);
> @@ -371,11 +372,11 @@ sub new {
>  }
>  
>  sub tkinit {
> -    $tkinterp = new(@_);
> +    $tkinterp = Tcl::Tk->new(@_);
>      $mainwindow;
>  }
>  sub MainWindow {
> -    $tkinterp = new(@_);
> +    $tkinterp = Tcl::Tk->new(@_);
>      $mainwindow;
>  }
>  
> 

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

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

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

> > > 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.

This patch make Tcl::Tk a subclass of Tcl instead of the other way
around.  The test suite certainly still passes as well as it did
before; t/optmenu.t have some failures but from its cvs log they
appear to be know.

--Gisle


Index: Tcl.pm
===================================================================
RCS file: /cvsroot/tcltkce/Tcl/Tcl.pm,v
retrieving revision 1.14
diff -u -p -r1.14 Tcl.pm
--- Tcl.pm	15 Apr 2004 13:25:20 -0000	1.14
+++ Tcl.pm	16 Apr 2004 09:31:26 -0000
@@ -272,11 +272,8 @@ See http://www.perl.com/perl/misc/Artist
 
 use strict;
 use DynaLoader;
-unless (defined $Tcl::Tk::VERSION) {
-    package Tcl::Tk; # define empty package
-}
 use vars qw(@ISA);
-@ISA = qw(DynaLoader Tcl::Tk);
+@ISA = qw(DynaLoader);
 
 Tcl->bootstrap($Tcl::VERSION);
 
Index: Tcl.xs
===================================================================
RCS file: /cvsroot/tcltkce/Tcl/Tcl.xs,v
retrieving revision 1.21
diff -u -p -r1.21 Tcl.xs
--- Tcl.xs	15 Apr 2004 10:47:16 -0000	1.21
+++ Tcl.xs	16 Apr 2004 09:31:27 -0000
@@ -871,7 +871,7 @@ FETCH(av, key = NULL)
 	    croak("bad object passed to Tcl::Var::FETCH");
 	}
 	sv = *av_fetch(av, 0, FALSE);
-	if (sv_isa(sv, "Tcl")) {
+	if (sv_derived_from(sv, "Tcl")) {
 	    IV tmp = SvIV((SV *) SvRV(sv));
 	    interp = (Tcl) tmp;
 	}
@@ -904,7 +904,7 @@ STORE(av, sv1, sv2 = NULL)
 	if (AvFILL(av) != 1 && AvFILL(av) != 2)
 	    croak("bad object passed to Tcl::Var::STORE");
 	sv = *av_fetch(av, 0, FALSE);
-	if (sv_isa(sv, "Tcl")) {
+	if (sv_derived_from(sv, "Tcl")) {
 	    IV tmp = SvIV((SV *) SvRV(sv));
 	    interp = (Tcl) tmp;
 	}
Index: lib/Tcl/Tk.pm
===================================================================
RCS file: /cvsroot/tcltkce/TclTk/lib/Tcl/Tk.pm,v
retrieving revision 1.21
diff -u -p -r1.21 Tk.pm
--- lib/Tcl/Tk.pm	15 Apr 2004 22:07:31 -0000	1.21
+++ lib/Tcl/Tk.pm	16 Apr 2004 09:32:00 -0000
@@ -5,7 +5,7 @@ use Tcl;
 use Exporter;
 use DynaLoader;
 use vars qw(@ISA @EXPORT_OK %EXPORT_TAGS);
-@ISA = qw(Exporter DynaLoader);
+@ISA = qw(DynaLoader Exporter Tcl);
 
 $Tcl::Tk::VERSION = '0.77';
 
@@ -340,6 +340,7 @@ sub new {
 	$sync = 0;
     }
     $i = new Tcl;
+    bless $i, $class;
     if (!defined($tkinterp)) {
 	# CreateMainWindow is no longer necessary (was for pre-Tk8)
 	#$i->CreateMainWindow($display, $name, $sync);
@@ -371,11 +372,11 @@ sub new {
 }
 
 sub tkinit {
-    $tkinterp = new(@_);
+    $tkinterp = Tcl::Tk->new(@_);
     $mainwindow;
 }
 sub MainWindow {
-    $tkinterp = new(@_);
+    $tkinterp = Tcl::Tk->new(@_);
     $mainwindow;
 }
 

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

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

> > 1. it could be reasonable to sometimes make reverse
> > subtitution of parameters after getting result of Tcl
> > calculation. May be in subroutine with slightly different
> > name (wcall?)
> >
> > it is needed for, say, $widget->cget('-textvariable') to
> > return a reference scalar and not a name like _SCALAR_0xXXXXXX
> >
> Yes, it would be nice to be able to round trip these
> values better.  I think the first run would be to clean
> up how the module creates commands and vars in Tcl (use
> a ::perl namespace, where we can also create our own
> stuff like ::perl::eval).  Later on we could look into

this looks like this is robust enough way...

> creating our own object type in Tcl to wrap Perl SVs, so
> we never lose touch either way.

but in this case we'll lose compatibility with current version of Tcl/Tk,
8.4.x, which do not have such object type...


> > 2. I see it very useful for DEBUGging purposes to have a
> > possibility to track what exactly list passed to "icall" and
> > what returned from it. This helps in developing perlTk
> > compatibility subroutines...
> 
> This is just another couple of print statements cased on
> DEBUG, no?

yes, only that, and I, while I use those, I did not even inserted those into
CVS because those are so easy and obvious, so anyone who needs them just add
"print" statements and go...


Best regards,
Vadim.

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

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

"Jeff Hobbs" <je...@Ac...> writes:

> > Is there a semantic difference between [list a b c] and {a b c}
> > in Tcl the language?  If not, then I don't think they should be
> > different when passed to perl either.
> 
> OH man, oh man ... this is sticky.  Yes and no.  At the C level,
> the first is a pure list (perl AV), while the second is just a
> string.  You can stringify the list and listify the string, just
> as you can convert an SvPV to an AV and back.

I read this answer to mean that there is no semantic difference.  What
it is represented as internally should not matter.  There is no two-way
conversion between strings and arrays in perl.

>                                              The trick is that
> in passing a Tcl_Obj to become and SV, I check the object types
> first for efficient conversion (trying to reduce round-tripping
> through strings, which I think you've noticed the positive
> effect of).

I understand all that, but I don't think this should dictate the
semantics.

> I think that I've properly handled it with the recent changes to
> call and icall.  If something is still "not right", please tell
> me.

To me it wrong if:

    $tcl->Eval("set var {a b c}");

returns something different to perl than

    $tcl->Eval("set var [list a b c]");

if these two expressions have exactly the same semantics in Tcl.

I would suggest that we always return the string in scalar context and
always list in list context.  If the value is not a valid list, then
we croak in list context.

Alternatively we return return some object that just wraps the Tcl_Obj
and can used as both a string and array reference.  This can be
combined with the previous alternative, so this only happens in scalar
context.

Alternatively we have a separate methods that indicate if a string,
array reference or list is wanted as return value.

   $tcl->Eval_giving_string($code);
   $tcl->Eval_giving_arrayref($code);
   $tcl->Eval_giving_list($code);

--Gisle

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

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

> 1. it could be reasonable to sometimes make reverse
> subtitution of parameters after getting result of Tcl
> calculation. May be in subroutine with slightly different
> name (wcall?)
>
> it is needed for, say, $widget->cget('-textvariable') to
> return a reference scalar and not a name like _SCALAR_0xXXXXXX
>
> Very correct way is not obvious to me, but half-correct way
> is to create another wrapper layer subroutine wcall that will
> search content of $res (and @res?) in %anon_refs hash.

Yes, it would be nice to be able to round trip these
values better.  I think the first run would be to clean
up how the module creates commands and vars in Tcl (use
a ::perl namespace, where we can also create our own
stuff like ::perl::eval).  Later on we could look into
creating our own object type in Tcl to wrap Perl SVs, so
we never lose touch either way.

> 2. I see it very useful for DEBUGging purposes to have a
> possibility to track what exactly list passed to "icall" and
> what returned from it. This helps in developing perlTk
> compatibility subroutines...

This is just another couple of print statements cased on
DEBUG, no?

Jeff

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

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

> Is there a semantic difference between [list a b c] and {a b c}
> in Tcl the language?  If not, then I don't think they should be
> different when passed to perl either.

OH man, oh man ... this is sticky.  Yes and no.  At the C level,
the first is a pure list (perl AV), while the second is just a
string.  You can stringify the list and listify the string, just
as you can convert an SvPV to an AV and back.  The trick is that
in passing a Tcl_Obj to become and SV, I check the object types
first for efficient conversion (trying to reduce round-tripping
through strings, which I think you've noticed the positive
effect of).

I think that I've properly handled it with the recent changes to
call and icall.  If something is still "not right", please tell
me.  It's important to be careful, because the way that Tcl will
convert a string to a list is indifferent to extra whitespace.
The following all represent the same thing in when listified:

set var {a    b    c}
set var {  a b c  }
set var {a
b
c}

Jeff

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

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

Gisle Aas wrote:
> "Konovalov, Vadim" <vko...@sp...> writes:
>>Please update ChangeLog in all such cases.
>>I am not very knowledgable in ChangeLog's techniques, but looks like it
>>should contain comments on every little change, and I noticed yesterday you
>>did update without touching ChangeLog.
> 
> 
> My plan was to create some ChangeLog entries from the CVS log at the
> end of the day.  I would be more happy if we actually had the
> ChangeLog autogenerated from the CVS log.

What I do is write the ChangeLog entries, and copy those directly
into my commit messages.

Jeff

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

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

Is there a semantic difference between [list a b c] and {a b c} in Tcl
the language?  If not, then I don't think they should be different when
passed to perl either.

--Gisle

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

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

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

> Please update ChangeLog in all such cases.
> I am not very knowledgable in ChangeLog's techniques, but looks like it
> should contain comments on every little change, and I noticed yesterday you
> did update without touching ChangeLog.

My plan was to create some ChangeLog entries from the CVS log at the
end of the day.  I would be more happy if we actually had the
ChangeLog autogenerated from the CVS log.

--Gisle

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

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

> > This patch make Tcl::Ev more correct.
> 
> I've applied this patch myself now; Tcl.pm -r1.14

Thank you a lot.

Please update ChangeLog in all such cases.
I am not very knowledgable in ChangeLog's techniques, but looks like it
should contain comments on every little change, and I noticed yesterday you
did update without touching ChangeLog.

Thank you once again for providing help.

Best regards,
Vadim.

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

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

Gisle Aas <gi...@ca...> writes:

> This patch make Tcl::Ev more correct.

I've applied this patch myself now; Tcl.pm -r1.14

--Gisle

> ==== //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] Drop listify [PATCH]

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

> OK, I think the real problem was the bit of code at the end of
> 'call' that conflicted with Tcl.xs:prepare_Tcl_result() which
> handled the G_SCALAR / G_ARRAY diffs already.  I think the
> following patch is appropriate, and it works with a call.t that
> I just checked into CVS.  Please comment on this, as I am not
> certain that I'm not breaking some perl basic assumptions here.

I see new code as good improvements of elder one.

However I have few ideas to this bit of code, and I have them implemented in
my local machine:

1. it could be reasonable to sometimes make reverse subtitution of
parameters after getting result of Tcl calculation. May be in subroutine
with slightly different name (wcall?)

it is needed for, say, $widget->cget('-textvariable') to return a reference
scalar and not a name like _SCALAR_0xXXXXXX

Very correct way is not obvious to me, but half-correct way is to create
another wrapper layer subroutine wcall that will search content of $res (and
@res?) in %anon_refs hash.

2. I see it very useful for DEBUGging purposes to have a possibility to
track what exactly list passed to "icall" and what returned from it. This
helps in developing perlTk compatibility subroutines...


> 
> Index: Tcl.pm
> ===================================================================
> RCS file: /cvsroot/tcltkce/Tcl/Tcl.pm,v
> retrieving revision 1.9
> diff -u -r1.9 Tcl.pm
> --- Tcl.pm      12 Apr 2004 23:09:56 -0000      1.9
> +++ Tcl.pm      14 Apr 2004 18:33:09 -0000
> @@ -395,15 +395,23 @@
>             }
>         }
>      }
> -    my (@res,$res);
> -    eval {
> -       @res = $interp->icall(@args);
> -    };
> -    if ($@) {
> -       confess "Tcl error $@ while invoking call\n \"@args\"";
> +    if (wantarray) {
> +       my @res;
> +       eval { @res = $interp->icall(@args); };
> +       if ($@) {
> +           confess "Tcl error '$@' while invoking array 
> result call:\n" .
> +               "\t\"@args\"";
> +       }
> +       return @res;
> +    } else {
> +       my $res;
> +       eval { $res = $interp->icall(@args); };
> +       if ($@) {
> +           confess "Tcl error '$@' while invoking scalar 
> result call:\n" .
> +               "\t\"@args\"";
> +       }
> +       return $res;
>      }
> -    return @res if wantarray;
> -    return $res[0];
>  }
> 
> 
> Jeff
> 
> 
> 
> -------------------------------------------------------
> 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...>]

> > > Related question is what versions of 'tcl' is the Tcl.pm 
> supposed to
> > > be compatible with?
> 
> > 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..
> 
> My dream is that people realize 8.0 is 7 years old and used
> newer versions of Tcl.  However, if you wanted to support it,
> the only thing you need to fix is Tcl_GetString (that was
> added in 8.1, but is simply Tcl_GetStringFromObj(var, NULL))
> and Tcl_FindExecutable (that's 8.1+).

Supporting 8.0 is not necessity, but in case we'll drop it, we *must*
improve Makefile.PL to detect elder Tcl/Tk versions and refuse to go through
build and test, otherwise CPAN testers will send a bunch of FAILs.

My opinion is gaining compatibility is even easier that fixing Makefile.PL
properly 
:) :)

> I reference tclStringTypePtr (8.1+) and tclWideIntTypePtr (8.4+),
> but don't actually use them yet, so there is no issue there (they
> will be NULL).
> 
> All the object stuff is correct in 8.0.  I'm not using the Tcl
> unicode routines in Tcl.xs, so there's no issue there.
> 
> Tcl::Tk does have some Tk 8.4 references as well, but I don't
> think that's a big deal (for example, labelframe and panedwindow
> are both 8.4+ widgets, but if you don't use them, no problem).

This sounds very promising...

Best regards,
Vadim.	

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

[Jan D. <ja...@Ac...>]

Gisle posted the following patch earlier today (before I subscribed to
the list):

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

The definition of dTHX is not robust.  You should use something like
this:

    #define dTHX extern int Perl___notused

without the trailing semicolon.  Otherwise code breaks if dTHX is
followed by more variable declarations:

    int
    foo(pTHX_ int arg)
    {
        dTHX;
        int bar;
        /* ... */
    }

The definition above is also what perl.h generates for current Perl when
you are not using PERL_IMPLICIT_CONTEXT.

Cheers,
-Jan

[tcltk-perl] RE: Re[4]: Tcl-Tk

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

> > Personally, I would restrict all my work to ActiveTcl-based
> > extensions.  These are better documented / maintained, and you can
> > just grab ActiveTcl for several platforms and build Tcl and Tcl::Tk
> > against it without issue.
>
> ... but Tix is not one of them... BTW do you mean you will
> revive it (I saw you did some CVS commits to Tix on SF)

I may make an updated release of Tix, but I don't want to
encourage the use of it.  It's a system that is showing its
age.  The very core design is just flawed in several ways.

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos

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

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

> OK, I think the real problem was the bit of code at the end 
> of 'call' that conflicted with Tcl.xs:prepare_Tcl_result() 
> which handled the G_SCALAR / G_ARRAY diffs already.  I think 
> the following patch is appropriate, and it works with a 
> call.t that I just checked into CVS.  Please comment on this, 
> as I am not certain that I'm not breaking some perl basic 
> assumptions here.

I have gone ahead and commited changes that turn on the
Tcl_ListObj -> AV and rewritten 'call' based on my earlier
patch.  Tests are all still successful.

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?

> 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..

My dream is that people realize 8.0 is 7 years old and used
newer versions of Tcl.  However, if you wanted to support it,
the only thing you need to fix is Tcl_GetString (that was
added in 8.1, but is simply Tcl_GetStringFromObj(var, NULL))
and Tcl_FindExecutable (that's 8.1+).

I reference tclStringTypePtr (8.1+) and tclWideIntTypePtr (8.4+),
but don't actually use them yet, so there is no issue there (they
will be NULL).

All the object stuff is correct in 8.0.  I'm not using the Tcl
unicode routines in Tcl.xs, so there's no issue there.

Tcl::Tk does have some Tk 8.4 references as well, but I don't
think that's a big deal (for example, labelframe and panedwindow
are both 8.4+ widgets, but if you don't use them, no problem).

Jeff

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

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

> 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];

OK, I think the real problem was the bit of code at the end of
'call' that conflicted with Tcl.xs:prepare_Tcl_result() which
handled the G_SCALAR / G_ARRAY diffs already.  I think the
following patch is appropriate, and it works with a call.t that
I just checked into CVS.  Please comment on this, as I am not
certain that I'm not breaking some perl basic assumptions here.

Index: Tcl.pm
===================================================================
RCS file: /cvsroot/tcltkce/Tcl/Tcl.pm,v
retrieving revision 1.9
diff -u -r1.9 Tcl.pm
--- Tcl.pm      12 Apr 2004 23:09:56 -0000      1.9
+++ Tcl.pm      14 Apr 2004 18:33:09 -0000
@@ -395,15 +395,23 @@
            }
        }
     }
-    my (@res,$res);
-    eval {
-       @res = $interp->icall(@args);
-    };
-    if ($@) {
-       confess "Tcl error $@ while invoking call\n \"@args\"";
+    if (wantarray) {
+       my @res;
+       eval { @res = $interp->icall(@args); };
+       if ($@) {
+           confess "Tcl error '$@' while invoking array result call:\n" .
+               "\t\"@args\"";
+       }
+       return @res;
+    } else {
+       my $res;
+       eval { $res = $interp->icall(@args); };
+       if ($@) {
+           confess "Tcl error '$@' while invoking scalar result call:\n" .
+               "\t\"@args\"";
+       }
+       return $res;
     }
-    return @res if wantarray;
-    return $res[0];
 }


Jeff